All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: David Ahern <dsahern@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	netdev@vger.kernel.org, davem@davemloft.net,
	jacob.e.keller@intel.com, roopa@nvidia.com, mlxsw@nvidia.com
Subject: Re: [patch net-next RFC 00/10] introduce line card support for modular switch
Date: Fri, 22 Jan 2021 09:05:55 +0100	[thread overview]
Message-ID: <20210122080555.GI3565223@nanopsycho.orion> (raw)
In-Reply-To: <971e9eff-0b71-8ff9-d72c-aebe73cab599@gmail.com>

Thu, Jan 21, 2021 at 05:38:40PM CET, dsahern@gmail.com wrote:
>On 1/21/21 8:32 AM, Jiri Pirko wrote:
>> Thu, Jan 21, 2021 at 12:41:58AM CET, kuba@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 i2c. This driver takes care of power
>>>>> management of the linecard, among other tasks.  
>>>>
>>>> So what does activated actually mean for your hardware? It seems to
>>>> mean something like: Some random card has been plugged in, we have no
>>>> idea what, but it has power, and we have enabled the MACs as
>>>> provisioned, which if you are lucky might match the hardware?
>>>>
>>>> The foundations of this feature seems dubious.
>>>
>>> But Jiri also says "The linecard type is known to the driver which
>>> operates on i2c." which sounds like there is some i2c driver (in user
>>> space?) which talks to the card and _does_ have the info? Maybe I'm
>>> misreading it. What's the i2c driver?
>> 
>> That is Vadim's i2c kernel driver, this is going to upstream.
>> 
>
>This pre-provisioning concept makes a fragile design to work around h/w
>shortcomings. You really need a way for the management card to know

Not really. As I replied to you in the other part of this thread, the
linecard is basically very similar to a splitter cable. In a way, it is
a splitter cable. And should be threated in a similar way. As a phy. Not
as a device. Cables are replaceble without netdevice reappearing. This
linecards are the same. Therefore, the concept of provisioning makes
sense for them, as it does for splitter cable.


>exactly what was plugged in to a slot so the control plane S/W can
>respond accordingly. Surely there is a way for processes on the LC to
>communicate with a process on the management card - even if it is inband
>packets with special headers.

If a device is capable of splitter cable/linecard hotplug, sure, that
may be implemented. But the user has to configure it as such, to be
aware that "cable change" may move netdevices around.

  parent reply	other threads:[~2021-01-22  8:07 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13 12:12 [patch net-next RFC 00/10] introduce line card support for modular switch Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 01/10] devlink: add support to create line card and expose to user Jiri Pirko
2021-01-14  3:09   ` kernel test robot
2021-01-15 15:47   ` Ido Schimmel
2021-01-13 12:12 ` [patch net-next RFC 02/10] devlink: implement line card provisioning Jiri Pirko
2021-01-15 16:03   ` Ido Schimmel
2021-01-15 16:51     ` Jiri Pirko
2021-01-15 18:09       ` Ido Schimmel
2021-01-18 12:50         ` Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 03/10] devlink: implement line card active state Jiri Pirko
2021-01-15 16:06   ` Ido Schimmel
2021-01-15 16:52     ` Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 04/10] devlink: append split port number to the port name Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 05/10] devlink: add port to line card relationship set Jiri Pirko
2021-01-15 16:10   ` Ido Schimmel
2021-01-15 16:53     ` Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 06/10] netdevsim: introduce line card support Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 07/10] netdevsim: allow port objects to be linked with line cards Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 08/10] netdevsim: create devlink line card object and implement provisioning Jiri Pirko
2021-01-14  1:01   ` kernel test robot
2021-01-14  1:22   ` kernel test robot
2021-01-14  1:32   ` kernel test robot
2021-01-15 16:30   ` Ido Schimmel
2021-01-15 16:54     ` Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 09/10] netdevsim: implement line card activation Jiri Pirko
2021-01-13 12:12 ` [patch net-next RFC 10/10] selftests: add netdevsim devlink lc test Jiri Pirko
2021-01-13 13:39 ` [patch iproute2/net-next RFC] devlink: add support for linecard show and provision Jiri Pirko
2021-01-14  2:07 ` [patch net-next RFC 00/10] introduce line card support for modular switch Andrew Lunn
2021-01-14  7:39   ` Jiri Pirko
2021-01-14 22:56     ` Jacob Keller
2021-01-15 14:19       ` Jiri Pirko
2021-01-19 11:56   ` Jiri Pirko
2021-01-19 14:51     ` Andrew Lunn
2021-01-20  8:36       ` Jiri Pirko
2021-01-20 13:56         ` Andrew Lunn
2021-01-20 23:41           ` Jakub Kicinski
2021-01-21  0:01             ` Andrew Lunn
2021-01-21  0:16               ` Jakub Kicinski
2021-01-21 15:34               ` Jiri Pirko
2021-01-21 15:32             ` Jiri Pirko
2021-01-21 16:38               ` David Ahern
2021-01-22  7:28                 ` Jiri Pirko
2021-01-22 14:13                   ` Andrew Lunn
2021-01-26 11:33                     ` Jiri Pirko
2021-01-26 13:56                       ` Andrew Lunn
2021-01-27  7:57                         ` Jiri Pirko
2021-01-27 14:14                           ` Andrew Lunn
2021-01-27 14:57                             ` David Ahern
2021-01-28  8:14                             ` Jiri Pirko
2021-01-28 14:17                               ` Andrew Lunn
2021-01-29  7:20                                 ` Jiri Pirko
     [not found]                                   ` <YBQujIdnFtEhWqTF@lunn.ch>
2021-01-29 16:45                                     ` Vadim Pasternak
2021-01-29 17:31                                       ` Andrew Lunn
2021-01-30 14:19                                         ` Jiri Pirko
     [not found]                                           ` <251d1e12-1d61-0922-31f8-a8313f18f194@gmail.com>
2021-02-01  8:16                                             ` Jiri Pirko
2021-02-01 13:41                                               ` Andrew Lunn
2021-02-03 14:57                                                 ` Jiri Pirko
2021-02-03 16:26                                                   ` Andrew Lunn
2021-02-01  1:43                                       ` Andrew Lunn
2021-01-22  8:05                 ` Jiri Pirko [this message]
2021-01-19 16:23     ` David Ahern
2021-01-20  8:37       ` Jiri Pirko
2021-01-14  2:27 ` Jakub Kicinski
2021-01-14  7:48   ` Jiri Pirko
2021-01-14 23:30     ` Jakub Kicinski
2021-01-15 14:39       ` Jiri Pirko
2021-01-15 19:26         ` Jakub Kicinski
2021-01-18 13:00           ` Jiri Pirko
2021-01-18 17:59             ` Jakub Kicinski
2021-01-19 11:51               ` Jiri Pirko
2021-01-18 22:55             ` David Ahern
2021-01-22  8:01               ` Jiri Pirko
2021-01-14 22:58   ` Jacob Keller
2021-01-14 23:20     ` Jakub Kicinski
2021-01-15 14:40       ` Jiri Pirko
2021-01-15 15:43 ` Ido Schimmel
2021-01-15 16:55   ` Jiri Pirko
2021-01-15 18:01     ` Ido Schimmel
2021-01-18 13:03       ` Jiri Pirko
2021-01-18 18:01 ` Edwin Peer
2021-01-18 22:57   ` David Ahern
2021-01-18 23:40     ` Edwin Peer
2021-01-19  2:39       ` David Ahern
2021-01-19  5:06         ` Edwin Peer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210122080555.GI3565223@nanopsycho.orion \
    --to=jiri@resnulli.us \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=jacob.e.keller@intel.com \
    --cc=kuba@kernel.org \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.