| 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: <20250811153315.856048-1-jramaseu@redhat.com>
Date: Mon, 11 Aug 2025 17:33:15 +0200
From: Jakub Ramaseuski <jramaseu@...hat.com>
To: 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
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.
Powered by blists - more mailing lists