Re: [RFC PATCH net-next 00/12] drop_monitor: Capture dropped packets and metadata

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Ido Schimmel <idosch@idosch.org> writes:

> From: Ido Schimmel <idosch@mellanox.com>
>
> So far drop monitor supported only one mode of operation in which a
> summary of recent packet drops is periodically sent to user space as a
> netlink event. The event only includes the drop location (program
> counter) and number of drops in the last interval.
>
> While this mode of operation allows one to understand if the system is
> dropping packets, it is not sufficient if a more detailed analysis is
> required. Both the packet itself and related metadata are missing.
>
> This patchset extends drop monitor with another mode of operation where
> the packet - potentially truncated - and metadata (e.g., drop location,
> timestamp, netdev) are sent to user space as a netlink event. Thanks to
> the extensible nature of netlink, more metadata can be added in the
> future.
>
> To avoid performing expensive operations in the context in which
> kfree_skb() is called, the dropped skbs are cloned and queued on per-CPU
> skb drop list. The list is then processed in process context (using a
> workqueue), where the netlink messages are allocated, prepared and
> finally sent to user space.
>
> As a follow-up, I plan to integrate drop monitor with devlink and allow
> the latter to call into drop monitor to report hardware drops. In the
> future, XDP drops can be added as well, thereby making drop monitor the
> go-to netlink channel for diagnosing all packet drops.

I like this!

Is there a mechanism for the user to filter the packets before they are
sent to userspace? A bpf filter would be the obvious choice I guess...

For integrating with XDP the trick would be to find a way to do it that
doesn't incur any overhead when it's not enabled. Are you envisioning
that this would be enabled separately for the different "modes" (kernel,
hardware, XDP, etc)?

-Toke