From: Jouni Malinen <j@w1.fi>
To: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Cc: johannes@sipsolutions.net, linux-wireless@vger.kernel.org,
Ilan Peer <ilan.peer@intel.com>,
Gregory Greenman <gregory.greenman@intel.com>,
Johannes Berg <johannes.berg@intel.com>
Subject: Re: [PATCH 06/14] wifi: cfg80211: Update the default DSCP-to-UP mapping
Date: Sun, 17 Dec 2023 11:42:05 +0200 [thread overview]
Message-ID: <ZX7CbSCEv7Zvv476@w1.fi> (raw)
In-Reply-To: <20231211085121.8a1c7d1f0034.I50aed38be78ae9aea052938e2cb6b5800010ecd4@changeid>
On Mon, Dec 11, 2023 at 09:05:24AM +0200, Miri Korenblit wrote:
> The default DSCP-to-UP mapping method defined in RFC8325
> applied to packets marked per recommendations in RFC4594 and
> destined to 802.11 WLAN clients will yield a number of inconsistent
> QoS mappings.
>
> To handle this, modify the mapping of specific DSCP values for
> which the default mapping will create inconsistencies, based on
> the recommendations in section 4 in RFC8325.
Could this commit message give some more justification for why these
exact specifications are the best source of this information? For
example, should this also reference the Wi-Fi QoS Management
specification?
> diff --git a/net/wireless/util.c b/net/wireless/util.c
> @@ -980,7 +980,53 @@ unsigned int cfg80211_classify8021d(struct sk_buff *skb,
> }
> }
>
> + /* The default mapping as defined in RFC8325 */
> ret = dscp >> 5;
Could you point to the exact location in RFC 8325 that has that as the
default mapping? Figure 1 has this note: "Note: All unused codepoints
are RECOMMENDED to be mapped to UP 0".
Section 2.4 does describe what many APs do, but that section is called
"Default UP-to-DSCP Mappings and Conflicts" which does not sound like a
recommended default mapping in RFC 8325..
> + /* Handle specific DSCP values for which the default mapping doesn't
> + * adhere to the intended usage of the DSCP value. See section 4 in
> + * RFC8325.
> + */
> + switch (dscp >> 2) {
What about "Standard: DF" (0 --> 0) and "Low-Priority Data: CS1" (8 ->
1)? Are those omitted here because the "dscp >> 5" happens to have same
value? It would seem to be good to have at least a comment here pointing
that out in particular taken into account that comment above about the
status of that "default mapping" and how it relates to RFC 8325.
> + case 10:
> + case 12:
> + case 14:
> + /* High throughput data: AF11, AF12, AF13 */
> + ret = 0;
> + break;
> + case 16:
> + /* Operations, Administration, and Maintenance and Provisioning:
> + * CS2
> + */
> + ret = 0;
> + break;
> + case 18:
> + case 20:
> + case 22:
> + /* Low latency data: AF21, AF22, AF23 */
> + ret = 3;
> + break;
> + case 24:
> + /* Broadcasting video: CS23 */
> + ret = 4;
> + break;
Typo.. Should be "CS3" instead of "CS23".
What about "Multimedia Streaming: AF31, AF32, AF33"? Shouldn't those
values 26, 28, 30 be mapped to 4? If not, it would be good to add a
comment explaining why that is not here while it is included in RFC 8325
Figure 1.
What about "Real-Time Interactive: CS4"? Shouldn't that value 32 be
mapped to 4? If not, it would be good to add a comment explaining why
that is not here while it is included in RFC 8325 Figure 1.
What about "Multimedia Conferencing: AF41, AF42, AF43"? Shouldn't those
values 34, 36, 38 be mapped to 4? If not, it would be good to add a
comment explaining why that is not here while it is included in RFC 8325
Figure 1.
> + case 40:
> + /* Signaling: CS5 */
> + ret = 5;
> + break;
> + case 44:
> + /* Voice Admit */
> + ret = 6;
> + break;
To be consistent, that comment should be "VOICE-ADMIT: VA".
> + case 46:
> + /* Telephony traffic: EF */
> + ret = 6;
> + break;
> + case 48:
> + /* Network Control Traffic: CS6 */
> + ret = 7;
> + break;
> + }
This does not include "Network Control: CS7". Is there a reason for not
covering that case 56 now? I know it is "reserved for future use", but
RFC 8325 does provide mapping for it as well.
--
Jouni Malinen PGP id EFC895FA
next prev parent reply other threads:[~2023-12-17 9:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-11 7:05 [PATCH 00/14] cfg80211/mac80211 patches from our internal tree 2023-12-10 Miri Korenblit
2023-12-11 7:05 ` [PATCH 01/14] wifi: mac80211: don't re-add debugfs during reconfig Miri Korenblit
2023-12-11 7:05 ` [PATCH 02/14] wifi: cfg80211: add BSS usage reporting Miri Korenblit
2023-12-11 7:05 ` [PATCH 03/14] wifi: mac80211: update some locking documentation Miri Korenblit
2023-12-11 7:05 ` [PATCH 04/14] wifi: cfg80211: Add support for setting TID to link mapping Miri Korenblit
2023-12-11 7:05 ` [PATCH 05/14] wifi: mac80211: add a flag to disallow puncturing Miri Korenblit
2023-12-11 7:05 ` [PATCH 06/14] wifi: cfg80211: Update the default DSCP-to-UP mapping Miri Korenblit
2023-12-12 9:39 ` Johannes Berg
2023-12-13 11:52 ` Peer, Ilan
2023-12-17 9:42 ` Jouni Malinen [this message]
2023-12-17 15:11 ` Peer, Ilan
2023-12-18 9:30 ` [PATCH v2] " Ilan Peer
2023-12-11 7:05 ` [PATCH 07/14] wifi: mac80211: Replace ENOTSUPP with EOPNOTSUPP Miri Korenblit
2023-12-11 7:05 ` [PATCH 08/14] wifi: cfg80211: " Miri Korenblit
2023-12-11 7:05 ` [PATCH 09/14] wifi: cfg80211: generate an ML element for per-STA profiles Miri Korenblit
2023-12-11 7:05 ` [PATCH 10/14] wifi: cfg80211: consume both probe response and beacon IEs Miri Korenblit
2023-12-11 7:05 ` [PATCH 11/14] wifi: mac80211: don't set ESS capab bit in assoc request Miri Korenblit
2023-12-11 7:05 ` [PATCH 12/14] wifi: mac80211: check defragmentation succeeded Miri Korenblit
2023-12-11 7:05 ` [PATCH 13/14] wifi: mac80211: mesh_plink: fix matches_local logic Miri Korenblit
2023-12-11 7:05 ` [PATCH 14/14] wifi: mac80211: mesh: check element parsing succeeded Miri Korenblit
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=ZX7CbSCEv7Zvv476@w1.fi \
--to=j@w1.fi \
--cc=gregory.greenman@intel.com \
--cc=ilan.peer@intel.com \
--cc=johannes.berg@intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=miriam.rachel.korenblit@intel.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.