[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2a829a9c-69a6-695d-d3df-59190b161787@iogearbox.net>
Date: Mon, 4 Dec 2023 16:22:29 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: Feng Zhou <zhoufeng.zf@...edance.com>,
Nikolay Aleksandrov <razor@...ckwall.org>, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, yangzhenze@...edance.com,
wangdongdong.6@...edance.com, tangchen.1@...edance.com
Subject: Re: [PATCH bpf-next] netkit: Add some ethtool ops to provide
information to user
On 12/1/23 9:42 AM, Feng Zhou wrote:
> 在 2023/11/30 18:56, Daniel Borkmann 写道:
>> On 11/30/23 10:24 AM, Feng Zhou wrote:
>>> 在 2023/11/30 17:06, Nikolay Aleksandrov 写道:
>>>> On 11/30/23 09:58, Feng zhou wrote:
>>>>> From: Feng Zhou <zhoufeng.zf@...edance.com>
>>>>>
>>>>> Add get_strings, get_sset_count, get_ethtool_stats to get peer
>>>>> ifindex.
>>>>> ethtool -S nk1
>>>>> NIC statistics:
>>>>> peer_ifindex: 36
>>>>>
>>>>> Add get_link, get_link_ksettings to get link stat.
>>>>> ethtool nk1
>>>>> Settings for nk1:
>>>>> ...
>>>>> Link detected: yes
>>>>>
>>>>> Add get_ts_info.
>>>>> ethtool -T nk1
>>>>> Time stamping parameters for nk1:
>>>>> ...
>>>>>
>>>>> Signed-off-by: Feng Zhou <zhoufeng.zf@...edance.com>
>>>>> ---
>>>>> drivers/net/netkit.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 53 insertions(+)
>>>>
>>>> I don't see any point in sending peer_ifindex through ethtool, even
>>>> worse through ethtool stats. That is definitely the wrong place for it.
>>>> You can already retrieve that through netlink. About the speed/duplex
>>>> this one makes more sense, but this is the wrong way to do it.
>>>> See how we did it for virtio_net (you are free to set speed/duplex
>>>> to anything to please bonding for example). Although I doubt anyone will use netkit with bonding, so even that is questionable. :)
>>>>
>>>> Nacked-by: Nikolay Aleksandrov <razor@...ckwall.org>
>>>
>>> We use netkit to replace veth to improve performance, veth can be used ethtool -S veth to get peer_ifindex, so this part is added, as long as it is to keep the netkit part and veth unified, to ensure the same usage habits, and to replace it without perception.
>>
>> Could you elaborate some more on the use case why you need to retrieve it
>> via ethtool, what alternatives were tried and don't work?
>>
>> Please also elaborate on the case for netkit_get_link_ksettings() and which
>> concrete problem you are trying to address with this extension?
>>
>> The commit message only explains what is done but does not go into the detail
>> of _why_ you need it.
>
> In general, this information can be obtained through ip commands or netlink, and netkit_get_link_ksettings really not necessary. The reason why ethtool supports this is that when we use veth, our business colleagues are used to using ethtool to obtain peer_ifindex, and then replace netkit, found that it could not be used, resulting in their script failure, so they asked us for a request.
Thanks, so the netkit_get_link_ksettings is optional. I don't quite follow what you
mean with regards to your business logic in veth to obtain peer ifindex. What does
the script do exactly with the peer ifindex (aka /why/ is it needed), could you
elaborate some more - it's still somewhat too vague? :) E.g. why it does not suffice
to look at the device type or other kind of attributes?
Thanks,
Daniel
Powered by blists - more mailing lists