From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BF93C4167B for ; Tue, 28 Nov 2023 19:31:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234821AbjK1Tbq (ORCPT ); Tue, 28 Nov 2023 14:31:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229927AbjK1Tbp (ORCPT ); Tue, 28 Nov 2023 14:31:45 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4DCD1988 for ; Tue, 28 Nov 2023 11:31:51 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F498C433C8; Tue, 28 Nov 2023 19:31:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701199911; bh=zCDwbROaUVxfVcFqjwU03nDOAOmZ9prweH8i9xKxAMs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HJXfN25Ahmu/3BcSrAj1tMC4nv613mpyfegOsfbV1J3RRSuIuT2Qu8zlKSK6ZSCAZ dbD6asZm5S978AOcYRhBxlGBnjJv6GxjVhlLoy2P6+XotXCgTYHqY07K6J8NtnTkR8 t4KTt6wZhesr7FIczoyJhqV6IIg8mQSKpA/UXRX49+5ct6W6xkFW1fbjHC6vYCGpp6 pDYCeA7ijdbgTrTJwWfEnIz0T+pcXuuwtj98Dt1OdmiLjXoZgZdtRwt5z5SuZjCNpR VeFMWESfLP7QWXvI/JDdNggCOxx1Sq7txEpywc5ZmijAmNEFpLzFb8UtGv4NJ+1rqv ttqnU4SWXV+hQ== Date: Tue, 28 Nov 2023 11:31:49 -0800 From: Saeed Mahameed To: Jakub Kicinski Cc: Jason Gunthorpe , David Ahern , Greg Kroah-Hartman , Arnd Bergmann , Leon Romanovsky , Jiri Pirko , Leonid Bloch , Itay Avraham , linux-kernel@vger.kernel.org, Saeed Mahameed Subject: Re: [PATCH V3 2/5] misc: mlx5ctl: Add mlx5ctl misc driver Message-ID: References: <20231127144017.GK436702@nvidia.com> <2023112752-pastel-unholy-c63d@gregkh> <20231127161732.GL436702@nvidia.com> <2023112707-feline-unselect-692f@gregkh> <20231127160719.4a8b2ad1@kernel.org> <20231128044628.GA8901@u2004-local> <20231128065321.53d4d5bb@kernel.org> <20231128162413.GP436702@nvidia.com> <20231128084421.6321b9b2@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20231128084421.6321b9b2@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28 Nov 08:44, Jakub Kicinski wrote: >On Tue, 28 Nov 2023 12:24:13 -0400 Jason Gunthorpe wrote: >> You said you already rejected it at the very start of this discussion >> and linked to the video recording of the rejection discussion: >> >> https://lore.kernel.org/all/20231019165055.GT3952@nvidia.com/ >> >> This session was specifically on the 600 FW configuration parameters >> that mlx5 has. This is something that is done today on non-secure boot >> systems with direct PCI access on sysfs and would be absorbed into >> this driver on secure-boot systems. Ie nothing really changes from the >> broader ecosystem perspective. > >The question at LPC was about making devlink params completely >transparent to the kernel. Basically added directly from FW. >That what I was not happy about. > >You can add as many params at the driver level as you want. >In fact I asked Saeed repeatedly to start posting all those >params instead of complaining. > We posted many params over the years the you shot down on the spot, do you really expect me to implement 600 of those knowing that you will nack 80% of them asking to have common knobs for all vendors, and you know that is impossible. you nack patches then ask for a porpossal, we came up with many proposal and discussed them face to face on multiple occasions, LPC/netconf etc, then you ask for patches, then you nack again, we are just going in circles here.. >> I second Dave's question - if you do not like mlx5ctl, then what is >> your vision to solve all these user problems? > >Let the users complain about the user problems. Also something >I repeatedly told Saeed. His response was something along the lines >of users are secret, they can't post on the list, blah, blah. > I never said it is a secret, but I can't publicly reveal who my customers are and what they want, you know very well who asked for the high frequency counter sampling.. So we came up with a very clear solution, that has nothing to do with netdev, since for that particular use-case it is not netdev specific, and netdev stack isn't even present. >You know one user who is participating in this thread? >*ME* >While the lot of you work for vendors. And how *YOU* expect the vendors to debug *YOUR* issues, if you don't allow them to access their HW? Asking all vendors to use *YOUR* "devlink generic_dev generic_knob" is an insult to all vendors, how about you provide the ASIC design and RTLs to all vendors and we just manufacture it for you..