netdev - Re: [PATCH net-next v3 3/3] 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] [day] [month] [year] [list]

Message-ID: <20250822141921.rlii3dnblodqezrc@skbuf>
Date: Fri, 22 Aug 2025 17:19:21 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Andrew Lunn <andrew@...n.ch>, 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>,
	Donald Hunter <donald.hunter@...il.com>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
	Jiri Pirko <jiri@...nulli.us>, Alexei Starovoitov <ast@...nel.org>,
	Daniel Borkmann <daniel@...earbox.net>,
	Jesper Dangaard Brouer <hawk@...nel.org>,
	John Fastabend <john.fastabend@...il.com>, kernel@...gutronix.de,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Russell King <linux@...linux.org.uk>, Divya.Koppera@...rochip.com,
	Sabrina Dubroca <sd@...asysnail.net>,
	Stanislav Fomichev <sdf@...ichev.me>
Subject: Re: [PATCH net-next v3 3/3] Documentation: net: add flow control
 guide and document ethtool API

On Fri, Aug 22, 2025 at 02:12:26PM +0200, Oleksij Rempel wrote:
> > > +The optimal values for these thresholds depend on the link's round-trip-time
> > > +(RTT) and the peer's internal processing latency. The high water mark must be
> > > +set low enough so that the MAC's RX FIFO does not overflow while waiting for
> > > +the peer to react to the PAUSE frame. The driver is responsible for configuring
> > > +sensible defaults according to the IEEE specification. User tuning should only
> > > +be necessary in special cases, such as on links with unusually long cable
> > > +lengths (e.g., long-haul fiber).
> > 
> > How would user tuning be achieved?
> 
> Do you mean how such tuning could be exposed to user space (e.g. via
> ethtool/sysfs), or rather whether it makes sense to provide a user
> interface for this at all, since drivers normally set safe defaults?

Sorry for not being clear. I think that by saying that user tuning
should only be necessary in certain cases, you're giving the impression
that it's supported in current API. You might want to clarify that it's
not.

Also, I'm not sure that the length of the cable runs would be a factor
in tuning the flow control watermarks, do you have a reference for that?
I'm mentally debating the value of the last sentence.