From: David Acker <dacker@roinet.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Kalle Valo <kalle.valo@iki.fi>,
linux-wireless@vger.kernel.org, patrik.flykt@nokia.com
Subject: Re: WMM classification guideline for applications?
Date: Sun, 06 Dec 2009 13:10:33 -0500 [thread overview]
Message-ID: <4B1BF399.1020103@roinet.com> (raw)
In-Reply-To: <1260096387.3461.2.camel@johannes.local>
Johannes Berg wrote:
> On Fri, 2009-12-04 at 11:08 -0500, David Acker wrote:
>
>> I am not an expert on how the kernel handles vlans, but it appears that
>> the priority field's value is set by the user space VLAN creation tools
>> through an ioctl with SET_VLAN_EGRESS_PRIORITY_CMD which calls
>> vlan_dev_set_egress_priority to map an skb priority to a vlan priority.
>> vlan_dev_hard_header then uses this information to populate the vlan
>> priority field based on the skb priority field.
>>
>> In this case it would seem that skb priority and the vlan priority are
>> both set and there may be a non-trivial mapping between the two.
>
> But doesn't that also mean that mac80211 can happily ignore the VLAN
> priority in the packet, because the vlan code will have propagated it to
> the skb->priority, if the administrator wishes to use it?
You are correct on rx. The tricky part is the non-trivial mapping on
tx. If mac80211 only looks at the skb->priority and assumes priority 0
means best effort, the code could be missing that skb->priority 0 maps
to vlan priority 7. If we define that mac80211 only looks at
skb->priority, perhaps we should allow user space control of the mapping
of the skb->priority to WMM priority queue. This could be similar to
the mapping capabilities in the VLAN code. That way, an admin can make
sure that the skb priority is mapped to both an appropriate vlan
priority and an appropriate WMM priority queue.
-ack
__________ Information from ESET Smart Security, version of virus signature database 4663 (20091205) __________
The message was checked by ESET Smart Security.
http://www.eset.com
next prev parent reply other threads:[~2009-12-06 18:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-04 14:02 WMM classification guideline for applications? Kalle Valo
2009-12-04 15:14 ` David Acker
2009-12-04 15:24 ` Kalle Valo
2009-12-04 16:08 ` David Acker
2009-12-04 16:56 ` Greg Oliver
2009-12-04 19:15 ` Dan Williams
2009-12-04 20:01 ` David Acker
2009-12-07 15:11 ` Kalle Valo
2009-12-04 21:01 ` Kalle Valo
2009-12-06 10:46 ` Johannes Berg
2009-12-06 18:10 ` David Acker [this message]
2009-12-06 18:32 ` Johannes Berg
2009-12-07 1:34 ` David Acker
2009-12-06 10:57 ` Johannes Berg
2009-12-07 15:50 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B1BF399.1020103@roinet.com \
--to=dacker@roinet.com \
--cc=johannes@sipsolutions.net \
--cc=kalle.valo@iki.fi \
--cc=linux-wireless@vger.kernel.org \
--cc=patrik.flykt@nokia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.