Re: [PATCH net-next] Documentation: networking: Add a test plan for ethtool pause validation

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 29 Jun 2026 17:24:51 +0200 Maxime Chevallier wrote:
> On 6/28/26 01:46, Andrew Lunn wrote:
> > On Sat, Jun 27, 2026 at 02:30:28PM -0700, Jakub Kicinski wrote:  
> >> The common way of checking prereqs in the tests is to call a function
> >> called require_xyz() which then raises a skip. At a quick glance - the
> >> rss_api and xdp_metadata are good tests to get a sense of the usual format.  
> > 
> > The counter example is the ksft_disruptive() decorator.
> > 
> > Pythons own unittest framework makes use of decorators to skip
> > tests. Its the Pythonic way.  

Problem is vast majority of our developers do not know "Pythonic" ways.
And bash tests for HW are an absolute pile of impossible to debug
dookie. Half of the time bash doesn't print anything when test fails,
so good luck figuring out what happened on someone else's setup 10%
of the time :|

I'm hoping to strike a balance with keeping Python relatively dumb,
and pulling as many people as possible away form bash.

> So maybe in the end, we can try to have something a bit less python-y, while still
> using extensive documentation using sphynx doc format ?
> 
> Let me send a V2 with the full test list, we'll see how much scaffolding
> we can build for ethtool testing, and how. I suspect that running/skipping based on
> the device's capabilities is going to be used throughout lots of tests
> beyond pause.
> 
> For now the important part is to get that test list right, and iterate on the
> test implementation once we agree on what to test, why and how.

Maybe we should step back and figure out the full story for the
self-documentation thing. The good tests under tools...drivers/net
already have module and test-case level doc. So we can come up with
a way of extracting that and weaving that into NIPA? That way we are
all on the same page?

How should the test info be presented? I think it'd fit best in here:
https://netdev.bots.linux.dev/devices.html ? Or do you have something
else in mind?