public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Guillaume Nault <gnault@redhat.com>
To: Ido Schimmel <idosch@nvidia.com>
Cc: David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	netdev@vger.kernel.org, Simon Horman <horms@kernel.org>,
	Taehee Yoo <ap420073@gmail.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	Saeed Mahameed <saeedm@nvidia.com>,
	Leon Romanovsky <leon@kernel.org>,
	Tariq Toukan <tariqt@nvidia.com>, Mark Bloch <mbloch@nvidia.com>,
	Edward Cree <ecree.xilinx@gmail.com>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Harald Welte <laforge@gnumonks.org>,
	David Ahern <dsahern@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Daniel Borkmann <daniel@iogearbox.net>,
	John Fastabend <john.fastabend@gmail.com>,
	Stanislav Fomichev <sdf@fomichev.me>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	KP Singh <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Jozsef Kadlecsik <kadlec@netfilter.org>,
	Florian Westphal <fw@strlen.de>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
	Xin Long <lucien.xin@gmail.com>
Subject: Re: [PATCH net-next] ipv4: Convert ->flowi4_tos to dscp_t.
Date: Mon, 25 Aug 2025 13:29:21 +0200	[thread overview]
Message-ID: <aKxJEaSZ40d416sK@debian> (raw)
In-Reply-To: <aKrmOtDqr_46icM1@shredder>

On Sun, Aug 24, 2025 at 01:15:22PM +0300, Ido Schimmel wrote:
> On Thu, Aug 21, 2025 at 04:06:57PM +0200, Guillaume Nault wrote:
> > By the way, do you have an opinion about converting struct
> > ip_tunnel_key::tos? Do you think it'd be worth it, or just code churn?
> 
> I'm not sure if it's even possible. For example, on Tx, some drivers
> interpret ip_tunnel_key::tos being 1 as a sign that TOS should be
> inherited from the encapsulated packet. See the script in [1] and its
> output in [2] for example.

For this case, I was thinking of storing the "inherit" option in a
tunnel flag.

> On Rx, drivers in collect metadata ("external") mode set this field to
> the TOS from the outer header (which can have ECN bits set). The field
> can later be used to match on the outer TOS using flower's "enc_tos" key
> (for example). See the script in [3] and its output in [4].

This one would be a problem indeed.
I'll leave struct ip_tunnel_key alone.

> [1]
> #!/bin/bash
> 
> ip netns add ns1
> ip -n ns1 link set dev lo up
> ip -n ns1 address add 192.0.2.1/32 dev lo
> 
> ip -n ns1 link add name dummy1 up type dummy
> ip -n ns1 route add default dev dummy1
> 
> ip -n ns1 link add name ipip1 up type ipip external
> ip -n ns1 route add 192.0.2.0/24 dev ipip1 \
> 	encap ip id 1234 dst 198.51.100.1 src 192.0.2.1 tos 1
> 
> ip netns exec ns1 tcpdump -i dummy1 -Q out -n -vvv -c 1 dst host 198.51.100.1 &
> sleep 1
> ip netns exec ns1 ping -q -Q 4 -w 1 -c 1 192.0.2.2
> 
> ip netns del ns1
> 
> [2]
> # ./ipip_repo_tunkey.sh 
> dropped privs to tcpdump
> tcpdump: listening on dummy1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
> PING 192.0.2.2 (192.0.2.2) 56(84) bytes of data.
> 13:11:02.742405 IP (tos 0x4, ttl 64, id 64774, offset 0, flags [none], proto IPIP (4), length 104)
>     192.0.2.1 > 198.51.100.1: IP (tos 0x4, ttl 64, id 21845, offset 0, flags [DF], proto ICMP (1), length 84)
>     192.0.2.1 > 192.0.2.2: ICMP echo request, id 360, seq 1, length 64
> 1 packet captured
> 1 packet received by filter
> 0 packets dropped by kernel
> 
> --- 192.0.2.2 ping statistics ---
> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
> 
> [3]
> #!/bin/bash
> 
> for ns in ns1 ns2; do
> 	ip netns add $ns
> 	ip -n $ns link set dev lo up
> done
> 
> ip -n ns1 link add name eth0 type veth peer name eth0 netns ns2
> ip -n ns1 link set dev eth0 up
> ip -n ns2 link set dev eth0 up
> 
> ip -n ns1 address add 192.0.2.1/32 dev lo
> ip -n ns1 link add name vx0 up type \
> 	vxlan id 10010 local 192.0.2.1 remote 192.0.2.2 dstport 4789 tos 0xff
> ip -n ns1 address add 192.0.2.17/28 dev eth0
> ip -n ns1 route add default via 192.0.2.18
> 
> ip -n ns2 address add 192.0.2.2/32 dev lo
> ip -n ns2 link add name vx0 up type vxlan dstport 4789 external
> ip -n ns2 address add 192.0.2.18/28 dev eth0
> ip -n ns2 route add default via 192.0.2.17
> tc -n ns2 qdisc add dev vx0 clsact
> tc -n ns2 filter add dev vx0 ingress pref 1 proto all \
> 	flower enc_src_ip 192.0.2.1 enc_dst_ip 192.0.2.2 enc_tos 0xfe \
> 	action drop
> 
> ip netns exec ns1 mausezahn vx0 -a own -b 00:11:22:33:44:55 \
> 	-A 198.51.100.1 -B 198.51.100.2 -t ip tos=0xff -c 1 -q
> sleep 1
> tc -n ns2 -s filter show dev vx0 ingress
> 
> for ns in ns1 ns2; do
> 	ip netns del $ns
> done
> 
> [4]
> # ./vxlan_repo_tunkey.sh 
> filter protocol all pref 1 flower chain 0 
> filter protocol all pref 1 flower chain 0 handle 0x1 
>   enc_dst_ip 192.0.2.2
>   enc_src_ip 192.0.2.1
>   enc_tos 254
>   not_in_hw
>         action order 1: gact action drop
>          random type none pass val 0
>          index 1 ref 1 bind 1 installed 1 sec used 1 sec firstused 1 sec
>         Action statistics:
>         Sent 20 bytes 1 pkt (dropped 1, overlimits 0 requeues 0) 
>         backlog 0b 0p requeues 0
> 


      reply	other threads:[~2025-08-25 11:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-20 23:32 [PATCH net-next] ipv4: Convert ->flowi4_tos to dscp_t Guillaume Nault
2025-08-21  6:56 ` Ido Schimmel
2025-08-21 14:06   ` Guillaume Nault
2025-08-24 10:15     ` Ido Schimmel
2025-08-25 11:29       ` Guillaume Nault [this message]

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=aKxJEaSZ40d416sK@debian \
    --to=gnault@redhat.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrii@kernel.org \
    --cc=ap420073@gmail.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=ecree.xilinx@gmail.com \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=haoluo@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kadlec@netfilter.org \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=laforge@gnumonks.org \
    --cc=leon@kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=martin.lau@linux.dev \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mbloch@nvidia.com \
    --cc=mhiramat@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    --cc=rostedt@goodmis.org \
    --cc=saeedm@nvidia.com \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=tariqt@nvidia.com \
    --cc=yonghong.song@linux.dev \
    /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