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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZAaCINTWbMxH2wGD@lore-desk>
Date:   Tue, 7 Mar 2023 01:15:28 +0100
From:   Lorenzo Bianconi <lorenzo@...nel.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org, davem@...emloft.net,
        pabeni@...hat.com, edumazet@...gle.com, hawk@...nel.org,
        toke@...hat.com, memxor@...il.com, alardam@...il.com,
        lorenzo.bianconi@...hat.com
Subject: Re: [RFC net-next] ethtool: provide XDP information with
 XDP_FEATURES_GET

> 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

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)