From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AEB39429CF1 for ; Mon, 27 Jul 2026 20:42:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785184952; cv=none; b=h9j7goAi76hD5yIGR8WGjj8aaaMvRf0G3awESNRuE6kxYuPNUbO4ieRbSlopNG0iL1Vmx53jov9D+CWMWCZMErAxC6bgbhEls0/Rzz4tZNeDS3PrLxqDd59Jx+XhvFNSKtQ5+ZjU0YJKrHINl9YFxc0/e5ZLBslL2dwhs98pEaQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785184952; c=relaxed/simple; bh=Ui3YovzBnEITRwv6UiFGujNRa6R42S7qnYRz7X1pT40=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=I/e9KA8pAYe1LYXKrhF9OWKWbFvqCLux1IB+8Hwf8k2dLajbVTRIBmjt8ujcJARak/pmA+CGVagMazwFB2OtlW1/QOmxCIFp+sLzfx2vjsvpfIL7d6oGHiU8MoESYJ5Gw05FsbNp86LLgHLCSw4otquA3naWRXvRsc5sdhO3ZHw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org; spf=none smtp.mailfrom=blackwall.org; dkim=pass (2048-bit key) header.d=blackwall.org header.i=@blackwall.org header.b=lZEG50nt; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=blackwall.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=blackwall.org header.i=@blackwall.org header.b="lZEG50nt" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4921eed3fa2so21795875e9.0 for ; Mon, 27 Jul 2026 13:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackwall.org; s=google; t=1785184947; x=1785789747; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=vAavlAAVVFUy/ko+lCR7ziFkEFuLRUE1b0ehH46la8s=; b=lZEG50ntroaQ190TVDFMtw/05wD06liLklOPD4cKD9G3xV54J4MVBiGYn+TQ/2OO7J j3nvYlT5wvyZ9tflKETZcKu+uBqPcJFOl64tPrrgGUPwqSCuHe0Sb6FBNnHD04wqSAYY fL/Lev5CKfdUDKGbogy4knBhENROsDW3r2eXM7sgkrMuS67nIdFCuoaXrTd7rYBhFJGz oGS6OEeMGpz5VsClYAnUKzH1ofePUR3rOODRX782TKTjC+0PLbazybZG80/MgGpcVS/k kE7tfGYcMcG/8ttmcXCha8KI6IB1aCSE9jtVJ8rtJQD6pdEYueJDqAkERFMO1VFG3hss UJPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785184947; x=1785789747; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=vAavlAAVVFUy/ko+lCR7ziFkEFuLRUE1b0ehH46la8s=; b=oHaU57UPnv2PglF3MC++gaf4uMSAL5GkjQOghEoO7HezezlIY9nUWdjFAIffwg45cI qlDyMbnyyyN+tw24fM/KE+ZwrZ7S/jhGU8fZfTlpilPa5Nvq9GPnUrvU5pDpltJ/f0QX oY9WF74fGcqQ7o3g8d9R4ND2NnHxYvxorsFj5k3HT/Rbtg+dr5eBC/rzBCqHLv3hWjQ9 8H3y13rh6lcOHRQ5CcFCHH3sjO7UjhvZoygr5723Dmr60RXCfQJ5A2PqGDsPc7D4Ve+v gW8hQNBfXaVWOQstnOp3vayTo4hLCW+nsUs4CFb4G6RRvVVhm1jDAGP4U5lMg/qFlgwP dV3Q== X-Forwarded-Encrypted: i=1; AHgh+RrQDaVWIYrbGep67nElXZ3Ei0N0nDb57A92Xd2vUYzKw6EHMBUMUyXMABehgdp2ALMa/jtkeNpyZnCSO78=@vger.kernel.org X-Gm-Message-State: AOJu0YwJxWDgzQigL2QRbQwgIRst0BsdQYo/LjgBDZAxlQgW06kKqzqI fEPDm371CHsFICgBhoZfUbnvJFFMKNWxMsG7syDb8DDt2iM9LoAyVahijDAwyYFKWBg= X-Gm-Gg: AR+sD11pHRkWbVMQ4OC54tn4gXi/XU0VB3+sGm0oshGdMsZix+wJkpGkIQ5ujKzh0Eh fXUvT+1IvpTutmrfp7H8N/2VbFl4OUCNdP4/e09nfKGqj8wR1ryTbePKPSt263j/CKqhp1flcBG nMClG8ScHIKS79Bz0dB0/nMpymEW52Zk1nEBEUW7MCssaAq1vAAaUpUnOn28UODCfJl57qSE6Oq 9DjZpaiTODx9PvMbHrnuTKUlKZvTS2aKAc1PdXonJpXpqsGXM42ORMd63Z0bGBtkGBOC2MdOvk4 E1TydFlpz0V4hy+v8Ed1lJ5cIbUNy3Z/5hUBaSPFpY5Z7voxrEbeYvze6sgspP5WlhbqayFCdRy fyAa0CBRyyqgvBp/AjnBEQb5sacZ91yE2wIPNVB+pIkk4zOoserEZ/o+xPDAjHocuXyXOljBF7g == X-Received: by 2002:a05:600c:2192:b0:493:b56b:c45c with SMTP id 5b1f17b1804b1-496c4fd94ebmr4334485e9.30.1785184946481; Mon, 27 Jul 2026 13:42:26 -0700 (PDT) Received: from localhost ([109.160.73.171]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85bb57cfsm53391608f8f.11.2026.07.27.13.42.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jul 2026 13:42:26 -0700 (PDT) Date: Mon, 27 Jul 2026 23:42:18 +0300 From: Nikolay Aleksandrov To: Tariq Toukan Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , netdev@vger.kernel.org, Paolo Abeni , Aleksandr Loktionov , Alexander Lobakin , Arthur Kiyanovski , Daniel Zahka , David Ahern , Gal Pressman , Jiri Pirko , Jiri Pirko , Jonathan Corbet , Leon Romanovsky , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, Mark Bloch , Petr Machata , Przemek Kitszel , Ratheesh Kannoth , Saeed Mahameed , Shuah Khan , Simon Horman , Vlad Dumitrescu Subject: Re: [PATCH net-next V4 2/2] net/mlx5: implement max_sfs parameter Message-ID: References: <20260723082643.1870844-1-tariqt@nvidia.com> <20260723082643.1870844-3-tariqt@nvidia.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=us-ascii Content-Disposition: inline In-Reply-To: <20260723082643.1870844-3-tariqt@nvidia.com> On Thu, Jul 23, 2026 at 11:26:43AM +0300, Tariq Toukan wrote: > From: Nikolay Aleksandrov > > Implement max_sfs generic parameter to allow users to control the total > light-weight NIC subfunctions that can be created using devlink instead > of external vendor tools. A value of 0 will effectively disable creation > of new subfunction devices. A warning is sent to user-space via extack > (returning extack without error code is interpreted as a warning by > user-space tools). The maximum value is capped at U16_MAX. > > Signed-off-by: Nikolay Aleksandrov > Reviewed-by: David Ahern > Reviewed-by: Alexander Lobakin > Signed-off-by: Tariq Toukan > --- > Documentation/networking/devlink/mlx5.rst | 7 +- > .../mellanox/mlx5/core/lib/nv_param.c | 118 +++++++++++++++++- > 2 files changed, 121 insertions(+), 4 deletions(-) > Sashiko has 2 comments: > + data = MLX5_ADDR_OF(mnvda_reg, mnvda, configuration_item_data); > + MLX5_SET(nv_global_pci_conf, data, per_pf_num_sf, !!ctx->val.vu32); If max_sfs is set to 0 for a single Physical Function (PF), does this unintentionally clear the global per_pf_num_sf bit? The commit message and documentation indicate max_sfs applies to each PF independently. However, clearing this global device configuration bit would silently disable Subfunction capabilities for all other PFs on the entire device. Could this break Subfunction configurations on independent ports? Answer: Yes, it does. I just tested it and it switches the config for both PFs on a device. Somehow I missed this, and it was in earlier reviews as well. The !!ctx->val.vu32 should just be 1. I'm sorry for the noise, I'll fix it and queue v5. and Does this unconditionally overwrite any existing configuration for the SubFunction BAR size? When a user configures a custom log_sf_bar_size via firmware tools like mlxconfig, and then later uses devlink to change max_sfs, it appears this line discards any non-zero value already present in the configuration data and forcibly replaces it with MLX5_DEFAULT_LOG_SF_BAR_SIZE. Should this code preserve the existing log_sf_bar_size if it was already configured? Answer: Yes, it does and it is okay. That was intentional.