On Tue, May 19, 2020 at 04:15:41PM +0200, Andrew Lunn wrote: > > +# Test port split configuration using devlink-port width attribute. > > +# The test is skipped in case the attribute is not available. > > +# > > +# First, check that all the ports with a width of 1 fail to split. > > +# Second, check that all the ports with a width larger than 1 can be split > > +# to all valid configurations (e.g., split to 2, split to 4 etc.) > > Hi Ido
Hi Andrew, > > I know very little about splitting ports. So these might be dumb > questions. > > Is there a well defined meaning of width? Is it something which can be > found in an 802.3 standard? It's basically the number of lanes: If a port is a 100Gbps port and has a width of 4, then every lane is running at 25Gbps. Splitting this port to 4 (via 'devlink port split') allows you to get 4 ports each capable of supporting speeds up to 25Gbps (the original netdev disappears). Example splitter cable: https://www.mellanox.com/related-docs/prod_cables/PB_MCP7F00-A0xxRyyz_100GbE_QSFP28_to_4x25GbE_4xSFP28_DAC_Splitter.pdf Some documentation from mlxsw Wiki: https://github.com/Mellanox/mlxsw/wiki/Switch-Port-Configuration#port-splitting > Is it well defined that all splits of the for 2, 4, 8 have to be > supported? That I don't actually know. It is true for Mellanox and I can only assume it holds for other vendors. So far beside mlxsw only nfp implemented port_split() callback. I see it has this check: ``` if (eth_port.is_split || eth_port.port_lanes % count) { ret = -EINVAL; goto out; } ``` So it seems to be consistent with mlxsw. Jakub will hopefully chime in and keep me honest. > Must all 40Gbps ports with a width of 4, be splitable to 2x > 20Mps? It seems like some hardware might only allow 4x 10G? Possible. There are many vendor-specific quirks in this area, as I'm sure you know :) > > If 20Gbps is supported, can you then go recursive and split one of the > 20G ports into 2x 10G, leaving the other as a 20G port? Quite certain this is not supported by any vendor. I assume you're asking because you are trying to see if the test is not making some vendor-specific assumptions? Personally, I think it's not. We decided to put it under net/ rather than drivers/net/mlxsw because we always prefer to write tests that can be shared with others. This is what actually motivated this work. We had a very Mellanox-specific test in our regression and we wanted to remove it, but it was not possible to write such a test without this attribute.
