netdev - Re: [RFC PATCH net-next 00/12] Add drop monitor for offloaded data paths

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5a96c7ca-0434-bed4-ef68-84b4f4d7dace@gmail.com>
Date:   Tue, 28 May 2019 18:32:29 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Ido Schimmel <idosch@...sch.org>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, jiri@...lanox.com, mlxsw@...lanox.com,
        dsahern@...il.com, roopa@...ulusnetworks.com,
        nikolay@...ulusnetworks.com, andy@...yhouse.net,
        pablo@...filter.org, jakub.kicinski@...ronome.com,
        pieter.jansenvanvuuren@...ronome.com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com,
        Ido Schimmel <idosch@...lanox.com>,
        Vladimir Oltean <olteanv@...il.com>
Subject: Re: [RFC PATCH net-next 00/12] Add drop monitor for offloaded data
 paths



On 5/28/2019 5:21 AM, Ido Schimmel wrote:
> From: Ido Schimmel <idosch@...lanox.com>
> 
> Users have several ways to debug the kernel and understand why a packet
> was dropped. For example, using "drop monitor" and "perf". Both
> utilities trace kfree_skb(), which is the function called when a packet
> is freed as part of a failure. The information provided by these tools
> is invaluable when trying to understand the cause of a packet loss.
> 
> In recent years, large portions of the kernel data path were offloaded
> to capable devices. Today, it is possible to perform L2 and L3
> forwarding in hardware, as well as tunneling (IP-in-IP and VXLAN).
> Different TC classifiers and actions are also offloaded to capable
> devices, at both ingress and egress.
> 
> However, when the data path is offloaded it is not possible to achieve
> the same level of introspection as tools such "perf" and "drop monitor"
> become irrelevant.
> 
> This patchset aims to solve this by allowing users to monitor packets
> that the underlying device decided to drop along with relevant metadata
> such as the drop reason and ingress port.
> 
> The above is achieved by exposing a fundamental capability of devices
> capable of data path offloading - packet trapping. While the common use
> case for packet trapping is the trapping of packets required for the
> correct functioning of the control plane (e.g., STP, BGP packets),
> packets can also be trapped due to other reasons such as exceptions
> (e.g., TTL error) and drops (e.g., blackhole route).
> 
> Given this ability is not specific to a port, but rather to a device, it
> is exposed using devlink. Each capable driver is expected to register
> its supported packet traps with devlink and report trapped packets to
> devlink as they income. devlink will perform accounting of received
> packets and bytes and will potentially generate an event to user space
> using a new generic netlink multicast group.
> 
> While this patchset is concerned with traps corresponding to dropped
> packets, the interface itself is generic and can be used to expose traps
> corresponding to control packets in the future. The API is vendor
> neutral and similar to the API exposed by SAI which is implemented by
> several vendors already.
> 
> The implementation in this patchset is on top of both mlxsw and
> netdevsim so that people could experiment with the interface and provide
> useful feedback.

This is not particularly useful feedback but I found very little to
comment on because you have covered a lot of ground here.

What you propose is entirely reasonable and seems perfectly adequate to
report the Broadcom tags reason code (RC) (there are only a few reason
codes) within DSA. I don't know if other tagging formats may allow
similar information to be reported.

Looking forward to the non-RFC version!
-- 
Florian