linux-kernel - Re: [PATCH net-next v8 1/1] Documentation: net: add flow control guide and document ethtool API

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: <aSh37U5VOgYqmzqN@shell.armlinux.org.uk>
Date: Thu, 27 Nov 2025 16:10:21 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Alexei Starovoitov <ast@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>, Rob Herring <robh@...nel.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Donald Hunter <donald.hunter@...il.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	Jonathan Corbet <corbet@....net>,
	John Fastabend <john.fastabend@...il.com>,
	Lukasz Majewski <lukma@...x.de>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Stanislav Fomichev <sdf@...ichev.me>,
	Paolo Abeni <pabeni@...hat.com>, Jiri Pirko <jiri@...nulli.us>,
	Jesper Dangaard Brouer <hawk@...nel.org>,
	Divya.Koppera@...rochip.com,
	Kory Maincent <kory.maincent@...tlin.com>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>, netdev@...r.kernel.org,
	Sabrina Dubroca <sd@...asysnail.net>, linux-kernel@...r.kernel.org,
	kernel@...gutronix.de, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH net-next v8 1/1] Documentation: net: add flow control
 guide and document ethtool API

On Thu, Nov 27, 2025 at 10:20:54AM +0100, Oleksij Rempel wrote:
> 2. **Forced Mode** (``autoneg off``)

This should state that this is the "autoneg" on the ethtool -A / --pause
command, not the ethtool -s / --change command.

> Pre-link Configuration (Administrative UP, Physical DOWN) How should drivers
> handle set_pauseparam when the link is physically down?
> 
>  Fully Forced: If speed/duplex are forced, we can validate the pause request
>  immediately.
> 
>  Parallel Detection: If the link comes up later (e.g., as Half Duplex via
>  parallel detection), a previously accepted "forced pause" configuration might
>  become invalid. Should we block forced pause settings until the link is
>  physically up?

Why would the users request become invalid? Why should the user have to
re-set their requested policy if the link flips from FD to HD and back
to FD for whatever reason? The kernel should accept the users requested
policy, and apply it when appropriate (in other words, when in FD mode.)

> State Persistence and Toggling When toggling autoneg (e.g., autoneg on -> off
> -> on), should the kernel or driver cache the previous advertisement?
> 
>   Currently, if a user switches to forced mode and back, the previous
>   advertisement preferences might be lost or reset to defaults depending on the
>   driver.

Turning pause autoneg off should not change the advertisement. It should
be thought of a control that selects whether the results of autoneg are
used vs not used. Note that phylink updates the advertisement even when
pause autoneg is turned off. This follows the stated API documentation
(please ensure your documentation conforms to the already existing API
documentation, and doesn't inadvertently propose something different -
this is exactly why I hate that we're getting multiple definitions of
the same stuff in different places.)

 * If the link is autonegotiated, drivers should use
 * mii_advertise_flowctrl() or similar code to set the advertised
 * pause frame capabilities based on the @rx_pause and @tx_pause flags,
 * even if @autoneg is zero.  They should also allow the advertised
 * pause frame capabilities to be controlled directly through the
 * advertising field of &struct ethtool_cmd.

Note that this requires that the advertisement is updated even if pause
autoneg is zero. Phylink implements this.

>   Similarly, if no administrative configuration has ever been set, what should
>   get_pauseparam report? Should it read the current hardware state (which might
>   be default) or return zero/empty?
> 
> Synchronization with Link Modes Configuring pause via set_pauseparam vs.
> link_ksettings can lead to desynchronization.
> 
>   My testing shows that set_pauseparam often updates the driver's internal
>   pause state but may not trigger the necessary link reset/re-advertisement
>   that link_ksettings does.
> 
>   This results in the reported "Advertised" pause modes in ethtool output being
>   out of sync with the actual Pause API settings.
> 
>   Combining configuration over different interfaces sometimes will avoid
>   link reset, so new configuration is not advertised.

... which I'm sure Andrew will argue is a reason for drivers to use
phylink which implements this properly!

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!