Mon, Jul 22, 2019 at 08:31:22PM CEST, ido...@idosch.org wrote: >From: Ido Schimmel <ido...@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. > >Example usage with patched dropwatch [1] can be found here [2]. Example >dissection of drop monitor netlink events with patched wireshark [3] can >be found here [4]. I will submit both changes upstream after the kernel >changes are accepted. > >Patches #1-#6 are just cleanups with no functional changes intended. > >Patches #7-#8 perform small refactoring before the actual changes are >introduced in the last four patches.
In general, this looks very good to me. Thanks!
