Thu, Jan 28, 2021 at 03:17:13PM CET, and...@lunn.ch wrote: >On Thu, Jan 28, 2021 at 09:14:34AM +0100, Jiri Pirko wrote: >> Wed, Jan 27, 2021 at 03:14:34PM CET, and...@lunn.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 >
