"Some NICs have multiple transmit descriptor rings which can be used
  to implement QoS, but NetBSD does not let us use them. The problem is
  to provide an API and a user interface so that developers and users can
  exploit those rings to implement QoS policies.

I see this somewhat differently, more like how a crypto coprocessor
can be used to speed up operations that are already possible in
software (IPsec, SSL, etc.).

So one could ask,

  Given the existing ALTQ framework in NetBSD, how can we use hardware
  support to offload some of the processing, or gain some efficiency?
  For example, many NICs support the loading of TX descriptors for
  multiple packets, but this is slightly incompatible with QoS
  disciplines that want to select the next packet as closely as
  possible to TX time in order to get precise conformance to e.g. CBQ
  or PRIQ schemes.  So, a card that had multiple queues with defined
  qos processing could be used to offload some of the altq processing.

So, I might ask what the typical behavior of cards with multiple
txdesc rings are, or the card you are playing with.  Can you program
it to do priority queues among them, so that it takes packets from
ring 0 if there are any, and if not takes the first packet from ring
1, etc.?  Then if ALTQ is doing a priority queue and has fewer classes
than rings, the final priq selection could be offloaded to the card,
enabling deeper pipelining and perhaps more speed and/or reduced CPU
utiliziation from fewer interrupts.

Or can the cards be programmed to do CBQ?  RED?  Or can the host turn
them on and off individually?

But, I've found that I really want QoS mechanisms when the link is
slow and packets are building up.  This can certainly happen on slower
Ethernets, but these are precisely where the CPU cost of altq is not a
big deal.  Sorry if I'm sounding contrary, but the real benefits of
exploiting this feature are not immediately apparent to me.

I do think it is important to have general mechanisms, and then use
hardware support when it works, rather than having different
mechanisms for each kind of hardware.

Or am I talking about something different than you mean?

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