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

From: David Ahern
Date: Mon Nov 22 2021 - 11:42:10 EST

On 11/21/21 3:47 AM, Menglong Dong wrote:
> 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
> shortcoming
> of this idea is that it can't reuse the drop reason for the 'snmp'
> frame.
> 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

you don't need to add 'snmp' to drop monitor; you only need to add
NET_DM_ATTR_ to the existing one.

This is the end of __udp4_lib_rcv:


you want to add a tracepoint at both UDP_INC_STATS making 3 consecutive
lines that give access to the dropped skb with only slight variations in

The last one, kfree_skb, gives you the address of the drop + the skb for
analysis. Just add the metadata to the existing drop monitor.