netdev - Re: [PATCH net-next 0/2] net: snmp: tracepoint support for snmp

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: <20211112093140.373da4f7@gandalf.local.home>
Date:   Fri, 12 Nov 2021 09:31:40 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Menglong Dong <menglong8.dong@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>, mingo@...hat.com,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        dsahern@...nel.org, Menglong Dong <imagedong@...cent.com>,
        LKML <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/2] net: snmp: tracepoint support for snmp

On Fri, 12 Nov 2021 14:42:23 +0800
Menglong Dong <menglong8.dong@...il.com> wrote:

> What's more, I have also realized another version: create tracepoint for every
> statistics type, such as snmp_udp_incsumerrors, snmp_udp_rcvbuferrors, etc.
> This can solve performance issue, as users can enable part of them, which
> may be triggered not frequently. However, too many tracepoint are created, and
> I think it may be not applicable.

If possible, it would be great to have a single tracepoint to handle all
statistics (not sure what data it will be having). Or at least break it
down to one tracepoint per group of statistics.

There's two approaches that can be taken.

1) Create a DECLARE_EVENT_CLASS() template that the group of tracepoints
use, and then create a DEFINE_EVENT() for each one. This will create a
separate trace event for each stat. Most the footprint of a trace event is
in the CLASS portion, so having a single class helps keep the size overhead
down.

2) Just use a single trace event for all stats in a group, but perhaps have
a type field for each to use. That way it can be easy to filter on a set of
stats to trace.

-- Steve