Received: by 2002:a05:7208:3003:b0:81:def:69cd with SMTP id f3csp4284836rba; Tue, 2 Apr 2024 12:20:15 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCX4k8NNe/GJ0SRnmXYqfon22vg2wYUZH+0NQkRuaYMSPy1wsESHHqiyNyoB9tox6hvLzkwmRQK0cjj6FhqVeB1vG+HWZp8CBZ/2yvGPFw== X-Google-Smtp-Source: AGHT+IEJp+aSMhfn8c5ZAIf7mF4DpTAuVMD8gAqzVP2mUQOpi8bC66ALYBkR8xii0+4+sWl0SC9B X-Received: by 2002:a05:622a:5c15:b0:434:3470:dff5 with SMTP id gd21-20020a05622a5c1500b004343470dff5mr4186617qtb.23.1712085614830; Tue, 02 Apr 2024 12:20:14 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712085614; cv=pass; d=google.com; s=arc-20160816; b=cFdb40uI1E33YMPA8zkAdUcKLkSzmPP2wrCCPbfckHqiqLEh60rzTpjJhECF1WdxbE JHwATq9t1CTFjquq+3LdscygX1t/mRsCzqdbPdUChpGuo16O0AORJ+33hB3R7we2ZE22 SNZqudWUwvDjQ8eDAcaIqmCH6FPxJ1dmF7oPx3oMzX4KyloWXgqI9/16bmkLu+xNRGG2 qMKQOa9GsuE7stKZGrep3pU2AONNqmqmuioFnXBuILgC7UfIJrO5DdnmRWn9Kcl8wPZR V+hPywoHTfRF1yPXNmTbc+51ryjGvb5AZG7sm90Hr87vqXijIfNskxzoBKjI4lkyn89Y Mufw== 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=vDDXrv+HikbIl7SvvC23D28x/S6AJ1CWv0ig5Lcrf/o=; fh=DppK+88jEiOIX4kHFbd1FO2NpKWO29MZFImqTIXChJs=; b=wgCDVQ01Z/c2dpFhKZ6tyQsl4YaxghGbS6uRf8yp/ZhGKu7698MKiHCC9u+gbfHoMR 6CmQPwxk0GYe1vuOO9E/TPir0IZA3o+IfhXWcYJOeVnFfljV1xvNFnpyhHMGLyv8utXg diVuketTcAyLsuZ5/1cqPa39caYl/2myHF93Vm9yFTslMkYw5LT+xatChuG/QFFg1l1V XT1gze6htAj0ykUguoDF40M7UH0G46DzBoEtr3BkA81LcMG9gKdUolZLGSZyES6KZ8P9 QFXm2W0WF+fH+haOOJZj1+21RoYEkGyHTM61OxKvnpD3ictfsmlpIsF//kjH/5msgQO5 7LdA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="p0adb/s0"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-128554-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-128554-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. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id ci17-20020a05622a261100b00432b6d3f142si13139969qtb.17.2024.04.02.12.20.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Apr 2024 12:20:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-128554-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="p0adb/s0"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-128554-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-128554-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 947381C225D4 for ; Tue, 2 Apr 2024 19:20:14 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DEAC715B57F; Tue, 2 Apr 2024 19:20:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p0adb/s0" 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 06E052C9D; Tue, 2 Apr 2024 19:20:05 +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=1712085606; cv=none; b=Bh2oKZg/XBn1TgiOdLFiE0hV0+iGBUy9Tf7BBwzsg0iwN/W4bcra1Mcj6tsF87BhB9pW61ssquR33s8X2tJFtmjo8PI53+FdKWtQsppTqujQCpAElEE/1otEoRAhYHWZOTe14hf6SW+V2BEfya4Q5rGyEC/qyU6srN6Ajs4OeSc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712085606; c=relaxed/simple; bh=xLpJZ8NXTAClbq6nSFG+T4k+KQApXOEcPjNpsIydk5s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KVxHL4DA0WCD/TVIFlDKL+wohB5sqBSMYXBUC+Tt4LffzvxajZ5LTi6pxs1i5rG1J6+HLRic7O3+9L1PGgsk/BIlq1e11kcvPvZEvfWIsE4Y+V6IHYm/p5xc29cLmtp7/qV/JRI0iylSkW+2j/vkaltCcxH5HTPXGN0ixxXlMnA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p0adb/s0; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE1A7C433C7; Tue, 2 Apr 2024 19:20:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712085605; bh=xLpJZ8NXTAClbq6nSFG+T4k+KQApXOEcPjNpsIydk5s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=p0adb/s0fi7dJ67UdTzGLdygrJ2ZX0HWC/tXcURGkKtdWdISqYJtafCWlE9Mh5YTO qDXTx3Jfv1cGXEyPbZ9GVq9lFOA6EYOw4p6YxvVXl9sV2uzSulZkiN8Zysl6ms9L6U Ay3IkK7hZakzcO9QRjzwh3a40bdltUP88bl5mC9i/3ahT9PcJzS04ejgd0sLFWQ+j8 K5SyxKR7z+UOG4MwVMynuo5XHr+FXJn+7KkcelB23h0yLQPSMXsRemTH1GK098y2t3 1BabJFgNM1CxN8JR0eUTGBWzRSO3NmK/4aJG9uzHG8ZtveaIledTSzx3+crH4DORYU 8GL+MjlA6nStg== Date: Tue, 2 Apr 2024 22:20:01 +0300 From: Leon Romanovsky To: Jakub Kicinski Cc: David Ahern , 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 , Junxian Huang Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver Message-ID: <20240402192001.GQ11187@unreal> References: <510c1b6b-1738-4baa-bdba-54d478633598@kernel.org> <20240322135826.1c4655e2@kernel.org> <20240322154027.5555780a@kernel.org> <1cd2a70c-17b8-4421-b70b-3c0199a84a6a@kernel.org> <20240401123003.GC73174@unreal> <20240401075003.70f5cb4b@kernel.org> <20240401181033.GB11187@unreal> <20240401120420.4d33a89b@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 Content-Disposition: inline In-Reply-To: <20240401120420.4d33a89b@kernel.org> On Mon, Apr 01, 2024 at 12:04:20PM -0700, Jakub Kicinski wrote: > On Mon, 1 Apr 2024 21:10:33 +0300 Leon Romanovsky wrote: > > > Sorry, I have a completely different reading of that thread. > > > Thanks for bringing it up, tho. > > > > Different people have different opinions, and it is fine. > > Agreed! I think the core of our disagreement is whether and when > one set of people get to force their set of choices on other people. > Far be it from me to try to force my opinions in RDMA or the kernel > as a whole. > > > > As I said multiple times I agree that configuring custom parameters > > > in RDMA is a necessity. Junxian's approach of putting such code in > > > the RDMA driver / subsystem is more than reasonable. Even better, > > > it looks like the API is fairly narrowly defined. > > > > It was a tiny example, which emphasizes the need for a common way. > > > > If we were listen to average RDMA driver author, we would find ourselves > > with gazillion different sysfs knobs which do nothing except sending > > raw data to FW. As a subsystem, we don't want to waste our time in > > not-beneficial to the subsystem code. > > No disagreement here either, there's a trade-off here between what > you call waste of time and what I'd call fostering organic > collaboration. Even without taking your priorities into account - > whether reviewing device APIs is beneficial is (a) subjective, > (b) subsystem dependent, so you should be allowed to make your choice > (within the bounds of Linus's trust). But what I keep arguing is that > so should we :| Internal device API is a different story, and I assure you that we are very close in our views here. Probably main difference is that I'm very lax for first user and very strict for the second one, while you are more stricter than me even for the first one. I gave an example from HNS for API to configure FW without any subsystem involvement and there is no real way to push to collaboration here without standardization. Thanks