On Mon, 28 Sep 2026 19:34:21 -0400 Willem de Bruijn wrote:
> If 1/5 fixes a bug that is reachable today (does it?) then it needs to
> go to net on its own.
Before this series, it is reachable when the tag is already in the frame,
for example a stacked VLAN device or an OVS QinQ path. I reproduced it
with the following script:
ip netns add g1; ip netns add g2
ip link add v0 type veth peer name v1
ip link set v0 netns g1; ip link set v1 netns g2
for n in g1 g2; do
r=v0; [ $n = g2 ] && r=v1
ip -n $n link add link $r name vlan200 type vlan id 200
ip -n $n link add link vlan200 name vlan100 type vlan id 100
for d in $r vlan200 vlan100; do
ip -n $n link set $d gso_max_size 524280
done
ip -n $n link set $r up; ip -n $n link set vlan200 up
ip -n $n link set vlan100 up
done
ip -n g1 addr add 2001:db8::1/64 dev vlan100
ip -n g2 addr add 2001:db8::2/64 dev vlan100
ip netns exec g2 iperf3 -s -D
ip -n g1 link set v0 gso_ipv4_max_size 65536
ip netns exec g1 iperf3 -c 2001:db8::2 -t 6
ip -n g1 link set v0 gso_ipv4_max_size 524280
ip netns exec g1 iperf3 -c 2001:db8::2 -t 6
With gso_ipv4_max_size = 65536, iperf3 reports 442 Mbps; with 524280, it
reports 39.4 Gbps. So gso_ipv4_max_size clearly affects this IPv6 flow.
I will keep 1/5 in the series and drop the Fixes tag, as Paolo suggests.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
