netdev - Re: [net-next PATCH v3 0/8] Add support for 25G, 50G, and 100G to fbnic

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5ce8c769-6c36-4d0a-831d-e8edab830beb@redhat.com>
Date: Thu, 19 Jun 2025 10:44:41 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Alexander Duyck <alexander.duyck@...il.com>, netdev@...r.kernel.org
Cc: linux@...linux.org.uk, hkallweit1@...il.com, andrew+netdev@...n.ch,
 davem@...emloft.net, kuba@...nel.org, kernel-team@...a.com,
 edumazet@...gle.com
Subject: Re: [net-next PATCH v3 0/8] Add support for 25G, 50G, and 100G to
 fbnic

On 6/19/25 12:07 AM, Alexander Duyck wrote:
> The fbnic driver up till now had avoided actually reporting link as the
> phylink setup only supported up to 40G configurations. This changeset is
> meant to start addressing that by adding support for 50G and 100G interface
> types.
> 
> With that basic support added fbnic can then set those types based on the
> EEPROM configuration provided by the firmware and then report those speeds
> out using the information provided via the phylink call for getting the
> link ksettings. This provides the basic MAC support and enables supporting
> the speeds as well as configuring flow control.
> 
> After this I plan to add support for a PHY that will represent the SerDes
> PHY being used to manage the link as we need a way to indicate link
> training into phylink to prevent link flaps on the PCS while the SerDes is
> in training, and then after that I will look at rolling support for our
> PCS/PMA into the XPCS driver.

Apparently this is causing TSO tests failures:

# ok 1 tso.ipv4
# # Testing with mangleid enabled
# # Check| At
/home/virtme/testing-24/tools/testing/selftests/drivers/net/hw/./tso.py,
line 160, in f:
# # Check|     run_one_stream(cfg, ipver, remote_v4, remote_v6,
# # Check| At
/home/virtme/testing-24/tools/testing/selftests/drivers/net/hw/./tso.py,
line 80, in run_one_stream:
# # Check|     ksft_ge(qstat_new['tx-hw-gso-wire-packets'] -
# # Check failed 0 < 2516.0 Number of LSO wire-packets with LSO enabled
# not ok 2 tso.vxlan4_ipv4
# # Check| At
/home/virtme/testing-24/tools/testing/selftests/drivers/net/hw/./tso.py,
line 160, in f:
# # Check|     run_one_stream(cfg, ipver, remote_v4, remote_v6,
# # Check| At
/home/virtme/testing-24/tools/testing/selftests/drivers/net/hw/./tso.py,
line 80, in run_one_stream:
# # Check|     ksft_ge(qstat_new['tx-hw-gso-wire-packets'] -
# # Check failed 0 < 2516.0 Number of LSO wire-packets with LSO enabled
# not ok 3 tso.vxlan4_ipv6

And vlxlan TSO, too:

# # Check| At
/home/virtme/testing-24/tools/testing/selftests/drivers/net/hw/./tso.py,
line 154, in f:
# # Check|     run_one_stream(cfg, ipver, remote_v4, remote_v6,
should_lso=False)
# # Check| At
/home/virtme/testing-24/tools/testing/selftests/drivers/net/hw/./tso.py,
line 65, in run_one_stream:
# # Check|     ksft_lt(tcp_sock_get_retrans(sock), 10)
# # Check failed 10 >= 10
# not ok 10 tso.vxlan6_ipv6

I'm tentatively/blindly removing this from the PW queue to double check
the assumption.

/P