Re: [RFC net-next] ethtool: provide XDP information with XDP_FEATURES_GET

[Lorenzo Bianconi <lorenzo@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

> On Mon, 6 Mar 2023 19:32:02 +0100 Lorenzo Bianconi wrote:
> > So far the only way to dump the XDP features supported by the NIC is through
> > libbpf running bpf_xdp_query(). I would say it is handy for a sysadmin to
> > examine the XDP NIC capabilities in a similar way he/she is currently doing
> > for the hw offload capabilities. Something like (I have an ethtool user-space
> > patch not posted yet):
> 
> The sysadmin running linux-next or 6.3-rc1, that is? :)

:)

> 
> The plan in my head is to package a tool like tools/net/ynl/cli.py for
> sysadmins to use. Either package it with the specs or expose the specs
> in sysfs like we expose BTF and kheaders.
> 
> I was hoping we can "give it a release or two" to get more experience
> with the specs with just developers using them, 'cause once sysadmins
> are using them we'll have to worry about backward compat.
> 
> But I don't want to hold you back so if the plan above sounds sensible
> to you we can start executing on it, perhaps?
> 
> Alternative would be to teach ethtool or some other tool (new tool?)
> to speak netdev genl, because duplicating the uAPI at the kernel level
> really seems odd :(

ok, I got your point here and I am fine with it. What I would like to improve
with the proposed ethtool support is to help the user to double-check why a
given XDP verdict or functionality is not working properly. A typical example
I think is mlx5 driver where we can enable/disable some XDP capabilities through
ethtool, so the sysadmin can double check that XDP "rx-sg" is actually not
enabled because rq_wq_type is not set to MLX5_WQ_TYPE_CYCLIC.
I think it is fine to use cli.py to solve this issue in order to avoid mixing
uAPI :)

Regards,
Lorenzo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]