[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231005165344.50228a06@kernel.org>
Date: Thu, 5 Oct 2023 16:53:44 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Edward Cree <ecree.xilinx@...il.com>
Cc: edward.cree@....com, linux-net-drivers@....com, davem@...emloft.net,
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: [PATCH v4 net-next 2/7] net: ethtool: attach an XArray of
custom RSS contexts to a netdevice
On Thu, 5 Oct 2023 19:43:36 +0100 Edward Cree wrote:
> > Is this one set by the driver? How would it be set?
>
> I was thinking drivers would just assign this directly in their
> probe routine.
>
> > It'd be good if drivers didn't access ethtool state directly.
> > Makes core easier to refactor if the API is constrained.
>
> Would you prefer it as a getter in the ethtool ops? The core
> would call it every time a new context is being allocated.
If ops work that'd be simplest. I was worried that the exact limit
may need to be established at runtime based on FW/HW gen, and that's
why you place it here. But that's a more general problem with the
current simplistic approach of sticking all the capabilities into ops.
If you only need a static cofing we can go with ops and add runtime
corrections for all caps later on.
Powered by blists - more mailing lists