From mboxrd@z Thu Jan 1 00:00:00 1970 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 757742DA74D; Tue, 4 Nov 2025 19:22:18 +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=1762284138; cv=none; b=OiD0w+lOqDPz3+Nr9KdiNQ9JBmo5nDHPsq1kB98/wVBhTkJS6inKvrm+p5+kG4dQg8pyyMSGCf8tl9UxcSKwA8m2QWEgqNpUThlmvNoNINJAo8+/pLHvYcmEwt2tFGLK+H0/AaRsj4roUqwc/2iFL+gvTGwp2lLb3YLzm7Di8XM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762284138; c=relaxed/simple; bh=+lf7dW++l2EW9+9yEsAcle5UBElW4w+UfVpXaHOHW2Y=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=iiXUsgGjyXkPOmTLbUdAwSAhSJw+J8rDINuC46XCevETeFXg8hNauXVgEqYixPs/vraNT9hBxELvcYLV8PGkjuG2uubnb9FcbNgdtGypSqrPLNWFsaDElJjUYYoC1XBXLGmHUwzBru2CPfBaOGlJLFta5QUL/TZb2N1ccyM6qgs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=B+/TZv1X; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="B+/TZv1X" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A88DC16AAE; Tue, 4 Nov 2025 19:22:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762284138; bh=+lf7dW++l2EW9+9yEsAcle5UBElW4w+UfVpXaHOHW2Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=B+/TZv1XRq0zzd5NbGu3Z9bN5OyQZnNOsope6laxMrWxA3/9XRg7VX+3PhsjNe7lW 5cbgxn6SqwRaVkJbyodTHSn0LdeO5DaMLbCFV/YkdMgryijwrq6LyocnrsiVuNyhLv xHsrmZselWKpvNIRQMjhLTdiIa0VnfoixY52BS0uFlEVig1wBgEFGzD/T3bGyB56e6 1l8b7lD0a36nrmABwnEvq70bPZRM5IzkSVy7iTQN+TPjab7k/GpzkYFUllJxth410q 4+JiRU+f29KNZ9lJy0ZuU0cQlh4AQfIsQMj0TIhuqexc7SbGFrZJBc5IimM07mEMvE R1RZeW1bSnP0w== Date: Tue, 4 Nov 2025 11:22:14 -0800 From: Jakub Kicinski To: Jiri Pirko Cc: Daniel Zahka , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Jonathan Corbet , Srujana Challa , Bharat Bhushan , Herbert Xu , Brett Creeley , Andrew Lunn , Michael Chan , Pavan Chebbi , Tony Nguyen , Przemek Kitszel , Sunil Goutham , Linu Cherian , Geetha sowjanya , Jerin Jacob , hariprasad , Subbaraya Sundeep , Tariq Toukan , Saeed Mahameed , Leon Romanovsky , Mark Bloch , Ido Schimmel , Petr Machata , Manish Chopra , Maxime Coquelin , Alexandre Torgue , Siddharth Vadapalli , Roger Quadros , Loic Poulain , Sergey Ryazanov , Johannes Berg , Vladimir Oltean , Michal Swiatkowski , Aleksandr Loktionov , Dave Ertman , Vlad Dumitrescu , "Russell King (Oracle)" , Alexander Sverdlin , Lorenzo Bianconi , netdev@vger.kernel.org, linux-doc@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-rdma@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org Subject: Re: [PATCH net-next v2 2/2] net/mlx5: implement swp_l4_csum_mode via devlink params Message-ID: <20251104112214.7f60b252@kernel.org> In-Reply-To: References: <20251103194554.3203178-1-daniel.zahka@gmail.com> <20251103194554.3203178-3-daniel.zahka@gmail.com> Precedence: bulk X-Mailing-List: linux-rdma@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 4 Nov 2025 11:14:03 +0100 Jiri Pirko wrote: > >@@ -548,6 +703,12 @@ static const struct devlink_param mlx5_nv_param_devlink_params[] = { > > mlx5_nv_param_devlink_cqe_compress_get, > > mlx5_nv_param_devlink_cqe_compress_set, > > mlx5_nv_param_devlink_cqe_compress_validate), > >+ DEVLINK_PARAM_DRIVER(MLX5_DEVLINK_PARAM_ID_SWP_L4_CSUM_MODE, > >+ "swp_l4_csum_mode", DEVLINK_PARAM_TYPE_STRING, > > I still think that even unlikely this will be implemented in other > driver, it is generic param. Could you please treat it as such? We need a clearer definition of what this does then. Is it basically disabling silicon validation of L4 checksum and allows for the FW to compute the L4 checksum? Which may negatively impact performance? (hence disabled by default?)