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 E6221A0613 for ; Thu, 29 Aug 2019 17:33:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 741151E53B; Thu, 29 Aug 2019 17:33:34 +0200 (CEST) Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) by dpdk.org (Postfix) with ESMTP id D0D401E53A for ; Thu, 29 Aug 2019 17:33:33 +0200 (CEST) Received: by mail-pl1-f195.google.com with SMTP id m9so1735733pls.8 for ; Thu, 29 Aug 2019 08:33:33 -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=ARJ4+yGcb7gyuzZPq8gOPkyuC0BbEf3ZFeAcT34WY2I=; b=Zpz/3NGUMqClY2Qh7qLNI+jT7qpGjhZTFQ6u6E/M6vz+f04TD1KpCR3qTkltScMO09 DFDV6sxmRJmPW8lG8IuvNqGFhUMxPKf/Kl43MLCyQAjO8G7oQy1j7W92OIbVDbV8Ei34 cuR0gdNjpnzgDQlp0E6Duo7CbL2HdDVvBuYXcxAENm0mXszjUTiqplJRo6DDZ9rei64A /ZzeW/yeh3vJ7EF5MA1SeFQzP3bJ780mbXoGhNSXJ9F/2xymgiFqXgPXyp6gR7JGw/UM UJevPXgKIjBzBXtSpz1dK+vVUY+E0gM1OsKVeElRwpNSkadYAxnNkaptCOMFIk+N1rt2 BT2A== 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=ARJ4+yGcb7gyuzZPq8gOPkyuC0BbEf3ZFeAcT34WY2I=; b=fB9GvfOofwVNZAqwai2ymMzXWy0a9fLPwkD0C8GYRkzDvzFeO5Z5+WG7MSDGOEeukv oQ0I1yBJrWWJAPu0Rxqa2O39HxGSXMox0AA9ZKWYiIcs4IwelTc5PLkpXb20bf5AfXCm 2p8nTPkH0WtIQxR7EPPwF6PArgQh65580NbfPIDD8CWyhWs+iOD3/iM9K6ILYpG+toOG 5PQ0CCoLuZGm7ztbHTfyCEky4AkfxzKE5F218JkQ4Ek4dQW73QMoY0PeRwYW+87C9EwJ ssfrpBJEZRhkTFOKkQkeo1C2YS7gAwe1G+DF8DDiWQwGNdjDuxTTGkn/mmM+rJ9Q/X9B fTNw== X-Gm-Message-State: APjAAAU+y8ySb7hkNrwDxfub1+dGH3nsTgji5tur9IqbPqDXYYapm6cZ 4X83TnVp6ZqliWcEdOtmvgK0KGQR6Mk= X-Google-Smtp-Source: APXvYqzxuUWau+dTN70v58ok9LLzxd5tVudMjGvAZdDvi5m21uOYunwdRNwHTE6qe+2v3N/mB7q2dQ== X-Received: by 2002:a17:902:fe01:: with SMTP id g1mr9612885plj.154.1567092812801; Thu, 29 Aug 2019 08:33:32 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id o129sm3878728pfg.1.2019.08.29.08.33.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2019 08:33:32 -0700 (PDT) Date: Thu, 29 Aug 2019 08:33:25 -0700 From: Stephen Hemminger To: Nitin Katiyar Cc: "dev@dpdk.org" , Venkatesan Pradeep Message-ID: <20190829083325.592a0885@hermes.lan> In-Reply-To: References: <1566934217-23824-1-git-send-email-nitin.katiyar@ericsson.com> <20190827161231.6c2313c7@xps13> 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 Thu, 29 Aug 2019 03:47:02 +0000 Nitin Katiyar wrote: > > -----Original Message----- > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Wednesday, August 28, 2019 1:43 AM > > To: Nitin Katiyar > > Cc: dev@dpdk.org; Venkatesan Pradeep > > > > Subject: Re: [dpdk-dev] [PATCH 1/2] bus/pci: Fail rte_pci_probe if probing all > > whitelisted devices fail. > > > > 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. > Hi, > Thanks for your comments. I am sorry I couldn't understand the scenario you mentioned. > > If we are not probing the device then why should we be incrementing the probed counter. If current implementation doesn't handle the scenario where all the devices in concern failed in probe (as per the whitelist) and code fails to catch that case. Application like OVS using DPDK comes up successfully although it doesn't have any physical device in usable state. > > Best regards, > Nitin > When application starts there maybe no PCI devices, but PCI devices arrive later via hotplug.