From: Tobias Waldekranz <tobias@waldekranz•com>
To: Vladimir Oltean <olteanv@gmail•com>
Cc: davem@davemloft•net, kuba@kernel•org, andrew@lunn•ch,
vivien.didelot@gmail•com, f.fainelli@gmail•com,
j.vosburgh@gmail•com, vfalico@gmail•com, andy@greyhouse•net,
netdev@vger•kernel.org
Subject: Re: [PATCH v2 net-next 2/4] net: dsa: Link aggregation support
Date: Tue, 01 Dec 2020 15:29:53 +0100 [thread overview]
Message-ID: <871rg98uqm.fsf@waldekranz.com> (raw)
In-Reply-To: <20201201140354.lnhwx3ix2ogtnngy@skbuf>
On Tue, Dec 01, 2020 at 16:03, Vladimir Oltean <olteanv@gmail•com> wrote:
> On Mon, Nov 30, 2020 at 03:06:08PM +0100, Tobias Waldekranz wrote:
>> When a LAG joins a bridge, the DSA subsystem will treat that as each
>> individual port joining the bridge. The driver may look at the port's
>> LAG pointer to see if it is associated with any LAG, if that is
>> required. This is analogue to how switchdev events are replicated out
>> to all lower devices when reaching e.g. a LAG.
>
> Agree with the principle. But doesn't that mean that this code:
>
> static int dsa_slave_switchdev_blocking_event(struct notifier_block *unused,
> unsigned long event, void *ptr)
> {
> struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
> int err;
>
> switch (event) {
> case SWITCHDEV_PORT_OBJ_ADD:
> err = switchdev_handle_port_obj_add(dev, ptr,
> dsa_slave_dev_check,
> dsa_slave_port_obj_add);
> return notifier_from_errno(err);
> case SWITCHDEV_PORT_OBJ_DEL:
> err = switchdev_handle_port_obj_del(dev, ptr,
> dsa_slave_dev_check,
> dsa_slave_port_obj_del);
> return notifier_from_errno(err);
> case SWITCHDEV_PORT_ATTR_SET:
> err = switchdev_handle_port_attr_set(dev, ptr,
> dsa_slave_dev_check,
> dsa_slave_port_attr_set);
> return notifier_from_errno(err);
> }
>
> return NOTIFY_DONE;
> }
>
> should be replaced with something that also reacts to the case where
> "dev" is a LAG? Like, for example, I imagine that a VLAN installed on a
> bridge port that is a LAG should be propagated to the switch ports
> beneath that LAG. Similarly for all bridge attributes.
That is exactly what switchdev_handle_* does, no? It is this exact
behavior that my statement about switchdev event replication references.
> As for FDB and MDB addresses, I think they should be propagated towards
> a "logical port" corresponding to the LAG upper. I don't know how the
> mv88e6xxx handles this.
mv88e6xxx differentiates between multicast and unicast entries. So MDB
entries fit very well with the obj_add/del+replication. Unicast entries
will have use "lagX" as its destination, so in that case we need a new
dsa op along the lines of "lag_fdb_add/del".
next prev parent reply other threads:[~2020-12-01 14:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 14:06 [PATCH v2 net-next 0/4] net: dsa: Link aggregation support Tobias Waldekranz
2020-11-30 14:06 ` [PATCH v2 net-next 1/4] net: bonding: Notify ports about their initial state Tobias Waldekranz
2020-11-30 14:06 ` [PATCH v2 net-next 2/4] net: dsa: Link aggregation support Tobias Waldekranz
2020-12-01 1:37 ` Vladimir Oltean
2020-12-01 8:13 ` Tobias Waldekranz
2020-12-01 13:29 ` Vladimir Oltean
2020-12-01 14:22 ` Tobias Waldekranz
2020-12-01 14:03 ` Vladimir Oltean
2020-12-01 14:29 ` Tobias Waldekranz [this message]
2020-12-01 20:04 ` Vladimir Oltean
2020-12-01 21:48 ` Tobias Waldekranz
2020-12-01 22:23 ` Vladimir Oltean
2020-11-30 14:06 ` [PATCH v2 net-next 3/4] net: dsa: mv88e6xxx: " Tobias Waldekranz
2020-11-30 14:06 ` [PATCH v2 net-next 4/4] net: dsa: tag_dsa: Support reception of packets from LAG devices Tobias Waldekranz
2020-12-01 21:24 ` Vladimir Oltean
2020-12-01 22:31 ` Tobias Waldekranz
2020-12-02 0:33 ` 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=871rg98uqm.fsf@waldekranz.com \
--to=tobias@waldekranz$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=andy@greyhouse$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=f.fainelli@gmail$(echo .)com \
--cc=j.vosburgh@gmail$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=olteanv@gmail$(echo .)com \
--cc=vfalico@gmail$(echo .)com \
--cc=vivien.didelot@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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