netdev - Re: [PATCH ethtool] netlink: rss: retrieve ring count using ETHTOOL

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: <2fsnu2mhk4x5j3bh33pugjfs4e34ys72hmzahdlbctxolfagxj@obbdtitbnax3>
Date: Mon, 16 Sep 2024 21:38:14 +0200
From: Michal Kubecek <mkubecek@...e.cz>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>, 
	Sudheer Mogilappagari <sudheer.mogilappagari@...el.com>
Subject: Re: [PATCH ethtool] netlink: rss: retrieve ring count using
 ETHTOOL_GRXRINGS ioctl

On Fri, Sep 13, 2024 at 12:38:28PM +0300, Vladimir Oltean wrote:
> Several drivers regressed when ethtool --show-rxfh was converted from
> ioctl to netlink. This is because ETHTOOL_GRXRINGS was converted to
> ETHTOOL_MSG_CHANNELS_GET, which is semantically equivalent to
> ETHTOOL_GCHANNELS but different from ETHTOOL_GRXRINGS. Drivers which
> implement ETHTOOL_GRXRINGS do not necessarily implement ETHTOOL_GCHANNELS
> or its netlink equivalent.
> 
> According to the man page, "A channel is an IRQ and the set of queues
> that can trigger that IRQ.", which is different from the definition of
> a queue/ring. So we shouldn't be attempting to query the # of rings for
> the ioctl variant, but the # of channels for the netlink variant anyway.

I have asked this multiple times but I never got a direct answer: is
this only a formal terminology problem or is there an actual difference
between the two? In particular: is someone aware of an example of
a driver and device where these two counts differ? Or is there a reason
to expect such device either exists or will exist in the future?

(Actually, I seem to remember that the first time I asked, the general
consensus was that combined + rx is indeed the value we need here -
which is what current code does. But it has been few years so I would
have to look it up to be sure.)

If there is no real difference, it would be really unfortunate to have
the same count presented under two different names via two different
interfaces (->get_rxnfc() and ->get_channels() in ethtool_ops) with most
drivers providing both but some only one and some only the other. Which
seems to be the current state and the long term solution should be
cleaning this up.

If there is an actual difference, the long term solution would be
providing the necessary information as part of the
reply to ETHTOOL_MSG_RSS_GET requests - and the sooner we add it, the
better.

Short term, I'm afraid that however ugly this hack is, it's either it or
disabling the netlink handler until we can get the information reliably
from kernel.

Michal

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)