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:

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?

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