[PATCH] 802.1p priority (fixed)

[Andre Oppermann]

Brooks Davis wrote:
> 
> On Sun, Jan 23, 2005 at 11:05:19AM +0500, Boris Kovalenko wrote:
> >       And what this changes? Some switches totally ignore 802.1p. We're
> > talking about IEEE standard and should fully support it. Also, may You
> > point me where You have read this?

Chiming in somewhere into this thread...

> The issue is that you may need the ability to treat some values as
> though they are the same because some network environments will do this.
> 
> While I think a lower level solution will be the most useful in the
> end, I don't object to an interface based solution.  I think you should
> proceed with that with the idea that you add a third, optional keyword
> to vlan initalization to specify priority.  That way you can create
> seperate interfaces for each priority for any vlan tag.  Something like:
> 
> ifconfig vlan create vlan 2 vlandev fxp0 vlanpri 3

For a clean handling of 802.1p tagging we should handle it like this:

 1. Extend to ifconfig and vlan to be able to specify a DEFAULT vlan
    priority.

 2. Have vlan insert the 802.1p priority from a generic layer 2 specifics
    aganostic priority m_tag into the vlan header overiding any configured
    default value on the vlan interface.

 3. Extend any|all of the packet filters and|or ALTQ to set the generic
    layer 2 priority tag directly via the m_tag.  Propagation of any pritority
    information contained in the layer 3 (IP TOS) is done through the
    packet filters subject to their filtering abilities to prevent abuse.

 4. Provide a way for applications (via setsockopt) to specify their priority
    wishes.

The entire tagging thing should be generic that other kinds of networks
can use it as well (frame relay for example).  I think 4 bits is fine.
If less than 16 priorities are supported it should shift to the right
and use the remainder.

Starting with just the default vlan priority configuration via ifconfig
is fine with provided that the overriding via m_tags is documented that
we don't have POLA problems later on when we implement the full thing.

-- 
Andre