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