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

[Eric Woudstra <ericwouds@gmail.com>]

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.

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.

>> 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'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/