mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Horatiu Vultur <horatiu.vultur@microchip.com>
To: "Allan W. Nielsen" <allan.nielsen@microchip.com>
Cc: Andrew Lunn <andrew@lunn.ch>, <linux-kernel@vger.kernel.org>,
	<netdev@vger.kernel.org>, <bridge@lists.linux-foundation.org>,
	<jiri@resnulli.us>, <ivecera@redhat.com>, <davem@davemloft.net>,
	<roopa@cumulusnetworks.com>, <nikolay@cumulusnetworks.com>,
	<anirudh.venkataramanan@intel.com>, <olteanv@gmail.com>,
	<jeffrey.t.kirsher@intel.com>, <UNGLinuxDriver@microchip.com>
Subject: Re: [RFC net-next v3 04/10] net: bridge: mrp: Add generic netlink interface to configure MRP
Date: Sun, 26 Jan 2020 14:39:05 +0100	[thread overview]
Message-ID: <20200126133905.wzsvdsdvkc32dd4k@soft-dev3.microsemi.net> (raw)
In-Reply-To: <20200125192854.yi544iu2atvbbwey@lx-anielsen.microsemi.net>

Hi,
The 01/25/2020 20:28, Allan W. Nielsen wrote:
> On 25.01.2020 16:34, Andrew Lunn wrote:
> > 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 thought is more clear to see which commands are used to configure MRP
by adding a new generic netlink than extending the existing 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.
Actually the userspace application doesn't create the bridge and add the
interfaces. It expects that user does this using iproute2 or other
commands.
And once the bridge and interfaces are added then it would just
configure the bridge.

> > 
> > 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.
I have not look yet over this, I will try to have a look ASAP.

> 
> 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

-- 
/Horatiu

  reply	other threads:[~2020-01-26 13:39 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24 16:18 [RFC net-next v3 00/10] net: bridge: mrp: Add support for Media Redundancy Protocol (MRP) Horatiu Vultur
2020-01-24 16:18 ` [RFC net-next v3 01/10] net: bridge: mrp: Expose mrp attributes Horatiu Vultur
2020-01-24 16:18 ` [RFC net-next v3 02/10] net: bridge: mrp: Expose function br_mrp_port_open Horatiu Vultur
2020-01-24 17:37   ` Andrew Lunn
2020-01-25 11:29     ` Horatiu Vultur
2020-01-24 16:18 ` [RFC net-next v3 03/10] net: bridge: mrp: Add MRP interface used by netlink Horatiu Vultur
2020-01-24 17:43   ` Andrew Lunn
2020-01-25 11:37     ` Horatiu Vultur
2020-01-25 15:20       ` Andrew Lunn
2020-01-25 19:16         ` Allan W. Nielsen
2020-01-26 13:28           ` Horatiu Vultur
2020-01-26 15:39             ` Andrew Lunn
2020-02-20  9:08             ` Nikolay Aleksandrov
2020-02-20 13:00               ` Allan W. Nielsen
2020-01-24 16:18 ` [RFC net-next v3 04/10] net: bridge: mrp: Add generic netlink interface to configure MRP Horatiu Vultur
2020-01-25 15:34   ` Andrew Lunn
2020-01-25 19:28     ` Allan W. Nielsen
2020-01-26 13:39       ` Horatiu Vultur [this message]
2020-01-24 16:18 ` [RFC net-next v3 05/10] net: bridge: mrp: Update MRP interface to add switchdev support Horatiu Vultur
2020-01-24 16:18 ` [RFC net-next v3 06/10] net: bridge: mrp: switchdev: Extend switchdev API to offload MRP Horatiu Vultur
2020-01-25 16:35   ` Andrew Lunn
2020-01-26 13:22     ` Horatiu Vultur
2020-01-26 15:59       ` Andrew Lunn
2020-01-27 11:04         ` Allan W. Nielsen
2020-01-27 14:41           ` Jürgen Lambrecht
     [not found]           ` <c5733ddb-a837-b866-54bf-c631baf36c54@televic.com>
2020-01-27 15:06             ` Andrew Lunn
2020-01-28  9:50           ` Jürgen Lambrecht
2020-01-27 11:29         ` Jürgen Lambrecht
2020-01-27 12:27           ` Allan W. Nielsen
2020-01-27 14:39             ` Jürgen Lambrecht
2020-01-28  9:58               ` Allan W. Nielsen
2020-01-24 16:18 ` [RFC net-next v3 07/10] net: bridge: mrp: switchdev: Implement MRP API for switchdev Horatiu Vultur
2020-01-24 16:18 ` [RFC net-next v3 08/10] net: bridge: mrp: Connect MRP api with the switchev API Horatiu Vultur
2020-01-24 16:18 ` [RFC net-next v3 09/10] net: bridge: mrp: Integrate MRP into the bridge Horatiu Vultur
2020-01-25 15:42   ` Andrew Lunn
2020-01-26 12:49     ` Horatiu Vultur
2020-01-25 16:16   ` Andrew Lunn
2020-01-26 13:01     ` Horatiu Vultur
2020-01-26 17:12       ` Andrew Lunn
2020-01-27 10:57         ` Allan W. Nielsen
2020-01-27 13:02           ` Horatiu Vultur
2020-01-27 13:40           ` Andrew Lunn
2020-01-28  9:56             ` Jürgen Lambrecht
2020-01-28 10:17             ` Allan W. Nielsen
2020-01-24 16:18 ` [RFC net-next v3 10/10] net: bridge: mrp: Update Kconfig and Makefile Horatiu Vultur
2020-01-24 20:34 ` [RFC net-next v3 00/10] net: bridge: mrp: Add support for Media Redundancy Protocol (MRP) Allan W. Nielsen
2020-01-24 21:05   ` Vinicius Costa Gomes
2020-01-25  9:44     ` Allan W. Nielsen
2020-01-25 16:23       ` Andrew Lunn
2020-01-25 19:12         ` Allan W. Nielsen
2020-01-25 21:18       ` Vinicius Costa Gomes
2020-01-28 10:35         ` Jürgen Lambrecht
2020-02-18 12:18 ` Allan W. Nielsen
2020-02-18 16:55   ` Jakub Kicinski
2020-02-20 10:48   ` Nikolay Aleksandrov
2020-02-20 12:58     ` Allan W. Nielsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200126133905.wzsvdsdvkc32dd4k@soft-dev3.microsemi.net \
    --to=horatiu.vultur@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=allan.nielsen@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=anirudh.venkataramanan@intel.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=ivecera@redhat.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jiri@resnulli.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@cumulusnetworks.com \
    --cc=olteanv@gmail.com \
    --cc=roopa@cumulusnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®