From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v5 04/12] eal: integrate bus scan and probe with EAL Date: Fri, 06 Jan 2017 14:46:14 +0100 Message-ID: <1912570.qtcMvjyK2L@xps13> 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: david.marchand@6wind.com, dev@dpdk.org To: Shreyansh Jain 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) In-Reply-To: <12807c5e-24b4-796b-5c1e-8c08090f4d06@nxp.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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