netdev.vger.kernel.org archive mirror
 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 03/10] net: bridge: mrp: Add MRP interface used by netlink
Date: Sun, 26 Jan 2020 14:28:43 +0100	[thread overview]
Message-ID: <20200126132843.k4rzn7vfti7lqvos@soft-dev3.microsemi.net> (raw)
In-Reply-To: <20200125191612.5dlzlvb7g2bucqna@lx-anielsen.microsemi.net>

The 01/25/2020 20:16, Allan W. Nielsen wrote:
> On 25.01.2020 16:20, Andrew Lunn wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > On Sat, Jan 25, 2020 at 12:37:26PM +0100, Horatiu Vultur wrote:
> > > The 01/24/2020 18:43, Andrew Lunn wrote:
> > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > > >
> > > > > br_mrp_flush - will flush the FDB.
> > > >
> > > > How does this differ from a normal bridge flush? I assume there is a
> > > > way for user space to flush the bridge FDB.
> > > 
> > > Hi,
> > > 
> > > If I seen corectly the normal bridge flush will clear the entire FDB for
> > > all the ports of the bridge. In this case it is require to clear FDB
> > > entries only for the ring ports.
> > 
> > Maybe it would be better to extend the current bridge netlink call to
> > be able to pass an optional interface to be flushed?  I'm not sure it
> > is a good idea to have two APIs doing very similar things.
> I agree.
I would look over this.

> 
> And when looking at this again, I start to think that we should have
> extended the existing netlink interface with new commands, instead of
> adding a generic netlink.
We could do also that. The main reason why I have added a new generic
netlink was that I thought it would be clearer what commands are for MRP
configuration. But if you think that we should go forward by extending
existing netlink interface, that is perfectly fine for me.

> 
> /Allan
> 

-- 
/Horatiu

  reply	other threads:[~2020-01-26 13:28 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 [this message]
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
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=20200126132843.k4rzn7vfti7lqvos@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;
as well as URLs for NNTP newsgroup(s).