All of lore.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 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.