Files
linux/include/linux
Jamal Hadi Salim 98b34f3e8c net: Introduce skb tc depth field to track packet loops
Add a 2-bit per-skb tc depth field to track packet loops across the stack.

The previous per-CPU loop counters like MIRRED_NEST_LIMIT
assume a single call stack and lose state in two cases:
1) When a packet is queued and reprocessed later (e.g., egress->ingress
   via backlog), the per-cpu state is gone by the time it is dequeued.
2) With XPS/RPS a packet may arrive on one CPU and be processed on
   another.

A per-skb field solves both by travelling with the packet itself.

The field fits in existing padding, using 2 bits that were previously a
hole:

pahole before(-) and after (+) diff looks like:
   __u8       slow_gro:1;           /*   132: 3  1 */
   __u8       csum_not_inet:1;      /*   132: 4  1 */
   __u8       unreadable:1;         /*   132: 5  1 */
 + __u8       tc_depth:2;           /*   132: 6  1 */

 - /* XXX 2 bits hole, try to pack */
   /* XXX 1 byte hole, try to pack */

   __u16      tc_index;             /*   134     2 */

There used to be a ttl field which was removed as part of tc_verd in commit
aec745e2c5 ("net-tc: remove unused tc_verd fields").  It was already
unused by that time, due to remove earlier in commit c19ae86a51 ("tc: remove
unused redirect ttl").

The first user of this field is netem, which increments tc_depth on
duplicated packets before re-enqueueing them at the root qdisc.  On
re-entry, netem skips duplication for any skb with tc_depth already set,
bounding recursion to a single level regardless of tree topology.

The other user is mirred which increments it on each pass
and limits to depth to MIRRED_DEFER_LIMIT (3).

The new field was called ttl in earlier versions of this patch
but renamed to tc_depth to avoid confusion with IP ttl.

Note (looking at you Sashiko! Dont ignore me and continue bringing this up):
1. Since both mirred and netem utilize the same 2-bit tc_depth field it is
   possible when netem and mirred are used together that netem qdisc to skip
   the duplication step. This is a known trade-off, as a 2-bit field cannot
   independently track both features' recursion depths and it is not considered
   sane to have a setup that addresses both features on at the same time.

2. skb_scrub_packet does not clear tc_depth. This means a packet's loop history
  is preserved even across namespaces. While this might be restrictive for
  some topologies, it is also design intent to provide robustness against loops
  across namespaces.

Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260525122556.973584-2-jhs@mojatatu.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-28 12:26:36 +02:00
..
2026-02-11 13:44:47 +01:00
2025-10-22 07:54:33 +02:00
2026-04-02 15:52:49 +02:00
2026-03-18 15:11:40 +05:30
2026-03-19 23:55:27 +01:00
2026-01-20 19:44:19 -08:00
2026-04-03 16:53:50 -04:00
2026-04-22 12:58:57 -07:00
2025-11-21 11:21:31 +01:00
2026-04-04 08:10:37 -06:00
2026-03-16 13:16:49 +01:00
2026-03-02 17:08:05 -05:00
2025-09-23 11:13:22 +02:00
2026-03-31 19:15:21 +02:00
2026-05-19 17:26:07 +02:00
2025-10-22 07:55:00 +02:00
2025-11-01 12:44:49 -05:00
2025-12-13 20:04:32 +12:00
2026-04-16 07:03:40 -07:00
2026-03-23 13:33:51 -04:00
2026-04-07 17:38:07 +02:00
2026-02-19 09:12:05 +01:00
2025-12-23 11:23:10 -08:00
2026-02-27 16:40:16 +01:00
2025-10-29 18:28:29 -07:00
2025-09-13 17:32:44 -07:00
2026-01-12 16:52:09 +01:00
2025-11-04 12:36:02 +01:00
2026-02-23 13:43:16 -08:00
2026-02-06 07:29:14 -07:00
2025-10-22 07:53:15 +02:00
2025-09-23 11:13:22 +02:00
2026-04-05 13:53:28 -07:00
2026-01-05 16:43:31 +01:00
2026-01-11 06:09:11 -10:00
2026-04-01 10:19:41 +02:00
2026-04-03 16:53:50 -04:00
2026-04-03 16:53:50 -04:00
2026-03-18 09:59:57 +00:00
2026-04-06 11:39:54 +02:00
2026-04-05 13:53:00 -07:00
2025-11-23 12:30:40 +01:00
2026-03-17 15:34:47 +05:30
2025-12-29 11:53:38 +01:00
2026-01-26 20:02:27 -08:00
2025-09-17 15:58:29 -04:00
2026-03-08 11:06:53 +01:00
2025-09-23 13:28:20 -04:00
2025-11-05 23:58:20 +01:00
2025-11-03 17:41:17 +01:00
2026-03-27 07:35:05 -07:00
2026-01-30 11:34:34 +00:00
2026-04-05 13:53:10 -07:00
2026-02-10 11:39:31 +01:00
2026-02-10 11:39:30 +01:00
2026-01-11 06:09:11 -10:00
2026-04-20 11:35:17 -07:00
2025-10-30 18:35:26 +01:00
2025-10-24 21:39:27 +02:00
2025-10-31 10:16:23 +01:00
2026-03-27 17:14:31 -07:00
2026-02-27 16:40:16 +01:00
2026-01-11 06:09:11 -10:00
2026-03-08 11:06:53 +01:00
2025-11-28 09:21:18 -07:00
2026-03-31 07:04:00 -06:00
2026-05-05 16:12:07 +08:00
2026-03-25 20:11:29 +01:00
2026-03-23 12:41:58 +01:00
2026-03-13 08:22:54 +01:00
2026-03-12 15:05:34 +01:00
2026-04-13 08:39:51 -07:00
2026-04-06 09:06:39 +02:00
2025-11-03 17:41:18 +01:00
2026-03-30 16:43:24 -06:00
2026-01-30 18:26:59 -08:00