In light of all the discussions and details that were explained, and as you'veSounds good. We will continue working on defining a good control/data-plane separation
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.
As was already suggested you can put the MRP options in the bridge's options andI'm okay with this.
process them from the bridge netlink code, that should simplify your code.
You could also make the port's "mrp_aware" bool into an internal portGood point, we will do that.
flag (use net_bridge_port's flags field) so it can be quickly tested
and in a hot cache line.