public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: "Marek Behún" <kabel@kernel.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Vivien Didelot" <vivien.didelot@gmail.com>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	"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>,
	"Roopa Prabhu" <roopa@nvidia.com>,
	"Nikolay Aleksandrov" <razor@blackwall.org>,
	"Tobias Waldekranz" <tobias@waldekranz.com>,
	"Ansuel Smith" <ansuelsmth@gmail.com>,
	"DENG Qingfang" <dqfext@gmail.com>,
	"Alvin Šipraga" <alsi@bang-olufsen.dk>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Luiz Angelo Daros de Luca" <luizluca@gmail.com>,
	"Felix Fietkau" <nbd@nbd.name>, "John Crispin" <john@phrozen.org>,
	"Sean Wang" <sean.wang@mediatek.com>
Subject: Re: [PATCH net-next 0/9] DSA changes for multiple CPU ports (part 4)
Date: Sun, 4 Sep 2022 15:41:15 +0000	[thread overview]
Message-ID: <20220904154115.oybr524635lfrgqp@skbuf> (raw)
In-Reply-To: <20220903044832.125984e2@thinkpad>

On Sat, Sep 03, 2022 at 04:48:32AM +0200, Marek Behún wrote:
> My opinion is that it would be better to add new DSA specific netlink
> operations instead of using the existing iflink as I did in the that
> patch.

Ok, I'll send out the iproute2 patch today.

> I think that DSA should have it's own IP subcommands. Using the
> standard, already existing API, is not sufficient for more complex
> configurations/DSA routing settings. Consider DSA where there are
> multiple switches and the switches are connected via multiple ports:
> 
> +----------+   +---------------+   +---------+
> |     eth0 <---> sw0p0   sw0p2 <---> sw1p0
> | cpu      |   |               |   |        ....
> |     eth1 <---> sw0p1   s20p3 <---> sw1p1
> +----------+   +---------------+   +---------+
> 
> The routing is more complicated in this scenario.

This is so problematic that I don't even know where to start.

Does anyone do this? What do they want to achieve? How do they want the
system to behave?

Let's push your example even one step further:

 +----------+   +---------------+   +---------------+   +---------+
 |     eth0 <---> sw0p0   sw0p2 <---> sw1p0   sw1p2 <---> sw2p0
 | cpu      |   |               |   |               |   |        ....
 |     eth1 <---> sw0p1   sw0p3 <---> sw1p1   sw1p3 <---> sw2p1
 +----------+   +---------------+   +---------------+   +---------+

With our current DT bindings, DSA (cascade) ports would need to contain
links to all DSA ports of indirectly connected switches, because this is
what the dst->rtable expects.

	switch@0 {
		reg = <0>;
		dsa,member = <0 0>;

		ethernet-ports {
			port@0 {
				reg = <0>;
				ethernet = <&eth0>;
			};

			port@1 {
				reg = <1>;
				ethernet = <&eth1>;
			};

			sw0p2: port@2 {
				reg = <2>;
				link = <&sw1p0>, <&sw2p0>, <&sw2p1>;
			};

			sw0p3: port@3 {
				reg = <3>;
				link = <&sw1p1>, <&sw2p0>, <&sw2p1>;
			};
		};
	};

	switch@1 {
		reg = <1>;
		dsa,member = <0 1>;

		ethernet-ports {
			sw1p0: port@0 {
				reg = <0>;
				link = <&sw0p2>;
			};

			sw1p1: port@1 {
				reg = <1>;
				link = <&sw0p3>;
			};

			sw1p2: port@2 {
				reg = <2>;
				link = <&sw2p0>;
			};

			sw1p3: port@3 {
				reg = <3>;
				link = <&sw2p1>;
			};
		};
	};

	switch@2 {
		reg = <2>;
		dsa,member = <0 2>;

		ethernet-ports {
			port@0 {
				reg = <0>;
				link = <&sw1p2>, <&sw0p2>, <&sw0p3>;
			};

			port@1 {
				reg = <1>;
				link = <&sw1p3>, <&sw0p2>, <&sw0p3>;
			};
		};
	};

> The old API is not sufficient.

There is no "old API" to speak of, because none of this is exposed.
So, 'insufficient' is an understatement. Furthermore, the rtnl_link_ops
are exposed per *user* port, we still gain zero control of the
dst->rtable.

The main consumer of the dst->rtable is this:

/* Return the local port used to reach an arbitrary switch device */
static inline unsigned int dsa_routing_port(struct dsa_switch *ds, int device)
{
	struct dsa_switch_tree *dst = ds->dst;
	struct dsa_link *dl;

	list_for_each_entry(dl, &dst->rtable, list)
		if (dl->dp->ds == ds && dl->link_dp->ds->index == device)
			return dl->dp->index;

	return ds->num_ports;
}

Notice the singular *the* local port. So it would currently return the
local cascade port from the first dsa_link added to the rtable (in turn,
the first port which has a 'link' OF node description to a cascade port
of @device). If there are any further dsa_links between a cascade port
of this switch and a cascade port of that switch, they are ignored
(which is a good thing in terms of compatibility between old kernels and
new device trees, but still raises questions).

For each of the functions in the call graph below, we need to determine
exactly what we need to make behave differently (consider a potential
second, third, fourth dsa_link, and how to expose this structure):

                             dsa_port_host_address_match
                              |
                              |  dsa_port_host_vlan_match
                              |   |
                              v   v
                  dsa_switch_is_upstream_of
                  |                        |
                  |                        |
                  | mv88e6xxx_lag_sync_map |
                  v            |           |
          dsa_is_upstream_port |           |
                          |    |           |
   mv88e6xxx_port_vlan    |    |           |
              |           |    |           |
              v           |    |           |
dsa_switch_upstream_port  |    |           |
                     |    |    |           |
                     |    |    |           |
 plenty of drivers   |    |    |           |
               |     |    |    |           |
               v     v    v    |           |
           dsa_upstream_port   |           |
                       |       |           |
                       v       v           |
                     dsa_towards_port      |
                                   |       |
                                   |       |
                                   v       v
                              dsa_routing_port

  reply	other threads:[~2022-09-04 15:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 19:59 [PATCH net-next 0/9] DSA changes for multiple CPU ports (part 4) Vladimir Oltean
2022-08-30 19:59 ` [PATCH net-next 1/9] net: introduce iterators over synced hw addresses Vladimir Oltean
2022-08-30 19:59 ` [PATCH net-next 2/9] net: dsa: introduce dsa_port_get_master() Vladimir Oltean
2022-08-30 19:59 ` [PATCH net-next 3/9] net: dsa: allow the DSA master to be seen and changed through rtnetlink Vladimir Oltean
2022-09-01  3:50   ` Jakub Kicinski
2022-09-01 13:29     ` Vladimir Oltean
2022-08-30 19:59 ` [PATCH net-next 4/9] net: dsa: don't keep track of admin/oper state on LAG DSA masters Vladimir Oltean
2022-08-30 19:59 ` [PATCH net-next 5/9] net: dsa: suppress appending ethtool stats to " Vladimir Oltean
2022-08-30 19:59 ` [PATCH net-next 6/9] net: dsa: suppress device links " Vladimir Oltean
2022-08-30 19:59 ` [PATCH net-next 7/9] net: dsa: allow masters to join a LAG Vladimir Oltean
2022-08-30 19:59 ` [PATCH net-next 8/9] docs: net: dsa: update information about multiple CPU ports Vladimir Oltean
2022-08-30 19:59 ` [PATCH net-next 9/9] net: dsa: felix: add support for changing DSA master Vladimir Oltean
2022-09-02 10:31 ` [PATCH net-next 0/9] DSA changes for multiple CPU ports (part 4) Vladimir Oltean
2022-09-02 18:33   ` Florian Fainelli
2022-09-02 18:40     ` Vladimir Oltean
2022-09-03  2:48   ` Marek Behún
2022-09-04 15:41     ` Vladimir Oltean [this message]
2022-09-02 18:44 ` Christian Marangi
2022-09-03  2:50   ` Marek Behún
2022-09-04 19:34   ` Vladimir Oltean
2022-09-06 16:10     ` Colin Foster
2022-09-06 16:18       ` 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=20220904154115.oybr524635lfrgqp@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=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=john@phrozen.org \
    --cc=kabel@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luizluca@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.org \
    --cc=roopa@nvidia.com \
    --cc=sean.wang@mediatek.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