Hi Nik, On 20.02.2020 12:48, Nikolay Aleksandrov wrote:
In light of all the discussions and details that were explained, and as you've noted above, I think more code should be put in kernel space at the very least the performance/latency critical parts would benefit from being executed in the kernel (kind of control/data-plane separation). It seems from the switchdev calls there's a minimal state working set which define the behaviour and can be used to make decisions (similar to STP) in the kernel, but the complex logic how to set them can be executed in user-space meaning that maybe these hw-offload calls can have a simple SW fallback logic based on their current values. I think it is worth considering if this can be achieved before going to full in-kernel implementation of the state machine. Since you intend to hw-offload it then putting in some SW fallback logic would be good when the HW can't offload everything, what you suggest above also sounds good to me and I think you'll have to extend mdb and the multicast code to do it, but IIRC you already have code to do that based on previous discussions.
Sounds good. We will continue working on defining a good control/data-plane separation and only keep the data-plane in the kernel. Also it seems that we agree that the SW fallback of the data-plane should stay in the kernel - we will do that.
As was already suggested you can put the MRP options in the bridge's options and process them from the bridge netlink code, that should simplify your code.
I'm okay with this. The main argument I see for creating a seperate MRP netlink interface instead of extending the bridge, is that MRP is properly not the last bridge protocol we will want to work on. To complete the MRP-2018 implementation, we will also need some CFM support (defined in 802.1Qag or the latest version of 802.1Q). And furhter out we will properly want to implement the full CFM protocol. DLR may also be relevant at some point, and there may be other. My main point is, that at some point we will properly want to do seperate NETLINK interfaces for this. Not sure if that is now or later.
You could also make the port's "mrp_aware" bool into an internal port flag (use net_bridge_port's flags field) so it can be quickly tested and in a hot cache line.
Good point, we will do that. /Allan
