linux-kernel - Re: [PATCH net-next v2 1/1] Documentation: networking: add detailed guide on Ethernet flow control configuration

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] [day] [month] [year] [list]

Message-ID: <aKWB8QA8fTwrZhFb@pengutronix.de>
Date: Wed, 20 Aug 2025 10:06:09 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Kory Maincent <kory.maincent@...tlin.com>,
	Lukasz Majewski <lukma@...x.de>, Jonathan Corbet <corbet@....net>,
	kernel@...gutronix.de, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Russell King <linux@...linux.org.uk>,
	Divya.Koppera@...rochip.com
Subject: Re: [PATCH net-next v2 1/1] Documentation: networking: add detailed
 guide on Ethernet flow control configuration

On Tue, Aug 19, 2025 at 02:48:22PM +0200, Andrew Lunn wrote:
> > +2. Half-Duplex: Collision-Based Flow Control
> > +--------------------------------------------
> > +On half-duplex links, a device cannot send and receive simultaneously, so PAUSE
> > +frames are not used. Flow control is achieved by leveraging the CSMA/CD
> > +(Carrier Sense Multiple Access with Collision Detection) protocol itself.
> > +
> > +* **How it works**: To inhibit incoming data, a receiving device can force a
> > +    collision on the line. When the sending station detects this collision, it
> > +    terminates its transmission, sends a "jam" signal, and then executes the
> > +    "Collision backoff and retransmission" procedure as defined in IEEE 802.3,
> > +    Section 4.2.3.2.5. This algorithm makes the sender wait for a random
> > +    period before attempting to retransmit. By repeatedly forcing collisions,
> > +    the receiver can effectively throttle the sender's transmission rate.
> > +
> > +.. note::
> > +    While this mechanism is part of the IEEE standard, there is currently no
> > +    generic kernel API to configure or control it. Drivers should not enable
> > +    this feature until a standardized interface is available.
> 
> Interesting. I did not know about this.
> 
> I wounder if we want phylib and phylink to return -EOPNOTSUPP in the
> general code, if the current link is 1/2 duplex?

Rejecting ethtool -A calls in half-duplex mode would cause problems. At
request time we often don’t know what the final link will be (autoneg,
fixed link, link flapping, etc.). On top of that, PAUSE conflicts not
only with half-duplex, but also with PFC.

A cleaner model is to treat ethtool pause config as a wish specifically
for 802.3x PAUSE. Phylib/phylink store this wish and apply it
automatically when the negotiated link is compatible (full-duplex
without PFC). If the link is not compatible (half-duplex, PFC), the wish
is ignored.

So the user always sets their preference once, the kernel enforces it
when possible, and status queries (ethtool -a) show the actual active
state. This avoids races and keeps semantics simple and predictable.

> > +Additionally, some MACs provide a way to configure the `pause_time` value
> > +(quanta) sent in PAUSE frames. This value's duration depends on the link
> > +speed. As there is currently no generic kernel interface to configure this,
> > +drivers often set it to a default or maximum value, which may not be optimal
> > +for all use cases.
> 
> The Mellanox driver has something in this space. It is a long time ago
> that i reviewed the patches. I don't remember if it is a pause_time
> you can configure, or the maximum number of pause frames you can send
> before giving up and just letting the buffers overflow. I also don't
> remember what API is used, if it is something custom, or generic. It
> is a bit of a niche thing, so maybe it is not worth researching and
> mentioning.

I did some digging. A number of drivers simply hard-code the pause
quanta to the maximum value for all link modes:

stmmac: #define PAUSE_TIME 0xffff
lan78xx: pause_time_quanta = 65535
smsc95xx / smsc75xx: flow = 0xFFFF0002
FEC: FEC_ENET_OPD_V  = 0xFFF0

If we translate quanta into real time:
1 Gbps -> 1 quanta = 512 ns -> max val ~ 33.6 ms
100 Mbps -> 1 quanta = 5.12 µs -> max val ~ 335 ms
10 Mbps -> 1 quanta = 51.2 µs -> max val ~ 3.3 s

-- 
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 |