From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 6AA292BF4 for ; Wed, 9 Mar 2016 00:03:41 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id p65so169736317wmp.1 for ; Tue, 08 Mar 2016 15:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=7mc+LQmrNnhQG4JpXNQQwd8JRh7UN3bJkYTBik0xD5I=; b=Fvwhq+VP7ppoJzhE1Wop0k09EnpECwMpxOB6FMzQ5M6YhCMI/rqQw6OAN+SRU9sUjb 9b5KRQJT14noiEMOgnRUJgaOJ+UF8YqNBVqn0Z/t+7rixfJL5CDp+mnqrMX8bfQLGcpz E7NwQGKZfUZsq01sj5QJemrFvaBit7xunUQnWRjPeSOJ0V9qQFrsHKKbACIVXraOCd4t Lm2VK3ZRQK41nzpZDb/JY27g614/jIDjej6dTDHasS40geecqG0eV21fit/NrETksTUM QRDhj1EIOx/pr2gVDtdLCsarVu8XUsKRydy731Ur8cc/0Xe4jS/oPCmo8DhX507kHn2P oq7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=7mc+LQmrNnhQG4JpXNQQwd8JRh7UN3bJkYTBik0xD5I=; b=IczL2jrM3LCAnl8pYELDFNzMgcYhW0eeq4BkC9YCAXe07ygt9a+DVal44Cp814XN6m gz4fAftsw0KAcPUYDL3jZTkBjj2lxDwHZd153fKC6HArcjOB+X7xf6hQCVhvsZr5Lqn2 sHRJfgUItzyIQ5vSwcyKqSxSI0fqMwNOsRs9qhIDpEA67SD5+7vGNtzFsXLlsNGYz2UT T7EA3GyYbv+2eZfegqIAvjiaVW5VT3QGCMORDliVsTMdG1XD56oMp+O5QdybvJP+yUcF /pNr9ZKFFqTWvgcthAa3fQN3OXBtJ2Y7odqksRUPy50wfXff5PDBzmIS8B/Bp2S/zvQZ EK/g== X-Gm-Message-State: AD7BkJJgHX1Jx21zIz6xXapwVs6S4TznJ2jUOh2ZiLVx2scFvhp55H/6SZ4v4qrnM8QpLfO3 X-Received: by 10.28.93.79 with SMTP id r76mr22886929wmb.32.1457478221276; Tue, 08 Mar 2016 15:03:41 -0800 (PST) Received: from xps13.localnet (171.36.101.84.rev.sfr.net. [84.101.36.171]) by smtp.gmail.com with ESMTPSA id i1sm5011587wjs.45.2016.03.08.15.03.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2016 15:03:40 -0800 (PST) From: Thomas Monjalon To: "Xie, Huawei" Date: Wed, 09 Mar 2016 00:01:52 +0100 Message-ID: <2051698.bGFa2huFVf@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <20151222035041.GA7532@pxdev.xzpeter.org> <1581750.D14419ZT36@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org, "Troitsky, Nikita" Subject: Re: [dpdk-dev] [PATCH v4 4/4] virtio: return 1 to tell the upper layer we don't take over this device X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 23:03:41 -0000 2016-03-01 10:08, Xie, Huawei: > On 3/1/2016 5:57 PM, Thomas Monjalon wrote: > > 2016-03-01 08:39, Xie, Huawei: > >> On 3/1/2016 4:24 PM, Thomas Monjalon wrote: > >>> 2016-03-01 07:53, Xie, Huawei: > >>>> On 3/1/2016 3:18 PM, Thomas Monjalon wrote: > >>>>> 2016-02-26 09:53, Huawei Xie: > >>>>>> @@ -1037,8 +1039,11 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev) > >>>>>> > >>>>>> pci_dev = eth_dev->pci_dev; > >>>>>> > >>>>>> - if (vtpci_init(pci_dev, hw) < 0) > >>>>>> - return -1; > >>>>>> + ret = vtpci_init(pci_dev, hw); > >>>>>> + if (ret) { > >>>>>> + rte_free(eth_dev->data->mac_addrs); > >>>>> The freeing seems not related to this patch. > >>>> I can send a separate patch, ok within this patchset? > >>> Yes > >>> > >>>>> [...] > >>>>>> PMD_INIT_LOG(INFO, "trying with legacy virtio pci."); > >>>>>> - if (legacy_virtio_resource_init(dev, hw) < 0) > >>>>>> + if (legacy_virtio_resource_init(dev, hw) < 0) { > >>>>>> + if (dev->kdrv == RTE_KDRV_UNKNOWN) { > >>>>>> + PMD_INIT_LOG(INFO, > >>>>>> + "skip kernel managed virtio device."); > >>>>>> + return 1; > >>>>>> + } > >>>>>> return -1; > >>>>>> + } > >>>>> You cannot skip a device if it was whitelisted. > >>>>> I think you should check RTE_DEVTYPE_WHITELISTED_PCI and throw an error > >>>>> in this case. > >>>> I feel there is a subtle difference on the understanding of -w args. To > >>>> me, without it, probe all devices; with it, only probe whiltelisted API. > >>>> That is all. > >>> I don't know if it is clearly documented indeed. > >>> > >>>> Do you mean that -w implies that devices whitelisted must be probed > >>>> successfully otherwise we throw an error? If i get it right, then what > >>>> about the devices whitelisted but without PMD driver? > >>> Yes we should probably consider the whitelist as a "forced" init. > >>> Later, we could introduce some device flags for probing/discovery: > >>> PROBE_AUTO, PROBE_FORCE, PROBE_IGNORE. It would make white/black list > >>> more precise. > >>> > >>>> I will fix, :). > >>>> if (dev->kdrv == RTE_KDRV_UNKNOWN && dev->devargs->type != > >>>> RTE_DEVTYPE_WHITELISTED_PCI) { > >>>> .... > >>>> return 1; > >>>> } > >>> You should also consider the blacklist case: if there is a blacklist, > >>> the not blacklisted devices must be initialised or throw an error. > >>> > >> Don't we already skip probing the blacklisted device in > >> rte_eal_pci_probe_one_driver? > > Yes, I'm talking about the devices which are not blacklisted. > > Having some blacklisted devices imply that others are implicitly whitelisted. > > For blacklist, it only means the blacklisted device should be excluded > from being probed. It doesn't mean all other devices should be probed > either successfully or otherwise throw an error which cause DPDK exit. Yes it is. Currently we have 3 cases: - probe auto (best effort) - whitelist (implicitly blacklist other devices) - blacklist (implicitly whitelist other devices) If you want to mix blacklist and best effort (auto probing), we must set these requirements as per device flags instead of the current lists. > Even that, the upper layer should explicitly put the non-blacklisted > device into whitelist, i mean here we should only deal with whitelist. It is not the way it is done currently. But some per-device flags could be introduced later to make it explicit and deal only with the whitelist flag (let's call it PROBE_FORCE).