On 10/15/24 9:44 PM, Felix Fietkau wrote: > 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. It is handled in the same manner when dealing with the forward-fastpath, with the aid of conntrack. If roaming is problematic, then it would be for both the forward-fastpath and the bridge-fastpath. I have a topic on the banana-pi forum about this patch-set, so I think long discussions about additional details we could have there, keeping the mailing list more clean. >>> 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
