All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
	netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>, Ido Schimmel <idosch@idosch.org>,
	Tobias Waldekranz <tobias@waldekranz.com>,
	Roopa Prabhu <roopa@nvidia.com>,
	Nikolay Aleksandrov <nikolay@nvidia.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	bridge@lists.linux-foundation.org,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Marek Behun <kabel@blackhole.sk>,
	DENG Qingfang <dqfext@gmail.com>
Subject: Re: [PATCH v4 net-next 13/15] net: dsa: add support for bridge TX forwarding offload
Date: Sun, 18 Jul 2021 19:51:08 -0700	[thread overview]
Message-ID: <f6918f62-0482-f89a-61c6-c4d8071192a8@gmail.com> (raw)
In-Reply-To: <20210718214434.3938850-14-vladimir.oltean@nxp.com>



On 7/18/2021 2:44 PM, Vladimir Oltean wrote:
> For a DSA switch, to offload the forwarding process of a bridge device
> means to send the packets coming from the software bridge as data plane
> packets. This is contrary to everything that DSA has done so far,
> because the current taggers only know to send control packets (ones that
> target a specific destination port), whereas data plane packets are
> supposed to be forwarded according to the FDB lookup, much like packets
> ingressing on any regular ingress port. If the FDB lookup process
> returns multiple destination ports (flooding, multicast), then
> replication is also handled by the switch hardware - the bridge only
> sends a single packet and avoids the skb_clone().
> 
> DSA plays a substantial role in backing the forwarding offload, and
> leaves relatively few things up to the switch driver. In particular, DSA
> keeps for each bridge port a zero-based index (the number of the
> bridge). Multiple ports enslaved to the same bridge have a pointer to
> the same accel_priv structure.
> 
> The tagger can check if the packet that is being transmitted on has
> skb->offload_fwd_mark = true or not. If it does, it can be sure that the
> packet belongs to the data plane of a bridge, further information about
> which can be obtained based on dp->bridge_dev and dp->bridge_num.
> It can then compose a DSA tag for injecting a data plane packet into
> that bridge number.
> 
> For the switch driver side, we offer two new dsa_switch_ops methods,
> called .port_bridge_fwd_offload_{add,del}, which are modeled after
> .port_bridge_{join,leave}.
> These methods are provided in case the driver needs to configure the
> hardware to treat packets coming from that bridge software interface as
> data plane packets. The switchdev <-> bridge interaction happens during
> the netdev_master_upper_dev_link() call, so to switch drivers, the
> effect is that the .port_bridge_fwd_offload_add() method is called
> immediately after .port_bridge_join().
> 
> If the bridge number exceeds the number of bridges for which the switch
> driver can offload the TX data plane (and this includes the case where
> the driver can offload none), DSA falls back to simply returning
> tx_fwd_offload = false in the switchdev_bridge_port_offload() call.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
	netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Jiri Pirko <jiri@resnulli.us>, DENG Qingfang <dqfext@gmail.com>,
	bridge@lists.linux-foundation.org,
	Ido Schimmel <idosch@idosch.org>,
	Nikolay Aleksandrov <nikolay@nvidia.com>,
	Roopa Prabhu <roopa@nvidia.com>, Marek Behun <kabel@blackhole.sk>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Tobias Waldekranz <tobias@waldekranz.com>
Subject: Re: [Bridge] [PATCH v4 net-next 13/15] net: dsa: add support for bridge TX forwarding offload
Date: Sun, 18 Jul 2021 19:51:08 -0700	[thread overview]
Message-ID: <f6918f62-0482-f89a-61c6-c4d8071192a8@gmail.com> (raw)
In-Reply-To: <20210718214434.3938850-14-vladimir.oltean@nxp.com>



On 7/18/2021 2:44 PM, Vladimir Oltean wrote:
> For a DSA switch, to offload the forwarding process of a bridge device
> means to send the packets coming from the software bridge as data plane
> packets. This is contrary to everything that DSA has done so far,
> because the current taggers only know to send control packets (ones that
> target a specific destination port), whereas data plane packets are
> supposed to be forwarded according to the FDB lookup, much like packets
> ingressing on any regular ingress port. If the FDB lookup process
> returns multiple destination ports (flooding, multicast), then
> replication is also handled by the switch hardware - the bridge only
> sends a single packet and avoids the skb_clone().
> 
> DSA plays a substantial role in backing the forwarding offload, and
> leaves relatively few things up to the switch driver. In particular, DSA
> keeps for each bridge port a zero-based index (the number of the
> bridge). Multiple ports enslaved to the same bridge have a pointer to
> the same accel_priv structure.
> 
> The tagger can check if the packet that is being transmitted on has
> skb->offload_fwd_mark = true or not. If it does, it can be sure that the
> packet belongs to the data plane of a bridge, further information about
> which can be obtained based on dp->bridge_dev and dp->bridge_num.
> It can then compose a DSA tag for injecting a data plane packet into
> that bridge number.
> 
> For the switch driver side, we offer two new dsa_switch_ops methods,
> called .port_bridge_fwd_offload_{add,del}, which are modeled after
> .port_bridge_{join,leave}.
> These methods are provided in case the driver needs to configure the
> hardware to treat packets coming from that bridge software interface as
> data plane packets. The switchdev <-> bridge interaction happens during
> the netdev_master_upper_dev_link() call, so to switch drivers, the
> effect is that the .port_bridge_fwd_offload_add() method is called
> immediately after .port_bridge_join().
> 
> If the bridge number exceeds the number of bridges for which the switch
> driver can offload the TX data plane (and this includes the case where
> the driver can offload none), DSA falls back to simply returning
> tx_fwd_offload = false in the switchdev_bridge_port_offload() call.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

  reply	other threads:[~2021-07-19  2:51 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-18 21:44 [PATCH v4 net-next 00/15] Allow forwarding for the software bridge data path to be offloaded to capable devices Vladimir Oltean
2021-07-18 21:44 ` [Bridge] " Vladimir Oltean
2021-07-18 21:44 ` [PATCH v4 net-next 01/15] net: dpaa2-switch: use extack in dpaa2_switch_port_bridge_join Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  9:17   ` Ioana Ciornei
2021-07-19  9:17     ` [Bridge] " Ioana Ciornei
2021-07-18 21:44 ` [PATCH v4 net-next 02/15] net: dpaa2-switch: refactor prechangeupper sanity checks Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  9:18   ` Ioana Ciornei
2021-07-19  9:18     ` [Bridge] " Ioana Ciornei
2021-07-18 21:44 ` [PATCH v4 net-next 03/15] mlxsw: spectrum: " Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-18 21:44 ` [PATCH v4 net-next 04/15] mlxsw: spectrum: refactor leaving an 8021q upper that is a bridge port Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  2:16   ` Florian Fainelli
2021-07-19  2:16     ` [Bridge] " Florian Fainelli
2021-07-18 21:44 ` [PATCH v4 net-next 05/15] net: marvell: prestera: refactor prechangeupper sanity checks Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  2:20   ` Florian Fainelli
2021-07-19  2:20     ` [Bridge] " Florian Fainelli
2021-07-18 21:44 ` [PATCH v4 net-next 06/15] net: switchdev: guard drivers against multiple obj replays on same bridge port Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  2:17   ` Florian Fainelli
2021-07-19  2:17     ` [Bridge] " Florian Fainelli
2021-07-18 21:44 ` [PATCH v4 net-next 07/15] net: bridge: disambiguate offload_fwd_mark Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  2:26   ` Florian Fainelli
2021-07-19  2:26     ` [Bridge] " Florian Fainelli
2021-07-18 21:44 ` [PATCH v4 net-next 08/15] net: bridge: switchdev: recycle unused hwdoms Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-18 21:44 ` [PATCH v4 net-next 09/15] net: bridge: switchdev: let drivers inform which bridge ports are offloaded Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  9:23   ` Ioana Ciornei
2021-07-19  9:23     ` [Bridge] " Ioana Ciornei
2021-07-20  7:53   ` Horatiu Vultur
2021-07-20  7:53     ` [Bridge] " Horatiu Vultur
2021-07-20  8:45     ` Vladimir Oltean
2021-07-20  8:45       ` [Bridge] " Vladimir Oltean
2021-07-18 21:44 ` [PATCH v4 net-next 10/15] net: bridge: switchdev object replay helpers for everybody Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  8:19   ` Vladimir Oltean
2021-07-19  8:19     ` [Bridge] " Vladimir Oltean
2021-07-19  9:26   ` Ioana Ciornei
2021-07-19  9:26     ` [Bridge] " Ioana Ciornei
2021-07-18 21:44 ` [PATCH v4 net-next 11/15] net: bridge: switchdev: allow the TX data plane forwarding to be offloaded Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  2:43   ` Florian Fainelli
2021-07-19  2:43     ` [Bridge] " Florian Fainelli
2021-07-19  7:22   ` Vladimir Oltean
2021-07-19  7:22     ` [Bridge] " Vladimir Oltean
2021-07-18 21:44 ` [PATCH v4 net-next 12/15] net: dsa: track the number of switches in a tree Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  2:54   ` Florian Fainelli
2021-07-19  2:54     ` [Bridge] " Florian Fainelli
2021-07-18 21:44 ` [PATCH v4 net-next 13/15] net: dsa: add support for bridge TX forwarding offload Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  2:51   ` Florian Fainelli [this message]
2021-07-19  2:51     ` Florian Fainelli
2021-07-18 21:44 ` [PATCH v4 net-next 14/15] net: dsa: mv88e6xxx: map virtual bridges with forwarding offload in the PVT Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  2:52   ` Florian Fainelli
2021-07-19  2:52     ` [Bridge] " Florian Fainelli
2021-07-18 21:44 ` [PATCH v4 net-next 15/15] net: dsa: tag_dsa: offload the bridge forwarding process Vladimir Oltean
2021-07-18 21:44   ` [Bridge] " Vladimir Oltean
2021-07-19  2:47   ` Florian Fainelli
2021-07-19  2:47     ` [Bridge] " Florian Fainelli
2021-07-19  7:41     ` Vladimir Oltean
2021-07-19  7:41       ` [Bridge] " Vladimir Oltean
2021-07-20 11:24 ` [PATCH v4 net-next 00/15] Allow forwarding for the software bridge data path to be offloaded to capable devices Ido Schimmel
2021-07-20 11:24   ` [Bridge] " Ido Schimmel
2021-07-20 13:20   ` Vladimir Oltean
2021-07-20 13:20     ` [Bridge] " Vladimir Oltean
2021-07-20 13:51     ` Ido Schimmel
2021-07-20 13:51       ` [Bridge] " Ido Schimmel

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=f6918f62-0482-f89a-61c6-c4d8071192a8@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=grygorii.strashko@ti.com \
    --cc=idosch@idosch.org \
    --cc=jiri@resnulli.us \
    --cc=kabel@blackhole.sk \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@nvidia.com \
    --cc=roopa@nvidia.com \
    --cc=stephen@networkplumber.org \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.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.