Re: Q: Interrupts for transferring datapackets to thehardware

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of [email protected]
> Sent: Thursday, November 15, 2007 8:11 AM
> To: ipw2200
> Subject: Re: [Ipw2100-devel] 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).

Again, it's been a while since I looked at 2200, but if it works like
3945/4965, the Tx response gets issued just after all the bits have been
transmitted through the radio, and the packet has been ACK'd by the
receiver.  So, if you can measure the time between 1)  placing the
packet on the queue, and 2) getting an interrupt announcing the Tx
response (the response that corresponds to the packet of interest), that
should hopefully give you what you're looking for.  If packet was
successful, you might want to subtract the normal time for the receiver
to issue the ACK, depending on your needs (time to attempt Tx vs time to
complete the transfer, including ACK).

Background:  The device issues a Tx response after attempting each Tx
command.  Responses arrive at the driver via the same mechanism as Rx
frames (i.e. the Rx queue).  I'm not sure if 2200 issues a Tx response
after each Tx *attempt* (successful or not), or after a series of
attempts for the one packet (i.e. after trying rate scaling until
receiving an ACK, or after trying all rates and never receiving an ACK).
You may need to experiment a bit with that.

> 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?

Not sure ... if this is a different interrupt from the one (rx) that
announces command responses, rx packets, etc., and it happens before the
rx interrupt, then this may be true.  Pulling the bits into the device
would, of course, occur some short time before they actually get to "the
air", and then it takes little bit more time to receive the ACK.

> 
> 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?

I don't think you'll see interrupts from 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  :-) 

Your English is excellent!  :-)

-- Ben --
> 
> 
> 
> 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 --

-------------------------------------------------------------------------
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/