On 5/28/2019 5:21 AM, Ido Schimmel wrote:
> From: Ido Schimmel <[email protected]>
>
> 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
