netdev - Re: [PATCH net-next v6 6/7] net: selftests: Export net_test_phy_loopback

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: <09a4cd33-3170-4f87-a84b-5e1734d97206@engleder-embedded.com>
Date: Wed, 12 Feb 2025 22:36:00 +0100
From: Gerhard Engleder <gerhard@...leder-embedded.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
 netdev@...r.kernel.org, Oleksij Rempel <o.rempel@...gutronix.de>
Subject: Re: [PATCH net-next v6 6/7] net: selftests: Export
 net_test_phy_loopback_*

On 12.02.25 21:46, Andrew Lunn wrote:
>> Reusing the complete test set as extension is not feasible as the first
>> test requires an existing link and for loopback test no link is
>> necessary. But yes, I can do better and rework it to reusable tests.
>> I'm not sure if I will use ethtool_test_flags as IMO ideally all tests
>> run always to ensure easy use.
> 
> We try to ensure backwards/forwards compatibly between ethtool and the
> kernel.
> 
> The point about ethtool_test_flags is that for older versions of
> ethtool, you have no idea what the reserved field contains. Has it
> always been set to zero? If there is a flag indicating reserved
> contains a value, you then know it is safe to use it.

I'm not sure if I understand the last sentence. Do you mean it is safe
to use a flag that was previously marked as reserved if the clients did
set it to zero, but for ethtool_test_flags this is not the case?

> At some point, the API needs moving to netlink sockets. It then
> becomes a lot easier to add extra parameters, as attributes.
> 
> There is also an interesting overlap here and:
> 
> https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-management-and-testing.html
> 
> What you are doing is not too dissimilar, although the PRBS is an
> 802.3 standard concept and typically part of the PCS. There needs to
> be some sort of API for configuring the PRBS, maybe as part of ethtool
> self tests? If so, the API is going to need extensions.

Sounds also similar to bit error testing of transceivers. I want to
stress a data link with all supported modes and this is similar.
For me it is sufficient if the driver tests all supported modes, without
any configuration from user space. But extending the API
to enable advanced testing during development and production is
reasonable.

Gerhard