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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aKS5p8ALKEl5PISD@shell.armlinux.org.uk>
Date: Tue, 19 Aug 2025 18:51:36 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>,
	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, 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?
> 
> It might be considered an ABI change. I guess the generic code
> currently stores the settings and only puts them into effect when the
> link changes to full duplex?

The pause API is exactly that, it's an API for controlling the pause
frame stuff which isn't the HD version of flow control. We haven't had
an API for it, but it does exist.

In networks which are HD in nature, enabling HD "flow control" would
be disasterous. (Think 10base2 or a twisted-pair network that uses a
hub rather than a switch.) When the station decides to inhibit the
reception of packets, it will cause a collision on the network, which
will be network-wide rather than just the segment between a switch
and host. Whether that's something we care, whether it's something
that should be mentioned is an open question.

> > +
> > +Configuring Flow Control with `ethtool`
> > +=======================================
> > +
> > +The standard tool for managing flow control is `ethtool`.
> > +
> > +Viewing the Current Settings
> > +----------------------------
> > +Use `ethtool -a <interface>` to see the current configuration.
> > +
> > +.. code-block:: text
> > +
> > +  $ ethtool -a eth0
> > +  Pause parameters for eth0:
> > +  Autonegotiate:  on
> > +  RX:             on
> > +  TX:             on
> > +
> > +* **Autonegotiate**: Shows if flow control settings are being negotiated with
> > +    the link partner.
> > +
> > +* **RX**: Shows if we will *obey* PAUSE frames (pause our sending).
> > +
> > +* **TX**: Shows if we will *send* PAUSE frames (ask the peer to pause).
> > +
> > +If autonegotiation is on, `ethtool` will also show the active, negotiated result.
> > +This result is calculated by `ethtool` itself based on the advertisement masks
> > +from both link partners. It represents the expected outcome according to IEEE
> > +802.3 rules, but the final decision on what is programmed into the MAC hardware
> > +is made by the kernel driver.
> > +
> > +.. code-block:: text
> > +
> > +  RX negotiated: on
> > +  TX negotiated: on
> 
> Maybe add a description of what happens if Pause Auto negotiation is
> off?
> 
> Also, one of the common errors is mixing up Pause Autoneg and Autoneg
> in general. Pause Autoneg can be off while generic Autoneg is on.
> 
> And if i remember correctly, with phylink, if generic Autoneg is off,
> but pause Autoneg is on, the settings are saved until generic Autoneg
> is enabled.

Yes, phylink remembers the settings for the ethtool command in
pl->link_config.pause.

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