From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shreyansh Jain Subject: Re: [PATCH v5 04/12] eal: integrate bus scan and probe with EAL Date: Mon, 9 Jan 2017 12:05:53 +0530 Message-ID: <277ffd19-d6f5-d7b8-abfd-70870cfd4a35@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> <1912570.qtcMvjyK2L@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: , To: Thomas Monjalon Return-path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0087.outbound.protection.outlook.com [104.47.38.87]) by dpdk.org (Postfix) with ESMTP id CF995282 for ; Mon, 9 Jan 2017 07:32:33 +0100 (CET) In-Reply-To: <1912570.qtcMvjyK2L@xps13> 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 Friday 06 January 2017 07:16 PM, Thomas Monjalon wrote: > 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? Yes, I will add to cover letter as Pending Item. > Thanks >