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:

quoted

Hi Eric,

On Wed, Jul 08, 2026 at 08:36:11PM +0200, Eric Woudstra wrote:

quoted

On 7/8/26 11:48 AM, Pablo Neira Ayuso wrote:

quoted

On Tue, Jul 07, 2026 at 11:10:41AM +0200, Eric Woudstra wrote:

quoted

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/20260317101525.358016-1-ericwouds@gmail.com/

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.

quoted

quoted

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/20260512103347.102746-1-ericwouds@gmail.com/

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/20260317101722.358640-1-ericwouds@gmail.com/

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).