| Message ID | 20240829065459.2273106-1-idosch@nvidia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Unmask upper DSCP bits - part 2 | expand |
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>
Hello: This series was applied to netdev/net-next.git (main) by David S. Miller <davem@davemloft.net>: On Thu, 29 Aug 2024 09:54:47 +0300 you 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. > > [...] Here is the summary with links: - [net-next,v2,01/12] ipv4: Unmask upper DSCP bits in RTM_GETROUTE output route lookup https://git.kernel.org/netdev/net-next/c/47afa284b96c - [net-next,v2,02/12] ipv4: Unmask upper DSCP bits in ip_route_output_key_hash() https://git.kernel.org/netdev/net-next/c/a63cef46adcb - [net-next,v2,03/12] ipv4: icmp: Unmask upper DSCP bits in icmp_route_lookup() https://git.kernel.org/netdev/net-next/c/4805646c42e5 - [net-next,v2,04/12] ipv4: Unmask upper DSCP bits in ip_sock_rt_tos() https://git.kernel.org/netdev/net-next/c/ff95cb5e521b - [net-next,v2,05/12] ipv4: Unmask upper DSCP bits in get_rttos() https://git.kernel.org/netdev/net-next/c/356d054a4967 - [net-next,v2,06/12] ipv4: Unmask upper DSCP bits when building flow key https://git.kernel.org/netdev/net-next/c/f6c89e95555a - [net-next,v2,07/12] xfrm: Unmask upper DSCP bits in xfrm_get_tos() https://git.kernel.org/netdev/net-next/c/b261b2c6c18b - [net-next,v2,08/12] ipv4: Unmask upper DSCP bits in ip_send_unicast_reply() https://git.kernel.org/netdev/net-next/c/13f6538de2b8 - [net-next,v2,09/12] ipv6: sit: Unmask upper DSCP bits in ipip6_tunnel_xmit() https://git.kernel.org/netdev/net-next/c/6a59526628ad - [net-next,v2,10/12] ipvlan: Unmask upper DSCP bits in ipvlan_process_v4_outbound() https://git.kernel.org/netdev/net-next/c/939cd1abf080 - [net-next,v2,11/12] vrf: Unmask upper DSCP bits in vrf_process_v4_outbound() https://git.kernel.org/netdev/net-next/c/c5d8ffe29cf2 - [net-next,v2,12/12] bpf: Unmask upper DSCP bits in __bpf_redirect_neigh_v4() https://git.kernel.org/netdev/net-next/c/50033400fc3a You are awesome, thank you!
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(-)