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 22:48:34 +0100 [thread overview]
Message-ID: <87wny16vv1.fsf@waldekranz.com> (raw)
In-Reply-To: <20201201200423.mujxza7g7gsgntbg@skbuf>
On Tue, Dec 01, 2020 at 22:04, Vladimir Oltean <olteanv@gmail•com> wrote:
> On Tue, Dec 01, 2020 at 03:29:53PM +0100, Tobias Waldekranz wrote:
>> 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.
>
> I'm sorry, I don't mean to be overly obtuse, but _how_ does the current
> code propagate a VLAN to a physical port located below a bond? Through
> magic? The dsa_slave_dev_check is passed as a parameter to
> switchdev_handle_port_obj_add _exactly_ because the code has needed so
> far to match only on DSA interfaces and not on bonding interfaces. So
> the code does not react to VLANs added on a bonding interface. Hence my
> question.
There is no magic involved, here is the relevant snippet from
__switchdev_handle_port_obj_add:
/* Switch ports might be stacked under e.g. a LAG. Ignore the
* unsupported devices, another driver might be able to handle them. But
* propagate to the callers any hard errors.
*
* If the driver does its own bookkeeping of stacked ports, it's not
* necessary to go through this helper.
*/
netdev_for_each_lower_dev(dev, lower_dev, iter) {
if (netif_is_bridge_master(lower_dev))
continue;
err = __switchdev_handle_port_obj_add(lower_dev, port_obj_info,
check_cb, add_cb);
if (err && err != -EOPNOTSUPP)
return err;
}
> ip link del bond0
> ip link add bond0 type bond mode 802.3ad
> ip link set swp1 down && ip link set swp1 master bond0 && ip link set swp1 up
> ip link set swp2 down && ip link set swp2 master bond0 && ip link set swp2 up
> ip link del br0
> ip link add br0 type bridge
> ip link set bond0 master br0
> ip link set swp0 master br0
>
> This should propagate the VLANs to swp1 and swp2 but doesn't:
> bridge vlan add dev bond0 vid 100
I ran through this on my setup and it is indeed propagated to all ports.
Just a thought, when you rebased the ocelot specific stuff to v2, did
you add the number of supported LAGs to ds->num_lags? If not, DSA will
assume that the hardware does not support offloading.
> It's perfectly acceptable to say that this patch set doesn't deal with
> that. But your commit message seems to suggest that it's me who's
> misunderstanding something.
I understand, that is why I explicitly mentioned the lack of static FDB
support for example. But it absolutely should deal with the full list I
specified, so thanks for testing it.
next prev parent reply other threads:[~2020-12-01 21:49 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
2020-12-01 20:04 ` Vladimir Oltean
2020-12-01 21:48 ` Tobias Waldekranz [this message]
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=87wny16vv1.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