From: Guillaume Nault <gnault@redhat.com>
To: Ido Schimmel <idosch@nvidia.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
pabeni@redhat.com, edumazet@google.com, dsahern@kernel.org,
ast@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev,
john.fastabend@gmail.com, steffen.klassert@secunet.com,
herbert@gondor.apana.org.au, bpf@vger.kernel.org
Subject: Re: [PATCH net-next 00/12] Unmask upper DSCP bits - part 2
Date: Tue, 27 Aug 2024 15:47:05 +0200 [thread overview]
Message-ID: <Zs3Y2ehPt3jEABwa@debian> (raw)
In-Reply-To: <20240827111813.2115285-1-idosch@nvidia.com>
On Tue, Aug 27, 2024 at 02:18:01PM +0300, Ido Schimmel wrote:
> tl;dr - This patchset continues to unmask the upper DSCP bits in the
> IPv4 flow key in preparation for allowing IPv4 FIB rules to match on
> DSCP. No functional changes are expected. Part 1 was merged in commit
> ("Merge branch 'unmask-upper-dscp-bits-part-1'").
>
> The TOS field in the IPv4 flow key ('flowi4_tos') is used during FIB
> lookup to match against the TOS selector in FIB rules and routes.
>
> It is currently impossible for user space to configure FIB rules that
> match on the DSCP value as the upper DSCP bits are either masked in the
> various call sites that initialize the IPv4 flow key or along the path
> to the FIB core.
>
> In preparation for adding a DSCP selector to IPv4 and IPv6 FIB rules, we
Hum, do you plan to add a DSCP selector for IPv6? That shouldn't be
necessary as IPv6 already takes all the DSCP bits into account. Also we
don't need to keep any compatibility with the legacy TOS interpretation,
as it has never been defined nor used in IPv6.
> need to make sure the entire DSCP value is present in the IPv4 flow key.
> This patchset continues to unmask the upper DSCP bits, but this time in
> the output route path.
next prev parent reply other threads:[~2024-08-27 13:47 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 11:18 [PATCH net-next 00/12] Unmask upper DSCP bits - part 2 Ido Schimmel
2024-08-27 11:18 ` [PATCH net-next 01/12] ipv4: Unmask upper DSCP bits in RTM_GETROUTE output route lookup Ido Schimmel
2024-08-27 13:55 ` Guillaume Nault
2024-08-27 11:18 ` [PATCH net-next 02/12] ipv4: Unmask upper DSCP bits in ip_route_output_key_hash() Ido Schimmel
2024-08-27 13:57 ` Guillaume Nault
2024-08-27 11:18 ` [PATCH net-next 03/12] ipv4: icmp: Unmask upper DSCP bits in icmp_route_lookup() Ido Schimmel
2024-08-27 14:16 ` Guillaume Nault
2024-08-27 11:18 ` [PATCH net-next 04/12] ipv4: Unmask upper DSCP bits in ip_sock_rt_tos() Ido Schimmel
2024-08-27 14:29 ` Guillaume Nault
2024-08-27 11:18 ` [PATCH net-next 05/12] ipv4: Unmask upper DSCP bits in get_rttos() Ido Schimmel
2024-08-27 14:43 ` Guillaume Nault
2024-08-27 11:18 ` [PATCH net-next 06/12] ipv4: Unmask upper DSCP bits when building flow key Ido Schimmel
2024-08-27 14:51 ` Guillaume Nault
2024-08-27 15:37 ` Ido Schimmel
2024-08-27 11:18 ` [PATCH net-next 07/12] xfrm: Unmask upper DSCP bits in xfrm_get_tos() Ido Schimmel
2024-08-27 14:54 ` Guillaume Nault
2024-08-27 11:18 ` [PATCH net-next 08/12] ipv4: Unmask upper DSCP bits in ip_send_unicast_reply() Ido Schimmel
2024-08-27 15:09 ` Guillaume Nault
2024-08-27 11:18 ` [PATCH net-next 09/12] ipv6: sit: Unmask upper DSCP bits in ipip6_tunnel_xmit() Ido Schimmel
2024-08-27 15:17 ` Guillaume Nault
2024-08-27 11:18 ` [PATCH net-next 10/12] ipvlan: Unmask upper DSCP bits in ipvlan_process_v4_outbound() Ido Schimmel
2024-08-27 15:19 ` Guillaume Nault
2024-08-27 11:18 ` [PATCH net-next 11/12] vrf: Unmask upper DSCP bits in vrf_process_v4_outbound() Ido Schimmel
2024-08-27 15:22 ` Guillaume Nault
2024-08-27 11:18 ` [PATCH net-next 12/12] bpf: Unmask upper DSCP bits in __bpf_redirect_neigh_v4() Ido Schimmel
2024-08-27 13:47 ` Guillaume Nault [this message]
2024-08-27 15:45 ` [PATCH net-next 00/12] Unmask upper DSCP bits - part 2 Ido Schimmel
2024-08-28 12:09 ` Ido Schimmel
2024-08-29 11:54 ` Guillaume Nault
2024-08-29 14:52 ` Ido Schimmel
2024-08-29 15:10 ` Guillaume Nault
2024-08-29 11:30 ` Guillaume Nault
2024-08-29 14:43 ` Ido Schimmel
2024-08-29 15:08 ` 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=Zs3Y2ehPt3jEABwa@debian \
--to=gnault@redhat.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=idosch@nvidia.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).