From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Greear Date: Fri, 07 Jan 2011 08:05:06 -0800 Subject: [ath9k-devel] ath_tx_send_ampdu, DMA descriptors, and pending_frames. Message-ID: <4D2739B2.9060101@candelatech.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org In ath_tx_start, the packet is mapped to DMA and then sent to ath_tx_start_dma. However, ath_tx_start_dma may in turn call ath_tx_send_ampdu, which may choose to buffer the packet on a tid->buf_q instead of sending it directly to the hardware. From comments in the code, it will buffer for any of these reasons: /* * Do not queue to h/w when any of the following conditions is true: * - there are pending frames in software queue * - the TID is currently paused for ADDBA/BAR request * - seqno is not within block-ack window * - h/w queue depth exceeds low water mark */ If we have lots of stations and/or lots of AMPDU packets, I think it could consume all (or way too many) of the tx DMA descriptor resources and yet leave the actual DMA transmit logic idle. Should we perhaps not do the DMA mapping until we are actually ready to transmit the packet? I think that in conjunction with this, we should not be so quick to call ath_mac80211_stop_queue unless the *hardware* queues are too full, not just the pending buffers waiting on a tid to un-pause, etc. I think that would allow stations to continue to transmit frames even if others are paused for whatever reason. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com