From: Ido Schimmel <idosch@idosch.org> To: Vladimir Oltean <olteanv@gmail.com> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>, netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>, "David S. Miller" <davem@davemloft.net>, Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>, Vivien Didelot <vivien.didelot@gmail.com>, Jiri Pirko <jiri@resnulli.us>, 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>, Vadym Kochan <vkochan@marvell.com>, Taras Chornyi <tchornyi@marvell.com>, Ioana Ciornei <ioana.ciornei@nxp.com>, Lars Povlsen <lars.povlsen@microchip.com>, Steen Hegelund <Steen.Hegelund@microchip.com>, UNGLinuxDriver@microchip.com, Claudiu Manoil <claudiu.manoil@nxp.com>, Alexandre Belloni <alexandre.belloni@bootlin.com> Subject: Re: [PATCH v4 net-next 00/15] Allow forwarding for the software bridge data path to be offloaded to capable devices Date: Tue, 20 Jul 2021 16:51:23 +0300 [thread overview] Message-ID: <YPbU20/cjkz04s8b@shredder> (raw) In-Reply-To: <20210720132026.mpk3iq3z6vmmzxyd@skbuf> On Tue, Jul 20, 2021 at 04:20:26PM +0300, Vladimir Oltean wrote: > On Tue, Jul 20, 2021 at 02:24:29PM +0300, Ido Schimmel wrote: > > Too many things are squashed into this one patchset. It needs to be > > split. > > > > The TX forwarding offload in mv88e6xxx is not related to the replay > > stuff and should be added in a separate patchset. This can be done by > > first adding the switchdev_bridge_port_offload() / > > switchdev_bridge_port_unoffload() APIs that only take care of setting / > > unsetting the hardware domain for the bridge port. Then, in a different > > patchset, these APIs can be augmented with a parameter for the replay > > stuff. It should be easier to review that way and require less > > unnecessary surgeries in drivers that do not require the added > > functionality. > > Fair point. I will submit patches 1-10 and 11-15 separately. Not sure if you mean in that order or not, but I suggested first getting the TX forwarding offload (patches 11-15) in and then extending the new APIs with replay argument so that drivers can opt-in. This should reduce the complexity of the second patchset and make it less likely to introduce bugs. > > > According to the title, the patchset is focused on improving > > performance, but there are no performance numbers that I could see and > > most of the patches deal with the replay stuff instead. > > Maybe, but the truth is that it is not really the performance > improvement that I care about. The performance quote is from Tobias' > original cover letter, which I took as-is. I can build a synthetic test > for multicasting on 10 mv88e6xxx ports or something like that, or maybe > Tobias can provide a more relevant example out of Westermo's use cases. > But it would be silly if this patchset's acceptance would depend on the > numbers. This is one of those cases where completely different interests > led me and Tobias to the the same solution. > > I don't want to bore you to death with details, but for some switches > (DSA or otherwise), being able to send bridge packets as they are (data > plane packets) instead of what they aren't (control plane packets) is a > matter of functionality and not performance. Such switches only use > control plane packets for link-local packet traps, and sending/receiving > a control packet is expensive. > > For this class of switches (some may call them "dumb", but whatever), > this patch series makes the difference between supporting and not > supporting local IP termination through a VLAN-aware bridge, bridging > with a foreign interface, bridging with software upper interfaces like > LAG, etc. OK, so this can be mentioned in the cover letter as well as an argument for the feature. Wanted to make sure the patches were actually tested given Tobias was the first to publish them and I'm not sure if he tested them in the new form or if you have the required hardware.
WARNING: multiple messages have this Message-ID (diff)
From: Ido Schimmel <idosch@idosch.org> To: Vladimir Oltean <olteanv@gmail.com> Cc: Andrew Lunn <andrew@lunn.ch>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Vladimir Oltean <vladimir.oltean@nxp.com>, Ioana Ciornei <ioana.ciornei@nxp.com>, Marek Behun <kabel@blackhole.sk>, Florian Fainelli <f.fainelli@gmail.com>, "David S. Miller" <davem@davemloft.net>, Steen Hegelund <Steen.Hegelund@microchip.com>, bridge@lists.linux-foundation.org, Nikolay Aleksandrov <nikolay@nvidia.com>, Roopa Prabhu <roopa@nvidia.com>, Jakub Kicinski <kuba@kernel.org>, Vivien Didelot <vivien.didelot@gmail.com>, Grygorii Strashko <grygorii.strashko@ti.com>, Jiri Pirko <jiri@resnulli.us>, Vadym Kochan <vkochan@marvell.com>, DENG Qingfang <dqfext@gmail.com>, Claudiu Manoil <claudiu.manoil@nxp.com>, Lars Povlsen <lars.povlsen@microchip.com>, netdev@vger.kernel.org, UNGLinuxDriver@microchip.com, Taras Chornyi <tchornyi@marvell.com>, Tobias Waldekranz <tobias@waldekranz.com> Subject: Re: [Bridge] [PATCH v4 net-next 00/15] Allow forwarding for the software bridge data path to be offloaded to capable devices Date: Tue, 20 Jul 2021 16:51:23 +0300 [thread overview] Message-ID: <YPbU20/cjkz04s8b@shredder> (raw) In-Reply-To: <20210720132026.mpk3iq3z6vmmzxyd@skbuf> On Tue, Jul 20, 2021 at 04:20:26PM +0300, Vladimir Oltean wrote: > On Tue, Jul 20, 2021 at 02:24:29PM +0300, Ido Schimmel wrote: > > Too many things are squashed into this one patchset. It needs to be > > split. > > > > The TX forwarding offload in mv88e6xxx is not related to the replay > > stuff and should be added in a separate patchset. This can be done by > > first adding the switchdev_bridge_port_offload() / > > switchdev_bridge_port_unoffload() APIs that only take care of setting / > > unsetting the hardware domain for the bridge port. Then, in a different > > patchset, these APIs can be augmented with a parameter for the replay > > stuff. It should be easier to review that way and require less > > unnecessary surgeries in drivers that do not require the added > > functionality. > > Fair point. I will submit patches 1-10 and 11-15 separately. Not sure if you mean in that order or not, but I suggested first getting the TX forwarding offload (patches 11-15) in and then extending the new APIs with replay argument so that drivers can opt-in. This should reduce the complexity of the second patchset and make it less likely to introduce bugs. > > > According to the title, the patchset is focused on improving > > performance, but there are no performance numbers that I could see and > > most of the patches deal with the replay stuff instead. > > Maybe, but the truth is that it is not really the performance > improvement that I care about. The performance quote is from Tobias' > original cover letter, which I took as-is. I can build a synthetic test > for multicasting on 10 mv88e6xxx ports or something like that, or maybe > Tobias can provide a more relevant example out of Westermo's use cases. > But it would be silly if this patchset's acceptance would depend on the > numbers. This is one of those cases where completely different interests > led me and Tobias to the the same solution. > > I don't want to bore you to death with details, but for some switches > (DSA or otherwise), being able to send bridge packets as they are (data > plane packets) instead of what they aren't (control plane packets) is a > matter of functionality and not performance. Such switches only use > control plane packets for link-local packet traps, and sending/receiving > a control packet is expensive. > > For this class of switches (some may call them "dumb", but whatever), > this patch series makes the difference between supporting and not > supporting local IP termination through a VLAN-aware bridge, bridging > with a foreign interface, bridging with software upper interfaces like > LAG, etc. OK, so this can be mentioned in the cover letter as well as an argument for the feature. Wanted to make sure the patches were actually tested given Tobias was the first to publish them and I'm not sure if he tested them in the new form or if you have the required hardware.
next prev parent reply other threads:[~2021-07-20 13:53 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 2021-07-19 2:51 ` [Bridge] " 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 [this message] 2021-07-20 13:51 ` 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=YPbU20/cjkz04s8b@shredder \ --to=idosch@idosch.org \ --cc=Steen.Hegelund@microchip.com \ --cc=UNGLinuxDriver@microchip.com \ --cc=alexandre.belloni@bootlin.com \ --cc=andrew@lunn.ch \ --cc=bridge@lists.linux-foundation.org \ --cc=claudiu.manoil@nxp.com \ --cc=davem@davemloft.net \ --cc=dqfext@gmail.com \ --cc=f.fainelli@gmail.com \ --cc=grygorii.strashko@ti.com \ --cc=ioana.ciornei@nxp.com \ --cc=jiri@resnulli.us \ --cc=kabel@blackhole.sk \ --cc=kuba@kernel.org \ --cc=lars.povlsen@microchip.com \ --cc=netdev@vger.kernel.org \ --cc=nikolay@nvidia.com \ --cc=olteanv@gmail.com \ --cc=roopa@nvidia.com \ --cc=stephen@networkplumber.org \ --cc=tchornyi@marvell.com \ --cc=tobias@waldekranz.com \ --cc=vivien.didelot@gmail.com \ --cc=vkochan@marvell.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: linkBe 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.