On 15.10.24 15:32, Eric Woudstra wrote:

On 10/15/24 2:16 PM, Felix Fietkau wrote:

quoted

Hi Eric,

On 14.10.24 20:29, Eric Woudstra wrote:

quoted

It would be no problem for me to change the subject and body, if you
think that is better.

The thing is, these patches actually make it possible to set up a fully
functional software fastpath between bridged interfaces. Only after the
software fastpath is set up and functional, it can be offloaded, which
happens to by my personal motivation to write this patch-set.

If the offload flag is set in the flowtable, the software fastpath will
be offloaded. But in this patch-set, there is nothing that changes
anything there, the existing code is used unchanged.

FWIW, a while back, I also wanted to add a software fast path for the
bridge layer to the kernel, also with the intention of using it for
hardware offload. It wasn't accepted back then, because (if I remember
correctly) people didn't want any extra complexity in the network stack
to make the bridge layer faster.

Hello Felix,

I think this patch-set is a clear showcase it is not very complex at
all. The core of making it possible only consists a few patches. Half of
this patch-set involves improvements that also apply to the
forward-fastpath.

It's definitely an interesting approach. How does it deal with devices 
roaming from one bridge port to another? I couldn't find that in the code.

quoted

Because of that, I created this piece of software:
https://github.com/nbd168/bridger

It uses an eBPF TC classifier for discovering flows and handling the
software fast path, and also creates hardware offload rules for flows.
With that, hardware offloading for bridged LAN->WLAN flows is fully
supported on MediaTek hardware with upstream kernels.

- Felix

Thanks, I've seen that already. Nice piece of software, but I'm not
running openwrt. I would like to see a solution implemented in the
kernel, so any operating system can use it.

Makes sense. By the way, bridger can easily be built for non-OpenWrt 
systems too. The only library that's actually needed is libubox - that 
one is small and can be linked in statically. ubus support is fully 
optional and not necessary for standard cases.

- Felix