Add NEXT verdict for BPF program chaining by qdeslandes · Pull Request #474 · facebook/bpfilter

qdeslandes · 2026-03-13T20:04:42Z

Add a new BF_VERDICT_NEXT terminal verdict, meaning "pass to the next BPF program.".

On TC, this maps to TCX_NEXT which defers packet processing to the next program in the TCX link, distinct from TCX_PASS which accepts the packet and bypasses subsequent programs.
For NF, XDP, and cgroup_skb, NEXT maps to the same return code as ACCEPT since these hooks don't distinguish between the two.

src/libbpfilter/include/bpfilter/verdict.h

src/bpfilter/cgen/cgroup_skb.c

tests/e2e/rules/next_tc.sh

github-actions · 2026-03-13T20:14:21Z

tests/e2e/CMakeLists.txt

src/libbpfilter/chain.c

src/libbpfilter/include/bpfilter/verdict.h

tests/e2e/rules/next_tc.sh

doc/usage/bfcli.rst

The get_verdict flavor callback returns the BPF return code directly, using negative values for errors. This will conflict with TCX_NEXT (-1) when adding the NEXT verdict. Switch to an output parameter so that the return value is reserved for error reporting. No functional change.

Add a new terminal verdict BF_VERDICT_NEXT that means "pass to next BPF program." For TC this will map to TCX_NEXT; for other flavors it maps to the same return code as ACCEPT. Replace the _BF_TERMINAL_VERDICT_MAX sentinel with an explicit bf_verdict_is_valid_policy() function, which is easier to reason about and extend. Update chain creation and the CLI parser to use it. Add NEXT to the lexer so it is recognised as a verdict token.

Map BF_VERDICT_NEXT to flavor-specific return codes: - TC: TCX_NEXT (-1), distinct from TCX_PASS - Netfilter: NF_ACCEPT (same as ACCEPT) - XDP: XDP_PASS (same as ACCEPT) - cgroup_skb: 1 (same as ACCEPT) Handle NEXT as a terminal verdict in rule codegen, alongside ACCEPT and DROP.

Update bfcli usage documentation to describe the NEXT verdict for both chain policies and rule verdicts. Note that NEXT has distinct behavior only for TC hooks (TCX_NEXT); for NF, XDP, and cgroup_skb it maps to the same return code as ACCEPT.

jordalgo · 2026-03-17T23:58:29Z

doc/usage/bfcli.rst

+
+    - ``ACCEPT``: forward the packet to the kernel.
+    - ``DROP``: discard the packet.
+    - ``NEXT``: pass the packet to the next BPF program. For TC hooks, this maps to ``TCX_NEXT``, deferring the decision to the next program in the TCX link. For NF, XDP, and cgroup_skb hooks, ``NEXT`` behaves identically to ``ACCEPT`` since these hooks do not distinguish between "accept" and "pass to next program."


Do you want to call out that if there are no other BPF programs then this acts like ACCEPT?

jordalgo · 2026-03-18T00:00:39Z

doc/usage/bfcli.rst

  - ``counter``: optional literal. If set, the filter will counter the number of packets and bytes matched by the rule.
  - ``mark``: optional, ``$MARK`` must be a valid decimal or hexadecimal 32-bits value. If set, write the packet's marker value. This marker can be used later on in a rule (see ``meta.mark``) or with a TC filter.
-  - ``$VERDICT``: action taken by the rule if the packet is matched against **all** the criteria: either ``ACCEPT``, ``DROP``, ``CONTINUE``, or ``REDIRECT``.
+  - ``$VERDICT``: action taken by the rule if the packet is matched against **all** the criteria: either ``ACCEPT``, ``DROP``, ``CONTINUE``, ``NEXT``, or ``REDIRECT``.


nit:

Suggested change

- ``$VERDICT``: action taken by the rule if the packet is matched against **all** the criteria: either ``ACCEPT``, ``DROP``, ``CONTINUE``, ``NEXT``, or ``REDIRECT``.

- ``$VERDICT``: action taken by the rule if the packet is matched against **all** the criteria. One of the following:

Not sure why you want to list the verdicts and then list them again with descriptions

jordalgo · 2026-03-18T00:03:40Z

doc/usage/bfcli.rst


+.. note::
+
+    ``NEXT`` has distinct behavior only for TC hooks (``BF_HOOK_TC_INGRESS``, ``BF_HOOK_TC_EGRESS``), where it maps to ``TCX_NEXT`` and defers to the next BPF program in the TCX link. For all other hooks (Netfilter, XDP, cgroup_skb), ``NEXT`` produces the same return code as ``ACCEPT``.


nit

Suggested change

``NEXT`` has distinct behavior only for TC hooks (``BF_HOOK_TC_INGRESS``, ``BF_HOOK_TC_EGRESS``), where it maps to ``TCX_NEXT`` and defers to the next BPF program in the TCX link. For all other hooks (Netfilter, XDP, cgroup_skb), ``NEXT`` produces the same return code as ``ACCEPT``.

``NEXT`` has distinct behavior only for TC hooks (``BF_HOOK_TC_INGRESS``, ``BF_HOOK_TC_EGRESS``), where it maps to ``TCX_NEXT`` and defers to the next BPF program in the TCX link. For all other hooks (Netfilter, XDP, cgroup_skb), ``NEXT`` is equivalent to ``ACCEPT``.

jordalgo · 2026-03-18T00:06:35Z

src/bpfilter/cgen/cgroup_skb.c

+ * @return 0 on success, or a negative errno value on failure.
 */
-static int _bf_cgroup_skb_get_verdict(enum bf_verdict verdict)
+static int _bf_cgroup_skb_get_verdict(enum bf_verdict verdict, int *ret_code)


Since these are internal APIs, I think you could have kept the same return mechanism without adding the ret_code param and just check for -ENOTSUP on the caller. Obviously a matter of style but less changes.

jordalgo · 2026-03-18T00:11:22Z

src/libbpfilter/verdict.c

+    case BF_VERDICT_DROP:
+    case BF_VERDICT_NEXT:
+        return true;
+    default:


As mentioned on another diff, it would be nice if this is an exhaustive check instead of using default

Integrates Claude Code as an AI assistant for reviewing pull requests. This is experimental and relies on a subscription provided by Meta. Example of what this review looks like: facebook/bpfilter#474 (comment) Signed-off-by: Jordan Rome <linux@jordanrome.com>

meta-cla bot added the cla signed label Mar 13, 2026