[RFC]: vlan priority handling in WMM

[RFC]: vlan priority handling in WMM

[voncken]

	I would like to manage the VLAN priority in Wireless QOS (WMM).

	I get the VLAN tag from skb->vlan_tci and I extract the VLAN priority. 

	How I should handle the priority value 0. 
		- Handle this value as no priority request, In this case the frame will sent with the DSCP priority or default (Best effort)
		- Handle this value as a lowest priority, in this case I Map it to the WMM.

	For your information, you can found below a discussion on this point with Johannes Berg.

	Regards.

	Cedric Voncken.

-----Message d'origine-----
De : Johannes Berg [mailto:johannes@sipsolutions.net] 
Envoyé : lundi 8 juillet 2013 14:16
À : voncken
Cc : linux-wireless@vger.kernel.org
Objet : Re: [PATCH V2] vlan priority handling in WMM

On Mon, 2013-07-08 at 12:39 +0200, voncken wrote:
> > > 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.

What do you mean by "is often used"? I don't see how that would be the case? Are you saying routers commonly ignore the VLAN priority value if it's 0? That would seem odd?

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

I don't know! Since you don't seem to really know either, we should ask somebody who knows, I think. Maybe you should Cc netdev with this question on the patch or so?

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

Ah yes, I made the same mistake, sorry.

johannes

[RFC]: vlan priority handling in WMM

[Cedric Debarge]

Dear mailing list,

I would like to manage the VLAN priority in Wireless QOS (WMM).

I get the VLAN tag from skb->vlan_tci and I extract the VLAN priority. 

How I should handle the priority value 0. 
	- Handle this value as no priority request, In this case the frame will 
		sent with the DSCP priority or default (Best effort)
	- Handle this value as a lowest priority, in this case I Map it to the WMM.

For your information, you can found below a discussion on this point 
with Johannes Berg.

Regards.

Cedric Voncken.

-----Message d'origine-----
De : Johannes Berg [mailto:johannes@sipsolutions.net]
Envoyé : lundi 8 juillet 2013 14:16
À : voncken
Cc : linux-wireless@vger.kernel.org
Objet : Re: [PATCH V2] vlan priority handling in WMM

On Mon, 2013-07-08 at 12:39 +0200, voncken wrote:
> > > 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.

What do you mean by "is often used"? I don't see how that would be the case? Are you saying routers commonly ignore the VLAN priority value if it's 0? That would seem odd?

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

I don't know! Since you don't seem to really know either, we should ask somebody who knows, I think. Maybe you should Cc netdev with this question on the patch or so?

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

Ah yes, I made the same mistake, sorry.

johannes

Re: [RFC]: vlan priority handling in WMM

[Ben Hutchings]

On Thu, 2013-07-11 at 09:45 +0200, Cedric Debarge wrote:
> Dear mailing list,
> 
> I would like to manage the VLAN priority in Wireless QOS (WMM).
> 
> I get the VLAN tag from skb->vlan_tci and I extract the VLAN priority. 
> 
> How I should handle the priority value 0. 
> 	- Handle this value as no priority request, In this case the frame will 
> 		sent with the DSCP priority or default (Best effort)
>         - Handle this value as a lowest priority, in this case I Map it to the WMM.
[...]

IEEE 802.1q refers to the definition in 802.1d:

> The user_priority parameter is the priority requested by the
> originating service user. The value of this parameter is in the range
> 0 through 7.
> 
> NOTE—The default user_priority value is 0. Values 1 through 7 form an
> ordered sequence of user_priorities, with 1 being the lowest value and
> 7 the highest. See 7.7.3 and Annex G (informative) for further
> explanation of the use of user_priority values.

So a value of 0 should be treated as no priority request, same as for an
untagged frame.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.