Received: by 2002:ab2:6857:0:b0:1ef:ffd0:ce49 with SMTP id l23csp1502563lqp; Fri, 22 Mar 2024 18:27:58 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXwyNabAJ/xbwFf0t/ryQtnKbxkEwttgza5NTY8o6gHigLCHT2z1h5xxZQg9eRcThlZjlO0JLxX7m5V1AuBFF1rtT+Q92lia+jBdGaiAQ== X-Google-Smtp-Source: AGHT+IHN7yDnn0MSyMnxO74Tjzxyof6NanMokKtLKmDXC2t0paNvNF/IPUgYA27nP0nY7fV9Q/1d X-Received: by 2002:adf:a4c5:0:b0:341:9db8:6269 with SMTP id h5-20020adfa4c5000000b003419db86269mr575700wrb.48.1711157277843; Fri, 22 Mar 2024 18:27:57 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711157277; cv=pass; d=google.com; s=arc-20160816; b=u2uTzB9El9ywxenabSurgfWaIInF/6bTLZuXnRoqmKoKzli0F2L9EilyTxidzFtL3l lebFVbOBU2oYqLXWg4TtGwYan1Diq0TWeVA+8TSjLZYSXwyLxzgvqPutfEoXRMZh7Ppt lfq/gBEa1AmnkrCv/zpsCfw1gMJsOOWScNYhn9hKCv92YTR/x9Y9kndwPPDkGKVbXfoS e1V/jthWwmh2+7Q3Ml2Ry1Y7NhwJFMEiGPIjC33oTgb1ju/4fg2bjWdnCCK8dfYXbJuU oSjTX5uGewFCHOcwLlhpUK9w4KAJdahDq8LMVQ6HXpJEzPcs1LcdC+/wieXs1zDldaZV pYTQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=xMuqkxN4b/AL4uAflEcxZ3kIO7mM1ywaH3JlrymXit0=; fh=qqJU9QDzsqwkZjJbPw11XxlWiX6sRxJ6q+bnTk92tJQ=; b=YIaQe61Qww+9Igpfuh+grFNnXJ9s9x+IYc/LPoPqd4iVDQohQH1EmGtHwaDNbrTXLB VlCAx0t6EdynVhgXMqoLqLnwdIKWzttf1UHchJ70ZNqdX6HLhrcFuHaHfgMcyuGdLdbQ KUygimBoRfeRRLYlMuGbCJQBuGc13+9k7SxHgcyGNPUlBpeSHw7pNQdvbs3POw4uaoUI NJyACgdOe8iEpDxsYxscAq5+CtnuqUwFDtIsWe8ohsHfmOrCoM5WSTDQ94pEHKSRYONs u9t6LkI2D/SA84Qw6VsWHlbSp55sf1cqOlPITNrHIznH3ErxAXSEcUcK2aQR+HB7U3cS XIpQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sFtXcs4U; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-112158-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-112158-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id o11-20020a1709064f8b00b00a46b8ff5e13si335527eju.685.2024.03.22.18.27.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 18:27:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-112158-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sFtXcs4U; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-112158-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-112158-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 797BD1F231E4 for ; Sat, 23 Mar 2024 01:27:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CE0FE138A; Sat, 23 Mar 2024 01:27:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sFtXcs4U" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC3E4A31; Sat, 23 Mar 2024 01:27:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711157268; cv=none; b=uIQEJgUSW651o5yg8I5YNDNJfvWFp63hRfsO0hZmCMuULH7c8Ox4mQof9QozEEJEZUKAuuZFjjO4uPp7wJW/wXC3v0E3WOy6bF8Hud9l+e/pXM8u6Gpw/ZNc/c1bDD5QtngFCiXKCqlK5B89f1tCteJwjTjijtLXDV5tkdFehsw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711157268; c=relaxed/simple; bh=SnJw3WHU7mGXIfMu4X5OwlfqOErDGWfN6ynEqqaOkmY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MkcWtH520zhgNGQEtjzDF/eg0As8Nc2vlSGeBed0e9FqT+zcIJ8/LAySJ8Rv6rRGsoCIYiYFFSc2j3ebPVM9MoZ3b0Rc6Fk9WGXxFzNrLAbSVl96kRHNIxsY95RG9hNlrZmEHtC2SxKC2tt0MLhOgk3NXPXZgam9BXMYnB+iT2g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sFtXcs4U; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5EA87C433F1; Sat, 23 Mar 2024 01:27:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711157267; bh=SnJw3WHU7mGXIfMu4X5OwlfqOErDGWfN6ynEqqaOkmY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sFtXcs4UiPC+Zkt0BcXfyJ69u9R0J549Sy/aI1d4HV2J7RtrutRDdQGru9lMJY00O zPSWuJ2HrnmtZZ/hwEWzDRRPNJv3dZOE1LSzg2GCJ0VOmQ/YfoAoEpB2ww0clVw0NB tGzBJNW4YOq0t6WHPXf2QYdaNDzpX7UgPCl6moTplpdF2cYu/+zuzO5AYY7GuTwmfN mUSEUl/t1mQOhQjOaZAju3CcNSVkGxPI3N5MmOMTUiCby8bVBuQgVlfSnJSCbnjOwv VMSwHGS8QW2MouRZAVcYkYQaac8ypNRM0X5xqIERO1l1R/nL+dCKeNPYt/B35+i6ON a5lU7bsVRaiZA== Date: Fri, 22 Mar 2024 18:27:45 -0700 From: Saeed Mahameed To: Jakub Kicinski Cc: Jason Gunthorpe , Andy Gospodarek , David Ahern , Greg Kroah-Hartman , Christoph Hellwig , Arnd Bergmann , Leon Romanovsky , Jiri Pirko , Leonid Bloch , Itay Avraham , Saeed Mahameed , Aron Silverton , linux-kernel@vger.kernel.org, "netdev@vger.kernel.org" Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver Message-ID: References: <20240214175735.GG1088888@nvidia.com> <20240304160237.GA2909161@nvidia.com> <9cc7127f-8674-43bc-b4d7-b1c4c2d96fed@kernel.org> <2024032248-ardently-ribcage-a495@gregkh> <510c1b6b-1738-4baa-bdba-54d478633598@kernel.org> <20240322135826.1c4655e2@kernel.org> <20240322214423.GL159172@nvidia.com> <20240322152924.64be7ec4@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20240322152924.64be7ec4@kernel.org> On 22 Mar 15:29, Jakub Kicinski wrote: >On Fri, 22 Mar 2024 18:44:23 -0300 Jason Gunthorpe wrote: >> On Fri, Mar 22, 2024 at 01:58:26PM -0700, Jakub Kicinski wrote: >> > > Well said, David. >> > > >> > > I would totally support doing something like this in a fairly generic >> > > way that could be leveraged/instantiated by drivers that will allow >> > > communication/inspection of hardware blocks in the datapath. There are >> > > lots of different ways this could go, so feedback on this would help get >> > > us all moving in the right direction. >> > >> > The more I learn, the more I am convinced that the technical >> > justifications here are just smoke and mirrors. >> >> Let's see some evidence of this then, point to some sillicon devices >> in the multibillion gate space that don't have complex FW built into >> their design? > >Existence of complex FW does not imply that production systems must >have a backdoor to talk to that FW in kernel-unmitigated fashion. > >As an existence proof I give you NICs we use at Meta. >Or old Netronome NICs, you can pick. > This is not true at all, at least for our NICs. Our NICs do need non-netdev interfaces at least for debug and monitoring non-netdev functionality and use-cases at Meta. We can talk about this offline. Also below you mentioned another one of your vendors using proprietary mechanism for configuration. So you can't just have it both ways. It is obvious to everyone that in the AI era, everyone needs customization, this interface is the proposal for the standardization, if you cared to look at Jason's proposal you will see how he goes in length describing how abstraction can happen in user space. >> > The main motivation for nVidia, Broadcom, (and Enfabrica?) being to >> > hide as much as possible of what you consider your proprietary >> > advantage in the "AI gold rush". >> >> Despite all of those having built devices like this well before the >> "AI gold rush" and it being a general overall design principle for the >> industry because, yes, the silicon technology available actually >> demands it. >> >> It is not to say you couldn't do otherwise, it is just simply too >> expensive. > >I do agree that it is expensive, not sure if it's "too" expensive. >But Linux never promised that our way of doing SW development would >always be the most cost effective option, right? Especially short >term. Or that we'll be competitive time to market. > >> > RDMA is what it is but I really hate how you're trying to pretend >> > that it's is somehow an inherent need of advanced technology and >> > we need to lower the openness standards for all of the kernel. >> >> Open hardware has never been an "openness standard" for the kernel. > >I was in the meeting with a vendor this morning and when explicitly >asked by an SRE (not from my org nor in any way "primed" by me) >whether configuration of some run of the mill PCI thing can be exposed >via devlink params instead of whatever proprietary thing the vendor was >pitching, the vendor's answer was silence and then a pitch of another >proprietary mechanism. > Well, this is why we came up with fwctl interface, so nobody needs to sit in silence and all vendors can agree to one interface. We both know devlink params can't scale well enough and accommodate all vendors and don't forget it's netdev specifc! >So no, the "open hardware" is certainly not a requirement for the >kernel. But users can't get vendors to implement standard Linux >configuration interfaces, and your proposal will make it a lot worse. Vendors are already using proprietary configuration interfaces, using direct PCI access via sysfs.. So on the contrary to what you say, this proposal came to unify vendors, and improve the user's experience.. with fwctl, and the proper use-space shared tooling as Jason's suggested you can force other vendors to follow the herd and implement the new standard interfaces that we already have 3 vendors agree to..