Re: [PATCH v4 net-next 00/15] Allow forwarding for the software bridge data path to be offloaded to capable devices

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:

quoted

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.

quoted

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.