Re: [PATCH v5 04/12] eal: integrate bus scan and probe with EAL

[Shreyansh Jain <shreyansh.jain@nxp.com>]

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
>