[ath9k-devel] [Make-wifi-fast] Diagram of the ath9k TX path

Well, there shouldn't /also/ be a software queue behind each TXQ at
that point. Eg, in FreeBSD, I queue up to 64 frames per station and
then default to round robining between stations when it's time to form
another aggregate. It's done that way so i or someone else can
implement a wifi queue discipline in between the per-station / per-TID
queues and the hardware queue that knew about time of flight, etc.

The variations on the internal driver tended to slide some more
complicated queue management and rate control between the bit that
dequeued from the per-TID/per-STA packet queue and formed aggregates.
Ie, the aggregate was only formed at hardware queue time, and only two
were pushed into the hardware at once. There were only deep hardware
queues in very old, pre-11n drivers, to minimise CPU overhead.

So yeah, do reduce that a bit. The hardware queue should be two
frames, there shouldn't be anything needed to be queued up behind it
in the software queue backing it if you're aggregating, and if you
/are/, that queue should be backed based on flight time (eg lots of
little frames, or one big aggregate, but not lots of big aggregates.)

Yeah, I also have to add NOACK support for A-MPDU in the freebsd
driver for various reasons (voice, yes, but also multicast A-MPDU.)
You just need to ensure that you slide along the BAW in a way that
flushes the sender, or you may drop some frames but you're in the BAW,
and then the receiver buffers them for up to their timeout value
(typically tens of milliseconds) waiting for more frames in the BAW
(hopefully retries). I dunno if you're really allowed to be sending
NOACK data frames if you've negotiated immediate blockack though!

And yeah for time? totally depends on what you're doing. Yes, if you
have lots of stations actively doing traffic, then yes you should just
form smaller aggregates. It's especially good for dealing with the
full frame retries (ie, RTS/CTS worked, but the data frame didn't, and
you didn't get a block-ack at all.) On longer aggregates, that can
/really/ hurt - ie, you're likely better off doing one full retry only
and then failing it so you can requeue it in software and break it up
into a smaller set of aggregates after the rate control code gets the
update.

(God, I should really do this all to freebsd now that I'm kinda
allowed to again..)


-adrian