[dpdk-dev,04/13] pci: use scan_mode configuration

  When scanning/probing devices the bus should use its configuration instead
of looking at the devargs->type field.

Signed-off-by: Jan Blunck <jblunck@infradead.org>
---
 lib/librte_eal/common/eal_common_pci.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)
  

On Tue, Jul 11, 2017 at 07:25:03PM -0400, Jan Blunck wrote:
> When scanning/probing devices the bus should use its configuration instead
> of looking at the devargs->type field.
> 

With this patch, how do you probe a device that was previously
blacklisted?

The answers I see to this question are pretty bad, maybe you have a good
solution.

On the other hand, can you explain why you want this limitation? What
problem does this solve? You have one view of the hotplug API, I would
like to understand why you hold this view.

Regarding the rte_devargs API, it can be fixed without making the
hotplug needlessly complicated I think.

I must point out that the scan_mode (incorrectly named) is something
that will be removed next release. The probe policies will be reworked
and I don't think that the solution should be proposed as a fix a few
days before the RC2.

> Signed-off-by: Jan Blunck <jblunck@infradead.org>
> ---
>  lib/librte_eal/common/eal_common_pci.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/librte_eal/common/eal_common_pci.c b/lib/librte_eal/common/eal_common_pci.c
> index 72fcc35c2..fb0e29ac4 100644
> --- a/lib/librte_eal/common/eal_common_pci.c
> +++ b/lib/librte_eal/common/eal_common_pci.c
> @@ -197,8 +197,7 @@ rte_pci_probe_one_driver(struct rte_pci_driver *dr,
>  
>  	/* no initialization when blacklisted, return without error */
>  	if (dev->device.devargs != NULL &&
> -		dev->device.devargs->type ==
> -			RTE_DEVTYPE_BLACKLISTED_PCI) {
> +		rte_pci_bus.bus.conf.scan_mode == RTE_BUS_SCAN_BLACKLIST) {
>  		RTE_LOG(INFO, EAL, "  Device is blacklisted, not"
>  			" initializing\n");
>  		return 1;
> @@ -404,8 +403,7 @@ rte_pci_probe(void)
>  		/* probe all or only whitelisted devices */
>  		if (probe_all)
>  			ret = pci_probe_all_drivers(dev);
> -		else if (devargs != NULL &&
> -			devargs->type == RTE_DEVTYPE_WHITELISTED_PCI)
> +		else if (devargs != NULL)
>  			ret = pci_probe_all_drivers(dev);
>  		if (ret < 0) {
>  			RTE_LOG(ERR, EAL, "Requested device " PCI_PRI_FMT
> -- 
> 2.13.2
>
  

On Thu, Jul 13, 2017 at 1:59 PM, Gaëtan Rivet <gaetan.rivet@6wind.com> wrote:
> On Tue, Jul 11, 2017 at 07:25:03PM -0400, Jan Blunck wrote:
>> When scanning/probing devices the bus should use its configuration instead
>> of looking at the devargs->type field.
>>
>
> With this patch, how do you probe a device that was previously
> blacklisted?
>
> The answers I see to this question are pretty bad, maybe you have a good
> solution.
>
> On the other hand, can you explain why you want this limitation? What
> problem does this solve? You have one view of the hotplug API, I would
> like to understand why you hold this view.
>
> Regarding the rte_devargs API, it can be fixed without making the
> hotplug needlessly complicated I think.
>
> I must point out that the scan_mode (incorrectly named) is something
> that will be removed next release. The probe policies will be reworked
> and I don't think that the solution should be proposed as a fix a few
> days before the RC2.
>

You just introduced them in 17.08-rc1 and you want to remove them
again for 17.11?! Please revert these changes in this case for
17.08-rc2.

Thomas, what is your take on this?


>> Signed-off-by: Jan Blunck <jblunck@infradead.org>
>> ---
>>  lib/librte_eal/common/eal_common_pci.c | 6 ++----
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/librte_eal/common/eal_common_pci.c b/lib/librte_eal/common/eal_common_pci.c
>> index 72fcc35c2..fb0e29ac4 100644
>> --- a/lib/librte_eal/common/eal_common_pci.c
>> +++ b/lib/librte_eal/common/eal_common_pci.c
>> @@ -197,8 +197,7 @@ rte_pci_probe_one_driver(struct rte_pci_driver *dr,
>>
>>       /* no initialization when blacklisted, return without error */
>>       if (dev->device.devargs != NULL &&
>> -             dev->device.devargs->type ==
>> -                     RTE_DEVTYPE_BLACKLISTED_PCI) {
>> +             rte_pci_bus.bus.conf.scan_mode == RTE_BUS_SCAN_BLACKLIST) {
>>               RTE_LOG(INFO, EAL, "  Device is blacklisted, not"
>>                       " initializing\n");
>>               return 1;
>> @@ -404,8 +403,7 @@ rte_pci_probe(void)
>>               /* probe all or only whitelisted devices */
>>               if (probe_all)
>>                       ret = pci_probe_all_drivers(dev);
>> -             else if (devargs != NULL &&
>> -                     devargs->type == RTE_DEVTYPE_WHITELISTED_PCI)
>> +             else if (devargs != NULL)
>>                       ret = pci_probe_all_drivers(dev);
>>               if (ret < 0) {
>>                       RTE_LOG(ERR, EAL, "Requested device " PCI_PRI_FMT
>> --
>> 2.13.2
>>
>
> --
> Gaėtan Rivet
> 6WIND
  

13/07/2017 21:42, Jan Blunck:
> On Thu, Jul 13, 2017 at 1:59 PM, Gaëtan Rivet <gaetan.rivet@6wind.com> wrote:
> > On Tue, Jul 11, 2017 at 07:25:03PM -0400, Jan Blunck wrote:
> >> When scanning/probing devices the bus should use its configuration instead
> >> of looking at the devargs->type field.
> >>
> >
> > With this patch, how do you probe a device that was previously
> > blacklisted?
> >
> > The answers I see to this question are pretty bad, maybe you have a good
> > solution.
> >
> > On the other hand, can you explain why you want this limitation? What
> > problem does this solve? You have one view of the hotplug API, I would
> > like to understand why you hold this view.
> >
> > Regarding the rte_devargs API, it can be fixed without making the
> > hotplug needlessly complicated I think.
> >
> > I must point out that the scan_mode (incorrectly named) is something
> > that will be removed next release. The probe policies will be reworked
> > and I don't think that the solution should be proposed as a fix a few
> > days before the RC2.
> 
> You just introduced them in 17.08-rc1 and you want to remove them
> again for 17.11?! Please revert these changes in this case for
> 17.08-rc2.

Please remember that it has been introduced to prepare the move of
the bus drivers and allow some kind of hotplug as used in failsafe,
without breaking the devargs syntax.
This is a step in an incremental process, and experimental functions
and deprecated API can be dropped for a better replacement in 17.11.

> Thomas, what is your take on this?

I did not change my mind:
We must deprecate the syntax in devargs for 17.11.
Then, with a new syntax, it will be possible to simplify a lot of things,
including the probe policies.

For now, we must work on 17.08-rc2 with two goals:
	- fix the API break introduced in devargs API
	- fix the reworked hotplug to make it work in basic PCI cases
	- make sure the new failsafe PMD can be integrated

I will integrate only the patches which clearly fix something.
Patches with justification "it would be better" will wait for 17.11.

Are these rules clear enough to let us progress together in
the 17.08 timeframe, and 17.11 cycle?
Thanks for your efforts and making 17.08 release possible.