From: Guillaume Nault <gnault@redhat.com>
To: Matthias May <matthias.may@westermo.com>
Cc: netdev@vger.kernel.org, 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
Subject: Re: [PATCH 2/2 net-next] geneve: fix TOS inheriting for ipv6
Date: Wed, 27 Jul 2022 16:45:48 +0200 [thread overview]
Message-ID: <20220727144548.GB31646@pc-4.home> (raw)
In-Reply-To: <712bcd84-4dbe-67a6-afa9-ddc01ea27cc8@westermo.com>
On Tue, Jul 26, 2022 at 06:29:56PM +0200, Matthias May wrote:
> On 25/07/2022 19:05, Guillaume Nault wrote:
> > On Sun, Jul 24, 2022 at 02:37:41AM +0200, Matthias May wrote:
> > > The current code uses the RT_TOS macro to cut off the 6 DSCP
> > > bits, down to the original 3 TOS bits.
> > >
> > > Do not use this macro to get the prio for inheriting purposes.
> >
> > Honestly, this patch is a bug fix and is suitable for the net tree
> > (with appropriate 'Fixes' tag).
> >
> > Ideally, we'd also fix ip6_dst_lookup_tunnel() (used by bareudp
> > tunnels) and vxlan6_get_route().
> >
> > Also, mlx5e_tc_tun_update_header_ipv6() and
> > mlx5e_tc_tun_create_header_ipv6() both call RT_TOS() inside
> > ip6_make_flowinfo() and certainly need to be fixed too.
> >
>
> Hi Guillaume
> How would i do that?
> Send a v2 to net with the fixes tag on 95caf6f71a999?
> Or just resend to net with the fixes tag on 95caf6f71a999?
> Since there are no actual changes to the patch.
Hi Matthias,
Ideally, send a patch series to net that'd removes RT_TOS() from the
ip6_make_flowinfo() calls in geneve, vxlan and bareudp (one patch for
each protocol, with the appropriate Fixes tag). You can add the IPv4
patch in that series or send it separately, as you see fit.
Alternatively you can just repost this series to net, with a proper
Fixes tag for each patch (and I'll take care of vxlan and bareudp in
a future series).
> This kind of contradicts the statement that IPv4 and IPv6 should behave the same.
> --> v6 would be fixed, but v4 not.
I personally consider the current IPv4 behaviour for TOS inherit option
to be a bug, so, in this case, we can have both IPv4 and IPv6 fixed in
the same tree.
But generally speaking, we have some divergence in how IPv4 and IPv6
treat tos/dsfield. That's because of some historical reasons and it's
not easy to reconciliate both implementations (because of backward
compatibility).
> BR
> Matthias
next prev parent reply other threads:[~2022-07-27 14:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-24 0:37 [PATCH 0/2 net-next] geneve: fix TOS inheriting Matthias May
2022-07-24 0:37 ` [PATCH 1/2 net-next] geneve: fix TOS inheriting for ipv4 Matthias May
2022-07-24 0:37 ` [PATCH 2/2 net-next] geneve: fix TOS inheriting for ipv6 Matthias May
2022-07-25 17:05 ` Guillaume Nault
2022-07-26 16:29 ` Matthias May
2022-07-27 14:45 ` Guillaume Nault [this message]
2022-07-25 16:57 ` [PATCH 0/2 net-next] geneve: fix TOS inheriting Guillaume Nault
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=20220727144548.GB31646@pc-4.home \
--to=gnault@redhat.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=eyal.birger@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthias.may@westermo.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=pabeni@redhat.com \
--cc=yoshfuji@linux-ipv6.org \
/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.