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 850771FCFFC; Wed, 4 Mar 2026 18:15:24 +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=1772648124; cv=none; b=pEfChQO5PpGp0qJUYQ1Fu3G0VpvBAH2NO96Rt22uzd3hj7trOMyJPNBBOTsnieSamqTuIWibzFd7KbISG0PSLuEeY5Xmp9j7ziOr/e2NMRtCDt3hJvrAG+A8tvDTzx/ffbJxeOWWUalGAip5z4OsYv8xIC/9nMe7tyfUjPnBtmE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772648124; c=relaxed/simple; bh=i3AdJpcQctz2YOqXPjkQFg+xjHKpWsnaX71lZqXYgTI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HAkk36apwyDmvL3ZI2+SNwvtT8ynXA5vbnALv2zgHi4hH/O+cCj5E0lc4JbQMHHw1lEiRnMKMh/wFe7DL3xrWRFYh/2oG8smHQyNkDHGxWymJennf9V8JP9kiTl52Ui18W9ZtMIQ0t9od68GOjR4DWgFwxLQL4KWU/npGEyAaHQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hTKWakEr; 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="hTKWakEr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14C30C4CEF7; Wed, 4 Mar 2026 18:15:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772648123; bh=i3AdJpcQctz2YOqXPjkQFg+xjHKpWsnaX71lZqXYgTI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hTKWakErJUMN6EOHtpPun6JoiuBIL31PVHyD1aOa9dHGGA6DdB7MCzOdA1CZp2V4A JDEX7JmDdnPZKsyOhNKkXvHds9jcKOWeufqyfS1poXMIqetu6jQbhGafvC9yQyOQ3/ BDBDH0uSVj47mC4LDMXG0i/vCTGUCCTgmRohYeauaOqaovoKlX/AreOV7+vjWZAAQn 41Dkms5LJaGlMyafs7kSyjOqEe8ZCUgrZrexfazfyNKtTdSzbwn3n5nmLLkpGHkhAr 2UCaLvxEY4yyZGk0YmlEa1C6zJM9W1BRcdXsqakqlayKn2aK9UVAoDaQcNtZwO0Lg0 pn73FWH+XHwVw== Date: Wed, 4 Mar 2026 10:15:22 -0800 From: Jakub Kicinski To: Jiri Pirko Cc: Tariq Toukan , Eric Dumazet , Paolo Abeni , Andrew Lunn , "David S. Miller" , Donald Hunter , Jonathan Corbet , Saeed Mahameed , Leon Romanovsky , Mark Bloch , Shuah Khan , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kselftest@vger.kernel.org, Gal Pressman , Dragos Tatulea , Shay Drory , Jiri Pirko , Moshe Shemesh Subject: Re: [PATCH net-next V3 00/10] devlink: add per-port resource support Message-ID: <20260304101522.09da1f58@kernel.org> In-Reply-To: References: <20260226221916.1800227-1-tariqt@nvidia.com> <20260302192640.49af074f@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-Transfer-Encoding: 7bit On Wed, 4 Mar 2026 11:34:13 +0100 Jiri Pirko wrote: > >>I have a strong suspicion that the user will want to access all > >>resources of a device. `devlink resource show [$dev]` should dump > >>all resources devlink knows about, including port ones. > >> > >>What's the reason for the new command? > > > >You are right, one cmd would do. Good thing someone forgot to implement > >dump for it :) > > On a second thought, if we merge multiple objects into one dump, how > does this extend? I mean, the userspace has to check there are no extra > attributes, as they may be used as a handle to another new object > introduced in the future... Idk, it's a bit odd. That's true, the user space must be able to interpret the object identifier. So if we extend the command to add more identifiers we will have to add the bitmask to the dump request, and have the user space tell the kernel which objects it can recognize. I was just saying that we don't have to add such attribute now, maybe leave a comment in a strategic place for our future selves?