From: Guillaume Nault <gnault@redhat.com>
To: Russell Strong <russell@strong.id.au>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next] net: DSCP in IPv4 routing v2
Date: Mon, 23 Nov 2020 23:55:05 +0100 [thread overview]
Message-ID: <20201123225505.GA21345@linux.home> (raw)
In-Reply-To: <20201121182250.661bfee5@192-168-1-16.tpgi.com.au>
On Sat, Nov 21, 2020 at 06:24:46PM +1000, Russell Strong wrote:
> From 2f27f92d5a6f4dd69ac4af32cdb51ba8d2083606 Mon Sep 17 00:00:00 2001
> From: Russell Strong <russell@strong.id.au>
> Date: Sat, 21 Nov 2020 18:12:43 +1000
> Subject: [PATCH] DSCP in IPv4 routing v2
>
> This patch allows the use of DSCP values in routing
Thanks. There are some problems with this patch though.
About the email:
* Why did you duplicate email headers in the body?
* For the subject, please put the "v2" in the "[PATCH ... ]" part.
* You're modifying many files, but haven't Cc-ed any of their authors
or maintainers.
* The patch content is corrupted.
> Use of TOS macros are replaced with DSCP macros
> where the change does not change the user space API
> with one exception:
>
> net/ipv4/fib_rules.c has been changed to accept a
> wider range of values ( dscp values ). Previously
> this would have returned an error.
Have you really verified that replacing each of these RT_TOS calls had
no unwanted side effect?
RT_TOS didn't clear the second lowest bit, while the new IP_DSCP does.
Therefore, there's no guarantee that such a blanket replacement isn't
going to change existing behaviours. Replacements have to be done
step by step and accompanied by an explanation of why they're safe.
BTW, I think there are some problems with RT_TOS that need to be fixed
separately first.
For example some of the ip6_make_flowinfo() calls can probably
erroneously mark some packets with ECT(0). Instead of masking the
problem in this patch, I think it'd be better to have an explicit fix
that'd mask the ECN bits in ip6_make_flowinfo() and drop the buggy
RT_TOS() in the callers.
Another example is inet_rtm_getroute(). It calls
ip_route_output_key_hash_rcu() without masking the tos field first.
Therefore it can return a different route than what the routing code
would actually use. Like for the ip6_make_flowinfo() case, it might
be better to stop relying on the callers to mask ECN bits and do that
in ip_route_output_key_hash_rcu() instead.
I'll verify that these two problems can actually happen in practice
and will send patches if necessary.
> iproute2 already supports setting dscp values through
> ip route add dsfield <dscp value> lookup ......
>
> Signed-off-by: Russell Strong <russell@strong.id.au>
> ---
> .../ethernet/mellanox/mlx5/core/en/tc_tun.c | 2 +-
> drivers/net/geneve.c | 4 ++--
> drivers/net/ipvlan/ipvlan_core.c | 2 +-
> drivers/net/ppp/pptp.c | 2 +-
> drivers/net/vrf.c | 2 +-
> drivers/net/vxlan.c | 4 ++--
> include/net/ip.h | 2 +-
> include/net/route.h | 6 ++----
> include/uapi/linux/ip.h | 2 ++
> net/bridge/br_netfilter_hooks.c | 2 +-
> net/core/filter.c | 4 ++--
> net/core/lwt_bpf.c | 2 +-
> net/ipv4/fib_frontend.c | 2 +-
> net/ipv4/fib_rules.c | 2 +-
> net/ipv4/icmp.c | 6 +++---
> net/ipv4/ip_gre.c | 2 +-
> net/ipv4/ip_output.c | 2 +-
> net/ipv4/ip_tunnel.c | 6 +++---
> net/ipv4/ipmr.c | 6 +++---
> net/ipv4/netfilter.c | 2 +-
> net/ipv4/netfilter/ipt_rpfilter.c | 2 +-
> net/ipv4/netfilter/nf_dup_ipv4.c | 2 +-
> net/ipv4/route.c | 20 +++++++++----------
> net/ipv6/ip6_output.c | 2 +-
> net/ipv6/ip6_tunnel.c | 4 ++--
> net/ipv6/sit.c | 4 ++--
> net/xfrm/xfrm_policy.c | 2 +-
> 27 files changed, 49 insertions(+), 49 deletions(-)
next prev parent reply other threads:[~2020-11-23 22:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-21 8:24 [PATCH net-next] net: DSCP in IPv4 routing v2 Russell Strong
2020-11-23 22:55 ` Guillaume Nault [this message]
2020-11-24 2:41 ` Russell Strong
2020-11-24 15:22 ` Guillaume Nault
2021-12-14 15:47 ` Matthias May
2021-12-14 15:58 ` Matthias May
2021-12-14 19:24 ` Guillaume Nault
2021-12-15 12:37 ` Matthias May
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=20201123225505.GA21345@linux.home \
--to=gnault@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=russell@strong.id.au \
/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).