Maybe you did not see where I wrote,

  "I guess that these chipset features could be used to implement `hardware
  ALTQ(9)' by analogy to `hardware crypto' ? I think that a driver can
  provide a hardware implementation of some CBQ, HFSC, and PRIQ configs
  by overloading the {cbq,hfsc,priq}_class_create routines. Some CBQ and
  PRIQ configs will map to rtw's prioritized rings. Some HFSC configs might
  also map to a combo of prioritized rings and a contention-free ring."

Nope, I didn't!

  > packets from ring 0 if there are any, and if not takes the first packet
  > from ring 1, etc.?

  The card I am playing with has high-, normal-, and low-priority descriptor
  rings which work as you describe above. As you mention, the hardware
  implementation is advantageous for reasons of deeper pipelines and
  fewer interrupts.

OK, so mostly we are looking at priority queues.

  I think that the NIC's multiple transmit priorities can help to
  alleviate HOL blocking kind of like this: if_start puts all packets in
  the normal-priority ring by default. In a HOL-blocking condition involving
  weak/busy receiver W, if_starts puts packets for W into the low-priority
  ring, and packets for a receiver R != W into the high-priority ring. When
  the blocking condition is over, packets for W go into the low-priority
  ring until its weak/busy condition ends. Packets for receivers R !=
  W go into the normal-priority ring.

What one really needs is some sort of per-receiver queue with
fairshare unless an CTS is not forthcoming, in which case the packet
gets skipped for now.   But I suppose you could implement the above
scheme, except that it isn't immediately clear how W is fingered,
unless the kernel keeps track of the outgoing packets and scores
receivers based on inter-transmit gap when the txcomplete interrupts
happen.  At least that seems to be the hard part.

But the use of queues to mitigate problems from HOL blocking doesn't
require any tagging or QOS processing; this is really about just the
driver (or 802.11 layer, or more generally for all interfaces that
use a per-receiver RTS which may not be forthcoming).

-- 
        Greg Troxel <gdt@ir.bbn.com>