Re: Q: Interrupts for transferring datapackets to thehardware

Thank you for answering this.

Unfortunately your answer brings up other questions for me, so perhaps 
it's better if I describe the idea that I want to implement. It would be very
kind if somebody could tell me whether I'm on a totally wrong trail and
if there is an easier way to solve my task.

I am interested in the time it takes for a tx-packet to be transmitted after
having being placed in one of the device tx-queues ("service time" for a
packet at the MAC layer). For each tx-queue I would be interested in some
averaged estimations like the average service rate (the ratio of transmitted
packets per timespan per queue).

As far as I understand the 2915 has only one cmd queue, 4 tx queues and 1 rx
queue (hardware). I'm thinking about some way of getting this 
time which would represent the service ratio by using the device interrupts 
and the drivers queue slots reclaim function /ipw_queue_tx_reclaim/
(mostly because I did not see an easy way of calculating these times
from the information the device gives me).

I think the ratio of reclaimed slots per timespan per queue should give 
me a good estimation of the actual "service times" for  packets in a 
specific queue, because these slots get reclaimed after the device sends 
an interrupt. As far as I understand this interrupt is thrown by the card 
after it has just pulled out packets from the ipw-queues and transferred 
them to the device.
Am I correct on this?

On the topic of empty queues I would be especially interested in the following:
Can it happen, that the device tries to pull out packets from a driver queue and
then sees it's empty or does this scenario never happen because for a pull from
a specific queue there is always a corresponding cmd in the cmd-queue and so 
there would never be interrupts on empty queues?

Based on this I'm planning to make some tests, whether 
this ratio and actual "service times" correspond to each other in a good
way.

Regards Klaus

p.s. also thank you for the correction of my spelling. I'm pretty glad
that after not writing English for some years, nobody showed up bombing
my car for some serious insults I slipped unawarely into the text. I'll
do my best to keep it readable  :-) 



Cahill, Ben M schrieb:
> It's been a long time since I looked at 2200/2915 driver code, but IIRC,
> those devices work pretty much the same way as 3945/4965.
>
> The device (2200, etc.) has Tx/cmd queues that the driver fills with Tx
> or other commands (all commands to the device flow through these).  When
> the device services one of these commands, it responds to the driver
> with a response packet and an interrupt.  It will also send a "response"
> and interrupt when it receives a frame to pass to driver.
>
> -- Ben --
>
> p.s.  "it's" = "it is" (*often* misused when someone really means "its"
> = possessive "it", which is what you mean below) ... just a pet peeve of
> mine!  :-)
>
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/