Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp726719pxb; Tue, 9 Feb 2021 10:47:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJzDZkiUrk15DdJeBgcfsxaKg1z5bbJdfMPoq4cJvKb2Cyuph0QhbMgvK+JOLoJaI323n8kk X-Received: by 2002:a17:907:1607:: with SMTP id hb7mr12670138ejc.265.1612896468867; Tue, 09 Feb 2021 10:47:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612896468; cv=none; d=google.com; s=arc-20160816; b=XDBe2wO5RfQ/QkekXm66nraj0RjyBAVfLMhpKjUXcG+5UheyAlVZFPp0965tYRJ0y2 mbhHZqNrp2VtbRT13X0XSC3ftTGyBsZhMtQe9rXWwltgjofV48XqCNMn5GushDm/PBCA g4gfPpzjFR4HbBXd4x1QnRi+nooY2s5aTU4V5Ji9ORXEfm8CglrG2d75dD12a6VQc1G2 txss1JfD1+MEdP5yNLC/cNWvnlZqBWUN+ffoq2OzQJUZ7A5IpWY5QeOwXRhFGtKgMbtU GA/9GlIpQoRWB8fmFM+D0j3qiels57ZUAPUqpPGfEbFfSn7lsZcGfnfPKNfOKv9Wr49/ cfZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=/73nnwKYIm1AUNsNYL6OxVYi3SDCipJroJC6yomdvoY=; b=J7wu2WIGMhedFdmbWX7FK3h35zNtykx9WVQG7bxZqHncUr3EvGVdenpNnV+zJE5aok OeSkzqlI1JUHMwvpZLjXNQnIdn8NaKDL81lfwHKww28XrSGWKtHrlRnI3OVD0OluH6lM OWNdZgSbXzhNLI+uLaQQ6+wtM9BO8p9TVA+r1ybNFKiiEEsdtfgxBU0PKO+JfeuSWSP6 10FciKEIqBZpMhgdLooj1xaS2h1y+xM2107/anc1Du+mfJmVDswPNNoBnM/yfrHwuyjQ nfjBYYyog1/LBgyndBGi1dTlHlMpjQGreyL5XNJZavvDDY6TKpkCGnZFlluxv9TLGanW a9vQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="byU4w/21"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e8si5567631ejt.591.2021.02.09.10.47.24; Tue, 09 Feb 2021 10:47:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="byU4w/21"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233638AbhBISpY (ORCPT + 99 others); Tue, 9 Feb 2021 13:45:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:33134 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233260AbhBIRtP (ORCPT ); Tue, 9 Feb 2021 12:49:15 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 56E5C64DB3; Tue, 9 Feb 2021 17:48:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612892909; bh=0bwozM0+19GheowWSY/r03uwZDq+Knnhrmbub8g0N6Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=byU4w/21yTB7r7ByiSRRVMOX6dtzSThCyfIvKLZdTFmiDNCtN+eBtznGboki9nzex qzRzeBhk7vuT8gDfqpjk36AuVKoifXMp7BXitegzmRmmWAggcN9VriCCCry++0W0TR B3trywkx4+IHo2O//uJJos+OdmC9wmqqdkCS0Fg6DDtRyBk4ZMevelWH1NzSftjdu6 tOucl4W3TRK5oq0TxgO1OszwY2/3tPzwalLlhPIJnOS23DTyKZ3PHBZO9jtTAKgF4V MSh5sKURSWOrY8czE4fMIKEyDH3egYXEJ+dIyyWZVgx4RUqMR+HKrAX+MxsWCDNcmA PAU0FygKggQSw== Date: Tue, 9 Feb 2021 09:48:28 -0800 From: Jakub Kicinski To: Tobias Waldekranz Cc: Vadym Kochan , "David S. Miller" , netdev@vger.kernel.org, Mickey Rachamim , linux-kernel@vger.kernel.org, Vladimir Oltean Subject: Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support Message-ID: <20210209094828.5635e2bc@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <87pn194fp4.fsf@waldekranz.com> References: <20210203165458.28717-1-vadym.kochan@plvision.eu> <20210203165458.28717-6-vadym.kochan@plvision.eu> <20210204211647.7b9a8ebf@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <87v9b249oq.fsf@waldekranz.com> <20210208130557.56b14429@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <87pn194fp4.fsf@waldekranz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 09 Feb 2021 12:56:55 +0100 Tobias Waldekranz wrote: > > I ask myself that question pretty much every day. Sadly I have no clear > > answer. > > Thank you for your candid answer, really appreciate it. I do not envy > you one bit, making those decisions must be extremely hard. > > > Silicon is cheap, you can embed a reasonable ARM or Risc-V core in the > > chip for the area and power draw comparable to one high speed serdes > > lane. > > > > The drivers landing in the kernel are increasingly meaningless. My day > > job is working for a hyperscaler. Even though we have one of the most > > capable kernel teams on the planet most of issues with HW we face > > result in "something is wrong with the FW, let's call the vendor". > > Right, and being a hyperscaler probably at least gets you some attention > when you call your vendor. My day job is working for a nanoscaler, so my > experience is that we must be prepared to solve all issues in-house; if > we get any help from the vendor that is just a bonus. > > > And even when I say "drivers landing" it is an overstatement. > > If you look at high speed anything these days the drivers cover > > multiple generations of hardware, seems like ~5 years ago most > > NIC vendors reached sufficient FW saturation to cover up differences > > between HW generations. > > > > At the same time some FW is necessary. Certain chip functions, are > > best driven by a micro-controller running a tight control loop. > > I agree. But I still do not understand why vendors cling to the source > of these like it was their wallet. That is the beauty of selling > silicon; you can fully leverage OSS and still have a very straight > forward business model. Vendors want to be able to "add value", lock users in and sell support. Users adding features themselves hurts their bottom line. Take a look at income breakdown for publicly traded companies. There were also rumors recently about certain huge silicon vendor revoking the SDK license from a NOS company after that company got bought. Business people make rational choices, trust me. It's on us to make rational choices in the interest of the community (incl. our users). > > The complexity of FW is a spectrum, from basic to Qualcomm. > > The problem is there is no way for us to know what FW is hiding > > by just looking at the driver. > > > > Where do we draw the line? > > Yeah it is a very hard problem. In this particular case though, the > vendor explicitly said that what they have done is compiled their > existing SDK to run on the ASIC: > > https://lore.kernel.org/netdev/BN6PR18MB1587EB225C6B80BF35A44EBFBA5A0@BN6PR18MB1587.namprd18.prod.outlook.com > > So there is no reason that it could not be done as a proper driver. I guess you meant "no _technical_ reason" ;) > > Personally I'd really like to see us pushing back stronger. > > Hear, hear!