Received: by 2002:a05:7208:3003:b0:81:def:69cd with SMTP id f3csp4266715rba; Tue, 2 Apr 2024 11:48:47 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWeqkxmWL2RB6ivd5VsJTPupZZwxHnwL+gJFumkJjbcCBn/wJPcL8tpPjwdD7DE+iGuDTP1phpL13uPSZrN8BLAQ6Ez424YmbZCeDTwZQ== X-Google-Smtp-Source: AGHT+IEpVtL4+kpMdx+TasCdOOTp4HZ3mrWe0il5S1YtLZqtLD8VHW1zuFFsChH7Hgxccgaokcql X-Received: by 2002:a9d:6c0c:0:b0:6e6:8916:da26 with SMTP id f12-20020a9d6c0c000000b006e68916da26mr13176071otq.1.1712083727064; Tue, 02 Apr 2024 11:48:47 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712083727; cv=pass; d=google.com; s=arc-20160816; b=UH3nA2i4mmsccnGjHyivnxZt9BVWcby2T6pwduqipeZsdWgiElLxLP+xCXOtrubN8A 0QsImlsFVvteBq2Hn78/aIziOOGOoIPGmjDURdWGRX692yP8Rxf27P/lJLlCmG7lb3fI 3z3zgR7JODkll5gPBx8dkbhyoxjQqb2mKJx7fI8rko2KvCaBULSVGcY/znZfGIKC+8// +Zsr3pCYnXjjOPDc9mOj35X9Yj0oFR5qGErELtzL5UX5aGe9gmekcKFDMB8cAoSPgCul ohplWnOYgsMC+VDz2AVNsBxccPTmlTG4sA+G7vDpSSfCN7LyhwiOSuy6h0345/FsHrs7 JMxg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=d46dk20gnWloWjPBiMR2Qh20eHEuK49vKdmXscSjI98=; fh=5NGmKs2y8Cr89hyf5GxjWMipyRZMPMfyFK6TEJ96L7g=; b=EyRmgLNpMdc1Gag4a4YDmheeZLnTGPioPJwpppUiVfni0u0bYU913KmP0VaGQVyPq2 ncwfM1DlXVEAcaj0oXeSQmVjzTlzrfmW/VG7OuiJt20KLuOcdK+20LUHQeervk/w4fjZ yzB1bR3/mjoXMnXDFkkK5jB7dLvlFucioZFtOX+Ctp7JL2MEZPznLmjG/Ea8M+5629yS kur7ZxdhxXiQuQLLhSafUe5lGSmJxYR2nylzkMfHZYOrCQErc8NeL0B/ABOhFMQv3vN8 XrIzvzTTjCFHKyCLPlePdHj1JXfsnpNGqjE+MTPOzJrgIJHdm3FmDv5++JjI1CCACTnj FivQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pQCHQU5E; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-128519-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-128519-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id dh7-20020a05622a4e0700b00432d86e2c23si6244898qtb.356.2024.04.02.11.48.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Apr 2024 11:48:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-128519-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pQCHQU5E; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-128519-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-128519-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 ny.mirrors.kernel.org (Postfix) with ESMTPS id B3FDE1C21C4A for ; Tue, 2 Apr 2024 18:48:46 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 02AFF15B542; Tue, 2 Apr 2024 18:48:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pQCHQU5E" 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 221E615AAAA; Tue, 2 Apr 2024 18:48:37 +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=1712083717; cv=none; b=XxgA6SKsQK5Hlb33Kqh2wFAuXsnBPm7HqcvDwET/bPmFdrX+TKCxplh0OsHcBWe0RXm+/cZQl4y9kiLkTSe4Aqv49r+addjZPcJ8muS4RBhCA3UW0OnyQ6D2VAwACMsGCA1gEdlJ09niHlGty/9+poXHElULALgEDWQeocKRfpo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712083717; c=relaxed/simple; bh=mKrjhnY8pVcgEHLKKw5VsWYAh/llZ4ifRJMaYVxScms=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Aupp2iWQMGecgoHCfcdqHNVpTwUemee8ev+05TQfdxoX/g/vEuy5Z+NTgQlo9dQnFn9THckWCHDQsptUZJXF7NNNRj+2ESMdcJ+LvMzNc1al12mcqNZtWUuuO5DBPh4RzMiARbmoQY1MIzlvUmK9VzplUIwxe1xtDbuIhlleG3s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pQCHQU5E; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4794BC433C7; Tue, 2 Apr 2024 18:48:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712083716; bh=mKrjhnY8pVcgEHLKKw5VsWYAh/llZ4ifRJMaYVxScms=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pQCHQU5EecHUloNS1mzyuT76vUsvoHOW8HJUKnliuoM2IRbghFV20xjh4JSmnZDrU NHAeHggejGhmARM1CeO6eIn+Q0ashBEccumjvC4KtesoTAdt536j68NaubLwBuW35X gxiHQrFtU/PP+NDvhD586PfmvLOc71bnlJAS0tyUNJLNeM3b1a+QHafG1uct3qGgeC AyNDZC6eQFBWQp1O6JTvsuirt08Vr+DJVTdGWslII5OpB62srTUFC/Ue3+05JODGGN ZUHs25oM4sZh/+3h6s/X5hTbcIxmQS57QGOfzkCwBZQejF4KROYn9No29ubTZKj2y1 RQtdbK0MDFkig== Date: Tue, 2 Apr 2024 21:48:32 +0300 From: Leon Romanovsky To: Edward Cree Cc: David Ahern , Jakub Kicinski , Greg Kroah-Hartman , Jason Gunthorpe , Christoph Hellwig , Saeed Mahameed , Arnd Bergmann , Jiri Pirko , Leonid Bloch , Itay Avraham , Saeed Mahameed , Aron Silverton , linux-kernel@vger.kernel.org, "netdev@vger.kernel.org" , Andy Gospodarek Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver Message-ID: <20240402184832.GO11187@unreal> References: <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> <20240322154027.5555780a@kernel.org> <1cd2a70c-17b8-4421-b70b-3c0199a84a6a@kernel.org> <0ea32dd4-f408-5870-77eb-f18899f1ad44@gmail.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0ea32dd4-f408-5870-77eb-f18899f1ad44@gmail.com> On Tue, Apr 02, 2024 at 05:32:44PM +0100, Edward Cree wrote: > On 26/03/2024 14:57, David Ahern wrote: > > The proposal is an attempt at a common interface and common tooling to a > > degree but independent of any specific subsystem of which many are > > supported by the device. > > [ Let me prefix this by noting that I'm speaking personally here, and > not representing the position of my employer. ] <...> > you're getting maintainer pushback. May I suggest you to take a short break, collect names of people who participated in this discussion and check in git history/MAINTAINERS file their contribution to the linux kernel? After you do that, try to ask yourself if your response is still appropriate. Thanks. > > Do we need to go all the way back to operating systems 101 and point out > that one of the fundamental jobs of a kernel is to *abstract* the > hardware, and provide *services* to userspace rather than mere devices? > > Frankly, this whole thread reads to me like certain vendors whining that > they weren't expecting to have to get their new features *reviewed* by > upstream — possibly they thought devlink params would just get rubber- > stamped — and now they're finding that the kernel's quality standards > still apply. > Complaining that devlink params "don't scale" is disingenuous. Patches > aren't languishing for want of reviewer resources; it's just that it > takes *submitter* time and effort to bring them up to the quality level > that's required, and occasionally the vendor has to (shock! horror!) > tell the world what one of their magic knobs actually *does*. > > If all the configuration of these Complex Devices™ goes through fwctl > backdoors, where exactly is anyone going to discover the commonalities > to underlie the generic interfaces of the next generation? What would > configuring plain vanilla netdevs be like today if, instead of a set of > well-defined cross-vendor APIs, ethtool (say) had been a mechanism to > write arbitrary values to hardware registers on the NIC? > These commonalities are key to allowing a product category to mature. I > realise vendors in many cases don't want that to happen, because mature > products are largely commoditised and thus don't command huge margins; > but Linux isn't here to serve vendors' interests at the expense of > users. > > On 23/03/2024 01:27, Saeed Mahameed wrote: > > It is obvious to everyone that in the AI era, everyone needs > > customization > > It's always possible to argue that the New Thing is qualitatively > different from anything that went before, that these "multibillion > gate devices" need to be able to break the rules. > But the truth is, you aren't that special. > > -e