All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@kernel.org>
To: Ido Schimmel <idosch@nvidia.com>, netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, gnault@redhat.com, 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 v2 00/12] Unmask upper DSCP bits - part 2
Date: Thu, 29 Aug 2024 18:55:23 -0700	[thread overview]
Message-ID: <a9603de2-3ff3-40aa-9bb1-2a02c2ed3e5e@kernel.org> (raw)
In-Reply-To: <20240829065459.2273106-1-idosch@nvidia.com>

On 8/28/24 12:54 AM, 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
> 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.
> 
> Patches #1-#3 unmask the upper DSCP bits in the various places that
> invoke the core output route lookup functions directly.
> 
> Patches #4-#6 do the same in three helpers that are widely used in the
> output path to initialize the TOS field in the IPv4 flow key.
> 
> The rest of the patches continue to unmask these bits in call sites that
> invoke the following wrappers around the core lookup functions:
> 
> Patch #7 - __ip_route_output_key()
> Patches #8-#12 - ip_route_output_flow()
> 
> The next patchset will handle the callers of ip_route_output_ports() and
> ip_route_output_key().
> 
> No functional changes are expected as commit 1fa3314c14c6 ("ipv4:
> Centralize TOS matching") moved the masking of the upper DSCP bits to
> the core where 'flowi4_tos' is matched against the TOS selector.
> 
> Changes since v1 [1]:
> 
> * Remove IPTOS_RT_MASK in patch #7 instead of in patch #6
> 
> [1] https://lore.kernel.org/netdev/20240827111813.2115285-1-idosch@nvidia.com/
> 
> Ido Schimmel (12):
>   ipv4: Unmask upper DSCP bits in RTM_GETROUTE output route lookup
>   ipv4: Unmask upper DSCP bits in ip_route_output_key_hash()
>   ipv4: icmp: Unmask upper DSCP bits in icmp_route_lookup()
>   ipv4: Unmask upper DSCP bits in ip_sock_rt_tos()
>   ipv4: Unmask upper DSCP bits in get_rttos()
>   ipv4: Unmask upper DSCP bits when building flow key
>   xfrm: Unmask upper DSCP bits in xfrm_get_tos()
>   ipv4: Unmask upper DSCP bits in ip_send_unicast_reply()
>   ipv6: sit: Unmask upper DSCP bits in ipip6_tunnel_xmit()
>   ipvlan: Unmask upper DSCP bits in ipvlan_process_v4_outbound()
>   vrf: Unmask upper DSCP bits in vrf_process_v4_outbound()
>   bpf: Unmask upper DSCP bits in __bpf_redirect_neigh_v4()
> 
>  drivers/net/ipvlan/ipvlan_core.c | 4 +++-
>  drivers/net/vrf.c                | 3 ++-
>  include/net/ip.h                 | 5 ++++-
>  include/net/route.h              | 5 ++---
>  net/core/filter.c                | 2 +-
>  net/ipv4/icmp.c                  | 3 ++-
>  net/ipv4/ip_output.c             | 3 ++-
>  net/ipv4/route.c                 | 8 ++++----
>  net/ipv6/sit.c                   | 5 +++--
>  net/xfrm/xfrm_policy.c           | 3 ++-
>  10 files changed, 25 insertions(+), 16 deletions(-)
> 

For the set:

Reviewed-by: David Ahern <dsahern@kernel.org>


  parent reply	other threads:[~2024-08-30  1:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-29  6:54 [PATCH net-next v2 00/12] Unmask upper DSCP bits - part 2 Ido Schimmel
2024-08-29  6:54 ` [PATCH net-next v2 01/12] ipv4: Unmask upper DSCP bits in RTM_GETROUTE output route lookup Ido Schimmel
2024-08-29  6:54 ` [PATCH net-next v2 02/12] ipv4: Unmask upper DSCP bits in ip_route_output_key_hash() Ido Schimmel
2024-08-29  6:54 ` [PATCH net-next v2 03/12] ipv4: icmp: Unmask upper DSCP bits in icmp_route_lookup() Ido Schimmel
2024-08-29  6:54 ` [PATCH net-next v2 04/12] ipv4: Unmask upper DSCP bits in ip_sock_rt_tos() Ido Schimmel
2024-08-29  6:54 ` [PATCH net-next v2 05/12] ipv4: Unmask upper DSCP bits in get_rttos() Ido Schimmel
2024-08-29  6:54 ` [PATCH net-next v2 06/12] ipv4: Unmask upper DSCP bits when building flow key Ido Schimmel
2024-08-29 10:47   ` Guillaume Nault
2024-08-29  6:54 ` [PATCH net-next v2 07/12] xfrm: Unmask upper DSCP bits in xfrm_get_tos() Ido Schimmel
2024-08-29 10:52   ` Guillaume Nault
2024-08-29  6:54 ` [PATCH net-next v2 08/12] ipv4: Unmask upper DSCP bits in ip_send_unicast_reply() Ido Schimmel
2024-08-29  6:54 ` [PATCH net-next v2 09/12] ipv6: sit: Unmask upper DSCP bits in ipip6_tunnel_xmit() Ido Schimmel
2024-08-29  6:54 ` [PATCH net-next v2 10/12] ipvlan: Unmask upper DSCP bits in ipvlan_process_v4_outbound() Ido Schimmel
2024-08-29  6:54 ` [PATCH net-next v2 11/12] vrf: Unmask upper DSCP bits in vrf_process_v4_outbound() Ido Schimmel
2024-08-29  6:54 ` [PATCH net-next v2 12/12] bpf: Unmask upper DSCP bits in __bpf_redirect_neigh_v4() Ido Schimmel
2024-08-29 11:02   ` Guillaume Nault
2024-08-30  1:55 ` David Ahern [this message]
2024-08-31 16:50 ` [PATCH net-next v2 00/12] Unmask upper DSCP bits - part 2 patchwork-bot+netdevbpf

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=a9603de2-3ff3-40aa-9bb1-2a02c2ed3e5e@kernel.org \
    --to=dsahern@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gnault@redhat.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 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.