Hi Florian, Pablo, I'll leave it up to you - if `br_netfilter` isn't the right approach in this case, then we can drop that series.
Before your reply, I wasn't familiar with Eric Woudstra's "bridge-fastpath" series - thanks for the tip. I'll take a look at it and try to build on those patches. Thanks, and best regards, Dan wt., 30 cze 2026 o 10:45 Pablo Neira Ayuso <[email protected]> napisał(a): > > 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 > > <[email protected]> and Bo-Cun Chen <[email protected]>. > > 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.
