Re: [RFC net-next v2 2/6] ethtool: Add loopback GET/SET netlink implementation

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

On 09/03/2026 15:51, Björn Töpel wrote:
> Björn Töpel <bjorn@kernel.org> writes:
> 
>> Maxime Chevallier <maxime.chevallier@bootlin.com> writes:
>>
>>> Hi Björn,
>>>
>>> On 08/03/2026 13:40, Björn Töpel wrote:
>>>> Add the kernel-side ETHTOOL_MSG_LOOPBACK_GET,
>>>> ETHTOOL_MSG_LOOPBACK_SET, and ETHTOOL_MSG_LOOPBACK_NTF handlers using
>>>> the standard ethnl_request_ops infrastructure.
>>>>
>>>> GET collects loopback entries from per-component helpers via
>>>> loopback_get_entries(). SET parses the nested entry attributes,
>>>> dispatches each to loopback_set_one(), and only sends a notification
>>>> when the state is changed.
>>>>
>>>> No components are wired yet.
>>>>
>>>> Signed-off-by: Björn Töpel <bjorn@kernel.org>
>>>
>>> At a first glance, what I see is that you're using the GET ->doit method
>>> to retrieve an array of loopback entries. The pefered approach in that
>>> case is to use the GET ->dumpit command instead, issueing a netlink DUMP
>>> request to list all available loopback entities on a given netdev.
>>>
>>> If you want some reference on that, take a look at the phy.c + the
>>> 'perphy' helpers in net/ethtool/netlink.c
>>>
>>> The idea is that you can pass a netdev ifindex in the header of the DUMP
>>> request, which you can use to dump all loopbacks the passed netdev.
>>>
>>> You can also check the ethtool code itself, you'll see that when you use
>>> the "ethtool --show-phys eth0" command for example, it issues a DUMP
>>> request to the kernel.
>>
>> Ah, got it! Thanks!
> 
> Thanks for pointing this out! I like how using this can get rid of the
> fixed size array in struct ethtool_loopback_cfg, which had a bad smell
> to me.
> 
> Thinking out loud -- Now, using a similar scheme for loopback requires
> some thought around the sub-iterator: Loopback has "multiple"
> sub-iterator: (component, [id], name)... or needs scheme to deal with
> one sub-iter, and loopback can share a lot of code with the
> perphy-functions.

yeah, at some point in the past I played around with the idea of more
generic ethnl helpers for filtered DUMP requests :

https://lore.kernel.org/netdev/20250324104012.367366-1-maxime.chevallier@bootlin.com/

At that time, the PHY usecase was the main user so I ended-up ditching
that in favor of the more specific perphy helpers we have today, after
discussing the matter with Jakub.

Now that we're seeing more and more ethnl DUMP commands that can take a
netdev ifindex in the request, maybe some of that code above can be useful
for you and we can resurect this approach ?

Maxime 

> 
> 
> Björn