netdev - Re: [net-next PATCH] net: Correct TOS priority mapping for DSCP EF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 15 Sep 2014 17:09:13 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	brouer@...hat.com
Cc:	netdev@...r.kernel.org, eric.dumazet@...il.com,
	shemminger@...tta.com
Subject: Re: [net-next PATCH] net: Correct TOS priority mapping for DSCP EF

From: Jesper Dangaard Brouer <brouer@...hat.com>
Date: Mon, 15 Sep 2014 16:50:47 +0200

> The DSCP value for Expedited Forwarding (EF) got mapped to
> internal priority TC_PRIO_INTERACTIVE_BULK, which ends up in
> medium/best-effort priority band(1) of pfifo_fast
> 
> This patch change TOS mapping, causing the DSCP EF to get mapped
> to TC_PRIO_INTERACTIVE, which end up in high priority band(0)
> of pfifo_fast.
> 
> While performing this policy change, document the TOS to priority
> lookup table ip_tos2prio[16].  Thus, making it easier to
> understand this table for reviewers.
> 
> The DSCP AFxx mappings are also suboptimal, but we choose not to
> change those mapping, only document the mapping in the code.
> 
> Signed-off-by: Jesper Dangaard Brouer <brouer@...hat.com>

I don't think you can make these mappings given that we don't
take the code-service bits of the TOS into account when we use
this table at all.

The DSCP values are composed in the top 6 bits, but we are only
considering the low 3 bits of that field (along with the high
bit of "CU", which is part of the ECN value and thus "don't care")

We should only match EF when the top two DSCP bits are "10".

This table and it's relationship to DSCP is confusing (but your
comments in this patch helped a lot, thanks).  Also it isn't
clear why we don't interpret the full DSCP field.

ECN_OR_COST() does nothing but serve as an annotation meaning
that this value has an ECN bit set.

So why don't we shift down by two bits, to get rid of the entire
"CU" field, and consider all 6 bits of the DSCP value in the
ip_tos2prio[] table?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html