[dpdk-dev] [PATCH] app/testpmd: display port driver name
This makes it easier to check which driver name is reported through ethdev
rte_eth_dev_info_get().
Example:
root at ubuntu1604:~/dpdk# ./build/app/testpmd -c 0x6
--vdev net_af_packet0,iface=mgmt0 -- -i --total-num-mbufs 2049
[snip]
testpmd> show port info all
* Infos for port 0 *
MAC address: DE:AD:DE:01:02:03
Driver name: net_af_packet
Connect to socket: 0
memory allocation on the socket: 0
Signed-off-by: David Marchand
---
This small patch is what I used to check
http://dpdk.org/dev/patchwork/patch/17170/ and
http://dpdk.org/dev/patchwork/patch/17171/.
---
app/test-pmd/config.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 36c47ab..8cf537d 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -454,10 +454,13 @@ port_infos_display(portid_t port_id)
}
port = [port_id];
rte_eth_link_get_nowait(port_id, );
+ memset(_info, 0, sizeof(dev_info));
+ rte_eth_dev_info_get(port_id, _info);
printf("\n%s Infos for port %-2d %s\n",
info_border, port_id, info_border);
rte_eth_macaddr_get(port_id, _addr);
print_ethaddr("MAC address: ", _addr);
+ printf("\nDriver name: %s", dev_info.driver_name);
printf("\nConnect to socket: %u", port->socket_id);
if (port_numa[port_id] != NUMA_NO_CONFIG) {
@@ -500,8 +503,6 @@ port_infos_display(portid_t port_id)
printf(" qinq(extend) off \n");
}
- memset(_info, 0, sizeof(dev_info));
- rte_eth_dev_info_get(port_id, _info);
if (dev_info.hash_key_size > 0)
printf("Hash key size in bytes: %u\n", dev_info.hash_key_size);
if (dev_info.reta_size > 0)
--
2.7.4
[dpdk-dev] [PATCH v2 2/2] net: align ethdev and eal driver names
Some virtual pmds report a different name than the vdev driver name
registered in eal.
While it does not hurt, let's try to be consistent.
Signed-off-by: David Marchand
Reviewed-by: Ferruh Yigit
---
drivers/net/af_packet/rte_eth_af_packet.c | 4 +++-
drivers/net/bonding/rte_eth_bond_api.c | 7 +++
drivers/net/bonding/rte_eth_bond_pmd.c | 4 ++--
drivers/net/bonding/rte_eth_bond_private.h | 2 +-
drivers/net/mpipe/mpipe_tilegx.c | 21 -
drivers/net/null/rte_eth_null.c| 4 +++-
drivers/net/pcap/rte_eth_pcap.c| 4 +++-
drivers/net/ring/rte_eth_ring.c| 4 +++-
drivers/net/vhost/rte_eth_vhost.c | 4 +++-
drivers/net/virtio/virtio_ethdev.c | 6 +-
drivers/net/virtio/virtio_ethdev.h | 2 ++
drivers/net/virtio/virtio_user_ethdev.c| 2 +-
drivers/net/xenvirt/rte_eth_xenvirt.c | 3 ++-
13 files changed, 47 insertions(+), 20 deletions(-)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index a66a657..8cae165 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -437,6 +437,8 @@ open_packet_iface(const char *key __rte_unused,
return 0;
}
+static struct rte_vdev_driver pmd_af_packet_drv;
+
static int
rte_pmd_init_internals(const char *name,
const int sockfd,
@@ -690,7 +692,7 @@ rte_pmd_init_internals(const char *name,
(*eth_dev)->dev_ops =
(*eth_dev)->driver = NULL;
(*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
- (*eth_dev)->data->drv_name = "AF_PACKET PMD";
+ (*eth_dev)->data->drv_name = pmd_af_packet_drv.driver.name;
(*eth_dev)->data->kdrv = RTE_KDRV_NONE;
(*eth_dev)->data->numa_node = numa_node;
diff --git a/drivers/net/bonding/rte_eth_bond_api.c
b/drivers/net/bonding/rte_eth_bond_api.c
index 2a3893a..a4e86ae 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "rte_eth_bond.h"
#include "rte_eth_bond_private.h"
@@ -44,8 +45,6 @@
#define DEFAULT_POLLING_INTERVAL_10_MS (10)
-const char pmd_bond_driver_name[] = "rte_bond_pmd";
-
int
check_for_bonded_ethdev(const struct rte_eth_dev *eth_dev)
{
@@ -54,7 +53,7 @@ check_for_bonded_ethdev(const struct rte_eth_dev *eth_dev)
return -1;
/* return 0 if driver name matches */
- return eth_dev->data->drv_name != pmd_bond_driver_name;
+ return eth_dev->data->drv_name != pmd_bond_drv.driver.name;
}
int
@@ -221,7 +220,7 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t
socket_id)
RTE_ETH_DEV_DETACHABLE;
eth_dev->driver = NULL;
eth_dev->data->kdrv = RTE_KDRV_NONE;
- eth_dev->data->drv_name = pmd_bond_driver_name;
+ eth_dev->data->drv_name = pmd_bond_drv.driver.name;
eth_dev->data->numa_node = socket_id;
rte_spinlock_init(>lock);
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index a80b6fa..9bfd9f6 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2566,12 +2566,12 @@ bond_ethdev_configure(struct rte_eth_dev *dev)
return 0;
}
-static struct rte_vdev_driver bond_drv = {
+struct rte_vdev_driver pmd_bond_drv = {
.probe = bond_probe,
.remove = bond_remove,
};
-RTE_PMD_REGISTER_VDEV(net_bonding, bond_drv);
+RTE_PMD_REGISTER_VDEV(net_bonding, pmd_bond_drv);
RTE_PMD_REGISTER_ALIAS(net_bonding, eth_bond);
RTE_PMD_REGISTER_PARAM_STRING(net_bonding,
diff --git a/drivers/net/bonding/rte_eth_bond_private.h
b/drivers/net/bonding/rte_eth_bond_private.h
index d95d440..5a411e2 100644
--- a/drivers/net/bonding/rte_eth_bond_private.h
+++ b/drivers/net/bonding/rte_eth_bond_private.h
@@ -63,7 +63,7 @@
extern const char *pmd_bond_init_valid_arguments[];
-extern const char pmd_bond_driver_name[];
+extern struct rte_vdev_driver pmd_bond_drv;
/** Port Queue Mapping Structure */
struct bond_rx_queue {
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index f00..f0ba91e 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -87,7 +87,6 @@ struct mpipe_local {
static __thread struct mpipe_local mpipe_local;
static struct mpipe_context mpipe_contexts[GXIO_MPIPE_INSTANCE_MAX];
static int mpipe_instances;
-static const char *drivername = "MPIPE PMD";
/* Per queue statistics. */
struct mpipe_queue_stats {
@@ -1549,7 +1548,7 @@ mpipe_link_mac(const char *ifname, uint8_t *mac)
}
static int
-rte_pmd_mpipe_probe(const char *ifname,
+rte_pmd_mpipe_probe_common(struct rte_vdev_driver *drv, const char *ifname,
[dpdk-dev] [PATCH 4/7] virtio: Don't fill dev_info->driver_name
On Mon, Nov 21, 2016 at 5:34 PM, Jan Blunck wrote: > On Sun, Nov 20, 2016 at 4:22 PM, David Marchand >> I posted something similar [1], so looks good to me :-) >> >> [1]: http://dpdk.org/dev/patchwork/patch/16991/ >> > > Thanks for reviewing. Do we go with your proposal then? Do you plan to > follow up on the comments? Yes will do. Out of curiosity how did you catch the qede driver ? Did you check all other drivers ? -- David Marchand
[dpdk-dev] [PATCH] eal: postpone vdev initialization
On Sun, Nov 20, 2016 at 9:00 AM, Jerin Jacob wrote: > Some platform like octeontx may use pci and > vdev based combined device to represent a logical > dpdk functional device.In such case, postponing the > vdev initialization after pci device > initialization will provide the better view of > the pci device resources in the system in > vdev's probe function, and it allows better > functional subsystem registration in vdev probe > function. > > As a bonus, This patch fixes a bond device > initialization use case. > > example command to reproduce the issue: > ./testpmd -c 0x2 --vdev 'eth_bond0,mode=0, > slave=:02:00.0,slave=:03:00.0' -- > --port-topology=chained > > root cause: > In existing case(vdev initialization and then pci > initialization), creates three Ethernet ports with > following port ids > 0 - Bond device > 1 - PCI device 0 > 2 - PCI devive 1 > > Since testpmd, calls the configure/start on all the ports on > start up,it will translate to following illegal setup sequence > > 1)bond device configure/start > 1.1) pci device0 stop/configure/start > 1.2) pci device1 stop/configure/start > 2)pci device 0 configure(illegal setup case, > as device in start state) > > The fix changes the initialization sequence and > allow initialization in following valid setup order > 1) pcie device 0 configure/start > 2) pcie device 1 configure/start > 3) bond device 2 configure/start > 3.1) pcie device 0/stop/configure/start > 3.2) pcie device 1/stop/configure/start This patch is fine. It's been a while since I looked at the bonding pmd. I am just wondering if the bonding pmd should really start its slaves ports. -- David Marchand
[dpdk-dev] [RFC PATCH 0/6] Restructure EAL device model for bus support
This is grey area for me. > (3*) Probably exposing a bitmask for device capabilities. Nothing similar > exists now to relate it. Don't know if that is useful. Allowing > applications to question a device about what it supports and what it > doesn't - making it more flexible at application layer (but more code > as well.) > (4*) Even vdev would be an instantiated as a device. It is not being done > currently. > (#) Items which are still pending > > With this cover letter, some patches have been posted. These are _only_ for > discussion purpose. They are not complete and neither compilable. > All the patches, except 0001, have sufficient context about what the changes > are and rationale for same. Obviously, code is best answer. As said by Jan B., I too think that splitting the patches into smaller patchsets is important. Looking at your datamodel, some quick comments : - Why init/uninit in rte_driver ? Why not probe/remove ? - I don't think dev_private_size makes sense in rte_driver. The bus is responsible for creating rte_device objects (embedded or not in rte_$bus_device objects). If a driver needs to allocate some priv (for whatever needs), the driver should do the allocation itself (or maybe a helper for current eth_driver), then reference the original rte_$bus_device object it got from the probe method. For a first patchset, I would see: - introduce the rte_bus object. In rte_eal_init, for each bus, we call the scan method. Then, for each bus, we find the appropriate rte_driver using the bus match method then call the probe method. If the probe succeeds, the rte_device points to the associated rte_driver, - migrate the pci scan code to a pci bus (scan looks at sysfs for linux / ioctl for bsd + devargs for blacklist / whitelist ?), match is the same at what is done in rte_eal_pci_probe_one_driver() at the moment, - migrate the vdev init code to a vdev bus (scan looks at devargs): this is new, we must create rte_device objects for vdev drivers to use later Then we can talk about the next steps once the bus is in place. -- David Marchand
[dpdk-dev] [PATCH 7/7] ethdev: Move filling of rte_eth_dev_info->pci_dev to dev_infos_get()
On Sun, Nov 20, 2016 at 11:05 AM, Jan Blunck wrote: > Only the device itself can decide its PCI or not. > > Signed-off-by: Jan Blunck > --- > drivers/net/bnx2x/bnx2x_ethdev.c| 1 + > drivers/net/bnxt/bnxt_ethdev.c | 2 ++ > drivers/net/cxgbe/cxgbe_ethdev.c| 2 ++ > drivers/net/e1000/em_ethdev.c | 1 + > drivers/net/e1000/igb_ethdev.c | 2 ++ > drivers/net/ena/ena_ethdev.c| 2 ++ > drivers/net/enic/enic_ethdev.c | 1 + > drivers/net/fm10k/fm10k_ethdev.c| 1 + > drivers/net/i40e/i40e_ethdev.c | 1 + > drivers/net/i40e/i40e_ethdev_vf.c | 1 + > drivers/net/ixgbe/ixgbe_ethdev.c| 2 ++ > drivers/net/mlx4/mlx4.c | 2 ++ > drivers/net/mlx5/mlx5_ethdev.c | 2 ++ > drivers/net/nfp/nfp_net.c | 1 + > drivers/net/qede/qede_ethdev.c | 1 + > drivers/net/szedata2/rte_eth_szedata2.c | 1 + > drivers/net/thunderx/nicvf_ethdev.c | 2 ++ > drivers/net/virtio/virtio_ethdev.c | 1 + > drivers/net/vmxnet3/vmxnet3_ethdev.c| 2 ++ > lib/librte_ether/rte_ethdev.c | 1 - > 20 files changed, 28 insertions(+), 1 deletion(-) Looks good to me. -- David Marchand
[dpdk-dev] [PATCH 2/7] eal: Helper to convert to struct rte_pci_device
Hello Jan,
On Sun, Nov 20, 2016 at 11:05 AM, Jan Blunck wrote:
> Signed-off-by: Jan Blunck
> ---
> lib/librte_eal/common/include/rte_pci.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/librte_eal/common/include/rte_pci.h
> b/lib/librte_eal/common/include/rte_pci.h
> index 9ce8847..0376160 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -160,6 +160,8 @@ struct rte_pci_device {
> enum rte_kernel_driver kdrv;/**< Kernel driver
> passthrough */
> };
>
> +#define ETH_DEV_PCI_DEV(ptr) ((ptr)->pci_dev)
> +
> /** Any PCI device identifier (vendor, device, ...) */
> #define PCI_ANY_ID (0x)
> #define RTE_CLASS_ANY_ID (0xff)
This should come from ethdev, not eal.
--
David Marchand
[dpdk-dev] [PATCH v2] eal/linuxapp: fix return value check of mknod()
Hello Wei,
On Wed, Nov 16, 2016 at 3:40 AM, Wei Dai wrote:
> In function pci_mknod_uio_dev() in lib/librte_eal/eal/eal_pci_uio.c,
> The return value of mknod() is ret, not f got by fopen().
> So the value of ret should be checked for mknod().
>
> Fixes: 67c536bdad93 ("pci: move uio mapping in a dedicated file")
The commit you are pointing is just moving the code.
I would incriminate f7f97c16048e ("pci: add option --create-uio-dev to
run without hotplug")
The rest looks good to me.
--
David Marchand
[dpdk-dev] Clarification for eth_driver changes
On Fri, Nov 11, 2016 at 8:16 PM, Ferruh Yigit wrote: > On 11/10/2016 11:05 AM, Shreyansh Jain wrote: >> On Thursday 10 November 2016 01:46 PM, David Marchand wrote: >>> Do we really need to keep a eth_driver ? >> >> No. As you have rightly mentioned below (as well as in your Jan'16 >> post), it is a mere convenience. > > Isn't it good to separate the logic related which bus device connected > and what functionality it provides. Because these two can be flexible: > > device -> virtual_bus -> ethernet_functionality > device -> pci_bus -> crypto_functionality > device -> x_bus -> y_function "a device is linked to a bus" (fine) "a bus knows what a device does" (?!) Not sure I follow you. -- David Marchand
[dpdk-dev] [PATCH 2/2] net: align ethdev and eal driver names
Hello Ferruh, On Thu, Nov 10, 2016 at 7:46 PM, Ferruh Yigit wrote: > On 11/10/2016 1:51 PM, David Marchand wrote: >> Some virtual pmds report a different name than the vdev driver name >> registered in eal. >> While it does not hurt, let's try to be consistent. >> >> Signed-off-by: David Marchand >> --- > > Since you did all the work, instead of second patch what do you think > doing something like [1] (basically adding eth_dev->rte_driver link) and > when done for all vdevs, remove eth_dev->data->drv_name completely? Hum, in the end, it is better to wait for Shreyansh 17.02 patches. Either I will rebase this patchset, or it won't be necessary anymore. -- David Marchand
[dpdk-dev] [PATCH] doc: announce API and ABI changes for librte_eal
On Thu, Nov 10, 2016 at 12:17 PM, Shreyansh Jain wrote: > Signed-off-by: Shreyansh Jain > --- > doc/guides/rel_notes/deprecation.rst | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 1a9e1ae..2af2476 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -35,3 +35,13 @@ Deprecation Notices > * mempool: The functions for single/multi producer/consumer are deprecated >and will be removed in 17.02. >It is replaced by ``rte_mempool_generic_get/put`` functions. > + > +* ABI/API changes are planned for 17.02: ``rte_device``, ``rte_driver`` will > be > + impacted because of introduction of a new ``rte_bus`` hierarchy. This would > + also impact the way devices are identified by EAL. A bus-device-driver > model > + will be introduced providing a hierarchical view of devices. > + > +* ``eth_driver`` is planned to be removed in 17.02. This currently serves as > + a placeholder for PMDs to register themselves. Changes for ``rte_bus`` will > + provide a way to handle device initialization currently being done in > + ``eth_driver``. > -- > 2.7.4 > Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH 2/2] net: align ethdev and eal driver names
Some virtual pmds report a different name than the vdev driver name
registered in eal.
While it does not hurt, let's try to be consistent.
Signed-off-by: David Marchand
---
drivers/net/af_packet/rte_eth_af_packet.c | 4 +++-
drivers/net/bonding/rte_eth_bond_api.c | 7 +++
drivers/net/bonding/rte_eth_bond_pmd.c | 4 ++--
drivers/net/bonding/rte_eth_bond_private.h | 2 +-
drivers/net/mpipe/mpipe_tilegx.c | 21 -
drivers/net/null/rte_eth_null.c| 4 +++-
drivers/net/pcap/rte_eth_pcap.c| 4 +++-
drivers/net/ring/rte_eth_ring.c| 4 +++-
drivers/net/vhost/rte_eth_vhost.c | 4 +++-
drivers/net/virtio/virtio_ethdev.c | 6 +-
drivers/net/virtio/virtio_ethdev.h | 2 ++
drivers/net/virtio/virtio_user_ethdev.c| 2 +-
drivers/net/xenvirt/rte_eth_xenvirt.c | 3 ++-
13 files changed, 47 insertions(+), 20 deletions(-)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index a66a657..8cae165 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -437,6 +437,8 @@ open_packet_iface(const char *key __rte_unused,
return 0;
}
+static struct rte_vdev_driver pmd_af_packet_drv;
+
static int
rte_pmd_init_internals(const char *name,
const int sockfd,
@@ -690,7 +692,7 @@ rte_pmd_init_internals(const char *name,
(*eth_dev)->dev_ops =
(*eth_dev)->driver = NULL;
(*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
- (*eth_dev)->data->drv_name = "AF_PACKET PMD";
+ (*eth_dev)->data->drv_name = pmd_af_packet_drv.driver.name;
(*eth_dev)->data->kdrv = RTE_KDRV_NONE;
(*eth_dev)->data->numa_node = numa_node;
diff --git a/drivers/net/bonding/rte_eth_bond_api.c
b/drivers/net/bonding/rte_eth_bond_api.c
index 2a3893a..a4e86ae 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "rte_eth_bond.h"
#include "rte_eth_bond_private.h"
@@ -44,8 +45,6 @@
#define DEFAULT_POLLING_INTERVAL_10_MS (10)
-const char pmd_bond_driver_name[] = "rte_bond_pmd";
-
int
check_for_bonded_ethdev(const struct rte_eth_dev *eth_dev)
{
@@ -54,7 +53,7 @@ check_for_bonded_ethdev(const struct rte_eth_dev *eth_dev)
return -1;
/* return 0 if driver name matches */
- return eth_dev->data->drv_name != pmd_bond_driver_name;
+ return eth_dev->data->drv_name != pmd_bond_drv.driver.name;
}
int
@@ -221,7 +220,7 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t
socket_id)
RTE_ETH_DEV_DETACHABLE;
eth_dev->driver = NULL;
eth_dev->data->kdrv = RTE_KDRV_NONE;
- eth_dev->data->drv_name = pmd_bond_driver_name;
+ eth_dev->data->drv_name = pmd_bond_drv.driver.name;
eth_dev->data->numa_node = socket_id;
rte_spinlock_init(>lock);
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index a80b6fa..9bfd9f6 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2566,12 +2566,12 @@ bond_ethdev_configure(struct rte_eth_dev *dev)
return 0;
}
-static struct rte_vdev_driver bond_drv = {
+struct rte_vdev_driver pmd_bond_drv = {
.probe = bond_probe,
.remove = bond_remove,
};
-RTE_PMD_REGISTER_VDEV(net_bonding, bond_drv);
+RTE_PMD_REGISTER_VDEV(net_bonding, pmd_bond_drv);
RTE_PMD_REGISTER_ALIAS(net_bonding, eth_bond);
RTE_PMD_REGISTER_PARAM_STRING(net_bonding,
diff --git a/drivers/net/bonding/rte_eth_bond_private.h
b/drivers/net/bonding/rte_eth_bond_private.h
index d95d440..5a411e2 100644
--- a/drivers/net/bonding/rte_eth_bond_private.h
+++ b/drivers/net/bonding/rte_eth_bond_private.h
@@ -63,7 +63,7 @@
extern const char *pmd_bond_init_valid_arguments[];
-extern const char pmd_bond_driver_name[];
+extern struct rte_vdev_driver pmd_bond_drv;
/** Port Queue Mapping Structure */
struct bond_rx_queue {
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index f00..f0ba91e 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -87,7 +87,6 @@ struct mpipe_local {
static __thread struct mpipe_local mpipe_local;
static struct mpipe_context mpipe_contexts[GXIO_MPIPE_INSTANCE_MAX];
static int mpipe_instances;
-static const char *drivername = "MPIPE PMD";
/* Per queue statistics. */
struct mpipe_queue_stats {
@@ -1549,7 +1548,7 @@ mpipe_link_mac(const char *ifname, uint8_t *mac)
}
static int
-rte_pmd_mpipe_probe(const char *ifname,
+rte_pmd_mpipe_probe_common(struct rte_vdev_driver *drv, const char *ifname,
const c
[dpdk-dev] [PATCH 1/2] net: remove dead driver names
Since b1fb53a39d88 ("ethdev: remove some PCI specific handling"),
rte_eth_dev_info_get() relies on dev->data->drv_name to report the driver
name to caller.
Having the pmds set driver_info->driver_name in the pmds is useless,
since ethdev overwrites it right after.
The only thing the pmd must do is:
- for pci drivers, call rte_eth_copy_pci_info() which then sets
data->drv_name
- for vdev drivers, manually set data->drv_name
At this stage, virtio-user does not properly report a driver name (fixed in
next commit).
Signed-off-by: David Marchand
---
drivers/net/af_packet/rte_eth_af_packet.c | 5 +
drivers/net/nfp/nfp_net.c | 1 -
drivers/net/null/rte_eth_null.c | 4 +---
drivers/net/pcap/rte_eth_pcap.c | 4 +---
drivers/net/qede/qede_ethdev.c| 1 -
drivers/net/ring/rte_eth_ring.c | 4 +---
drivers/net/vhost/rte_eth_vhost.c | 3 ---
drivers/net/virtio/virtio_ethdev.c| 4
drivers/net/xenvirt/rte_eth_xenvirt.c | 5 +
9 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index ff45068..a66a657 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -115,8 +115,6 @@ static const char *valid_arguments[] = {
NULL
};
-static const char *drivername = "AF_PACKET PMD";
-
static struct rte_eth_link pmd_link = {
.link_speed = ETH_SPEED_NUM_10G,
.link_duplex = ETH_LINK_FULL_DUPLEX,
@@ -280,7 +278,6 @@ eth_dev_info(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
{
struct pmd_internals *internals = dev->data->dev_private;
- dev_info->driver_name = drivername;
dev_info->if_index = internals->if_index;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)ETH_FRAME_LEN;
@@ -693,7 +690,7 @@ rte_pmd_init_internals(const char *name,
(*eth_dev)->dev_ops =
(*eth_dev)->driver = NULL;
(*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
- (*eth_dev)->data->drv_name = drivername;
+ (*eth_dev)->data->drv_name = "AF_PACKET PMD";
(*eth_dev)->data->kdrv = RTE_KDRV_NONE;
(*eth_dev)->data->numa_node = numa_node;
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index c6b1587..0c342ab 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1006,7 +1006,6 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- dev_info->driver_name = dev->driver->pci_drv.driver.name;
dev_info->max_rx_queues = (uint16_t)hw->max_rx_queues;
dev_info->max_tx_queues = (uint16_t)hw->max_tx_queues;
dev_info->min_rx_bufsize = ETHER_MIN_MTU;
diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 836d982..09d77fd 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -88,7 +88,6 @@ struct pmd_internals {
static struct ether_addr eth_addr = { .addr_bytes = {0} };
-static const char *drivername = "Null PMD";
static struct rte_eth_link pmd_link = {
.link_speed = ETH_SPEED_NUM_10G,
.link_duplex = ETH_LINK_FULL_DUPLEX,
@@ -295,7 +294,6 @@ eth_dev_info(struct rte_eth_dev *dev,
return;
internals = dev->data->dev_private;
- dev_info->driver_name = drivername;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)-1;
dev_info->max_rx_queues = RTE_DIM(internals->rx_null_queues);
@@ -555,7 +553,7 @@ eth_dev_null_create(const char *name,
eth_dev->driver = NULL;
data->dev_flags = RTE_ETH_DEV_DETACHABLE;
data->kdrv = RTE_KDRV_NONE;
- data->drv_name = drivername;
+ data->drv_name = "Null PMD";
data->numa_node = numa_node;
/* finally assign rx and tx ops */
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 0162f44..8b4fba7 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -119,7 +119,6 @@ static struct ether_addr eth_addr = {
.addr_bytes = { 0, 0, 0, 0x1, 0x2, 0x3 }
};
-static const char *drivername = "Pcap PMD";
static struct rte_eth_link pmd_link = {
.link_speed = ETH_SPEED_NUM_10G,
.link_duplex = ETH_LINK_FULL_DUPLEX,
@@ -552,7 +551,6 @@ eth_dev_info(struct rte_eth_dev *dev,
{
struct pmd_internals *internals = dev->data->dev_private;
- dev_info->driver_name = drivername;
dev_info->if_index = internals->if_index;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (ui
[dpdk-dev] Clarification for eth_driver changes
Hello Shreyansh, On Thu, Nov 10, 2016 at 8:26 AM, Shreyansh Jain wrote: > I need some help and clarification regarding some changes I am doing to > cleanup the EAL code. > > There are some changes which should be done for eth_driver/rte_eth_device > structures: > > 1. most obvious, eth_driver should be renamed to rte_eth_driver. > 2. eth_driver currently has rte_pci_driver embedded in it > - there can be ethernet devices which are _not_ PCI > - in which case, this structure should be removed. Do we really need to keep a eth_driver ? As far as I can see, it is only a convenient wrapper for existing pci drivers, but in the end it is just a pci_driver with ethdev context in it that could be pushed to each existing driver. In my initial description http://dpdk.org/ml/archives/dev/2016-January/031390.html, what I had in mind was only having a rte_eth_device pointing to a generic rte_device. If we need to invoke some generic driver ops from ethdev (I can only see the ethdev hotplug api, maybe I missed something), then we would go through rte_eth_device -> rte_device -> rte_driver. The rte_driver keeps its own bus/private logic in its code, and no need to expose a type. > 3. Similarly, rte_eth_dev has rte_pci_device which should be replaced with > rte_device. Yes, that's the main change for me. Thanks. -- David Marchand
[dpdk-dev] [PATCH] pci: fix one device probing
On Thu, Aug 4, 2016 at 1:50 PM, Igor Ryzhov wrote: > The rte_eal_pci_probe_one function could return false positive result if > no driver is found for the device. > > Signed-off-by: Igor Ryzhov > --- > lib/librte_eal/common/eal_common_pci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/librte_eal/common/eal_common_pci.c > b/lib/librte_eal/common/eal_common_pci.c > index 7248c38..bfb6fd2 100644 > --- a/lib/librte_eal/common/eal_common_pci.c > +++ b/lib/librte_eal/common/eal_common_pci.c > @@ -344,7 +344,7 @@ rte_eal_pci_probe_one(const struct rte_pci_addr *addr) > continue; > > ret = pci_probe_all_drivers(dev); > - if (ret < 0) > + if (ret) > goto err_return; > return 0; > } Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH] pci: do not mark device as taken when probe fails
dev->driver should be set only if a driver did take the device. Signed-off-by: David Marchand --- lib/librte_eal/common/eal_common_pci.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lib/librte_eal/common/eal_common_pci.c b/lib/librte_eal/common/eal_common_pci.c index 971ad20..6163b09 100644 --- a/lib/librte_eal/common/eal_common_pci.c +++ b/lib/librte_eal/common/eal_common_pci.c @@ -214,7 +214,11 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr, struct rte_pci_device *d dev->driver = dr; /* call the driver probe() function */ - return dr->probe(dr, dev); + ret = dr->probe(dr, dev); + if (ret) + dev->driver = NULL; + + return ret; } /* return positive value if driver doesn't support this device */ return 1; -- 2.7.4
[dpdk-dev] [PATCH] pci: Don't call probe callback if driver already loaded.
Hello Thomas, On Sun, Nov 6, 2016 at 10:59 PM, Thomas Monjalon wrote: > 2016-10-25 14:50, Ben Walker: >> If the user asks to probe multiple times, the probe >> callback should only be called on devices that don't have >> a driver already loaded. >> >> This is useful if a driver is registered after the >> execution of a program has started and the list of devices >> needs to be re-scanned. >> >> Signed-off-by: Ben Walker > > Applied, thanks Can you add a follow up patch I will send shortly ? Thanks. -- David Marchand
[dpdk-dev] [PATCH] pci: Don't call probe callback if driver already loaded.
On Thu, Oct 27, 2016 at 3:28 PM, David Marchand wrote: > On Tue, Oct 25, 2016 at 11:50 PM, Ben Walker > wrote: >> If the user asks to probe multiple times, the probe >> callback should only be called on devices that don't have >> a driver already loaded. >> >> This is useful if a driver is registered after the >> execution of a program has started and the list of devices >> needs to be re-scanned. > > Why not use the hotplug api, attaching explicitely one pci device ? Ah, scratch that. I've been too quick to reply. Ok, you are loading a new driver. -- David Marchand
[dpdk-dev] [PATCH] pci: Don't call probe callback if driver already loaded.
Hello Benjamin, On Tue, Oct 25, 2016 at 11:50 PM, Ben Walker wrote: > If the user asks to probe multiple times, the probe > callback should only be called on devices that don't have > a driver already loaded. > > This is useful if a driver is registered after the > execution of a program has started and the list of devices > needs to be re-scanned. Why not use the hotplug api, attaching explicitely one pci device ? > Signed-off-by: Ben Walker > --- > lib/librte_eal/common/eal_common_pci.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/lib/librte_eal/common/eal_common_pci.c > b/lib/librte_eal/common/eal_common_pci.c > index 638cd86..971ad20 100644 > --- a/lib/librte_eal/common/eal_common_pci.c > +++ b/lib/librte_eal/common/eal_common_pci.c > @@ -289,6 +289,10 @@ pci_probe_all_drivers(struct rte_pci_device *dev) > if (dev == NULL) > return -1; > > + /* Check if a driver is already loaded */ > + if (dev->driver != NULL) > + return 0; > + This can do the trick, yes. To be safe, I think we are missing a check in rte_eal_pci_probe_one_driver() so that dev->driver is only set when the probe function from the driver did succeed. -- David Marchand
[dpdk-dev] [PATCH] ethdev: Support VFs on the different PCI domains
On Tue, Oct 11, 2016 at 3:49 PM, Kamil Rytarowski
wrote:
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index 382c959..01d5fb0 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -225,7 +225,7 @@ rte_eth_dev_create_unique_device_name(char *name, size_t
> size,
> {
> int ret;
>
> - ret = snprintf(name, size, "%d:%d.%d",
> + ret = snprintf(name, size, "%d:%d:%d.%d", pci_dev->addr.domain,
> pci_dev->addr.bus, pci_dev->addr.devid,
> pci_dev->addr.function);
> if (ret < 0)
This patch is obsolete since this part has been moved to eal.
Can you test with current master branch if there is still an issue ?
Thanks.
--
David Marchand
[dpdk-dev] [PATCH] net/virtio: add missing driver name
The driver name has been lost with the eal rework.
Restore it.
Fixes: c830cb295411 ("drivers: use PCI registration macro")
Signed-off-by: David Marchand
---
drivers/net/virtio/virtio_ethdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index b4dfc0a..809ebf7 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1304,6 +1304,9 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
static struct eth_driver rte_virtio_pmd = {
.pci_drv = {
+ .driver = {
+ .name = "net_virtio",
+ },
.id_table = pci_id_virtio_map,
.drv_flags = RTE_PCI_DRV_DETACHABLE,
.probe = rte_eth_dev_pci_probe,
--
2.7.4
[dpdk-dev] [PATCH 2/2] ethdev: fix vendor id in debug message
Fixes: af75078fece3 ("first public release")
Signed-off-by: David Marchand
---
lib/librte_ether/rte_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 24029f0..88fa382 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -274,7 +274,7 @@ rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
if (diag == 0)
return 0;
- RTE_PMD_DEBUG_TRACE("driver %s: eth_dev_init(vendor_id=0x%u
device_id=0x%x) failed\n",
+ RTE_PMD_DEBUG_TRACE("driver %s: eth_dev_init(vendor_id=0x%x
device_id=0x%x) failed\n",
pci_drv->driver.name,
(unsigned) pci_dev->id.vendor_id,
(unsigned) pci_dev->id.device_id);
--
2.7.4
[dpdk-dev] [PATCH 1/2] ethdev: fix hotplug attach
If a pci probe operation creates a port but, for any reason, fails to
finish this operation and decides to delete the newly created port, then
the last created port id can not be trusted anymore and any subsequent
attach operations will fail.
This problem was noticed while working on a vm that had a virtio-net
management interface bound to the virtio-net kernel driver and no port
whitelisted in the commandline:
root at ubuntu1404:~/dpdk# ./build/app/testpmd -c 0x6 --
-i --total-num-mbufs=2049
EAL: Detected 3 lcore(s)
EAL: Probing VFIO support...
EAL: Debug logs available - lower performance
EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using
unreliable clock cycles !
EAL: PCI device :00:03.0 on NUMA socket -1
EAL: probe driver: 1af4:1000 (null)
rte_eth_dev_pci_probe: driver (null): eth_dev_init(vendor_id=0x6900
device_id=0x1000) failed
EAL: No probed ethernet devices
^
|
Here, rte_eth_dev_pci_probe() fails since vtpci_init() reports an
error. This results in a rte_eth_dev_release_port() right after a
rte_eth_dev_allocate().
Then, if we try to attach a port using rte_eth_dev_attach:
testpmd> port attach net_ring0
Attaching a new port...
PMD: Initializing pmd_ring for net_ring0
PMD: Creating rings-backed ethdev on numa socket 0
Two solutions:
- either update the last created port index to something invalid
(when freeing a ethdev port),
- or rely on the port count, before and after the eal attach.
The latter solution seems (well not really more robust but at least)
less fragile than the former.
We still have some issues with drivers that create multiple ethdev
ports with a single probe operation, but this was already the case.
Fixes: b0fb26685570 ("ethdev: convert to EAL hotplug")
Reported-by: Daniel Mrzyglod
Signed-off-by: David Marchand
---
lib/librte_ether/rte_ethdev.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index c517e88..24029f0 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -421,7 +421,7 @@ int
rte_eth_dev_attach(const char *devargs, uint8_t *port_id)
{
int ret = -1;
- int current = eth_dev_last_created_port;
+ int current = rte_eth_dev_count();
char *name = NULL;
char *args = NULL;
@@ -438,9 +438,9 @@ rte_eth_dev_attach(const char *devargs, uint8_t *port_id)
if (ret < 0)
goto err;
- /* no point looking at eth_dev_last_created_port if no port exists */
- if (!nb_ports) {
- RTE_LOG(ERR, EAL, "No ports found for device (%s)\n", name);
+ /* no point looking at the port count if no port exists */
+ if (!rte_eth_dev_count()) {
+ RTE_LOG(ERR, EAL, "No port found for device (%s)\n", name);
ret = -1;
goto err;
}
@@ -448,7 +448,7 @@ rte_eth_dev_attach(const char *devargs, uint8_t *port_id)
/* if nothing happened, there is a bug here, since some driver told us
* it did attach a device, but did not create a port.
*/
- if (current == eth_dev_last_created_port) {
+ if (current == rte_eth_dev_count()) {
ret = -1;
goto err;
}
--
2.7.4
[dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs
Hello, On Tue, Oct 4, 2016 at 6:59 PM, Jean Tourrilhes wrote: > On Tue, Oct 04, 2016 at 02:11:39PM +0100, Sergio Gonzalez Monroy wrote: >> The case you are trying to fix is, as an example, when your secondary app is >> using LPM but your primary is not. >> So basically with this patch, you are removing the tailq for LPM on >> secondary and continuing as normal, is that the case? > > The secondary can't use tailq types that the primary does not > have, because they are shared across the shared memory. I am not a "multi process" user but afaik the primary process is responsible for filling the shared memory. The secondary processes look at it. So having unaligned processes can't work. > What happens is that the primary and secondary did not compile > in the same list of tailq. See previous e-mail : > http://dpdk.org/ml/archives/dev/2016-September/047329.html > The reason it's happening is that the secondary was not > compiled with the DPDK build system, but with the build system of the > application (in this case, Snort). Oubviously, porting the application > to the DPDK build system is not practical, so we need to live with > this case. > The build system of the application does not have all the > subtelties of the DPDK build system, and ends up including *all* the > constructors, wether they are used or not in the code. Moreover, they > are included in a different order. Actually, by default the builds > include no constructors at all (which is a big fail), so the library > needs to be included with --whole-archive (see Snort DPDK > instructions). I thought you had unaligned binaries. You are compiling only one binary ? >> I am not convinced about this approach. > > I agree that the whole constructor approach is flaky and my > patch is only a band aid. Constructors should be entirely removed > IMHO, and a more deterministic init method should be used instead of > depending on linker magic. > Note that the other constructors happen to work right in my > case, but that's probably pure luck. The list of mempool constructors > happen to be the same and in the same order (order matters for mempool > constructors). The app is not using spinlock, hash, crc and acl, so > I did not look if the lists did match. I am not sure Sergio is talking about the constructor approach. Anyway, the constructors invocation order should not matter. Primary and secondary processes build their local tailq entries list in constructors (so far, I can't see how this is wrong). "Later", each process updates this list with the actual pointer to the lists by looking at the shared memory in rte_eal_init (calling rte_eal_tailqs_init). What matters is that secondary tailqs are a subset of the primary tailqs. I still have some trouble understanding what you are trying to do. As Sergio asked, can you come up with a simplified example/use case ? Thanks. -- David Marchand
[dpdk-dev] [PATCH] log: do not drop debug logs at compile time
On Mon, Oct 3, 2016 at 6:27 PM, Wiles, Keith wrote: >> On Oct 3, 2016, at 10:37 AM, Olivier Matz wrote: >> What makes you feel it's easier to add a log level instead of adding a >> new RTE_LOG_DP() function? > > It seems to me the log levels are for displaying logs at different levels > adding a new macro to not log is just a hack because we do not have a log > level for data path. This is why I would like to see a log level added and > not a new macro. > > It also appears the new RTE_LOG() will always be in the code as you moved the > test to the RTE_LOG_DP() macro. This would mean all RTE_LOG() in the code > will always call rte_log(), correct? > > If using a new DEBUG_DP (maybe DATAPATH is a better log level name) level we > can use the same macro as before and modify the level only. This way we can > remove via the compiler any log that is below the default RTE_LOG_LEVEL. I > see keeping the rte_log() could be a performance problem or code blot when > you really want to remove them all. > > The DATAPATH log level would be above (smaller number) then DEBUG in the enum > list. To remove all debug logs just set the RTE_LOG_LEVEL to RTE_LOG_DATAPATH. If I try to draw a parrallel to syslog (well, the log subsystem in eal has always been bound to syslog ...), what you propose here is like adding a new level in syslog while you have syslog facilities. With the current log api, we have types and levels, can't we filter at build time depending on the log "type" ? Here we would strip PMD type logs > INFO. -- David Marchand
[dpdk-dev] [PATCH] log: do not drop debug logs at compile time
On Fri, Sep 16, 2016 at 9:43 AM, Olivier Matz wrote: > Today, all logs whose level is lower than INFO are dropped at > compile-time. This prevents from enabling debug logs at runtime using > --log-level=8. > > The rationale was to remove debug logs from the data path at > compile-time, avoiding a test at run-time. > > This patch changes the behavior of RTE_LOG() to avoid the compile-time > optimization, and introduces the RTE_LOG_DP() macro that has the same > behavior than the previous RTE_LOG(), for the rare cases where debug > logs are in the data path. > > So it is now possible to enable debug logs at run-time by just > specifying --log-level=8. Some drivers still have special compile-time > options to enable more debug log. Maintainers may consider to > remove/reduce them. > > Signed-off-by: Olivier Matz > --- > config/common_base | 1 + > doc/guides/faq/faq.rst | 2 +- > drivers/net/bnxt/bnxt_txr.c | 2 +- > drivers/net/nfp/nfp_net.c | 8 +++--- > examples/distributor/main.c | 4 +-- > examples/ipsec-secgw/esp.c | 2 +- > examples/ipsec-secgw/ipsec.c| 4 +-- > examples/packet_ordering/main.c | 6 ++-- > examples/quota_watermark/qw/main.c | 2 +- > examples/tep_termination/main.c | 4 +-- > examples/vhost/main.c | 14 +- > examples/vhost_xen/main.c | 20 +++--- > lib/librte_eal/common/include/rte_log.h | 49 > + > 13 files changed, 67 insertions(+), 51 deletions(-) > > diff --git a/config/common_base b/config/common_base > index 7830535..04b71e9 100644 > --- a/config/common_base > +++ b/config/common_base > @@ -89,6 +89,7 @@ CONFIG_RTE_MAX_MEMSEG=256 > CONFIG_RTE_MAX_MEMZONE=2560 > CONFIG_RTE_MAX_TAILQ=32 > CONFIG_RTE_LOG_LEVEL=RTE_LOG_INFO > +CONFIG_RTE_LOG_DP_LEVEL=RTE_LOG_INFO > CONFIG_RTE_LOG_HISTORY=256 > CONFIG_RTE_LIBEAL_USE_HPET=n > CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n [snip] > diff --git a/lib/librte_eal/common/include/rte_log.h > b/lib/librte_eal/common/include/rte_log.h > index 919563c..76b198f 100644 > --- a/lib/librte_eal/common/include/rte_log.h > +++ b/lib/librte_eal/common/include/rte_log.h [snip] > @@ -266,6 +257,30 @@ int rte_vlog(uint32_t level, uint32_t logtype, const > char *format, va_list ap) > * - Negative on error. > */ > #define RTE_LOG(l, t, ...) \ > +rte_log(RTE_LOG_ ## l, \ > +RTE_LOGTYPE_ ## t, # t ": " __VA_ARGS__) > + > +/** > + * Generates a log message for data path. > + * > + * Similar to RTE_LOG(), except that it is removed at compilation time > + * if the RTE_LOG_DP_LEVEL configuration option is lower than the log > + * level argument. > + * > + * @param l > + * Log level. A value between EMERG (1) and DEBUG (8). The short name is > + * expanded by the macro, so it cannot be an integer value. > + * @param t > + * The log type, for example, EAL. The short name is expanded by the > + * macro, so it cannot be an integer value. > + * @param ... > + * The fmt string, as in printf(3), followed by the variable arguments > + * required by the format. > + * @return > + * - 0: Success. > + * - Negative on error. > + */ > +#define RTE_LOG_DP(l, t, ...) \ > (void)((RTE_LOG_ ## l <= RTE_LOG_LEVEL) ? \ > rte_log(RTE_LOG_ ## l, \ > RTE_LOGTYPE_ ## t, # t ": " __VA_ARGS__) : \ > -- > 2.8.1 Hum, I suppose RTE_LOG_DP should look at RTE_LOG_DP_LEVEL. -- David Marchand
[dpdk-dev] [PATCH v10 00/25] Introducing rte_driver/rte_device generalization
Sorry dropped the ml. On Fri, Sep 16, 2016 at 4:21 PM, David Marchand wrote: > Commenting in the cover letter because these are details and it is > easier to track down what is missing before push for Thomas. > > >> driver: init/uninit common wrappers for PCI drivers > > In this patch subject, init/uninit -> prove/remove. > > >> eal: define container macro > > This patch is fine, but not used in the patchset. I would postpone it > until we actually need it. > > >> eal: extract vdev infra > > This patch commit log tells that the vdev register macro does not call > DRIVER_EXPORT_NAME while it actually does so. > > >> eal: remove unused PMD types > > This patch commit log has some outdated note about pmdinfo. > > We still have a reference about PMD_REGISTER_DRIVER in the > documentation that could be replaced with a note on > DRIVER_REGISTER_PCI() > But I would do this in "drivers: convert all phy drivers as PCI drivers". > > >> eal/pci: replace PCI devinit/devuninit with probe/remove > > This patch only replaces the init/uninit methods with prove/remove for pci. > I would generalise this to vdev as well. -- David Marchand
[dpdk-dev] [PATCH] drivers: advertise kmod dependencies in pmdinfo
On Thu, Sep 15, 2016 at 4:22 PM, Olivier Matz wrote: > Add a new macro DRIVER_REGISTER_KMOD_DEP() that allows a driver to > declare the list of kernel modules required to run properly. > > Today, most PCI drivers require uio/vfio. > > Signed-off-by: Olivier Matz Thanks Olivier, this looks good to me. Btw, I remember some issues with binding ixgbevf devices to uio_pci_generic, so advertising should be carefully checked for each driver. Could drivers maintainers have a look at this ? -- David Marchand
[dpdk-dev] [PATCH v9 00/25] Introducing rte_driver/rte_device generalization
Hello Shreyansh, On Wed, Sep 7, 2016 at 4:07 PM, Shreyansh Jain wrote: > This patch is part of larger aim to: > > + > eth_driver (PMD)|-> rte_driver > crypto_driver (PMD) | ^ > | | > + | > / >+---/+ >| rte_pci_driver | >| rte_vdev_driver| >| rte_soc_driver | >| rte_xxx_driver | > > Where PMD devices (rte_eth_dev, rte_cryptodev_dev) are connected to their > drivers rather than explicitly inheriting type specific driver (PCI, etc). > > > About the Patches: > == > > There are a large number of patches for this - primarily because the changes > are quite varied and keeping them logically separate yet compilable is > important. Most of the patches are small and those which are large touch the > drivers (PMDs) to accommodate the structure changes: > > - Patches 0001~0003 are for introducing the container_of function (so that >rte_device can be obtained from rte_pci_device, for example), and >removing unused code. > - Patches 0004~0007 just perform the ground work for enabling change from >rte_driver/eth_driver based PMDs to rte_xxx_driver based PMDs > - In patch 0008, all the pdev PMDs are changed to support rte_pci_driver ( >including cryptodev, which is eventually generalized with PCI) > - Patch 0009~0010 merge the crypto and pci functions for registration and >naming. > - Patches 0011~0014 deal with hotplugging - hotplug no more invokes scan of >complete bus and has been generalized into EAl from ethdev. > - Patches 0015 introduces vdev init/uninit into separate C units and >enables its compilation. Patch 0016~0017 build on it and remove the >remaining legacy support for vdev/pdev distinctions. > - Patches 0018~0022 enable the vdev drivers to register using the >DRIVER_REGISTER_* operations, and remove their rte_driver->init() > - Patch 0023 enables the rte_driver registration into a common driver >linked list. > - Patches 0024~0025 introduce the rte_device, a generalization of >rte_xxx_device, and associated operation of creating rte_device linked >list. It also enables the drivers to use rte_device.name/numa_node >members rather than rte_xxx_device specific members. > > Notes: > == > > * Some sign-off were already provided by Jan on the original v5; But, as a > large number of merges have been made, I am leaving those out just in case > it is not sync with initial understanding. > > * This might not be in-sync with pmdinfogen as PMD_REGISTER_DRIVER is > removed [7]. > > Future Work/Pending: > === > - Presently eth_driver, rte_eth_dev are not aligned to the rte_driver/ >rte_device model. eth_driver still is a PCI specific entity. This >has been highlighted by comments from Ferruh in [9]. > - cryptodev driver too still remains to be normalized over the rte_driver >model > - Some variables, like drv_name (as highlighted by Ferruh), are getting >duplicated across rte_xxx_driver/device and rte_driver/device. Overall, we are still missing some parts : - in my initial proposition, the rte_driver would embed the probe/remove (previsouly init/uninit) functions that would take rte_device object as arguments (and maybe we should get rid of the double lists, I am not yet convinced it is easy). - the pmdinfo stuff is broken and could be implemented for vdev, I did a quick patch that replaces the "PMD_REGISTER_DRIVER(.*)" regexp as "DRIVER_REGISTER_.*(.*)" then I added a DRIVER_EXPORT_NAME(nm, __COUNTER__) in the vdev register macro, it looks to work fine. pmdinfo is a bit too pci but I think we can go with this. - the names should go to rte_device/rte_driver objects ? -- David Marchand
[dpdk-dev] [PATCH v9 13/25] ethdev: convert to eal hotplug
On Wed, Sep 7, 2016 at 4:08 PM, Shreyansh Jain
wrote:
[snip]
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index fdeac86..86c9d1a 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
[snip]
> + ret = rte_eal_dev_attach(name, args);
> + if (ret < 0)
> + goto err;
> +
> + /* no point looking at eth_dev_last_created_port if no port exists */
> + if (!nb_ports) {
> + RTE_LOG(ERR, EAL, "No ports founds for device (%s)\n", name);
No port found ?
--
David Marchand
[dpdk-dev] [PATCH v9 08/25] drivers: convert all pdev drivers as pci drivers
On Wed, Sep 7, 2016 at 4:08 PM, Shreyansh Jain wrote: > Simplify crypto and ethdev pci drivers init by using newly introduced > init macros and helpers. > Those drivers then don't need to register as "rte_driver"s anymore. > > Exceptions: > - virtio and mlx* use RTE_INIT directly as they have custom initialization > steps. Afaics, we are missing some DRIVER_EXPORT_NAME for those. > - VDEV devices are not modified - they continue to use PMD_REGISTER_DRIVER. > > Signed-off-by: David Marchand > Signed-off-by: Shreyansh Jain -- David Marchand
[dpdk-dev] [PATCH v9 07/25] driver: init/uninit common wrappers for PCI drivers
On Wed, Sep 7, 2016 at 4:07 PM, Shreyansh Jain wrote: > crypto and ethdev drivers aligned to PCI probe/remove. Existing handlers for > init/uninit can be easily reused for this. I would keep in the commit log a mention on the 1 - 1 association between the ethdev/crypto device and the pci device. Besides, I kind of remember a suggestion to rename init as probe and uninit as remove (Thomas ?). But this can go later in the series. -- David Marchand
[dpdk-dev] [PATCH v9 06/25] eal: introduce init macros
On Wed, Sep 7, 2016 at 4:07 PM, Shreyansh Jain
wrote:
> diff --git a/lib/librte_eal/common/include/rte_pci.h
> b/lib/librte_eal/common/include/rte_pci.h
> index fa74962..cf673e4 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -470,6 +470,16 @@ void rte_eal_pci_dump(FILE *f);
> */
> void rte_eal_pci_register(struct rte_pci_driver *driver);
>
> +/** Helper for PCI device registeration from driver (eth, crypto) instance */
Typo: registration
> +#define DRIVER_REGISTER_PCI(nm, pci_drv) \
> +RTE_INIT(pciinitfn_ ##nm); \
> +static void pciinitfn_ ##nm(void) \
> +{ \
> + (pci_drv).name = RTE_STR(nm);\
> + rte_eal_pci_register(_drv); \
> +}\
> +DRIVER_EXPORT_NAME(nm, __COUNTER__)
Checkpatch complains about a missing space.
--
David Marchand
[dpdk-dev] [PATCH] scripts: reverse order of checked commits
On Fri, Sep 9, 2016 at 1:11 PM, Thomas Monjalon wrote: > The list of git commits to check was in the reversed order. > Also add a comment in the help of checkpatches.sh about list input. > > Signed-off-by: Thomas Monjalon Thanks Thomas. Tested-by: David Marchand -- David Marchand
[dpdk-dev] [RFC] igb_uio: deprecate iomem and ioport mapping
Hello Jianfeng,
On Thu, Sep 1, 2016 at 4:16 AM, Jianfeng Tan wrote:
> Previously in igb_uio, iomem is mapped, and both ioport and io mem
> are recorded into uio framework, which is duplicated and makes the
> code too complex.
>
> For iomem, DPDK user space code never opens or reads files under
> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/maps/. Instead,
> /sys/pci/bus/devices/:xx:xx.x/resourceY are used to map device
> memory.
>
> For ioport, non-x86 platforms cannot read from files under
> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/portio/ directly, because
> non-x86 platforms need to map port region for access in user space,
> see non-x86 version pci_uio_ioport_map(). x86 platforms can use the
> the same way as uio_pci_generic.
>
> This patch deprecates iomem and ioport mapping in igb_uio kernel
> module, and adjusts the iomem implementation in both igb_uio and
> uio_pci_generic:
> - for x86 platform, get ports info from /proc/ioports;
> - for non-x86 platform, map and get ports info by pci_uio_ioport_map().
>
> Note: this will affect those applications who are using files under
> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/maps/ and
> /sys/pci/bus/devices/:xx:xx.x/uio/uioY/portio/.
>
> Signed-off-by: Jianfeng Tan
> ---
> lib/librte_eal/linuxapp/eal/eal_pci.c | 4 -
> lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 56 +-
> lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 119
> ++
> 3 files changed, 9 insertions(+), 170 deletions(-)
[snip]
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> index 1786b75..28d09ed 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
[snip]
> - /* FIXME only for primary process ? */
> - if (dev->intr_handle.type == RTE_INTR_HANDLE_UNKNOWN) {
> -
> - snprintf(filename, sizeof(filename), "/dev/uio%u", uio_num);
> - dev->intr_handle.fd = open(filename, O_RDWR);
> - if (dev->intr_handle.fd < 0) {
> - RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
> - filename, strerror(errno));
> - return -1;
> - }
> - dev->intr_handle.type = RTE_INTR_HANDLE_UIO;
> - }
The only potential issue I can see removing this is that if a device
has no iomem resource, then its interrupt fd will never be
initialised.
I can see no problem at the moment, so let's go with this.
If such a problem arises later, we can separate this from the resource
mapping stuff (with a new api ?).
The rest looks good to me.
As Ferruh said, this should go through deprecation notices then go in 17.02.
--
David Marchand
[dpdk-dev] [PATCH 1/3] net/ixgbe: move PCI device ids to the driver
On Mon, Aug 8, 2016 at 11:10 AM, Ferruh Yigit wrote:
> On 8/8/2016 7:36 AM, David Marchand wrote:
>> The only thing that bothers me using this ("unsynchronised") internal
>> pci device list is that, if people were using the ethtool part of kni,
>> there would now be devices that won't be recognised anymore.
>> Is it intentional ?
>
> I am aware that the list changed, but wasn't sure about updating the
> list in drivers or not.
>
> If a device is not listed in driver's pci device id table, it may not be
> supported, so ethtool may give wrong output, or it may just be missing,
> this is hard to know without testing (although this was the case before
> this patch)
>
> Since it is easy to add new id, and we are at the beginning of the
> release, I was thinking if somebody reports KNI ethotool support is
> missing for a specific device, we can add it instead of adding all by
> default.
Ok for me and with this we can know if this ethtool part is used :-)
--
David Marchand
[dpdk-dev] [PATCH 1/3] net/ixgbe: move PCI device ids to the driver
Hello Ferruh,
On Fri, Aug 5, 2016 at 4:09 PM, Ferruh Yigit wrote:
> PCI device ids moved from common header into ixgbe driver itself.
>
> KNI starts using pci_device_id from kni/ethtool/ixgbe driver, this is
> only for KNI ethtool support, KNI data path is not effected.
>
> Signed-off-by: Ferruh Yigit
Thanks for working on this.
The only thing that bothers me using this ("unsynchronised") internal
pci device list is that, if people were using the ethtool part of kni,
there would now be devices that won't be recognised anymore.
Is it intentional ?
If so, we should explain why in the documentation.
Same comment for the igb patch.
--
David Marchand
[dpdk-dev] [PATCH 3/3] eal: remove rte_pci_dev_ids.h
On Sat, Aug 6, 2016 at 2:55 PM, Thomas Monjalon wrote: > What do you think about this list? I would say we can remove it. Yes, we already discussed this with John. http://dpdk.org/ml/archives/dev/2016-January/031595.html -- David Marchand
[dpdk-dev] [PATCH v2] log: remove history dump
On Fri, Jul 29, 2016 at 3:50 PM, Thomas Monjalon wrote: > The log history feature was deprecated in 16.07. > The remaining empty functions are removed in 16.11. > > Signed-off-by: Thomas Monjalon > --- > v2: fix LIBABIVER and compilation of test Thanks Thomas. Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH] ivshmem: remove integration in dpdk
Following discussions on the mailing list [1] and since nobody stood up to implement the necessary cleanups, here is the ivshmem integration removal. There is not much to say about this patch, a lot of code is being removed. The default configuration file for packet_ordering example is replaced with the "native" x86 file. The only tricky part is in eal_memory with the memseg index stuff. More cleanups can be done after this but will come in subsequent patchsets. [1]: http://dpdk.org/ml/archives/dev/2016-June/040844.html Signed-off-by: David Marchand --- MAINTAINERS | 8 - app/test/Makefile| 1 - app/test/autotest_data.py| 6 - app/test/test.c | 3 - app/test/test.h | 1 - app/test/test_ivshmem.c | 433 config/defconfig_arm64-armv8a-linuxapp-gcc | 1 - config/defconfig_x86_64-ivshmem-linuxapp-gcc | 49 -- config/defconfig_x86_64-ivshmem-linuxapp-icc | 49 -- doc/api/doxy-api-index.md| 1 - doc/api/doxy-api.conf| 1 - doc/api/examples.dox | 2 - doc/guides/linux_gsg/build_dpdk.rst | 2 +- doc/guides/linux_gsg/quick_start.rst | 14 +- doc/guides/prog_guide/img/ivshmem.png| Bin 44920 -> 0 bytes doc/guides/prog_guide/index.rst | 1 - doc/guides/prog_guide/ivshmem_lib.rst| 160 - doc/guides/prog_guide/source_org.rst | 1 - doc/guides/rel_notes/deprecation.rst | 3 - doc/guides/rel_notes/release_16_11.rst | 3 + examples/Makefile| 1 - examples/l2fwd-ivshmem/Makefile | 43 -- examples/l2fwd-ivshmem/guest/Makefile| 50 -- examples/l2fwd-ivshmem/guest/guest.c | 452 - examples/l2fwd-ivshmem/host/Makefile | 50 -- examples/l2fwd-ivshmem/host/host.c | 895 - examples/l2fwd-ivshmem/include/common.h | 111 examples/packet_ordering/Makefile| 2 +- lib/Makefile | 1 - lib/librte_eal/common/eal_common_memzone.c | 12 - lib/librte_eal/common/eal_private.h | 22 - lib/librte_eal/common/include/rte_memory.h | 3 - lib/librte_eal/common/include/rte_memzone.h | 7 +- lib/librte_eal/common/malloc_heap.c | 8 - lib/librte_eal/linuxapp/eal/Makefile | 9 - lib/librte_eal/linuxapp/eal/eal.c| 10 - lib/librte_eal/linuxapp/eal/eal_ivshmem.c| 954 --- lib/librte_eal/linuxapp/eal/eal_memory.c | 30 +- lib/librte_ivshmem/Makefile | 54 -- lib/librte_ivshmem/rte_ivshmem.c | 919 -- lib/librte_ivshmem/rte_ivshmem.h | 165 - lib/librte_ivshmem/rte_ivshmem_version.map | 12 - mk/rte.app.mk| 1 - 43 files changed, 13 insertions(+), 4537 deletions(-) delete mode 100644 app/test/test_ivshmem.c delete mode 100644 config/defconfig_x86_64-ivshmem-linuxapp-gcc delete mode 100644 config/defconfig_x86_64-ivshmem-linuxapp-icc delete mode 100644 doc/guides/prog_guide/img/ivshmem.png delete mode 100644 doc/guides/prog_guide/ivshmem_lib.rst delete mode 100644 examples/l2fwd-ivshmem/Makefile delete mode 100644 examples/l2fwd-ivshmem/guest/Makefile delete mode 100644 examples/l2fwd-ivshmem/guest/guest.c delete mode 100644 examples/l2fwd-ivshmem/host/Makefile delete mode 100644 examples/l2fwd-ivshmem/host/host.c delete mode 100644 examples/l2fwd-ivshmem/include/common.h delete mode 100644 lib/librte_eal/linuxapp/eal/eal_ivshmem.c delete mode 100644 lib/librte_ivshmem/Makefile delete mode 100644 lib/librte_ivshmem/rte_ivshmem.c delete mode 100644 lib/librte_ivshmem/rte_ivshmem.h delete mode 100644 lib/librte_ivshmem/rte_ivshmem_version.map diff --git a/MAINTAINERS b/MAINTAINERS index 6536c6b..5e3d825 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -546,14 +546,6 @@ F: app/test/test_cmdline* F: examples/cmdline/ F: doc/guides/sample_app_ug/cmd_line.rst -Qemu IVSHMEM -M: Anatoly Burakov -F: lib/librte_ivshmem/ -F: lib/librte_eal/linuxapp/eal/eal_ivshmem.c -F: doc/guides/prog_guide/ivshmem_lib.rst -F: app/test/test_ivshmem.c -F: examples/l2fwd-ivshmem/ - Key/Value parsing M: Olivier Matz F: lib/librte_kvargs/ diff --git a/app/test/Makefile b/app/test/Makefile index 49ea195..611d77a 100644 --- a/app/test/Makefile +++ b/app/test/Makefile @@ -167,7 +167,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_KNI) += test_kni.c SRCS-$(CONFIG_RTE_LIBRTE_POWER) += test_power.c test_power_acpi_cpufreq.c SRCS-$(CONFIG_RTE_LIBRTE_POWER) += test_power_kvm_vm.c SRCS-y += test_common.c -SRCS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += test_ivshmem.c SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += test_distributor.c SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += test_distr
[dpdk-dev] [PATCH] doc: announce API change for virtual device initialization
On Thu, Jul 28, 2016 at 5:47 PM, De Lara Guarch, Pablo wrote: >> This is a layer violation. >> EAL does not know a thing about "ports". >> >> This information should come from the crypto framework and so an api >> in crypto framework is the right place, not EAL. >> >> This is a NACK for me. > > Fair enough. So you mean to use rte_eth_dev_attach in ethdev library and > a similar function in cryptodev library? Yes, and/or wait that the rework in ethdev/eal hotplug has taken place and mirror this in crypto. -- David Marchand
[dpdk-dev] [PATCH] doc: announce API change for virtual device initialization
Hello Pablo, On Mon, Jul 4, 2016 at 4:50 PM, Pablo de Lara wrote: > In order to create a virtual device, user needs to call > rte_eal_vdev_init generally, but this function returns 0 > on success or negative number if error. Instead, something > more useful would be to return the port or device id of the > device created, so the user can call rte_eal_vdev_init > function and use the device straight away, using the id returned > by the function. > > Signed-off-by: Pablo de Lara > --- > doc/guides/rel_notes/deprecation.rst | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index f502f86..60cc7c7 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -41,3 +41,8 @@ Deprecation Notices > * The mempool functions for single/multi producer/consumer are deprecated and >will be removed in 16.11. >It is replaced by rte_mempool_generic_get/put functions. > + > +* The rte_eal_vdev_init function will be changed in 16.11 to return > + the port/device id of the device created, instead of 0, when it has been > + initialized successfully, so user can use the returned value straight away > + to call all the device functions that require that parameter. > -- > 2.5.0 > This is a layer violation. EAL does not know a thing about "ports". This information should come from the crypto framework and so an api in crypto framework is the right place, not EAL. This is a NACK for me. -- David Marchand
[dpdk-dev] [PATCH] doc: announce removal of Xen Dom0 support
On Thu, Jul 28, 2016 at 10:20 AM, Thomas Monjalon wrote: > There were some efforts to fix Xen Dom0 support in 16.07: > http://dpdk.org/ml/archives/dev/2016-July/043823.html > But there is still at least one bug: > http://dpdk.org/ml/archives/dev/2016-July/044207.html > And nobody cares: > http://dpdk.org/ml/archives/dev/2016-July/044376.html > > Signed-off-by: Thomas Monjalon Lots of cleanups for 16.11 :-) Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH] doc: announce ivshmem support removal
On Wed, Jul 20, 2016 at 6:35 PM, Thomas Monjalon wrote: > There was a prior call with an explanation of what needs to be done: > http://dpdk.org/ml/archives/dev/2016-June/040844.html > - Qemu patch upstreamed > - IVSHMEM PCI device managed by a PCI driver > - No DPDK objects (ring/mempool) allocated by EAL > > As nobody seems interested, it is time to remove this code which > makes EAL improvements harder. > > Signed-off-by: Thomas Monjalon Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH 2/2] app/test: filter out unavailable tests
On Wed, Jul 13, 2016 at 11:24 PM, Thomas Monjalon wrote: > Some tests can fail to run because they are not compiled. > It has been more visible recently when the PCI test became disabled > in the default configuration because of dependency on libarchive: > PCI autotest:Fail [Not found] > > The autotest script catch them and do not count them as an error anymore: > PCI autotest:Skipped [Not Available] > > The commands dump_ring and dump_mempool are removed from the autotest list > because they are some internal commands but not some registered tests. > Thus they cannot be parsed as available test commands. > > Signed-off-by: Thomas Monjalon Suggested-by: David Marchand and I trust you for the python ;-) -- David Marchand
[dpdk-dev] [PATCH v4 10/10] net/ena: remove unneeded PCI macro
I suppose this is a remnant of rte_pci_dev_ids.h, just remove this.
Signed-off-by: David Marchand
---
drivers/net/ena/ena_ethdev.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index f1b5e64..ac0803d 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -169,10 +169,9 @@ static const struct ena_stats ena_stats_ena_com_strings[]
= {
#define PCI_DEVICE_ID_ENA_LLQ_VF 0xEC21
static struct rte_pci_id pci_id_ena_map[] = {
-#define RTE_PCI_DEV_ID_DECL_ENA(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
- RTE_PCI_DEV_ID_DECL_ENA(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_VF)
- RTE_PCI_DEV_ID_DECL_ENA(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_LLQ_VF)
- {.device_id = 0},
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_LLQ_VF) },
+ { .device_id = 0 },
};
static int ena_device_init(struct ena_com_dev *ena_dev,
--
1.9.1
[dpdk-dev] [PATCH v4 09/10] net/bnxt: move PCI device ids to the driver
Moved defines since the driver had no such information.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/bnxt/bnxt_ethdev.c | 27 +---
lib/librte_eal/common/include/rte_pci_dev_ids.h | 34 -
2 files changed, 24 insertions(+), 37 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 9a2123e..3795fac 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -56,10 +56,31 @@
static const char bnxt_version[] =
"Broadcom Cumulus driver " DRV_MODULE_NAME "\n";
+#define PCI_VENDOR_ID_BROADCOM 0x14E4
+
+#define BROADCOM_DEV_ID_57301 0x16c8
+#define BROADCOM_DEV_ID_57302 0x16c9
+#define BROADCOM_DEV_ID_57304_PF 0x16ca
+#define BROADCOM_DEV_ID_57304_VF 0x16cb
+#define BROADCOM_DEV_ID_57402 0x16d0
+#define BROADCOM_DEV_ID_57404 0x16d1
+#define BROADCOM_DEV_ID_57406_PF 0x16d2
+#define BROADCOM_DEV_ID_57406_VF 0x16d3
+#define BROADCOM_DEV_ID_57406_MF 0x16d4
+#define BROADCOM_DEV_ID_57314 0x16df
+
static struct rte_pci_id bnxt_pci_id_map[] = {
-#define RTE_PCI_DEV_ID_DECL_BNXT(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
- {.device_id = 0},
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57301) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57302) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57304_PF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57304_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57402) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57404) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_PF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_MF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57314) },
+ { .vendor_id = 0, /* sentinel */ },
};
#define BNXT_ETH_RSS_SUPPORT ( \
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index fd2eb5d..6ec8ae8 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,20 +73,11 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_BNXT
-#define RTE_PCI_DEV_ID_DECL_BNXT(vend, dev)
-#endif
-
#ifndef PCI_VENDOR_ID_INTEL
/** Vendor ID used by Intel devices */
#define PCI_VENDOR_ID_INTEL 0x8086
#endif
-#ifndef PCI_VENDOR_ID_BROADCOM
-/** Vendor ID used by Broadcom devices */
-#define PCI_VENDOR_ID_BROADCOM 0x14E4
-#endif
-
/ Physical IGB devices from e1000_hw.h
/
#define E1000_DEV_ID_82576 0x10C9
@@ -326,30 +317,6 @@ RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_A_VF_HV)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV)
-/** Broadcom bnxt devices **/
-
-#define BROADCOM_DEV_ID_57301 0x16c8
-#define BROADCOM_DEV_ID_57302 0x16c9
-#define BROADCOM_DEV_ID_57304_PF 0x16ca
-#define BROADCOM_DEV_ID_57304_VF 0x16cb
-#define BROADCOM_DEV_ID_57402 0x16d0
-#define BROADCOM_DEV_ID_57404 0x16d1
-#define BROADCOM_DEV_ID_57406_PF 0x16d2
-#define BROADCOM_DEV_ID_57406_VF 0x16d3
-#define BROADCOM_DEV_ID_57406_MF 0x16d4
-#define BROADCOM_DEV_ID_57314 0x16df
-
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57301)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57302)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57304_PF)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57304_VF)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57402)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57404)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_PF)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_VF)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_MF)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57314)
-
/*
* Undef all RTE_PCI_DEV_ID_DECL_* here.
*/
@@ -357,4 +324,3 @@ RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM,
BROADCOM_DEV_ID_57314)
#undef RTE_PCI_DEV_ID_DECL_IGBVF
#undef RTE_PCI_DEV_ID_DECL_IXGBE
#undef RTE_PCI_DEV_ID_DECL_IXGBEVF
-#undef RTE_PCI_DEV_ID_DECL_BNXT
--
1.9.1
[dpdk-dev] [PATCH v4 08/10] net/bnx2x: move PCI device ids to the driver
Reused defines from the driver and moved broadcom vendor id macro.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/bnx2x/bnx2x.c | 3 +-
drivers/net/bnx2x/bnx2x_ethdev.c| 21 --
lib/librte_eal/common/include/rte_pci_dev_ids.h | 55 -
3 files changed, 18 insertions(+), 61 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 10859c1..95fbad8 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -22,7 +22,6 @@
#include "ecore_init_ops.h"
#include "rte_version.h"
-#include "rte_pci_dev_ids.h"
#include
#include
@@ -9572,7 +9571,7 @@ void bnx2x_load_firmware(struct bnx2x_softc *sc)
int f;
struct stat st;
- fwname = sc->devinfo.device_id == BNX2X_DEV_ID_57711
+ fwname = sc->devinfo.device_id == CHIP_NUM_57711
? FW_NAME_57711 : FW_NAME_57810;
f = open(fwname, O_RDONLY);
if (f < 0) {
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 84c9662..c8d2bf2 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -16,15 +16,28 @@
/*
* The set of PCI devices this driver supports
*/
+#define BROADCOM_PCI_VENDOR_ID 0x14E4
static struct rte_pci_id pci_id_bnx2x_map[] = {
-#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57800) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57711) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57810) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57811) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_OBS) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_4_10) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_2_20) },
+#ifdef RTE_LIBRTE_BNX2X_MF_SUPPORT
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57810_MF) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57811_MF) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_MF) },
+#endif
{ .vendor_id = 0, }
};
static struct rte_pci_id pci_id_bnx2xvf_map[] = {
-#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57800_VF) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57810_VF) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57811_VF) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_VF) },
{ .vendor_id = 0, }
};
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index ef85d08..fd2eb5d 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,14 +73,6 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_BNX2X
-#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_BNX2XVF
-#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_BNXT
#define RTE_PCI_DEV_ID_DECL_BNXT(vend, dev)
#endif
@@ -334,51 +326,6 @@ RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_A_VF_HV)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV)
-/** QLogic devices **/
-
-/* Broadcom/QLogic BNX2X */
-#define BNX2X_DEV_ID_57710 0x164e
-#define BNX2X_DEV_ID_57711 0x164f
-#define BNX2X_DEV_ID_57711E0x1650
-#define BNX2X_DEV_ID_57712 0x1662
-#define BNX2X_DEV_ID_57712_MF 0x1663
-#define BNX2X_DEV_ID_57712_VF 0x166f
-#define BNX2X_DEV_ID_57713 0x1651
-#define BNX2X_DEV_ID_57713E0x1652
-#define BNX2X_DEV_ID_57800 0x168a
-#define BNX2X_DEV_ID_57800_MF 0x16a5
-#define BNX2X_DEV_ID_57800_VF 0x16a9
-#define BNX2X_DEV_ID_57810 0x168e
-#define BNX2X_DEV_ID_57810_MF 0x16ae
-#define BNX2X_DEV_ID_57810_VF 0x16af
-#define BNX2X_DEV_ID_57811 0x163d
-#define BNX2X_DEV_ID_57811_MF 0x163e
-#define BNX2X_DEV_ID_57811_VF 0x163f
-
-#define BNX2X_DEV_ID_57840_OBS 0x168d
-#define BNX2X_DEV_ID_57840_OBS_MF 0x16ab
-#define BNX2X_DEV_ID_57840_4_100x16a1
-#define BNX2X_DEV_ID_57840_2_200x16a2
-#define BNX2X_DEV_ID_57840_MF 0x16a4
-#define BNX2X_DEV_ID_57840_VF 0x16ad
-
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800)
-RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800_VF)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57711)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID
[dpdk-dev] [PATCH v4 06/10] net/vmxnet3: move PCI device ids to the driver
Moved vmware device ids macro since the driver had no such information.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/vmxnet3/vmxnet3_ethdev.c| 9 -
lib/librte_eal/common/include/rte_pci_dev_ids.h | 16
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 8da4449..5874215 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -100,12 +100,11 @@ static void vmxnet3_process_events(struct vmxnet3_hw *);
/*
* The set of PCI devices this driver supports
*/
+#define VMWARE_PCI_VENDOR_ID 0x15AD
+#define VMWARE_DEV_ID_VMXNET3 0x07B0
static const struct rte_pci_id pci_id_vmxnet3_map[] = {
-
-#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(VMWARE_PCI_VENDOR_ID, VMWARE_DEV_ID_VMXNET3) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops vmxnet3_eth_dev_ops = {
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 1c66784..a4aba6d 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,10 +73,6 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_VMXNET3
-#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_ENIC
#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
#endif
@@ -98,11 +94,6 @@
#define PCI_VENDOR_ID_INTEL 0x8086
#endif
-#ifndef PCI_VENDOR_ID_VMWARE
-/** Vendor ID used by VMware devices */
-#define PCI_VENDOR_ID_VMWARE 0x15AD
-#endif
-
#ifndef PCI_VENDOR_ID_CISCO
/** Vendor ID used by Cisco VIC devices */
#define PCI_VENDOR_ID_CISCO 0x1137
@@ -352,12 +343,6 @@ RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_A_VF_HV)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV)
-/** VMware VMXNET3 devices **/
-
-#define VMWARE_DEV_ID_VMXNET3 0x07B0
-
-RTE_PCI_DEV_ID_DECL_VMXNET3(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3)
-
/** Cisco VIC devices **/
#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
@@ -444,5 +429,4 @@ RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM,
BROADCOM_DEV_ID_57314)
#undef RTE_PCI_DEV_ID_DECL_IGBVF
#undef RTE_PCI_DEV_ID_DECL_IXGBE
#undef RTE_PCI_DEV_ID_DECL_IXGBEVF
-#undef RTE_PCI_DEV_ID_DECL_VMXNET3
#undef RTE_PCI_DEV_ID_DECL_BNXT
--
1.9.1
[dpdk-dev] [PATCH v4 05/10] net/virtio: move PCI device ids to the driver
Reused defines from the driver.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
Acked-by: Yuanhan Liu
---
drivers/net/virtio/virtio_ethdev.c | 7 ++-
lib/librte_eal/common/include/rte_pci_dev_ids.h | 16
2 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 8467b3c..850e3ba 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -103,11 +103,8 @@ static int virtio_dev_queue_stats_mapping_set(
* The set of PCI devices this driver supports
*/
static const struct rte_pci_id pci_id_virtio_map[] = {
-
-#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(VIRTIO_PCI_VENDORID, VIRTIO_PCI_DEVICEID_MIN) },
+ { .vendor_id = 0, /* sentinel */ },
};
struct rte_virtio_xstats_name_off {
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 9e97d7c..1c66784 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,10 +73,6 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_VIRTIO
-#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_VMXNET3
#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
#endif
@@ -102,11 +98,6 @@
#define PCI_VENDOR_ID_INTEL 0x8086
#endif
-#ifndef PCI_VENDOR_ID_QUMRANET
-/** Vendor ID used by virtio devices */
-#define PCI_VENDOR_ID_QUMRANET 0x1AF4
-#endif
-
#ifndef PCI_VENDOR_ID_VMWARE
/** Vendor ID used by VMware devices */
#define PCI_VENDOR_ID_VMWARE 0x15AD
@@ -361,12 +352,6 @@ RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_A_VF_HV)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV)
-/** Virtio devices from virtio.h **/
-
-#define QUMRANET_DEV_ID_VIRTIO 0x1000
-
-RTE_PCI_DEV_ID_DECL_VIRTIO(PCI_VENDOR_ID_QUMRANET, QUMRANET_DEV_ID_VIRTIO)
-
/** VMware VMXNET3 devices **/
#define VMWARE_DEV_ID_VMXNET3 0x07B0
@@ -459,6 +444,5 @@ RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM,
BROADCOM_DEV_ID_57314)
#undef RTE_PCI_DEV_ID_DECL_IGBVF
#undef RTE_PCI_DEV_ID_DECL_IXGBE
#undef RTE_PCI_DEV_ID_DECL_IXGBEVF
-#undef RTE_PCI_DEV_ID_DECL_VIRTIO
#undef RTE_PCI_DEV_ID_DECL_VMXNET3
#undef RTE_PCI_DEV_ID_DECL_BNXT
--
1.9.1
[dpdk-dev] [PATCH v4 03/10] net/i40e: move PCI device ids to the driver
Reused defines from the driver.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
Changes since v3
- added new pci ids from HEAD
---
drivers/net/i40e/i40e_ethdev.c | 25 +++--
drivers/net/i40e/i40e_ethdev_vf.c | 9 ++--
lib/librte_eal/common/include/rte_pci_dev_ids.h | 70 -
3 files changed, 28 insertions(+), 76 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 31c2e11..daac236 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -454,9 +454,28 @@ static void i40e_set_default_mac_addr(struct rte_eth_dev
*dev,
static int i40e_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static const struct rte_pci_id pci_id_i40e_map[] = {
-#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_XL710) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QEMU) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_C) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_A) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_C) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2_A) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_SFP28) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_1G_BASE_T_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_I_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_I_X722) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops i40e_eth_dev_ops = {
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 31547db..a616ae0 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1110,9 +1110,12 @@ i40evf_get_link_status(struct rte_eth_dev *dev, struct
rte_eth_link *link)
}
static const struct rte_pci_id pci_id_i40evf_map[] = {
-#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF_HV) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF_HV) },
+ { .vendor_id = 0, /* sentinel */ },
};
static inline int
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 1b22adb..30fcdee 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,14 +73,6 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_I40E
-#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_I40EVF
-#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_VIRTIO
#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev)
#endif
@@ -341,52 +333,6 @@ RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_X_KR)
RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_82599_BYPASS)
#endif
-/*** Physical I40E devices from i40e_type.h */
-
-#define I40E_DEV_ID_SFP_XL710 0x1572
-#define I40E_DEV_ID_QEMU0x1574
-#define I40E_DEV_ID_KX_B0x1580
-#define I40E_DEV_ID_KX_C0x1581
-#define I40E_DEV_ID_QSFP_A 0x1583
-#define I40E_DEV_ID_QSFP_B 0x1584
-#define I40E_DEV_ID_QSFP_C 0x1585
-#define I40E_DEV_ID_10G_BASE_T 0x1586
-#define I40E_DEV_ID_20G_KR2 0x1587
-#define I40E_DEV_ID_20G_KR2_A 0x1588
-#define I40E_DEV_ID_10G_BASE_T4 0x1589
-#define I40E_DEV_ID_25G_B 0x158A
-#define I40E_DEV_ID_25G_SFP28
[dpdk-dev] [PATCH v4 02/10] net/e1000: move em PCI device ids to the driver
Reused defines from the driver and added a Intel vendor id macro for use by
igb later.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
igb/igbvf is left as is, waiting for kni/ethtool cleanup.
Signed-off-by: David Marchand
---
Changes since v3:
- dropped all but em pci device ids
---
drivers/net/e1000/e1000_ethdev.h| 2 +
drivers/net/e1000/em_ethdev.c | 37 +-
lib/librte_eal/common/include/rte_pci_dev_ids.h | 148
3 files changed, 34 insertions(+), 153 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethdev.h b/drivers/net/e1000/e1000_ethdev.h
index e8bf8da..6c25c8d 100644
--- a/drivers/net/e1000/e1000_ethdev.h
+++ b/drivers/net/e1000/e1000_ethdev.h
@@ -35,6 +35,8 @@
#define _E1000_ETHDEV_H_
#include
+#define E1000_INTEL_VENDOR_ID 0x8086
+
/* need update link, bit flag */
#define E1000_FLAG_NEED_LINK_UPDATE (uint32_t)(1 << 0)
#define E1000_FLAG_MAILBOX (uint32_t)(1 << 1)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 4de5eb2..ad104ed 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -137,11 +137,38 @@ static enum e1000_fc_mode em_fc_setting = e1000_fc_full;
* The set of PCI devices this driver supports
*/
static const struct rte_pci_id pci_id_em_map[] = {
-
-#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-
-{0},
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82540EM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82545EM_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82545EM_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546EB_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546EB_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82546EB_QUAD_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82571EB_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82571EB_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82571EB_SERDES) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571EB_SERDES_DUAL) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571EB_SERDES_QUAD) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571EB_QUAD_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571PT_QUAD_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571EB_QUAD_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571EB_QUAD_COPPER_LP) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82572EI_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82572EI_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82572EI_SERDES) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82572EI) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82573L) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82574L) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82574LA) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82583V) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_LPT_I217_LM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_LPT_I217_V) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_LPTLP_I218_LM)
},
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_LPTLP_I218_V)
},
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_I218_LM2) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_I218_V2) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_I218_LM3) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_I218_V3) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops eth_em_ops = {
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index ecb877c..1b22adb 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -57,10 +57,6 @@
*
*/
-#ifndef RTE_PCI_DEV_ID_DECL_EM
-#define RTE_PCI_DEV_ID_DECL_EM(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_IGB
#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev)
#endif
@@ -142,149 +138,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/ Physical EM devices from e1000_hw.h /
-
-#define E1000_DEV_ID_825420x1000
-#define E1000_DEV_ID_82543GC_FIBER0x1001
-#define E1000_DEV_ID_82543GC_COPPER 0x1004
-#define E1000_DEV_ID_82544EI_COPPER 0x1008
-#define E1000_DEV_ID_82544EI_FIBER0x1009
-#define E1000_DEV_ID_82544GC_COPPER 0x100C
-#define E1
[dpdk-dev] [PATCH v4 01/10] eal: remove PCI device ids header from doxygen
This file is going to disappear, remove the doxygen parts that reference
various drivers and remove it from the doxygen index.
Signed-off-by: David Marchand
---
doc/api/doxy-api-index.md | 1 -
lib/librte_eal/common/include/rte_pci_dev_ids.h | 40 -
2 files changed, 41 deletions(-)
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 5e7f024..2284a53 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -45,7 +45,6 @@ There are many libraries, so their headers may be grouped by
topics:
[vhost] (@ref rte_virtio_net.h),
[KNI](@ref rte_kni.h),
[PCI](@ref rte_pci.h),
- [PCI IDs](@ref rte_pci_dev_ids.h)
- **memory**:
[memseg] (@ref rte_memory.h),
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index af39fbb..ecb877c 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -57,46 +57,6 @@
*
*/
-/**
- * @file
- *
- * This file contains a list of the PCI device IDs recognised by DPDK, which
- * can be used to fill out an array of structures describing the devices.
- *
- * Currently five families of devices are recognised: those supported by the
- * IGB driver, by EM driver, those supported by the IXGBE driver, those
- * supported by the BNXT driver, and by virtio driver which is a para
- * virtualization driver running in guest virtual machine. The inclusion of
- * these in an array built using this file depends on the definition of
- * RTE_PCI_DEV_ID_DECL_BNXT
- * RTE_PCI_DEV_ID_DECL_EM
- * RTE_PCI_DEV_ID_DECL_IGB
- * RTE_PCI_DEV_ID_DECL_IGBVF
- * RTE_PCI_DEV_ID_DECL_IXGBE
- * RTE_PCI_DEV_ID_DECL_IXGBEVF
- * RTE_PCI_DEV_ID_DECL_I40E
- * RTE_PCI_DEV_ID_DECL_I40EVF
- * RTE_PCI_DEV_ID_DECL_VIRTIO
- * at the time when this file is included.
- *
- * In order to populate an array, the user of this file must define this macro:
- * RTE_PCI_DEV_ID_DECL_IXGBE(vendorID, deviceID). For example:
- *
- * @code
- * struct device {
- * int vend;
- * int dev;
- * };
- *
- * struct device devices[] = {
- * #define RTE_PCI_DEV_ID_DECL_IXGBE(vendorID, deviceID) {vend, dev},
- * #include
- * };
- * @endcode
- *
- * Note that this file can be included multiple times within the same file.
- */
-
#ifndef RTE_PCI_DEV_ID_DECL_EM
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev)
#endif
--
1.9.1
[dpdk-dev] [PATCH v4 00/10] kill global pci device id list (almost)
With the introduction of pmdinfo by Neil, we have almost everything in place
to get rid of the pci devices in eal.
We still have some ties with some pmds for functionalities like kni/ethtool or
ixgbe bypass api, so the plan has switched to touch all pmds but those igb and
ixgbe drivers.
Since we still need rte_pci_dev_ids.h for those drivers, I just stripped the
doxygen parts to stop referencing it in the documentation.
I have validated this patchset by comparing the pmdinfo outputs and just
noticed a difference for enic (where the pci ids were registered twice
before).
Yet, please maintainers review carefully.
Thanks.
Changes since v3:
- dropped my approach at extracting informations from binaries
- let igb{,vf} and ixgbe{,vf} untouched
- rebased on HEAD
- added bnxt
Changes since v2:
- rebased on HEAD
- ena driver has been aligned
- this patchset now depends on [1] as it avoids touching all drivers this way
- not storing the pci ids in a dedicated section anymore, pci drivers are
exported and parsed by a quickly written (and naive) tool
Changes since v1:
- indent fixes in i40e, fm10k, virtio, vmxnet3, enic, bnx2x.
- rebased on head (ixgbe update)
- removed doc update (will be sent separately)
[1]: http://dpdk.org/ml/archives/dev/2016-April/037686.html
--
David Marchand
David Marchand (10):
eal: remove PCI device ids header from doxygen
net/e1000: move em PCI device ids to the driver
net/i40e: move PCI device ids to the driver
net/fm10k: move PCI device ids to the driver
net/virtio: move PCI device ids to the driver
net/vmxnet3: move PCI device ids to the driver
net/enic: move PCI device ids to the driver
net/bnx2x: move PCI device ids to the driver
net/bnxt: move PCI device ids to the driver
net/ena: remove unneeded pci macro
doc/api/doxy-api-index.md | 1 -
drivers/net/bnx2x/bnx2x.c | 3 +-
drivers/net/bnx2x/bnx2x_ethdev.c| 21 +-
drivers/net/bnxt/bnxt_ethdev.c | 27 +-
drivers/net/e1000/e1000_ethdev.h| 2 +
drivers/net/e1000/em_ethdev.c | 37 ++-
drivers/net/ena/ena_ethdev.c| 7 +-
drivers/net/enic/enic_ethdev.c | 12 +-
drivers/net/fm10k/fm10k_ethdev.c| 6 +-
drivers/net/i40e/i40e_ethdev.c | 25 +-
drivers/net/i40e/i40e_ethdev_vf.c | 9 +-
drivers/net/virtio/virtio_ethdev.c | 7 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c| 9 +-
lib/librte_eal/common/include/rte_pci_dev_ids.h | 420
14 files changed, 120 insertions(+), 466 deletions(-)
--
1.9.1
[dpdk-dev] Ignoring number of bytes read in eal
Hello, On Tue, Jun 28, 2016 at 10:40 AM, Kobylinski, MichalX wrote: > CID 13212 - Ignoring number of bytes read: > The number of bytes copied into the buffer can be smaller than the requested > number and the buffer can potentially be accessed out of range. > In rte_mem_virt2phy: Value returned from a function and indicating the number > of bytes read is ignored. > > File: /lib/librte_eal/linuxapp/eal/eal_memory.c > Line: 187 > > Can I mark this error as "False Positive"? > > Because return from read function is checked in "if" condition. If return > from read is less than 0 function rte_mem_virt2phy is aborted and return: log > message, RTE_BAD_PHYS_ADDR. ? Coverity is complaining because (in theory) read can return less than sizeof(uint64_t). This most likely can't happen, but still coverity is right from my pov. I'd rather fix this than mark this as false positive, Sergio ? -- David Marchand
[dpdk-dev] [PATCH 09/11] eal: move PCI table macro
Hello Thomas, Neil, (will be back in a couple of days, thanks Thomas for pointing this thread) On Thu, Jul 7, 2016 at 6:25 PM, Thomas Monjalon wrote: > 2016-07-07 12:11, Neil Horman: >> On Thu, Jul 07, 2016 at 05:36:28PM +0200, Thomas Monjalon wrote: >> > Remove include of rte_pci.h in the generic header rte_dev.h >> > and move the macro DRIVER_REGISTER_PCI_TABLE in rte_pci.h. > [...] >> >> This seems strange to me, in that its odd for the driver information export >> macros to be spread out in multiple locations. Specifically it enjoins the >> use >> of the DRV_EXP_TAG macro, which helps centralize tag naming. Perhaps the >> happy >> medium is to place all the export macros (includnig PMD_REGISTER_DRIVER) into >> its own pmd_register.h header? > > I don't know. > David, your opinion? - The suggestion I did offline to Thomas was to move pci stuff in pci headers. We are trying to move from the "all pci" code in eal to accomodate for other "buses" / architectures. Having a pci macro in a generic header like rte_dev.h is wrong to me. Moving this to a new header like pmd_register.h sounds like a new generic header with pci specific stuff in it. So, I am not sure I follow you Neil. Can you elaborate ? - Why do you want to centralise the tag naming ? To avoid collisions ? Well, adding those tags should not happen that often and I think we can maintain this with careful reviews. -- David Marchand
[dpdk-dev] [PATCH v2] eal: fix thread naming on FreeBSD
On Fri, Jun 17, 2016 at 6:02 PM, Thomas Monjalon
wrote:
> rte_thread_setname was a macro defined only for Linux.
> The function rte_thread_setname() can now be used on FreeBSD
> as well on Linux.
> It is required to build librte_pdump.
>
> The macro was 0 for old glibc. The function is now returning -1.
> The related logs are decreased from error to debug level because
> it is not an important failure, just a debug inconvenience.
>
> Fixes: 278f945402c5 ("pdump: add new library for packet capture")
>
> Signed-off-by: Thomas Monjalon
Acked-by: David Marchand
--
David Marchand
[dpdk-dev] [PATCH] eal: fix thread naming on FreeBSD
On Fri, Jun 17, 2016 at 5:25 PM, Thomas Monjalon
wrote:
> rte_thread_setname was a macro defined only for Linux.
> The function rte_thread_setname() can now be used on FreeBSD
> as well on Linux.
> It is required to build librte_pdump.
>
> The macro was 0 for old glibc. The function is now returning -1.
> The related logs are decreased from error to debug level because
> it is not an important failure, just a debug inconvenience.
>
> Fixes: 278f945402c5 ("pdump: add new library for packet capture")
>
> Signed-off-by: Thomas Monjalon
[snip]
> diff --git a/lib/librte_eal/common/include/rte_lcore.h
> b/lib/librte_eal/common/include/rte_lcore.h
> index ac15130..1dcfba7 100644
> --- a/lib/librte_eal/common/include/rte_lcore.h
> +++ b/lib/librte_eal/common/include/rte_lcore.h
> @@ -250,23 +250,16 @@ void rte_thread_get_affinity(rte_cpuset_t *cpusetp);
> /**
> * Set thread names.
> *
> - * Macro to wrap `pthread_setname_np()` with a glibc version check.
> - * Only glibc >= 2.12 supports this feature.
> + * @note Only glibc >= 2.12 supports this feature.
This comment is a bit weird since, this only applies to Linux and not
BSD, right ?
The rest looks good to me.
--
David Marchand
[dpdk-dev] [PATCH v2] eal: Fix resource leak while secondary process maps pci devices
On Thu, Jun 16, 2016 at 4:33 AM, Tetsuya Mukawa wrote: > This patch fixes resource leak of pci_uio_map_secondary(). > If pci_map_resource() succeeds but mapped address is different from an > address primary process mapped, this should be error. > Then the addresses secondary process mapped should be freed. > > Signed-off-by: Tetsuya Mukawa scripts/check-git-log.sh is not happy : Wrong headline uppercase: eal: Fix resource leak while secondary process maps pci devices Wrong headline lowercase: eal: Fix resource leak while secondary process maps pci devices Headline too long: eal: Fix resource leak while secondary process maps pci devices Missing 'Fixes' tag: eal: Fix resource leak while secondary process maps pci devices checkpatch is not happy, but I think we can ignore it. WARNING:LONG_LINE: line over 80 characters #48: FILE: lib/librte_eal/common/eal_common_pci_uio.c:93: +(size_t)uio_res->maps[j].size); Anyways, looks good to me, Thomas, can you fix the commit logs of those last 3 patches on eal ? Thanks. -- David Marchand
[dpdk-dev] [PATCH v2] eal: Fix wrong resource release while unmapping pci devices
On Thu, Jun 16, 2016 at 4:33 AM, Tetsuya Mukawa wrote: > This patch fixes wrong resource release of pci_uio_unmap(). > The 'path' member of mapped_pci_resource structure is allocated by > primary process, but currently it will be freed by both primary > and secondary process. > The patch fixes to be freed by only primary process. > > Signed-off-by: Tetsuya Mukawa Wrong headline uppercase: eal: Fix wrong resource release while unmapping pci devices Wrong headline lowercase: eal: Fix wrong resource release while unmapping pci devices Missing 'Fixes' tag: eal: Fix wrong resource release while unmapping pci devices Then you can add my ack. -- David Marchand
[dpdk-dev] [PATCH v2] eal: Fix wrong error checking while parsing device arguments
On Thu, Jun 16, 2016 at 4:33 AM, Tetsuya Mukawa wrote:
> This patch fixes wrong error checking of rte_eal_parse_devargs_str().
> Currently, a return value of strdup() is wrongly checked.
>
> Fixes: 0fe11ec592b2 ("eal: add vdev init and uninit")
> Signed-off-by: Tetsuya Mukawa
Forgot to pass this patch through scripts/check-git-log.sh script :
Wrong headline uppercase:
eal: Fix wrong error checking while parsing device arguments
With this fixed, you can add my ack.
--
David Marchand
[dpdk-dev] [PATCH] eal: Fix wrong resource release of pci_uio_unmap()
On Wed, Jun 15, 2016 at 5:27 AM, Tetsuya Mukawa wrote:
> The 'path' member of mapped_pci_resource structure is allocated by
> primary process, but currenctly it will be freed by both primary
> and secondary process.
> The patch fixes to be freed by only primary process.
>
> Signed-off-by: Tetsuya Mukawa
Function name in title.
> ---
> lib/librte_eal/common/eal_common_pci_uio.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/eal_common_pci_uio.c
> b/lib/librte_eal/common/eal_common_pci_uio.c
> index e718643..b2c68f3 100644
> --- a/lib/librte_eal/common/eal_common_pci_uio.c
> +++ b/lib/librte_eal/common/eal_common_pci_uio.c
> @@ -162,7 +162,9 @@ pci_uio_unmap(struct mapped_pci_resource *uio_res)
> for (i = 0; i != uio_res->nb_maps; i++) {
> pci_unmap_resource(uio_res->maps[i].addr,
> (size_t)uio_res->maps[i].size);
> - rte_free(uio_res->maps[i].path);
> +
> + if (rte_eal_process_type() == RTE_PROC_PRIMARY)
> + rte_free(uio_res->maps[i].path);
> }
> }
>
The rest looks good to me.
--
David Marchand
[dpdk-dev] [PATCH] eal: Fix wrong error checking of rte_eal_parse_devargs_str()
On Wed, Jun 15, 2016 at 5:26 AM, Tetsuya Mukawa wrote:
> Currently, a return value of strdup() isn't checked correctly.
> The patch fixes it.
>
> Signed-off-by: Tetsuya Mukawa
Idem, the title does not need the function name to describe what is going wrong.
This might deserve a fixline, I traced this to 0fe11ec592b2 ("eal: add
vdev init and uninit").
> ---
> lib/librte_eal/common/eal_common_devargs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/eal_common_devargs.c
> b/lib/librte_eal/common/eal_common_devargs.c
> index 2bfe54a..e403717 100644
> --- a/lib/librte_eal/common/eal_common_devargs.c
> +++ b/lib/librte_eal/common/eal_common_devargs.c
> @@ -58,7 +58,7 @@ rte_eal_parse_devargs_str(const char *devargs_str,
> return -1;
>
> *drvname = strdup(devargs_str);
> - if (drvname == NULL)
> + if (*drvname == NULL)
> return -1;
>
> /* set the first ',' to '\0' to split name and arguments */
> --
> 2.7.4
>
--
David Marchand
[dpdk-dev] [PATCH] eal: Fix resource leak of pci_uio_map_secondary()
Hello Tetsuya, On Wed, Jun 15, 2016 at 5:26 AM, Tetsuya Mukawa wrote: > If pci_map_resource() succeeds but mapped address is different from an > address primary process mapped, this should be error. > Then the address secondary process mapped should be freed. > > Signed-off-by: Tetsuya Mukawa The title should not contain the function name. > --- > lib/librte_eal/common/eal_common_pci_uio.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/lib/librte_eal/common/eal_common_pci_uio.c > b/lib/librte_eal/common/eal_common_pci_uio.c > index f062e81..e718643 100644 > --- a/lib/librte_eal/common/eal_common_pci_uio.c > +++ b/lib/librte_eal/common/eal_common_pci_uio.c > @@ -85,6 +85,9 @@ pci_uio_map_secondary(struct rte_pci_device *dev) > "Cannot mmap device resource file %s > to address: %p\n", > uio_res->maps[i].path, > uio_res->maps[i].addr); > + if (mapaddr != MAP_FAILED) > + pci_unmap_resource(mapaddr, > + > (size_t)uio_res->maps[i].size); > return -1; > } > } What of the previous mappings that might have succeeded earlier in this loop ? -- David Marchand
[dpdk-dev] [PATCH v2] eal: remove useless includes of mempool and ring
On Fri, Jun 10, 2016 at 12:19 AM, Thomas Monjalon wrote: > The libraries rte_mempool and rte_ring are not used in EAL, > except for the ivshmem part (CONFIG_RTE_LIBRTE_IVSHMEM). > > Signed-off-by: Thomas Monjalon Thanks Thomas. Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH v3] log: deprecate history dump
On Fri, Jun 10, 2016 at 12:10 AM, Thomas Monjalon wrote: > The log history uses rte_mempool. In order to remove the mempool > dependency in EAL (and improve the build), this feature is deprecated. > The ABI is kept but the behaviour is now voided because it seems this > function was not used. The history can be read from syslog. > > Signed-off-by: Thomas Monjalon Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH] log: deprecate history dump
(rte_mempool_mc_get(log_history_mp, ) < 0)
> - obj = NULL;
> - hist_buf = obj;
> - }
> -
> - /* no buffer */
> - if (hist_buf == NULL) {
> - rte_spinlock_unlock(_list_lock);
> - return -ENOBUFS;
> - }
> -
> - /* not enough room for msg, buffer go back in mempool */
> - if (size >= hist_buf_size) {
> - rte_mempool_mp_put(log_history_mp, hist_buf);
> - rte_spinlock_unlock(_list_lock);
> - return -ENOBUFS;
> - }
> -
> - /* add in history */
> - memcpy(hist_buf->buf, buf, size);
> - hist_buf->buf[size] = hist_buf->buf[hist_buf_size-1] = '\0';
> - hist_buf->size = size;
> - STAILQ_INSERT_TAIL(_history, hist_buf, next);
> - log_history_size++;
> - rte_spinlock_unlock(_list_lock);
> -
> return 0;
> }
>
> void
> -rte_log_set_history(int enable)
> +rte_log_set_history(int enable __rte_unused)
> {
> - history_enabled = enable;
> }
Maybe a warning here for the people who did not read the deprecation notices ?
--
David Marchand
[dpdk-dev] [PATCH] eal: add option --avail-cores to detect lcores
Hello Jianfeng, On Wed, Mar 9, 2016 at 2:05 PM, Panu Matilainen wrote: > On 03/08/2016 07:38 PM, Tan, Jianfeng wrote: >> >> Hi Panu, >> >> On 3/8/2016 4:54 PM, Panu Matilainen wrote: >>> >>> On 03/04/2016 12:05 PM, Jianfeng Tan wrote: >>>> >>>> This patch adds option, --avail-cores, to use lcores which are available >>>> by calling pthread_getaffinity_np() to narrow down detected cores before >>>> parsing coremask (-c), corelist (-l), and coremap (--lcores). >>>> >>>> Test example: >>>> $ taskset 0xc ./examples/helloworld/build/helloworld \ >>>> --avail-cores -m 1024 >>>> >>>> Signed-off-by: Jianfeng Tan >>>> Acked-by: Neil Horman >>> >>> >>> Hmm, to me this sounds like something that should be done always so >>> there's no need for an option. Or if there's a chance it might do the >>> wrong thing in some rare circumstance then perhaps there should be a >>> disabler option instead? >> >> >> Thanks for comments. >> >> Yes, there's a use case that we cannot handle. >> >> If we make it as default, DPDK applications may fail to start, when user >> specifies a core in isolcpus and its parent process (say bash) has a >> cpuset affinity that excludes isolcpus. Originally, DPDK applications >> just blindly do pthread_setaffinity_np() and it always succeeds because >> it always has root privilege to change any cpu affinity. >> >> Now, if we do the checking in rte_eal_cpu_init(), those lcores will be >> flagged as undetected (in my older implementation) and leads to failure. >> To make it correct, we would always add "taskset mask" (or other ways) >> before DPDK application cmd lines. >> >> How do you think? > > > I still think it sounds like something that should be done by default and > maybe be overridable with some flag, rather than the other way around. > Another alternative might be detecting the cores always but if running as > root, override but with a warning. > > But I dont know, just wondering. To look at it from another angle: why would > somebody use this new --avail-cores option and in what situation, if things > "just work" otherwise anyway? +1 and I don't even see why we should have an option to disable this, since taskset would do the job. Looking at your special case, if the user did set an isolcpus option for another use, with no -c/-l, I understand the dpdk application won't care too much about it. So, this seems like somehow rude to the rest of the system and unwanted. We can still help the user starting its application as root (without taskset) by adding a warning message if a requested cpu (-c / -l ..) is not part of the available cpus. -- David Marchand
[dpdk-dev] [PATCH v4] eal: make hugetlb initialization more robust
On Wed, May 18, 2016 at 10:06 AM, Sergio Gonzalez Monroy wrote: > On 17/05/2016 17:40, Thomas Monjalon wrote: >> >> 2016-05-12 00:44, Jianfeng Tan: >>> >>> This patch adds an option, --huge-trybest, to use a recover mechanism to >>> the case that there are not so many hugepages (declared in sysfs), which >>> can be used. It relys on a mem access to fault-in hugepages, and if fails >> >> relys -> relies >> >>> with SIGBUS, recover to previously saved stack environment with >>> siglongjmp(). >>> >>> Besides, this solution fixes an issue when hugetlbfs is specified with an >>> option of size. Currently DPDK does not respect the quota of a hugetblfs >>> mount. It fails to init the EAL because it tries to map the number of >>> free >>> hugepages in the system rather than using the number specified in the >>> quota >>> for that mount. >> >> It looks to be a bug. Why adding an option? >> What is the benefit of the old behaviour, not using --try-best? > > > I do not see any benefit to the old behavior. > Given that we need the signal handling for the cgroup use case, I would be > inclined to use > this method as the default instead of trying to figure out how many > hugepages we have free, etc. +1 -- David Marchand
[dpdk-dev] [PATCH v4] eal: make hugetlb initialization more robust
Hello Sergio,
On Wed, May 18, 2016 at 9:56 AM, Sergio Gonzalez Monroy
wrote:
> On 17/05/2016 17:39, David Marchand wrote:
>>> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
>>> b/lib/librte_eal/linuxapp/eal/eal_memory.c
>>> index 5b9132c..8c77010 100644
>>> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
>>> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
>>> @@ -417,12 +434,33 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
>>> hugepg_tbl[i].final_va = virtaddr;
>>> }
>>>
>>> + if (orig && internal_config.huge_trybest) {
>>> + /* In linux, hugetlb limitations, like cgroup,
>>> are
>>> +* enforced at fault time instead of mmap(), even
>>> +* with the option of MAP_POPULATE. Kernel will
>>> send
>>> +* a SIGBUS signal. To avoid to be killed, save
>>> stack
>>> +* environment here, if SIGBUS happens, we can
>>> jump
>>> +* back here.
>>> +*/
>>> + if (wrap_sigsetjmp()) {
>>> + RTE_LOG(DEBUG, EAL, "SIGBUS: Cannot mmap
>>> more "
>>> + "hugepages of size %u MB\n",
>>> + (unsigned)(hugepage_sz /
>>> 0x10));
>>> + munmap(virtaddr, hugepage_sz);
>>> + close(fd);
>>> + unlink(hugepg_tbl[i].filepath);
>>> + return i;
>>> + }
>>> + *(int *)virtaddr = 0;
>>> + }
>>> +
>>> +
>>> /* set shared flock on the file. */
>>> if (flock(fd, LOCK_SH | LOCK_NB) == -1) {
>>> - RTE_LOG(ERR, EAL, "%s(): Locking file failed:%s
>>> \n",
>>> + RTE_LOG(DEBUG, EAL, "%s(): Locking file failed:%s
>>> \n",
>>> __func__, strerror(errno));
>>> close(fd);
>>> - return -1;
>>> + return i;
>>> }
>>>
>>> close(fd);
>>
>> Maybe I missed something, but we are writing into some hugepage before
>> the flock has been called.
>> Are we sure there is nobody else using this hugepage ?
>>
>> Especially, can't this cause trouble to a primary process running if
>> we start the exact same primary process ?
>>
>
> We lock the hugepage directory during eal_hugepage_info_init(), and we do
> not unlock
> until we have finished eal_memory_init.
>
> I think that takes care of that case.
Yes, thanks.
--
David Marchand
[dpdk-dev] [PATCH v4] eal: make hugetlb initialization more robust
Hello Jianfeng,
On Thu, May 12, 2016 at 2:44 AM, Jianfeng Tan wrote:
> This patch adds an option, --huge-trybest, to use a recover mechanism to
> the case that there are not so many hugepages (declared in sysfs), which
> can be used. It relys on a mem access to fault-in hugepages, and if fails
> with SIGBUS, recover to previously saved stack environment with
> siglongjmp().
>
> Besides, this solution fixes an issue when hugetlbfs is specified with an
> option of size. Currently DPDK does not respect the quota of a hugetblfs
> mount. It fails to init the EAL because it tries to map the number of free
> hugepages in the system rather than using the number specified in the quota
> for that mount.
>
> It's still an open issue with CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS. Under
> this case (such as IVSHMEM target), having hugetlbfs mounts with quota will
> fail to remap hugepages as it relies on having mapped all free hugepages
> in the system.
For such a case case, maybe having some warning log message when it
fails would help the user.
+ a known issue in the release notes ?
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> b/lib/librte_eal/linuxapp/eal/eal_memory.c
> index 5b9132c..8c77010 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -417,12 +434,33 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
> hugepg_tbl[i].final_va = virtaddr;
> }
>
> + if (orig && internal_config.huge_trybest) {
> + /* In linux, hugetlb limitations, like cgroup, are
> +* enforced at fault time instead of mmap(), even
> +* with the option of MAP_POPULATE. Kernel will send
> +* a SIGBUS signal. To avoid to be killed, save stack
> +* environment here, if SIGBUS happens, we can jump
> +* back here.
> +*/
> + if (wrap_sigsetjmp()) {
> + RTE_LOG(DEBUG, EAL, "SIGBUS: Cannot mmap more
> "
> + "hugepages of size %u MB\n",
> + (unsigned)(hugepage_sz / 0x10));
> + munmap(virtaddr, hugepage_sz);
> + close(fd);
> + unlink(hugepg_tbl[i].filepath);
> + return i;
> + }
> + *(int *)virtaddr = 0;
> + }
> +
> +
> /* set shared flock on the file. */
> if (flock(fd, LOCK_SH | LOCK_NB) == -1) {
> - RTE_LOG(ERR, EAL, "%s(): Locking file failed:%s \n",
> + RTE_LOG(DEBUG, EAL, "%s(): Locking file failed:%s \n",
> __func__, strerror(errno));
> close(fd);
> - return -1;
> + return i;
> }
>
> close(fd);
Maybe I missed something, but we are writing into some hugepage before
the flock has been called.
Are we sure there is nobody else using this hugepage ?
Especially, can't this cause trouble to a primary process running if
we start the exact same primary process ?
--
David Marchand
[dpdk-dev] [PATCH] eal: fix log level/type retrieving on a standard pthread
On Mon, May 9, 2016 at 6:13 PM, Olivier Matz wrote: > From: Maxime Leroy > > The functions rte_log_cur_msg_loglevel() and rte_log_cur_msg_logtype() > return the current log level/type for the message being processed. They > are used when implementing a user-defined logging stream. > > The current log levels and types were stored in a table indexed by the > lcore_id, only returning a valid value for dataplane threads. Setting > and getting these values in a non dataplane thread was ignored, using > the global value instead. > > To fix this issue, a per-thread variable could be used (with > RTE_DEFINE_PER_LCORE), allowing any pthread to set and retrieve its > current log level or type. > > Signed-off-by: Maxime Leroy > Signed-off-by: Olivier Matz Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH v2 5/7] eal/linux: mmap ioports on ppc64
Hello Olivier,
On Tue, May 17, 2016 at 11:59 AM, Olivier Matz
wrote:
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> index ac449c5..077ad96 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> @@ -411,81 +412,153 @@ pci_uio_ioport_map(struct rte_pci_device *dev, int bar,
> RTE_LOG(DEBUG, EAL, "PCI Port IO found start=0x%lx\n", start);
>
> p->base = start;
> + p->len = 0;
> return 0;
> +}
> #else
> - RTE_SET_USED(dev);
> - RTE_SET_USED(bar);
> - RTE_SET_USED(p);
> +int
> +pci_uio_ioport_map(struct rte_pci_device *dev, int bar,
> + struct rte_pci_ioport *p)
> +{
> + FILE *f;
> + char buf[BUFSIZ];
> + char filename[PATH_MAX];
> + uint64_t phys_addr, end_addr, flags;
> + int fd, i;
> + void *addr;
> +
> + /* open and read addresses of the corresponding resource in sysfs */
> + snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT "/resource",
> + SYSFS_PCI_DEVICES, dev->addr.domain, dev->addr.bus,
> +dev->addr.devid, dev->addr.function);
> + f = fopen(filename, "r");
> + if (f == NULL) {
> + RTE_LOG(ERR, EAL, "Cannot open sysfs resource: %s\n",
> + strerror(errno));
> + return -1;
> + }
> + for (i = 0; i < bar + 1; i++) {
> + if (fgets(buf, sizeof(buf), f) == NULL) {
> + RTE_LOG(ERR, EAL, "Cannot read sysfs resource\n");
> + goto error;
> + }
> + }
> + if (pci_parse_one_sysfs_resource(buf, sizeof(buf), _addr,
> + _addr, ) < 0)
> + goto error;
> + if ((flags & IORESOURCE_IO) == 0) {
> + RTE_LOG(ERR, EAL, "BAR %d is not an IO resource\n", bar);
> + goto error;
> + }
> + snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT "/resource%d",
> + SYSFS_PCI_DEVICES, dev->addr.domain, dev->addr.bus,
> +dev->addr.devid, dev->addr.function, bar);
> +
> + /* mmap the pci resource */
> + fd = open(filename, O_RDWR);
> + if (fd < 0) {
> + RTE_LOG(ERR, EAL, "Cannot open %s: %s\n", filename,
> + strerror(errno));
> + goto error;
> + }
> + addr = mmap(NULL, end_addr + 1, PROT_READ | PROT_WRITE,
> + MAP_SHARED, fd, 0);
Sorry, did not catch it in v1, but a close(fd) is missing here.
With this, I think the patchset looks good.
Just missing some opinion from the virtio maintainers ?
> + if (addr == MAP_FAILED) {
> + RTE_LOG(ERR, EAL, "Cannot mmap IO port resource: %s\n",
> + strerror(errno));
> + goto error;
> + }
> +
> + /* strangely, the base address is mmap addr + phys_addr */
> + p->base = (uintptr_t)addr + phys_addr;
> + p->len = end_addr + 1;
> + RTE_LOG(DEBUG, EAL, "PCI Port IO found start=0x%"PRIx64"\n", p->base);
> + fclose(f);
> +
> + return 0;
> +
> +error:
> + fclose(f);
> return -1;
> -#endif
> }
> +#endif
--
David Marchand
[dpdk-dev] [PATCH] app/test: fix log check when default level is high
Hello Thomas, On Wed, May 4, 2016 at 3:34 PM, Thomas Monjalon wrote: > The log unit test was checking display of low priority messages. > It was not working if RTE_LOG_LEVEL is not RTE_LOG_DEBUG. > It is even easier to see since the default level is INFO (9b9d7ca). > > Now the test use ERR and CRIT levels which should be always enabled > while not trigerring syslog output on the console. > > Signed-off-by: Thomas Monjalon > --- > app/test/autotest_test_funcs.py | 20 > app/test/test_logs.c| 20 +--- > 2 files changed, 17 insertions(+), 23 deletions(-) > > diff --git a/app/test/autotest_test_funcs.py b/app/test/autotest_test_funcs.py > index 0f012f6..f04909d 100644 > --- a/app/test/autotest_test_funcs.py > +++ b/app/test/autotest_test_funcs.py > @@ -145,18 +145,14 @@ def logs_autotest(child, test_name): > child.sendline(test_name) > > log_list = [ > - "TESTAPP1: this is a debug level message", > - "TESTAPP1: this is a info level message", > - "TESTAPP1: this is a warning level message", > - "TESTAPP2: this is a info level message", > - "TESTAPP2: this is a warning level message", > - "TESTAPP1: this is a debug level message", > - "TESTAPP1: this is a debug level message", > - "TESTAPP1: this is a info level message", > - "TESTAPP1: this is a warning level message", > - "TESTAPP2: this is a info level message", > - "TESTAPP2: this is a warning level message", > - "TESTAPP1: this is a debug level message", > + "TESTAPP1: error message", > + "TESTAPP1: critical message", > + "TESTAPP2: critical message", > + "TESTAPP1: error message", > + "TESTAPP1: error message", > + "TESTAPP1: critical message", > + "TESTAPP2: critical message", > + "TESTAPP1: error message", Since this list is tighly coupled to test_logs.c, a little comment on why the messages are declared twice in this list would help. > ] > > for log_msg in log_list: > diff --git a/app/test/test_logs.c b/app/test/test_logs.c > index 18a3b6a..861cdff 100644 > --- a/app/test/test_logs.c > +++ b/app/test/test_logs.c > @@ -66,24 +66,22 @@ test_logs(void) > rte_set_log_type(RTE_LOGTYPE_TESTAPP2, 1); > > /* log in debug level */ > - rte_set_log_level(RTE_LOG_DEBUG); > - RTE_LOG(DEBUG, TESTAPP1, "this is a debug level message\n"); > - RTE_LOG(INFO, TESTAPP1, "this is a info level message\n"); > - RTE_LOG(WARNING, TESTAPP1, "this is a warning level message\n"); > + rte_set_log_level(RTE_LOG_ERR); > + RTE_LOG(ERR, TESTAPP1, "error message\n"); > + RTE_LOG(CRIT, TESTAPP1, "critical message\n"); Comment is wrong, should be about error level. > > /* log in info level */ > - rte_set_log_level(RTE_LOG_INFO); > - RTE_LOG(DEBUG, TESTAPP2, "debug level message (not displayed)\n"); > - RTE_LOG(INFO, TESTAPP2, "this is a info level message\n"); > - RTE_LOG(WARNING, TESTAPP2, "this is a warning level message\n"); > + rte_set_log_level(RTE_LOG_CRIT); > + RTE_LOG(ERR, TESTAPP2, "error message (not displayed)\n"); > + RTE_LOG(CRIT, TESTAPP2, "critical message\n"); Idem. > > /* disable one log type */ > rte_set_log_type(RTE_LOGTYPE_TESTAPP2, 0); > > /* log in debug level */ > - rte_set_log_level(RTE_LOG_DEBUG); > - RTE_LOG(DEBUG, TESTAPP1, "this is a debug level message\n"); > - RTE_LOG(DEBUG, TESTAPP2, "debug level message (not displayed)\n"); > + rte_set_log_level(RTE_LOG_ERR); > + RTE_LOG(ERR, TESTAPP1, "error message\n"); > + RTE_LOG(ERR, TESTAPP2, "error message (not displayed)\n"); Idem. -- David Marchand
[dpdk-dev] [PATCH 5/7] eal/linux: mmap ioports on ppc64
On Fri, May 13, 2016 at 2:50 PM, Olivier Matz wrote: > On PPC64, the ioports are mapped in memory. Implement the missing part > of ioport API for PPC64 when using uio. This may also work on other > architectures but it has not been tested. > > Signed-off-by: David Marchand > Signed-off-by: Olivier Matz > --- > lib/librte_eal/common/include/rte_pci.h| 4 +- > lib/librte_eal/linuxapp/eal/eal_pci.c | 4 +- > lib/librte_eal/linuxapp/eal/eal_pci_init.h | 6 ++ > lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 119 > +++-- > 4 files changed, 107 insertions(+), 26 deletions(-) > > diff --git a/lib/librte_eal/common/include/rte_pci.h > b/lib/librte_eal/common/include/rte_pci.h > index fd049d1..4657396 100644 > --- a/lib/librte_eal/common/include/rte_pci.h > +++ b/lib/librte_eal/common/include/rte_pci.h > @@ -105,7 +105,8 @@ extern struct pci_device_list pci_device_list; /**< > Global list of PCI devices. > /** Nb. of values in PCI resource format. */ > #define PCI_RESOURCE_FMT_NVAL 3 > > -/** IO resource type: memory address space */ > +/** IO resource type: */ > +#define IORESOURCE_IO 0x0100 > #define IORESOURCE_MEM0x0200 > > /** This could go in a linux-specific header. > diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c > b/lib/librte_eal/linuxapp/eal/eal_pci.c > index 1a93725..f1ea52b 100644 > --- a/lib/librte_eal/linuxapp/eal/eal_pci.c > +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c > @@ -191,9 +191,9 @@ pci_find_max_end_va(void) > } > > /* parse one line of the "resource" sysfs file (note that the 'line' > - * string is modified) > + * string is modified > */ Garbage ? -- David Marchand
[dpdk-dev] [PATCH 6/7] virtio: fix pci accesses for ppc64 in legacy mode
Hello Olivier,
On Fri, May 13, 2016 at 2:50 PM, Olivier Matz wrote:
> From: David Marchand
>
> Although ppc supports both endianesses, qemu supposes that the cpu is
> big endian and enforces this for the virtio-net stuff.
>
> Fix PCI accesses in legacy mode. Only ppc64le is supported at the moment.
>
> Signed-off-by: David Marchand
> Signed-off-by: Olivier Matz
> ---
> drivers/net/virtio/virtio_pci.c | 44
> +
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
> index 9cdca06..bdb89fd 100644
> --- a/drivers/net/virtio/virtio_pci.c
> +++ b/drivers/net/virtio/virtio_pci.c
> @@ -55,18 +55,62 @@
> */
> #define VIRTIO_PCI_CONFIG(hw) (((hw)->use_msix) ? 24 : 20)
>
> +/*
> + * Since we are in legacy mode:
> + * http://ozlabs.org/~rusty/virtio-spec/virtio-0.9.5.pdf
> + *
> + * "Note that this is possible because while the virtio header is PCI (i.e.
> + * little) endian, the device-specific region is encoded in the native
> endian of
> + * the guest (where such distinction is applicable)."
> + *
> + * For powerpc which supports both, qemu supposes that cpu is big endian and
> + * enforces this for the virtio-net stuff.
> + */
> +
> static void
> legacy_read_dev_config(struct virtio_hw *hw, size_t offset,
>void *dst, int length)
> {
> rte_eal_pci_ioport_read(>io, dst, length,
> VIRTIO_PCI_CONFIG(hw) + offset);
> +#ifdef RTE_ARCH_PPC_64
> + switch (length) {
> + case 4:
> + *(uint32_t *)dst = rte_be_to_cpu_32(*(uint32_t *)dst);
> + break;
> + case 2:
> + *(uint16_t *)dst = rte_be_to_cpu_16(*(uint16_t *)dst);
> + break;
> + default:
> + break;
> + }
> +#endif
> }
I think that, in the original patch, I was handling lengths different
than 1, 2 and 4 ;-)
Idem for write.
--
David Marchand
[dpdk-dev] [PATCH v3 02/13] ixgbe: move pci device ids to driver
On Fri, Apr 29, 2016 at 3:34 AM, Wu, Jingjing wrote: > Hi, David > > For the changes on igb, ixgbe, I saw you create a new header file called > **__pci_dev_ids.h to replace the rte_pci_dev_ids.h for each driver. > But for the changes on i40e, you didn't do that way. > If you look into the base code, you will find for each Intel NIC, the device > ids are defined there, such as ixgbe_type.h; i40e_devid.h; E1000_hw.h. > > I'd prefer the way you did in i40e driver. It's clearer and with minor change. This is what I wanted to do, but this requires a rework in kni and the pci test. -- David Marchand
[dpdk-dev] [RFC PATCH 0/4]: Implement module information export
On Tue, May 3, 2016 at 1:57 PM, Neil Horman wrote: > On Tue, Apr 26, 2016 at 01:39:47PM -0400, Neil Horman wrote: >> Hey- >> So a few days ago we were reviewing Davids patch series to introduce >> the >> abiilty to dump hardware support from pmd DSO's in a human readable format. >> That effort encountered some problems, most notably the fact that stripping a >> DSO removed the required information that the proposed tool keyed off, as >> well >> as the need to dead reckon offsets between symbols that may not be constant >> (dependent on architecture). >> >> I was going to start looking into the possibility of creating a modinfo >> section in a simmilar fashion to what kernel modules do in linux or BSD. I >> decided to propose this solution instead though, because the kernel style >> solution requires a significant amount of infrastructure that I think we can >> maybe avoid maintaining, if we accept some minor caviats >> >> To do this We emit a set of well known marker symbols for each DSO that an >> external application can search for (in this case I called them >> this_pmd_driver, where n is a counter macro). These marker symbols are >> n is a counter macro). These marker symbols are exported by PMDs for >> external access. External tools can then access these symbols via the >> dlopen/dlsym api (or via elfutils libraries) >> >> The symbols above alias the rte_driver struct for each PMD, and the external >> application can then interrogate the registered driver information. >> >> I also add a pointer to the pci id table struct for each PMD so that we can >> export hardware support. >> >> This approach has a few pros and cons: >> >> pros: >> 1) Its simple, and doesn't require extra infrastructure to implement. E.g. >> we >> don't need a new tool to extract driver information and emit the C code to >> build >> the binary data for the special section, nor do we need a custom linker >> script >> to link said special section in place >> >> 2) Its stable. Because the marker symbols are explicitly exported, this >> approach is resilient against stripping. >> >> cons: >> 1) It creates an artifact in that PMD_REGISTER_DRIVER has to be used in one >> compilation unit per DSO. As an example em and igb effectively merge two >> drivers into one DSO, and the uses of PMD_REGISTER_DRIVER occur in two >> separate >> C files for the same single linked DSO. Because of the use of the >> __COUNTER__ >> macro we get multiple definitions of the same marker symbols. >> >> I would make the argument that the downside of the above artifact isn't that >> big >> a deal. Traditionally in other projects a unit like a module (or DSO in our >> case) only ever codifies a single driver (e.g. module_init() in the linux >> kernel >> is only ever used once per built module). If we have code like igb/em that >> shares some core code, we should build the shared code to object files and >> link >> them twice, once to an em.so pmd and again to an igb.so pmd. >> >> But regardless, I thought I would propose this to see what you all thought of >> it. >> >> FWIW, heres sample output of the pmdinfo tool from this series probing the >> librte_pmd_ena.so module: >> >> [nhorman at hmsreliant dpdk]$ ./build/app/pmdinfo >> ~/git/dpdk/build/lib/librte_pmd_ena.so >> PMD 0 Information: >> Driver Name: ena_driver >> Driver Type: PCI >> |PCI Table| >> | VENDOR ID | DEVICE ID | SUBVENDOR ID | SUBDEVICE ID | >> |-| >> | 1d0f| ec20| | | >> | 1d0f| ec21| | | >> |-| >> >> >> >> > Ping, thoughts here? - This implementation does not support binaries, so it is not suitable for people who don't want dso, this is partially why I used bfd rather than just dlopen. - The name of the tool "pmdinfo" is likely to cause problems, I would say we need to prefix t with dpdk. - How does it behave if we strip the dsos ? - Using __COUNTER__ seeems a bit tricky to me, can't this cause misalignments ? - The tool output format is not script friendly from my pov. -- David Marchand
[dpdk-dev] [PATCH] app/test: fix +/-1 error in allocation
On Tue, May 3, 2016 at 9:15 PM, Jan Viktorin wrote:
> A bug has been detected by valgrind:
>
> ==14406== Invalid write of size 1
> ==14406==by 0x86ECC76: sprintf (in /usr/lib/libc-2.23.so)
> ==14406==by 0x430B0A: commands_init (in
> /home/jviki/Projects/dpdk/dpdk-soc/build/app/test)
> ==14406==by 0x42F215: main (in
> /home/jviki/Projects/dpdk/dpdk-soc/build/app/test)
> ==14406== Address 0x9d72ff2 is 0 bytes after a block of size 1,346 alloc'd
> ==14406==at 0x78C1BD0: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==14406==by 0x430AE4: commands_init (in
> /home/jviki/Projects/dpdk/dpdk-soc/build/app/test)
> ==14406==by 0x42F215: main (in
> /home/jviki/Projects/dpdk/dpdk-soc/build/app/test)
> ==14406==
>
> The commands buffer is exactly 1346 B long so there is an access just after
> the buffer. The sprintf always writes '\0' at the end of the string. The '#'
> separator adds 1 B more to each string. This is correct until the last string
> is sprinted there. The last one is 1 B longer then expected, i.e.:
>
> strlen(t->command) + strlen("#") + ONE_FOR_ZERO
>
> Fixes: 727909c59231 ("app/test: introduce dynamic commands list")
>
> Signed-off-by: Jan Viktorin
Good catch.
Acked-by: David Marchand
--
David Marchand
[dpdk-dev] [PATCH v2] virtio: fix modify drv_flags for specific device
Hello Tan, On Thu, Apr 28, 2016 at 8:08 PM, Jianfeng Tan wrote: > Issue: virtio's drv_flags are decided by devices types (modern vs legacy), > and which kernel driver is used, and the negotiated features (especially > VIRTIO_NET_STATUS) with backend, which makes it possible to multiple > virtio devices have different versions of drv_flags, but this variable > is currently shared by each virtio device. The wording is a bit strange, maybe the sentence is a bit too long. But the rest looks good to me. Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH] virtio: fix modify drv_flags for specific device
Hello, On Wed, Apr 27, 2016 at 7:10 AM, Tan, Jianfeng wrote: > Besides, I see bnx2x pmd could have similar issue, and the QLogic bnx2x > maintainers are CCed to confirm. Well, a way to detect those kind of issues would be to constify drv_flags. -- David Marchand
[dpdk-dev] [PATCH] virtio: fix modify drv_flags for specific device
On Tue, Apr 26, 2016 at 4:24 AM, Jianfeng Tan wrote:
> Issue: virtio's drv_flags are decided by devices types (modern vs legacy),
> and which kernel driver is used, and the negotiated features (especially
> VIRTIO_NET_STATUS) with backend, which makes it possible to multiple
> virtio devices have different versions of drv_flags, but this variable
> is currently shared by each virtio device.
>
> How to fix: dev_flags is a device-specific variable to store this info.
>
> Fixes: da978dfdc43 ("virtio: use port IO to get PCI resource")
>
> Reported-by: David Marchand
> Suggested-by: David Marchand
> Signed-off-by: Jianfeng Tan
- ethdev dev_flags is supposed to be filled with
RTE_ETH_DEV_DETACHABLE, RTE_ETH_DEV_INTR_LSC etc... not pci macros.
- I would have kept the init code as it is until the
rte_eth_copy_pci_info() step, then sanitise the dev_flags, but this
might be a matter of taste.
--
David Marchand
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
Hello, On Fri, Apr 22, 2016 at 7:15 AM, Tan, Jianfeng wrote: > On 4/21/2016 4:51 PM, David Marchand wrote: >> virtio code relies on drv_flags (even updating it while this should be >> per-device). >> So first, virtio should rely on dev_flags. > > > Mainly drv_flags's RTE_PCI_DRV_INTR_LSC, and RTE_PCI_DRV_DETACHABLE bit is > used. I understand the issue, pointed out by you here, that if two virtio > devices are used in a VM, one with feature VIRTIO_NET_F_STATUS, and the > other without feature VIRTIO_NET_F_STATUS (under the case that two vhost > backends are used). Then it leads to uncertainty of the behavior. > > Since the flags has been copied into dev_flags after features negotiated, I > believe we should use dev_flags instead of drv_flags. A patch to fix this > will be sent. Ok. >> The rest needs to be astracted in some virtio ops ? > So with that fix goes, we may make it more clear now. Do you mean this? Well, here, we have what looks like to be two drivers (one pci and one vdev). You tried to keep all this code together, to avoid duplicating it, which sounds sane. But in the end, you are trying to make this work by adding checks where this can't. I am not saying we should duplicate the code, but maybe having some internal virtio ops / abstraction would do the trick and avoid those checks. The reason of those comments is that dev_type in ethdev is going to disappear, see [1] and [2]. Drivers are called through their own specific ethdev/crypto ops and so, those drivers know implicitely that their are either pci or vdev (or whatever in the future) drivers. [1]: http://dpdk.org/ml/archives/dev/2016-April/037686.html [2]: http://dpdk.org/ml/archives/dev/2016-January/031390.html -- David Marchand
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
Hello, On Thu, Apr 21, 2016 at 4:56 AM, Jianfeng Tan wrote: > Add a new virtual device named eth_cvio, it can be used just like > eth_ring, eth_null, etc. > > Configured parameters include: > - rx (optional, 1 by default), number of rx, not used for now. > - tx (optional, 1 by default), number of tx, not used for now. > - cq (optional, 0 by default), not supported for now. > - mac (optional), random value will be given if not specified. > - queue_size (optional, 256 by default), size of virtqueue. > - path (madatory), path of vhost, depends on the file type, vhost > user if the given path points to a unix socket; vhost-net if the > given path points to a char device. > - ifname (optional), specify the name of backend tap device; only > valid when backend is vhost-net. > > The major difference with original virtio for vm is that, here we use > virtual addr instead of physical addr for vhost to calculate relative > address. > > When enable CONFIG_RTE_VIRTIO_VDEV (enabled by default), the compiled > library can be used in both VM and container environment. This implementation heavily relies on dev_type to keep as much code shared between pci / vdev path as possible. virtio code relies on drv_flags (even updating it while this should be per-device). So first, virtio should rely on dev_flags. The rest needs to be astracted in some virtio ops ? Thanks. -- David Marchand
[dpdk-dev] [PATCH v3 00/13] kill global pci device id list
On Wed, Apr 20, 2016 at 2:43 PM, David Marchand wrote: > - not storing the pci ids in a dedicated section anymore, pci drivers are > exported and parsed by a quickly written (and naive) tool Rethinking about this, this part won't do. Stripping symbols breaks it, and I had to go some gymnastics to get the symbols, while having exported information sanitised as strings in a dedicated section constructed at build time would be saner. Yes, this really sounds like modinfo ... Volunteers ? -- David Marchand
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
On Wed, Apr 20, 2016 at 8:15 PM, Neil Horman wrote:
> On Wed, Apr 20, 2016 at 03:39:59PM +0200, David Marchand wrote:
>> On Wed, Apr 20, 2016 at 3:29 PM, Neil Horman
>> wrote:
>> >> +#ifndef RTE_PCI_DEV_ID_DECL_EM
>> >> +#define RTE_PCI_DEV_ID_DECL_EM(vend, dev)
>> >> +#endif
>> >> +
>> >> +#ifndef PCI_VENDOR_ID_INTEL
>> >> +/** Vendor ID used by Intel devices */
>> >> +#define PCI_VENDOR_ID_INTEL 0x8086
>> >> +#endif
>> >> +
>> > This is broken, PCI_VENDOR_ID_INTEL should be defined in a central
>> > location for
>> > all pci drivers, not redefined in every compilation unit. And you can
>> > likely
>>
>> Well we can keep the vendors in a common header, but I don't see the benefit.
>>
> ?
> The fact that you won't have to do this
> #ifndef PCI_VENDOR_ID_INTEL
> #define PCI_VENDOR_ID_INTEL ...
> #endif
> in every pmd
Ok, so you would keep the rte_pci_dev_ids.h with just the vendors in it ?
Or, we could rely on linux kernel headers (pci_ids.h), rather than
maintain a header in dpdk.
But this would add a dependency build on dpdk and I am not sure there
is something equivalent on freebsd (afaics all drivers seem to
duplicate the pci vendor id).
Any freebsd gourou reading this ?
>> > just remvoe the RTE_PCI_DEV_ID_DECL_* macros from each patch and use the
>> > RTE_PCI_DEV macro, as all the DECL macros just evaluate to that anyway.
>>
>> app/test/test_pci.c:#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev)
>> {RTE_PCI_DEVICE(vend, dev)},
>> lib/librte_eal/linuxapp/kni/kni_misc.c: #define
>> RTE_PCI_DEV_ID_DECL_IGB(vend, dev) case (dev):
>>
>> All this stuff is because of pci tests and kni code.
>>
> You're going to have to explain a bit further than that. Why does the kni
> code
> and pci testing code require that each driver have their own macro that just
> maps to the same macro underneath? Looking at the test_pci code, it appears
> its
> done because we used to contain all our pci device ids in a single file, and
> the
> device specific macros were used to selectively enable devices that were there
> for testing. But the point of this series is in part to separate out the
> device
> ids to their own locations, so it seems like you will have to fix up the pci
> tests anyway (and additionally it would be nice to include more than just EM,
> IGB, and IXGBE in thsoe tests anyway, though I understand thats outside the
> scope of this series)
- test_pci.c should be about testing pci infrastructure.
Relying on igb / ixgbe (or whatever pci device if we extend the list
to all pci ids) being present on the system to run successfully is
flawed but I have no better idea.
- kni implements specific ethtool stuff based on pci ids.
kni contains duplicated code from the kernel and it uses those ids to
drive to the right ops.
The solutions I have imagined so far :
* use a shared header for the devices that it supports
* drop the use of pci ids between kni library and kni kernel driver,
instead use the pmd name that would be resolved internally by the kni
library at RTE_KNI_IOCTL_CREATE time, and use this in the kni kernel
driver
* drop kni :-)
I don't mind doing trivial changes, but I don't have time for more on
this series.
--
David Marchand
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
On Wed, Apr 20, 2016 at 3:29 PM, Neil Horman wrote:
>> +#ifndef RTE_PCI_DEV_ID_DECL_EM
>> +#define RTE_PCI_DEV_ID_DECL_EM(vend, dev)
>> +#endif
>> +
>> +#ifndef PCI_VENDOR_ID_INTEL
>> +/** Vendor ID used by Intel devices */
>> +#define PCI_VENDOR_ID_INTEL 0x8086
>> +#endif
>> +
> This is broken, PCI_VENDOR_ID_INTEL should be defined in a central location
> for
> all pci drivers, not redefined in every compilation unit. And you can likely
Well we can keep the vendors in a common header, but I don't see the benefit.
> just remvoe the RTE_PCI_DEV_ID_DECL_* macros from each patch and use the
> RTE_PCI_DEV macro, as all the DECL macros just evaluate to that anyway.
app/test/test_pci.c:#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev)
{RTE_PCI_DEVICE(vend, dev)},
lib/librte_eal/linuxapp/kni/kni_misc.c: #define
RTE_PCI_DEV_ID_DECL_IGB(vend, dev) case (dev):
All this stuff is because of pci tests and kni code.
>>
>
>> +
>> +#undef RTE_PCI_DEV_ID_DECL_EM
> Why are you undefining this here? Is it because its in a header file and
> you're
> concerned about multiple inclusion? You should use an ifdef guard instead, or
> just define all the device id's in the header and ennumerate the pci table in
> one of the C files for the driver. That should apply to all the patches in
> this
> series I think
Just moved the code.
--
David Marchand
[dpdk-dev] [PATCH v3 13/13] app: introduce dpdk-obj-info tool
Export some useful information for startup scripts and debug. For now, only pci drivers are handled. Example for a static binary: marchand at gloops:~/git/dpdk$ ./build/app/dpdk-obj-info ./build/app/testpmd pci:driver=cxgbe,flags=needmapping,lsc pci:driver=cxgbe,id=vendor=1425,device=5400,subvendor=,subdevice= pci:driver=cxgbe,id=vendor=1425,device=5401,subvendor=,subdevice= pci:driver=cxgbe,id=vendor=1425,device=5402,subvendor=,subdevice= Example for a dso: marchand at gloops:~/git/dpdk$ ./build/app/dpdk-obj-info ./build/lib/librte_pmd_ixgbe.so pci:driver=ixgbe,flags=needmapping,lsc,detachable pci:driver=ixgbe,id=vendor=8086,device=10b6,subvendor=,subdevice= pci:driver=ixgbe,id=vendor=8086,device=1508,subvendor=,subdevice= pci:driver=ixgbe,id=vendor=8086,device=10c6,subvendor=,subdevice= Signed-off-by: David Marchand --- app/Makefile | 1 + app/dpdk-obj-info/Makefile| 45 + app/dpdk-obj-info/dpdk-obj-info.c | 188 ++ 3 files changed, 234 insertions(+) create mode 100644 app/dpdk-obj-info/Makefile create mode 100644 app/dpdk-obj-info/dpdk-obj-info.c diff --git a/app/Makefile b/app/Makefile index 1151e09..0461a35 100644 --- a/app/Makefile +++ b/app/Makefile @@ -37,5 +37,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += test-pipeline DIRS-$(CONFIG_RTE_TEST_PMD) += test-pmd DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_test DIRS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += proc_info +DIRS-y += dpdk-obj-info include $(RTE_SDK)/mk/rte.subdir.mk diff --git a/app/dpdk-obj-info/Makefile b/app/dpdk-obj-info/Makefile new file mode 100644 index 000..b0f4bc7 --- /dev/null +++ b/app/dpdk-obj-info/Makefile @@ -0,0 +1,45 @@ +# BSD LICENSE +# +# Copyright 2016 6WIND S.A. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of 6WIND S.A. nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +include $(RTE_SDK)/mk/rte.vars.mk + + +APP = dpdk-obj-info + +SRCS-y += dpdk-obj-info.c + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +LDLIBS += -lbfd --as-needed + +DEPDIRS-y += lib + +include $(RTE_SDK)/mk/rte.app.mk diff --git a/app/dpdk-obj-info/dpdk-obj-info.c b/app/dpdk-obj-info/dpdk-obj-info.c new file mode 100644 index 000..23c183d --- /dev/null +++ b/app/dpdk-obj-info/dpdk-obj-info.c @@ -0,0 +1,188 @@ +/*- + * BSD LICENSE + * + * Copyright 2016 6WIND S.A. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of 6WIND S.A. nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
[dpdk-dev] [PATCH v3 12/13] drivers: export pci drivers
Signed-off-by: David Marchand
---
drivers/net/mlx4/mlx4.c | 1 +
drivers/net/mlx5/mlx5.c | 1 +
drivers/net/virtio/virtio_ethdev.c | 1 +
lib/librte_eal/common/include/rte_pci.h | 7 +++
4 files changed, 10 insertions(+)
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 0c76e72..14fe9dd 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5789,6 +5789,7 @@ static struct eth_driver mlx4_driver = {
.dev_private_size = sizeof(struct priv)
};
+RTE_EAL_PCI_DRIVER_EXPORT(mlx4, mlx4_driver.pci_drv);
RTE_INIT(rte_mlx4_pmd_init);
static void
rte_mlx4_pmd_init(void)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index f6399fc..975bb3f 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -646,6 +646,7 @@ static struct eth_driver mlx5_driver = {
.dev_private_size = sizeof(struct priv)
};
+RTE_EAL_PCI_DRIVER_EXPORT(mlx5, mlx5_driver.pci_drv);
RTE_INIT(rte_mlx5_pmd_init);
static void
rte_mlx5_pmd_init(void)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index ee95cab..587ba60 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1211,6 +1211,7 @@ static struct eth_driver rte_virtio_pmd = {
.dev_private_size = sizeof(struct virtio_hw),
};
+RTE_EAL_PCI_DRIVER_EXPORT(virtio, rte_virtio_pmd.pci_drv);
RTE_INIT(rte_virtio_pmd_init);
static void
rte_virtio_pmd_init(void)
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 3bb1833..3095f94 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -497,12 +497,19 @@ void rte_eal_pci_dump(FILE *f);
void rte_eal_pci_register(struct rte_pci_driver *driver);
#define RTE_EAL_PCI_REGISTER(name, d) \
+RTE_EAL_PCI_DRIVER_EXPORT(name, d); \
RTE_INIT(pciinitfn_ ##name); \
static void pciinitfn_ ##name(void) \
{ \
rte_eal_pci_register(); \
}
+#define RTE_EAL_PCI_DRIVER_PREFIX "pcidriver_"
+
+#define RTE_EAL_PCI_DRIVER_EXPORT(name, d) \
+extern const typeof(d) *pcidriver_ ##name; \
+const typeof(d) *pcidriver_ ##name =
+
/**
* Unregister a PCI driver.
*
--
1.9.1
[dpdk-dev] [PATCH v3 10/13] pci: no need for global device ids list
Now that all pci device ids are in their respective drivers, we can remove this header. Signed-off-by: David Marchand --- doc/api/doxy-api-index.md | 1 - lib/librte_eal/common/Makefile | 2 +- lib/librte_eal/common/include/rte_pci_dev_ids.h | 93 - 3 files changed, 1 insertion(+), 95 deletions(-) delete mode 100644 lib/librte_eal/common/include/rte_pci_dev_ids.h diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index f626386..6b0ea11 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -45,7 +45,6 @@ There are many libraries, so their headers may be grouped by topics: [vhost] (@ref rte_virtio_net.h), [KNI](@ref rte_kni.h), [PCI](@ref rte_pci.h), - [PCI IDs](@ref rte_pci_dev_ids.h) - **memory**: [memseg] (@ref rte_memory.h), diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile index f5ea0ee..bb9810d 100644 --- a/lib/librte_eal/common/Makefile +++ b/lib/librte_eal/common/Makefile @@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk INC := rte_branch_prediction.h rte_common.h INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h INC += rte_log.h rte_memory.h rte_memzone.h rte_pci.h -INC += rte_pci_dev_ids.h rte_per_lcore.h rte_random.h +INC += rte_per_lcore.h rte_random.h INC += rte_tailq.h rte_interrupts.h rte_alarm.h INC += rte_string_fns.h rte_version.h INC += rte_eal_memconfig.h rte_malloc_heap.h diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h b/lib/librte_eal/common/include/rte_pci_dev_ids.h deleted file mode 100644 index 6720b7a..000 --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h +++ /dev/null @@ -1,93 +0,0 @@ -/*- - * This file is provided under a dual BSD/GPLv2 license. When using or - * redistributing this file, you may do so under either license. - * - * GPL LICENSE SUMMARY - * - * Copyright(c) 2010-2015 Intel Corporation. All rights reserved. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of version 2 of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. - * The full GNU General Public License is included in this distribution - * in the file called LICENSE.GPL. - * - * Contact Information: - * Intel Corporation - * - * BSD LICENSE - * - * Copyright(c) 2010-2014 Intel Corporation. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of Intel Corporation nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - */ - -/** - * @file - * - * This file contains a list of the PCI device IDs recognised by DPDK, which - * can be used to fill out an array of structures describing the devices. - * - * Currently four families of devices are recognised: those supported by the - * IGB driver, by EM driver, those supported by the IXGBE driver, and by virtio - * driver which
[dpdk-dev] [PATCH v3 09/13] ena: remove unneeded pci macro
I suppose this is a remnant of rte_pci_dev_ids.h, just remove this.
Signed-off-by: David Marchand
---
drivers/net/ena/ena_ethdev.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 2b60a67..efa5e31 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -80,11 +80,9 @@
#define PCI_DEVICE_ID_ENA_LLQ_VF 0xEC21
static struct rte_pci_id pci_id_ena_map[] = {
-#define RTE_PCI_DEV_ID_DECL_ENA(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-
- RTE_PCI_DEV_ID_DECL_ENA(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_VF)
- RTE_PCI_DEV_ID_DECL_ENA(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_LLQ_VF)
- {.device_id = 0},
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_LLQ_VF) },
+ { .device_id = 0 },
};
static int ena_device_init(struct ena_com_dev *ena_dev,
--
1.9.1
[dpdk-dev] [PATCH v3 08/13] bnx2x: move pci device ids to driver
Reused defines from the driver and moved broadcom vendor id macro.
Signed-off-by: David Marchand
---
drivers/net/bnx2x/bnx2x.c | 3 +-
drivers/net/bnx2x/bnx2x_ethdev.c| 21 +++--
lib/librte_eal/common/include/rte_pci_dev_ids.h | 60 -
3 files changed, 18 insertions(+), 66 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 6edb2f9..8264a74 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -22,7 +22,6 @@
#include "ecore_init_ops.h"
#include "rte_version.h"
-#include "rte_pci_dev_ids.h"
#include
#include
@@ -9588,7 +9587,7 @@ void bnx2x_load_firmware(struct bnx2x_softc *sc)
int f;
struct stat st;
- fwname = sc->devinfo.device_id == BNX2X_DEV_ID_57711
+ fwname = sc->devinfo.device_id == CHIP_NUM_57711
? FW_NAME_57711 : FW_NAME_57810;
f = open(fwname, O_RDONLY);
if (f < 0) {
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index ba194b5..06a0add 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -16,15 +16,28 @@
/*
* The set of PCI devices this driver supports
*/
+#define PCI_VENDOR_ID_BROADCOM 0x14E4
static struct rte_pci_id pci_id_bnx2x_map[] = {
-#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57711) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_OBS) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_4_10) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_2_20) },
+#ifdef RTE_LIBRTE_BNX2X_MF_SUPPORT
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810_MF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811_MF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_MF) },
+#endif
{ .vendor_id = 0, }
};
static struct rte_pci_id pci_id_bnx2xvf_map[] = {
-#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_VF) },
{ .vendor_id = 0, }
};
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 1c22c04..6720b7a 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -88,66 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#ifndef RTE_PCI_DEV_ID_DECL_BNX2X
-#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_BNX2XVF
-#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
-#endif
-
-#ifndef PCI_VENDOR_ID_BROADCOM
-/** Vendor ID used by Broadcom devices */
-#define PCI_VENDOR_ID_BROADCOM 0x14E4
-#endif
-
-/** QLogic devices **/
-
-/* Broadcom/QLogic BNX2X */
-#define BNX2X_DEV_ID_57710 0x164e
-#define BNX2X_DEV_ID_57711 0x164f
-#define BNX2X_DEV_ID_57711E0x1650
-#define BNX2X_DEV_ID_57712 0x1662
-#define BNX2X_DEV_ID_57712_MF 0x1663
-#define BNX2X_DEV_ID_57712_VF 0x166f
-#define BNX2X_DEV_ID_57713 0x1651
-#define BNX2X_DEV_ID_57713E0x1652
-#define BNX2X_DEV_ID_57800 0x168a
-#define BNX2X_DEV_ID_57800_MF 0x16a5
-#define BNX2X_DEV_ID_57800_VF 0x16a9
-#define BNX2X_DEV_ID_57810 0x168e
-#define BNX2X_DEV_ID_57810_MF 0x16ae
-#define BNX2X_DEV_ID_57810_VF 0x16af
-#define BNX2X_DEV_ID_57811 0x163d
-#define BNX2X_DEV_ID_57811_MF 0x163e
-#define BNX2X_DEV_ID_57811_VF 0x163f
-
-#define BNX2X_DEV_ID_57840_OBS 0x168d
-#define BNX2X_DEV_ID_57840_OBS_MF 0x16ab
-#define BNX2X_DEV_ID_57840_4_100x16a1
-#define BNX2X_DEV_ID_57840_2_200x16a2
-#define BNX2X_DEV_ID_57840_MF 0x16a4
-#define BNX2X_DEV_ID_57840_VF 0x16ad
-
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800)
-RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800_VF)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57711)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810)
-RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810_VF)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57811)
-RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57811_VF)
-RTE_PCI_DEV_I
[dpdk-dev] [PATCH v3 07/13] enic: move pci device ids to driver
Moved cisco vendor id since the driver had no such information.
Signed-off-by: David Marchand
---
drivers/net/enic/enic_ethdev.c | 13 +
lib/librte_eal/common/include/rte_pci_dev_ids.h | 17 -
2 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 7539811..0e26aa9 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -57,15 +57,12 @@
/*
* The set of PCI devices this driver supports
*/
+#define PCI_VENDOR_ID_CISCO 0x1137
static const struct rte_pci_id pci_id_enic_map[] = {
-#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#ifndef PCI_VENDOR_ID_CISCO
-#define PCI_VENDOR_ID_CISCO0x1137
-#endif
-#include "rte_pci_dev_ids.h"
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET)
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
-{.vendor_id = 0, /* Sentinal */},
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_CISCO,
+ PCI_DEVICE_ID_CISCO_VIC_ENET_VF) },
+ {.vendor_id = 0, /* sentinel */},
};
static int
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 0ecff3c..1c22c04 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -88,10 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#ifndef RTE_PCI_DEV_ID_DECL_ENIC
-#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_BNX2X
#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev)
#endif
@@ -100,24 +96,11 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#endif
-#ifndef PCI_VENDOR_ID_CISCO
-/** Vendor ID used by Cisco VIC devices */
-#define PCI_VENDOR_ID_CISCO 0x1137
-#endif
-
#ifndef PCI_VENDOR_ID_BROADCOM
/** Vendor ID used by Broadcom devices */
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/** Cisco VIC devices **/
-
-#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
-#define PCI_DEVICE_ID_CISCO_VIC_ENET_VF 0x0071 /* enet SRIOV VF */
-
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET)
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
-
/** QLogic devices **/
/* Broadcom/QLogic BNX2X */
--
1.9.1
[dpdk-dev] [PATCH v3 06/13] vmxnet3: move pci device ids to driver
Moved vmware device ids macro since the driver had no such information.
Signed-off-by: David Marchand
---
drivers/net/vmxnet3/vmxnet3_ethdev.c| 9 -
lib/librte_eal/common/include/rte_pci_dev_ids.h | 16
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 375e681..e3cfee4 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -100,12 +100,11 @@ static void vmxnet3_process_events(struct vmxnet3_hw *);
/*
* The set of PCI devices this driver supports
*/
+#define PCI_VENDOR_ID_VMWARE 0x15AD
+#define VMWARE_DEV_ID_VMXNET3 0x07B0
static const struct rte_pci_id pci_id_vmxnet3_map[] = {
-
-#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops vmxnet3_eth_dev_ops = {
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 448b5e1..0ecff3c 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -88,10 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#ifndef RTE_PCI_DEV_ID_DECL_VMXNET3
-#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_ENIC
#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
#endif
@@ -104,11 +100,6 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#endif
-#ifndef PCI_VENDOR_ID_VMWARE
-/** Vendor ID used by VMware devices */
-#define PCI_VENDOR_ID_VMWARE 0x15AD
-#endif
-
#ifndef PCI_VENDOR_ID_CISCO
/** Vendor ID used by Cisco VIC devices */
#define PCI_VENDOR_ID_CISCO 0x1137
@@ -119,12 +110,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/** VMware VMXNET3 devices **/
-
-#define VMWARE_DEV_ID_VMXNET3 0x07B0
-
-RTE_PCI_DEV_ID_DECL_VMXNET3(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3)
-
/** Cisco VIC devices **/
#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
@@ -183,4 +168,3 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM,
BNX2X_DEV_ID_57840_MF)
*/
#undef RTE_PCI_DEV_ID_DECL_BNX2X
#undef RTE_PCI_DEV_ID_DECL_BNX2XVF
-#undef RTE_PCI_DEV_ID_DECL_VMXNET3
--
1.9.1
[dpdk-dev] [PATCH v3 05/13] virtio: move pci device ids to driver
Reused defines from virtio_pci.h.
Signed-off-by: David Marchand
---
drivers/net/virtio/virtio_ethdev.c | 7 ++-
lib/librte_eal/common/include/rte_pci_dev_ids.h | 17 -
2 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index f8cc158..ee95cab 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -102,11 +102,8 @@ static int virtio_dev_queue_stats_mapping_set(
* The set of PCI devices this driver supports
*/
static const struct rte_pci_id pci_id_virtio_map[] = {
-
-#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(VIRTIO_PCI_VENDORID, VIRTIO_PCI_DEVICEID_MIN) },
+ { .vendor_id = 0, /* sentinel */ },
};
struct rte_virtio_xstats_name_off {
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index a19fdfa..448b5e1 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -68,7 +68,6 @@
* driver which is a para virtualization driver running in guest virtual
machine.
* The inclusion of these in an array built using this file depends on the
* definition of
- * RTE_PCI_DEV_ID_DECL_VIRTIO
* at the time when this file is included.
*
* In order to populate an array, the user of this file must define this macro:
@@ -89,10 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#ifndef RTE_PCI_DEV_ID_DECL_VIRTIO
-#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_VMXNET3
#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
#endif
@@ -109,11 +104,6 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#endif
-#ifndef PCI_VENDOR_ID_QUMRANET
-/** Vendor ID used by virtio devices */
-#define PCI_VENDOR_ID_QUMRANET 0x1AF4
-#endif
-
#ifndef PCI_VENDOR_ID_VMWARE
/** Vendor ID used by VMware devices */
#define PCI_VENDOR_ID_VMWARE 0x15AD
@@ -129,12 +119,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/** Virtio devices from virtio.h **/
-
-#define QUMRANET_DEV_ID_VIRTIO 0x1000
-
-RTE_PCI_DEV_ID_DECL_VIRTIO(PCI_VENDOR_ID_QUMRANET, QUMRANET_DEV_ID_VIRTIO)
-
/** VMware VMXNET3 devices **/
#define VMWARE_DEV_ID_VMXNET3 0x07B0
@@ -199,5 +183,4 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM,
BNX2X_DEV_ID_57840_MF)
*/
#undef RTE_PCI_DEV_ID_DECL_BNX2X
#undef RTE_PCI_DEV_ID_DECL_BNX2XVF
-#undef RTE_PCI_DEV_ID_DECL_VIRTIO
#undef RTE_PCI_DEV_ID_DECL_VMXNET3
--
1.9.1
[dpdk-dev] [PATCH v3 04/13] fm10k: move pci device ids to driver
Since the base driver already defines all pci device ids, no need to
redefine them, let's just drop the previous RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/fm10k/fm10k_ethdev.c| 7 +++---
lib/librte_eal/common/include/rte_pci_dev_ids.h | 29 -
2 files changed, 4 insertions(+), 32 deletions(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 146bc2a..40b57f9 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -3018,9 +3018,10 @@ eth_fm10k_dev_uninit(struct rte_eth_dev *dev)
* and SRIOV-VF devices.
*/
static const struct rte_pci_id pci_id_fm10k_map[] = {
-#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev) { RTE_PCI_DEVICE(vend, dev) },
-#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev) { RTE_PCI_DEVICE(vend, dev) },
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID, FM10K_DEV_ID_PF) },
+ { RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID,
+ FM10K_DEV_ID_SDI_FM10420_QDA2) },
+ { RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID, FM10K_DEV_ID_VF) },
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index f1f3e13..a19fdfa 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -97,14 +97,6 @@
#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_FM10K
-#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_FM10KVF
-#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_ENIC
#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
#endif
@@ -117,11 +109,6 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#endif
-#ifndef PCI_VENDOR_ID_INTEL
-/** Vendor ID used by Intel devices */
-#define PCI_VENDOR_ID_INTEL 0x8086
-#endif
-
#ifndef PCI_VENDOR_ID_QUMRANET
/** Vendor ID used by virtio devices */
#define PCI_VENDOR_ID_QUMRANET 0x1AF4
@@ -142,14 +129,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/*** Physical FM10K devices from fm10k_type.h ***/
-
-#define FM10K_DEV_ID_PF 0x15A4
-#define FM10K_DEV_ID_SDI_FM10420_QDA2 0x15D0
-
-RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_PF)
-RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_SDI_FM10420_QDA2)
-
/** Virtio devices from virtio.h **/
#define QUMRANET_DEV_ID_VIRTIO 0x1000
@@ -162,12 +141,6 @@ RTE_PCI_DEV_ID_DECL_VIRTIO(PCI_VENDOR_ID_QUMRANET,
QUMRANET_DEV_ID_VIRTIO)
RTE_PCI_DEV_ID_DECL_VMXNET3(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3)
-/*** Virtual FM10K devices from fm10k_type.h ***/
-
-#define FM10K_DEV_ID_VF 0x15A5
-
-RTE_PCI_DEV_ID_DECL_FM10KVF(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_VF)
-
/** Cisco VIC devices **/
#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
@@ -228,5 +201,3 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM,
BNX2X_DEV_ID_57840_MF)
#undef RTE_PCI_DEV_ID_DECL_BNX2XVF
#undef RTE_PCI_DEV_ID_DECL_VIRTIO
#undef RTE_PCI_DEV_ID_DECL_VMXNET3
-#undef RTE_PCI_DEV_ID_DECL_FM10K
-#undef RTE_PCI_DEV_ID_DECL_FM10KVF
--
1.9.1
[dpdk-dev] [PATCH v3 03/13] i40e: move pci device ids to driver
Since the base driver already defines all pci device ids, no need to
redefine them, let's just drop the previous RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/i40e/i40e_ethdev.c | 21 ++--
drivers/net/i40e/i40e_ethdev_vf.c | 9 ++--
lib/librte_eal/common/include/rte_pci_dev_ids.h | 64 -
3 files changed, 24 insertions(+), 70 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 4e87399..b43acf1 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -448,9 +448,24 @@ static void i40e_set_default_mac_addr(struct rte_eth_dev
*dev,
struct ether_addr *mac_addr);
static const struct rte_pci_id pci_id_i40e_map[] = {
-#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_XL710) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QEMU) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_C) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_A) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_C) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2_A) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_1G_BASE_T_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T_X722) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops i40e_eth_dev_ops = {
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 1e41b3a..967324c 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1089,9 +1089,12 @@ i40evf_get_link_status(struct rte_eth_dev *dev, struct
rte_eth_link *link)
}
static const struct rte_pci_id pci_id_i40evf_map[] = {
-#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF_HV) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF_HV) },
+ { .vendor_id = 0, /* sentinel */ },
};
static inline int
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index ac2a6d6..f1f3e13 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -68,8 +68,6 @@
* driver which is a para virtualization driver running in guest virtual
machine.
* The inclusion of these in an array built using this file depends on the
* definition of
- * RTE_PCI_DEV_ID_DECL_I40E
- * RTE_PCI_DEV_ID_DECL_I40EVF
* RTE_PCI_DEV_ID_DECL_VIRTIO
* at the time when this file is included.
*
@@ -91,14 +89,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#ifndef RTE_PCI_DEV_ID_DECL_I40E
-#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_I40EVF
-#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_VIRTIO
#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev)
#endif
@@ -152,44 +142,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/*** Physical I40E devices from i40e_type.h */
-
-#define I40E_DEV_ID_SFP_XL710 0x1572
-#define I40E_DEV_ID_QEMU0x1574
-#define I40E_DEV_ID_KX_B0x1580
-#define I40E_DEV_ID_KX_C0x1581
-#define I40E_DEV_ID_QSFP_A 0x1583
-#define I40E_DEV_ID_QSFP_B 0x1584
-#define I40E_DEV_ID_QSFP_C 0x1585
-#define I40E_DEV_ID_10G_BASE_T 0x1586
-#define I40E_DEV_ID_20G_KR2 0x1587
-#define I40E_DEV_ID_20G_KR2_A 0x1588
-#define I40E_DEV_ID_10G_BASE_T4 0x1589
-#define I40E_DEV_ID_X722_A0 0x374C
-#define I40E_DEV_ID_KX_X722 0x37CE
-#define I40E_DEV_ID_QSFP_X722
[dpdk-dev] [PATCH v3 02/13] ixgbe: move pci device ids to driver
test application and kni still want to know ixgbe pci devices.
So let's create a header in the driver that will be used by them.
Same comment as for e1000 driver, we can't reuse base/ headers at the moment
because of macros redefinitions nightmare.
Signed-off-by: David Marchand
---
app/test-pmd/Makefile | 2 +
app/test-pmd/cmdline.c | 2 +-
app/test/Makefile | 1 +
app/test/test_pci.c | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c| 4 +-
drivers/net/ixgbe/ixgbe_pci_dev_ids.h | 213
lib/librte_eal/common/include/rte_pci_dev_ids.h | 154 -
lib/librte_eal/linuxapp/kni/Makefile| 1 +
lib/librte_eal/linuxapp/kni/kni_misc.c | 4 +-
9 files changed, 223 insertions(+), 160 deletions(-)
create mode 100644 drivers/net/ixgbe/ixgbe_pci_dev_ids.h
diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index 72426f3..a8899b8 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -64,6 +64,8 @@ ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
CFLAGS_mempool_anon.o := -D_GNU_SOURCE
endif
CFLAGS_cmdline.o := -D_GNU_SOURCE
+# for bypass pci device ids
+CFLAGS_cmdline.o += -I$(RTE_SDK)/drivers/net/ixgbe
# this application needs libraries first
DEPDIRS-y += lib drivers
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index c5b9479..45cbcff 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -10586,7 +10586,7 @@ cmd_reconfig_device_queue(portid_t id, uint8_t dev,
uint8_t queue)
}
#ifdef RTE_NIC_BYPASS
-#include
+#include
uint8_t
bypass_is_supported(portid_t port_id)
{
diff --git a/app/test/Makefile b/app/test/Makefile
index 8a1f54c..051eb8c 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -173,6 +173,7 @@ endif
# pci tests want to know some pci devices ids
CFLAGS_test_pci.o += -I$(RTE_SDK)/drivers/net/e1000
+CFLAGS_test_pci.o += -I$(RTE_SDK)/drivers/net/ixgbe
# this application needs libraries first
DEPDIRS-y += lib drivers
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 7215936..cdb79ab 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -68,7 +68,7 @@ static int my_driver_init(struct rte_pci_driver *dr,
struct rte_pci_id my_driver_id[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBE(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include
+#include
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 5103c7c..098918a 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -421,7 +421,7 @@ static int ixgbe_dev_udp_tunnel_port_del(struct rte_eth_dev
*dev,
static const struct rte_pci_id pci_id_ixgbe_map[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBE(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+#include "ixgbe_pci_dev_ids.h"
{ .vendor_id = 0, /* sentinel */ },
};
@@ -433,7 +433,7 @@ static const struct rte_pci_id pci_id_ixgbe_map[] = {
static const struct rte_pci_id pci_id_ixgbevf_map[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+#include "ixgbe_pci_dev_ids.h"
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/drivers/net/ixgbe/ixgbe_pci_dev_ids.h
b/drivers/net/ixgbe/ixgbe_pci_dev_ids.h
new file mode 100644
index 000..467a281
--- /dev/null
+++ b/drivers/net/ixgbe/ixgbe_pci_dev_ids.h
@@ -0,0 +1,213 @@
+/*-
+ * This file is provided under a dual BSD/GPLv2 license. When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.GPL.
+ *
+ * Contact Information:
+ * Intel Corporation
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, t
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
test application and kni still want to know e1000 pci devices.
So let's create headers in the driver that will be used by them.
I wanted to reuse base/ headers, but because of some headaches trying to resolve
macros redefinition collisions in kni (with ixgbe next commit), I left it as is.
Signed-off-by: David Marchand
---
app/test/Makefile | 3 +
app/test/test_pci.c | 3 +-
drivers/net/e1000/em_ethdev.c | 2 +-
drivers/net/e1000/em_pci_dev_ids.h | 208 +++
drivers/net/e1000/igb_ethdev.c | 4 +-
drivers/net/e1000/igb_pci_dev_ids.h | 165 +++
lib/librte_eal/common/include/rte_pci_dev_ids.h | 254
lib/librte_eal/linuxapp/kni/Makefile| 1 +
lib/librte_eal/linuxapp/kni/kni_misc.c | 4 +-
9 files changed, 384 insertions(+), 260 deletions(-)
create mode 100644 drivers/net/e1000/em_pci_dev_ids.h
create mode 100644 drivers/net/e1000/igb_pci_dev_ids.h
diff --git a/app/test/Makefile b/app/test/Makefile
index a4907d5..8a1f54c 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -171,6 +171,9 @@ CFLAGS_test_memcpy_perf.o += -fno-var-tracking-assignments
endif
endif
+# pci tests want to know some pci devices ids
+CFLAGS_test_pci.o += -I$(RTE_SDK)/drivers/net/e1000
+
# this application needs libraries first
DEPDIRS-y += lib drivers
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 0ed357e..7215936 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -77,8 +77,9 @@ struct rte_pci_id my_driver_id2[] = {
/* IGB & EM NICS */
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
+#include
#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include
+#include
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 1f80c05..203a9e5 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -139,7 +139,7 @@ static enum e1000_fc_mode em_fc_setting = e1000_fc_full;
static const struct rte_pci_id pci_id_em_map[] = {
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+#include "em_pci_dev_ids.h"
{0},
};
diff --git a/drivers/net/e1000/em_pci_dev_ids.h
b/drivers/net/e1000/em_pci_dev_ids.h
new file mode 100644
index 000..736a68e
--- /dev/null
+++ b/drivers/net/e1000/em_pci_dev_ids.h
@@ -0,0 +1,208 @@
+/*-
+ * This file is provided under a dual BSD/GPLv2 license. When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.GPL.
+ *
+ * Contact Information:
+ * Intel Corporation
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHE
[dpdk-dev] [PATCH v3 00/13] kill global pci device id list
This patchset moves all pci device ids from eal to the pmds that need them. Global pci device id list is then removed. A new tool (name to be discussed) has been added to retrieve some information from the dpdk elf objects. I can't work on this subject at the moment, so please feel free to make these patches yours if you have better ideas / ways to achieve the same result. Changes since v2: - rebased on HEAD - ena driver has been aligned - this patchset now depends on [1] as it avoids touching all drivers this way - not storing the pci ids in a dedicated section anymore, pci drivers are exported and parsed by a quickly written (and naive) tool Changes since v1: - indent fixes in i40e, fm10k, virtio, vmxnet3, enic, bnx2c. - rebased on head (ixgbe update) - removed doc update (will be sent separately) [1]: http://dpdk.org/ml/archives/dev/2016-April/037686.html -- David Marchand David Marchand (13): e1000: move pci device ids to driver ixgbe: move pci device ids to driver i40e: move pci device ids to driver fm10k: move pci device ids to driver virtio: move pci device ids to driver vmxnet3: move pci device ids to driver enic: move pci device ids to driver bnx2x: move pci device ids to driver ena: remove unneeded pci macro pci: no need for global device ids list drivers: constify pci id tables drivers: export pci drivers app: introduce dpdk-obj-info tool app/Makefile| 1 + app/dpdk-obj-info/Makefile | 45 ++ app/dpdk-obj-info/dpdk-obj-info.c | 188 +++ app/test-pmd/Makefile | 2 + app/test-pmd/cmdline.c | 2 +- app/test/Makefile | 4 + app/test/test_pci.c | 5 +- doc/api/doxy-api-index.md | 1 - drivers/crypto/qat/rte_qat_cryptodev.c | 2 +- drivers/net/bnx2x/bnx2x.c | 3 +- drivers/net/bnx2x/bnx2x_ethdev.c| 25 +- drivers/net/cxgbe/cxgbe_ethdev.c| 2 +- drivers/net/e1000/em_ethdev.c | 2 +- drivers/net/e1000/em_pci_dev_ids.h | 208 +++ drivers/net/e1000/igb_ethdev.c | 4 +- drivers/net/e1000/igb_pci_dev_ids.h | 165 ++ drivers/net/ena/ena_ethdev.c| 10 +- drivers/net/enic/enic_ethdev.c | 13 +- drivers/net/fm10k/fm10k_ethdev.c| 7 +- drivers/net/i40e/i40e_ethdev.c | 21 +- drivers/net/i40e/i40e_ethdev_vf.c | 9 +- drivers/net/ixgbe/ixgbe_ethdev.c| 4 +- drivers/net/ixgbe/ixgbe_pci_dev_ids.h | 213 +++ drivers/net/mlx4/mlx4.c | 1 + drivers/net/mlx5/mlx5.c | 1 + drivers/net/nfp/nfp_net.c | 2 +- drivers/net/virtio/virtio_ethdev.c | 8 +- drivers/net/vmxnet3/vmxnet3_ethdev.c| 9 +- lib/librte_eal/common/Makefile | 2 +- lib/librte_eal/common/include/rte_pci.h | 7 + lib/librte_eal/common/include/rte_pci_dev_ids.h | 704 lib/librte_eal/linuxapp/kni/Makefile| 2 + lib/librte_eal/linuxapp/kni/kni_misc.c | 8 +- 33 files changed, 918 insertions(+), 762 deletions(-) create mode 100644 app/dpdk-obj-info/Makefile create mode 100644 app/dpdk-obj-info/dpdk-obj-info.c create mode 100644 drivers/net/e1000/em_pci_dev_ids.h create mode 100644 drivers/net/e1000/igb_pci_dev_ids.h create mode 100644 drivers/net/ixgbe/ixgbe_pci_dev_ids.h delete mode 100644 lib/librte_eal/common/include/rte_pci_dev_ids.h -- 1.9.1
