netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Ansuel Smith <ansuelsmth@gmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [RFC PATCH net-next 0/7] DSA master state tracking
Date: Thu, 9 Dec 2021 17:56:17 +0000	[thread overview]
Message-ID: <20211209175617.652rdiidc6pfgdwz@skbuf> (raw)
In-Reply-To: <61b24089.1c69fb81.c8040.164b@mx.google.com>

On Thu, Dec 09, 2021 at 06:44:38PM +0100, Ansuel Smith wrote:
> > I think the problem is that we also need to track the operstate of the
> > master (netif_oper_up via NETDEV_CHANGE) before declaring it as good to go.
> > You can see that this is exactly the line after which the timeouts disappear:
> > 
> > [    7.146901] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > 
> > I didn't really want to go there, because now I'm not sure how to
> > synthesize the information for the switch drivers to consume it.
> > Anyway I've prepared a v2 patchset and I'll send it out very soon.
> 
> Wonder if we should leave the driver decide when it's ready by parsing
> the different state? (And change
> the up ops to something like a generic change?)

There isn't just one state to track, which is precisely the problem that
I had to deal with for v2. The master is operational during the time
frame between NETDEV_UP and NETDEV_GOING_DOWN, intersected with the
interval during which netif_oper_up(master) is true. So in the simple
state propagation approach, DSA would need to provide at least two ops
to switches, one for admin state and the other for oper state. And the
switch driver would need to AND the two and keep state by itself.
Letting the driver make the decision would have been acceptable to me if
we could have 3 ops and a common implementation, something like this:

static void qca8k_master_state_change(struct dsa_switch *ds,
				      const struct dsa_master *master)
{
	bool operational = (master->flags & IFF_UP) && netif_oper_up(master);
}

	.master_admin_state_change	= qca8k_master_state_change,
	.master_oper_state_change	= qca8k_master_state_change,

but the problem is that during NETDEV_GOING_DOWN, master->flags & IFF_UP
is still true, so this wouldn't work. And replacing the NETDEV_GOING_DOWN
notifier with the NETDEV_DOWN one would solve that problem, but it would
no longer guarantee that the switch can disable this feature without
timeouts before the master is down - because now it _is_ down.

  reply	other threads:[~2021-12-09 17:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08 22:32 [RFC PATCH net-next 0/7] DSA master state tracking Vladimir Oltean
2021-12-08 22:32 ` [RFC PATCH net-next 1/7] net: dsa: only bring down user ports assigned to a given DSA master Vladimir Oltean
2021-12-08 22:32 ` [RFC PATCH net-next 2/7] net: dsa: refactor the NETDEV_GOING_DOWN master tracking into separate function Vladimir Oltean
2021-12-08 22:32 ` [RFC PATCH net-next 3/7] net: dsa: use dsa_tree_for_each_user_port in dsa_tree_master_going_down() Vladimir Oltean
2021-12-08 22:32 ` [RFC PATCH net-next 4/7] net: dsa: provide switch operations for tracking the master state Vladimir Oltean
2021-12-08 22:32 ` [RFC PATCH net-next 5/7] net: dsa: stop updating master MTU from master.c Vladimir Oltean
2021-12-08 22:32 ` [RFC PATCH net-next 6/7] net: dsa: hold rtnl_mutex when calling dsa_master_{setup,teardown} Vladimir Oltean
2021-12-08 22:32 ` [RFC PATCH net-next 7/7] net: dsa: replay master state events in dsa_tree_{setup,teardown}_master Vladimir Oltean
2021-12-09  3:05 ` [RFC PATCH net-next 0/7] DSA master state tracking Ansuel Smith
2021-12-09 14:28   ` Vladimir Oltean
2021-12-09 14:44     ` Ansuel Smith
2021-12-09 17:33       ` Vladimir Oltean
2021-12-09 17:44         ` Ansuel Smith
2021-12-09 17:56           ` Vladimir Oltean [this message]
2021-12-09 18:16             ` Ansuel Smith
2021-12-09 17:57           ` Vladimir Oltean
2021-12-09 18:34             ` Ansuel Smith

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=20211209175617.652rdiidc6pfgdwz@skbuf \
    --to=vladimir.oltean@nxp.com \
    --cc=andrew@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).