linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Vadym Kochan <vadym.kochan@plvision.eu>,
	Mickey Rachamim <mickeyr@marvell.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Tobias Waldekranz <tobias@waldekranz.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Vladimir Oltean <vladimir.oltean@nxp.com>
Subject: Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support
Date: Tue, 9 Feb 2021 09:35:00 -0800	[thread overview]
Message-ID: <20210209093500.53b55ca8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <YCKVAtu2Y8DAInI+@lunn.ch>

On Tue, 9 Feb 2021 14:58:26 +0100 Andrew Lunn wrote:
> > At the same time some FW is necessary. Certain chip functions, are 
> > best driven by a micro-controller running a tight control loop.   
> 
> For a smart NIC, i could agree. But a switch? The data path is in
> hardware. The driver is all about configuring this hardware, and then
> it is idle. Polls the PHYs once a second, maybe gather statistics,
> allows the network stack to perform STP, but otherwise it does
> nothing.
> 
> So for me, i don't see that being a valid argument for this driver.
> 
> By putting their SDK inside the CPU on the switch, and adding an RPC
> interface, Marvell can quickly get some sort of support working in the
> Linux ecosystem. But this solution has all the problems of a binary
> blob in userspace.
> 
> I doubt there is going to be any community engagement with this
> driver. Marvell is going to have to add all the features. If a user
> wants a feature which is not currently supported, they have little
> chance of being able to add it themselves. There is no documentation
> of the RPC interface. So even if the firmware has support for more
> than what the Linux driver implements, only Marvell knows about it.
> 
> Products based around this driver are going to find it hard to
> differentiate on switch features. The switch can do what Marvell
> allows you to do. All differentiation is going to be limited to above
> that, the user interface.
> 
> For some market segments, that might be enough. You don't see
> community based patches adding new features to the Mellanex/nvidia
> hardware. But when you look at the DSA drivers, a lot of the features
> there are from the community. There is probably space for both.
> 
> Looking into my crystal ball, Marvell will probably have the base
> features of their switch implemented before Microchip does, simply
> because they are reusing code hidden away in the CPU. But then
> development will stagnate. Microchip will take a bit longer to get the
> base features implemented. But then because of the openness, users
> will start using the hardware in different ways, and implement
> features which are important to them. And contribute bug fixes. The
> driver will keep gaining new features and mature, and in the end, the
> device built from it will be a lot more divers and interesting.
> 
> What i'm not sure is how we as a community push back. Marvells whole
> strategy is black box. I doubt we can make them open up the firmware.
> Do we want to throw out the driver from the kernel? I don't think it
> is that bad. We can point out the problems with Marvell's model. We
> can put in review effort for Microchip, make their driver better. And
> we can encourage the 3rd and 4th vendors in the enterprise switch
> space to follow Microchips lead.

Sounds like we have 3 people who don't like FW-heavy designs dominating
the kernel - this conversation can only go one way. 

Marvell, Plvision anything to share? AFAIU the values of Linux kernel
are open source, healthy community, empowering users. With the SDK on
the embedded CPU your driver does not seem to tick any of these boxes.

  reply	other threads:[~2021-02-09 17:37 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-03 16:54 [PATCH net-next 0/7] Marvell Prestera Switchdev misc updates Vadym Kochan
2021-02-03 16:54 ` [PATCH net-next 1/7] net: marvell: prestera: bump supported firmware version to 2.5 Vadym Kochan
2021-02-03 16:54 ` [PATCH net-next 2/7] net: marvell: prestera: disable events interrupt while handling Vadym Kochan
2021-02-05  5:10   ` Jakub Kicinski
2021-02-05 11:28     ` Vadym Kochan
2021-02-03 16:54 ` [PATCH net-next 3/7] net: marvell: prestera: add support for AC3X 98DX3265 device Vadym Kochan
2021-02-03 16:54 ` [PATCH net-next 4/7] net: marvell: prestera: move netdev topology validation to prestera_main Vadym Kochan
2021-02-05 14:09   ` Vladimir Oltean
2021-02-03 16:54 ` [PATCH net-next 5/7] net: marvell: prestera: add LAG support Vadym Kochan
2021-02-05  5:16   ` Jakub Kicinski
2021-02-08 19:54     ` Tobias Waldekranz
2021-02-08 21:05       ` Jakub Kicinski
2021-02-08 22:30         ` Andrew Lunn
2021-02-09 12:37           ` Tobias Waldekranz
2021-02-09 11:56         ` Tobias Waldekranz
2021-02-09 17:48           ` Jakub Kicinski
2021-02-09 13:58         ` Andrew Lunn
2021-02-09 17:35           ` Jakub Kicinski [this message]
2021-02-09 20:31             ` [EXT] " Mickey Rachamim
2021-02-09 21:34               ` Tobias Waldekranz
2021-02-10 10:41                 ` Mickey Rachamim
2021-02-10 21:44                   ` Tobias Waldekranz
2021-02-10  0:28               ` Andrew Lunn
2021-02-10 10:42                 ` Mickey Rachamim
2021-02-10 19:25               ` Jakub Kicinski
2021-02-10 20:52             ` Taras Chornyi
2021-02-05 15:24   ` Vladimir Oltean
2021-02-03 16:54 ` [PATCH net-next 6/7] net: marvell: prestera: align flood setting according to latest firmware version Vadym Kochan
2021-02-03 16:54 ` [PATCH net-next 7/7] net: marvell: prestera: fix port event handling on init Vadym Kochan
2021-02-05  5:19   ` Jakub Kicinski
2021-02-05 12:31     ` Vadym Kochan

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=20210209093500.53b55ca8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mickeyr@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=tobias@waldekranz.com \
    --cc=vadym.kochan@plvision.eu \
    --cc=vladimir.oltean@nxp.com \
    --subject='Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).