1.. SPDX-License-Identifier: GPL-2.0
2
3============
4Devlink Trap
5============
6
7Background
8==========
9
10Devices capable of offloading the kernel's datapath and perform functions such
11as bridging and routing must also be able to send specific packets to the
12kernel (i.e., the CPU) for processing.
13
14For example, a device acting as a multicast-aware bridge must be able to send
15IGMP membership reports to the kernel for processing by the bridge module.
16Without processing such packets, the bridge module could never populate its
17MDB.
18
19As another example, consider a device acting as router which has received an IP
20packet with a TTL of 1. Upon routing the packet the device must send it to the
21kernel so that it will route it as well and generate an ICMP Time Exceeded
22error datagram. Without letting the kernel route such packets itself, utilities
23such as ``traceroute`` could never work.
24
25The fundamental ability of sending certain packets to the kernel for processing
26is called "packet trapping".
27
28Overview
29========
30
31The ``devlink-trap`` mechanism allows capable device drivers to register their
32supported packet traps with ``devlink`` and report trapped packets to
33``devlink`` for further analysis.
34
35Upon receiving trapped packets, ``devlink`` will perform a per-trap packets and
36bytes accounting and potentially report the packet to user space via a netlink
37event along with all the provided metadata (e.g., trap reason, timestamp, input
38port). This is especially useful for drop traps (see :ref:`Trap-Types`)
39as it allows users to obtain further visibility into packet drops that would
40otherwise be invisible.
41
42The following diagram provides a general overview of ``devlink-trap``::
43
44                                    Netlink event: Packet w/ metadata
45                                                   Or a summary of recent drops
46                                  ^
47                                  |
48         Userspace                |
49        +---------------------------------------------------+
50         Kernel                   |
51                                  |
52                          +-------+--------+
53                          |                |
54                          |  drop_monitor  |
55                          |                |
56                          +-------^--------+
57                                  |
58                                  | Non-control traps
59                                  |
60                             +----+----+
61                             |         |      Kernel's Rx path
62                             | devlink |      (non-drop traps)
63                             |         |
64                             +----^----+      ^
65                                  |           |
66                                  +-----------+
67                                  |
68                          +-------+-------+
69                          |               |
70                          | Device driver |
71                          |               |
72                          +-------^-------+
73         Kernel                   |
74        +---------------------------------------------------+
75         Hardware                 |
76                                  | Trapped packet
77                                  |
78                               +--+---+
79                               |      |
80                               | ASIC |
81                               |      |
82                               +------+
83
84.. _Trap-Types:
85
86Trap Types
87==========
88
89The ``devlink-trap`` mechanism supports the following packet trap types:
90
91  * ``drop``: Trapped packets were dropped by the underlying device. Packets
92    are only processed by ``devlink`` and not injected to the kernel's Rx path.
93    The trap action (see :ref:`Trap-Actions`) can be changed.
94  * ``exception``: Trapped packets were not forwarded as intended by the
95    underlying device due to an exception (e.g., TTL error, missing neighbour
96    entry) and trapped to the control plane for resolution. Packets are
97    processed by ``devlink`` and injected to the kernel's Rx path. Changing the
98    action of such traps is not allowed, as it can easily break the control
99    plane.
100  * ``control``: Trapped packets were trapped by the device because these are
101    control packets required for the correct functioning of the control plane.
102    For example, ARP request and IGMP query packets. Packets are injected to
103    the kernel's Rx path, but not reported to the kernel's drop monitor.
104    Changing the action of such traps is not allowed, as it can easily break
105    the control plane.
106
107.. _Trap-Actions:
108
109Trap Actions
110============
111
112The ``devlink-trap`` mechanism supports the following packet trap actions:
113
114  * ``trap``: The sole copy of the packet is sent to the CPU.
115  * ``drop``: The packet is dropped by the underlying device and a copy is not
116    sent to the CPU.
117  * ``mirror``: The packet is forwarded by the underlying device and a copy is
118    sent to the CPU.
119
120Generic Packet Traps
121====================
122
123Generic packet traps are used to describe traps that trap well-defined packets
124or packets that are trapped due to well-defined conditions (e.g., TTL error).
125Such traps can be shared by multiple device drivers and their description must
126be added to the following table:
127
128.. list-table:: List of Generic Packet Traps
129   :widths: 5 5 90
130
131   * - Name
132     - Type
133     - Description
134   * - ``source_mac_is_multicast``
135     - ``drop``
136     - Traps incoming packets that the device decided to drop because of a
137       multicast source MAC
138   * - ``vlan_tag_mismatch``
139     - ``drop``
140     - Traps incoming packets that the device decided to drop in case of VLAN
141       tag mismatch: The ingress bridge port is not configured with a PVID and
142       the packet is untagged or prio-tagged
143   * - ``ingress_vlan_filter``
144     - ``drop``
145     - Traps incoming packets that the device decided to drop in case they are
146       tagged with a VLAN that is not configured on the ingress bridge port
147   * - ``ingress_spanning_tree_filter``
148     - ``drop``
149     - Traps incoming packets that the device decided to drop in case the STP
150       state of the ingress bridge port is not "forwarding"
151   * - ``port_list_is_empty``
152     - ``drop``
153     - Traps packets that the device decided to drop in case they need to be
154       flooded (e.g., unknown unicast, unregistered multicast) and there are
155       no ports the packets should be flooded to
156   * - ``port_loopback_filter``
157     - ``drop``
158     - Traps packets that the device decided to drop in case after layer 2
159       forwarding the only port from which they should be transmitted through
160       is the port from which they were received
161   * - ``blackhole_route``
162     - ``drop``
163     - Traps packets that the device decided to drop in case they hit a
164       blackhole route
165   * - ``ttl_value_is_too_small``
166     - ``exception``
167     - Traps unicast packets that should be forwarded by the device whose TTL
168       was decremented to 0 or less
169   * - ``tail_drop``
170     - ``drop``
171     - Traps packets that the device decided to drop because they could not be
172       enqueued to a transmission queue which is full
173   * - ``non_ip``
174     - ``drop``
175     - Traps packets that the device decided to drop because they need to
176       undergo a layer 3 lookup, but are not IP or MPLS packets
177   * - ``uc_dip_over_mc_dmac``
178     - ``drop``
179     - Traps packets that the device decided to drop because they need to be
180       routed and they have a unicast destination IP and a multicast destination
181       MAC
182   * - ``dip_is_loopback_address``
183     - ``drop``
184     - Traps packets that the device decided to drop because they need to be
185       routed and their destination IP is the loopback address (i.e., 127.0.0.0/8
186       and ::1/128)
187   * - ``sip_is_mc``
188     - ``drop``
189     - Traps packets that the device decided to drop because they need to be
190       routed and their source IP is multicast (i.e., 224.0.0.0/8 and ff::/8)
191   * - ``sip_is_loopback_address``
192     - ``drop``
193     - Traps packets that the device decided to drop because they need to be
194       routed and their source IP is the loopback address (i.e., 127.0.0.0/8 and ::1/128)
195   * - ``ip_header_corrupted``
196     - ``drop``
197     - Traps packets that the device decided to drop because they need to be
198       routed and their IP header is corrupted: wrong checksum, wrong IP version
199       or too short Internet Header Length (IHL)
200   * - ``ipv4_sip_is_limited_bc``
201     - ``drop``
202     - Traps packets that the device decided to drop because they need to be
203       routed and their source IP is limited broadcast (i.e., 255.255.255.255/32)
204   * - ``ipv6_mc_dip_reserved_scope``
205     - ``drop``
206     - Traps IPv6 packets that the device decided to drop because they need to
207       be routed and their IPv6 multicast destination IP has a reserved scope
208       (i.e., ffx0::/16)
209   * - ``ipv6_mc_dip_interface_local_scope``
210     - ``drop``
211     - Traps IPv6 packets that the device decided to drop because they need to
212       be routed and their IPv6 multicast destination IP has an interface-local scope
213       (i.e., ffx1::/16)
214   * - ``mtu_value_is_too_small``
215     - ``exception``
216     - Traps packets that should have been routed by the device, but were bigger
217       than the MTU of the egress interface
218   * - ``unresolved_neigh``
219     - ``exception``
220     - Traps packets that did not have a matching IP neighbour after routing
221   * - ``mc_reverse_path_forwarding``
222     - ``exception``
223     - Traps multicast IP packets that failed reverse-path forwarding (RPF)
224       check during multicast routing
225   * - ``reject_route``
226     - ``exception``
227     - Traps packets that hit reject routes (i.e., "unreachable", "prohibit")
228   * - ``ipv4_lpm_miss``
229     - ``exception``
230     - Traps unicast IPv4 packets that did not match any route
231   * - ``ipv6_lpm_miss``
232     - ``exception``
233     - Traps unicast IPv6 packets that did not match any route
234   * - ``non_routable_packet``
235     - ``drop``
236     - Traps packets that the device decided to drop because they are not
237       supposed to be routed. For example, IGMP queries can be flooded by the
238       device in layer 2 and reach the router. Such packets should not be
239       routed and instead dropped
240   * - ``decap_error``
241     - ``exception``
242     - Traps NVE and IPinIP packets that the device decided to drop because of
243       failure during decapsulation (e.g., packet being too short, reserved
244       bits set in VXLAN header)
245   * - ``overlay_smac_is_mc``
246     - ``drop``
247     - Traps NVE packets that the device decided to drop because their overlay
248       source MAC is multicast
249   * - ``ingress_flow_action_drop``
250     - ``drop``
251     - Traps packets dropped during processing of ingress flow action drop
252   * - ``egress_flow_action_drop``
253     - ``drop``
254     - Traps packets dropped during processing of egress flow action drop
255
256Driver-specific Packet Traps
257============================
258
259Device drivers can register driver-specific packet traps, but these must be
260clearly documented. Such traps can correspond to device-specific exceptions and
261help debug packet drops caused by these exceptions. The following list includes
262links to the description of driver-specific traps registered by various device
263drivers:
264
265  * :doc:`netdevsim`
266  * :doc:`mlxsw`
267
268.. _Generic-Packet-Trap-Groups:
269
270Generic Packet Trap Groups
271==========================
272
273Generic packet trap groups are used to aggregate logically related packet
274traps. These groups allow the user to batch operations such as setting the trap
275action of all member traps. In addition, ``devlink-trap`` can report aggregated
276per-group packets and bytes statistics, in case per-trap statistics are too
277narrow. The description of these groups must be added to the following table:
278
279.. list-table:: List of Generic Packet Trap Groups
280   :widths: 10 90
281
282   * - Name
283     - Description
284   * - ``l2_drops``
285     - Contains packet traps for packets that were dropped by the device during
286       layer 2 forwarding (i.e., bridge)
287   * - ``l3_drops``
288     - Contains packet traps for packets that were dropped by the device during
289       layer 3 forwarding
290   * - ``l3_exceptions``
291     - Contains packet traps for packets that hit an exception (e.g., TTL
292       error) during layer 3 forwarding
293   * - ``buffer_drops``
294     - Contains packet traps for packets that were dropped by the device due to
295       an enqueue decision
296   * - ``tunnel_drops``
297     - Contains packet traps for packets that were dropped by the device during
298       tunnel encapsulation / decapsulation
299   * - ``acl_drops``
300     - Contains packet traps for packets that were dropped by the device during
301       ACL processing
302
303Packet Trap Policers
304====================
305
306As previously explained, the underlying device can trap certain packets to the
307CPU for processing. In most cases, the underlying device is capable of handling
308packet rates that are several orders of magnitude higher compared to those that
309can be handled by the CPU.
310
311Therefore, in order to prevent the underlying device from overwhelming the CPU,
312devices usually include packet trap policers that are able to police the
313trapped packets to rates that can be handled by the CPU.
314
315The ``devlink-trap`` mechanism allows capable device drivers to register their
316supported packet trap policers with ``devlink``. The device driver can choose
317to associate these policers with supported packet trap groups (see
318:ref:`Generic-Packet-Trap-Groups`) during its initialization, thereby exposing
319its default control plane policy to user space.
320
321Device drivers should allow user space to change the parameters of the policers
322(e.g., rate, burst size) as well as the association between the policers and
323trap groups by implementing the relevant callbacks.
324
325If possible, device drivers should implement a callback that allows user space
326to retrieve the number of packets that were dropped by the policer because its
327configured policy was violated.
328
329Testing
330=======
331
332See ``tools/testing/selftests/drivers/net/netdevsim/devlink_trap.sh`` for a
333test covering the core infrastructure. Test cases should be added for any new
334functionality.
335
336Device drivers should focus their tests on device-specific functionality, such
337as the triggering of supported packet traps.
338