[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f0ecc83c-13c7-9cb8-ee2c-8b8e1cba7db1@gmail.com>
Date: Tue, 19 Sep 2023 15:36:30 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: edward.cree@....com, linux-net-drivers@....com, davem@...emloft.net,
kuba@...nel.org, edumazet@...gle.com, pabeni@...hat.com,
netdev@...r.kernel.org, habetsm.xilinx@...il.com,
sudheer.mogilappagari@...el.com, jdamato@...tly.com, andrew@...n.ch,
mw@...ihalf.com, linux@...linux.org.uk, sgoutham@...vell.com,
gakula@...vell.com, sbhatta@...vell.com, hkelam@...vell.com,
saeedm@...dia.com, leon@...nel.org
Subject: Re: [RFC PATCH v3 net-next 4/7] net: ethtool: let the core choose RSS
context IDs
On 19/09/2023 12:10, Martin Habets wrote:
> On Tue, Sep 12, 2023 at 03:21:39PM +0100, edward.cree@....com wrote:
>> + int (*create_rxfh_context)(struct net_device *,
>> + struct ethtool_rxfh_context *ctx,
>> + const u32 *indir, const u8 *key,
>> + const u8 hfunc, u32 rss_context);
>
> To return the rss_context this creates shouldn't it use a pointer to
> rss_context here?
No, the whole point of this new API is that the core, not the
driver, chooses the value of rss_context. Does the commit
message not explain that sufficiently?
(If you look at Patch #7 you'll see that sfc doesn't even use the
value, though other drivers might if their HW has a fixed set of
slots for RSS configs.)
-ed
Powered by blists - more mailing lists