[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230403150312.79174a7e@kernel.org>
Date: Mon, 3 Apr 2023 15:03:12 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: <edward.cree@....com>
Cc: <linux-net-drivers@....com>, <davem@...emloft.net>,
<pabeni@...hat.com>, <edumazet@...gle.com>,
Edward Cree <ecree.xilinx@...il.com>, <netdev@...r.kernel.org>,
<habetsm.xilinx@...il.com>, <sudheer.mogilappagari@...el.com>
Subject: Re: [RFC PATCH net-next 5/6] net: ethtool: add a mutex protecting
RSS contexts
On Mon, 3 Apr 2023 17:33:02 +0100 edward.cree@....com wrote:
> u32 rss_ctx_max_id;
> struct idr rss_ctx;
> + struct mutex rss_lock;
Argh, the mutex doubles the size of the state, and most drivers don't
implement this feature. My thinking was to add a "ethtool state"
pointer to net_device which will be allocated by ethtool on demand
and can hold all ethtool related state.
For psychological reasons primarily (IOW I feel like people shy away
from storing state in the core because it feels expensive to add stuff
to net_device while it would not seem expensive to add it to struct
ethtool_netdev_state).
Maybe we can do the on-demand allocation later - but could we at least
wrap the ethtool-related fields in a separate struct to hold them
together?
Powered by blists - more mailing lists