netdev - Re: [PATCH net-next] ethtool: add netlink support for rss set

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

Date:   Tue, 14 Mar 2023 13:34:51 +0000
From:   Edward Cree <ecree.xilinx@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        "Mogilappagari, Sudheer" <sudheer.mogilappagari@...el.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>,
        "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>
Subject: Re: [PATCH net-next] ethtool: add netlink support for rss set

On 13/03/2023 22:53, Jakub Kicinski wrote:
> Ah, so you do have a feature. Yes, it would be somewhat helpful but my
> larger concern remains. We skipped the dump implementation when
> implementing GET. The admin still has no way of knowing what / how many
> RSS contexts had been created. With the context ID being an unbounded
> integer just going from 0 until ENOENT is not even an option.
> 
> So we need to start tracking the contexts.

Hi Jakub, as the original author of custom RSS contexts I feel like I
 owe this bit of work; I can take a swing at it, unless Sudheer would
 rather do it himself.

> Add a pointer to struct
> netdevice to hold an "ethtool_settings" struct. In the ethtool settings
> struct add a list head. Put an object for each created RSS context on
> that list.
Would an IDR not be appropriate here, rather than a list?
AFAICT every driver that supports contexts either treats the context
 ID as an opaque handle or as an index into a fixed-size array, so as
 long as the driver reports its max context ID to the core somehow,
 the specific ID values chosen are arbitrary and the driver doesn't
 need to do the choosing, it can just take what comes out of the IDR.