From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "Vladimir Oltean" <olteanv@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Jakub Kicinski" <kuba@kernel.org>,
"Vivien Didelot" <vivien.didelot@gmail.com>,
"Andrew Lunn" <andrew@lunn.ch>,
"Tobias Waldekranz" <tobias@waldekranz.com>,
"Marek Behún" <kabel@kernel.org>,
"Ansuel Smith" <ansuelsmth@gmail.com>,
"DENG Qingfang" <dqfext@gmail.com>,
"Alvin Šipraga" <alsi@bang-olufsen.dk>,
"Claudiu Manoil" <claudiu.manoil@nxp.com>,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
"Colin Foster" <colin.foster@in-advantage.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Luiz Angelo Daros de Luca" <luizluca@gmail.com>,
"Roopa Prabhu" <roopa@nvidia.com>,
"Nikolay Aleksandrov" <razor@blackwall.org>,
"Frank Wunderlich" <frank-w@public-files.de>
Subject: Re: [RFC PATCH net-next 10/12] net: dsa: allow the DSA master to be seen and changed through rtnetlink
Date: Mon, 23 May 2022 23:08:35 +0000 [thread overview]
Message-ID: <20220523230834.4jv2kyg6eqx5rmi3@skbuf> (raw)
In-Reply-To: <d5d485e3-bddf-f052-2f46-f306f53f3d34@gmail.com>
On Mon, May 23, 2022 at 11:41:45AM -0700, Florian Fainelli wrote:
> > +static int dsa_changelink(struct net_device *dev, struct nlattr *tb[],
> > + struct nlattr *data[],
> > + struct netlink_ext_ack *extack)
> > +{
> > + int err;
> > +
> > + if (!data)
> > + return 0;
> > +
> > + if (data[IFLA_DSA_MASTER]) {
>
> We could add a comment to explain that IFLA_LINK is "reserved" for standard
> usage of associating the DSA device with a different upper type, like VLAN,
> bridge master etc.
TBH I don't have a very strong opinion here. IFLA_LINK does not mean the
same thing for all virtual netdevices, it means one thing for vlan/macvlan
where it describes an upper/lower relationship and another for veth
where it describes the pair, and yet another for DSA where it describes
the host port.
What seems to be universally loved about IFLA_LINK is that the notation
"eth0@eth1" used by iproute2 is cute, it lets loose users' imagination.
I did ask here whether it would be good to introduce a more specific
attribute, no response though.
https://lore.kernel.org/netdev/20210411170939.cxmva5vdcpqu4bmi@skbuf/
If the IFLA_LINK meaning is namespaced per netdev kind, I suppose we
could reuse that just fine to change the DSA master. In any case I
wouldn't want to make the debate of the century out of this.
> > + u32 ifindex = nla_get_u32(data[IFLA_DSA_MASTER]);
> > + struct net_device *master;
> > +
> > + master = __dev_get_by_index(dev_net(dev), ifindex);
> > + if (!master)
> > + return -EINVAL;
> > +
> > + err = dsa_slave_change_master(dev, master, extack);
> > + if (err)
> > + return err;
> > + }
>
> I would be tempted to reduce the indentation here because we are almost
> guaranteed to add code in that conditional section?
The idea was to avoid code movement if we ever add other netlink
attributes other than IFLA_DSA_MASTER. But not sure whether to optimize
for that.
> [snip]
>
> > +static int dsa_port_assign_master(struct dsa_port *dp,
> > + struct net_device *master,
> > + struct netlink_ext_ack *extack,
> > + bool fail_on_err)
> > +{
> > + struct dsa_switch *ds = dp->ds;
> > + int port = dp->index, err;
> > +
> > + err = ds->ops->port_change_master(ds, port, master, extack);
> > + if (err && !fail_on_err)
> > + dev_err(ds->dev, "port %d failed to assign master %s: %pe\n",
> > + port, master->name, ERR_PTR(err));
>
> Should not that go over extack instead?
Here we print if "fail_on_err" was false. We avoid failing on errors
when we are in an error rollback code path. This is also the reason why
I did not set extack, presumably because it may have been set before by
ds->ops->port_change_master. Printing to the console shows all errors
along the path, setting the extack shows only the first, or last, error.
> > +
> > + if (err && fail_on_err)
> > + return err;
> > +
> > + dp->cpu_dp = master->dsa_ptr;
> > +
> > + return 0;
> > +}
> > +
> > +/* Change the dp->cpu_dp affinity for a user port. Note that both cross-chip
> > + * notifiers and drivers have implicit assumptions about user-to-CPU-port
> > + * mappings, so we unfortunately cannot delay the deletion of the objects
> > + * (switchdev, standalone addresses, standalone VLANs) on the old CPU port
> > + * until the new CPU port has been set up. So we need to completely tear down
> > + * the old CPU port before changing it, and restore it on errors during the
> > + * bringup of the new one.
> > + */
> > +int dsa_port_change_master(struct dsa_port *dp, struct net_device *master,
> > + struct netlink_ext_ack *extack)
> > +{
> > + struct net_device *bridge_dev = dsa_port_bridge_dev_get(dp);
> > + struct net_device *old_master = dsa_port_to_master(dp);
> > + struct net_device *dev = dp->slave;
> > + struct dsa_switch *ds = dp->ds;
> > + int port = dp->index;
> > + bool vlan_filtering;
> > + int err, tmp;
> > +
> > + /* Bridges may hold host FDB, MDB and VLAN objects. These need to be
> > + * migrated, so dynamically unoffload and later reoffload the bridge
> > + * port.
> > + */
> > + if (bridge_dev) {
> > + dsa_port_pre_bridge_leave(dp, bridge_dev);
> > + dsa_port_bridge_leave(dp, bridge_dev);
> > + }
> > +
> > + /* The port might still be VLAN filtering even if it's no longer
> > + * under a bridge, either due to ds->vlan_filtering_is_global or
> > + * ds->needs_standalone_vlan_filtering. In turn this means VLANs
> > + * on the CPU port.
> > + */
> > + vlan_filtering = dsa_port_is_vlan_filtering(dp);
> > + if (vlan_filtering) {
> > + err = dsa_slave_manage_vlan_filtering(dev, false);
> > + if (err) {
> > + dev_err(ds->dev,
> > + "port %d failed to remove standalone VLANs: %pe\n",
> > + port, ERR_PTR(err));
>
> Likewise, should not that be via extack? And likewise for pretty much any
> message down below.
Here we could populate the extack.
> [snip]
>
> > + if (!ds->ops->port_change_master)
> > + return -EOPNOTSUPP;
>
> This could be provided over extactk since it is not even supposed to be
> happening.
What do you mean it's not supposed to be happening? This is the only
place where we have a NULL check for ds->ops->port_change_master.
I didn't add an extack here because I didn't think there's much to say
beside the usual strerror(EOPNOTSUPP) = "Operation not supported".
I may add an extack saying "Driver does not support changing DSA master"
or some sort of message like that.
next prev parent reply other threads:[~2022-05-23 23:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-23 10:42 [RFC PATCH net-next 00/12] DSA changes for multiple CPU ports (part 3) Vladimir Oltean
2022-05-23 10:42 ` [RFC PATCH net-next 01/12] net: introduce iterators over synced hw addresses Vladimir Oltean
2022-05-23 17:54 ` Florian Fainelli
2022-05-23 10:42 ` [RFC PATCH net-next 02/12] net: dsa: walk through all changeupper notifier functions Vladimir Oltean
2022-05-23 18:11 ` Florian Fainelli
2022-05-23 10:42 ` [RFC PATCH net-next 03/12] net: dsa: don't stop at NOTIFY_OK when calling ds->ops->port_prechangeupper Vladimir Oltean
2022-05-23 17:56 ` Florian Fainelli
2022-05-23 10:42 ` [RFC PATCH net-next 04/12] net: bridge: move DSA master bridging restriction to DSA Vladimir Oltean
2022-05-23 17:57 ` Florian Fainelli
2022-05-23 23:02 ` Nikolay Aleksandrov
2022-05-23 10:42 ` [RFC PATCH net-next 05/12] net: dsa: existing DSA masters cannot join upper interfaces Vladimir Oltean
2022-05-23 17:58 ` Florian Fainelli
2022-05-23 10:42 ` [RFC PATCH net-next 06/12] net: dsa: only bring down user ports assigned to a given DSA master Vladimir Oltean
2022-05-23 17:59 ` Florian Fainelli
2022-05-23 10:42 ` [RFC PATCH net-next 07/12] net: dsa: all DSA masters must be down when changing the tagging protocol Vladimir Oltean
2022-05-23 18:00 ` Florian Fainelli
2022-05-23 10:42 ` [RFC PATCH net-next 08/12] net: dsa: use dsa_tree_for_each_cpu_port in dsa_tree_{setup,teardown}_master Vladimir Oltean
2022-05-23 18:01 ` Florian Fainelli
2022-05-23 10:42 ` [RFC PATCH net-next 09/12] net: dsa: introduce dsa_port_get_master() Vladimir Oltean
2022-05-23 18:08 ` Florian Fainelli
2022-05-23 10:42 ` [RFC PATCH net-next 10/12] net: dsa: allow the DSA master to be seen and changed through rtnetlink Vladimir Oltean
2022-05-23 18:41 ` Florian Fainelli
2022-05-23 23:08 ` Vladimir Oltean [this message]
2022-05-23 10:42 ` [RFC PATCH net-next 11/12] net: dsa: allow masters to join a LAG Vladimir Oltean
2022-05-23 10:42 ` [RFC PATCH net-next 12/12] net: dsa: felix: add support for changing DSA master Vladimir Oltean
2022-05-23 21:53 ` [RFC PATCH net-next 00/12] DSA changes for multiple CPU ports (part 3) Florian Fainelli
2022-05-23 22:51 ` Vladimir Oltean
2022-05-24 12:02 ` Ansuel Smith
2022-05-24 12:29 ` Vladimir Oltean
2022-05-24 12:38 ` Ansuel Smith
2022-05-24 13:24 ` 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=20220523230834.4jv2kyg6eqx5rmi3@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=alsi@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=claudiu.manoil@nxp.com \
--cc=colin.foster@in-advantage.com \
--cc=dqfext@gmail.com \
--cc=f.fainelli@gmail.com \
--cc=frank-w@public-files.de \
--cc=kabel@kernel.org \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=luizluca@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=tobias@waldekranz.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox