linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Tobias Waldekranz <tobias@waldekranz.com>,
	Vadym Kochan <vadym.kochan@plvision.eu>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, Mickey Rachamim <mickeyr@marvell.com>,
	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: Mon, 8 Feb 2021 23:30:44 +0100	[thread overview]
Message-ID: <YCG7lEncISjQwEOk@lunn.ch> (raw)
In-Reply-To: <20210208130557.56b14429@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

> > I took a quick look at it, and what I found left me very puzzled. I hope
> > you do not mind me asking a generic question about the policy around
> > switchdev drivers. If someone published a driver using something similar
> > to the following configuration flow:
> > 
> > iproute2  daemon(SDK)
> >    |        ^    |
> >    :        :    : user/kernel boundary
> >    v        |    |
> > netlink     |    |
> >    |        |    |
> >    v        |    |
> >  driver     |    |
> >    |        |    |
> >    '--------'    |
> >                  : kernel/hardware boundary
> >                  v
> >                 ASIC
> > 
> > My guess is that they would be (rightly IMO) told something along the
> > lines of "we do not accept drivers that are just shims for proprietary
> > SDKs".
> > 
> > But it seems like if that same someone has enough area to spare in their
> > ASIC to embed a CPU, it is perfectly fine to run that same SDK on it,
> > call it "firmware", and then push a shim driver into the kernel tree.
> > 
> > iproute2
> >    |
> >    :               user/kernel boundary
> >    v
> > netlink
> >    |
> >    v
> >  driver
> >    |
> >    |
> >    :               kernel/hardware boundary
> >    '-------------.
> >                  v
> >              daemon(SDK)
> >                  |
> >                  v
> >                 ASIC
> > 
> > What have we, the community, gained by this? In the old world, the
> > vendor usually at least had to ship me the SDK in source form. Having
> > seen the inside of some of those sausage factories, they are not the
> > kinds of code bases that I want at the bottom of my stack; even less so
> > in binary form where I am entirely at the vendor's mercy for bugfixes.
> > 
> > We are talking about a pure Ethernet fabric here, so there is no fig
> > leaf of "regulatory requirements" to hide behind, in contrast to WiFi
> > for example.
> > 
> > Is it the opinion of the netdev community that it is OK for vendors to
> > use this model?

What i find interesting is the comparison between Microchip Sparx5 and
Marvell Prestera. They offer similar capabilities. Both have a CPU on
them. As you say Marvell is pushing their SDK into this CPU, black
box. Microchip decided to open everything, no firmware, the kernel
driver is directly accessing the hardware, the datasheet is available,
and microchip engineers are here on the list.

I really hope that Sparx5 takes off, and displaces Prestera. In terms
of being able to solve issues, we the community can work with
Sparx5. Prestera is too much a black box.

	Andrew

  reply	other threads:[~2021-02-08 22:31 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 [this message]
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
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=YCG7lEncISjQwEOk@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --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).