[dpdk-dev] [PATCH 8/9] pci: add a helper to refresh a device

Jan Viktorin viktorin at rehivetech.com
Wed Feb 10 12:23:33 CET 2016


On Fri, 29 Jan 2016 15:08:35 +0100
David Marchand <david.marchand at 6wind.com> wrote:

> It will be used mainly for hotplug code.
> 
> Signed-off-by: David Marchand <david.marchand at 6wind.com>
> ---
>  lib/librte_eal/bsdapp/eal/eal_pci.c   | 49 +++++++++++++++++++++++++++++++++++
>  lib/librte_eal/common/eal_private.h   | 13 ++++++++++
>  lib/librte_eal/linuxapp/eal/eal_pci.c | 13 ++++++++++
>  3 files changed, 75 insertions(+)
> 
> diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c b/lib/librte_eal/bsdapp/eal/eal_pci.c
> index 4584522..5dd89e3 100644
> --- a/lib/librte_eal/bsdapp/eal/eal_pci.c
> +++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
> @@ -396,6 +396,55 @@ error:
>  	return -1;
>  }
>  
> +int
> +pci_refresh_device(const struct rte_pci_addr *addr)

What about pci_reload_device or pci_reload_device_info? I don't mind
too much, only the word 'refresh' reminds me other associations.

> +{
> +	int fd;
> +	struct pci_conf matches[2];
> +	struct pci_match_conf match = {
> +		.pc_sel = {
> +			.pc_domain = addr->domain,
> +			.pc_bus = addr->bus,
> +			.pc_dev = addr->devid,
> +			.pc_func = addr->function,
> +		},
> +	};
> +	struct pci_conf_io conf_io = {
> +		.pat_buf_len = 0,
> +		.num_patterns = 1,
> +		.patterns = { &match },
> +		.match_buf_len = sizeof(matches),
> +		.matches = &matches[0],
> +	};
> +
> +	fd = open("/dev/pci", O_RDONLY);

Just courious who provides this special file... is a DPDK-specific
thing? I haven't noticed it anywhere in Linux.

> +	if (fd < 0) {
> +		RTE_LOG(ERR, EAL, "%s(): error opening /dev/pci\n", __func__);
> +		goto error;

If you write:
		return -1;

then you can...

> +	}
> +
> +	if (ioctl(fd, PCIOCGETCONF, &conf_io) < 0) {
> +		RTE_LOG(ERR, EAL, "%s(): error with ioctl on /dev/pci: %s\n",
> +				__func__, strerror(errno));
> +		goto error;
> +	}
> +
> +	if (conf_io.num_matches != 1)
> +		goto error;
> +
> +	if (pci_scan_one(fd, &matches[0]) < 0)
> +		goto error;
> +
> +	close(fd);
> +
> +	return 0;
> +
> +error:

...remove this if:

> +	if (fd >= 0)
> +		close(fd);

Or, do you consider it more stable in the orignal way?

> +	return -1;
> +}
> +
>  /* Read PCI config space. */
>  int rte_eal_pci_read_config(const struct rte_pci_device *dev,
>  			    void *buf, size_t len, off_t offset)
> diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
> index 072e672..ed1903f 100644
> --- a/lib/librte_eal/common/eal_private.h
> +++ b/lib/librte_eal/common/eal_private.h
> @@ -155,6 +155,19 @@ struct rte_pci_driver;
>  struct rte_pci_device;
>  
>  /**
> + * Refresh a pci device object by asking the kernel for the latest information.
> + *
> + * This function is private to EAL.
> + *
> + * @param addr
> + *	The PCI Bus-Device-Function address to look for
> + * @return
> + *   - 0 on success.
> + *   - negative on error.

I don't know whether this is a convention in DPDK, anyway, I don't
like to restrict errors to just negatives. You cannot write

if ((err = pci_refresh_device(...)) /* < 0 */) {
	handle_error(err);
}

as the check for < 0 is required (easy to be avoided).

> + */
> +int pci_refresh_device(const struct rte_pci_addr *addr);
> +
> +/**
>   * Unbind kernel driver for this device
>   *
>   * This function is private to EAL.
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linuxapp/eal/eal_pci.c
> index a354f76..4fe8b60 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
> @@ -393,6 +393,19 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
>  	return 0;
>  }
>  
> +int
> +pci_refresh_device(const struct rte_pci_addr *addr)
> +{
> +	char filename[PATH_MAX];
> +
> +	snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT,
> +		 SYSFS_PCI_DEVICES, addr->domain, addr->bus, addr->devid,
> +		 addr->function);
> +
> +	return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
> +			    addr->function);
> +}
> +
>  /*
>   * split up a pci address into its constituent parts.
>   */



-- 
   Jan Viktorin                  E-mail: Viktorin at RehiveTech.com
   System Architect              Web:    www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic


More information about the dev mailing list