[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200125192854.yi544iu2atvbbwey@lx-anielsen.microsemi.net>
Date: Sat, 25 Jan 2020 20:28:54 +0100
From: "Allan W. Nielsen" <allan.nielsen@...rochip.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Horatiu Vultur <horatiu.vultur@...rochip.com>,
<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
<bridge@...ts.linux-foundation.org>, <jiri@...nulli.us>,
<ivecera@...hat.com>, <davem@...emloft.net>,
<roopa@...ulusnetworks.com>, <nikolay@...ulusnetworks.com>,
<anirudh.venkataramanan@...el.com>, <olteanv@...il.com>,
<jeffrey.t.kirsher@...el.com>, <UNGLinuxDriver@...rochip.com>
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
Powered by blists - more mailing lists