[dpdk-dev] [EXT] Re: [PATCH] bus/pci: restricted bus scanning to allowed devices

Sunil Kumar Kori skori at marvell.com
Thu Feb 27 09:30:22 CET 2020


Hello All, 

Is there any thought on this ? Otherwise it can be merged. 

Regards
Sunil Kumar Kori

>-----Original Message-----
>From: Sunil Kumar Kori
>Sent: Thursday, January 23, 2020 2:13 PM
>To: Stephen Hemminger <stephen at networkplumber.org>; Jerin Jacob
>Kollanukkaran <jerinj at marvell.com>
>Subject: FW: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: restricted bus scanning to
>allowed devices
>
>Hello Stephen,
>
>Can you please look into this patch or provide your thought in this ? So that it
>can be merged within 20.02 release.
>
>Regards
>Sunil Kumar Kori
>
>-----Original Message-----
>From: Sunil Kumar Kori <skori at marvell.com>
>Sent: Tuesday, January 21, 2020 2:09 PM
>To: Sunil Kumar Kori <skori at marvell.com>; Stephen Hemminger
><stephen at networkplumber.org>
>Cc: dev at dpdk.org
>Subject: RE: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: restricted bus scanning to
>allowed devices
>
>Hello Stephen,
>Any suggestions ?
>
>Regards
>Sunil Kumar Kori
>
>>-----Original Message-----
>>From: dev <dev-bounces at dpdk.org> On Behalf Of Sunil Kumar Kori
>>Sent: Tuesday, December 17, 2019 4:30 PM
>>To: Stephen Hemminger <stephen at networkplumber.org>
>>Cc: dev at dpdk.org
>>Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: restricted bus
>>scanning to allowed devices
>>
>>
>>
>>Regards
>>Sunil Kumar Kori
>>
>>>-----Original Message-----
>>>From: Stephen Hemminger <stephen at networkplumber.org>
>>>Sent: Monday, December 16, 2019 9:43 PM
>>>To: Sunil Kumar Kori <skori at marvell.com>
>>>Cc: dev at dpdk.org
>>>Subject: [EXT] Re: [dpdk-dev] [PATCH] bus/pci: restricted bus scanning
>>>to allowed devices
>>>
>>>External Email
>>>
>>>----------------------------------------------------------------------
>>>> 			/* Create dummy pci device to get devargs */
>>>> +			dummy_dev.addr.domain =
>>>matches[i].pc_sel.pc_domain;
>>>> +			dummy_dev.addr.bus = matches[i].pc_sel.pc_bus;
>>>> +			dummy_dev.addr.devid = matches[i].pc_sel.pc_dev;
>>>> +			dummy_dev.addr.function =
>>>matches[i].pc_sel.pc_func;
>>>> +			dummy_dev.device.devargs =
>>>> +
>>>	pci_devargs_lookup(&dummy_dev);
>>>> +
>>>> +			/* Check that device should be ignored or not  */
>>>> +			if (pci_ignore_device(&dummy_dev))
>>>> +				continue;
>>>
>>>It seems that you are creating dummy_dev as an alternative to passing
>>>just the PCI bus/device/function. Wouldn't be easier to just use BDF
>>>instead. Dummy arguments on the stack can lead to more corner cases in
>>>the future if device subsystem changes.
>>Agreed and initially I have implemented using BDF only instead of using
>>dummy device.
>>But using that approach, I was not able to use existing APIs to get
>>devargs and ignore device.
>>I had to write almost same functions to solve the purpose. So just to
>>avoid having replica of same code, I followed this approach. Please suggest.
>>>
>>>> +/**
>>>> + * Get the devargs of a PCI device.
>>>> + *
>>>> + * @param pci_dev
>>>> + *	PCI device to be validated
>>>> + * @return
>>>> + *	devargs on succes, NULL otherwise
>>>> + */
>>>> +struct rte_devargs *pci_devargs_lookup(struct rte_pci_device
>>>> +*pci_dev);
>>>
>>>Must be marked experimental (or internal).
>>>The pci_device should be marked const.
>>Okay but If I go with BDF one then this change is not required anyway.
>>>
>>>
>>>> +
>>>> +/**
>>>> + * Validate whether a pci device should be ignored or not.
>>>> + *
>>>> + * @param pci_dev
>>>> + *	PCI device to be validated
>>>> + * @return
>>>> + *	1 if device is to be ignored, 0 otherwise
>>>> + */
>>>> +bool pci_ignore_device(const struct rte_pci_device *pci_dev);
>>>
>>>ditto
>>ditto


More information about the dev mailing list