linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tobias Waldekranz <tobias@waldekranz.com>
To: Andrew Lunn <andrew@lunn.ch>, Jakub Kicinski <kuba@kernel.org>
Cc: 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: Tue, 09 Feb 2021 13:37:10 +0100	[thread overview]
Message-ID: <87mtwd4du1.fsf@waldekranz.com> (raw)
In-Reply-To: <YCG7lEncISjQwEOk@lunn.ch>

On Mon, Feb 08, 2021 at 23:30, Andrew Lunn <andrew@lunn.ch> wrote:
>> > 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.

Indeed, it is a very stark difference in approach. Perhaps a silly
example, but it speaks to their developer focus, just the fact that they
have an online register reference on GitHub[1] amazed me. What a breath
of fresh air! ...and speaks to the general state of things, I guess :)

Unsurprisingly the team behind it are also really great to work with!

> I really hope that Sparx5 takes off, and displaces Prestera. In terms

We are certainly keeping our eyes on it!

> of being able to solve issues, we the community can work with
> Sparx5. Prestera is too much a black box.

I would only add that I still, perhaps naively, hope Marvell will
eventually see the benefits of having a truly open driver.

> 	Andrew

[1]: https://microchip-ung.github.io/sparx-5_reginfo/reginfo_sparx-5.html

  reply	other threads:[~2021-02-09 12:38 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 [this message]
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=87mtwd4du1.fsf@waldekranz.com \
    --to=tobias@waldekranz.com \
    --cc=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=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).