RE: [PATCH V2] vlan priority handling in WMM

["voncken" <cedric.voncken@acksys.fr>]

> > The vlan Tag contain three bit for priority. The value 0 indicate no 
> > priority (on this case the VLAN tag contain only VID). The vlan_tci 
> > field is set to zero if the frame do not contain the vlan tag. So if 
> > we have not a vlan tag or no priority in VLAN tag the priority value 
> > is always 0.

> Yes but don't we know that the vlan_tci field is valid?

> I don't think you're correct in that 0 means "no priority present", it actually means "best effort" as far as I can tell. Ignoring the VLAN tag when the field is 0 would mean we could use a higher priority from the contents of the frame, which would not be desired?

I can add a test with the macro vlan_tx_tag_present() to verify if the vlan_tci field is valid. 
I test the value 0 to skip the VLAN priority and use the dscp priority in this case. The priority 0 in VLAN tag is often use to turn off the QOS, because not bit is allowed for it.
For me is it correct. Nevertheless, if you prefer, I can test only the vlan_tci validity and in this case always use the VLAN priority.

> > Sorry but I don't understand. The vlan_tci field it is a __u16 value 
> > (defined in include/linux/skbuff.h), the VLAN_PRIO_MASK is set to
> > 0xE000 and VLAN_PRIO_SHIFT is set to 13 (defined in 
> > include/linux/if_vlan.h), the vlan_priority is an unsigned char. For 
> > me the vlan_priority contain a 3-bit value (0xE000 >>13 = 0x0003), why
> > 2 ?

> Umm? No? Think again about what hweight(0x0003) is.

Sorry I made a mistake  0xE000 >>13 = 0x0007 and not 0x0003, and 7 is a 3 bits value.

Cedric