> >When the platform line card driver is on the BMC, you need a proxy in
> >between. Isn't this what IPMI and Redfish is all about? The proxy
> >driver can offer the same interface as the platform line card driver.
>
> Do you have any example of kernel driver which is doing some thing like
> that?
Mon, Feb 01, 2021 at 02:41:07PM CET, and...@lunn.ch wrote:
>On Mon, Feb 01, 2021 at 09:16:41AM +0100, Jiri Pirko wrote:
>> Sun, Jan 31, 2021 at 06:09:24PM CET, dsah...@gmail.com wrote:
>> >On 1/30/21 7:19 AM, Jiri Pirko wrote:
>> >> Fri, Jan 29, 2021 at 06:31:59PM CET, and...@lunn.ch wrote:
>>
On Mon, Feb 01, 2021 at 09:16:41AM +0100, Jiri Pirko wrote:
> Sun, Jan 31, 2021 at 06:09:24PM CET, dsah...@gmail.com wrote:
> >On 1/30/21 7:19 AM, Jiri Pirko wrote:
> >> Fri, Jan 29, 2021 at 06:31:59PM CET, and...@lunn.ch wrote:
> Platform line card driver is aware of line card I2C topology, i
Sun, Jan 31, 2021 at 06:09:24PM CET, dsah...@gmail.com wrote:
>On 1/30/21 7:19 AM, Jiri Pirko wrote:
>> Fri, Jan 29, 2021 at 06:31:59PM CET, and...@lunn.ch wrote:
Platform line card driver is aware of line card I2C topology, its
responsibility is to detect line card basic hardware type, c
> Platform line card driver is aware of line card I2C topology, its
> responsibility is to detect line card basic hardware type, create I2C
> topology (mux), connect all the necessary I2C devices, like hotswap
> devices, voltage and power regulators devices, iio/a2d devices and line
> card EEPROMs,
Fri, Jan 29, 2021 at 06:31:59PM CET, and...@lunn.ch wrote:
>> Platform line card driver is aware of line card I2C topology, its
>> responsibility is to detect line card basic hardware type, create I2C
>> topology (mux), connect all the necessary I2C devices, like hotswap
>> devices, voltage and pow
> Platform line card driver is aware of line card I2C topology, its
> responsibility is to detect line card basic hardware type, create I2C
> topology (mux), connect all the necessary I2C devices, like hotswap
> devices, voltage and power regulators devices, iio/a2d devices and line
> card EEPROMs,
ubject: Re: [patch net-next RFC 00/10] introduce line card support for
> modular switch
>
> On Fri, Jan 29, 2021 at 08:20:15AM +0100, Jiri Pirko wrote:
> > 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 wro
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 mlxr
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
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.
On 1/27/21 7:14 AM, Andrew Lunn wrote:
>> 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. Ml
> >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
Tue, Jan 26, 2021 at 02:56:08PM CET, and...@lunn.ch wrote:
>On Tue, Jan 26, 2021 at 12:33:26PM +0100, Jiri Pirko wrote:
>> Fri, Jan 22, 2021 at 03:13:12PM CET, and...@lunn.ch wrote:
>> >> I don't see any way. The userspace is the one who can get the info, from
>> >> the i2c driver. The mlxsw driver
On Tue, Jan 26, 2021 at 12:33:26PM +0100, Jiri Pirko wrote:
> Fri, Jan 22, 2021 at 03:13:12PM CET, and...@lunn.ch wrote:
> >> I don't see any way. The userspace is the one who can get the info, from
> >> the i2c driver. The mlxsw driver has no means to get that info itself.
> >
> >Hi Jiri
> >
> >Pl
Fri, Jan 22, 2021 at 03:13:12PM CET, and...@lunn.ch wrote:
>> I don't see any way. The userspace is the one who can get the info, from
>> the i2c driver. The mlxsw driver has no means to get that info itself.
>
>Hi Jiri
>
>Please can you tell us more about this i2c driver. Do you have any
>architec
> I don't see any way. The userspace is the one who can get the info, from
> the i2c driver. The mlxsw driver has no means to get that info itself.
Hi Jiri
Please can you tell us more about this i2c driver. Do you have any
architecture pictures?
It is not unknown for one driver to embed another
Thu, Jan 21, 2021 at 05:38:40PM CET, dsah...@gmail.com wrote:
>On 1/21/21 8:32 AM, Jiri Pirko wrote:
>> Thu, Jan 21, 2021 at 12:41:58AM CET, k...@kernel.org wrote:
>>> On Wed, 20 Jan 2021 14:56:46 +0100 Andrew Lunn wrote:
> No, the FW does not know. The ASIC is not physically able to get the
>>
Mon, Jan 18, 2021 at 11:55:45PM CET, dsah...@gmail.com wrote:
>On 1/18/21 6:00 AM, Jiri Pirko wrote:
>>
>>> Reconfiguring routing is not the end of the world.
>> Well, yes, but you don't really want netdevices to come and go then you
>> plug in/out cables/modules. That's why we have split implemen
Thu, Jan 21, 2021 at 05:38:40PM CET, dsah...@gmail.com wrote:
>On 1/21/21 8:32 AM, Jiri Pirko wrote:
>> Thu, Jan 21, 2021 at 12:41:58AM CET, k...@kernel.org wrote:
>>> On Wed, 20 Jan 2021 14:56:46 +0100 Andrew Lunn wrote:
> No, the FW does not know. The ASIC is not physically able to get the
>>
On 1/21/21 8:32 AM, Jiri Pirko wrote:
> Thu, Jan 21, 2021 at 12:41:58AM CET, k...@kernel.org wrote:
>> On Wed, 20 Jan 2021 14:56:46 +0100 Andrew Lunn wrote:
No, the FW does not know. The ASIC is not physically able to get the
linecard type. Yes, it is odd, I agree. The linecard type is kn
Thu, Jan 21, 2021 at 12:41:58AM CET, k...@kernel.org wrote:
>On Wed, 20 Jan 2021 14:56:46 +0100 Andrew Lunn wrote:
>> > No, the FW does not know. The ASIC is not physically able to get the
>> > linecard type. Yes, it is odd, I agree. The linecard type is known to
>> > the driver which operates on i
Thu, Jan 21, 2021 at 01:01:21AM CET, and...@lunn.ch wrote:
>On Wed, Jan 20, 2021 at 03:41:58PM -0800, Jakub Kicinski wrote:
>> On Wed, 20 Jan 2021 14:56:46 +0100 Andrew Lunn wrote:
>> > > No, the FW does not know. The ASIC is not physically able to get the
>> > > linecard type. Yes, it is odd, I ag
On Wed, 20 Jan 2021 14:56:46 +0100 Andrew Lunn wrote:
> > No, the FW does not know. The ASIC is not physically able to get the
> > linecard type. Yes, it is odd, I agree. The linecard type is known to
> > the driver which operates on i2c. This driver takes care of power
> > management of the lineca
On Wed, Jan 20, 2021 at 03:41:58PM -0800, Jakub Kicinski wrote:
> On Wed, 20 Jan 2021 14:56:46 +0100 Andrew Lunn wrote:
> > > No, the FW does not know. The ASIC is not physically able to get the
> > > linecard type. Yes, it is odd, I agree. The linecard type is known to
> > > the driver which opera
On Thu, 21 Jan 2021 01:01:21 +0100 Andrew Lunn wrote:
> On Wed, Jan 20, 2021 at 03:41:58PM -0800, Jakub Kicinski wrote:
> > On Wed, 20 Jan 2021 14:56:46 +0100 Andrew Lunn wrote:
> > > > No, the FW does not know. The ASIC is not physically able to get the
> > > > linecard type. Yes, it is odd, I a
> No, the FW does not know. The ASIC is not physically able to get the
> linecard type. Yes, it is odd, I agree. The linecard type is known to
> the driver which operates on i2c. This driver takes care of power
> management of the linecard, among other tasks.
So what does activated actually mean f
Tue, Jan 19, 2021 at 05:23:19PM CET, dsah...@gmail.com wrote:
>On 1/19/21 4:56 AM, Jiri Pirko wrote:
>> Thu, Jan 14, 2021 at 03:07:18AM CET, and...@lunn.ch wrote:
$ devlink lc provision netdevsim/netdevsim10 lc 0 type card4ports
$ devlink lc
netdevsim/netdevsim10:
lc 0 state p
Tue, Jan 19, 2021 at 03:51:49PM CET, and...@lunn.ch wrote:
>On Tue, Jan 19, 2021 at 12:56:10PM +0100, Jiri Pirko wrote:
>> Thu, Jan 14, 2021 at 03:07:18AM CET, and...@lunn.ch wrote:
>> >> $ devlink lc provision netdevsim/netdevsim10 lc 0 type card4ports
>> >> $ devlink lc
>> >> netdevsim/netdevsim1
Thu, Jan 14, 2021 at 03:07:18AM CET, and...@lunn.ch wrote:
>> $ devlink lc provision netdevsim/netdevsim10 lc 0 type card4ports
>> $ devlink lc
>> netdevsim/netdevsim10:
>> lc 0 state provisioned type card4ports
>> supported_types:
>>card1port card2ports card4ports
>> lc 1 state unp
On Tue, Jan 19, 2021 at 12:56:10PM +0100, Jiri Pirko wrote:
> Thu, Jan 14, 2021 at 03:07:18AM CET, and...@lunn.ch wrote:
> >> $ devlink lc provision netdevsim/netdevsim10 lc 0 type card4ports
> >> $ devlink lc
> >> netdevsim/netdevsim10:
> >> lc 0 state provisioned type card4ports
> >> suppor
On 1/19/21 4:56 AM, Jiri Pirko wrote:
> Thu, Jan 14, 2021 at 03:07:18AM CET, and...@lunn.ch wrote:
>>> $ devlink lc provision netdevsim/netdevsim10 lc 0 type card4ports
>>> $ devlink lc
>>> netdevsim/netdevsim10:
>>> lc 0 state provisioned type card4ports
>>> supported_types:
>>>card1
Mon, Jan 18, 2021 at 06:59:28PM CET, k...@kernel.org wrote:
>On Mon, 18 Jan 2021 14:00:09 +0100 Jiri Pirko wrote:
>> >> >Or to put it differently IMO the netdev should be provisioned if the
>> >> >system has a port into which user can plug in a cable. When there is
>> >>
>> >> Not really. For
On Mon, Jan 18, 2021 at 6:39 PM David Ahern wrote:
> > Indeed, this is what we ended up doing, although we still need to
> > confirm Network Manager, systemd and whatever else our customers might
> > use do the necessary to satisfy the user requirement to handle the
> > delayed init.
>
> I am not
On 1/18/21 4:40 PM, Edwin Peer wrote:
> On Mon, Jan 18, 2021 at 2:57 PM David Ahern wrote:
>
>> On 1/18/21 11:01 AM, Edwin Peer wrote:
>>> I'm facing a similar issue with NIC firmware that isn't yet ready by
>>> device open time, but have been resisting the urge to lie to the stack
>>
>> why not
On Mon, Jan 18, 2021 at 2:57 PM David Ahern wrote:
> On 1/18/21 11:01 AM, Edwin Peer wrote:
> > I'm facing a similar issue with NIC firmware that isn't yet ready by
> > device open time, but have been resisting the urge to lie to the stack
>
> why not have the ndo_open return -EBUSY or -EAGAIN to
On 1/18/21 11:01 AM, Edwin Peer wrote:
> I'm facing a similar issue with NIC firmware that isn't yet ready by
> device open time, but have been resisting the urge to lie to the stack
why not have the ndo_open return -EBUSY or -EAGAIN to tell S/W to try
again 'later'?
> about the state of the devi
On 1/18/21 6:00 AM, Jiri Pirko wrote:
>
>> Reconfiguring routing is not the end of the world.
> Well, yes, but you don't really want netdevices to come and go then you
> plug in/out cables/modules. That's why we have split implemented as we
And you don't want a routing daemon to use netdevices wh
On Wed, Jan 13, 2021 at 4:14 AM Jiri Pirko wrote:
> To resolve this, a concept of "provisioning" is introduced.
> The user may "provision" certain slot with a line card type.
> Driver then creates all instances (devlink ports, netdevices, etc)
> related to this line card type. The carrier of netd
On Mon, 18 Jan 2021 14:00:09 +0100 Jiri Pirko wrote:
> >> >Or to put it differently IMO the netdev should be provisioned if the
> >> >system has a port into which user can plug in a cable. When there is
> >>
> >> Not really. For slit cables, the ports are provisioned not matter which
> >> cab
Fri, Jan 15, 2021 at 07:01:45PM CET, ido...@idosch.org wrote:
>On Fri, Jan 15, 2021 at 05:55:59PM +0100, Jiri Pirko wrote:
>> Fri, Jan 15, 2021 at 04:43:57PM CET, ido...@idosch.org wrote:
>> >On Wed, Jan 13, 2021 at 01:12:12PM +0100, Jiri Pirko wrote:
>> >> # Create a new netdevsim device, with no
Fri, Jan 15, 2021 at 08:26:17PM CET, k...@kernel.org wrote:
>On Fri, 15 Jan 2021 15:39:06 +0100 Jiri Pirko wrote:
>> >I'm not a SFP experts so maybe someone will correct me but AFAIU
>> >the QSFP (for optics) is the same regardless of breakout. It's the
>> >passive optical strands that are either b
On Fri, 15 Jan 2021 15:39:06 +0100 Jiri Pirko wrote:
> >I'm not a SFP experts so maybe someone will correct me but AFAIU
> >the QSFP (for optics) is the same regardless of breakout. It's the
> >passive optical strands that are either bundled or not. So there is
> >no way for the system to detect t
On Fri, Jan 15, 2021 at 05:55:59PM +0100, Jiri Pirko wrote:
> Fri, Jan 15, 2021 at 04:43:57PM CET, ido...@idosch.org wrote:
> >On Wed, Jan 13, 2021 at 01:12:12PM +0100, Jiri Pirko wrote:
> >> # Create a new netdevsim device, with no ports and 2 line cards:
> >> $ echo "10 0 2" >/sys/bus/netdevsim/n
Fri, Jan 15, 2021 at 04:43:57PM CET, ido...@idosch.org wrote:
>On Wed, Jan 13, 2021 at 01:12:12PM +0100, Jiri Pirko wrote:
>> # Create a new netdevsim device, with no ports and 2 line cards:
>> $ echo "10 0 2" >/sys/bus/netdevsim/new_device
>> $ devlink port # No ports are listed
>> $ devlink lc
>>
On Wed, Jan 13, 2021 at 01:12:12PM +0100, Jiri Pirko wrote:
> # Create a new netdevsim device, with no ports and 2 line cards:
> $ echo "10 0 2" >/sys/bus/netdevsim/new_device
> $ devlink port # No ports are listed
> $ devlink lc
> netdevsim/netdevsim10:
> lc 0 state unprovisioned
> supported
Fri, Jan 15, 2021 at 12:20:58AM CET, k...@kernel.org wrote:
>On Thu, 14 Jan 2021 14:58:33 -0800 Jacob Keller wrote:
>> > There is no way to tell a breakout cable from normal one, so the
>> > system has no chance to magically configure itself. Besides SFP
>> > is just plugging a cable, not a module
Fri, Jan 15, 2021 at 12:30:13AM CET, k...@kernel.org wrote:
>On Thu, 14 Jan 2021 08:48:04 +0100 Jiri Pirko wrote:
>> Thu, Jan 14, 2021 at 03:27:16AM CET, k...@kernel.org wrote:
>> >On Wed, 13 Jan 2021 13:12:12 +0100 Jiri Pirko wrote:
>> >> This patchset introduces support for modular switch syste
Thu, Jan 14, 2021 at 11:56:15PM CET, jacob.e.kel...@intel.com wrote:
>
>
>On 1/13/2021 11:39 PM, Jiri Pirko wrote:
>> Thu, Jan 14, 2021 at 03:07:18AM CET, and...@lunn.ch wrote:
>>>
>>> I assume if i prevision for card4ports but actually install a
>>> card2ports, all the interfaces stay down?
>>
>>
On Thu, 14 Jan 2021 08:48:04 +0100 Jiri Pirko wrote:
> Thu, Jan 14, 2021 at 03:27:16AM CET, k...@kernel.org wrote:
> >On Wed, 13 Jan 2021 13:12:12 +0100 Jiri Pirko wrote:
> >> This patchset introduces support for modular switch systems.
> >> NVIDIA Mellanox SN4800 is an example of such. It contai
On Thu, 14 Jan 2021 14:58:33 -0800 Jacob Keller wrote:
> > There is no way to tell a breakout cable from normal one, so the
> > system has no chance to magically configure itself. Besides SFP
> > is just plugging a cable, not a module of the system..
> >
> If you're able to tell what is plugged
On 1/13/2021 6:27 PM, Jakub Kicinski wrote:
> On Wed, 13 Jan 2021 13:12:12 +0100 Jiri Pirko wrote:
>> This patchset introduces support for modular switch systems.
>> NVIDIA Mellanox SN4800 is an example of such. It contains 8 slots
>> to accomodate line cards. Available line cards include:
>> 16
On 1/13/2021 11:39 PM, Jiri Pirko wrote:
> Thu, Jan 14, 2021 at 03:07:18AM CET, and...@lunn.ch wrote:
>>
>> I assume if i prevision for card4ports but actually install a
>> card2ports, all the interfaces stay down?
>
> Yes, the card won't get activated in case or provision mismatch.
>
If you'
Thu, Jan 14, 2021 at 03:27:16AM CET, k...@kernel.org wrote:
>On Wed, 13 Jan 2021 13:12:12 +0100 Jiri Pirko wrote:
>> This patchset introduces support for modular switch systems.
>> NVIDIA Mellanox SN4800 is an example of such. It contains 8 slots
>> to accomodate line cards. Available line cards in
Thu, Jan 14, 2021 at 03:07:18AM CET, and...@lunn.ch wrote:
>> $ devlink lc provision netdevsim/netdevsim10 lc 0 type card4ports
>> $ devlink lc
>> netdevsim/netdevsim10:
>> lc 0 state provisioned type card4ports
>> supported_types:
>>card1port card2ports card4ports
>> lc 1 state unp
On Wed, 13 Jan 2021 13:12:12 +0100 Jiri Pirko wrote:
> This patchset introduces support for modular switch systems.
> NVIDIA Mellanox SN4800 is an example of such. It contains 8 slots
> to accomodate line cards. Available line cards include:
> 16X 100GbE (QSFP28)
> 8X 200GbE (QSFP56)
> 4X 400GbE (Q
> $ devlink lc provision netdevsim/netdevsim10 lc 0 type card4ports
> $ devlink lc
> netdevsim/netdevsim10:
> lc 0 state provisioned type card4ports
> supported_types:
>card1port card2ports card4ports
> lc 1 state unprovisioned
> supported_types:
>card1port card2ports ca
From: Jiri Pirko
This patchset introduces support for modular switch systems.
NVIDIA Mellanox SN4800 is an example of such. It contains 8 slots
to accomodate line cards. Available line cards include:
16X 100GbE (QSFP28)
8X 200GbE (QSFP56)
4X 400GbE (QSFP-DD)
Similar to split cabels, it is essenc
58 matches
Mail list logo
