From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A664E45BC0; Tue, 29 Oct 2024 17:07:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 495B042E48; Tue, 29 Oct 2024 17:07:16 +0100 (CET) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by mails.dpdk.org (Postfix) with ESMTP id 1B74E40261 for ; Tue, 29 Oct 2024 17:07:15 +0100 (CET) Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-20b5affde14so41236575ad.3 for ; Tue, 29 Oct 2024 09:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1730218034; x=1730822834; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=rytp4O8UIrvVroYeZoBk4oM0jZSCnv0oz5pwLZE9DOk=; b=pv+0BfD/UhKcR5pxG5Lj8W1O2eA76e5kEZqOUNKkzAYJDxHkfmzkyJJiA89q9Cx26l LVAbKydGXqaLRqQbsik4orBIXMEFmAsWU5y8ZuNKRU4KjEYj83zc5UV4f6lHariQXZdn Us3G54ZaQ11hRDvnoitWso1IRqmhp7JEaROyxwXkkbAAkWL8c5azIsfRp2EdrqWaDMAq AtMZBnKMs7bkQg02pdcLOezlRxqEnd6JfV8kWJ/kGsheOgiuCit9kdWTz49K5LuoOD49 xkOmDRmC2MNaxjVOOwjidCV1QTkMtbY46lgIYZsZyAFTN4eD4rFvRHNunCEizsbm5aXn LKSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730218034; x=1730822834; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rytp4O8UIrvVroYeZoBk4oM0jZSCnv0oz5pwLZE9DOk=; b=tLsiJCb6mSaXNVabfHhpr17jHTK9zJflfKyBdbfUgM9CwuPH7GbztRRhjqP82zKV/q V581DW9qiF0bnwYqycnZr3+CeHrb+yNvXwJri55y6REnaoA86eEAOO1K8KntMNB29eaC KXH5NlMlWbk3l9xz4VrXGaWtx+oQJnMsV8PJRwgLd+9Tap/W8hKMhBzbZBLLrGTsbj5h ZlITFqV1heF/VCgiICHNZ7x5wWNx7QA/YzYxxoPyyBFM1zrvkeAKk9HPpwF2HC7aUxGt 6t4sQTVSl4QQTPKGasa2GW27WZogbvvZsmO3xc9SOwjknsdR7C2qm4dN+/1E4jCHfqmi 2BpA== X-Forwarded-Encrypted: i=1; AJvYcCX6lDrHQqkXopPHU96XWZQ/lb8sFCX5Q9mPeMZSXZCxS47HkgNOV4AgqCaz/lmpYl+7/s4=@dpdk.org X-Gm-Message-State: AOJu0YwrnxKJlS8jq7dn+AqF4DruDxzT6zthKdd2xWeha4j3v6pwRCF+ jP9Lms/vTCBuBHkBBkKDqVsR8Zv/CJ2ffFFIVtMoI1xr39uyKHetxRK0oxKuTTA= X-Google-Smtp-Source: AGHT+IE6Acn4lu4iv3cZiOdfukGZFeCrcoP1Ol7biRsXn2jftjpCggUxtuDVxjRov8gc/E0Bu5YIxA== X-Received: by 2002:a17:902:cec3:b0:20e:57c8:6ab3 with SMTP id d9443c01a7336-210c68739b0mr197673785ad.4.1730218034178; Tue, 29 Oct 2024 09:07:14 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-210bbf88490sm67820735ad.114.2024.10.29.09.07.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Oct 2024 09:07:13 -0700 (PDT) Date: Tue, 29 Oct 2024 09:07:12 -0700 From: Stephen Hemminger To: "Minggang(Gavin) Li" Cc: viacheslavo@nvidia.com, matan@nvidia.com, orika@nvidia.com, thomas@monjalon.net, Dariusz Sosnowski , Bing Zhao , Suanming Mou , dev@dpdk.org, rasland@nvidia.com, Rongwei Liu Subject: Re: [PATCH V2 3/7] net/mlx5: add new devargs to control probe optimization Message-ID: <20241029090712.35ade0c0@hermes.local> In-Reply-To: References: <20241016083818.662020-8-gavinl@nvidia.com> <20241028091822.860660-1-gavinl@nvidia.com> <20241028091822.860660-4-gavinl@nvidia.com> <20241028084732.10774614@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 29 Oct 2024 16:27:25 +0800 "Minggang(Gavin) Li" wrote: > On 10/28/2024 11:47 PM, Stephen Hemminger wrote: > > On Mon, 28 Oct 2024 11:18:18 +0200 > > "Minggang Li(Gavin)" wrote: > > > >> +- ``probe_opt_en`` parameter [int] > >> + > >> + A non-zero value optimizes the probe process, especially for large scale. > >> + PMD will hold the IB device information internally and reuse it. > >> + > >> + By default, the PMD will set this value to 0. > >> + > > Is there ever a case where this should not be used? > > > > It would be better to just detect and use it if available. > > This driver does not need more options... > The new mechanism, which is required by few users, so we would not break > production and with the option we encourage to use new way only those > who actually needs. Once we see the new way is reliable - we will change > the default value. I understand that philosophy but it leads to a maze of technical debt. Has a full suite of tests been done with both settings of the option? Has both values been tested on all combinations of platforms and OS releases? My point is every option adds to the necessary test matrix geometrically!