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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20230306113225.6a087a4c@kernel.org>
Date:   Mon, 6 Mar 2023 11:32:25 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Lorenzo Bianconi <lorenzo@...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 :(