> 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:
signature.asc
Description: PGP signature
