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 9B9F430FC26; Tue, 5 May 2026 01:21: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=1777944084; cv=none; b=QTR70IVPGF8syBT+vEgyzZLaSsH2b+o1hYtDyrATxHY4DRUfnkLbZjoXdqBe1FOXex7QtAq0ZYaBPyydZF3NHwU5ZvpP9DIWRa/8N1vnH8ij0DIAX+1pY5wRc3+ePnhsxkwPxXik/1IeQnu/aUDJ3T8f20R31rbbEVYYaYSf2ik= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777944084; c=relaxed/simple; bh=WFjVRf1GxXlnia9YSNKUChMaNSiPGz8MkXkFb/g359A=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=UVh9J8PhHdv0eIWQn28nq9aQ0jKxAvoPr3OxCplQ+D4gcEGmWS0Ed2TRsrt3iOhjJqVvtowpHbq0BuVMxcyRJO68Szdbxbc+0UhWl6DWQKZ6O8zKmOfdEguZZJUv0Qj0NMdqEdNHeYVJBtBRxD3phf1TusI1GOfQcUnAA/yQelc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HHSaAKe3; 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="HHSaAKe3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30F9FC2BCB8; Tue, 5 May 2026 01:21:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777944084; bh=WFjVRf1GxXlnia9YSNKUChMaNSiPGz8MkXkFb/g359A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HHSaAKe3Lvevpp9ukIS8pu43GTcOlDXPBXk4kZAfqJ5uPLx9cGKcudfMCfdXt9dOu bQLgjOTAne3LS+CNOKX2keDrtCJfxZE8AjxP7OMHRXMiKlYM/P4zqkAoEyLZtJ9spa ByYrhpigZlvF+tZ+qr02Xyv7M2X2tvqByAdp4ATplY5Hbnhrf3BzQy8U8cwHgyBd8g tebi87vk+hL1ZqqD5yM1KIFZ/QJw0+xb+G6KloZdtBIeuurghRY5WyqA/nGjamkP2i lmtspc8HFGWk+s9ytolI5fS+Nr4ujKFU3ocQPHWOwzYYoEcFJCwFzGbwbAIiFaeZ8n qC0EXobeSG4wg== Date: Mon, 4 May 2026 18:21:22 -0700 From: Jakub Kicinski To: Mark Bloch Cc: Tariq Toukan , Eric Dumazet , Paolo Abeni , Andrew Lunn , "David S. Miller" , Leon Romanovsky , Jason Gunthorpe , Saeed Mahameed , Shay Drory , Or Har-Toov , Edward Srouji , Maher Sanalla , Simon Horman , Gerd Bayer , Moshe Shemesh , Kees Cook , Patrisious Haddad , Parav Pandit , Carolina Jubran , Cosmin Ratiu , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Gal Pressman , Dragos Tatulea Subject: Re: [PATCH net-next V2 7/7] net/mlx5: Add profile to auto-enable switchdev mode at device init Message-ID: <20260504182122.08efb41e@kernel.org> In-Reply-To: References: <20260501041633.231662-1-tariqt@nvidia.com> <20260501041633.231662-8-tariqt@nvidia.com> <421e8885-5849-4390-8956-9bc344fa0bf0@nvidia.com> <20260502184153.4fd8d06f@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=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 3 May 2026 10:51:06 +0300 Mark Bloch wrote: > On 03/05/2026 4:41, Jakub Kicinski wrote: > > On Sat, 2 May 2026 23:08:43 +0300 Mark Bloch wrote: =20 > >> Before I respin for the unrelated MR_CACHE cleanup, I=E2=80=99d like t= o confirm > >> whether the opt-in profile approach is acceptable at all. Regardless > >> of this last patch, the first 6 patches fix real representor/LAG locki= ng > >> issues and are needed independently, so I=E2=80=99d like to keep those= moving toward > >> acceptance as soon as possible. =20 > >=20 > > For probe-time config module param is probably our only option. > > I'd obviously prefer to have a devlink-level knob for this, instead=20 > > of a mlx5 specific one. Can we come up with some format that'd apply > > more broadly? devlink=3D[$bfd:]flag1 ? so devlink=3D[$bdf:]switchdev-mo= de ? =20 >=20 > I=E2=80=99m not convinced this is really a generic devlink knob problem. I'm surprised you say that. Anyone using switchdev mode could benefit. Having the probe in one mode and switch adds to boot time. Whether it's a DPU or not is quite secondary. Unless there's another deeper reason which makes the DPU incapable of running in the non-switchdev mode. But not sure that squares with the code you posted AFAICT. > A device should probe in its selected/default configuration. For DPU > deployments switchdev is the expected operating mode. mlx5 just made the > wrong default choice historically, and this profile is a way to move away > from that without forcing it on everyone at once. I expect/hope to move > quickly from this flag to simply making switchdev the driver default for > all DPU configs. >=20 > A generic cmdline format also gets complicated quickly: vendor-specific > flags, ordering/dependencies between flags, hotplug timing, and whether a > BDF rule should apply when a device is passed into a VM after boot. > Userspace scripts are probably better for that kind of policy because > they can carry real site specific logic. >=20 > I=E2=80=99ll drop this last patch from the series for now so the represen= tor/LAG > locking fixes can move independently and we can continue the default > switchdev discussion separately. I can always submit that as a standalone > patch later in the cycle if needed. SG