On Sat, Jan 10, 2004 at 03:45:42PM -0500, Greg Troxel wrote:
>   "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.).

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."

> 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.?

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.

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

No CBQ, no RED. I *think* you can stop a ring independent of the others.

> 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 think that multiple hardware transmit priorities will help solve some
obscure problems that bedevil WISPs (volo.net) and community networks
(cuwireless.net).  (The person who is interested in 802.11 for home or
office use, only, might want to stop reading at this point.)  One of
the problems is called "head-of-line blocking."

In head-of-line (HOL) blocking, packets at the head of the queue cannot
be transmitted because the nexthop is not ready to receive them, so
packets at the tail of the queue, whose nexthops ARE ready to receive
them, wait. And wait and wait and wait: to transmit a 1500-byte packet
ten times at 1Mb/s makes following packets wait more than a tenth of a
second, which wreaks havoc on important protocols.

HOL blocking happens in 802.11b networks when the packet at the head of
the Tx queue is destined for a "weak receiver" or a "busy receiver." By a
"weak receiver," I mean one who receives our packets with low S/N ratio,
thus requiring a low data rate, retries, fragmentation, or all of the
above. By a "busy receiver," I mean one who is in communication with
hidden nodes. By the time the packets for the weak receivers get sent
many times at a piddling 1Mb/s, the packets at the tail of the queue
might be too late: a TCP ACK is overdue, say, or else somebody's VoIP
stream has "stuttered".

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.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933