All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Nikolay Aleksandrov <nikolay@nvidia.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	bridge@lists.linux-foundation.org,
	Roopa Prabhu <roopa@nvidia.com>, Jiri Pirko <jiri@resnulli.us>,
	Ido Schimmel <idosch@idosch.org>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	UNGLinuxDriver@microchip.com, Vadym Kochan <vkochan@marvell.com>,
	Taras Chornyi <tchornyi@marvell.com>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Ioana Ciornei <ioana.ciornei@nxp.com>,
	Ivan Vecera <ivecera@redhat.com>,
	linux-omap@vger.kernel.org
Subject: Re: [PATCH net-next 2/9] net: bridge: offload initial and final port flags through switchdev
Date: Mon, 8 Feb 2021 13:45:11 +0200	[thread overview]
Message-ID: <20210208114511.xtzma5byrdnr5s7r@skbuf> (raw)
In-Reply-To: <95dede91-56aa-1852-8fbf-71d446fa7ede@nvidia.com>

On Mon, Feb 08, 2021 at 01:37:03PM +0200, Nikolay Aleksandrov wrote:
> Hi Vladimir,
> I think this patch potentially breaks some use cases. There are a few problems, I'll
> start with the more serious one: before the ports would have a set of flags that were
> always set when joining, now due to how nbp_flags_change() handles flag setting some might
> not be set which would immediately change behaviour w.r.t software fwding. I'll use your
> example of BR_BCAST_FLOOD: a lot of drivers will return an error for it and any broadcast
> towards these ports will be dropped, we have mixed environments with software ports that
> sometimes have traffic (e.g. decapped ARP requests) software forwarded which will stop working.

Yes, you're right. The only solution I can think of is to add a "bool ignore_errors"
to nbp_flags_change, set to true from new_nbp and del_nbp, and to false from the
netlink code.

> The other lesser issue is with the style below, I mean these three calls for each flag are
> just ugly and look weird as you've also noted, since these APIs are internal can we do better?

Doing better would mean allowing nbp_flags_change() to have a bit mask with
potentially more brport flags set, and to call br_switchdev_set_port_flag in
a for_each_set_bit() loop?

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <olteanv@gmail.com>
To: Nikolay Aleksandrov <nikolay@nvidia.com>
Cc: Ivan Vecera <ivecera@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>, Vadym Kochan <vkochan@marvell.com>,
	linux-omap@vger.kernel.org, netdev@vger.kernel.org,
	bridge@lists.linux-foundation.org,
	Ioana Ciornei <ioana.ciornei@nxp.com>,
	linux-kernel@vger.kernel.org,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Taras Chornyi <tchornyi@marvell.com>,
	Ido Schimmel <idosch@idosch.org>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Roopa Prabhu <roopa@nvidia.com>, Jakub Kicinski <kuba@kernel.org>,
	UNGLinuxDriver@microchip.com,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Bridge] [PATCH net-next 2/9] net: bridge: offload initial and final port flags through switchdev
Date: Mon, 8 Feb 2021 13:45:11 +0200	[thread overview]
Message-ID: <20210208114511.xtzma5byrdnr5s7r@skbuf> (raw)
In-Reply-To: <95dede91-56aa-1852-8fbf-71d446fa7ede@nvidia.com>

On Mon, Feb 08, 2021 at 01:37:03PM +0200, Nikolay Aleksandrov wrote:
> Hi Vladimir,
> I think this patch potentially breaks some use cases. There are a few problems, I'll
> start with the more serious one: before the ports would have a set of flags that were
> always set when joining, now due to how nbp_flags_change() handles flag setting some might
> not be set which would immediately change behaviour w.r.t software fwding. I'll use your
> example of BR_BCAST_FLOOD: a lot of drivers will return an error for it and any broadcast
> towards these ports will be dropped, we have mixed environments with software ports that
> sometimes have traffic (e.g. decapped ARP requests) software forwarded which will stop working.

Yes, you're right. The only solution I can think of is to add a "bool ignore_errors"
to nbp_flags_change, set to true from new_nbp and del_nbp, and to false from the
netlink code.

> The other lesser issue is with the style below, I mean these three calls for each flag are
> just ugly and look weird as you've also noted, since these APIs are internal can we do better?

Doing better would mean allowing nbp_flags_change() to have a bit mask with
potentially more brport flags set, and to call br_switchdev_set_port_flag in
a for_each_set_bit() loop?

  reply	other threads:[~2021-02-08 12:07 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-07 23:21 [PATCH net-next 0/9] Cleanup in brport flags switchdev offload for DSA Vladimir Oltean
2021-02-07 23:21 ` [Bridge] " Vladimir Oltean
2021-02-07 23:21 ` [PATCH net-next 1/9] net: bridge: don't print in br_switchdev_set_port_flag Vladimir Oltean
2021-02-07 23:21   ` [Bridge] " Vladimir Oltean
2021-02-07 23:21 ` [PATCH net-next 2/9] net: bridge: offload initial and final port flags through switchdev Vladimir Oltean
2021-02-07 23:21   ` [Bridge] " Vladimir Oltean
2021-02-08 11:37   ` Nikolay Aleksandrov
2021-02-08 11:37     ` [Bridge] " Nikolay Aleksandrov
2021-02-08 11:45     ` Vladimir Oltean [this message]
2021-02-08 11:45       ` Vladimir Oltean
2021-02-08 12:17       ` Nikolay Aleksandrov
2021-02-08 12:17         ` [Bridge] " Nikolay Aleksandrov
2021-02-07 23:21 ` [PATCH net-next 3/9] net: dsa: stop setting initial and final brport flags Vladimir Oltean
2021-02-07 23:21   ` [Bridge] " Vladimir Oltean
2021-02-07 23:21 ` [PATCH net-next 4/9] net: dsa: kill .port_egress_floods overengineering Vladimir Oltean
2021-02-07 23:21   ` [Bridge] " Vladimir Oltean
2021-02-07 23:21 ` [PATCH net-next 5/9] net: squash switchdev attributes PRE_BRIDGE_FLAGS and BRIDGE_FLAGS Vladimir Oltean
2021-02-07 23:21   ` [Bridge] " Vladimir Oltean
2021-02-08 16:04   ` Ioana Ciornei
2021-02-08 16:04     ` [Bridge] " Ioana Ciornei
2021-02-07 23:21 ` [PATCH net-next 6/9] net: bridge: stop treating EOPNOTSUPP as special in br_switchdev_set_port_flag Vladimir Oltean
2021-02-07 23:21   ` [Bridge] " Vladimir Oltean
2021-02-07 23:21 ` [PATCH net-next 7/9] net: mscc: ocelot: use separate flooding PGID for broadcast Vladimir Oltean
2021-02-07 23:21   ` [Bridge] " Vladimir Oltean
2021-02-07 23:21 ` [PATCH net-next 8/9] net: mscc: ocelot: offload bridge port flags to device Vladimir Oltean
2021-02-07 23:21   ` [Bridge] " Vladimir Oltean
2021-02-07 23:21 ` [PATCH net-next 9/9] net: mscc: ocelot: support multiple bridges Vladimir Oltean
2021-02-07 23:21   ` [Bridge] " Vladimir Oltean

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=20210208114511.xtzma5byrdnr5s7r@skbuf \
    --to=olteanv@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=bridge@lists.linux-foundation.org \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=grygorii.strashko@ti.com \
    --cc=idosch@idosch.org \
    --cc=ioana.ciornei@nxp.com \
    --cc=ivecera@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@nvidia.com \
    --cc=roopa@nvidia.com \
    --cc=tchornyi@marvell.com \
    --cc=vivien.didelot@gmail.com \
    --cc=vkochan@marvell.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.