diff mbox series

[bpf-next] netkit: Add some ethtool ops to provide information to user

Message ID 20231130075844.52932-1-zhoufeng.zf@bytedance.com (mailing list archive)
State Changes Requested
Delegated to: BPF
Headers show
Series [bpf-next] netkit: Add some ethtool ops to provide information to user | expand

Checks

Context Check Description
bpf/vmtest-bpf-next-PR success PR summary
bpf/vmtest-bpf-next-VM_Test-0 success Logs for Lint
bpf/vmtest-bpf-next-VM_Test-1 success Logs for ShellCheck
bpf/vmtest-bpf-next-VM_Test-2 success Logs for Validate matrix.py
bpf/vmtest-bpf-next-VM_Test-3 success Logs for aarch64-gcc / build / build for aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-8 success Logs for aarch64-gcc / veristat
bpf/vmtest-bpf-next-VM_Test-4 success Logs for aarch64-gcc / test (test_maps, false, 360) / test_maps on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-7 success Logs for aarch64-gcc / test (test_verifier, false, 360) / test_verifier on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-6 success Logs for aarch64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-5 success Logs for aarch64-gcc / test (test_progs, false, 360) / test_progs on aarch64 with gcc
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for bpf-next
netdev/ynl fail Tree is dirty after regen; build failed; build has 1 warnings/errors;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 1117 this patch: 1117
netdev/cc_maintainers success CCed 7 of 7 maintainers
netdev/build_clang success Errors and warnings before: 1143 this patch: 1143
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 1144 this patch: 1144
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 67 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
bpf/vmtest-bpf-next-VM_Test-14 success Logs for s390x-gcc / veristat
bpf/vmtest-bpf-next-VM_Test-16 success Logs for x86_64-gcc / build / build for x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-15 success Logs for set-matrix
bpf/vmtest-bpf-next-VM_Test-9 success Logs for s390x-gcc / build / build for s390x with gcc
bpf/vmtest-bpf-next-VM_Test-18 success Logs for x86_64-gcc / test (test_progs, false, 360) / test_progs on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-20 success Logs for x86_64-gcc / test (test_progs_no_alu32_parallel, true, 30) / test_progs_no_alu32_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-22 success Logs for x86_64-gcc / test (test_verifier, false, 360) / test_verifier on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-21 success Logs for x86_64-gcc / test (test_progs_parallel, true, 30) / test_progs_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-19 success Logs for x86_64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-17 success Logs for x86_64-gcc / test (test_maps, false, 360) / test_maps on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-23 success Logs for x86_64-gcc / veristat / veristat on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-26 success Logs for x86_64-llvm-16 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-16
bpf/vmtest-bpf-next-VM_Test-24 success Logs for x86_64-llvm-16 / build / build for x86_64 with llvm-16
bpf/vmtest-bpf-next-VM_Test-25 success Logs for x86_64-llvm-16 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-16
bpf/vmtest-bpf-next-VM_Test-27 success Logs for x86_64-llvm-16 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-16
bpf/vmtest-bpf-next-VM_Test-29 success Logs for x86_64-llvm-16 / veristat
bpf/vmtest-bpf-next-VM_Test-28 success Logs for x86_64-llvm-16 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-16
bpf/vmtest-bpf-next-VM_Test-13 success Logs for s390x-gcc / test (test_verifier, false, 360) / test_verifier on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-12 success Logs for s390x-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-11 success Logs for s390x-gcc / test (test_progs, false, 360) / test_progs on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-10 success Logs for s390x-gcc / test (test_maps, false, 360) / test_maps on s390x with gcc

Commit Message

Feng Zhou Nov. 30, 2023, 7:58 a.m. UTC
From: Feng Zhou <zhoufeng.zf@bytedance.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@bytedance.com>
---
 drivers/net/netkit.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

Comments

Nikolay Aleksandrov Nov. 30, 2023, 9:06 a.m. UTC | #1
On 11/30/23 09:58, Feng zhou wrote:
> From: Feng Zhou <zhoufeng.zf@bytedance.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@bytedance.com>
> ---
>   drivers/net/netkit.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 53 insertions(+)
> 

Hi,
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@blackwall.org>

Cheers,
  Nik
Feng Zhou Nov. 30, 2023, 9:24 a.m. UTC | #2
在 2023/11/30 17:06, Nikolay Aleksandrov 写道:
> On 11/30/23 09:58, Feng zhou wrote:
>> From: Feng Zhou <zhoufeng.zf@bytedance.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@bytedance.com>
>> ---
>>   drivers/net/netkit.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 53 insertions(+)
>>
> 
> Hi,
> 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@blackwall.org>
> 
> Cheers,
>   Nik
> 

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.
Daniel Borkmann Nov. 30, 2023, 10:56 a.m. UTC | #3
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@bytedance.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@bytedance.com>
>>> ---
>>>   drivers/net/netkit.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
>>>   1 file changed, 53 insertions(+)
>>>
>>
>> Hi,
>> 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@blackwall.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.

Thanks,
Daniel
Feng Zhou Dec. 1, 2023, 8:42 a.m. UTC | #4
在 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@bytedance.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@bytedance.com>
>>>> ---
>>>>   drivers/net/netkit.c | 53 
>>>> ++++++++++++++++++++++++++++++++++++++++++++
>>>>   1 file changed, 53 insertions(+)
>>>>
>>>
>>> Hi,
>>> 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@blackwall.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.
> 
> Thanks,
> Daniel

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.
Daniel Borkmann Dec. 4, 2023, 3:22 p.m. UTC | #5
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@bytedance.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@bytedance.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@blackwall.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
Feng Zhou Dec. 6, 2023, 6:59 a.m. UTC | #6
在 2023/12/4 23:22, Daniel Borkmann 写道:
> Thanks, so the netkit_get_link_ksettings is optional. 

Yes, netkit_get_link_ksettings really not necessary, I just added it in 
line with veth.

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? 
Daniel Borkmann Dec. 6, 2023, 10:57 a.m. UTC | #7
On 12/6/23 7:59 AM, Feng Zhou wrote:
> 在 2023/12/4 23:22, Daniel Borkmann 写道:
>> Thanks, so the netkit_get_link_ksettings is optional. 
> 
> Yes, netkit_get_link_ksettings really not necessary, I just added it in line with veth.
> 
> 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? 
Feng Zhou Dec. 7, 2023, 9:56 a.m. UTC | #8
在 2023/12/6 18:57, Daniel Borkmann 写道:
> On 12/6/23 7:59 AM, Feng Zhou wrote:
>> 在 2023/12/4 23:22, Daniel Borkmann 写道:
>>> Thanks, so the netkit_get_link_ksettings is optional. 
>>
>> Yes, netkit_get_link_ksettings really not necessary, I just added it 
>> in line with veth.
>>
>> 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? 
diff mbox series

Patch

diff --git a/drivers/net/netkit.c b/drivers/net/netkit.c
index 97bd6705c241..1a5199568a07 100644
--- a/drivers/net/netkit.c
+++ b/drivers/net/netkit.c
@@ -34,6 +34,12 @@  struct netkit_link {
 	u32 location;
 };
 
+static struct {
+	const char string[ETH_GSTRING_LEN];
+} ethtool_stats_keys[] = {
+	{ "peer_ifindex" },
+};
+
 static __always_inline int
 netkit_run(const struct bpf_mprog_entry *entry, struct sk_buff *skb,
 	   enum netkit_action ret)
@@ -211,8 +217,55 @@  static void netkit_get_drvinfo(struct net_device *dev,
 	strscpy(info->driver, DRV_NAME, sizeof(info->driver));
 }
 
+static void netkit_get_strings(struct net_device *dev, u32 stringset, u8 *buf)
+{
+	u8 *p = buf;
+
+	switch (stringset) {
+	case ETH_SS_STATS:
+		memcpy(p, &ethtool_stats_keys, sizeof(ethtool_stats_keys));
+		p += sizeof(ethtool_stats_keys);
+		break;
+	}
+}
+
+static int netkit_get_sset_count(struct net_device *dev, int sset)
+{
+	switch (sset) {
+	case ETH_SS_STATS:
+		return ARRAY_SIZE(ethtool_stats_keys);
+	default:
+		return -EOPNOTSUPP;
+	}
+}
+
+static void netkit_get_ethtool_stats(struct net_device *dev,
+				     struct ethtool_stats *stats, u64 *data)
+{
+	struct netkit *nk = netkit_priv(dev);
+	struct net_device *peer = rtnl_dereference(nk->peer);
+
+	data[0] = peer ? peer->ifindex : 0;
+}
+
+static int netkit_get_link_ksettings(struct net_device *dev,
+				     struct ethtool_link_ksettings *cmd)
+{
+	cmd->base.speed		= SPEED_10000;
+	cmd->base.duplex	= DUPLEX_FULL;
+	cmd->base.port		= PORT_TP;
+	cmd->base.autoneg	= AUTONEG_DISABLE;
+	return 0;
+}
+
 static const struct ethtool_ops netkit_ethtool_ops = {
 	.get_drvinfo		= netkit_get_drvinfo,
+	.get_link		= ethtool_op_get_link,
+	.get_strings		= netkit_get_strings,
+	.get_sset_count		= netkit_get_sset_count,
+	.get_ethtool_stats	= netkit_get_ethtool_stats,
+	.get_link_ksettings	= netkit_get_link_ksettings,
+	.get_ts_info		= ethtool_op_get_ts_info,
 };
 
 static void netkit_setup(struct net_device *dev)