On Fri, Jan 09, 2004 at 09:55:23AM -0500, Greg Troxel wrote:
>   Here is my proposal in code for associating VLAN tags with hardware
>   queues.
> 
> OK, but...
> 
>     % pass out to vlan0 proto ospf
>     % pass out to vlan2 tcp port ftp-data
>     % pass out to vlan1
> 
> Perhaps it would help if you gave a problem statement.

Probably. How is this?

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

"All other things being equal, users and developers will prefer a familiar
UI and an existing API."

> Creating
> vlans, giving them different qos treatment, and then using ipfilter to
> direct traffic onto them (if I followed your example) seems odd to me,
> when you could be using CBQ, PRIQ or something else (from ALTQ)
> instead.

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.

> If what you really want is a bunch of vlans (with vlan tagging on the
> wire), and you want to do qos processing of the hardware-level output
> queue to give priority to some vlans, then I would think you'd want to
> add vlan tag as an option to the ALTQ classifier so you can use it as
> a CBQ/PRIQ selector.

Yes, I think so.

Dave

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