Skip to contentSkip to conversation

devargs: add blacklisting by linux interface name

PATCH Superseded Chas Williams 5 participants 15 messages Oct 2, 2015 – Nov 10, 2015

lore
Share & tools
lore

Chas Williams

author
#0 lore raw

PATCH 1/1 devargs: add blacklisting by linux interface name

If a system is using deterministic interface names, it may be easier in some cases to use the interface name to blacklist an interface.

Signed-off-by Chas Williams <[email protected]>
---
 app/test/test_devargs.c                     |  2 ++
 lib/librte_eal/common/eal_common_devargs.c  |  8 ++++++++
 lib/librte_eal/common/eal_common_options.c  | 10 ++++++++++
 lib/librte_eal/common/eal_common_pci.c      | 17 +++++++++++------
 lib/librte_eal/common/eal_options.h         |  2 ++
 lib/librte_eal/common/include/rte_devargs.h |  5 +++++
 lib/librte_eal/common/include/rte_pci.h     |  1 +
 lib/librte_eal/linuxapp/eal/eal_pci.c       | 15 +++++++++++++++
 8 files changed, 54 insertions(+), 6 deletions(-)
app/test/test_devargs.c +2 -0
index f7fc59c..c204c49 100644
@@ -85,6 +85,8 @@ test_devargs(void)
 		goto fail;
 	if (rte_eal_devargs_type_count(RTE_DEVTYPE_VIRTUAL) != 2)
 		goto fail;
+	if (rte_eal_devargs_add(RTE_DEVTYPE_BLACKLISTED_NAME, "eth0") < 0)
+		goto fail;
 	free_devargs_list();
 
 	/* check virtual device with argument parsing */
lib/librte_eal/common/eal_common_devargs.c +8 -0
index ec56165..cac651b 100644
@@ -113,6 +113,14 @@ rte_eal_devargs_add(enum rte_devtype devtype, const char *devargs_str)
 			goto fail;
 
 		break;
+	case RTE_DEVTYPE_BLACKLISTED_NAME:
+		/* save interface name */
+		ret = snprintf(devargs->name.name,
+			       sizeof(devargs->name.name), "%s", buf);
+		if (ret < 0 || ret >= (int)sizeof(devargs->name.name))
+			goto fail;
+
+		break;
 	}
 
 	free(buf);
lib/librte_eal/common/eal_common_options.c +10 -0
index 1f459ac..c08126d 100644
@@ -90,6 +90,7 @@ eal_long_options[] = {
 	{OPT_VFIO_INTR,         1, NULL, OPT_VFIO_INTR_NUM        },
 	{OPT_VMWARE_TSC_MAP,    0, NULL, OPT_VMWARE_TSC_MAP_NUM   },
 	{OPT_XEN_DOM0,          0, NULL, OPT_XEN_DOM0_NUM         },
+	{OPT_BLACKLISTED_NAME,  1, NULL, OPT_BLACKLISTED_NAME_NUM },
 	{0,                     0, NULL, 0                        }
 };
 

@@ -785,6 +786,13 @@ eal_parse_common_option(int opt, const char *optarg,
 		}
 		break;
 
+	case OPT_BLACKLISTED_NAME_NUM:
+		if (rte_eal_devargs_add(RTE_DEVTYPE_BLACKLISTED_NAME,
+				optarg) < 0) {
+			return -1;
+		}
+		break;
+
 	/* don't know what to do, leave this to caller */
 	default:
 		return 1;

@@ -898,6 +906,8 @@ eal_common_usage(void)
 	       "  --"OPT_VDEV"              Add a virtual device.\n"
 	       "                      The argument format is <driver><id>[,key=val,...]\n"
 	       "                      (ex: --vdev=eth_pcap0,iface=eth2).\n"
+	       "  --"OPT_BLACKLISTED_NAME" Add a device name to the black list.\n"
+	       "                      Prevent EAL from using this named interface.\n"
 	       "  --"OPT_VMWARE_TSC_MAP"    Use VMware TSC map instead of native RDTSC\n"
 	       "  --"OPT_PROC_TYPE"         Type of this process (primary|secondary|auto)\n"
 	       "  --"OPT_SYSLOG"            Set syslog facility\n"
lib/librte_eal/common/eal_common_pci.c +11 -6
index dcfe947..41a7690 100644
@@ -90,11 +90,15 @@ static struct rte_devargs *pci_devargs_lookup(struct rte_pci_device *dev)
 	struct rte_devargs *devargs;
 
 	TAILQ_FOREACH(devargs, &devargs_list, next) {
-		if (devargs->type != RTE_DEVTYPE_BLACKLISTED_PCI &&
-			devargs->type != RTE_DEVTYPE_WHITELISTED_PCI)
-			continue;
-		if (!rte_eal_compare_pci_addr(&dev->addr, &devargs->pci.addr))
-			return devargs;
+		if (devargs->type == RTE_DEVTYPE_BLACKLISTED_PCI ||
+			devargs->type == RTE_DEVTYPE_WHITELISTED_PCI) {
+			if (!rte_eal_compare_pci_addr(&dev->addr, &devargs->pci.addr))
+				return devargs;
+		}
+		if (devargs->type == RTE_DEVTYPE_BLACKLISTED_NAME) {
+			if (strcmp(dev->name, devargs->name.name) == 0)
+				return devargs;
+		}
 	}
 	return NULL;
 }

@@ -174,7 +178,8 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr, struct rte_pci_device *d
 
 		/* no initialization when blacklisted, return without error */
 		if (dev->devargs != NULL &&
-			dev->devargs->type == RTE_DEVTYPE_BLACKLISTED_PCI) {
+			(dev->devargs->type == RTE_DEVTYPE_BLACKLISTED_PCI ||
+			 dev->devargs->type == RTE_DEVTYPE_BLACKLISTED_NAME)) {
 			RTE_LOG(DEBUG, EAL, "  Device is blacklisted, not initializing\n");
 			return 1;
 		}
lib/librte_eal/common/eal_options.h +2 -0
index f6714d9..2aea553 100644
@@ -45,6 +45,8 @@ enum {
 	/* first long only option value must be >= 256, so that we won't
 	 * conflict with short options */
 	OPT_LONG_MIN_NUM = 256,
+#define OPT_BLACKLISTED_NAME  "blacklisted-name"
+	OPT_BLACKLISTED_NAME_NUM,
 #define OPT_BASE_VIRTADDR     "base-virtaddr"
 	OPT_BASE_VIRTADDR_NUM,
 #define OPT_CREATE_UIO_DEV    "create-uio-dev"
lib/librte_eal/common/include/rte_devargs.h +5 -0
index 7084ae2..8531405 100644
@@ -59,6 +59,7 @@ enum rte_devtype {
 	RTE_DEVTYPE_WHITELISTED_PCI,
 	RTE_DEVTYPE_BLACKLISTED_PCI,
 	RTE_DEVTYPE_VIRTUAL,
+	RTE_DEVTYPE_BLACKLISTED_NAME,
 };
 
 /**

@@ -87,6 +88,10 @@ struct rte_devargs {
 			/** Driver name. */
 			char drv_name[32];
 		} virtual;
+		struct {
+			/** Interface name. */
+			char name[32];
+		} name;
 	};
 	/** Arguments string as given by user or "" for no argument. */
 	char *args;
lib/librte_eal/common/include/rte_pci.h +1 -0
index 83e3c28..852c149 100644
@@ -161,6 +161,7 @@ struct rte_pci_device {
 	struct rte_pci_resource mem_resource[PCI_MAX_RESOURCE];   /**< PCI Memory Resource */
 	struct rte_intr_handle intr_handle;     /**< Interrupt handle */
 	struct rte_pci_driver *driver;          /**< Associated driver */
+	char name[32];				/**< Interface name (if any) */
 	uint16_t max_vfs;                       /**< sriov enable if not zero */
 	int numa_node;                          /**< NUMA node connection */
 	struct rte_devargs *devargs;            /**< Device user arguments */
lib/librte_eal/linuxapp/eal/eal_pci.c +15 -0
index bc5b5be..c417d01 100644
@@ -260,6 +260,8 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
 	unsigned long tmp;
 	struct rte_pci_device *dev;
 	char driver[PATH_MAX];
+	struct dirent *e;
+	DIR *dir;
 	int ret;
 
 	dev = malloc(sizeof(*dev));

@@ -352,6 +354,19 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
 		return -1;
 	}
 
+	/* get network interface name */
+	snprintf(filename, sizeof(filename), "%s/net", dirname);
+	dir = opendir(filename);
+	if (dir) {
+		while ((e = readdir(dir)) != NULL) {
+			if (e->d_name[0] == '.')
+				continue;
+
+			strcpy(dev->name, e->d_name);
+		}
+		closedir(dir);
+	}
+
 	if (!ret) {
 		if (!strcmp(driver, "vfio-pci"))
 			dev->kdrv = RTE_KDRV_VFIO;
Signature · 1 line
2.1.0
#1 lore raw
Quoted 3 lines · Chas Williams

If a system is using deterministic interface names, it may be easier in some cases to use the interface name to blacklist an interface.

Is it possible to do this using the existing arguments, i.e. have the -b flag detect if it's a pci address or name automatically, rather than having to use a separate command-line arg for it?

/Bruce

author
#2 lore raw
Quoted 8 lines · Bruce Richardson
Quoted 3 lines · Chas Williams

If a system is using deterministic interface names, it may be easier in some cases to use the interface name to blacklist an interface.

Is it possible to do this using the existing arguments, i.e. have the -b flag detect if it's a pci address or name automatically, rather than having to use a separate command-line arg for it?

You might be able to distinguish names by context. I doubt interface names ever look like PCI addresses. But that's going to be a bigger change since -b will need to be updated to 'blacklist' intead of 'pci-blacklist' to prevent confusion. Or do you just want to overload '-b' and keep both long options?

#3 lore raw
Quoted 13 lines

-----Original Message-----
From: Charles (Chas) Williams [mailto:[email protected]]

Quoted 8 lines · Bruce Richardson
Quoted 3 lines · Chas Williams

If a system is using deterministic interface names, it may be easier in some cases to use the interface name to blacklist an interface.

Is it possible to do this using the existing arguments, i.e. have the -b flag detect if it's a pci address or name automatically, rather than having to use a separate command-line arg for it?

Quoted 6 lines

You might be able to distinguish names by context. I doubt interface names ever look like PCI addresses. But that's going to be a bigger change since -b will need to be updated to 'blacklist' intead of 'pci- blacklist' to prevent confusion. Or do you just want to overload '-b' and keep both long options?

I'm not sure about that, to be honest. However, I'd rather not have too many cmd line options to be maintained in the code.

Does you proposed blacklisting patch work with non-pci devices as well as with PCI ones as now?

/Bruce

author
#4 lore raw
Quoted 19 lines · Bruce
Quoted 13 lines

-----Original Message-----
From: Charles (Chas) Williams [mailto:[email protected]]

Quoted 8 lines · Bruce Richardson
Quoted 3 lines · Chas Williams

If a system is using deterministic interface names, it may be easier in some cases to use the interface name to blacklist an interface.

Is it possible to do this using the existing arguments, i.e. have the -b flag detect if it's a pci address or name automatically, rather than having to use a separate command-line arg for it?

Quoted 6 lines

You might be able to distinguish names by context. I doubt interface names ever look like PCI addresses. But that's going to be a bigger change since -b will need to be updated to 'blacklist' intead of 'pci- blacklist' to prevent confusion. Or do you just want to overload '-b' and keep both long options?

Quoted 5 lines

I'm not sure about that, to be honest. However, I'd rather not have too many cmd line options to be maintained in the code.

Does you proposed blacklisting patch work with non-pci devices as well as with PCI ones as now?

Unfortunately, the devargs API is rather PCI specific -- it takes a PCI device. Nothing prevents you from writing a device specific version of the devargs API though for your device class since the devargs list isn't static but checking for certain devargs wouldn't make sense in some cases. Checking to see if a USB device matched a blacklisted PCI device would be pointless.

Other devices (like Xen or hyperv) have a net/ directory/link in their /sys entry that lets you determine an interface name. I think it's the same for USB ethernet devices -- I don't happen to have one to check.

author
#5 lore raw
In reply to Richardson, Bruce
Quoted 5 lines · Bruce

I'm not sure about that, to be honest. However, I'd rather not have too many cmd line options to be maintained in the code.

Does you proposed blacklisting patch work with non-pci devices as well as with PCI ones as now?

I refactored this a bit to fit it into the existing pci blacklisting. Better?

author
#6 lore raw

PATCH v2 1/1 devargs: add blacklisting by linux interface name

In reply to Chas Williams

If a system is using deterministic interface names, it may be easier in some cases to use the interface name to blacklist an interface.

Signed-off-by Chas Williams <[email protected]>
---
 app/test/test_devargs.c                     |  2 ++
 lib/librte_eal/common/eal_common_devargs.c  |  9 +++++++--
 lib/librte_eal/common/eal_common_options.c  |  2 +-
 lib/librte_eal/common/eal_common_pci.c      | 10 ++++++++--
 lib/librte_eal/common/include/rte_devargs.h |  2 ++
 lib/librte_eal/common/include/rte_pci.h     |  1 +
 lib/librte_eal/linuxapp/eal/eal_pci.c       | 15 +++++++++++++++
 7 files changed, 36 insertions(+), 5 deletions(-)
app/test/test_devargs.c +2 -0
index f7fc59c..27855ff 100644
@@ -73,6 +73,8 @@ test_devargs(void)
 		goto fail;
 	if (rte_eal_devargs_add(RTE_DEVTYPE_BLACKLISTED_PCI, "0000:01:00.1") < 0)
 		goto fail;
+	if (rte_eal_devargs_add(RTE_DEVTYPE_BLACKLISTED_PCI, "eth0") < 0)
+		goto fail;
 	if (rte_eal_devargs_type_count(RTE_DEVTYPE_WHITELISTED_PCI) != 2)
 		goto fail;
 	if (rte_eal_devargs_type_count(RTE_DEVTYPE_BLACKLISTED_PCI) != 2)
lib/librte_eal/common/eal_common_devargs.c +7 -2
index ec56165..1fb8bad 100644
@@ -101,8 +101,13 @@ rte_eal_devargs_add(enum rte_devtype devtype, const char *devargs_str)
 	case RTE_DEVTYPE_BLACKLISTED_PCI:
 		/* try to parse pci identifier */
 		if (eal_parse_pci_BDF(buf, &devargs->pci.addr) != 0 &&
-		    eal_parse_pci_DomBDF(buf, &devargs->pci.addr) != 0)
-			goto fail;
+		    eal_parse_pci_DomBDF(buf, &devargs->pci.addr) != 0) {
+			/* save as interface name instead */
+			ret = snprintf(devargs->pci.name,
+				       sizeof(devargs->pci.name), "%s", buf);
+			if (ret < 0 || ret >= (int)sizeof(devargs->pci.name))
+				goto fail;
+		}
 
 		break;
 	case RTE_DEVTYPE_VIRTUAL:
lib/librte_eal/common/eal_common_options.c +1 -1
index 1f459ac..6920088 100644
@@ -889,7 +889,7 @@ eal_common_usage(void)
 	       "  -r RANKS            Force number of memory ranks (don't detect)\n"
 	       "  -b, --"OPT_PCI_BLACKLIST" Add a PCI device in black list.\n"
 	       "                      Prevent EAL from using this PCI device. The argument\n"
-	       "                      format is <domain:bus:devid.func>.\n"
+	       "                      format is <domain:bus:devid.func> or <name>.\n"
 	       "  -w, --"OPT_PCI_WHITELIST" Add a PCI device in white list.\n"
 	       "                      Only use the specified PCI devices. The argument format\n"
 	       "                      is <[domain:]bus:devid.func>. This option can be present\n"
lib/librte_eal/common/eal_common_pci.c +8 -2
index dcfe947..288c8bd 100644
@@ -93,8 +93,14 @@ static struct rte_devargs *pci_devargs_lookup(struct rte_pci_device *dev)
 		if (devargs->type != RTE_DEVTYPE_BLACKLISTED_PCI &&
 			devargs->type != RTE_DEVTYPE_WHITELISTED_PCI)
 			continue;
-		if (!rte_eal_compare_pci_addr(&dev->addr, &devargs->pci.addr))
-			return devargs;
+
+		if (devargs->pci.name[0] == '\0') {
+			if (!rte_eal_compare_pci_addr(&dev->addr, &devargs->pci.addr))
+				return devargs;
+		} else {
+			if (strcmp(dev->name, devargs->pci.name) == 0)
+				return devargs;
+		}
 	}
 	return NULL;
 }
lib/librte_eal/common/include/rte_devargs.h +2 -0
index 7084ae2..bc436ec 100644
@@ -81,6 +81,8 @@ struct rte_devargs {
 		struct {
 			/** PCI location. */
 			struct rte_pci_addr addr;
+			/** Interface name. */
+			char name[32];
 		} pci;
 		/** Used if type is RTE_DEVTYPE_VIRTUAL. */
 		struct {
lib/librte_eal/common/include/rte_pci.h +1 -0
index 83e3c28..852c149 100644
@@ -161,6 +161,7 @@ struct rte_pci_device {
 	struct rte_pci_resource mem_resource[PCI_MAX_RESOURCE];   /**< PCI Memory Resource */
 	struct rte_intr_handle intr_handle;     /**< Interrupt handle */
 	struct rte_pci_driver *driver;          /**< Associated driver */
+	char name[32];				/**< Interface name (if any) */
 	uint16_t max_vfs;                       /**< sriov enable if not zero */
 	int numa_node;                          /**< NUMA node connection */
 	struct rte_devargs *devargs;            /**< Device user arguments */
lib/librte_eal/linuxapp/eal/eal_pci.c +15 -0
index bc5b5be..befb71f 100644
@@ -260,6 +260,8 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
 	unsigned long tmp;
 	struct rte_pci_device *dev;
 	char driver[PATH_MAX];
+	struct dirent *e;
+	DIR *dir;
 	int ret;
 
 	dev = malloc(sizeof(*dev));

@@ -352,6 +354,19 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
 		return -1;
 	}
 
+	/* get network interface name */
+	snprintf(filename, sizeof(filename), "%s/net", dirname);
+	dir = opendir(filename);
+	if (dir) {
+		while ((e = readdir(dir)) != NULL) {
+			if (e->d_name[0] == '.')
+				continue;
+
+			strncpy(dev->name, e->d_name, sizeof(dev->name));
+		}
+		closedir(dir);
+	}
+
 	if (!ret) {
 		if (!strcmp(driver, "vfio-pci"))
 			dev->kdrv = RTE_KDRV_VFIO;
Signature · 1 line
2.1.0
#7 lore raw

lib/librte_eal/common/include/rte_pci.h struct rte_pci_device { · line 164

Quoted 9 lines · On Mon, 5 Oct 2015 11:26:08 -0400 Chas Williams <[email protected]> wrote:
lib/librte_eal/common/include/rte_pci.h +1 -0
index 83e3c28..852c149 100644
@@ -161,6 +161,7 @@ struct rte_pci_device {
 	struct rte_pci_resource mem_resource[PCI_MAX_RESOURCE];   /**< PCI Memory Resource */
 	struct rte_intr_handle intr_handle;     /**< Interrupt handle */
 	struct rte_pci_driver *driver;          /**< Associated driver */
+	char name[32];

Why not use IFNAMSIZ rather than magic constant here?

author
#8 lore raw
Quoted 14 lines · Stephen Hemminger

lib/librte_eal/common/include/rte_pci.h struct rte_pci_device { · line 164

Quoted 9 lines · On Mon, 5 Oct 2015 11:26:08 -0400 Chas Williams <[email protected]> wrote:
lib/librte_eal/common/include/rte_pci.h +1 -0
index 83e3c28..852c149 100644
@@ -161,6 +161,7 @@ struct rte_pci_device {
 	struct rte_pci_resource mem_resource[PCI_MAX_RESOURCE];   /**< PCI Memory Resource */
 	struct rte_intr_handle intr_handle;     /**< Interrupt handle */
 	struct rte_pci_driver *driver;          /**< Associated driver */
+	char name[32];

Why not use IFNAMSIZ rather than magic constant here?

No particular reason. It just matches the virtual device name size. I will change it.

#9 lore raw
In reply to Chas Williams

Hi Chas,

Quoted 32 lines · Chas Williams

If a system is using deterministic interface names, it may be easier in some cases to use the interface name to blacklist an interface.

Signed-off-by Chas Williams <[email protected]>
---
 app/test/test_devargs.c                     |  2 ++
 lib/librte_eal/common/eal_common_devargs.c  |  9 +++++++--
 lib/librte_eal/common/eal_common_options.c  |  2 +-
 lib/librte_eal/common/eal_common_pci.c      | 10 ++++++++--
 lib/librte_eal/common/include/rte_devargs.h |  2 ++
 lib/librte_eal/common/include/rte_pci.h     |  1 +
 lib/librte_eal/linuxapp/eal/eal_pci.c       | 15 +++++++++++++++
 7 files changed, 36 insertions(+), 5 deletions(-)
app/test/test_devargs.c +6 -0
index f7fc59c..27855ff 100644
 
 
[...]

@@ -352,6 +354,19 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
 		return -1;
 	}
 
+	/* get network interface name */
+	snprintf(filename, sizeof(filename), "%s/net", dirname);
+	dir = opendir(filename);
+	if (dir) {
+		while ((e = readdir(dir)) != NULL) {
+			if (e->d_name[0] == '.')

app/test/test_devargs.c pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus, · line 372

Quoted 10 lines
app/test/test_devargs.c +7 -0
+				continue;
+
+			strncpy(dev->name, e->d_name, sizeof(dev->name));
+		}
+		closedir(dir);
+	}
+
 	if (!ret) {
 		if (!strcmp(driver, "vfio-pci"))
 			dev->kdrv = RTE_KDRV_VFIO;

For PCI devices that have several interfaces (I think it's the case for some Mellanox boards), maybe we should not store the interface name?

Another small comment about the strncpy(): it's maybe safer to ensure that dev->name is properly nul-terminated.

Regards,
Olivier

author
#10 lore raw
Quoted 18 lines · Olivier MATZ

Hi Chas,

Quoted 16 lines
lib/librte_eal/linuxapp/eal/eal_pci.c +12 -0
@@ -352,6 +354,19 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
 		return -1;
 	}
 
+	/* get network interface name */
+	snprintf(filename, sizeof(filename), "%s/net", dirname);
+	dir = opendir(filename);
+	if (dir) {
+		while ((e = readdir(dir)) != NULL) {
+			if (e->d_name[0] == '.')
+				continue;
+
+			strncpy(dev->name, e->d_name, sizeof(dev->name));
+		}
+		closedir(dir);
+	}
Quoted 8 lines

lib/librte_eal/linuxapp/eal/eal_pci.c pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus, · line 372

Quoted 5 lines
lib/librte_eal/linuxapp/eal/eal_pci.c +1 -0
+
 	if (!ret) {
 		if (!strcmp(driver, "vfio-pci"))
 			dev->kdrv = RTE_KDRV_VFIO;

For PCI devices that have several interfaces (I think it's the case for some Mellanox boards), maybe we should not store the interface name?

I am not sure what you mean here. If a device has multiple ethernet interfaces, then it should a have seperate PCI device address space for each interface (I dont know of any DPDK drivers that don't make this assumption as well). If the device is multiprotocol, say Infiniband, the device might have a net/ subdirectory, but it will be called something like ib0 which you might want to blacklist for some reason.

Quoted 2 lines

Another small comment about the strncpy(): it's maybe safer to ensure that dev->name is properly nul-terminated.

A good idea but it shouldn't happen in practice since dev.name will be IFNAMSIZ. I will fix it in the next version.

#11 lore raw

2015-10-14 09:41, Charles Williams:

Quoted 8 lines · Olivier MATZ
Quoted 2 lines

For PCI devices that have several interfaces (I think it's the case for some Mellanox boards), maybe we should not store the interface name?

I am not sure what you mean here. If a device has multiple ethernet interfaces, then it should a have seperate PCI device address space for each interface (I dont know of any DPDK drivers that don't make this assumption as well).

mlx4 and cxgbe?

author
#12 lore raw
Quoted 11 lines · Thomas Monjalon

2015-10-14 09:41, Charles Williams:

Quoted 8 lines · Olivier MATZ
Quoted 2 lines

For PCI devices that have several interfaces (I think it's the case for some Mellanox boards), maybe we should not store the interface name?

I am not sure what you mean here. If a device has multiple ethernet interfaces, then it should a have seperate PCI device address space for each interface (I dont know of any DPDK drivers that don't make this assumption as well).

mlx4 and cxgbe?

OK, I see now. I don't know of a way to tell if a device has multiple ports just from the pci vendor/device id without maintaining some sort of table.

Do these devices have multiple interfaces listed in their /sys/devices/.../net diretory? If so, matching one of the listed interfaces can just blacklist the whole device similar to blacklisting by the device id.

#13 lore raw
Quoted 13 lines · On Thu, 05 Nov 2015 11:39:04 -0500 "Charles (Chas) Williams"…
Quoted 11 lines · Thomas Monjalon

2015-10-14 09:41, Charles Williams:

Quoted 8 lines · Olivier MATZ
Quoted 2 lines

For PCI devices that have several interfaces (I think it's the case for some Mellanox boards), maybe we should not store the interface name?

I am not sure what you mean here. If a device has multiple ethernet interfaces, then it should a have seperate PCI device address space for each interface (I dont know of any DPDK drivers that don't make this assumption as well).

mlx4 and cxgbe?

Quoted 8 lines

OK, I see now. I don't know of a way to tell if a device has multiple ports just from the pci vendor/device id without maintaining some sort of table.

Do these devices have multiple interfaces listed in their /sys/devices/.../net diretory? If so, matching one of the listed interfaces can just blacklist the whole device similar to blacklisting by the device id.

Devices with multiple ports are supposed to report the port via /sys/class/net/xxx/portid

But you aren't going to be able to blacklist only one port of these devices. The two drivers would be fighting over registers and IRQ management. Plus kernel bind/unbind is by PCI id.

author
#14 lore raw
Quoted 20 lines · Stephen Hemminger
Quoted 17 lines · On Thu, 05 Nov 2015 11:39:04 -0500 "Charles (Chas) Williams"…
Quoted 11 lines · Thomas Monjalon

2015-10-14 09:41, Charles Williams:

Quoted 8 lines · Olivier MATZ
Quoted 2 lines

For PCI devices that have several interfaces (I think it's the case for some Mellanox boards), maybe we should not store the interface name?

I am not sure what you mean here. If a device has multiple ethernet interfaces, then it should a have seperate PCI device address space for each interface (I dont know of any DPDK drivers that don't make this assumption as well).

mlx4 and cxgbe?

OK, I see now. I don't know of a way to tell if a device has multiple ports just from the pci vendor/device id without maintaining some sort of table.

Quoted 6 lines
Quoted 4 lines

Do these devices have multiple interfaces listed in their /sys/devices/.../net diretory? If so, matching one of the listed interfaces can just blacklist the whole device similar to blacklisting by the device id.

Devices with multiple ports are supposed to report the port via /sys/class/net/xxx/portid

But I want to find the ports associated by the PCI devices.

Quoted 3 lines

But you aren't going to be able to blacklist only one port of these devices. The two drivers would be fighting over registers and IRQ management. Plus kernel bind/unbind is by PCI id.

I understand that. Blacklisting an interface on a multiple port device would be essentially the same as blacklist by the PCI device id. You can't split the PCI device. I just need to find the list of ports associated with a single PCI device.