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 721C045C18; Wed, 30 Oct 2024 20:05:23 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4FFFD42F31; Wed, 30 Oct 2024 20:05:23 +0100 (CET) Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by mails.dpdk.org (Postfix) with ESMTP id A9CA342F2B for ; Wed, 30 Oct 2024 20:05:21 +0100 (CET) Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-2e2dc61bc41so115318a91.1 for ; Wed, 30 Oct 2024 12:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1730315121; x=1730919921; 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=f3vdLoe4TMlS0a8AgFL4aZ/GSs0QolbSK8gf7zB/2l4=; b=jVmw56lOFpI/8zYJNOuluGWlg3fqDN5T/yUVZoFvVqeiC2BBZ92ebvi+9HimGyIPP2 BG/4G9hq3W5jmgsALCDJ2Stez9BFVCbl4ZLYfTWbklTRXelKyg1zZqUFvtaMQ4D4/0XO jb1KVr8QIt8qPmXDldZLLj0bQpTpjpKaMULuV1eo5+JaXYLVtrpizze22QYKMuvP1Yzv bmTrIGQfBhpD18onL1/TgIP4LUjIXY6AtPR8uJLmLOiJrkje2E9eXGaLSr4ZqOtPVeIF T/8HQk69PWW0Fpp3VYhscJ2sWyRUMx8+QFNOy4sqeJ+mBME51YaFSJ6mge8835pFXD9u jXzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730315121; x=1730919921; 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=f3vdLoe4TMlS0a8AgFL4aZ/GSs0QolbSK8gf7zB/2l4=; b=iLQuNeKnU0JBgYGV2J4KhFu9rJGfbh1uzbif1hfrmQjjoxoW5El25T6Q/8y23kHQVt SJLSe9/eYaYL/Oc6F7b0dauJHTV5p4eDPkF4otAEKbyVUkQ8/Ah0TneKM18e59xf95JU AicjJV8/VqFabrRET0JJu+QfZuuieppUVFZIEm/mZGFoFXAmY5EpRFF0msmv+aazxkrI rEzvhMRre1m3Azn5wdHwvdH5q9cu6sVYhx0vtyYTBjBGahPR67lfZcLbm1jx2YjxYKcS VWzO7FrUyP8oE/psbNRilUUS4lp37uHapGml5aICNbMBcex0BtK/2qDb0B0yZFBbvH8d xF6w== X-Forwarded-Encrypted: i=1; AJvYcCUO7HQMv1cSPGftUV9uyt1xHuqCLwWafRYFZurTfecKs5hohleCENJDuiUm8zeGlhFDnjA=@dpdk.org X-Gm-Message-State: AOJu0YyF3hMN/oa95I61/49dDpiPTpkFzIAS8fk3G+nuzbfswYUqUnTw XU9a9kLZD7AJqDoGTYAt7Tr0g4a6xHc3L4XfVd11YmvX46YcrDlQhPQbnMpiNeI= X-Google-Smtp-Source: AGHT+IF+4MMS8RoEA4SLAkEIXdchpMk+l/ckgWzp2Ai6XkgGMDmUfiL1e02NPLQ9OgPYFhH8DBsUGg== X-Received: by 2002:a17:90b:3505:b0:2e0:8e36:132 with SMTP id 98e67ed59e1d1-2e8f0f53e60mr18488647a91.3.1730315119190; Wed, 30 Oct 2024 12:05:19 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e92fa262fasm2232144a91.21.2024.10.30.12.05.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Oct 2024 12:05:18 -0700 (PDT) Date: Wed, 30 Oct 2024 12:05:17 -0700 From: Stephen Hemminger To: Slava Ovsiienko Cc: "Minggang(Gavin) Li" , Matan Azrad , Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Dariusz Sosnowski , Bing Zhao , Suanming Mou , "dev@dpdk.org" , Raslan Darawsheh , rongwei liu Subject: Re: [PATCH V2 3/7] net/mlx5: add new devargs to control probe optimization Message-ID: <20241030120517.0dfcbf01@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> <20241029090712.35ade0c0@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 Wed, 30 Oct 2024 08:16:58 +0000 Slava Ovsiienko wrote: > Hi, > > > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Tuesday, October 29, 2024 6:07 PM > > To: Minggang(Gavin) Li > > Cc: Slava Ovsiienko ; Matan Azrad > > ; Ori Kam ; NBU-Contact-Thomas > > Monjalon (EXTERNAL) ; Dariusz Sosnowski > > ; Bing Zhao ; Suanming Mou > > ; dev@dpdk.org; Raslan Darawsheh > > ; rongwei liu > > Subject: Re: [PATCH V2 3/7] net/mlx5: add new devargs to control probe > > optimization > > > > 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. > > This specific case is not about philosophy in general. > > We have users with huge number of SFs/VFs configured and experiencing the issues > with gigantic probing timings (literally - tens of minutes). This story was lasting > long time, we were trying different approaches, then admitted we had to update kernel, > etc., and eventually we had things done and it resulted in this series. > > The new approach is event driven and based on the handling the new kernel-generated events. > So, it relies on system-wide environment and might be problematic on some hosts (we do not > expect too much though). > > At the same time, the existing probe approach provides acceptable performance and > satisfies the vast majority of the users. So, our main objective is not to break anything > in production (most users), the second objective - to resolve issues of some users with > configuration specifics (few users). That's why we would prefer to have the devarg > (with all its cons and pros) and set the devarg default value to false. Later, once the new kernel > API spreads and we have good production statistics we can consider altering the default > value to true or obsolete the devarg at all. Does this approach look reasonable? Ok, was just hoping that all this could be transparent to the users. Ideally, the driver could detect if the right version of components (rdma, kernel) were available at run time and just do the fast thing.