Message-ID: <20210129072015.GA4652@nanopsycho.orion>
Date:   Fri, 29 Jan 2021 08:20:15 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     David Ahern <dsahern@...il.com>, Jakub Kicinski <kuba@...nel.org>,
        netdev@...r.kernel.org, davem@...emloft.net,
        jacob.e.keller@...el.com, roopa@...dia.com, mlxsw@...dia.com,
        vadimp@...dia.com
Subject: Re: [patch net-next RFC 00/10] introduce line card support for
 modular switch

Thu, Jan 28, 2021 at 03:17:13PM CET, andrew@...n.ch wrote:
>On Thu, Jan 28, 2021 at 09:14:34AM +0100, Jiri Pirko wrote:
>> Wed, Jan 27, 2021 at 03:14:34PM CET, andrew@...n.ch wrote:
>> >> >There are Linux standard APIs for controlling the power to devices,
>> >> >the regulator API. So i assume mlxreg-pm will make use of that. There
>> >> >are also standard APIs for thermal management, which again, mlxreg-pm
>> >> >should be using. The regulator API allows you to find regulators by
>> >> >name. So just define a sensible naming convention, and the switch
>> >> >driver can lookup the regulator, and turn it on/off as needed.
>> >> 
>> >> 
>> >> I don't think it would apply. The thing is, i2c driver has a channel to
>> >> the linecard eeprom, from where it can read info about the linecard. The
>> >> i2c driver also knows when the linecard is plugged in, unlike mlxsw.
>> >> It acts as a standalone driver. Mlxsw has no way to directly find if the
>> >> card was plugged in (unpowered) and which type it is.
>> >> 
>> >> Not sure how to "embed" it. I don't think any existing API could help.
>> >> Basicall mlxsw would have to register a callback to the i2c driver
>> >> called every time card is inserted to do auto-provision.
>> >> Now consider a case when there are multiple instances of the ASIC on the
>> >> system. How to assemble a relationship between mlxsw instance and i2c
>> >> driver instance?
>> >
>> >You have that knowledge already, otherwise you cannot solve this
>> 
>> No I don't have it. I'm not sure why do you say so. The mlxsw and i2c
>> driver act independently.
>
>Ah, so you just export some information in /sys from the i2c driver?
>And you expect the poor user to look at the values, and copy paste
>them to the correct mlxsw instance? 50/50 guess if you have two
>switches, and hope they don't make a typO?

Which values are you talking about here exactly?


>
>> >I still don't actually get this use case. Why would i want to manually
>> >provision?
>> 
>> Because user might want to see the system with all netdevices, configure
>> them, change the linecard if they got broken and all config, like
>> bridge, tc, etc will stay on the netdevices. Again, this is the same we
>> do for split port. This is important requirement, user don't want to see
>> netdevices come and go when he is plugging/unplugging cables. Linecards
>> are the same in this matter. Basically is is a "splitter module",
>> replacing the "splitter cable"
>
>So, what is the real use case here? Why might the user want to do
>this?
>
>Is it: The magic smoke has escaped. The user takes a spare switch, and
>wants to put it on her desk to configure it where she has a comfy chair
>and piece and quiet, unlike in the data centre, which is very noise,
>only has hard plastic chair, no coffee allowed. She makes her best
>guess at the configuration, up/downs the interfaces, reboots, to make
>sure it is permanent, and only then moves to the data centre to swap
>the dead router for the new one, and fix up whatever configuration
>errors there are, while sat on the hard chair?
>
>So this feature is about comfy chair vs hard chair?

I don't really get the question, but configuring switch w/o any linecard
and plug the linecards in later on is definitelly a usecase.


>
>I'm also wondering about the splitter port use case. At what point do
>you tell the user that it is physically impossible to split the port
>because the SFP simply does not support it? You say the netdevs don't
>come/go. I assume the link never goes up, but how does the user know
>the configuration is FUBAR, not the SFP? To me, it seems a lot more
>intuitive that when i remove an SFP which has been split into 4, and
>pop in an SFP which only supports a single stream, the 3 extra netdevs
>would just vanish.

As I wrote easlier in this thread, for hw that supports it, there should
be possibility to turn on "autosplit" mode that would do exactly what
you describe. But depends on a usecase. User should be in power to
configure "autosplit" for split cables and "autodetect" for linecards.
Both should be treated in the same way I believe.


>
>   Andrew
>

Powered by blists - more mailing lists