From: Vadym Kochan <vadym.kochan@plvision.eu>
To: Ido Schimmel <idosch@idosch.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"David S . Miller" <davem@davemloft.net>,
Oleksandr Mazur <oleksandr.mazur@plvision.eu>,
Taras Chornyi <taras.chornyi@plvision.eu>,
Serhiy Boiko <serhiy.boiko@plvision.eu>,
Andrii Savka <andrii.savka@plvision.eu>,
Volodymyr Mytnyk <volodymyr.mytnyk@plvision.eu>,
Serhiy Pshyk <serhiy.pshyk@plvision.eu>
Subject: Re: [RFC net-next 1/3] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX325x (AC3x)
Date: Sat, 2 May 2020 18:20:49 +0300 [thread overview]
Message-ID: <20200502152049.GA8513@plvision.eu> (raw)
In-Reply-To: <20200305144937.GA132852@splinter>
Hi Ido,
On Thu, Mar 05, 2020 at 04:49:37PM +0200, Ido Schimmel wrote:
> On Tue, Feb 25, 2020 at 04:30:54PM +0000, Vadym Kochan wrote:
> > +int mvsw_pr_port_learning_set(struct mvsw_pr_port *port, bool learn)
> > +{
> > + return mvsw_pr_hw_port_learning_set(port, learn);
> > +}
> > +
> > +int mvsw_pr_port_flood_set(struct mvsw_pr_port *port, bool flood)
> > +{
> > + return mvsw_pr_hw_port_flood_set(port, flood);
> > +}
>
> Flooding and learning are per-port attributes? Not per-{port, VLAN} ?
> If so, you need to have various restrictions in the driver in case
> someone configures multiple vlan devices on top of a port and enslaves
> them to different bridges.
>
> > +
> > +
> > + INIT_LIST_HEAD(&port->vlans_list);
> > + port->pvid = MVSW_PR_DEFAULT_VID;
>
> If you're using VID 1, then you need to make sure that user cannot
> configure a VLAN device with with this VID. If possible, I suggest that
> you use VID 4095, as it cannot be configured from user space.
>
> I'm actually not entirely sure why you need a default VID.
>
> > +mvsw_pr_port_vlan_bridge_join(struct mvsw_pr_port_vlan *port_vlan,
> > + struct mvsw_pr_bridge_port *br_port,
> > + struct netlink_ext_ack *extack)
> > +{
> > + struct mvsw_pr_port *port = port_vlan->mvsw_pr_port;
> > + struct mvsw_pr_bridge_vlan *br_vlan;
> > + u16 vid = port_vlan->vid;
> > + int err;
> > +
> > + if (port_vlan->bridge_port)
> > + return 0;
> > +
> > + err = mvsw_pr_port_flood_set(port, br_port->flags & BR_FLOOD);
> > + if (err)
> > + return err;
> > +
> > + err = mvsw_pr_port_learning_set(port, br_port->flags & BR_LEARNING);
> > + if (err)
> > + goto err_port_learning_set;
>
> It seems that learning and flooding are not per-{port, VLAN} attributes,
> so I'm not sure why you have this here.
>
> The fact that you don't undo this in mvsw_pr_port_vlan_bridge_leave()
> tells me it should not be here.
>
> +
> > +void
> > +mvsw_pr_port_vlan_bridge_leave(struct mvsw_pr_port_vlan *port_vlan)
> > +{
> > + struct mvsw_pr_port *port = port_vlan->mvsw_pr_port;
> > + struct mvsw_pr_bridge_vlan *br_vlan;
> > + struct mvsw_pr_bridge_port *br_port;
> > + int port_count;
> > + u16 vid = port_vlan->vid;
> > + bool last_port, last_vlan;
> > +
> > + br_port = port_vlan->bridge_port;
> > + last_vlan = list_is_singular(&br_port->vlan_list);
> > + port_count =
> > + mvsw_pr_bridge_vlan_port_count_get(br_port->bridge_device, vid);
> > + br_vlan = mvsw_pr_bridge_vlan_find(br_port, vid);
> > + last_port = port_count == 1;
> > + if (last_vlan) {
> > + mvsw_pr_fdb_flush_port(port, MVSW_PR_FDB_FLUSH_MODE_DYNAMIC);
> > + } else if (last_port) {
> > + mvsw_pr_fdb_flush_vlan(port->sw, vid,
> > + MVSW_PR_FDB_FLUSH_MODE_DYNAMIC);
> > + } else {
> > + mvsw_pr_fdb_flush_port_vlan(port, vid,
> > + MVSW_PR_FDB_FLUSH_MODE_DYNAMIC);
>
> If you always flush based on {port, VID}, then why do you need the other
> two?
>
> +
> > +static int mvsw_pr_port_obj_attr_set(struct net_device *dev,
> > + const struct switchdev_attr *attr,
> > + struct switchdev_trans *trans)
> > +{
> > + int err = 0;
> > + struct mvsw_pr_port *port = netdev_priv(dev);
> > +
> > + switch (attr->id) {
> > + case SWITCHDEV_ATTR_ID_PORT_STP_STATE:
> > + err = -EOPNOTSUPP;
>
> You don't support STP?
Not, yet. But it will be in the next submission or official patch.
>
> > + break;
> > + default:
> > + kfree(switchdev_work);
> > + return NOTIFY_DONE;
> > + }
> > +
> > + queue_work(mvsw_owq, &switchdev_work->work);
>
> Once you defer the operation you cannot return an error, which is
> problematic. Do you have a way to know if the operation will succeed or
> not? That is, if the hardware has enough space for this new FDB entry?
>
Right, fdb configuration on via fw is blocking operation I still need to
think on it if it is possible by current design.
>
> Why do you need both 'struct mvsw_pr_switchdev' and 'struct
> mvsw_pr_bridge'? I think the second is enough. Also, I assume
> 'switchdev' naming is inspired by mlxsw, but 'bridge' is better.
>
I changed to use bridge for bridge object, because having bridge_device
may confuse.
Thank you for your comments they were very useful, sorry for so late
answer, I decided to re-implement this version a bit. Regarding flooding
and default vid I still need to check it.
Regards,
Vadym Kochan
next prev parent reply other threads:[~2020-05-02 15:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-25 16:30 [RFC net-next 0/3] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX326x (AC3x) Vadym Kochan
2020-02-25 16:30 ` [RFC net-next 1/3] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX325x (AC3x) Vadym Kochan
2020-02-25 22:05 ` Andrew Lunn
2020-02-26 15:54 ` Jiri Pirko
2020-02-27 21:32 ` Vadym Kochan
2020-02-27 21:43 ` Andrew Lunn
2020-02-27 23:50 ` Vadym Kochan
2020-02-28 6:36 ` Jiri Pirko
2020-02-28 14:03 ` Andrew Lunn
2020-02-28 6:34 ` Jiri Pirko
2020-02-28 9:44 ` Vadym Kochan
2020-02-28 10:59 ` Jiri Pirko
2020-02-27 14:22 ` Jiri Pirko
2020-02-28 8:06 ` Vadym Kochan
2020-02-28 11:03 ` Jiri Pirko
2020-02-28 4:22 ` Florian Fainelli
2020-02-28 8:17 ` Vadym Kochan
2020-03-05 14:49 ` Ido Schimmel
2020-05-02 15:20 ` Vadym Kochan [this message]
2020-05-05 4:01 ` Vadym Kochan
2020-02-25 16:30 ` [RFC net-next 2/3] net: marvell: prestera: Add PCI interface support Vadym Kochan
2020-02-25 20:49 ` Andrew Lunn
2020-02-27 11:05 ` Jiri Pirko
2020-02-28 16:54 ` Vadym Kochan
2020-02-29 7:58 ` Jiri Pirko
2020-03-01 2:12 ` Jakub Kicinski
2020-02-25 16:30 ` [RFC net-next 3/3] dt-bindings: marvell,prestera: Add address mapping for Prestera Switchdev PCIe driver Vadym Kochan
2020-02-28 4:24 ` Florian Fainelli
2020-02-25 22:12 ` [RFC net-next 0/3] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX326x (AC3x) Andrew Lunn
2020-02-25 22:45 ` Chris Packham
2020-02-28 16:50 ` Vadym Kochan
2020-02-26 15:44 ` Jiri Pirko
2020-02-26 16:38 ` Roopa Prabhu
2020-03-05 15:01 ` Ido Schimmel
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=20200502152049.GA8513@plvision.eu \
--to=vadym.kochan@plvision.eu \
--cc=andrii.savka@plvision.eu \
--cc=davem@davemloft.net \
--cc=idosch@idosch.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oleksandr.mazur@plvision.eu \
--cc=serhiy.boiko@plvision.eu \
--cc=serhiy.pshyk@plvision.eu \
--cc=taras.chornyi@plvision.eu \
--cc=volodymyr.mytnyk@plvision.eu \
/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).