[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220818154911.2973417-1-vladimir.oltean@nxp.com>
Date: Thu, 18 Aug 2022 18:49:01 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: netdev@...r.kernel.org
Cc: Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Kevin Hilman <khilman@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: [RFC PATCH net-next 00/10] Use robust notifiers in DSA
The DSA framework manages groups of switch devices called trees, and
when an event occurs on one switch, it notifies all the other switches
in that tree through something called cross-chip notifiers, so that they
can react on that change too.
Sometimes switches other than the one who originated a change can reject
that change, and DSA must restore the tree to the previous state. Right
now, it either doesn't always do that consistently, or it does that, by
emitting a second cross-chip notifier with the previous state (which is
handled even by switches which already *are* at the previous state,
since the notifier chain broke earlier).
The status quo has caused bugs like the one fixed in commit 4c46bb49460e
("net: dsa: felix: suppress non-changes to the tagging protocol"), and
this has led to me trying to improve things.
I am introducing a _robust() variant of the functions that emit
cross-chip notifiers, which performs better rollback. But we still need
the non-robust notifiers for things that are not expected to fail, so I
am also making the non-robust variants return void.
I am posting this as RFC because something still feels off, but I can't
exactly pinpoint what, and I'm looking for some feedback. Since most DSA
switches are behind I/O protocols that can fail or time out (SPI, I2C,
MDIO etc), everything can fail; that's a fact. On the other hand, when
a network device or the entire system is torn down, nobody cares that
SPI I/O failed - the system is still shutting down; that is also a fact.
I'm not quite sure how to reconcile the two. On one hand we're
suppressing errors emitted by DSA drivers in the non-robust form of
notifiers, and on the other hand there's nothing we can do about them
either way (upper layers don't necessarily care).
Vladimir Oltean (10):
notifier: allow robust variants to take a different void *v argument
on rollback
net: dsa: introduce and use robust form of dsa_tree_notify()
net: dsa: introduce and use robust form of dsa_broadcast()
net: dsa: introduce and use robust form of dsa_port_notify()
Revert "net: dsa: felix: suppress non-changes to the tagging protocol"
net: dsa: convert switch.c functions to return void if they can
net: dsa: remove "breaking chain" comment from dsa_switch_event
net: dsa: introduce a robust form of MTU cross-chip notifiers
net: dsa: make dsa_tree_notify() and derivatives return void
net: dsa: make _del variants of functions return void
drivers/base/power/domain.c | 4 +-
drivers/net/dsa/ocelot/felix.c | 3 -
include/linux/notifier.h | 8 +-
kernel/cpu_pm.c | 3 +-
kernel/module/main.c | 4 +-
kernel/notifier.c | 21 ++--
kernel/power/main.c | 3 +-
net/core/dev.c | 2 +-
net/dsa/dsa2.c | 156 ++++++++++++++++++++----
net/dsa/dsa_priv.h | 56 +++++----
net/dsa/port.c | 213 ++++++++++++++++++---------------
net/dsa/slave.c | 81 +++++--------
net/dsa/switch.c | 27 ++---
net/dsa/tag_8021q.c | 8 +-
14 files changed, 348 insertions(+), 241 deletions(-)
--
2.34.1
Powered by blists - more mailing lists