From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id CE5E02B8B for ; Fri, 6 Jan 2017 14:46:16 +0100 (CET) Received: by mail-wm0-f44.google.com with SMTP id t79so30012256wmt.0 for ; Fri, 06 Jan 2017 05:46:16 -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:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=G/5BxAsDSxKfYxmDpevA9b4XovI+xk5nB5OADeNArjQ=; b=BIx/0jPxvkU+Zoog0GQBMKjfd6oxCTX7o9Ra5lT9hJ7wLxf6uf94q1YjyNpV93NCxW w4l3EwBAdnK2cUJ8O7eBk1nsZVzUf1e61o7aTZXSjal96hUFf8OCahqe+QA8qKdPvbKL TLEVgc2khXkb9FKO0kd7M4COpVpE2j4/8Zc//4WukiIJT9uu2keOcfq7OUbTTSQMn/Qw /le+kFlbrBLRZeVY87zaOd4XVOTBaYb9iknr4WWkH49hzr9Py6Iy/iIFRtQOclsJCtKt VYhwzmG9KTJZc9KmTigvfzgJ0dHt/abJXaIHlFgDhugO51FwAy8OhoLLSsnWNHNHMCTb NFHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=G/5BxAsDSxKfYxmDpevA9b4XovI+xk5nB5OADeNArjQ=; b=F0ll86g831giS8HNMBU83CLY4qa0X1kHG9SiQUcVVoyWTbgTSJZcZCbt0sQzcgHKql H3D99egtLC8WUD1QXdDHjBkADsWT7kWBvG3nMUj2AqNn1Q7HKtH3SyihoiAzEypE3apL LDu9I/zuXKjS+N/Jd6pvmRSLiWVOpDuXGZ7uCHdlpjBSoNL3qicsHerXLliE2MNJmaiI EaJFJ9RGdD6BcaHW5iwE7gWyIlPk+li9wPATlsBgNkIhWtzz/IiQIUKE2wqMAc0vtmaK OPkOxjtWrHeilOJJRW8BdnHbw4sv7F4OSkZt92pRtoZ7/roBWhzKyXaz4gGZlkoDRLIE JfLQ== X-Gm-Message-State: AIkVDXKTR4E8XxUQq+Jx8NdDGUyp38kh16sbINpNl4OB7Jwxa4JX1MQKnpD0nQP4bp18XKhJ X-Received: by 10.28.155.202 with SMTP id d193mr4281767wme.38.1483710375691; Fri, 06 Jan 2017 05:46:15 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id u81sm3466669wmu.10.2017.01.06.05.46.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jan 2017 05:46:15 -0800 (PST) From: Thomas Monjalon To: Shreyansh Jain Cc: david.marchand@6wind.com, dev@dpdk.org Date: Fri, 06 Jan 2017 14:46:14 +0100 Message-ID: <1912570.qtcMvjyK2L@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <12807c5e-24b4-796b-5c1e-8c08090f4d06@nxp.com> References: <1482756644-13726-1-git-send-email-shreyansh.jain@nxp.com> <654c9419-247a-90b5-11d0-a8e3551ce582@nxp.com> <12807c5e-24b4-796b-5c1e-8c08090f4d06@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5 04/12] eal: integrate bus scan and probe with EAL 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: , X-List-Received-Date: Fri, 06 Jan 2017 13:46:17 -0000 2017-01-06 17:30, Shreyansh Jain: > On Friday 06 January 2017 04:08 PM, Shreyansh Jain wrote: > > On Wednesday 04 January 2017 03:16 AM, Thomas Monjalon wrote: > >> 2016-12-26 18:53, Shreyansh Jain: > >>> --- a/lib/librte_eal/linuxapp/eal/eal.c > >>> +++ b/lib/librte_eal/linuxapp/eal/eal.c > >>> @@ -844,6 +845,9 @@ rte_eal_init(int argc, char **argv) > >>> if (rte_eal_intr_init() < 0) > >>> rte_panic("Cannot init interrupt-handling thread\n"); > >>> > >>> + if (rte_eal_bus_scan()) > >>> + rte_panic("Cannot scan the buses for devices\n"); > >> > >> Yes, definitely. Just one scan functions which scan registered bus. > >> > >>> @@ -884,6 +888,9 @@ rte_eal_init(int argc, char **argv) > >>> if (rte_eal_pci_probe()) > >>> rte_panic("Cannot probe PCI\n"); > >>> > >>> + if (rte_eal_bus_probe()) > >>> + rte_panic("Cannot probe devices\n"); > >>> + > >>> if (rte_eal_dev_init() < 0) > >>> rte_panic("Cannot init pmd devices\n"); > >> > >> What is the benefit of initializing (probe) a device outside of the scan? > >> Currently, it is done in two steps, so you are keeping the same > >> behaviour. > > > > Yes, only for compatibility to existing model of two-step process. > > Ideally, only a single step is enough (init->probe). > > > > During the discussion in [1] also this point was raised - at that time > > for VDEV and applicability to PCI. > > > > [1] http://dpdk.org/ml/archives/dev/2016-December/051306.html > > > > If you want, I can merge these two. I postponed it because 1) it is an > > independent change and should really impact bus and 2) I was not sure > > of dependency of init *before* pthread_create for all workers. > > I forgot _not_ in above - rephrasing: > > If you want, I can merge these two. I postponed it because 1) it is an > independent change and should _not_ really impact bus and 2) I was not > sure of dependency of init *before* pthread_create for all workers. I'm OK with your approach. > >> I imagine a model where the scan function decide to initialize the > >> device and can require some help from a callback to make this decision. > >> So the whitelist/blacklist policy can be implemented with callbacks at > >> the scan level and possibly the responsibility of the application. > >> Note that the callback model would be a change for a next release. > > > > Agree. But, that is not really part of Bus patches - isn't it? Or, you > > want to change that with this series? No it is not the scope of this series. Please could you add it in the cover letter as a next step? Thanks