All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Machata <petrm@mellanox.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>
Cc: Jiri Pirko <jiri@mellanox.com>,
	Ido Schimmel <idosch@mellanox.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
	"ruxandra.radulescu@nxp.com" <ruxandra.radulescu@nxp.com>,
	"ioana.ciornei@nxp.com" <ioana.ciornei@nxp.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"ivecera@redhat.com" <ivecera@redhat.com>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"vivien.didelot@savoirfairelinux.com"
	<vivien.didelot@savoirfairelinux.com>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>
Subject: [PATCH net-next 00/12] switchdev: Convert switchdev_port_obj_{add,del}() to notifiers
Date: Thu, 22 Nov 2018 23:27:52 +0000	[thread overview]
Message-ID: <cover.1542927590.git.petrm@mellanox.com> (raw)

An offloading driver may need to have access to switchdev events on
ports that aren't directly under its control. An example is a VXLAN port
attached to a bridge offloaded by a driver. The driver needs to know
about VLANs configured on the VXLAN device. However the VXLAN device
isn't stashed between the bridge and a front-panel-port device (such as
is the case e.g. for LAG devices), so the usual switchdev ops don't
reach the driver.

VXLAN is likely not the only device type like this: in theory any L2
tunnel device that needs offloading will prompt requirement of this
sort.

A way to fix this is to give up the notion of port object addition /
deletion as a switchdev operation, which assumes somewhat tight coupling
between the message producer and consumer. And instead send the message
over a notifier chain.

The series starts with a clean-up patch #1, where
SWITCHDEV_OBJ_PORT_{VLAN, MDB}() are fixed up to lift the constraint
that the passed-in argument be a simple variable named "obj".

switchdev_port_obj_add and _del are invoked in a context that permits
blocking. Not only that, at least for the VLAN notification, being able
to signal failure is actually important. Therefore introduce a new
blocking notifier chain that the new events will be sent on. That's done
in patch #2. Retain the current (atomic) notifier chain for the
preexisting notifications.

In patch #3, introduce two new switchdev notifier types,
SWITCHDEV_PORT_OBJ_ADD and SWITCHDEV_PORT_OBJ_DEL. These notifier types
communicate the same event as the corresponding switchdev op, except in
a form of a notification. struct switchdev_notifier_port_obj_info was
added to carry the fields that correspond to the switchdev op arguments.
An additional field, handled, will be used to communicate back to
switchdev that the event has reached an interested party, which will be
important for the two-phase commit.

In patches #4, #5, and #7, rocker, DSA resp. ethsw are updated to
subscribe to the switchdev blocking notifier chain, and handle the new
notifier types. #6 introduces a helper to determine whether a
netdevice corresponds to a front panel port.

What these three drivers have in common is that their ports don't
support any uppers besides bridge. That makes it possible to ignore any
notifiers that don't reference a front-panel port device, because they
are certainly out of scope.

Unlike the previous three, mlxsw and ocelot drivers admit stacked
devices as uppers. While the current switchdev code recursively descends
through layers of lower devices, eventually calling the op on a
front-panel port device, the notifier would reference a stacking device
that's one of front-panel ports uppers. The filtering is thus more
complex.

For ocelot, such iteration is currently pretty much required, because
there's no bookkeeping of LAG devices. mlxsw does keep the list of LAGs,
however it iterates the lower devices anyway when deciding whether an
event on a tunnel device pertains to the driver or not.

Therefore this patch set instead introduces, in patch #8, a helper to
iterate through lowers, much like the current switchdev code does,
looking for devices that match a given predicate.

Then in patches #9 and #10, first mlxsw and then ocelot are updated to
dispatch the newly-added notifier types to the preexisting
port_obj_add/_del handlers. The dispatch is done via the new helper, to
recursively descend through lower devices.

Finally in patch #11, the actual switch is made, retiring the current
SDO-based code in favor of a notifier.

Now that the event is distributed through a notifier, the explicit
netdevice check in rocker, DSA and ethsw doesn't let through any events
except those done on a front-panel port itself. It is therefore
unnecessary to check in VLAN-handling code whether a VLAN was added to
the bridge itself: such events will simply be ignored much sooner.
Therefore remove it in patch #12.

Petr Machata (12):
  switchdev: SWITCHDEV_OBJ_PORT_{VLAN, MDB}(): Sanitize
  switchdev: Add a blocking notifier chain
  switchdev: Add SWITCHDEV_PORT_OBJ_ADD, SWITCHDEV_PORT_OBJ_DEL
  rocker: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL
  net: dsa: slave: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL
  staging: fsl-dpaa2: ethsw: Introduce ethsw_port_dev_check()
  staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL
  switchdev: Add helpers to aid traversal through lower devices
  mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL
  ocelot: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL
  switchdev: Replace port obj add/del SDO with a notification
  rocker, dsa, ethsw: Don't filter VLAN events on bridge itself

 .../ethernet/mellanox/mlxsw/spectrum_switchdev.c   |  47 ++++-
 drivers/net/ethernet/mscc/ocelot.c                 |  30 +++-
 drivers/net/ethernet/mscc/ocelot.h                 |   1 +
 drivers/net/ethernet/mscc/ocelot_board.c           |   3 +
 drivers/net/ethernet/rocker/rocker_main.c          |  60 ++++++-
 drivers/staging/fsl-dpaa2/ethsw/ethsw.c            |  68 +++++++-
 include/net/switchdev.h                            |  87 ++++++++--
 net/dsa/port.c                                     |   3 -
 net/dsa/slave.c                                    |  58 ++++++-
 net/switchdev/switchdev.c                          | 193 ++++++++++++++++-----
 10 files changed, 474 insertions(+), 76 deletions(-)

-- 
2.4.11

             reply	other threads:[~2018-11-23 10:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22 23:27 Petr Machata [this message]
2018-11-22 23:28 ` [PATCH net-next 01/12] switchdev: SWITCHDEV_OBJ_PORT_{VLAN, MDB}(): Sanitize Petr Machata
2018-11-22 23:28 ` [PATCH net-next 02/12] switchdev: Add a blocking notifier chain Petr Machata
2018-11-22 23:28 ` [PATCH net-next 03/12] switchdev: Add SWITCHDEV_PORT_OBJ_ADD, SWITCHDEV_PORT_OBJ_DEL Petr Machata
2018-11-22 23:28 ` [PATCH net-next 04/12] rocker: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL Petr Machata
2018-11-22 23:29 ` [PATCH net-next 05/12] net: dsa: slave: " Petr Machata
2018-11-22 23:29 ` [PATCH net-next 06/12] staging: fsl-dpaa2: ethsw: Introduce ethsw_port_dev_check() Petr Machata
2018-11-22 23:29 ` [PATCH net-next 07/12] staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL Petr Machata
2018-11-22 23:29 ` [PATCH net-next 08/12] switchdev: Add helpers to aid traversal through lower devices Petr Machata
2018-11-22 23:29 ` [PATCH net-next 09/12] mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL Petr Machata
2018-11-22 23:30 ` [PATCH net-next 10/12] ocelot: " Petr Machata
2018-11-22 23:32 ` [PATCH net-next 11/12] switchdev: Replace port obj add/del SDO with a notification Petr Machata
2018-11-22 23:48 ` [PATCH net-next 12/12] rocker, dsa, ethsw: Don't filter VLAN events on bridge itself Petr Machata
2018-11-23  1:40 ` [PATCH net-next 00/12] switchdev: Convert switchdev_port_obj_{add,del}() to notifiers Petr Machata
2018-11-24  2:02 ` David Miller

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=cover.1542927590.git.petrm@mellanox.com \
    --to=petrm@mellanox.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=f.fainelli@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=idosch@mellanox.com \
    --cc=ioana.ciornei@nxp.com \
    --cc=ivecera@redhat.com \
    --cc=jiri@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=ruxandra.radulescu@nxp.com \
    --cc=vivien.didelot@savoirfairelinux.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.