All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] ath_tx_send_ampdu, DMA descriptors, and pending_frames.
Date: Fri, 07 Jan 2011 08:05:06 -0800	[thread overview]
Message-ID: <4D2739B2.9060101@candelatech.com> (raw)

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

                 reply	other threads:[~2011-01-07 16:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D2739B2.9060101@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ath9k-devel@lists.ath9k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.