[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190724151540.GE2225@nanopsycho>
Date: Wed, 24 Jul 2019 17:15:40 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Ido Schimmel <idosch@...sch.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, nhorman@...driver.com,
dsahern@...il.com, roopa@...ulusnetworks.com,
nikolay@...ulusnetworks.com, jakub.kicinski@...ronome.com,
toke@...hat.com, andy@...yhouse.net, f.fainelli@...il.com,
andrew@...n.ch, vivien.didelot@...il.com, mlxsw@...lanox.com,
Ido Schimmel <idosch@...lanox.com>
Subject: Re: [RFC PATCH net-next 00/12] drop_monitor: Capture dropped packets
and metadata
Mon, Jul 22, 2019 at 08:31:22PM CEST, idosch@...sch.org wrote:
>From: Ido Schimmel <idosch@...lanox.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!
Powered by blists - more mailing lists