From: Tobias Waldekranz <tobias@waldekranz.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Ivan Vecera <ivecera@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Jiri Pirko <jiri@resnulli.us>, Petr Machata <petrm@nvidia.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
bridge@lists.linux-foundation.org,
Russell King <linux@armlinux.org.uk>,
Vivien Didelot <vivien.didelot@gmail.com>,
Ido Schimmel <idosch@nvidia.com>,
netdev@vger.kernel.org, Cooper Lees <me@cooperlees.com>,
Roopa Prabhu <roopa@nvidia.com>,
kuba@kernel.org, Matt Johnston <matt@codeconstruct.com.au>,
davem@davemloft.net, linux-kernel@vger.kernel.org
Subject: Re: [Bridge] [PATCH v2 net-next 04/10] net: bridge: mst: Notify switchdev drivers of VLAN MSTI migrations
Date: Tue, 08 Mar 2022 09:01:04 +0100 [thread overview]
Message-ID: <87y21kna9r.fsf@waldekranz.com> (raw)
In-Reply-To: <20220303205921.sxb52jzw4jcdj6m7@skbuf>
On Thu, Mar 03, 2022 at 22:59, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Tue, Mar 01, 2022 at 11:03:15AM +0100, Tobias Waldekranz wrote:
>> Whenever a VLAN moves to a new MSTI, send a switchdev notification so
>> that switchdevs can...
>>
>> ...either refuse the migration if the hardware does not support
>> offloading of MST...
>>
>> ..or track a bridge's VID to MSTI mapping when offloading is
>> supported.
>>
>> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
>> ---
>> include/net/switchdev.h | 10 +++++++
>> net/bridge/br_mst.c | 15 +++++++++++
>> net/bridge/br_switchdev.c | 57 +++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 82 insertions(+)
>>
>> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>> index 3e424d40fae3..39e57aa5005a 100644
>> --- a/include/net/switchdev.h
>> +++ b/include/net/switchdev.h
>> @@ -28,6 +28,7 @@ enum switchdev_attr_id {
>> SWITCHDEV_ATTR_ID_BRIDGE_MC_DISABLED,
>> SWITCHDEV_ATTR_ID_BRIDGE_MROUTER,
>> SWITCHDEV_ATTR_ID_MRP_PORT_ROLE,
>> + SWITCHDEV_ATTR_ID_VLAN_MSTI,
>> };
>>
>> struct switchdev_brport_flags {
>> @@ -35,6 +36,14 @@ struct switchdev_brport_flags {
>> unsigned long mask;
>> };
>>
>> +struct switchdev_vlan_attr {
>> + u16 vid;
>> +
>> + union {
>> + u16 msti;
>> + };
>
> Do you see other VLAN attributes that would be added in the future, such
> as to justify making this a single-element union from the get-go?
I could imagine being able to control things like multicast snooping on
a per-VLAN basis. Being able to act as a multicast router in one VLAN
but not another.
> Anyway if that is the case, we're lacking an id for the attribute type,
> so we'd end up needing to change drivers when a second union element
> appears. Otherwise they'd all expect an u16 msti.
My idea was that `enum switchdev_attr_id` would hold all of that
information. In this example SWITCHDEV_ATTR_ID_VLAN_MSTI, denotes both
that `vlan_attr` is the valid member of `u` and that `msti` is the valid
member of `vlan_attr`. If we add SWITCHDEV_ATTR_ID_VLAN_SNOOPING, that
would point to both `vlan_attr` and a new `bool snooping` in the union.
Do you think we should just have a SWITCHDEV_ATTR_ID_VLAN_ATTR for all
per-VLAN attributes and then have a separate union?
>> +};
>> +
>> struct switchdev_attr {
>> struct net_device *orig_dev;
>> enum switchdev_attr_id id;
>> @@ -50,6 +59,7 @@ struct switchdev_attr {
>> u16 vlan_protocol; /* BRIDGE_VLAN_PROTOCOL */
>> bool mc_disabled; /* MC_DISABLED */
>> u8 mrp_port_role; /* MRP_PORT_ROLE */
>> + struct switchdev_vlan_attr vlan_attr; /* VLAN_* */
>> } u;
>> };
>>
>> diff --git a/net/bridge/br_mst.c b/net/bridge/br_mst.c
>> index 8dea8e7257fd..aba603675165 100644
>> --- a/net/bridge/br_mst.c
>> +++ b/net/bridge/br_mst.c
>> @@ -7,6 +7,7 @@
>> */
>>
>> #include <linux/kernel.h>
>> +#include <net/switchdev.h>
>>
>> #include "br_private.h"
>>
>> @@ -65,9 +66,23 @@ static void br_mst_vlan_sync_state(struct net_bridge_vlan *pv, u16 msti)
>>
>> int br_mst_vlan_set_msti(struct net_bridge_vlan *mv, u16 msti)
>> {
>> + struct switchdev_attr attr = {
>> + .id = SWITCHDEV_ATTR_ID_VLAN_MSTI,
>> + .flags = SWITCHDEV_F_DEFER,
>
> Is the bridge spinlock held (atomic context), or otherwise why is
> SWITCHDEV_F_DEFER needed here?
Nope, just copypasta. In fact, it shouldn't be needed when setting the
state either, as you can only change the state via a netlink message. I
will remove it.
>> + .orig_dev = mv->br->dev,
>> + .u.vlan_attr = {
>> + .vid = mv->vid,
>> + .msti = msti,
>> + },
>> + };
>> struct net_bridge_vlan_group *vg;
>> struct net_bridge_vlan *pv;
>> struct net_bridge_port *p;
>> + int err;
>> +
>> + err = switchdev_port_attr_set(mv->br->dev, &attr, NULL);
>
> Treating a "VLAN attribute" as a "port attribute of the bridge" is
> pushing the taxonomy just a little, but I don't have a better suggestion.
Isn't there prior art here? I thought things like VLAN filtering already
worked like this?
>> + if (err && err != -EOPNOTSUPP)
>> + return err;
>>
>> mv->msti = msti;
>>
>> diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
>> index 6f6a70121a5e..160d7659f88a 100644
>> --- a/net/bridge/br_switchdev.c
>> +++ b/net/bridge/br_switchdev.c
>> @@ -428,6 +428,57 @@ static int br_switchdev_vlan_replay(struct net_device *br_dev,
>> return 0;
>> }
>>
>> +static int br_switchdev_mst_replay(struct net_device *br_dev,
>> + const void *ctx, bool adding,
>> + struct notifier_block *nb,
>> + struct netlink_ext_ack *extack)
>
> "bool adding" is unused, and replaying the VLAN to MSTI associations
> before deleting them makes little sense anyway.
>
> I understand the appeal of symmetry, so maybe put an
>
> if (adding) {
> err = br_switchdev_vlan_attr_replay(...);
> if (err && err != -EOPNOTSUPP)
> return err;
> }
>
> at the end of br_switchdev_vlan_replay()?
Yeah, that is better. Will change.
>> +{
>> + struct switchdev_notifier_port_attr_info attr_info = {
>> + .info = {
>> + .dev = br_dev,
>> + .extack = extack,
>> + .ctx = ctx,
>> + },
>> + };
>> + struct net_bridge *br = netdev_priv(br_dev);
>> + struct net_bridge_vlan_group *vg;
>> + struct net_bridge_vlan *v;
>> + int err;
>> +
>> + ASSERT_RTNL();
>> +
>> + if (!nb)
>> + return 0;
>> +
>> + if (!netif_is_bridge_master(br_dev))
>> + return -EINVAL;
>> +
>> + vg = br_vlan_group(br);
>> +
>> + list_for_each_entry(v, &vg->vlan_list, vlist) {
>> + struct switchdev_attr attr = {
>> + .id = SWITCHDEV_ATTR_ID_VLAN_MSTI,
>> + .flags = SWITCHDEV_F_DEFER,
>
> I don't think SWITCHDEV_F_DEFER has any effect on a replay.
Right, will fix.
>> + .orig_dev = br_dev,
>> + .u.vlan_attr = {
>> + .vid = v->vid,
>> + .msti = v->msti,
>> + }
>> + };
>> +
>> + if (!v->msti)
>> + continue;
>> +
>> + attr_info.attr = &attr;
>> + err = nb->notifier_call(nb, SWITCHDEV_PORT_ATTR_SET, &attr_info);
>> + err = notifier_to_errno(err);
>> + if (err)
>> + return err;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
>> struct br_switchdev_mdb_complete_info {
>> struct net_bridge_port *port;
>> @@ -695,6 +746,10 @@ static int nbp_switchdev_sync_objs(struct net_bridge_port *p, const void *ctx,
>> if (err && err != -EOPNOTSUPP)
>> return err;
>>
>> + err = br_switchdev_mst_replay(br_dev, ctx, true, blocking_nb, extack);
>> + if (err && err != -EOPNOTSUPP)
>> + return err;
>> +
>> err = br_switchdev_mdb_replay(br_dev, dev, ctx, true, blocking_nb,
>> extack);
>> if (err && err != -EOPNOTSUPP)
>> @@ -719,6 +774,8 @@ static void nbp_switchdev_unsync_objs(struct net_bridge_port *p,
>>
>> br_switchdev_mdb_replay(br_dev, dev, ctx, false, blocking_nb, NULL);
>>
>> + br_switchdev_mst_replay(br_dev, ctx, false, blocking_nb, NULL);
>> +
>> br_switchdev_vlan_replay(br_dev, ctx, false, blocking_nb, NULL);
>> }
>>
>> --
>> 2.25.1
>>
next prev parent reply other threads:[~2022-03-08 8:01 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 10:03 [Bridge] [PATCH v2 net-next 00/10] net: bridge: Multiple Spanning Trees Tobias Waldekranz
2022-03-01 10:03 ` [Bridge] [PATCH v2 net-next 01/10] net: bridge: mst: Multiple Spanning Tree (MST) mode Tobias Waldekranz
2022-03-01 23:01 ` Nikolay Aleksandrov
2022-03-07 14:53 ` Tobias Waldekranz
2022-03-03 22:28 ` Vladimir Oltean
2022-03-01 10:03 ` [Bridge] [PATCH v2 net-next 02/10] net: bridge: mst: Allow changing a VLAN's MSTI Tobias Waldekranz
2022-03-03 22:27 ` Vladimir Oltean
2022-03-07 14:54 ` Tobias Waldekranz
2022-03-01 10:03 ` [Bridge] [PATCH v2 net-next 03/10] net: bridge: mst: Support setting and reporting MST port states Tobias Waldekranz
2022-03-01 23:19 ` Nikolay Aleksandrov
2022-03-02 1:53 ` Roopa Prabhu
2022-03-07 15:03 ` Tobias Waldekranz
2022-03-07 15:00 ` Tobias Waldekranz
2022-03-07 15:03 ` Nikolay Aleksandrov
2022-03-01 10:03 ` [Bridge] [PATCH v2 net-next 04/10] net: bridge: mst: Notify switchdev drivers of VLAN MSTI migrations Tobias Waldekranz
2022-03-03 20:59 ` Vladimir Oltean
2022-03-08 8:01 ` Tobias Waldekranz [this message]
2022-03-08 17:17 ` Vladimir Oltean
2022-03-09 15:34 ` Tobias Waldekranz
2022-03-01 10:03 ` [Bridge] [PATCH v2 net-next 05/10] net: bridge: mst: Notify switchdev drivers of MST state changes Tobias Waldekranz
2022-03-01 10:03 ` [Bridge] [PATCH v2 net-next 06/10] net: dsa: Pass VLAN MSTI migration notifications to driver Tobias Waldekranz
2022-03-03 22:29 ` Vladimir Oltean
2022-03-09 15:47 ` Tobias Waldekranz
2022-03-09 17:03 ` Vladimir Oltean
2022-03-01 10:03 ` [Bridge] [PATCH v2 net-next 07/10] net: dsa: Pass MST state changes " Tobias Waldekranz
2022-03-03 22:20 ` Vladimir Oltean
2022-03-10 8:54 ` Tobias Waldekranz
2022-03-10 10:35 ` Vladimir Oltean
2022-03-10 16:05 ` Tobias Waldekranz
2022-03-10 16:18 ` Vladimir Oltean
2022-03-10 22:46 ` Tobias Waldekranz
2022-03-10 23:08 ` Vladimir Oltean
2022-03-10 23:59 ` Tobias Waldekranz
2022-03-11 0:22 ` Vladimir Oltean
2022-03-11 9:01 ` Tobias Waldekranz
2022-03-10 16:20 ` Tobias Waldekranz
2022-03-01 10:03 ` [Bridge] [PATCH v2 net-next 08/10] net: dsa: mv88e6xxx: Disentangle STU from VTU Tobias Waldekranz
2022-03-01 10:03 ` [Bridge] [PATCH v2 net-next 09/10] net: dsa: mv88e6xxx: Export STU as devlink region Tobias Waldekranz
2022-03-01 10:03 ` [Bridge] [PATCH v2 net-next 10/10] net: dsa: mv88e6xxx: MST Offloading Tobias Waldekranz
2022-03-03 22:26 ` Vladimir Oltean
2022-03-10 15:14 ` Tobias Waldekranz
2022-03-10 15:25 ` Vladimir Oltean
2022-03-10 15:33 ` Vladimir Oltean
2022-03-01 16:21 ` [Bridge] [PATCH v2 net-next 00/10] net: bridge: Multiple Spanning Trees Vladimir Oltean
2022-03-01 17:19 ` Stephen Hemminger
2022-03-01 21:20 ` Tobias Waldekranz
2022-03-01 22:30 ` Pavel Šimerda
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=87y21kna9r.fsf@waldekranz.com \
--to=tobias@waldekranz.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=idosch@nvidia.com \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=matt@codeconstruct.com.au \
--cc=me@cooperlees.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=petrm@nvidia.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=vivien.didelot@gmail.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.