netdev - Re: [RFC net-next] net: mvneta: align xdp stats naming scheme to mlx5 driver

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: <20200218193111.3b6d6e47@kicinski-fedora-PC1C0HJN>
Date:   Tue, 18 Feb 2020 19:31:11 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     David Miller <davem@...emloft.net>
Cc:     toke@...hat.com, lorenzo@...nel.org, netdev@...r.kernel.org,
        ilias.apalodimas@...aro.org, lorenzo.bianconi@...hat.com,
        andrew@...n.ch, brouer@...hat.com, dsahern@...nel.org,
        bpf@...r.kernel.org
Subject: Re: [RFC net-next] net: mvneta: align xdp stats naming scheme to
 mlx5 driver

On Tue, 18 Feb 2020 15:47:13 -0800 (PST) David Miller wrote:
> Really, mistakes happen and a poorly implemented or inserted fexit
> module should not be a reason to not have access to accurate and
> working statistics for fundamental events.
> 
> I am therefore totally against requiring fexit for this functionality.
> If you want more sophisticated events or custome ones, sure, but not
> for this baseline stuff.
> 
> I do, however, think we need a way to turn off these counter bumps if
> the user wishes to do so for maximum performance.

Yes, this point plus the precedence you mentioned elsewhere are quite
hard to contend with.

In an ideal world I was wondering if we could have the kernel install
the fexit hook, a'la what we do with drop monitor using tracepoints
from within the kernel.

Then have a proper netlink stats group for them, instead of the ethtool
free-form endlessly bikesheddable strings.

But I guess it could be hard to easily recover the source interface
pointer without digging through NAPI instances or such :S