On Tue, 18 Feb 2020 13:18:11 +0100 Allan W. Nielsen wrote: > But we should try make sure this also works in a backwards compatible > way with future MRP aware HW, and with existing (and future) SwitchDev > offloaded HW. At the very least we want to make this run on Ocelot, HW > offload the MRC role, but do the MRM in SW (as the HW is not capable of > this). > > If we use the kernel to abstract the MRP forwarding (not the entire > protocol like we did in v1/v2, not just the HW like we did in v3) then > we will have more flxibility to support other HW with a different set of > offload facilities, we can most likely achieve better performance, and > it would be a cleaner design. > > This will mean, that if user-space ask for MRP frame to be generated, > the kernel should make sure it will happen. The kernel can try to > offload this via the switchdev API, or it can do it in kernel-space. > > Again, it will mean putting back some code into kernel space, but I > think it is worth it. FWIW having the guarantee that the kernel can always perform requested service/operation (either thru offload or in SW in kernel space) seems appealing and in line what we've been doing for other offloads. IOW it'd be nice to have a kernel space software fallback for the offloaded operations.
