| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <689a2f3db6c9a_631932945d@willemb.c.googlers.com.notmuch> Date: Mon, 11 Aug 2025 13:58:21 -0400 From: Willem de Bruijn <willemdebruijn.kernel@...il.com> To: Jakub Ramaseuski <jramaseu@...hat.com>, willemdebruijn.kernel@...il.com Cc: horms@...nel.org, jramaseu@...hat.com, kuba@...nel.org, mschmidt@...hat.com, netdev@...r.kernel.org, pabeni@...hat.com, tizhao@...hat.com Subject: Re: Re: [PATCH net v2] net: mask NETIF_F_IPV6_CSUM flag on irregular packet header size 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@...E: <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@...E: <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@...65s0f0np0: <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.
Powered by blists - more mailing lists