netdev - Re: Netlink handler for ethtool --show-rxfh breaks driver compatibility

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: <20240717094501.2e60075d@kernel.org>
Date: Wed, 17 Jul 2024 09:45:01 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: "Mogilappagari, Sudheer" <sudheer.mogilappagari@...el.com>, Michal
 Kubecek <mkubecek@...e.cz>, "netdev@...r.kernel.org"
 <netdev@...r.kernel.org>, Wei Fang <wei.fang@....com>, "Samudrala, Sridhar"
 <sridhar.samudrala@...el.com>
Subject: Re: Netlink handler for ethtool --show-rxfh breaks driver
 compatibility

On Mon, 15 Jul 2024 18:46:53 +0300 Vladimir Oltean wrote:
> > They can provide a different number? Which number is the user
> > supposed to trust? Out of the 4 APIs we have? Or the NIC has
> > a different ring count depending on the API?  
> 
> To stay on point on GRXRINGS vs GCHANNELS, "man ethtool" does say
> "A channel is an IRQ and the set of queues that can trigger that IRQ."
> Doesn't sound either (a) identical or (b) that you can recover the # of
> rings from the # of channels, unless you make an assumption about how
> they are distributed to IRQs...

A bit short on time to write a proper reply, but thinking some more
about it, I think you're right. The choice of channels is not great.
It works today, but if we start stacking multiple Rx queues on a single
IRQ one day - things will get complicated. So let's go back to GRXRINGS
for now.