Search Linux Wireless

Re: ar9271 TX/RX buffer management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Adding linux-wireless as I review ath9k/ar9170 tx/rx buffer management here.

On Tue, Sep 8, 2009 at 1:54 PM, Denis Kirjanov<kirjanov@xxxxxxxxx> wrote:
> Looks like tx/rx engine initialization code is very similar to ath9k
> driver.

I expect most of the driver to be very similar to ath9k, what changes
here is the transport and because of it support for HTC/HIF. What also
changes with the new transport requirements is the need to sleep
during read/writes. This is actually the main reason for a new
mac80211 driver interface. We could have mucked with ath9k itself but
feared that the changes are too intrusive so instead we'll work on a
different driver core where this is done. Technically it may be
possible in the future to have ath9k rely on the same driver core, who
knows but for now the job is to get ar9271 support up.

> The question is where to obtain some values such as the number of TX|RX
> buffers? Will these values are the same as that of the previous driver?

That's yet to be determined/developed and I'm glad you asked. First
let me review ath9k's TX/RX buffer management, then I'll review ar9170
buffer management and explain why I think we should consider doing
something a little different for ath9k_htc. Note I wrote ar9170, not
ar9271.

ath9k TX buffer management
========================

ath9k allocates a preset of TX buffers structs (struct ath_buf) upon
init and stuffs them into a spare buffer linked list. When mac80211
informs us it wants to TX an skb, ath9k_tx(), a buffer is taken from
this spare list, the skb is linked to the ath_buf, DMA'd and then the
ath_buf added onto the appropriate tx queue linked list depending on
the skb priority/TID. Upon TX completion the ath_buf is reset and put
back into the spare buffer list. When we are are low on spare ath_buf
buffers we ask mac80211 to stop sending us data, once we have enough
free spare buffers we wake the queues up again. We guarantee that we
will at some point tell mac80211 to send us data again as we only tell
mac80211 to stop sending us data if we have at least one pending
completion buffer list.

ath9k RX buffer management
=========================

ath9k allocates a preset of RX buffers and stuffs them into a linked
list. The buffers are DMA'd so that the hardware can stuff into each
buffer data for us to retrieve and send up to mac80211. Upon RX we
always allocate a new buffer prior to sending a frame up to mac80211
so that we can fill in the gap for the missing skb of the current skb
and if there is no more memory we stuff the buffer we currently are
processing into the free RX buffers linked list and disregard the
DMA'd data. We then tell the hardware it can use that same buffer
space again. If we were able to allocate a new buffer in place for the
current one we send it to mac80211 for processing. We use a
predetermined RX buffer size. This RX buffer size is the space
required to receive the biggest frame possible on the ath9k 802.11n
hardware -- which happens to be the biggest AMSDU frame. I should note
that although AMSDU frames are typically not received as I don't think
many devices or drivers support sending AMDSU frames I believe wifi
cert requires you to RX AMSDU frames. Anyway this AMSDU size
requirement pushes our RX buffer size close to 4 KB and because the
kernel only gaurantees it'll *at least* allocate the requested size we
sometimes end up allocating 8KB per buffer on some systems. We could
potentially improve upon this, I believe we'd have to link AMSDU data
together across different descriptors, and I think that's possible.

ar9170 TX buffer management
=========================

ar9170 uses a tx_pending skb_buf_head for stashing skbs mac80211 sends
it. Contrary to ath9k it uses the skb to place the private driver tx
control info for the skb to indicate to the hardware how to transmit
that frame. Aggregates are put into an another skb_queue_head for the
destination TID for the destination sta and that TID is added to a
linked list of pending TIDs which need processing. It later iterates
through the list of TIDs, and queues pending buffers ont the
tx_pending skb_buf_head. Eventually we peg the skb->data onto a urb
and submit it to the device on the endpoint.

ar9170 RX buffer management
==========================

ar9170 uses a USB stream mode to receive buffers. This means a single
urb received being processed can contain more than one data buffer.
This gets untangled by ar9170_rx() and handled individually on
ar9170_handle_mpdu(). Because the data is tangled on a stream it means
we have to allocate an skb for each frame and then copy the data onto
it. This is done on  ar9170_rx_copy_data().

-------------

What I'd like to eventually see is a common shared buffer management
for TX for aggregation for drivers like ar9170 or ath9k where
aggregation is done in software. Then we won't have such different
implementations. Using the skb_buf_head usage on ar9170 seems
appealing over ath9k's linked list of buffers, however not that this
is easily possible on ar9170 as the skb->data is simply filled with
the ar9170_tx_control info. I can't think of a way to do the same on
ath9k. If we can figure out a way it'd be great so we can try to
eventually share buffer management for aggregation on mac80211. I
shall note some aspects of aggregation is handled in firmware for
ar9271, haven't gotten to review what exactly yet.

One thing which I think we should learn from how ar9170 is implemented
for ar9271 is using urb anchors.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux