From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 40A8D30E84E for ; Sat, 9 May 2026 07:01:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778310094; cv=none; b=A/d2X4Z1xSA9inPtGNH68UzhYYbaLDXqBbQ3izM7xsZs/SwZSjimt/j3VR4PlFmSvLUol6RESABJtHTGsB980vQQLEBWQaivJ0Dl8xcyHVqi3zahyRKljlrMYr6PqJwa2BMDa95do/KoGhQwDWYGIqcy8beu0LUjKliKNMOdVz8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778310094; c=relaxed/simple; bh=Fdkwzh7nzXXsRdR+lBF6ucGH+k2FBnutbxMgBG+r9aA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=i33gnNWsLcHbWvWNYa1xV+MAjizMRPSF5eCF7rTjHPOrvV62jcX/ezvcmYnoi+Kmg7i12E1u8z7F7GdTJYXEXeNfUnZqJl1skPZlXDatYsV1gvdJIQkHvZuq0/NJEU+j56UDbb9ZeT2MjE9vZLfkawUwspejfS4mgLzn9pUCA1c= 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=O39COjSE; arc=none smtp.client-ip=209.85.128.50 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="O39COjSE" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-488a9033b2cso25256285e9.2 for ; Sat, 09 May 2026 00:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20251104.gappssmtp.com; s=20251104; t=1778310089; x=1778914889; 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=aBUb6rJkP5kcBQ6tIPVqou1ctCmL/sfkRVBGBAME9Sk=; b=O39COjSETDTYb+Z7bD43p8tNEei8T9vTYSZjBbW2KOQQ9QIz9zAumYPYsJloJwh1l6 jz03kvFvqJ+3KyBKHCZwGes4EIylOUT9BoJs4/ym5MiBQZktSg0e+kis+Fz9Fyi3Gj3Y 17tENhANixFbAV0jyQQF9djR7/H3TwQC3wieMsl7J1yX6sZubNfzbq1Xya5SipjTiPs0 9MCEFwL70k9omeeYtgOQT18u5a6G9KY9qr3vE1h8gZo4Kdk1IULGpFZyRbJFkTR+rQDw idAyG+3CTW4j5mFLUFbyGQgfx15FbUb1g9HNpa+pxDz2hFrEJknLRSEzcwGT7MC6atuD LTcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778310089; x=1778914889; 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=aBUb6rJkP5kcBQ6tIPVqou1ctCmL/sfkRVBGBAME9Sk=; b=AUsbN2wnQhD8Ry8rWDTTiGIqpZKPpL3ADtwWIA7nsUnV9SdpcFyWQYbrO8KUu/gGPJ 5cLZeYtCLJRV/1ujzkzwmFAcss3wdcDsZZtV5KfM6L0NYMZCspNCwelBzHgyiM7N75tq DgJYKfzCsZiZWj6OuvA7v2Mm+6p2rFzyBKpsR3e7lztoLVxgstOUYrInI594xT9+fhTD m8KNvqNwzQ9Q+JaPkdZfiOZA126bIgUm4rat6zlQQ/J9yzmmpAq8UNMiwjJWwHM97yo7 xRC8Gt2eYXGxV7ox1ixEPNc2gcdxdFX8t6Ts3thWlbrtnp9s2Zep59OJ55OShO6pBhlx B72g== X-Forwarded-Encrypted: i=1; AFNElJ+5fNEzxu10IFdcMRU/wyftaP2rs4/Erllw8cFzxwFyvK95g9QO/I5bOD9NhUfqhjJ8i/7UbqI0U+dxSKs=@vger.kernel.org X-Gm-Message-State: AOJu0Yy07OmEFZdA26XlbxAoMJYvXng9sBOreTTOZYFbsMViNAv9iE9D GaWFXsCXlEHPqCoVFlbU5OGOpBGJwPDB25ya9Uk3zPNfsR1NUNHe0fhMFGk+FiwfSlQ= X-Gm-Gg: AeBDievwXOnibOjQ8C3vnIQuoGOmeJux5Y7OGrhfNo3URfiAxw8MEbv0mT90T/zZVWH OUFsPEdF+a0rKK+Uyj1FNEuk35qiZxNXR5s8mskkHKetvS/cxVTRtT7WMgugaR+A9fl1K3z+PdU uw989D8016qnqQgD7nPn/j855vG7pWwsIR2xWOFTdgNEAxm2At4M2wGf36PxdRBG05yJP8xSeoX s19K31dBTIg+tvSxVXiXrWgb63iWtsfKRHRPwTrtanFq/MLc+pF6PjMmey1YBxKzEdVEp531yJk 3g3PhxmGtiWaTTfrnIoJFg+dBlvl13KDxSOBtubp/KnuYhcbVZ8ShhRNOhxq+ckPIBmygwpkX+w xIpjIYJ9RHL4fDEgJCVyWBQgUoZQfxDQd5PAjc0reO+bcowuV48Xv0LBy+DYKDQSWjSTGR7i6d4 /AWEwF4SYKHmP8OMFsEHQDA1xaFqdlayJwzI0= X-Received: by 2002:a05:600c:4e15:b0:489:1f04:96c3 with SMTP id 5b1f17b1804b1-48e70687e22mr20671555e9.2.1778310088900; Sat, 09 May 2026 00:01:28 -0700 (PDT) Received: from FV6GYCPJ69 ([140.209.217.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e7040a8ffsm49536725e9.10.2026.05.09.00.01.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 May 2026 00:01:27 -0700 (PDT) Date: Sat, 9 May 2026 09:01:23 +0200 From: Jiri Pirko To: Jakub Kicinski Cc: Mark Bloch , 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 , Li RongQing , "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: <20260506123739.1959770-1-mbloch@nvidia.com> <3f9215c4-7c84-46d9-ba74-30dabe24db09@nvidia.com> <20260508175213.1952097f@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-Disposition: inline In-Reply-To: <20260508175213.1952097f@kernel.org> Sat, May 09, 2026 at 02:52:13AM +0200, kuba@kernel.org wrote: >On Fri, 8 May 2026 20:07:44 +0200 Jiri Pirko wrote: >> >I don't think switchdev by default should mean CX4+ in general. If we get >> >there, I would expect it to be limited to the DPU/BlueField/ECPF case, where >> >the host PF probe path can depend on the ECPF reaching switchdev. Changing the >> >default for regular host NIC deployments feels like a much larger compatibility >> >change. >> >> We can't travel throught time, but if from CX5 onwards the default would >> be switchdev, nobody would feel broken in terms of compatibility. That >> is my point. Having "legacy" as default is simply wrong for never NIC >> generations. That is why it is called "legacy" and it should have been >> rotten through and out since CX4 times. > >legacy vs switchdev only describes the eswitch configuration. >As a non-SR-IOV user I really don't want to see the extra representors >hanging around my systems, confusing all daemons. IIRC mlx5 had some >limitations around the uplink representor. Maybe that's the disconnect. >But for a real, fully featured switchdev eswitches having the >PHY and PF representors on boot, always, will not make sense. As "a non-SR-IOV user", what extra representors you talk about? When you have pfs only, you don't have anything extra. Just 1 netdev per-pf, one devlink port per-pf. What's extra about it? When you don't have VFs/SFs. Everyhing is the same: c-220-136-220-218:~$ sudo devlink dev eswitch show pci/0000:08:00.0 pci/0000:08:00.0: mode switchdev inline-mode none encap-mode basic c-220-136-220-218:~$ sudo devlink dev eswitch show pci/0000:08:00.1 pci/0000:08:00.1: mode legacy inline-mode none encap-mode basic c-220-136-220-218:~$ devlink dev pci/0000:08:00.0: index 0 nested_devlink: auxiliary/mlx5_core.eth.0 devlink_index/1: index 1 nested_devlink: pci/0000:08:00.0 pci/0000:08:00.1 auxiliary/mlx5_core.eth.0: index 2 pci/0000:08:00.1: index 3 nested_devlink: auxiliary/mlx5_core.eth.1 auxiliary/mlx5_core.eth.1: index 4 c-220-136-220-218:~$ devlink port auxiliary/mlx5_core.eth.0/65535: type eth netdev eth2 flavour physical port 0 splittable false auxiliary/mlx5_core.eth.1/131071: type eth netdev eth3 flavour physical port 1 splittable false c-220-136-220-218:~$ ip link ... 4: eth2: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether b8:e9:24:f2:b7:6c brd ff:ff:ff:ff:ff:ff altname enp8s0f0np0 5: eth3: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether b8:e9:24:f2:b7:6d brd ff:ff:ff:ff:ff:ff altname enp8s0f1np1 > >IOW it's not a question of the generation of the card but of >the deployment type / use case. I don't think so, not in the case of mlx5. The difference is only when you work with sr-iov, you either use legacy way (ip vf) or the new one. Same usecase. > >> >For the ASIC/NV bit: maybe technically possible, but it feels like the wrong >> >layer. This is boot/deployment policy, not a persistent hardware property, and >> >storing it in NV memory would make the state persist across kernels/hosts in a >> >surprising way. >> >> Well, as any other nv config, it persists across kernels/hosts. Think >> about it as "unbreak-my-not-legacy-device" bit. > >For most devices the switchdev mode does not change anything >substantial about the device. It's purely a kernel / driver config. >It changes what objects and default rules kernel / driver installs. >So I don't get why it would make sense to flash into the device >nvmem a Linux SW stack specific config. 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? [...]