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

From: Menglong Dong
Date: Sun Nov 21 2021 - 05:47:52 EST

On Fri, Nov 19, 2021 at 11:54 AM David Ahern <dsahern@xxxxxxxxx> wrote:
> But it integrates into existing tooling which is a big win.
> Ido gave the references for his work:

I have been thinking about this all day, and I think your words make sense.
Indeed, this can make use of the frame of the 'drop monitor' module of kernel
and the userspace tools of wireshark, dropwatch, etc. And this idea is more
suitable for the aim of 'get the reason for packet drop'. However, the
of this idea is that it can't reuse the drop reason for the 'snmp'

With creating a tracepoint for 'snmp', it can make use of the 'snmp' frame and
the modifications can be easier. However, it's not friendly to the
users, such as
dropwatch, wireshark, etc. And it seems it is a little redundant with what
the tracepoint for 'kfree_sbk()' do. However, I think it's not
difficult to develop
a userspace tool. In fact, I have already write a tool based on BCC, which is
able to make use of 'snmp' tracepoint, such as:

$ sudo ./ --tracer snmp -p udp --addr
begin tracing......
785487.366412: [snmp][udplite_noports]: UDP: ->

And it can monitor packet drop of udp with ip (filter by port,
statistics type are supported too).

And maybe we can integrate tracepoint of 'snmp' into 'drop monitor' with

@Steven What do you think? I think I'm ok with both ideas, as my main target
is to get the reason for the packet drop. As for the idea of
'kfree_skb_with_reason', I'm just a little worry about if we can accept the
modification it brings in.

Menglong Dong

> And the Wireshark dissector is also upstream:
> i.e., the skb is already pushed to userspace for packet analysis. You
> would just be augmenting more metadata along with it and not reinventing
> all of this for just snmp counter based drops.