Re: [PATCH v12 nf-next 3/7] netfilter: nf_flow_table_offload: Add nf_flow_rule_bridge()

[Pablo Neira Ayuso <pablo@netfilter.org>]

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?

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