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