[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250624075640.343f02dd@2a02-8440-d115-be0d-cec0-a2a1-bc3c-622e.rev.sfr.net>
Date: Tue, 24 Jun 2025 07:56:40 +0200
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org,
donald.hunter@...il.com, sdf@...ichev.me, jdamato@...tly.com,
ecree.xilinx@...il.com
Subject: Re: [PATCH net-next v2 4/8] net: ethtool: remove the data argument
from ethtool_notify()
On Mon, 23 Jun 2025 16:17:16 -0700
Jakub Kicinski <kuba@...nel.org> wrote:
> ethtool_notify() takes a const void *data argument, which presumably
> was intended to pass information from the call site to the subcommand
> handler. This argument currently has no users.
>
> Expecting the data to be subcommand-specific has two complications.
>
> Complication #1 is that its not plumbed thru any of the standardized
> callbacks. It gets propagated to ethnl_default_notify() where it
> remains unused. Coming from the ethnl_default_set_doit() side we pass
> in NULL, because how could we have a command specific attribute in
> a generic handler.
>
> Complication #2 is that we expect the ethtool_notify() callers to
> know what attribute type to pass in. Again, the data pointer is
> untyped.
>
> RSS will need to pass the context ID to the notifications.
> I think it's a better design if the "subcommand" exports its own
> typed interface and constructs the appropriate argument struct
> (which will be req_info). Remove the unused data argument from
> ethtool_notify() but retain it in a new internal helper which
> subcommands can use to build a typed interface.
>
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@...tlin.com>
Tested-by: Maxime Chevallier <maxime.chevallier@...tlin.com>
Maxime
Powered by blists - more mailing lists