From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3FE73CC31F for ; Thu, 16 Jul 2026 09:50:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784195425; cv=none; b=bbGvElU0QO8wy7l3IN7bX5F95pcU4gWI4xJfIJnZmiupn504Tr3q+ZHqHFsLgAqiz9nrUmltqSC747I3HG6x6hJr2OLzd6JRvJOwpTn2X7YWtz9Tv59oIQk+VRZ+ToHKmY9cyNCIf79USLt9b/Ip4IWHvK3EBY+EhRwMtGsKK5Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784195425; c=relaxed/simple; bh=IzGzR/B96zXUnP9cL57RRWHsGIwMJ5kA2saL/V+YkVk=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=esxJSETyAfxc6awOnMg3ciiYKD7QAeFCcI6ZVLlyXRaYsyRFMy4M/xs1DNPmqwHb4f7WhUi5bjH1RLeUL8Ie0CY4Ik2NfgpTSDsx+JEYlLxM2uKgxzRz2IBh/+06kKXFQHJQI9a1RJqT2PuuNB3XGTRQHLGVoCP+Rffk62SXMvc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=mk3zhNIL; arc=none smtp.client-ip=209.85.128.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mk3zhNIL" Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-80dc4a68e4aso52544117b3.0 for ; Thu, 16 Jul 2026 02:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784195422; x=1784800222; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=X0WBqVpTS1/SYj2ne64/eCxZslQII8DxYl3xDAKI+5c=; b=mk3zhNILfOmL8UcQ4HNCMKJxVZgtVvgMjSZ55s1RhCqQw/sfdhMVZNNRD1XYDOI7gX kJALn9QaVDtF4+KYbrfWKP06GgEFjlL87J9O0qTkl+82oA6odJlpx81nUtydWquyQk9J hmEN9X0FKDr8i6J3po5C5Yuu9EdTuhoXxZWZF4ipjyjv3RoEkc8EjhqMgAEJDkdEp7kj MX/JWy2Tdz/OLm+jVD07avjjEHxxvYBjlG4mTrWLfGhhlD87f5Q8s+g52Hfnm+/nK8q9 euMAHE7XFczOUFRF0B6zWBMksKloNs14YckIIRuZurwfRPjqjG6/EXAPJ5fp6i2KgpQu JYNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784195422; x=1784800222; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=X0WBqVpTS1/SYj2ne64/eCxZslQII8DxYl3xDAKI+5c=; b=gfzwDEe87yhyQGNwZN6+9a/ctYeZ3QAq624JBdeUXwhpxcoka2M8p0Cx/c3bkjn2He 6gYqOPjri8MzpxllWS26WVkmNvuXZ7H+nntgZ0rWADHjto6D6PvFPCUPFTnRLlnJSWHX k4v9Ap2mXkAMA7N5tL+dEY5CWG4KU3Bvsdtc793HgANVaecYnH/CU64cQAJ/c0xhnk5R kRAzoL+imQUzgJHnaqX9A6ANXr7InAGe8MAEV4trYETb7Uze9jsb4Qnu6S070nANgVfh ZBsbsZ781CogU/cBJV8Ml4vr7s91pI/T3eLklLgLpet7uN+ondcdM/d0uME7bYd4ZqVp gPew== X-Forwarded-Encrypted: i=1; AHgh+Rq8SHiDBFLKahA83CdFUhF3A+++JCH55NPYT+S3TVpBeWigorkXKSi4wYYHxZbFCtp444qJhxelxfydB6Y=@vger.kernel.org X-Gm-Message-State: AOJu0YxrIPFthmh7IfHahHXao3/QwSM/OPdb2oB2voGVmUHhUoGXWLK7 8X0GazE/Vvzvc4pt0KSsZzWtFXtqCgdg7mjLlYwIv1W7+udxOl5SdnNY X-Gm-Gg: AfdE7cnEAwAi4uE8AK9gssOzzZKCQ0r5hkst4NEpGPLkO2OOEDYvGiv7b3GY4sumQQ8 gzx4x+Onx/+0bdbhzn7Dnu3aDXeFif1maZDxGaXtnsp9iCA3rrb3CtqnbhOlGt7hJLTkc4ReUKv 23F3eKf01L0rAKG/k7ingbt6uJ7jrEe0UpyhsS/VsZvDFoR6iGSbIuUAf1hhzG44VCryJ7MbqbC M4E0zN1hIeXdFf9u1tgfg/f7rIXepaQkVsoI9+5qJ/2u1lfoe3Zj0U82QVcDGrdQy+Op42HOsAa RKQs2zaVrMzsh6eNEwpUxp7zmGOzY+8gyXqBL3c1bHs1NzNF3t+oOpyOpzrqdvuZH6sb+FS2iUv 9XmqPEcIr7FQd3qvhHzASqa9LjU86JKPxEXIkbKuhQTP3tk1aTrSyBWiy+do0lEJEvZmSydLcQV THyMlyfOdTtuWedy8YHwfprLRqDNI3kbeiypjo1qR5/PyqjGoG7d+Tsw8= X-Received: by 2002:a05:690c:9519:b0:81e:d8ec:d86d with SMTP id 00721157ae682-81ed8ecdb1emr28639267b3.2.1784195422483; Thu, 16 Jul 2026 02:50:22 -0700 (PDT) Received: from gmail.com (172.235.85.34.bc.googleusercontent.com. [34.85.235.172]) by smtp.gmail.com with ESMTPSA id 00721157ae682-81e6c1a44d6sm192511277b3.31.2026.07.16.02.50.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jul 2026 02:50:21 -0700 (PDT) Date: Thu, 16 Jul 2026 05:50:21 -0400 From: Willem de Bruijn To: Dave Seddon , netdev@vger.kernel.org Cc: "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Stanislav Fomichev , Tom Herbert , Willem de Bruijn , linux-kernel@vger.kernel.org, Dave Seddon Message-ID: In-Reply-To: <20260716004357.3652679-1-dave.seddon.ca@gmail.com> References: <20260716004357.3652679-1-dave.seddon.ca@gmail.com> Subject: Re: [PATCH net-next v1 00/11] net: flow_dissector: opt-in byte-identical fast paths for common shapes Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dave Seddon wrote: > G'day, > > __skb_flow_dissect() parses packet headers with a generic protocol-graph > parser. The graph walk is what makes the dissector so flexible, but most > machines spend that flexibility on the same traffic all day long: plain > eth + IPv4/IPv6 + TCP/UDP, perhaps with a VLAN tag or a tunnel header in > front. The intuition behind this series is that the common shapes can be > dissected by straight-line code instead, without giving up the graph > walk for everything else. > > Concretely: the series adds an opt-in, static-branch-gated fast path per > packet shape, covering the common cases and the IP-in-IP/GRE > encapsulations. Each shape has its own gate under > /proc/sys/net/flow_dissector/, every gate is disabled by default, and > when a gate is off its added cost is one not-taken branch per dissect. > The gates are manual in this series; a follow-up RFC will propose an > optional auto mode that flips them from the measured traffic mix (via > the patch-8 counters), so nobody has to hand-tune seven knobs > (eth_ip, vlan, qinq, pppoe, mpls, ipip, gre). Nothing > here depends on it -- it is where this is heading, not a prerequisite. > Relationship to the BPF flow dissector > ====================================== > The fast path is invoked strictly after the netns BPF flow dissector > hook in __skb_flow_dissect(): if a program is attached and returns any > verdict other than BPF_FLOW_DISSECTOR_CONTINUE, the function returns > before flow_dissect_fast() is reached. Attached BPF dissectors therefore > always take precedence, and a system running one sees bit-for-bit > unchanged behaviour from this series (patch 1 additionally makes its > program lookup cheaper for everyone else). Dissects fully handled by a > BPF program are deliberately not counted in > /proc/net/flow_dissector_stats (patch 8). > > The gates are global (a static key patches code shared by every netns); > per-netns dissector policy already has a mechanism -- the netns BPF > flow dissector -- and it keeps full precedence here. This series adds a lot of code: +2500 LoC. If you want a linear fast path, the BPF dissector offers that. I don't think the purported benefit justifies the significant new code, I'm afraid. The code is duplicative of existing paths, so there may be additional maintenance cost keeping the two consistent. And which paths justify a fast paths and which do not is highly subjective. Why is GRE included, for instance?