[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200920233340.ddps7yxoqlbvmv7m@skbuf>
Date: Sun, 20 Sep 2020 23:33:41 +0000
From: Vladimir Oltean <vladimir.oltean@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: netdev <netdev@...r.kernel.org>,
Florian Fainelli <f.fainelli@...il.com>,
Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...dia.com>,
Chris Healy <cphealy@...il.com>
Subject: Re: [PATCH net-next RFC v1 0/4] Add per port devlink regions
On Sat, Sep 19, 2020 at 04:43:28PM +0200, Andrew Lunn wrote:
>
> DSA only instantiates devlink ports for switch ports which are used.
> For this hardware, only 4 user ports and the CPU port have devlink
> ports, which explains the discontinuous port regions.
This is not so much a choice, as it is a workaround of the fact that
dsa_port_setup(), which registers devlink ports with devlink, is called
after ds->ops->setup(), so you can't register your port regions from
the same place as the global regions now.
So you're doing it from ds->ops->port_enable(), which is the DSA wrapper
for .ndo_open(). So, consequently, your port regions will only be
registered when the port is up, and will be unregistered when it goes
down. Is that what you want? I understand that users probably think they
want to debug only the ports that they actively use, but I've heard of
at least one problem in the past which was caused by invalid settings
(flooding in that case) on a port that was down. Sure, this is probably
a rare situation, but as I said, somebody trying to use port regions to
debug something like that is probably going to have a hard time, because
it isn't an easy surgery to figure the probe ordering out.
Thanks,
-Vladimir
Powered by blists - more mailing lists