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

On Thu, Jun 25, 2026 at 12:46:44PM +0200, Maxime Chevallier wrote:

Hi Andrew,

On 5/29/26 14:59, Andrew Lunn wrote:

(This discussion was a while ago, but this bit of context should be enough)

quoted

But we also need to consider that for some APIs, we have decided that
a configuration can be set now, which does not actually apply in our
current conditions, but it will be stored away for when conditions
change and it is applicable. The half duplex case could fit that. When
the link is currently half duplex, you can configure pause, but you
don't expect it to actually change the current behaviour. It only
kicks in when the link renegotiates to full duplex sometime in the
future. We have to also consider this the other way around. The link
is full duplex and pause is configured by the user. Something happens
with the LP and the link renegotiates to half duplex. The local end
should not throw away the configuration, it simply cannot apply it
given the current situation.

I'm writing the test description for HD with a better formatting, so the
HD test wouldn't be about "are we using pause stuff while in HD" as it
doesn't make sense, but rather "do we correctly store the pause settings
aside for later".

O.K.

I'm realising that we don't really have an API to report the *true* in-use pause
settings. Taking HD as an example :

# ethtool -s eth2 duplex half

[588209.379363] mvpp2 f4000000.ethernet eth2: Link is Up - 100Mbps/Half - flow control off

# ethtool eth2
	[...]
	Supported pause frame use: Symmetric Receive-only
	Advertised pause frame use: Symmetric Receive-only
	Link partner advertised pause frame use: Symmetric Receive-only

Does it even make sense to advertise this when in HD? But i don't
think we need to consider this now. I consider HD low priority, i
doubt it is actually used very often. We should concentrate on FD
testing.

# ethtool -a eth2
Autonegotiate:	on
RX:		off
TX:		off
RX negotiated: on
TX negotiated: on


Sure, pause and HD don't make sense, however what I find confusing to some
extent is that the only place we have information about the *actual* pause
settings is the "link is Up" log in dmesg.

Maybe we should extend ksetting get to return the resolved pause
parameters? But i'm not sure how much that actually gives us. Anything
using phylink will just ask phylink to fill in the ksettings
information, and it seems unlikely phylink gets it wrong. What we are
really trying to test is drivers which don't user phylink, those are
the ones which are generally broken, and they are not going to
implement anything new in ksettings. So i think the test has to look
at:

	Advertised pause frame use: Symmetric Receive-only
	Link partner advertised pause frame use: Symmetric Receive-only

and check these match what we expect.

    Andrew