From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 5A3A23FAE11 for ; Wed, 13 May 2026 11:11:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778670703; cv=none; b=U2ybTd4DL0V4XiaB8Sx6t2kYA/oUN6r/8WGA6oxtj6oHamhfQPTUahM4x57dUQmiaGZqSuGvR+ywdxSKV07giEirT2V+ZD2LUDziSkJwqHgaFzza/hNIAfNCCNRNAVnMBkoHGZortHp68yV3BW3d6+MJpmmHHBnoGuDqGB7bH+4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778670703; c=relaxed/simple; bh=ZXwAclxswpH9W2j+/oYb3qv3cmJKlKRNjuaVJ2ukMfU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ROIHfLcsoJGqLZtvesQzDcLsx8KGqYmNL87J8i7jAb1ISBGxFE11tz4oxOgDbAEE64+1Wg/GiDPflE188a2N/ADiDY7jH4Et65dHLyp2xyTOqjDgF0OF0iYAdg0xTcD5PFlYkwxDwz+gMvnuWqj0DF5AGLfiP0kAPfX6Mw8uz+Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=resnulli.us; spf=none smtp.mailfrom=resnulli.us; dkim=pass (2048-bit key) header.d=resnulli-us.20251104.gappssmtp.com header.i=@resnulli-us.20251104.gappssmtp.com header.b=JE77P9uY; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=resnulli.us Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=resnulli.us Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=resnulli-us.20251104.gappssmtp.com header.i=@resnulli-us.20251104.gappssmtp.com header.b="JE77P9uY" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-48d146705b4so80146135e9.3 for ; Wed, 13 May 2026 04:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20251104.gappssmtp.com; s=20251104; t=1778670699; x=1779275499; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8yDTQJL+RHs/YBzKpujLCRoZVSafUqZXfMLZzEz8A6w=; b=JE77P9uYkoqDBF9sOHO24gEkrwieIf/eMyVZr2mmVjIES2j7yKsKwgGftwBiAywZd6 Kik08oN23TrTMT2FCSCBSvpySsis9P7BUP7jHNcWQcNadU1pmEgSofLnCFp0EUv9A2i8 tNcDg9EgJwyvueTOn/QFpnR/DjgmjvObZiGSeg5D0VLJFEY2liLmHtI+u5vl5IWDJdke pqiIFNl5yW4rDK1crx6kWLD5QkJgMwsTUDVWbAe3aUnzVZrEdWcGOF/a5tUEJ58OfI8s bR2l27MqSMnXyUU8x6ykto74E/Qy7nBObTlRNN0LdPfZ784B1fCF4VTuvLER7Zulnf4X nP/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778670699; x=1779275499; h=in-reply-to:content-disposition: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; bh=8yDTQJL+RHs/YBzKpujLCRoZVSafUqZXfMLZzEz8A6w=; b=ADZOIyyP41MBhBRp08viSMMBrOTf4RWJTBQEnn56UHGha8V0sWKkGQ6aw7aHFXaPGu OWegnGmarJcoldCN9VuXFMA9niS5AJumhlN1Fk1jHNy4/LCD5cgf8iPQqkABe3ECXRLU HSVsvOV9HWOn9pG0zj47ylA8z+fqktgDsESk10pe6RfoAQoAHFSMZhPB/ZkHINF47644 gcOHf51A7tCxXbL0JSv1dGK27xsVyeDdHFu+Q0AluW1xTWta2hDOD6Ps1rIPO7NvnaSn q9tgfj4eS35Wuul35efR+/c26d0PlWdWQU2aW+kPAAa9G5AYpTJYywHYshTIwq6bXXC2 bfWQ== X-Forwarded-Encrypted: i=1; AFNElJ9HnXFWz+zP/1TyumibNqxMJ3FX1UiSMVM4pt43qvwV6kSofBgj1PRtvbQGFF4rywNwQwMalv3h+kCOzeY=@vger.kernel.org X-Gm-Message-State: AOJu0YwTxFXva4Sbr5rDqtbWHsTThqrk9MBZGHkHbLbzjlPBOOUrKaMX 68Kjdj2RlvVmzq8n+hJSAZVnLSrQOvvkU1WWpJY3B/QbZA6Zkgjgfa1XoprUP8/TOmQ= X-Gm-Gg: Acq92OGX14VQZLdK81erqQrCeblWXk6erQaYHBC4+I2N1fl2zIAgJCdJVcZSzHHQZvU iQMZifkmZJI456fxicf4s+8rFRBT4UX31L+jb0JDpBiiuRj0Ed0numDb30+TgSNjOVV9GkF4Dok xq6k+1uPxu7ASIE887Frnh2E829Tzqc+QDQ5NTvcegmWAy1GMzTbeIN03yQjsqW2KyYN0A8PPho 8RD09DX0ftvD2s96McVUdqr5l13WGkgLgH8c+eg3HDKjPU8Oz9c+zmGVmKCk2jAMGwHTa/NmZZ1 8X8Q3VLiry3LBQoB0M4MLL64vO6YfpgOpTSARFm4weTekSPsc7jShyPHKCrnt5ZFECSZMC8VlVR ebyETDLwIe6CPGOimdtWqGS5MKsdFLuIp77wJc3RG3SoAhzjpI9u3GtOk4v6jZtwVjEHJ4mlagI 56L9Mwh4ubuB12UJL9cISbkKmHwojLZdtD01SaO7q5Zc+J/w== X-Received: by 2002:a05:600c:4494:b0:48f:d410:6065 with SMTP id 5b1f17b1804b1-48fd410610dmr4475165e9.29.1778670698381; Wed, 13 May 2026 04:11:38 -0700 (PDT) Received: from FV6GYCPJ69 ([140.209.217.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fc8d624fbsm153171235e9.10.2026.05.13.04.11.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 04:11:37 -0700 (PDT) Date: Wed, 13 May 2026 13:11:28 +0200 From: Jiri Pirko To: Mark Bloch Cc: Parav Pandit , Jakub Kicinski , Eric Dumazet , Paolo Abeni , Andrew Lunn , "David S. Miller" , Jonathan Corbet , Shuah Khan , Simon Horman , Saeed Mahameed , Leon Romanovsky , Tariq Toukan , Andrew Morton , "Borislav Petkov (AMD)" , Randy Dunlap , Dave Hansen , Christian Brauner , Petr Mladek , "Peter Zijlstra (Intel)" , Thomas Gleixner , Pawan Gupta , Dapeng Mi , Kees Cook , Marco Elver , Eric Biggers , "NBU-Contact-Li Rongqing (EXTERNAL)" , "Paul E. McKenney" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-rdma@vger.kernel.org" Subject: Re: [RFC net-next 0/4] devlink: Add boot-time defaults Message-ID: References: <20260508175213.1952097f@kernel.org> <580a774b-ba9e-4523-b43a-476f75dd5b12@nvidia.com> <29868c1b-5751-421a-9f2b-2ac0f3324904@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: <29868c1b-5751-421a-9f2b-2ac0f3324904@nvidia.com> Wed, May 13, 2026 at 07:53:05AM CEST, mbloch@nvidia.com wrote: > > >On 12/05/2026 21:35, Jiri Pirko wrote: >> Tue, May 12, 2026 at 05:25:21PM CEST, parav@nvidia.com wrote: >>> >>> >>>> From: Jiri Pirko >>>> Sent: 12 May 2026 07:37 PM >>>> >>>> Tue, May 12, 2026 at 03:48:32PM CEST, parav@nvidia.com wrote: >>>>> >>>>>> From: Jiri Pirko >>>>>> Sent: 12 May 2026 02:16 PM >>>>>> >>>>>> Mon, May 11, 2026 at 08:21:37PM +0200, parav@nvidia.com wrote: >>>>>>> >>>>>>>> From: Mark Bloch >>>>>>>> Sent: 10 May 2026 06:02 PM >>>>>>>> >>>>>>> >>>>>>> [..] >>>>>>> >>>>>>>>> I look at it from the perspective that from some CX generation, >>>>>>>>> switchdev mode should be default. So that is a device-based decision. >>>>>>>>> I believe as such it can optionally be permanenty configured (nv config) >>>>>>>>> on older device. Why not? >>>>>>>> >>>>>>> Because sometimes switchdev_inactive is needed and sometimes not. >>>>>>> Such knob is not device decision. >>>>>> >>>>>> That is what I would call corner case. In that, user can use userspace >>>>>> configuration to change the mode in runtime. >>>>>> >>>>> Corner vs common depends on users one talks to. :) >>>>> If fw has switchdev(active) as default, and then >>>>> And user needs to run switchdev_inactive, it will actually break their switching applications. >>>> >>>> Can you describe the actutal breakage please? >>>> >>> Driver default was switchdev so all the traffic is forwarded to the switch, >>> and user didn't have chance to setup the fdb rules. >>> So packets are dropped but user didn't expect the traffic to be forwarded. >> >> User may switch mode to switchdev_inactive early on, before any of the >> representors are created. What's the issue then? > >That is the ordering problem I am trying to solve. > >On a DPU, the host PF cannot finish loading until the ECPF moves the eswitch to >switchdev/switchdev_inactive. So we need to do that transition during ECPF >driver init, as early as possible. Waiting for userspace means the host PF stays >blocked until userspace is up and has the right logic. > >That is not always true in practice, the driver may be built in, loaded from an >initramfs, or the initramfs may simply not contain the devlink policy we need. > >Also, after talking with Parav, my understanding is that we need to support both >switchdev and switchdev_inactive, since different customers want different boot >behavior. Once we do the transition, the host PF can load and may start sending >packets. At that point the initial mode already matters: in switchdev_inactive >packets are dropped until userspace programs the pipeline; in switchdev they may >reach the FDB before the pipeline is ready. > >So I do not think an early userspace transition is equivalent here. The initial >mode needs to be known by the kernel before userspace runs, which is why I am >proposing the devlink= command line default. Okay fair enough. Could you please at least make sure this is mode only config and noone would ever think about abusing this for any other configuration? Perhaps call it "devlink_eswitch_mode=" to remove the "devlink=" namespace flexibility?