All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sunil Kumar Kori <skori@marvell.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: restricted bus scanning to allowed devices
Date: Tue, 17 Dec 2019 11:00:00 +0000	[thread overview]
Message-ID: <CH2PR18MB3270ED32942FD4959732527AB4500@CH2PR18MB3270.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20191216081317.30f10c9d@hermes.lan>



Regards
Sunil Kumar Kori

>-----Original Message-----
>From: Stephen Hemminger <stephen@networkplumber.org>
>Sent: Monday, December 16, 2019 9:43 PM
>To: Sunil Kumar Kori <skori@marvell.com>
>Cc: dev@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

  reply	other threads:[~2019-12-17 11:00 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-16  7:55 [dpdk-dev] [PATCH] bus/pci: restricted bus scanning to allowed devices Sunil Kumar Kori
2019-12-16 16:13 ` Stephen Hemminger
2019-12-17 11:00   ` Sunil Kumar Kori [this message]
2020-01-21  8:39     ` [dpdk-dev] [EXT] " Sunil Kumar Kori
     [not found]       ` <MN2PR18MB327936807460D9F2AE4894F3B40F0@MN2PR18MB3279.namprd18.prod.outlook.com>
2020-02-27  8:30         ` Sunil Kumar Kori
2020-03-09  6:06           ` Sunil Kumar Kori
2020-04-06  9:32             ` Sunil Kumar Kori
2020-04-06 13:21               ` David Marchand
2020-04-07  9:21                 ` Sunil Kumar Kori
2020-04-07  9:28 ` [dpdk-dev] [PATCH v2 1/1] bus/pci: optimise scanning with whitelist/blacklist Sunil Kumar Kori
2020-04-17  8:30   ` Sunil Kumar Kori
2020-04-17  8:44   ` David Marchand
2020-04-17 11:15     ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-04-17 13:25       ` David Marchand
2020-04-17 15:12         ` Sunil Kumar Kori
2020-04-17 15:35           ` David Marchand
2020-04-17 16:00             ` Sunil Kumar Kori
2020-04-20  6:59               ` Sunil Kumar Kori
2020-04-20  6:55   ` [dpdk-dev] [PATCH v3 " Sunil Kumar Kori
2020-04-21 15:18     ` Gaëtan Rivet
2020-04-22  6:17       ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-04-22  9:38         ` Gaëtan Rivet
2020-04-23  7:47           ` Sunil Kumar Kori
2020-04-27 18:43     ` [dpdk-dev] " Gaëtan Rivet
2020-04-28 13:52       ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-05-01 11:39     ` [dpdk-dev] [PATCH v4 " Sunil Kumar Kori
2020-05-01 12:40       ` Sunil Kumar Kori
2020-05-01 21:00       ` Gaëtan Rivet
2020-05-02  7:20         ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-05-02  7:42       ` [dpdk-dev] [PATCH v5 " Sunil Kumar Kori
2020-05-02 11:27         ` Gaëtan Rivet
2020-05-04 14:17         ` David Marchand
2020-05-05  5:57           ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-05-06 12:54           ` [dpdk-dev] " David Marchand
2020-05-11 14:59         ` David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CH2PR18MB3270ED32942FD4959732527AB4500@CH2PR18MB3270.namprd18.prod.outlook.com \
    --to=skori@marvell.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.