Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Matthias May <matthias.may@westermo.com>
To:     <netdev@vger.kernel.org>
CC:     <davem@davemloft.net>, <yoshfuji@linux-ipv6.org>,
        <dsahern@kernel.org>, <edumazet@google.com>, <kuba@kernel.org>,
        <pabeni@redhat.com>, <nicolas.dichtel@6wind.com>,
        <eyal.birger@gmail.com>, <linux-kernel@vger.kernel.org>,
        Matthias May <matthias.may@westermo.com>
Subject: [PATCH 0/2 net-next] geneve: fix TOS inheriting
Date:   Sun, 24 Jul 2022 02:37:39 +0200
Message-ID: <20220724003741.57816-1-matthias.may@westermo.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk

Currently when the TOS of an encapsulated frame is inherited,
the 6 DSCP bits are cut down to 3 original TOS bits.
Compare to other L2 tunneling protocols (gretap, vxlan) this
is unexpected.
IPv4 and IPv6 have both this behaviour but for different reasons.

For IPv4 the bits are lost in the routing table lookup.
The patch copies the full tos out before the lookup and uses the copy.

For IPv6 the RT_TOS macro cuts off the 3 bits.
I'm not really familiar with the IPv6 code, but to me it seems as
if this part of the code only uses the TOS for the flowlabel.
Is there any reason why the flowlabel should be restricted to these
3 bits? The patch simply removes the usage of this macro, but i don't
know if there was a specific intention behind that. I can't find any
immediate breakage, but then again my IPv6 testing is fairly limited.

Matthias May (2):
  geneve: fix TOS inheriting for ipv4
  geneve: fix TOS inheriting for ipv6

 drivers/net/geneve.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

-- 
2.35.1