Re: [PATCH RFC v1 net-next 00/12] bridge-fastpath and related improvements

[Felix Fietkau]

On 15.10.24 15:32, Eric Woudstra wrote:
> On 10/15/24 2:16 PM, Felix Fietkau wrote:
> > Hi Eric,
> >
> > On 14.10.24 20:29, Eric Woudstra wrote:
> > > 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.

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