Messages in this thread | | | Date | Sat, 25 Jan 2020 20:28:54 +0100 | From | "Allan W. Nielsen" <> | Subject | Re: [RFC net-next v3 04/10] net: bridge: mrp: Add generic netlink interface to configure MRP |
| |
On 25.01.2020 16:34, Andrew Lunn wrote: >EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > >On Fri, Jan 24, 2020 at 05:18:22PM +0100, Horatiu Vultur wrote: >> Implement the generic netlink interface to configure MRP. The implementation >> will do sanity checks over the attributes and then eventually call the MRP >> interface which eventually will call the switchdev API. >What was your thinking between adding a new generic netlink interface, >and extending the current one? > >I've not looked at your user space code yet, but i assume it has to >make use of both? It needs to create the bridge and add the >interfaces. And then it needs to control the MRP state. > >Allan mentioned you might get around to implementing 802.1CB? Would >that be another generic netlink interface, or would you extend the MRP >interface? Horatiu, if you have given this any thoughts, then please share them.
Here are my thoughts on 802.1CB: If we look at this with the traditional NIC/host POW, then it would be natural to look at the HSR interface as Vinicius suggested, and expose it as a new interface (HSR0). But when looking at how 802.1CB say a bridge should act, and also what the capabilities of the HW are, then it seem more natural to extend the TC system. In HW it is a TCAM classifying the traffic, and it has some actions to either replicate the matched frames, or eliminate the additional copies.
The HW also supports CFM (see [1]), which we need (partly) to complete the MRP implementation with MIM/MIC roles. This is also useful for none MRP users (like ERPS).
This seems like an argument for moving this to the existing netlink interfaces instead of having it as a generic netlink.
[1] https://en.wikipedia.org/wiki/IEEE_802.1ag
/Allan
| |