* [PATCH net v2] net: mask NETIF_F_IPV6_CSUM flag on irregular packet header size
@ 2025-08-07 13:41 Jakub Ramaseuski
2025-08-07 20:55 ` Willem de Bruijn
0 siblings, 1 reply; 4+ messages in thread
From: Jakub Ramaseuski @ 2025-08-07 13:41 UTC (permalink / raw)
To: netdev
Cc: kuba, horms, pabeni, Jakub Ramaseuski, Tianhao Zhao,
Michal Schmidt, Willem de Bruijn
On any driver that advertises NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM but
not the superseding NETIF_F_HW_CSUM (e.g., ice/bnxt_en), the kernel
incorrectly attempts GSO on IPv6 packets with extension headers.
Because the NETIF_F_IPV6_CSUM feature is incompatible with these
headers, the failure results in a `skb_warn_bad_offload` warning and
a collapse of throughput, as observed with GREoIPv6 traffic.
Mask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4
in gso_features_check if the IPv6 header contains extension headers.
The exception is a BIG TCP extension, which, as stated in commit
68e068cabd2c6c53 (net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets):
"The feature is only enabled on devices that support BIG TCP TSO.
The header is only present for PF_PACKET taps like tcpdump,
and not transmitted by physical devices."
kernel log output (truncated):
WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140
...
Call Trace:
<TASK>
skb_checksum_help+0x12a/0x1f0
? netif_skb_features+0xc1/0x2e0
validate_xmit_skb+0x1a3/0x2d0
validate_xmit_skb_list+0x4f/0x80
sch_direct_xmit+0x1a2/0x380
__dev_xmit_skb+0x242/0x670
__dev_queue_xmit+0x3fc/0x7f0
? srso_alias_return_thunk+0x5/0xfbef5
? ip6_rt_copy_init+0xf0/0x290
? srso_alias_return_thunk+0x5/0xfbef5
? selinux_ip_postroute+0x1c5/0x420
? srso_alias_return_thunk+0x5/0xfbef5
ip6_finish_output2+0x25e/0x5d0
? srso_alias_return_thunk+0x5/0xfbef5
? nf_hook_slow+0x47/0xf0
? srso_alias_return_thunk+0x5/0xfbef5
ip6_finish_output+0x1fc/0x3f0
ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel]
? srso_alias_return_thunk+0x5/0xfbef5
ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre]
dev_hard_start_xmit+0x63/0x1c0
__dev_queue_xmit+0x6d0/0x7f0
? srso_alias_return_thunk+0x5/0xfbef5
? chacha_block_generic+0x72/0xd0
? srso_alias_return_thunk+0x5/0xfbef5
? selinux_ip_postroute+0x1c5/0x420
ip6_finish_output2+0x214/0x5d0
? srso_alias_return_thunk+0x5/0xfbef5
? nf_hook_slow+0x47/0xf0
ip6_finish_output+0x1fc/0x3f0
ip6_xmit+0x2ca/0x6f0
? __pfx_dst_output+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? nf_hook_slow+0x47/0xf0
ip6_finish_output+0x1fc/0x3f0
ip6_xmit+0x2ca/0x6f0
? __pfx_dst_output+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? __sk_dst_check+0x41/0xc0
? srso_alias_return_thunk+0x5/0xfbef5
? inet6_csk_route_socket+0x12e/0x200
inet6_csk_xmit+0xeb/0x150
__tcp_transmit_skb+0x555/0xa80
tcp_write_xmit+0x32a/0xe90
? srso_alias_return_thunk+0x5/0xfbef5
? skb_do_copy_data_nocache+0xc9/0x150
tcp_sendmsg_locked+0x437/0x1110
? srso_alias_return_thunk+0x5/0xfbef5
tcp_sendmsg+0x2f/0x50
...
skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e
skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00
skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00
skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00
skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00
skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00
skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9
skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01
skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a
Fixes: 04c20a9356f283da ("net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension")
Reported-by: Tianhao Zhao <tizhao@redhat.com>
Suggested-by: Michal Schmidt <mschmidt@redhat.com>
Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Signed-off-by: Jakub Ramaseuski <jramaseu@redhat.com>
---
---
net/core/dev.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index b28ce68830b2b..1d8a4d1da911e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3778,6 +3778,18 @@ static netdev_features_t gso_features_check(const struct sk_buff *skb,
if (!(iph->frag_off & htons(IP_DF)))
features &= ~NETIF_F_TSO_MANGLEID;
}
+
+ /* NETIF_F_IPV6_CSUM does not support IPv6 extension headers,
+ * so neither does TSO that depends on it.
+ */
+ if (features & NETIF_F_IPV6_CSUM &&
+ (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6 ||
+ (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4 &&
+ vlan_get_protocol(skb) == htons(ETH_P_IPV6))) &&
+ skb_transport_header_was_set(skb) &&
+ skb_network_header_len(skb) != sizeof(struct ipv6hdr) &&
+ !ipv6_has_hopopt_jumbo(skb))
+ features &= ~(NETIF_F_IPV6_CSUM | NETIF_F_TSO6 | NETIF_F_GSO_UDP_L4);
return features;
}
--
2.50.1
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH net v2] net: mask NETIF_F_IPV6_CSUM flag on irregular packet header size
2025-08-07 13:41 [PATCH net v2] net: mask NETIF_F_IPV6_CSUM flag on irregular packet header size Jakub Ramaseuski
@ 2025-08-07 20:55 ` Willem de Bruijn
2025-08-11 15:33 ` Jakub Ramaseuski
0 siblings, 1 reply; 4+ messages in thread
From: Willem de Bruijn @ 2025-08-07 20:55 UTC (permalink / raw)
To: Jakub Ramaseuski, netdev
Cc: kuba, horms, pabeni, Jakub Ramaseuski, Tianhao Zhao,
Michal Schmidt, Willem de Bruijn
Jakub Ramaseuski wrote:
> On any driver that advertises NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM but
> not the superseding NETIF_F_HW_CSUM (e.g., ice/bnxt_en), the kernel
Minor point (repeated), the two are generally not combined. See also
the following in netdev_fix_features:
/* Fix illegal checksum combinations */
if ((features & NETIF_F_HW_CSUM) &&
(features & (NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))) {
netdev_warn(dev, "mixed HW and IP checksum settings.\n");
features &= ~(NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM);
}
> incorrectly attempts GSO on IPv6 packets with extension headers.
This is not entirely correct. Hardware TSO/USO cannot be relied to
handle these packets, so GSO is correctly used.
But the GSO stack must not program checksum offload. Instead, compute
the checksum in software during segmentation.
This is tested from skb_segment with can_checksum_protocol. Which
could be amended for this IPv6 with extension header case directly.
But removing NETIF_F_IPV6_CSUM in gso_check_features will have the
same effect.
> Because the NETIF_F_IPV6_CSUM feature is incompatible with these
> headers, the failure results in a `skb_warn_bad_offload` warning and
> a collapse of throughput, as observed with GREoIPv6 traffic.
>
> Mask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4
> in gso_features_check if the IPv6 header contains extension headers.
>
> The exception is a BIG TCP extension, which, as stated in commit
> 68e068cabd2c6c53 (net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets):
> "The feature is only enabled on devices that support BIG TCP TSO.
> The header is only present for PF_PACKET taps like tcpdump,
> and not transmitted by physical devices."
>
> kernel log output (truncated):
> WARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140
> ...
> Call Trace:
> <TASK>
> skb_checksum_help+0x12a/0x1f0
> ? netif_skb_features+0xc1/0x2e0
> validate_xmit_skb+0x1a3/0x2d0
> validate_xmit_skb_list+0x4f/0x80
> sch_direct_xmit+0x1a2/0x380
> __dev_xmit_skb+0x242/0x670
> __dev_queue_xmit+0x3fc/0x7f0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? ip6_rt_copy_init+0xf0/0x290
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? selinux_ip_postroute+0x1c5/0x420
> ? srso_alias_return_thunk+0x5/0xfbef5
> ip6_finish_output2+0x25e/0x5d0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? nf_hook_slow+0x47/0xf0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ip6_finish_output+0x1fc/0x3f0
> ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel]
> ? srso_alias_return_thunk+0x5/0xfbef5
> ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre]
> dev_hard_start_xmit+0x63/0x1c0
> __dev_queue_xmit+0x6d0/0x7f0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? chacha_block_generic+0x72/0xd0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? selinux_ip_postroute+0x1c5/0x420
> ip6_finish_output2+0x214/0x5d0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? nf_hook_slow+0x47/0xf0
> ip6_finish_output+0x1fc/0x3f0
> ip6_xmit+0x2ca/0x6f0
> ? __pfx_dst_output+0x10/0x10
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? nf_hook_slow+0x47/0xf0
> ip6_finish_output+0x1fc/0x3f0
> ip6_xmit+0x2ca/0x6f0
> ? __pfx_dst_output+0x10/0x10
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __sk_dst_check+0x41/0xc0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? inet6_csk_route_socket+0x12e/0x200
> inet6_csk_xmit+0xeb/0x150
> __tcp_transmit_skb+0x555/0xa80
> tcp_write_xmit+0x32a/0xe90
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? skb_do_copy_data_nocache+0xc9/0x150
> tcp_sendmsg_locked+0x437/0x1110
> ? srso_alias_return_thunk+0x5/0xfbef5
> tcp_sendmsg+0x2f/0x50
> ...
> skb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e
> skb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00
> skb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00
> skb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00
> skb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00
> skb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00
> skb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9
> skb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01
> skb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a
>
> Fixes: 04c20a9356f283da ("net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension")
As said, I don't think this introduced the bug.
If you go to 04c20a9356f283da~1, does this traffic work?
> Reported-by: Tianhao Zhao <tizhao@redhat.com>
> Suggested-by: Michal Schmidt <mschmidt@redhat.com>
> Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Signed-off-by: Jakub Ramaseuski <jramaseu@redhat.com>
> ---
> ---
> net/core/dev.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index b28ce68830b2b..1d8a4d1da911e 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3778,6 +3778,18 @@ static netdev_features_t gso_features_check(const struct sk_buff *skb,
> if (!(iph->frag_off & htons(IP_DF)))
> features &= ~NETIF_F_TSO_MANGLEID;
> }
> +
> + /* NETIF_F_IPV6_CSUM does not support IPv6 extension headers,
> + * so neither does TSO that depends on it.
> + */
> + if (features & NETIF_F_IPV6_CSUM &&
> + (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6 ||
> + (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4 &&
> + vlan_get_protocol(skb) == htons(ETH_P_IPV6))) &&
> + skb_transport_header_was_set(skb) &&
> + skb_network_header_len(skb) != sizeof(struct ipv6hdr) &&
> + !ipv6_has_hopopt_jumbo(skb))
> + features &= ~(NETIF_F_IPV6_CSUM | NETIF_F_TSO6 | NETIF_F_GSO_UDP_L4);
>
> return features;
> }
> --
> 2.50.1
>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Re: [PATCH net v2] net: mask NETIF_F_IPV6_CSUM flag on irregular packet header size
2025-08-07 20:55 ` Willem de Bruijn
@ 2025-08-11 15:33 ` Jakub Ramaseuski
2025-08-11 17:58 ` Willem de Bruijn
0 siblings, 1 reply; 4+ messages in thread
From: Jakub Ramaseuski @ 2025-08-11 15:33 UTC (permalink / raw)
To: willemdebruijn.kernel
Cc: horms, jramaseu, kuba, mschmidt, netdev, pabeni, tizhao
Thanks for the feedback, Willem de Bruijn asked:
> If you go to 04c20a9356f283da~1, does this traffic work?
That is a good question, prior to this conversation I checked the results
on 6.11.0-27 (which is prior to that commit), with reverting 04c20a9356f283da
and 68e068cabd2c6c53 on v6.16, but not on 04c20a9356f283da~1. Here are the
iperf3 results for:
- git checkout 04c20a9356f283da~1
Connecting to host 2023::11, port 5201
[ 5] local 2023::12 port 47768 connected to 2023::11 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 1.88 GBytes 16.2 Gbits/sec 79 2.14 MBytes
[ 5] 1.00-2.00 sec 1.96 GBytes 16.8 Gbits/sec 11 1.89 MBytes
[ 5] 2.00-3.00 sec 1.96 GBytes 16.8 Gbits/sec 0 2.53 MBytes
[ 5] 3.00-4.00 sec 1.96 GBytes 16.9 Gbits/sec 1 2.35 MBytes
[ 5] 4.00-5.00 sec 1.95 GBytes 16.7 Gbits/sec 5 2.13 MBytes
[ 5] 5.00-6.00 sec 1.97 GBytes 16.9 Gbits/sec 0 2.72 MBytes
[ 5] 6.00-7.00 sec 1.96 GBytes 16.8 Gbits/sec 6 2.49 MBytes
[ 5] 7.00-8.00 sec 1.99 GBytes 17.1 Gbits/sec 2 2.26 MBytes
[ 5] 8.00-9.00 sec 1.97 GBytes 16.9 Gbits/sec 3 2.06 MBytes
[ 5] 9.00-10.00 sec 1.98 GBytes 17.0 Gbits/sec 0 2.66 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 19.6 GBytes 16.8 Gbits/sec 107 sender
[ 5] 0.00-10.00 sec 19.6 GBytes 16.8 Gbits/sec receiver
- git checkout 04c20a9356f283da
Connecting to host 2023::11, port 5201
[ 5] local 2023::12 port 44762 connected to 2023::11 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec 0 13.4 KBytes
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 3 2.69 KBytes
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 8 5.38 KBytes
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 5 2.69 KBytes
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 2.69 KBytes
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 2 5.38 KBytes
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 6.72 KBytes
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 6 5.38 KBytes
[ 5] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 2 5.38 KBytes
[ 5] 9.00-11.29 sec 0.00 Bytes 0.00 bits/sec 2 5.38 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-11.29 sec 128 KBytes 92.9 Kbits/sec 28 sender
[ 5] 0.00-11.46 sec 92.7 KBytes 66.3 Kbits/sec receiver
- git checkout v6.16 + this patch
Connecting to host 2023::11, port 5201
[ 5] local 2023::12 port 60108 connected to 2023::11 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 807 MBytes 6.77 Gbits/sec 0 1.74 MBytes
[ 5] 1.00-2.00 sec 852 MBytes 7.14 Gbits/sec 0 1.74 MBytes
[ 5] 2.00-3.00 sec 851 MBytes 7.14 Gbits/sec 0 1.83 MBytes
[ 5] 3.00-4.00 sec 837 MBytes 7.02 Gbits/sec 0 1.92 MBytes
[ 5] 4.00-5.00 sec 846 MBytes 7.10 Gbits/sec 0 1.92 MBytes
[ 5] 5.00-6.00 sec 852 MBytes 7.14 Gbits/sec 0 1.92 MBytes
[ 5] 6.00-7.00 sec 849 MBytes 7.12 Gbits/sec 0 1.92 MBytes
[ 5] 7.00-8.00 sec 849 MBytes 7.12 Gbits/sec 0 1.92 MBytes
[ 5] 8.00-9.00 sec 798 MBytes 6.69 Gbits/sec 0 1.92 MBytes
[ 5] 9.00-10.00 sec 805 MBytes 6.75 Gbits/sec 0 1.92 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 8.15 GBytes 7.00 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 8.15 GBytes 7.00 Gbits/sec receiver
Where ip addr shows:
1: lo: <LOOPBACK,UP,LOWER_UP> ...
...
...
8: enp65s0f0np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
...
inet6 2011::12/64 scope global
valid_lft forever preferred_lft forever
...
12: ip6tnl0@NONE: <NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1000
link/tunnel6 :: brd :: permaddr 1257:d9c1:e829::
inet6 fe80::1057:d9ff:fec1:e829/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
13: ip6gre0@NONE: <NOARP,UP,LOWER_UP> mtu 1448 qdisc noqueue state UNKNOWN group default qlen 1000
link/gre6 :: brd :: permaddr cab1:6316:aa70::
inet6 fe80::c8b1:63ff:fe16:aa70/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
14: gre1@enp65s0f0np0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1448 qdisc noqueue state UNKNOWN group default qlen 1000
link/gre6 2011::12 peer 2011::11 permaddr ded7:5b97:9098::
...
inet6 2023::12/64 scope global
valid_lft forever preferred_lft forever
...
with 2023::11 being the other side of that GRE tunnel
and ethtool -i enp65s0f0np0 shows that NIC uses ice driver.
Even though this commit fixes 04c20a9356f283da, the throughput is still
50 % of its original rate. This leads me to the following question: since
the original commit affects throughput on NICs with the bnxt_en or ice
drivers, is it possible that in
net/core/dev.c: skb_csum_hwoffload_help()
the check
...
if (vlan_get_protocol(skb) == htons(ETH_P_IPV6) &&
skb_network_header_len(skb) != sizeof(struct ipv6hdr) &&
!ipv6_has_hopopt_jumbo(skb))
goto sw_checksum;
...
should have another condition or flag before jumping to sw_checksum?
Any insights would be greatly appreciated.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Re: [PATCH net v2] net: mask NETIF_F_IPV6_CSUM flag on irregular packet header size
2025-08-11 15:33 ` Jakub Ramaseuski
@ 2025-08-11 17:58 ` Willem de Bruijn
0 siblings, 0 replies; 4+ messages in thread
From: Willem de Bruijn @ 2025-08-11 17:58 UTC (permalink / raw)
To: Jakub Ramaseuski, willemdebruijn.kernel
Cc: horms, jramaseu, kuba, mschmidt, netdev, pabeni, tizhao
Jakub Ramaseuski wrote:
> Thanks for the feedback, Willem de Bruijn asked:
> > If you go to 04c20a9356f283da~1, does this traffic work?
> That is a good question, prior to this conversation I checked the results
> on 6.11.0-27 (which is prior to that commit), with reverting 04c20a9356f283da
> and 68e068cabd2c6c53 on v6.16, but not on 04c20a9356f283da~1. Here are the
> iperf3 results for:
> - git checkout 04c20a9356f283da~1
> Connecting to host 2023::11, port 5201
> [ 5] local 2023::12 port 47768 connected to 2023::11 port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 1.88 GBytes 16.2 Gbits/sec 79 2.14 MBytes
> [ 5] 1.00-2.00 sec 1.96 GBytes 16.8 Gbits/sec 11 1.89 MBytes
> [ 5] 2.00-3.00 sec 1.96 GBytes 16.8 Gbits/sec 0 2.53 MBytes
> [ 5] 3.00-4.00 sec 1.96 GBytes 16.9 Gbits/sec 1 2.35 MBytes
> [ 5] 4.00-5.00 sec 1.95 GBytes 16.7 Gbits/sec 5 2.13 MBytes
> [ 5] 5.00-6.00 sec 1.97 GBytes 16.9 Gbits/sec 0 2.72 MBytes
> [ 5] 6.00-7.00 sec 1.96 GBytes 16.8 Gbits/sec 6 2.49 MBytes
> [ 5] 7.00-8.00 sec 1.99 GBytes 17.1 Gbits/sec 2 2.26 MBytes
> [ 5] 8.00-9.00 sec 1.97 GBytes 16.9 Gbits/sec 3 2.06 MBytes
> [ 5] 9.00-10.00 sec 1.98 GBytes 17.0 Gbits/sec 0 2.66 MBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 19.6 GBytes 16.8 Gbits/sec 107 sender
> [ 5] 0.00-10.00 sec 19.6 GBytes 16.8 Gbits/sec receiver
>
> - git checkout 04c20a9356f283da
> Connecting to host 2023::11, port 5201
> [ 5] local 2023::12 port 44762 connected to 2023::11 port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec 0 13.4 KBytes
> [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 3 2.69 KBytes
> [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 8 5.38 KBytes
> [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 5 2.69 KBytes
> [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 2.69 KBytes
> [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 2 5.38 KBytes
> [ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 6.72 KBytes
> [ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 6 5.38 KBytes
> [ 5] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 2 5.38 KBytes
> [ 5] 9.00-11.29 sec 0.00 Bytes 0.00 bits/sec 2 5.38 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-11.29 sec 128 KBytes 92.9 Kbits/sec 28 sender
> [ 5] 0.00-11.46 sec 92.7 KBytes 66.3 Kbits/sec receiver
>
> - git checkout v6.16 + this patch
> Connecting to host 2023::11, port 5201
> [ 5] local 2023::12 port 60108 connected to 2023::11 port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 807 MBytes 6.77 Gbits/sec 0 1.74 MBytes
> [ 5] 1.00-2.00 sec 852 MBytes 7.14 Gbits/sec 0 1.74 MBytes
> [ 5] 2.00-3.00 sec 851 MBytes 7.14 Gbits/sec 0 1.83 MBytes
> [ 5] 3.00-4.00 sec 837 MBytes 7.02 Gbits/sec 0 1.92 MBytes
> [ 5] 4.00-5.00 sec 846 MBytes 7.10 Gbits/sec 0 1.92 MBytes
> [ 5] 5.00-6.00 sec 852 MBytes 7.14 Gbits/sec 0 1.92 MBytes
> [ 5] 6.00-7.00 sec 849 MBytes 7.12 Gbits/sec 0 1.92 MBytes
> [ 5] 7.00-8.00 sec 849 MBytes 7.12 Gbits/sec 0 1.92 MBytes
> [ 5] 8.00-9.00 sec 798 MBytes 6.69 Gbits/sec 0 1.92 MBytes
> [ 5] 9.00-10.00 sec 805 MBytes 6.75 Gbits/sec 0 1.92 MBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 8.15 GBytes 7.00 Gbits/sec 0 sender
> [ 5] 0.00-10.00 sec 8.15 GBytes 7.00 Gbits/sec receiver
>
> Where ip addr shows:
>
> 1: lo: <LOOPBACK,UP,LOWER_UP> ...
> ...
> ...
> 8: enp65s0f0np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
> ...
> inet6 2011::12/64 scope global
> valid_lft forever preferred_lft forever
> ...
> 12: ip6tnl0@NONE: <NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1000
> link/tunnel6 :: brd :: permaddr 1257:d9c1:e829::
> inet6 fe80::1057:d9ff:fec1:e829/64 scope link proto kernel_ll
> valid_lft forever preferred_lft forever
> 13: ip6gre0@NONE: <NOARP,UP,LOWER_UP> mtu 1448 qdisc noqueue state UNKNOWN group default qlen 1000
> link/gre6 :: brd :: permaddr cab1:6316:aa70::
> inet6 fe80::c8b1:63ff:fe16:aa70/64 scope link proto kernel_ll
> valid_lft forever preferred_lft forever
> 14: gre1@enp65s0f0np0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1448 qdisc noqueue state UNKNOWN group default qlen 1000
> link/gre6 2011::12 peer 2011::11 permaddr ded7:5b97:9098::
> ...
> inet6 2023::12/64 scope global
> valid_lft forever preferred_lft forever
> ...
>
> with 2023::11 being the other side of that GRE tunnel
> and ethtool -i enp65s0f0np0 shows that NIC uses ice driver.
>
> Even though this commit fixes 04c20a9356f283da, the throughput is still
> 50 % of its original rate. This leads me to the following question: since
> the original commit affects throughput on NICs with the bnxt_en or ice
> drivers, is it possible that in
>
> net/core/dev.c: skb_csum_hwoffload_help()
>
> the check
> ...
> if (vlan_get_protocol(skb) == htons(ETH_P_IPV6) &&
> skb_network_header_len(skb) != sizeof(struct ipv6hdr) &&
> !ipv6_has_hopopt_jumbo(skb))
> goto sw_checksum;
> ...
> should have another condition or flag before jumping to sw_checksum?
> Any insights would be greatly appreciated.
I would not know what.
Things might work before the blamed commit if the hardware is
capable of checksum offload with IPv6 extension headers. Even when
NETIF_F_IPV6 does not guarantee that and there is no more exact flag
that covers that scenario.
In which case the patch is correct, fixing checksum offload when
no segmentation offload is enabled. And your patch extends it to the
case where segmentation offload is also enabled.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-08-11 17:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-07 13:41 [PATCH net v2] net: mask NETIF_F_IPV6_CSUM flag on irregular packet header size Jakub Ramaseuski
2025-08-07 20:55 ` Willem de Bruijn
2025-08-11 15:33 ` Jakub Ramaseuski
2025-08-11 17:58 ` Willem de Bruijn
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).