[PATCH v2 0/5] netfilter: nf_flow_table_path: L2 bridge offload

[Pablo Neira Ayuso]

Hi,

On Tue, Jun 30, 2026 at 08:57:30AM +0200, Daniel Pawlik wrote:
> This series adds L2 bridge offload support to nft_flow_offload, allowing
> bridged IPv4/IPv6 flows to be accelerated by the flowtable fast path
> without requiring L3 routing.
> 
> Background
> ----------
> Hardware flow offload engines (e.g. MediaTek PPE) can accelerate bridged
> traffic but require that nft_flow_offload detect and handle bridged flows
> differently from routed ones: no routing table lookup, MAC addresses from
> the Ethernet header, and VLAN context pre-populated from the bridge port.
> 
> v2: Fix missing Returns: tags in kernel-doc comments for the three new
>     bridge helpers (br_fdb_has_forwarding_entry_rcu,
>     br_vlan_get_offload_info_rcu, br_vlan_is_enabled_rcu).
> 
> Patches
> -------
> 1/5  net: export __dev_fill_forward_path
>      Refactors dev_fill_forward_path() to expose __dev_fill_forward_path()
>      which accepts a caller-supplied net_device_path_ctx, needed to
>      pre-populate VLAN state before the forward path walk.
> 
> 2/5  net: bridge: add flow offload helpers
>      Adds br_fdb_has_forwarding_entry_rcu(), br_vlan_get_offload_info_rcu()
>      and br_vlan_is_enabled_rcu() to expose bridge state to nft_flow_offload
>      without requiring inclusion of net/bridge/br_private.h.
> 
> 3/5  netfilter: nf_flow_table_path: add L2 bridge offload
>      Core of the series. Adds nft_flow_offload_is_bridging() detection,
>      nft_flow_route_bridging() which avoids nf_route() (fails for
>      bridged-only subnets), MAC/VLAN pre-population for bridged flows,
>      and a dst leak fix. nft_flow_route() becomes a thin dispatcher.
> 
> 4/5  netfilter: nf_flow_table_path: handle DEV_PATH_MTK_WDMA in path info
>      Fixes zero-source-MAC in PPE entries when a bridged flow traverses
>      MT7996/MT7915 WiFi WDMA hardware.
> 
> 5/5  netfilter: nf_flow_table_path: add VLAN passthrough support
>      Records VLAN encap info for passthrough-mode bridge ports so hardware
>      offload entries include the correct VLAN tag.
> 
> Rebase note
> -----------
> Originally developed against OpenWrt pending-6.18 patches by Ryan Chen
> <rchen14b at gmail.com> and Bo-Cun Chen <bc-bocun.chen at mediatek.com>.
> Rebased to current upstream: path discovery infrastructure moved to
> nf_flow_table_path.c in commit 93d7a7ed0734 ("netfilter: flowtable: move
> path discovery infrastructure to its own file"), so all netfilter changes
> now land in that file rather than nft_flow_offload.c.
> 
> How to enable bridge offload
> -----------------------------
> 1. Load kmod-br-netfilter so that bridged IP traffic traverses the
>    netfilter forward chain.
> 
> 2. Enable netfilter hooks on the bridge:
>      echo 1 > /sys/class/net/<br>/bridge/nf_call_iptables
>      echo 1 > /sys/class/net/<br>/bridge/nf_call_ip6tables

This requires br_netfilter which is a no go.

Sorry, but we should really target at the native nf_conntrack_bridge
support.

> 3. Register bridge member interfaces in the nft flowtable:
>      table inet filter {
>          flowtable f {
>              hook ingress priority filter
>              devices = { eth0, wlan0 }
>          }
>          chain forward {
>              type filter hook forward priority filter
>              meta l4proto { tcp, udp } flow add @f
>          }
>      }

Yes, but br_netfilter makes no sense for nftables.

br_netfilter was made to fill gap at the time ebtables was lagging a
lot behind iptables in terms of features. And getting ebtables on pair
with iptables in functionality was not feasible either, because it
required many new extensions that were specific of the bridge family,
which probably was not a big deal, but it also required to get
the ebtables command line tool on pair with iptables userspace, which
has received more development attention/effort that the bridge tool.

All of this does not stand true anymore with nftables, where the
bridge family capabilities are at pair with the inet families.

I am looking now at the native flowtable bridge support, I will get
back to you with updates.