From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3C1FFA0613 for ; Tue, 27 Aug 2019 22:12:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3D2AA1C1D8; Tue, 27 Aug 2019 22:12:37 +0200 (CEST) Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by dpdk.org (Postfix) with ESMTP id B4DBA1C1D7 for ; Tue, 27 Aug 2019 22:12:35 +0200 (CEST) Received: by mail-qk1-f196.google.com with SMTP id m2so302922qki.12 for ; Tue, 27 Aug 2019 13:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Td8YmZd3Md4bbtk21MB7HHJHg/WM4tSuPzQ8uoBOW+I=; b=lIUxM8r++0sWaNTXsH4KlJ+sgnJBD84BalR/TdPzZpggCtEXdAQxBSxORRctN53MsU da/fB+e5+a/5ZFNTmbkswgbDII0sf1EZBYvVK+QtjN09CCdILViPoAgmtfI/rHjd1Z1f E5RhBTHSg94Hb1dO5UFoVMxMzhm+/pIl1ZoRdWx7GtOY8xZ0PNR6jv91ky6W3fUAx6+F dbJepefExrMy9U1/DZEVdpIOI37JTa8yPOz2ReH3Eliz2e3QUdAbu0Bxkuuh1UOOuysx OivaAKJADYsJfuJvKnC3rHYSuRsaNDl0JVgCPkAk6I5KVAHPcA2GNTHclNzCtEgltTI5 2oFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Td8YmZd3Md4bbtk21MB7HHJHg/WM4tSuPzQ8uoBOW+I=; b=sJIfPsyiODQgojloPlXqyeGP+37bKhqHlC2l6b1gDPod8a5YA+0qQ+iFTCnAOx/l4V MDG2pmZf8Ebx6cK97fy5D2BbfKINxWslTa2vlc0jXEjTMpxE5sUPW6Y+QNSp7NyEeofC LnKSCywA3ThaKOiuIV79Kwl5g4P+s/xPsuvUqNvV12qfocK44MzO/upKiBSP7JDUib1g F+3vgIAwqDMXXJPkdlUeCW4vJwK5SO6TJ4WE8WaztJ5EZFFdWaD3piY8DsP0JMPlLOuC KufvVeHajBSz57aOkS2mIOZcryjuoB+jCxD9Icit0ym80rerlbYEYbFSGyn0ZzyrreG9 8kvQ== X-Gm-Message-State: APjAAAWhxdiF5NkheVsBt5Hyv1at0bagbJivoheIkh+/cTowpA+KtBLu 6AihOpC1qX3O9BchIuhJpnIz0zbs7tA= X-Google-Smtp-Source: APXvYqx+26xoZSpNg41qGvv+OYX7DDO4IOxQrOjs9WzaxmpEy5VuNDJfhFU+ajbAqX5QSVTOwTGnCg== X-Received: by 2002:a05:620a:1103:: with SMTP id o3mr392398qkk.28.1566936754921; Tue, 27 Aug 2019 13:12:34 -0700 (PDT) Received: from xps13 (pool-96-233-168-28.spfdma.east.verizon.net. [96.233.168.28]) by smtp.gmail.com with ESMTPSA id v26sm230624qkj.96.2019.08.27.13.12.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 27 Aug 2019 13:12:34 -0700 (PDT) Date: Tue, 27 Aug 2019 16:12:31 -0400 From: Stephen Hemminger To: Nitin Katiyar Cc: , Venkatesan Pradeep Message-ID: <20190827161231.6c2313c7@xps13> In-Reply-To: <1566934217-23824-1-git-send-email-nitin.katiyar@ericsson.com> References: <1566934217-23824-1-git-send-email-nitin.katiyar@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/2] bus/pci: Fail rte_pci_probe if probing all whitelisted devices fail. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, 28 Aug 2019 01:00:16 +0530 Nitin Katiyar wrote: > Even if whitelist of devices is provided, rte_pci_probe() increments > the probed counter for all the devices present in the system. If probe > fails for all the whitelisted devices it still return success because > failed and probed counts don't match. > > This patch increments probed count only when devices are actually > probed. > > Signed-off-by: Nitin Katiyar > Signed-off-by: Venkatesan Pradeep There are two differing interpretations of this. The simple case which is what your patch fixes is where user gives bad arguments and no devices are present. But the more complex case is where the devices show up later via hotplug or other discovery mechanism. For example, on Hyper-V/Azure SRIOV PCI devices can show up after application is started. Your patch might break the use case of where an application is started before the VF is available. More detailed example: 1. VM is started. 2. VF is take offline for maintenance or migration. 3. DPDK application is started with whitelist option (no usable PCI found). 4. VF becomes available after maintenance. Yes, this a somewhat made up order which is unlikely to happen in real life. But there is nothing stopping it from happening. I often recommend to customers using whitelist because the typical appliance scenario has a management interface, and you don't want the DPDK interacting with the VF of the management interface. Therefore, from my point of view, this patch is a NO.