From mboxrd@z Thu Jan  1 00:00:00 1970
From: Shreyansh Jain <shreyansh.jain@nxp.com>
Subject: Re: [PATCH v5 04/12] eal: integrate bus scan and probe
	with EAL
Date: Fri, 6 Jan 2017 17:30:46 +0530
Message-ID: <12807c5e-24b4-796b-5c1e-8c08090f4d06@nxp.com>
References: <1482756644-13726-1-git-send-email-shreyansh.jain@nxp.com>
 <1482758645-23057-1-git-send-email-shreyansh.jain@nxp.com>
 <1482758645-23057-5-git-send-email-shreyansh.jain@nxp.com>
 <1763533.RfUee4nzA4@xps13> <654c9419-247a-90b5-11d0-a8e3551ce582@nxp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: <david.marchand@6wind.com>, <dev@dpdk.org>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM01-BN3-obe.outbound.protection.outlook.com
 (mail-bn3nam01on0052.outbound.protection.outlook.com [104.47.33.52])
 by dpdk.org (Postfix) with ESMTP id 8E4C32B9C
 for <dev@dpdk.org>; Fri,  6 Jan 2017 12:57:18 +0100 (CET)
In-Reply-To: <654c9419-247a-90b5-11d0-a8e3551ce582@nxp.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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 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?
>
>
>