Hi, On Fri, Jul 10, 2026 at 05:16:44PM +0200, Eric Woudstra wrote: > > > On 7/10/26 11:26 AM, Pablo Neira Ayuso wrote: > > Hi Eric, > > > > On Wed, Jul 08, 2026 at 08:36:11PM +0200, Eric Woudstra wrote: > >> On 7/8/26 11:48 AM, Pablo Neira Ayuso wrote: > >>> On Tue, Jul 07, 2026 at 11:10:41AM +0200, Eric Woudstra wrote: > >>>> Add nf_flow_rule_bridge(). > >>>> > >>>> It only calls the common rule and adds the redirect. > >>> > >>> I decided to use the new _unsupp() function, so we don't pretend > >>> bridge hw offload is already supported. We will need a driver before > >>> we can add this, this stub does not provide much. I guess your goal > >>> was just to avoid a crash here. > >> > >> No, I am already using hw_offload between bridged interfaces > >> on the mt7986 succesfully for almost 2 years. > >> It works dsa-port to direct interface (lan1 to eth1 on Bananapi R3) and > >> between direct interfaces (eth0 to eth1 on Bananapi-R3-mini) > > > > Do you utilize the existing mt7986 driver in-tree without changes to > > achive this hardware offload? Or you have still have out-of-tree > > patches that need to be merged to achive this? > > I do not change anything about the mediatek drivers to achieve hardware > offload. No patch needed to fix hardware offload.
Good. I would suggest you follow up to replace my _unsupp() function with the .action function once the initial flowtable bridge support gets merged upstream, explaining what drivers you have tested, it would be nice for the record. But hold on a bit until initial steps are made to upstream the initial infrastructure, please. > However I do have a small fix for the offloading towards the mediatek > wifi interface. This is a fix for the software fastpath already. > Also with hardware offload to wifi interface, once the software fastpath > is setup correctly (needs this patch), then the hardware offload functions > correctly without any further patch. See patch: > > https://patchwork.ozlabs.org/project/netfilter-devel/patch/[email protected]/ > > It is not reviewed yet. I'm reading the commit description, info.indev = NULL is not returned anymore, a rebase, review and re-post once initial bridge supports gets added would be good. This is to build a fast path between the bridge ports and wifi through the SoC. > >> It can also be tested with my bridge_fastpath.sh selftest script. > >> This script uses veth-device pairs to test the software fastpath. > >> It can also use 2 real interfaces interconnected in a loop of copper, > >> when chosen with commandline arguments. Then it tests software- and > >> hardware-fastpath. It also tests many different scenarios. > >> > >> So this is why I've added it, as it is already functional. If a software > >> fastpath is setup correctly, the hardware fastpath is also functional. > > > > Thanks for explaining. > > > > I am targetting at a minimal subset of the flowtable bridge support at > > this stage. There is a need to make progress with the > > nf_conntrack_bridge counterpart before the flowtable bridge can get > > more features (namely, bridge vlan filtering support). > > I did send a newer version of my patch-set for nf_conntrack_bridge, > last version also adding support to defrag/refrag. See: > > https://patchwork.ozlabs.org/project/netfilter-devel/cover/[email protected]/ I'm taking a look to the nf_conntrack_bridge side. > I've added testcases for defrag/refrag to the bridge_fastpath.sh selftest > script (v5), so I know it is functional. > > For proper vlan filtering support, I do also believe you will need to > introduce DEV_PATH_BR_VLAN_KEEP_HW, or do something similar. See: > > https://patchwork.ozlabs.org/project/netfilter-devel/patch/[email protected]/ OK, this will be useful once bridge vlan filtering gets supported. The existing proposal that extends the bridge fill_forward_path relies uniquely on one single bridge port to decide whether keep, untag or tag? Should this look for the pvid at the ingress bridge port (tag or keep vlan), then look at the egress bridge port (for untagging).
