From: Tobias Waldekranz <tobias@waldekranz.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: andrew@lunn.ch, vivien.didelot@gmail.com, f.fainelli@gmail.com,
netdev@vger.kernel.org
Subject: Re: [RFC PATCH 0/4] net: dsa: link aggregation support
Date: Tue, 27 Oct 2020 15:59:30 +0100 [thread overview]
Message-ID: <87tuufvhnx.fsf@waldekranz.com> (raw)
In-Reply-To: <20201027122720.6jm4vuivi7tozzdq@skbuf>
On Tue, Oct 27, 2020 at 14:27, Vladimir Oltean <olteanv@gmail.com> wrote:
>> The LAG driver ops all receive the LAG netdev as an argument when this
>> information is already available through the port's lag pointer. This
>> was done to match the way that the bridge netdev is passed to all VLAN
>> ops even though it is in the port's bridge_dev. Is there a reason for
>> this or should I just remove it from the LAG ops?
>
> Maybe because on "leave", the bridge/LAG net device pointer inside
> struct dsa_port is first set to NULL, then the DSA notifier is called?
Right, that makes sense. For LAGs I keep ds->lag set until the leave ops
have run. But perhaps I should change it to match the VLAN ops?
> Since ocelot/felix does not have this restriction, and supports
> individual port addressing even under a LAG, you can imagine I am not
> very happy to see the RX data path punishing everyone else that is not
> mv88e6xxx.
I understand that, for sure. Though to be clear, the only penalty in
terms of performance is an extra call to dsa_slave_check, which is just
a load and compare on skb->dev->netdev_ops.
>> (mv88e6xxx) What is the policy regarding the use of DSA vs. EDSA? It
>> seems like all chips capable of doing EDSA are using that, except for
>> the Peridot.
>
> I have no documentation whatsoever for mv88e6xxx, but just wondering,
> what is the benefit brought by EDSA here vs DSA? Does DSA have the
> same restriction when the ports are in a LAG?
The same restrictions apply I'm afraid. The only difference is that you
prepend a proper ethertype before the tag.
The idea (as far as I know) is that you can trap control traffic (TO_CPU
in DSA parlance) to the CPU and receive (E)DSA tagged to implement
things like STP and LLDP, but you receive the data traffic (FORWARD)
untagged or with an 802.1Q tag.
This means you can use standard VLAN accelerators on NICs to
remove/insert the 1Q tags. In a routing scenario this can bring a
significant speed-up as you skip two memcpys per packet to remove and
insert the tag.
next prev parent reply other threads:[~2020-10-27 17:13 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-27 10:51 [RFC PATCH 0/4] net: dsa: link aggregation support Tobias Waldekranz
2020-10-27 10:51 ` [RFC PATCH 1/4] net: dsa: mv88e6xxx: use ethertyped dsa for 6390/6390X Tobias Waldekranz
2020-10-27 14:52 ` Marek Behun
2020-10-27 14:54 ` Marek Behun
2020-10-27 14:58 ` Marek Behun
2020-10-27 10:51 ` [RFC PATCH 2/4] net: dsa: link aggregation support Tobias Waldekranz
2020-10-28 0:58 ` Vladimir Oltean
2020-10-28 14:03 ` Tobias Waldekranz
2020-10-27 10:51 ` [RFC PATCH 3/4] net: dsa: mv88e6xxx: " Tobias Waldekranz
2020-10-29 5:28 ` kernel test robot
2020-10-29 11:54 ` Dan Carpenter
2020-10-29 11:54 ` Dan Carpenter
2020-10-27 10:51 ` [RFC PATCH 4/4] net: dsa: tag_edsa: support reception of packets from lag devices Tobias Waldekranz
2020-10-28 12:05 ` Vladimir Oltean
2020-10-28 15:28 ` Tobias Waldekranz
2020-10-28 18:18 ` Vladimir Oltean
2020-10-28 22:31 ` Tobias Waldekranz
2020-10-28 23:08 ` Vladimir Oltean
2020-10-29 7:47 ` Tobias Waldekranz
2020-10-30 9:21 ` Vladimir Oltean
2020-11-01 11:31 ` Ido Schimmel
2020-10-27 12:27 ` [RFC PATCH 0/4] net: dsa: link aggregation support Vladimir Oltean
2020-10-27 14:29 ` Andrew Lunn
2020-10-27 14:59 ` Tobias Waldekranz [this message]
2020-10-27 14:00 ` Andrew Lunn
2020-10-27 15:09 ` Tobias Waldekranz
2020-10-27 15:05 ` Marek Behun
2020-10-27 15:23 ` Andrew Lunn
2020-10-27 18:25 ` Tobias Waldekranz
2020-10-27 18:33 ` Marek Behun
2020-10-27 19:04 ` Vladimir Oltean
2020-10-27 19:21 ` Tobias Waldekranz
2020-10-27 19:00 ` Vladimir Oltean
2020-10-27 19:37 ` Tobias Waldekranz
2020-10-27 20:02 ` Vladimir Oltean
2020-10-27 20:53 ` Tobias Waldekranz
2020-10-27 22:32 ` Vladimir Oltean
2020-10-28 0:27 ` Tobias Waldekranz
2020-10-28 22:35 ` Marek Behun
2020-10-27 22:36 ` Andrew Lunn
2020-10-28 0:45 ` Tobias Waldekranz
2020-10-28 1:03 ` Andrew Lunn
2020-11-11 4:28 ` Florian Fainelli
2020-11-19 10:51 ` Vladimir Oltean
2020-11-19 11:52 ` Tobias Waldekranz
2020-11-19 18:12 ` 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=87tuufvhnx.fsf@waldekranz.com \
--to=tobias@waldekranz.com \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.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.