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

[Oleksij Rempel <o.rempel@pengutronix.de>]

Hi,

On Fri, May 29, 2026 at 09:42:14AM +0200, Maxime Chevallier wrote:
> Hi
> 
> On 5/28/26 01:25, Jakub Kicinski wrote:
> > On Wed, 27 May 2026 04:47:47 +0200 Andrew Lunn wrote:
> > > > It'd be great to hear from others but IMHO in the current form this is
> > > > not suitable for Documentation/networking/ We can commit the "knowledge"
> > > > part but enumerating the test cases seems odd for Documentation/.
> > > 
> > > Sorry, not looked too deeply at the actual content yet.
> > > 
> > > What i was thinking was a python file, which sphinx can ingest to
> > > produce documentation, and place holders were code would be added to
> > > implement the actual test during the next phase.
> > > 
> > > This is how i've done testing in the past. I would be the evil one who
> > > thought up the tests and described them in detail using sphinx markup
> > > in a python test template file. After some review they got passed off
> > > to a python developer for implementation. And when they got run and
> > > failed, sometimes the feature developer, the test developer and myself
> > > got together to figure who made the error.
> > > 
> > > I'm not sure we even need sphinx. What i find important is that the
> > > test is documented. What kAPI calls should be made with what
> > > parameters. What results we are expected and why? So that when a test
> > > fails, a developer has the information they need to fix their
> > > code. The Why? is important, and often missing from the kernel tests.
> > 
> > All makes sense. The question is primarily how we fit that into
> > the existing project layout we have in the kernel :(
> > 
> > The python tests can be hacked up to print the test case docstring
> > before the failure.
> > 
> > But I think for human and AI reviewer consumption it may be nice
> > to keep the condensed knowledge / common mistakes in Documentation/
> > If we had the ability to exercise the submissions it'd be a different
> > story test output would be a sufficient signal and/or could be fed into
> > the review. But for AI making a guess at whether the submitted driver is
> > correct purely from the driver source - knowledge is useful.
> 
> Also for the knowledge part, we had Oleksij's series that documented
> more aspects of flow control (not just the pause part) :
> 
> https://lore.kernel.org/netdev/20260304094811.2779953-1-o.rempel@pengutronix.de/
> 
> Oleksij, maybe we can merge some of the information here with your
> doc for the Docuentation/networking part ?

I have nothing against it. We need a documentation for proper testing
and implementations too :)

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |