Re: [RFC PATCH net-next 2/4] net: dsa: remove the "dsa_to_port in a loop" antipattern from the core

On Tue, Aug 10, 2021 at 02:35:32PM +0300, Vladimir Oltean wrote:

On Tue, Aug 10, 2021 at 02:41:07AM -0700, Florian Fainelli wrote:

quoted

On 8/9/2021 8:33 PM, DENG Qingfang wrote:

quoted

On Mon, Aug 09, 2021 at 10:03:18PM +0300, Vladimir Oltean wrote:

quoted

Ever since Vivien's conversion of the ds->ports array into a dst->ports
list, and the introduction of dsa_to_port, iterations through the ports
of a switch became quadratic whenever dsa_to_port was needed.

So, what is the benefit of a linked list here? Do we allow users to
insert/delete a dsa_port at runtime? If not, how about using a
dynamically allocated array instead?

The goal was to flatten the space while doing cross switch operations, which
would have otherwise required iterating over dsa_switch instances within a
dsa_switch_tree, and then over dsa_port within each dsa_switch.

To expand on that: technically dsa_port_touch() _does_ happen at
runtime, since multiple switches in a cross-chip tree probe
asynchronously. To use a dynamically allocated array would mean to
preallocate the sum of all DSA switch ports' worth of memory, and to
preallocate an index for each DSA switch within that single array.
Overall a list is simpler.

If I were to guess where Qingfang was hinting at, is that the receive
path now needs to iterate over a list, whereas before it simply indexed
an array:

static inline struct net_device *dsa_master_find_slave(struct net_device *dev,
						       int device, int port)
{
	struct dsa_port *cpu_dp = dev->dsa_ptr;
	struct dsa_switch_tree *dst = cpu_dp->dst;
	struct dsa_port *dp;

	list_for_each_entry(dp, &dst->ports, list)
		if (dp->ds->index == device && dp->index == port &&
		    dp->type == DSA_PORT_TYPE_USER)
			return dp->slave;

	return NULL;
}

I will try in the following days to make a prototype implementation of
converting back the linked list into an array and see if there is any
justifiable performance improvement.

[ even if this would make the "multiple CPU ports in LAG" implementation
  harder ]