[dpdk-dev] QoS: The difference of traffic class between subport and pipe in QoS
HI ! Is there difference of traffic class between subport and pipe in QOS ? After read prog_guide-2.2.pdf we kown that the scheduling hierarchy is port, subport, pipe, traffic class and queue. But the traffic class both in subport and pipe appeared in example of qos_sched . [subport 0] tb rate = 125000 ; Bytes per second tb size = 100 ; Bytes tc 0 rate = 125000 ; Bytes per second tc 1 rate = 125000 ; Bytes per second tc 2 rate = 125000 ; Bytes per second tc 3 rate = 125000 ; Bytes per second tc period = 10 ; Milliseconds pipe 0-4095 = 0; These pipes are configured with pipe profile 0 ; Pipe configuration [pipe profile 0] tb rate = 305175 ; Bytes per second tb size = 100 ; Bytes tc 0 rate = 305175 ; Bytes per second tc 1 rate = 305175 ; Bytes per second tc 2 rate = 305175 ; Bytes per second tc 3 rate = 305175 ; Bytes per second tc period = 40 ; Milliseconds Thanks
[dpdk-dev] [PATCH] net/ring: fix param string info
Fixes: 65eca099f405 ("drivers: split parameters infos in multiple lines")
Signed-off-by: Ferruh Yigit
---
drivers/net/ring/rte_eth_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 5551e18..b09d433 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -631,4 +631,4 @@ static struct rte_driver pmd_ring_drv = {
PMD_REGISTER_DRIVER(pmd_ring_drv, eth_ring);
DRIVER_REGISTER_PARAM_STRING(eth_ring,
- "nodeaction=[attach|detach]");
+ ETH_RING_NUMA_NODE_ACTION_ARG "=name:node:action(ATTACH|CREATE)");
--
2.7.4
[dpdk-dev] [PATCH] net/ring: fix ring eth dev creation via devargs
Using nodeaction devarg lets creating multiple ring eth devices:
"eth_ring0,nodeaction=R0:0:CREATE,nodeaction=R1:0:CREATE"
Trying to create all devices with same name fails. Since first part of
the nodeaction devarg is name (in above sample R0,R1), this name field
can be used as eth dev name.
Fixes: 61934c0956d4 ("ring: convert to use of PMD_REGISTER_DRIVER and fix
linking")
Signed-off-by: Ferruh Yigit
---
drivers/net/ring/rte_eth_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index a7048c7..5551e18 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -557,7 +557,7 @@ rte_pmd_ring_devinit(const char *name, const char *params)
goto out_free;
for (info->count = 0; info->count < info->total;
info->count++) {
- ret = eth_dev_ring_create(name,
+ ret =
eth_dev_ring_create(info->list[info->count].name,
info->list[info->count].node,
info->list[info->count].action);
if ((ret == -1) &&
--
2.7.4
[dpdk-dev] [PATCH] app/testpmd: fix set MTU cmd help string
Fixes: ae03d0d18adf ("app/testpmd: command to configure MTU")
Signed-off-by: Ferruh Yigit
---
app/test-pmd/cmdline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f90befc..17d238f 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1367,7 +1367,7 @@ cmdline_parse_token_num_t cmd_config_mtu_value =
cmdline_parse_inst_t cmd_config_mtu = {
.f = cmd_config_mtu_parsed,
.data = NULL,
- .help_str = "port config mtu value",
+ .help_str = "port config mtu port_id value",
.tokens = {
(void *)_config_mtu_port,
(void *)_config_mtu_keyword,
--
2.7.4
[dpdk-dev] [PATCH v6 8/9] ip_pipeline: fix lcore mapping for varying SMT threads as in ppc64
> -Original Message-
> From: Gowrishankar Muthukrishnan
> [mailto:gowrishankar.m at linux.vnet.ibm.com]
> Sent: Tuesday, August 16, 2016 11:28 AM
> To: dev at dpdk.org
> Cc: Chao Zhu ; Richardson, Bruce
> ; Ananyev, Konstantin
> ; Thomas Monjalon
> ; Dumitrescu, Cristian
> ; Pradeep
> Subject: [PATCH v6 8/9] ip_pipeline: fix lcore mapping for varying SMT
> threads as in ppc64
>
> This patch fixes ip_pipeline panic in app_init_core_map while preparing cpu
> core map in powerpc with SMT off. cpu_core_map_compute_linux currently
> prepares
> core mapping based on file existence in sysfs ie.
>
> /sys/devices/system/cpu/cpu/topology/physical_package_id
> /sys/devices/system/cpu/cpu/topology/core_id
>
> These files do not exist for lcores which are offline for any reason (as in
> powerpc, while SMT is off). In this situation, this function should further
> continue preparing map for other online lcores instead of returning with -1
> for a first unavailable lcore.
>
> Also, in SMT=off scenario for powerpc, lcore ids can not be always indexed
> from
> 0 upto 'number of cores present' (/sys/devices/system/cpu/present). For
> eg, for
> an online lcore 32, core_id returned in sysfs is 112 where online lcores are
> 10 (as in one configuration), hence sysfs lcore id can not be checked with
> indexing lcore number before positioning lcore map array.
>
> Signed-off-by: Gowrishankar Muthukrishnan
>
> ---
> examples/ip_pipeline/cpu_core_map.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/examples/ip_pipeline/cpu_core_map.c
> b/examples/ip_pipeline/cpu_core_map.c
> index cb088b1..dd8f678 100644
> --- a/examples/ip_pipeline/cpu_core_map.c
> +++ b/examples/ip_pipeline/cpu_core_map.c
> @@ -351,8 +351,10 @@ cpu_core_map_compute_linux(struct
> cpu_core_map *map)
> int lcore_socket_id =
>
> cpu_core_map_get_socket_id_linux(lcore_id);
>
> +#if !defined(RTE_ARCH_PPC_64)
> if (lcore_socket_id < 0)
> return -1;
> +#endif
>
> if (((uint32_t) lcore_socket_id) == socket_id)
> n_detected++;
> @@ -368,6 +370,7 @@ cpu_core_map_compute_linux(struct cpu_core_map
> *map)
> cpu_core_map_get_socket_id_linux(
> lcore_id);
>
> +#if !defined(RTE_ARCH_PPC_64)
> if (lcore_socket_id < 0)
> return -1;
>
> @@ -377,9 +380,14 @@ cpu_core_map_compute_linux(struct
> cpu_core_map *map)
>
> if (lcore_core_id < 0)
> return -1;
> +#endif
>
> +#if !defined(RTE_ARCH_PPC_64)
> if (((uint32_t) lcore_socket_id == socket_id)
> &&
> ((uint32_t) lcore_core_id ==
> core_id)) {
> +#else
> + if (((uint32_t) lcore_socket_id == socket_id))
> {
> +#endif
> uint32_t pos =
> cpu_core_map_pos(map,
> socket_id,
> core_id_contig,
> --
> 1.9.1
This patch only changes the code for PPC CPUs, I don't have the hardware to
check it myself, but I will take Gowrishankar's and Chao's word it is the right
thing to do for PPC CPUs, so ...
Acked by: Cristian Dumitrescu
[dpdk-dev] [PATCH v6 9/9] table: align rte table hash structs for cache line size
> -Original Message-
> From: Gowrishankar Muthukrishnan
> [mailto:gowrishankar.m at linux.vnet.ibm.com]
> Sent: Tuesday, August 16, 2016 11:28 AM
> To: dev at dpdk.org
> Cc: Chao Zhu ; Richardson, Bruce
> ; Ananyev, Konstantin
> ; Thomas Monjalon
> ; Dumitrescu, Cristian
> ; Pradeep
> Subject: [PATCH v6 9/9] table: align rte table hash structs for cache line
> size
>
> rte table hash structs rte_bucket_4_8, rte_bucket_4_16 and
> rte_bucket_4_32 have
> to be cache aligned as required by their corresponding hash create functions
> rte_table_hash_create_key8_lru etc.
>
> Signed-off-by: Gowrishankar Muthukrishnan
>
> ---
> lib/librte_table/rte_table_hash_key16.c | 4 ++--
> lib/librte_table/rte_table_hash_key32.c | 4 ++--
> lib/librte_table/rte_table_hash_key8.c | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/lib/librte_table/rte_table_hash_key16.c
> b/lib/librte_table/rte_table_hash_key16.c
> index b7e000f..2102326 100644
> --- a/lib/librte_table/rte_table_hash_key16.c
> +++ b/lib/librte_table/rte_table_hash_key16.c
> @@ -68,10 +68,10 @@ struct rte_bucket_4_16 {
> uint64_t next_valid;
>
> /* Cache line 1 */
> - uint64_t key[4][2];
> + uint64_t key[4][2] __rte_cache_aligned;
>
> /* Cache line 2 */
> - uint8_t data[0];
> + uint8_t data[0] __rte_cache_aligned;
> };
>
> struct rte_table_hash {
> diff --git a/lib/librte_table/rte_table_hash_key32.c
> b/lib/librte_table/rte_table_hash_key32.c
> index a7aba49..619f63a 100644
> --- a/lib/librte_table/rte_table_hash_key32.c
> +++ b/lib/librte_table/rte_table_hash_key32.c
> @@ -68,10 +68,10 @@ struct rte_bucket_4_32 {
> uint64_t next_valid;
>
> /* Cache lines 1 and 2 */
> - uint64_t key[4][4];
> + uint64_t key[4][4] __rte_cache_aligned;
>
> /* Cache line 3 */
> - uint8_t data[0];
> + uint8_t data[0] __rte_cache_aligned;
> };
>
> struct rte_table_hash {
> diff --git a/lib/librte_table/rte_table_hash_key8.c
> b/lib/librte_table/rte_table_hash_key8.c
> index e2e2bdc..4d5e0cd 100644
> --- a/lib/librte_table/rte_table_hash_key8.c
> +++ b/lib/librte_table/rte_table_hash_key8.c
> @@ -68,7 +68,7 @@ struct rte_bucket_4_8 {
> uint64_t key[4];
>
> /* Cache line 1 */
> - uint8_t data[0];
> + uint8_t data[0] __rte_cache_aligned;
> };
>
> struct rte_table_hash {
> --
> 1.9.1
Hi Gowrishankar,
My understanding is you are trying to work around the check invoked by the hash
table create functions that verifies the size of the bucket header structure is
a multiple of the cache line, right?
Given that the size of this structure is 1x, 2x or 3x times 64 bytes, the check
passes on IA CPUs (cache line of 64 bytes; explicit alignment to cache line
size is not needed in order to make the size of the structure a multiple of
cache line), but not on PPC CPUs (cache line of 128 bytes), correct?
I don't think your proposal provides the best way to fix this issue, since your
code leads to a considerable increase in the memory consumption used per bucket
in most cases:
- 100% more memory for 8-byte key hash table
- 0% more for 16-byte key hash table (code does not fix anything,
explicit alignment is not needed)
- 50% more for 32-byte key hash table
I suggest you simply change the check: instead of validating this data
structure is a multiple of cache line size, validate it is a multiple of 64
bytes.
Regards,
Cristian
[dpdk-dev] OpenSSL and non-BSD licenses in DPDK
Hello Everyone, First of all I would like to say hello since this is my first e-mail to this mailing list. I would like to ask a question regarding code licensing and importing code that uses different license than BSD-like. Especially I'm curious about the code that goes with OpenSSL/SSLeay license. Is it allowed to import such sources (or derived work) to DPDK? I've seen some GPL stuff, mostly kernel modules from Intel. So what with the above mentioned OpenSSL? Thank you in advance for your answers. Kind regards Zbigniew
[dpdk-dev] [PATCH] app/testpmd: fix set MTU cmd help string
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, August 31, 2016 9:49 AM
> To: dev at dpdk.org
> Cc: De Lara Guarch, Pablo
> Subject: [PATCH] app/testpmd: fix set MTU cmd help string
>
> Fixes: ae03d0d18adf ("app/testpmd: command to configure MTU")
>
> Signed-off-by: Ferruh Yigit
> ---
> app/test-pmd/cmdline.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index f90befc..17d238f 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -1367,7 +1367,7 @@ cmdline_parse_token_num_t
> cmd_config_mtu_value =
> cmdline_parse_inst_t cmd_config_mtu = {
> .f = cmd_config_mtu_parsed,
> .data = NULL,
> - .help_str = "port config mtu value",
> + .help_str = "port config mtu port_id value",
> .tokens = {
> (void *)_config_mtu_port,
> (void *)_config_mtu_keyword,
> --
> 2.7.4
Acked-by: Pablo de Lara
[dpdk-dev] [PATCH v2 14/14] ether: Support rte_soc_driver/device for etherdev
- eth_driver/rte_eth_dev embeds rte_soc_driver/device for relating SoC
PMDs to ethernet devices.
- Add probe and remove functions linked to eth_dev_init/uninit
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_ether/rte_ethdev.c | 129 ++
lib/librte_ether/rte_ethdev.h | 31 ++
2 files changed, 160 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 4fa65ca..b57d7b2 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -326,6 +326,101 @@ rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
}
int
+rte_eth_dev_soc_probe(struct rte_soc_driver *soc_drv,
+ struct rte_soc_device *soc_dev)
+{
+ struct eth_driver*eth_drv;
+ struct rte_eth_dev *eth_dev;
+ char ethdev_name[RTE_ETH_NAME_MAX_LEN];
+
+ int diag;
+
+ eth_drv = container_of(soc_drv, struct eth_driver, soc_drv);
+
+ rte_eal_soc_device_name(_dev->addr, ethdev_name,
+ sizeof(ethdev_name));
+
+ eth_dev = rte_eth_dev_allocate(ethdev_name);
+ if (eth_dev == NULL)
+ return -ENOMEM;
+
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+ eth_dev->data->dev_private = rte_zmalloc(
+ "ethdev private structure",
+ eth_drv->dev_private_size,
+ RTE_CACHE_LINE_SIZE);
+ if (eth_dev->data->dev_private == NULL)
+ rte_panic("Cannot allocate memzone for private port "
+ "data\n");
+ }
+ eth_dev->soc_dev = soc_dev;
+ eth_dev->driver = eth_drv;
+ eth_dev->data->rx_mbuf_alloc_failed = 0;
+
+ /* init user callbacks */
+ TAILQ_INIT(&(eth_dev->link_intr_cbs));
+
+ /*
+* Set the default MTU.
+*/
+ eth_dev->data->mtu = ETHER_MTU;
+
+ /* Invoke PMD device initialization function */
+ diag = (*eth_drv->eth_dev_init)(eth_dev);
+ if (diag == 0)
+ return 0;
+
+ RTE_PMD_DEBUG_TRACE("driver %s: eth_dev_init(%s) failed\n",
+ soc_drv->driver.name,
+ soc_dev->addr.name);
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ rte_free(eth_dev->data->dev_private);
+ rte_eth_dev_release_port(eth_dev);
+ return diag;
+}
+
+int
+rte_eth_dev_soc_remove(struct rte_soc_device *soc_dev)
+{
+ const struct eth_driver *eth_drv;
+ struct rte_eth_dev *eth_dev;
+ char ethdev_name[RTE_ETH_NAME_MAX_LEN];
+ int ret;
+
+ if (soc_dev == NULL)
+ return -EINVAL;
+
+ rte_eal_soc_device_name(_dev->addr, ethdev_name,
+ sizeof(ethdev_name));
+
+ eth_dev = rte_eth_dev_allocated(ethdev_name);
+ if (eth_dev == NULL)
+ return -ENODEV;
+
+ eth_drv = container_of(soc_dev->driver, struct eth_driver, soc_drv);
+
+ /* Invoke PMD device uninit function */
+ if (*eth_drv->eth_dev_uninit) {
+ ret = (*eth_drv->eth_dev_uninit)(eth_dev);
+ if (ret)
+ return ret;
+ }
+
+ /* free ether device */
+ rte_eth_dev_release_port(eth_dev);
+
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ rte_free(eth_dev->data->dev_private);
+
+ eth_dev->soc_dev = NULL;
+ eth_dev->driver = NULL;
+ eth_dev->data = NULL;
+
+ return 0;
+}
+
+
+int
rte_eth_dev_is_valid_port(uint8_t port_id)
{
if (port_id >= RTE_MAX_ETHPORTS ||
@@ -1555,6 +1650,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct
rte_eth_dev_info *dev_info)
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
dev_info->pci_dev = dev->pci_dev;
+ dev_info->soc_dev = dev->soc_dev;
dev_info->driver_name = dev->data->drv_name;
dev_info->nb_rx_queues = dev->data->nb_rx_queues;
dev_info->nb_tx_queues = dev->data->nb_tx_queues;
@@ -2530,8 +2626,13 @@ static inline
struct rte_intr_handle *eth_dev_get_intr_handle(struct rte_eth_dev *dev)
{
if (dev->pci_dev) {
+ RTE_VERIFY(dev->soc_dev == NULL);
return >pci_dev->intr_handle;
}
+ if (dev->soc_dev) {
+ RTE_VERIFY(dev->pci_dev == NULL);
+ return >soc_dev->intr_handle;
+ }
RTE_VERIFY(0);
return NULL;
@@ -2572,9 +2673,15 @@ static inline
const char *eth_dev_get_driver_name(const struct rte_eth_dev *dev)
{
if (dev->pci_dev) {
+ RTE_VERIFY(dev->soc_dev == NULL);
return dev->driver->pci_drv.driver.name;
}
+ if (dev->soc_dev) {
+ RTE_VERIFY(dev->pci_dev == NULL);
+ return dev->driver->soc_drv.driver.name;
+
[dpdk-dev] [PATCH v2 13/14] ether: extract function eth_dev_get_driver_name
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_ether/rte_ethdev.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 104ea4a..4fa65ca 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2568,6 +2568,17 @@ rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int
op, void *data)
return 0;
}
+static inline
+const char *eth_dev_get_driver_name(const struct rte_eth_dev *dev)
+{
+ if (dev->pci_dev) {
+ return dev->driver->pci_drv.driver.name;
+ }
+
+ RTE_VERIFY(0);
+ return NULL;
+}
+
const struct rte_memzone *
rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev, const char *ring_name,
uint16_t queue_id, size_t size, unsigned align,
@@ -2575,9 +2586,11 @@ rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev,
const char *ring_name,
{
char z_name[RTE_MEMZONE_NAMESIZE];
const struct rte_memzone *mz;
+ const char *drv_name;
+ drv_name = eth_dev_get_driver_name(dev);
snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d",
-dev->driver->pci_drv.driver.name, ring_name,
+drv_name, ring_name,
dev->data->port_id, queue_id);
mz = rte_memzone_lookup(z_name);
--
2.7.4
[dpdk-dev] [PATCH v2 12/14] ether: extract function eth_dev_get_intr_handle
We abstract access to the intr_handle here as we want to get
it either from the pci_dev or soc_dev.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_ether/rte_ethdev.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index e9f5467..104ea4a 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2526,6 +2526,17 @@ _rte_eth_dev_callback_process(struct rte_eth_dev *dev,
rte_spinlock_unlock(_eth_dev_cb_lock);
}
+static inline
+struct rte_intr_handle *eth_dev_get_intr_handle(struct rte_eth_dev *dev)
+{
+ if (dev->pci_dev) {
+ return >pci_dev->intr_handle;
+ }
+
+ RTE_VERIFY(0);
+ return NULL;
+}
+
int
rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int op, void *data)
{
@@ -2538,7 +2549,7 @@ rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int
op, void *data)
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = _eth_devices[port_id];
- intr_handle = >pci_dev->intr_handle;
+ intr_handle = eth_dev_get_intr_handle(dev);
if (!intr_handle->intr_vec) {
RTE_PMD_DEBUG_TRACE("RX Intr vector unset\n");
return -EPERM;
@@ -2598,7 +2609,7 @@ rte_eth_dev_rx_intr_ctl_q(uint8_t port_id, uint16_t
queue_id,
return -EINVAL;
}
- intr_handle = >pci_dev->intr_handle;
+ intr_handle = eth_dev_get_intr_handle(dev);
if (!intr_handle->intr_vec) {
RTE_PMD_DEBUG_TRACE("RX Intr vector unset\n");
return -EPERM;
--
2.7.4
[dpdk-dev] [PATCH v2 11/14] ether: verify we copy info from a PCI device
Now that different types of ethdev exist, check for presence of PCI dev while copying out the info. Similar would be done for SoC. Signed-off-by: Jan Viktorin Signed-off-by: Shreyansh Jain Signed-off-by: Hemant Agrawal --- lib/librte_ether/rte_ethdev.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c index b10d985..e9f5467 100644 --- a/lib/librte_ether/rte_ethdev.c +++ b/lib/librte_ether/rte_ethdev.c @@ -3200,6 +3200,8 @@ rte_eth_copy_pci_info(struct rte_eth_dev *eth_dev, struct rte_pci_device *pci_de return; } + RTE_VERIFY(eth_dev->pci_dev != NULL); + eth_dev->data->dev_flags = 0; if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_LSC) eth_dev->data->dev_flags |= RTE_ETH_DEV_INTR_LSC; -- 2.7.4
[dpdk-dev] [PATCH v2 10/14] ether: utilize container_of for pci_drv
It is not necessary to place the rte_pci_driver at the beginning
of the rte_eth_dev struct anymore as we use the container_of macro
to get the parent pointer.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_ether/rte_ethdev.c | 4 ++--
lib/librte_ether/rte_ethdev.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index d54ec9e..b10d985 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -242,7 +242,7 @@ rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
int diag;
- eth_drv = (struct eth_driver *)pci_drv;
+ eth_drv = container_of(pci_drv, struct eth_driver, pci_drv);
rte_eal_pci_device_name(_dev->addr, ethdev_name,
sizeof(ethdev_name));
@@ -303,7 +303,7 @@ rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
if (eth_dev == NULL)
return -ENODEV;
- eth_drv = (const struct eth_driver *)pci_dev->driver;
+ eth_drv = container_of(pci_dev->driver, struct eth_driver, pci_drv);
/* Invoke PMD device uninit function */
if (*eth_drv->eth_dev_uninit) {
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 2a697ec..8320dc4 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1842,7 +1842,7 @@ typedef int (*eth_dev_uninit_t)(struct rte_eth_dev
*eth_dev);
* Each Ethernet driver acts as a PCI driver and is represented by a generic
* *eth_driver* structure that holds:
*
- * - An *rte_pci_driver* structure (which must be the first field).
+ * - An *rte_pci_driver* structure.
*
* - The *eth_dev_init* function invoked for each matching PCI device.
*
--
2.7.4
[dpdk-dev] [PATCH v2 09/14] eal/soc: add intr_handle
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/common/include/rte_soc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_soc.h
b/lib/librte_eal/common/include/rte_soc.h
index d453398..bd496ed 100644
--- a/lib/librte_eal/common/include/rte_soc.h
+++ b/lib/librte_eal/common/include/rte_soc.h
@@ -53,6 +53,7 @@ extern "C" {
#include
#include
#include
+#include
extern struct soc_driver_list soc_driver_list;
/**< Global list of SoC Drivers */
@@ -81,6 +82,7 @@ struct rte_soc_device {
struct rte_device device; /**< Inherit code device */
struct rte_soc_addr addr; /**< SoC device Location */
struct rte_soc_id *id; /**< SoC device ID list */
+ struct rte_intr_handle intr_handle; /**< Interrupt handle */
struct rte_soc_driver *driver; /**< Associated driver */
};
--
2.7.4
[dpdk-dev] [PATCH v2 08/14] eal/soc: add drv_flags
The flags are copied from the PCI ones. They should be refactorized into a
general set of flags in the future.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/common/include/rte_soc.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_soc.h
b/lib/librte_eal/common/include/rte_soc.h
index c45b37e..d453398 100644
--- a/lib/librte_eal/common/include/rte_soc.h
+++ b/lib/librte_eal/common/include/rte_soc.h
@@ -117,8 +117,18 @@ struct rte_soc_driver {
soc_scan_t *scan_fn; /**< Callback for scanning SoC bus*/
soc_match_t *match_fn; /**< Callback to match dev<->drv */
const struct rte_soc_id *id_table; /**< ID table, NULL terminated */
+ uint32_t drv_flags;/**< Control handling of device */
};
+/** Device needs to map its resources by EAL */
+#define RTE_SOC_DRV_NEED_MAPPING 0x0001
+/** Device needs to be unbound even if no module is provieded */
+#define RTE_SOC_DRV_FORCE_UNBIND 0x0004
+/** Device driver supports link state interrupt */
+#define RTE_SOC_DRV_INTR_LSC0x0008
+/** Device driver supports detaching capability */
+#define RTE_SOC_DRV_DETACHABLE 0x0010
+
/**
* Utility function to write a SoC device name, this device name can later be
* used to retrieve the corresponding rte_soc_addr using above functions.
--
2.7.4
[dpdk-dev] [PATCH v2 07/14] eal/soc: extend and utilize devargs
It is assumed that SoC Devices provided on command line are prefixed with
"soc:". This patch adds parse and attach support for such devices.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/common/eal_common_dev.c | 27 ++
lib/librte_eal/common/eal_common_devargs.c | 17 +
lib/librte_eal/common/eal_common_soc.c | 55 ++---
lib/librte_eal/common/include/rte_devargs.h | 8 +
lib/librte_eal/common/include/rte_soc.h | 24 +
5 files changed, 119 insertions(+), 12 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_dev.c
b/lib/librte_eal/common/eal_common_dev.c
index d1f0ad8..fbc4443 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -106,17 +106,23 @@ rte_eal_dev_init(void)
int rte_eal_dev_attach(const char *name, const char *devargs)
{
- struct rte_pci_addr addr;
+ struct rte_soc_addr soc_addr;
+ struct rte_pci_addr pci_addr;
if (name == NULL || devargs == NULL) {
RTE_LOG(ERR, EAL, "Invalid device or arguments provided\n");
return -EINVAL;
}
- if (eal_parse_pci_DomBDF(name, ) == 0) {
- if (rte_eal_pci_probe_one() < 0)
+ memset(_addr, 0, sizeof(soc_addr));
+ if (rte_eal_parse_soc_spec(name, _addr) == 0) {
+ if (rte_eal_soc_probe_one(_addr) < 0) {
+ free(soc_addr.name);
+ goto err;
+ }
+ } else if (eal_parse_pci_DomBDF(name, _addr) == 0) {
+ if (rte_eal_pci_probe_one(_addr) < 0)
goto err;
-
} else {
if (rte_eal_vdev_init(name, devargs))
goto err;
@@ -131,15 +137,22 @@ err:
int rte_eal_dev_detach(const char *name)
{
- struct rte_pci_addr addr;
+ struct rte_soc_addr soc_addr;
+ struct rte_pci_addr pci_addr;
if (name == NULL) {
RTE_LOG(ERR, EAL, "Invalid device provided.\n");
return -EINVAL;
}
- if (eal_parse_pci_DomBDF(name, ) == 0) {
- if (rte_eal_pci_detach() < 0)
+ memset(_addr, 0, sizeof(soc_addr));
+ if (rte_eal_parse_soc_spec(name, _addr) == 0) {
+ if (rte_eal_soc_detach(_addr) < 0) {
+ free(soc_addr.name);
+ goto err;
+ }
+ } else if (eal_parse_pci_DomBDF(name, _addr) == 0) {
+ if (rte_eal_pci_detach(_addr) < 0)
goto err;
} else {
if (rte_eal_vdev_uninit(name))
diff --git a/lib/librte_eal/common/eal_common_devargs.c
b/lib/librte_eal/common/eal_common_devargs.c
index e403717..e1dae1a 100644
--- a/lib/librte_eal/common/eal_common_devargs.c
+++ b/lib/librte_eal/common/eal_common_devargs.c
@@ -41,6 +41,7 @@
#include
#include
+#include
#include
#include "eal_private.h"
@@ -105,6 +106,14 @@ rte_eal_devargs_add(enum rte_devtype devtype, const char
*devargs_str)
goto fail;
break;
+
+ case RTE_DEVTYPE_WHITELISTED_SOC:
+ case RTE_DEVTYPE_BLACKLISTED_SOC:
+ /* try to parse soc device with prefix "soc:" */
+ if (rte_eal_parse_soc_spec(buf, >soc.addr) != 0)
+ goto fail;
+ break;
+
case RTE_DEVTYPE_VIRTUAL:
/* save driver name */
ret = snprintf(devargs->virt.drv_name,
@@ -166,6 +175,14 @@ rte_eal_devargs_dump(FILE *f)
devargs->pci.addr.devid,
devargs->pci.addr.function,
devargs->args);
+ else if (devargs->type == RTE_DEVTYPE_WHITELISTED_SOC)
+ fprintf(f, " SoC whitelist %s %s\n",
+ devargs->soc.addr.name,
+ devargs->soc.addr.fdt_path);
+ else if (devargs->type == RTE_DEVTYPE_BLACKLISTED_SOC)
+ fprintf(f, " SoC blacklist %s %s\n",
+ devargs->soc.addr.name,
+ devargs->soc.addr.fdt_path);
else if (devargs->type == RTE_DEVTYPE_VIRTUAL)
fprintf(f, " VIRTUAL %s %s\n",
devargs->virt.drv_name,
diff --git a/lib/librte_eal/common/eal_common_soc.c
b/lib/librte_eal/common/eal_common_soc.c
index 4797dd9..efa722d 100644
--- a/lib/librte_eal/common/eal_common_soc.c
+++ b/lib/librte_eal/common/eal_common_soc.c
@@ -37,6 +37,8 @@
#include
#include
+#include
+#include
#include
#include "eal_private.h"
@@ -47,6 +49,21 @@ struct soc_driver_list soc_driver_list =
struct soc_device_list soc_device_list =
TAILQ_HEAD_INITIALIZER(soc_device_list);
+static struct rte_devargs *soc_devargs_lookup(struct rte_soc_device
[dpdk-dev] [PATCH v2 06/14] eal/soc: implement probing of drivers
Each SoC PMD registers a set of callback for scanning its own bus/infra and
matching devices to drivers when probe is called.
This patch introduces the infra for calls to SoC scan on rte_eal_soc_init()
and match on rte_eal_soc_probe().
Patch also adds test case for scan and probe.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
app/test/test_soc.c | 138 -
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 3 +
lib/librte_eal/common/eal_common_soc.c | 191
lib/librte_eal/common/include/rte_soc.h | 37 +
lib/librte_eal/linuxapp/eal/eal.c | 5 +
lib/librte_eal/linuxapp/eal/eal_soc.c | 16 ++
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 3 +
7 files changed, 392 insertions(+), 1 deletion(-)
diff --git a/app/test/test_soc.c b/app/test/test_soc.c
index ac03e64..4eb8146 100644
--- a/app/test/test_soc.c
+++ b/app/test/test_soc.c
@@ -87,14 +87,45 @@ static int test_compare_addr(void)
*/
struct test_wrapper {
struct rte_soc_driver soc_drv;
+ struct rte_soc_device soc_dev;
};
+static int empty_pmd0_devinit(struct rte_soc_driver *drv,
+ struct rte_soc_device *dev);
+static int empty_pmd0_devuninit(struct rte_soc_device *dev);
+static void test_soc_scan_dev0_cb(void);
+static int test_soc_match_dev0_cb(struct rte_soc_driver *drv,
+ struct rte_soc_device *dev);
+static void test_soc_scan_dev1_cb(void);
+static int test_soc_match_dev1_cb(struct rte_soc_driver *drv,
+ struct rte_soc_device *dev);
+
+static int
+empty_pmd0_devinit(struct rte_soc_driver *drv __rte_unused,
+ struct rte_soc_device *dev __rte_unused)
+{
+ return 0;
+}
+
+static int
+empty_pmd0_devuninit(struct rte_soc_device *dev)
+{
+ /* Release the memory associated with dev->addr.name */
+ free(dev->addr.name);
+
+ return 0;
+}
+
struct test_wrapper empty_pmd0 = {
.soc_drv = {
.driver = {
.name = "empty_pmd0"
},
- },
+ .devinit = empty_pmd0_devinit,
+ .devuninit = empty_pmd0_devuninit,
+ .scan_fn = test_soc_scan_dev0_cb,
+ .match_fn = test_soc_match_dev0_cb,
+ }
};
struct test_wrapper empty_pmd1 = {
@@ -102,9 +133,54 @@ struct test_wrapper empty_pmd1 = {
.driver = {
.name = "empty_pmd1"
},
+ .scan_fn = test_soc_scan_dev1_cb,
+ .match_fn = test_soc_match_dev1_cb,
},
};
+static void
+test_soc_scan_dev0_cb(void)
+{
+ /* SoC's scan would scan devices on its bus and add to
+* soc_device_list
+*/
+ empty_pmd0.soc_dev.addr.name = strdup("empty_pmd0_dev");
+
+ TAILQ_INSERT_TAIL(_device_list, _pmd0.soc_dev, next);
+}
+
+static int
+test_soc_match_dev0_cb(struct rte_soc_driver *drv __rte_unused,
+ struct rte_soc_device *dev)
+{
+ if (!dev->addr.name || strcmp(dev->addr.name, "empty_pmd0_dev"))
+ return 0;
+
+ return 1;
+}
+
+
+static void
+test_soc_scan_dev1_cb(void)
+{
+ /* SoC's scan would scan devices on its bus and add to
+* soc_device_list
+*/
+ empty_pmd0.soc_dev.addr.name = strdup("empty_pmd1_dev");
+
+ TAILQ_INSERT_TAIL(_device_list, _pmd1.soc_dev, next);
+}
+
+static int
+test_soc_match_dev1_cb(struct rte_soc_driver *drv __rte_unused,
+ struct rte_soc_device *dev)
+{
+ if (!dev->addr.name || strcmp(dev->addr.name, "empty_pmd1_dev"))
+ return 0;
+
+ return 1;
+}
+
static int
count_registered_socdrvs(void)
{
@@ -148,13 +224,54 @@ test_register_unregister(void)
return 0;
}
+/* Test Probe (scan and match) functionality */
+static int
+test_soc_init_and_probe(void)
+{
+ struct rte_soc_driver *drv;
+
+ /* Registering dummy drivers */
+ rte_eal_soc_register(_pmd0.soc_drv);
+ rte_eal_soc_register(_pmd1.soc_drv);
+ /* Assuming that test_register_unregister is working, not verifying
+* that drivers are indeed registered
+ */
+
+ /* rte_eal_soc_init is called by rte_eal_init, which in turn calls the
+* scan_fn of each driver.
+*/
+ TAILQ_FOREACH(drv, _driver_list, next) {
+ if (drv && drv->scan_fn)
+ drv->scan_fn();
+ }
+
+ /* rte_eal_init() would perform other inits here */
+
+ /* Probe would link the SoC devices<=>drivers */
+ rte_eal_soc_probe();
+
+ /* Unregistering dummy drivers */
+ rte_eal_soc_unregister(_pmd0.soc_drv);
+ rte_eal_soc_unregister(_pmd1.soc_drv);
+
+ free(empty_pmd0.soc_dev.addr.name);
+
+ printf("%s has been successful\n", __func__);
+ return 0;
+}
+
/* save
[dpdk-dev] [PATCH v2 05/14] eal/soc: init SoC infra from EAL
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/bsdapp/eal/Makefile| 1 +
lib/librte_eal/bsdapp/eal/eal.c | 4 +++
lib/librte_eal/bsdapp/eal/eal_soc.c | 46
lib/librte_eal/common/eal_private.h | 10 +++
lib/librte_eal/linuxapp/eal/Makefile | 1 +
lib/librte_eal/linuxapp/eal/eal.c | 3 ++
lib/librte_eal/linuxapp/eal/eal_soc.c | 56 +++
7 files changed, 121 insertions(+)
create mode 100644 lib/librte_eal/bsdapp/eal/eal_soc.c
create mode 100644 lib/librte_eal/linuxapp/eal/eal_soc.c
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index 5a3fc1d..cf4bf78 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -57,6 +57,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_hugepage_info.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_thread.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_log.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_pci.c
+SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_soc.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_debug.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_lcore.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_timer.c
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index a0c8f8c..7d8c3e8 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -567,6 +568,9 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_pci_init() < 0)
rte_panic("Cannot init PCI\n");
+ if (rte_eal_soc_init() < 0)
+ rte_panic("Cannot init SoC\n");
+
eal_check_mem_on_local_socket();
if (eal_plugins_init() < 0)
diff --git a/lib/librte_eal/bsdapp/eal/eal_soc.c
b/lib/librte_eal/bsdapp/eal/eal_soc.c
new file mode 100644
index 000..cb297ff
--- /dev/null
+++ b/lib/librte_eal/bsdapp/eal/eal_soc.c
@@ -0,0 +1,46 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 RehiveTech. 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 RehiveTech 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
+#include
+#include
+#include
+
+#include
+
+/* Init the SoC EAL subsystem */
+int
+rte_eal_soc_init(void)
+{
+ return 0;
+}
diff --git a/lib/librte_eal/common/eal_private.h
b/lib/librte_eal/common/eal_private.h
index df6582d..ba8407d 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -130,6 +130,16 @@ int rte_eal_pci_init(void);
struct rte_soc_driver;
struct rte_soc_device;
+/**
+ * Init the SoC infra.
+ *
+ * This function is private to EAL.
+ *
+ * @return
+ * 0 on success, negative on error
+ */
+int rte_eal_soc_init(void);
+
struct rte_pci_driver;
struct rte_pci_device;
diff --git a/lib/librte_eal/linuxapp/eal/Makefile
b/lib/librte_eal/linuxapp/eal/Makefile
index a520477..59e30fa 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -65,6 +65,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_vfio_mp_sync.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci_uio.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci_vfio.c
+SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_soc.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_debug.c
[dpdk-dev] [PATCH v2 04/14] eal: introduce --no-soc option
This option has the same meaning for the SoC infra as the --no-pci
for the PCI infra.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/common/eal_common_options.c | 5 +
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h| 2 ++
3 files changed, 8 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 1a1bab3..d97cf0a 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -85,6 +85,7 @@ eal_long_options[] = {
{OPT_NO_HPET, 0, NULL, OPT_NO_HPET_NUM },
{OPT_NO_HUGE, 0, NULL, OPT_NO_HUGE_NUM },
{OPT_NO_PCI,0, NULL, OPT_NO_PCI_NUM },
+ {OPT_NO_SOC,0, NULL, OPT_NO_SOC_NUM },
{OPT_NO_SHCONF, 0, NULL, OPT_NO_SHCONF_NUM},
{OPT_PCI_BLACKLIST, 1, NULL, OPT_PCI_BLACKLIST_NUM},
{OPT_PCI_WHITELIST, 1, NULL, OPT_PCI_WHITELIST_NUM},
@@ -855,6 +856,10 @@ eal_parse_common_option(int opt, const char *optarg,
conf->no_pci = 1;
break;
+ case OPT_NO_SOC_NUM:
+ conf->no_soc = 1;
+ break;
+
case OPT_NO_HPET_NUM:
conf->no_hpet = 1;
break;
diff --git a/lib/librte_eal/common/eal_internal_cfg.h
b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..3a98e94 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -67,6 +67,7 @@ struct internal_config {
unsigned hugepage_unlink; /**< true to unlink backing files */
volatile unsigned xen_dom0_support; /**< support app running on Xen
Dom0*/
volatile unsigned no_pci; /**< true to disable PCI */
+ volatile unsigned no_soc; /**< true to disable SoC */
volatile unsigned no_hpet;/**< true to disable HPET */
volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping
* instead of native TSC */
diff --git a/lib/librte_eal/common/eal_options.h
b/lib/librte_eal/common/eal_options.h
index a881c62..ba1e704 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -69,6 +69,8 @@ enum {
OPT_NO_HUGE_NUM,
#define OPT_NO_PCI"no-pci"
OPT_NO_PCI_NUM,
+#define OPT_NO_SOC"no-soc"
+ OPT_NO_SOC_NUM,
#define OPT_NO_SHCONF "no-shconf"
OPT_NO_SHCONF_NUM,
#define OPT_SOCKET_MEM"socket-mem"
--
2.7.4
[dpdk-dev] [PATCH v2 03/14] eal/soc: Implement SoC device list and dump
SoC devices would be linked in a separate list (from PCI). This is used for
probe function.
A helper for dumping the device list is added.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 ++
lib/librte_eal/common/eal_common_soc.c | 34 +
lib/librte_eal/common/include/rte_soc.h | 9 +++
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 ++
4 files changed, 47 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index cda8009..de38848 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -169,7 +169,9 @@ DPDK_16.11 {
rte_eal_dev_attach;
rte_eal_dev_detach;
soc_driver_list;
+ soc_device_list
rte_eal_soc_register;
rte_eal_soc_unregister;
+ rte_eal_soc_dump;
} DPDK_16.07;
diff --git a/lib/librte_eal/common/eal_common_soc.c
b/lib/librte_eal/common/eal_common_soc.c
index 56135ed..5dcddc5 100644
--- a/lib/librte_eal/common/eal_common_soc.c
+++ b/lib/librte_eal/common/eal_common_soc.c
@@ -31,6 +31,8 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include
+#include
#include
#include
@@ -40,6 +42,38 @@
/* Global SoC driver list */
struct soc_driver_list soc_driver_list =
TAILQ_HEAD_INITIALIZER(soc_driver_list);
+struct soc_device_list soc_device_list =
+ TAILQ_HEAD_INITIALIZER(soc_device_list);
+
+/* dump one device */
+static int
+soc_dump_one_device(FILE *f, struct rte_soc_device *dev)
+{
+ int i;
+
+ fprintf(f, "%s", dev->addr.name);
+ fprintf(f, " - fdt_path: %s\n",
+ dev->addr.fdt_path ? dev->addr.fdt_path : "(none)");
+
+ for (i = 0; dev->id && dev->id[i].compatible; ++i)
+ fprintf(f, " %s\n", dev->id[i].compatible);
+
+ return 0;
+}
+
+/* dump devices on the bus to an output stream */
+void
+rte_eal_soc_dump(FILE *f)
+{
+ struct rte_soc_device *dev = NULL;
+
+ if (!f)
+ return;
+
+ TAILQ_FOREACH(dev, _device_list, next) {
+ soc_dump_one_device(f, dev);
+ }
+}
/* register a driver */
void
diff --git a/lib/librte_eal/common/include/rte_soc.h
b/lib/librte_eal/common/include/rte_soc.h
index 16c5a1b..c6f98eb 100644
--- a/lib/librte_eal/common/include/rte_soc.h
+++ b/lib/librte_eal/common/include/rte_soc.h
@@ -56,8 +56,12 @@ extern "C" {
extern struct soc_driver_list soc_driver_list;
/**< Global list of SoC Drivers */
+extern struct soc_device_list soc_device_list;
+/**< Global list of SoC Devices */
TAILQ_HEAD(soc_driver_list, rte_soc_driver); /**< SoC drivers in D-linked Q. */
+TAILQ_HEAD(soc_device_list, rte_soc_device); /**< SoC devices in D-linked Q. */
+
struct rte_soc_id {
const char *compatible; /**< OF compatible specification */
@@ -142,6 +146,11 @@ rte_eal_compare_soc_addr(const struct rte_soc_addr *a0,
}
/**
+ * Dump discovered SoC devices.
+ */
+void rte_eal_soc_dump(FILE *f);
+
+/**
* Register a SoC driver.
*/
void rte_eal_soc_register(struct rte_soc_driver *driver);
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index 66c1258..b9d1932 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -175,7 +175,9 @@ DPDK_16.11 {
rte_eal_vdrv_register;
rte_eal_vdrv_unregister;
soc_driver_list;
+ soc_device_list;
rte_eal_soc_register;
rte_eal_soc_unregister;
+ rte_eal_soc_dump;
} DPDK_16.07;
--
2.7.4
[dpdk-dev] [PATCH v2 02/14] eal/soc: add rte_eal_soc_register/unregister logic
Registeration of a SoC driver through a helper DRIVER_REGISTER_SOC
(on the lines of DRIVER_REGISTER_PCI). soc_driver_list stores all the
registered drivers.
Test case has been introduced to verify the registration and
deregistration.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
app/test/test_soc.c | 111
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 4 +
lib/librte_eal/common/eal_common_soc.c | 56
lib/librte_eal/common/include/rte_soc.h | 26 ++
lib/librte_eal/linuxapp/eal/Makefile| 1 +
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 3 +
6 files changed, 201 insertions(+)
create mode 100644 lib/librte_eal/common/eal_common_soc.c
diff --git a/app/test/test_soc.c b/app/test/test_soc.c
index 916a863..ac03e64 100644
--- a/app/test/test_soc.c
+++ b/app/test/test_soc.c
@@ -75,6 +75,108 @@ static int test_compare_addr(void)
free(a2.name);
free(a1.name);
free(a0.name);
+
+ return 0;
+}
+
+/**
+ * Empty PMD driver based on the SoC infra.
+ *
+ * The rte_soc_device is usually wrapped in some higher-level struct
+ * (eth_driver). We simulate such a wrapper with an anonymous struct here.
+ */
+struct test_wrapper {
+ struct rte_soc_driver soc_drv;
+};
+
+struct test_wrapper empty_pmd0 = {
+ .soc_drv = {
+ .driver = {
+ .name = "empty_pmd0"
+ },
+ },
+};
+
+struct test_wrapper empty_pmd1 = {
+ .soc_drv = {
+ .driver = {
+ .name = "empty_pmd1"
+ },
+ },
+};
+
+static int
+count_registered_socdrvs(void)
+{
+ int i;
+ struct rte_soc_driver *drv;
+
+ i = 0;
+ TAILQ_FOREACH(drv, _driver_list, next)
+ i += 1;
+
+ return i;
+}
+
+static int
+test_register_unregister(void)
+{
+ struct rte_soc_driver *drv;
+ int count;
+
+ rte_eal_soc_register(_pmd0.soc_drv);
+
+ TEST_ASSERT(!TAILQ_EMPTY(_driver_list),
+ "No PMD is present but the empty_pmd0 should be there");
+ drv = TAILQ_FIRST(_driver_list);
+ TEST_ASSERT(!strcmp(drv->driver.name, "empty_pmd0"),
+ "The registered PMD is not empty_pmd0 but '%s'",
+ drv->driver.name);
+
+ rte_eal_soc_register(_pmd1.soc_drv);
+
+ count = count_registered_socdrvs();
+ TEST_ASSERT_EQUAL(count, 2, "Expected 2 PMDs but detected %d", count);
+
+ rte_eal_soc_unregister(_pmd0.soc_drv);
+ count = count_registered_socdrvs();
+ TEST_ASSERT_EQUAL(count, 1, "Expected 1 PMDs but detected %d", count);
+
+ rte_eal_soc_unregister(_pmd1.soc_drv);
+
+ printf("%s has been successful\n", __func__);
+ return 0;
+}
+
+/* save real devices and drivers until the tests finishes */
+struct soc_driver_list real_soc_driver_list =
+ TAILQ_HEAD_INITIALIZER(real_soc_driver_list);
+
+static int test_soc_setup(void)
+{
+ struct rte_soc_driver *drv;
+
+ /* no real drivers for the test */
+ while (!TAILQ_EMPTY(_driver_list)) {
+ drv = TAILQ_FIRST(_driver_list);
+ rte_eal_soc_unregister(drv);
+ TAILQ_INSERT_TAIL(_soc_driver_list, drv, next);
+ }
+
+ return 0;
+}
+
+static int test_soc_cleanup(void)
+{
+ struct rte_soc_driver *drv;
+
+ /* bring back real drivers after the test */
+ while (!TAILQ_EMPTY(_soc_driver_list)) {
+ drv = TAILQ_FIRST(_soc_driver_list);
+ TAILQ_REMOVE(_soc_driver_list, drv, next);
+ rte_eal_soc_register(drv);
+ }
+
return 0;
}
@@ -84,6 +186,15 @@ test_soc(void)
if (test_compare_addr())
return -1;
+ if (test_soc_setup())
+ return -1;
+
+ if (test_register_unregister())
+ return -1;
+
+ if (test_soc_cleanup())
+ return -1;
+
return 0;
}
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 7b3d409..cda8009 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -168,4 +168,8 @@ DPDK_16.11 {
rte_eal_dev_attach;
rte_eal_dev_detach;
+ soc_driver_list;
+ rte_eal_soc_register;
+ rte_eal_soc_unregister;
+
} DPDK_16.07;
diff --git a/lib/librte_eal/common/eal_common_soc.c
b/lib/librte_eal/common/eal_common_soc.c
new file mode 100644
index 000..56135ed
--- /dev/null
+++ b/lib/librte_eal/common/eal_common_soc.c
@@ -0,0 +1,56 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 RehiveTech. 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:
+ *
+ * *
[dpdk-dev] [PATCH v2 01/14] eal/soc: introduce very essential SoC infra definitions
Define initial structures and functions for the SoC infrastructure.
This patch supports only a very minimal functions for now.
More features will be added in the following commits.
Includes rte_device/rte_driver inheritance of
rte_soc_device/rte_soc_driver.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
app/test/Makefile | 1 +
app/test/test_soc.c | 90 +
lib/librte_eal/common/Makefile | 2 +-
lib/librte_eal/common/eal_private.h | 4 +
lib/librte_eal/common/include/rte_soc.h | 138
5 files changed, 234 insertions(+), 1 deletion(-)
create mode 100644 app/test/test_soc.c
create mode 100644 lib/librte_eal/common/include/rte_soc.h
diff --git a/app/test/Makefile b/app/test/Makefile
index 611d77a..64b261d 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -77,6 +77,7 @@ APP = test
#
SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) := commands.c
SRCS-y += test.c
+SRCS-y += test_soc.c
SRCS-y += resource.c
SRCS-y += test_resource.c
test_resource.res: test_resource.c
diff --git a/app/test/test_soc.c b/app/test/test_soc.c
new file mode 100644
index 000..916a863
--- /dev/null
+++ b/app/test/test_soc.c
@@ -0,0 +1,90 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 RehiveTech. 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 RehiveTech 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
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "test.h"
+
+static char *safe_strdup(const char *s)
+{
+ char *c = strdup(s);
+
+ if (c == NULL)
+ rte_panic("failed to strdup '%s'\n", s);
+
+ return c;
+}
+
+static int test_compare_addr(void)
+{
+ struct rte_soc_addr a0;
+ struct rte_soc_addr a1;
+ struct rte_soc_addr a2;
+
+ a0.name = safe_strdup("ethernet0");
+ a0.fdt_path = NULL;
+
+ a1.name = safe_strdup("ethernet0");
+ a1.fdt_path = NULL;
+
+ a2.name = safe_strdup("ethernet1");
+ a2.fdt_path = NULL;
+
+ TEST_ASSERT(!rte_eal_compare_soc_addr(, ),
+ "Failed to compare two soc addresses that equal");
+ TEST_ASSERT(rte_eal_compare_soc_addr(, ),
+ "Failed to compare two soc addresses that differs");
+
+ free(a2.name);
+ free(a1.name);
+ free(a0.name);
+ return 0;
+}
+
+static int
+test_soc(void)
+{
+ if (test_compare_addr())
+ return -1;
+
+ return 0;
+}
+
+REGISTER_TEST_COMMAND(soc_autotest, test_soc);
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index dfd64aa..b414008 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -33,7 +33,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_log.h rte_memory.h rte_memzone.h rte_soc.h rte_pci.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
diff --git a/lib/librte_eal/common/eal_private.h
b/lib/librte_eal/common/eal_private.h
index 431d6c2..df6582d 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -36,6 +36,7 @@
#include
#include
+#include
/**
[dpdk-dev] [PATCH v2 00/14] Introduce SoC device/driver framework for EAL
Introduction: = This patch set is direct derivative of Jan's original series [1],[2]. (Confirmed offline with Jan before posting.) - As this deviates substantially from original series, if need be I can post it as a separate patch rather than v2. Please suggest. - Also, there are comments on original v1 ([4]) which are _not_ incorporated in this series as they refer to section no more in new version. - Initial set also contains certain patches to generalize some PCI specific structures and function to common EAL ([6,7,8,9]. Those patches I'll post separately as they are good changes (in my opinion) and not related to SoC framework. It is built over the series [3] which introduces device structures for rte_driver/rte_device for generalizing devices into PCI, VDEV, XXX. For the purpose of this patchset, XXX=>SOC. Aim: As of now EAL is primarly focused on PCI initialization/probing. rte_eal_init() |- rte_eal_pci_init(): Find PCI devices from sysfs |- ... |- rte_eal_memzone_init() |- ... `- rte_eal_pci_probe(): Driver<=>Device initialization This patchset introduces SoC framework which would enable SoC drivers and drivers to be plugged into EAL, very similar to how PCI drivers/devices are done today. This is a stripped down version of PCI framework which allows the SoC PMDs to implement their own routines for detecting devices and linking devices to drivers. 1) Changes to EAL rte_eal_init() |- rte_eal_pci_init(): Find PCI devices from sysfs |- rte_eal_soc_init(): Calls PMDs->scan_fn |- ... |- rte_eal_memzone_init() |- ... |- rte_eal_pci_probe(): Driver<=>Device initialization, PMD->devinit() `- rte_eal_soc_probe(): Calls PMDs->match_fn and PMDs->devinit(); 2) New device/driver structures: - rte_soc_driver (inheriting rte_driver) - rte_soc_device (inheriting rte_device) - rte_eth_dev and eth_driver embedded rte_soc_device and rte_soc_driver, respectively. 3) The SoC PMDs need to: - define rte_soc_driver with necessary scan and match callbacks - Register themselves using DRIVER_REGISTER_SOC() - Implement respective bus scanning in the scan callbacks to add necessary devices to SoC device list - Implement necessary eth_dev_init/uninint for ethernet instances 4) Design considerations that are same as PCI: - SoC initialization is being done through rte_eal_init(), just after PCI initialization is done. - As in case of PCI, probe is done after rte_eal_pci_probe() to link the devices detected with the drivers registered. - Device attach/detach functions are available and have been designed on the lines of PCI framework. - PMDs register using DRIVER_REGISTER_SOC, very similar to DRIVER_REGISTER_PCI for PCI devices. - Linked list of SoC driver and devices exists independent of the other driver/device list, but inheriting rte_driver/rte_driver, these are also part of a global list. 5) Design considerations that are different from PCI: - Each driver implements its own scan and match function. PCI uses the BDF format to read the device from sysfs, but this _may_not_ be a case for a SoC ethernet device. = This is an important change from initial proposal by Jan in [2]. Unlike his attempt to use /sys/bus/platform, this patch relies on the PMD to detect the devices. This is because SoC may require specific or additional info for device detection. Further, SoC may have embedded devices/MACs which require initialization which cannot be covered through sysfs parsing. = PCI based PMDs rely on EAL's capability to detect devices. This proposal puts the onus on PMD to detect devices, add to soc_device_list and wait for Probe. Matching, of device<=>driver is again PMD's callback. Patchset Overview: == - Patches 0001~0003 introduce the base infrastructure and test case - Patch 0004 is for command line support for no-soc, on lines of no-pci - Patch 0005 enables EAL to handle SoC type devices - Patch 0006 adds support for scan and probe callbacks and updates the test framework with relevant test case. - Patch 0007~0009 enable device argument, driver specific flags and interrupt handling related basic infra. Subsequent patches build up on them. - Patch 0010~0013 makes changes to PCI as well as ethdev code to remove assumption that eth_driver is a PCI driver. - Patch 0014 adds necessary ethdev probe/remove functions for PMDs to use Future/Pending Changes: === - Device whitelisting/blacklist still relies on command line '-b' and '-c' which are internally implemented using OPT_PCI_BLACKLIST/OPT_PCI_WHITELIST. This needs to be changed to a generic form - OPT_DEV_*LIST - probably. [1] http://dpdk.org/ml/archives/dev/2016-January/030915.html [2] http://www.dpdk.org/ml/archives/dev/2016-May/038486.html [3] http://dpdk.org/ml/archives/dev/2016-August/045707.html [4]
[dpdk-dev] [E1000-devel] Unsupported SFP+ Module - Hardware Initialization Failure -19
The error value of -19 means your EEPROM indicates you're NIC doesn't have support for your SFP+ module. So you're correct this isn't specifically a DPDK issue, the code that verifies this is shared both between the Linux driver as well as DPDK. There are two possible cases here 1) we recognize the module but it isn't supported or 2) we don't know what the module is. If it was the first case then for the out of tree linux driver you could use the module parameter "allow_unsupported_sfp" to get around this check. Of course turning on this option produces the following rather scary log message: "WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules. Thanks, -Don Skidmore > -Original Message- > From: Ajit Khaparde [mailto:ajit.khaparde at broadcom.com] > Sent: Tuesday, August 30, 2016 7:22 PM > To: Alex Forster ; e1000-devel at > lists.sourceforge.net > Cc: dev at dpdk.org > Subject: Re: [E1000-devel] [dpdk-dev] Unsupported SFP+ Module - Hardware > Initialization Failure -19 > > On Tue, Aug 30, 2016 at 11:02 AM, Alex Forster > wrote: > > > Hi guys, > > > > I have a problem again that I had about a year ago[1]. My Finisar > > FTL410QE2C (multimode QSFP) transceivers aren?t working with my Intel > > X520-QDA1?s. I have 7 servers, each with two X520?s and two QSFP > > transceivers in them, totaling 14 NICs and transceivers, and all of > > them fail with the same error: Unsupported SFP+ Module / Hardware > > Initialization > > Failure: -19. > > > > This doesn?t appear to be specifically a DPDK issue, but rather an > > IXGBE issue, since (a) the stock Debian 8 IXGBE, (b) the latest out of > > tree IXGBE, and (c) DPDK?s copy of IXGBE all fail in this same way. > > I?m happy to take this to an IXGBE mailing list if somebody can point > > me to one, but just in case anyone here can help, here?s the info I?ve > > gathered? > > > > * The exact function where IXGBE bails is here, annotated with the > > values read from the transceiver?s EEPROMs: > > https://www.googledrive.com/ host/0B_-81lR_g8lyNDJ6QkkxS28yQzQ > > * I?ve modified DPDK?s copy of IXGBE to dump the whole EEPROM of these > > transceivers, which are here: https://gist.github.com/alexforster/ > > 5da30cd89d49877d5d6908e9628baee8 > > > > Here?s (I think) an important part: Last time I had this problem, I > > only had one server, and one of the two transceivers worked. I fixed > > the other transceiver in that server by replacing it with an identical > > model. Now, suddenly, neither of those transceivers (which have worked > > for ~11 months) are recognized. I don?t know how I could have done > > something that would have affected the EEPROM output, but I suspect I may > have. > > > > Anybody able to offer any advice? > > > > Alex Forster > > > > [1] http://dpdk.org/ml/archives/dev/2015-October/024973.html > > > Adding e1000-devel at lists.sourceforge.net
[dpdk-dev] [PATCH v2] kni: support RHEL 6.8
Add support for RHEL6.8 which uses an old version of kernel with some new features backported. Signed-off-by: Ferruh Yigit --- lib/librte_eal/linuxapp/kni/compat.h| 13 + lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 13 + lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h | 12 3 files changed, 38 insertions(+) diff --git a/lib/librte_eal/linuxapp/kni/compat.h b/lib/librte_eal/linuxapp/kni/compat.h index 647ba3c..962a4e7 100644 --- a/lib/librte_eal/linuxapp/kni/compat.h +++ b/lib/librte_eal/linuxapp/kni/compat.h @@ -38,3 +38,16 @@ #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 7, 0) #define HAVE_TRANS_START_HELPER #endif + +/* + * KNI uses NET_NAME_UNKNOWN macro to select correct version of alloc_netdev() + * For old kernels just backported the commit that enables the macro + * (685343fc3ba6) but still uses old API, it is required to undefine macro to + * select correct version of API, this is safe since KNI doesn't use the value. + * This fix is specific to RedHat/CentOS kernels. + */ +#if (defined(RHEL_RELEASE_CODE) && \ + (RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(6, 8)) && \ + (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34))) +#undef NET_NAME_UNKNOWN +#endif diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h index bdd0806..25ac41b 100644 --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h @@ -3915,4 +3915,17 @@ skb_set_hash(struct sk_buff *skb, __u32 hash, __always_unused int type) /* ndo_bridge_getlink adds new filter_mask and vlan_fill parameters */ #define HAVE_NDO_BRIDGE_GETLINK_FILTER_MASK_VLAN_FILL #endif /* >= 4.2.0 */ + +/* + * vlan_tx_tag_* macros renamed to skb_vlan_tag_* (Linux commit: df8a39defad4) + * For older kernels backported this commit, need to use renamed functions. + * This fix is specific to RedHat/CentOS kernels. + */ +#if (defined(RHEL_RELEASE_CODE) && \ + (RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(6, 8)) && \ + (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34))) +#define vlan_tx_tag_get skb_vlan_tag_get +#define vlan_tx_tag_present skb_vlan_tag_present +#endif + #endif /* _KCOMPAT_H_ */ diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h index 39ae42c..4c7a640 100644 --- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h +++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h @@ -3140,4 +3140,16 @@ static inline int __kc_pci_vfs_assigned(struct pci_dev *dev) #define SET_ETHTOOL_OPS(netdev, ops) ((netdev)->ethtool_ops = (ops)) #endif /* >= 3.16.0 */ +/* + * vlan_tx_tag_* macros renamed to skb_vlan_tag_* (Linux commit: df8a39defad4) + * For older kernels backported this commit, need to use renamed functions. + * This fix is specific to RedHat/CentOS kernels. + */ +#if (defined(RHEL_RELEASE_CODE) && \ + RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(6, 8) && \ + LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 34)) +#define vlan_tx_tag_get skb_vlan_tag_get +#define vlan_tx_tag_present skb_vlan_tag_present +#endif + #endif /* _KCOMPAT_H_ */ -- 2.7.4
[dpdk-dev] meter: excess token bucket update in srtcm
Hi, As per srTCM RFC 2697, we should be updating the E bucket only after the C bucket overflows. "Thereafter, the token counts Tc and Te are updated CIR times per second as follows: o If Tc is less than CBS, Tc is incremented by one, else o if Te is less then EBS, Te is incremented by one, else o neither Tc nor Te is incremented." However in the current DPDK implementation of srTCM, we are updating both the buckets simultaneously at the same rate (CIR). This will result in a token accumulation rate of (2*CIR). This seems like a bug to me. Can you confirm this? Nikhil
[dpdk-dev] [PATCH] kni: error release device list head could cause a kernel crash.
On 8/8/2016 12:48 PM, Ferruh Yigit wrote: > Hi, > > On 8/6/2016 12:19 PM, ??? wrote: >> From 3edca1e3194959ba26a6c36143f8423009661b11 Mon Sep 17 00:00:00 2001 >> From: zhouyangchao >> Date: Sat, 6 Aug 2016 19:14:51 +0800 >> Subject: [PATCH] kni: error release device list head could cause a kernel >> crash. >> >> Signed-off-by: zhouyangchao >> --- >> lib/librte_eal/linuxapp/kni/kni_misc.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c >> b/lib/librte_eal/linuxapp/kni/kni_misc.c >> index ae8133f..a49924b 100644 >> --- a/lib/librte_eal/linuxapp/kni/kni_misc.c >> +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c >> @@ -276,8 +276,8 @@ kni_release(struct inode *inode, struct file *file) >> #ifdef RTE_KNI_VHOST >> kni_vhost_backend_release(dev); >> #endif >> - kni_dev_remove(dev); >> list_del(>list); >> + kni_dev_remove(dev); >> } >> up_write(>kni_list_lock); >> >> @@ -613,8 +613,8 @@ kni_ioctl_release(struct net *net, >> #ifdef RTE_KNI_VHOST >> kni_vhost_backend_release(dev); >> #endif >> - kni_dev_remove(dev); >> list_del(>list); >> + kni_dev_remove(dev); >> ret = 0; >> break; >> } >> -- >> > > Can you please describe how crash can occur? > And if you have a crash log, can you include it? > > Access to device via list, removing device from list and adding device > to list all are protected by lock (kni_list_lock), so as far as I can > see the order of removing device and removing it from list shouldn't be > a problem. I have sent a patch to fix a crash in remove path, if you are working on master branch this can be same issue, can you please check following patch: http://dpdk.org/dev/patchwork/patch/15571/ Regards, ferruh
[dpdk-dev] 17.02 Roadmap
2016-08-31 10:31, O'Driscoll, Tim: > Below are the features that we're planning to submit for the 17.02 > release. We'll submit a patch to update the roadmap page with this info. > > Some things will obviously change during planning/development, so we'll > provide a more detailed update in late September/early October. > After that, things should hopefully be relatively stable. > > It would be good if others are also willing to share their plans so > that we can build up a complete picture of what's planned for 17.02 > and make sure there's no duplication. Thanks Tim. I would like to stress that it would be really better to know the intents of the other contributors.
[dpdk-dev] [PATCH] kni: fix crash for KNI interface remove
Removing KNI interface that has no PCI driver for ethtool support cause
kernel crash.
Fixes: 109febfe58f9 ("net/igb: move PCI device IDs from EAL")
Fixes: 221fba3b987c ("net/ixgbe: move PCI device IDs from EAL")
Signed-off-by: Ferruh Yigit
---
lib/librte_eal/linuxapp/kni/kni_misc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index 41a331f..acb961f 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -355,10 +355,12 @@ kni_dev_remove(struct kni_dev *dev)
if (!dev)
return -ENODEV;
- if (pci_match_id(ixgbe_pci_tbl, dev->pci_dev))
- ixgbe_kni_remove(dev->pci_dev);
- else if (pci_match_id(igb_pci_tbl, dev->pci_dev))
- igb_kni_remove(dev->pci_dev);
+ if (dev->pci_dev) {
+ if (pci_match_id(ixgbe_pci_tbl, dev->pci_dev))
+ ixgbe_kni_remove(dev->pci_dev);
+ else if (pci_match_id(igb_pci_tbl, dev->pci_dev))
+ igb_kni_remove(dev->pci_dev);
+ }
if (dev->net_dev) {
unregister_netdev(dev->net_dev);
--
2.7.4
[dpdk-dev] [PATCH v6 2/9] acl: add altivec intrinsics for dpdk acl on ppc_64
> > This patch adds port for ACL library in ppc64le. > > Signed-off-by: Gowrishankar Muthukrishnan linux.vnet.ibm.com> > --- > app/test-acl/main.c | 4 + > config/defconfig_ppc_64-power8-linuxapp-gcc | 1 - > lib/librte_acl/Makefile | 2 + > lib/librte_acl/acl.h| 4 + > lib/librte_acl/acl_run.h| 2 + > lib/librte_acl/acl_run_altivec.c| 47 > lib/librte_acl/acl_run_altivec.h| 329 > > lib/librte_acl/rte_acl.c| 13 ++ > lib/librte_acl/rte_acl.h| 1 + > 9 files changed, 402 insertions(+), 1 deletion(-) create mode 100644 > lib/librte_acl/acl_run_altivec.c create mode 100644 > lib/librte_acl/acl_run_altivec.h > I am not a ppc expert, and I don't have ppc HW to try, But from IA perspective - all looks good. Acked-by: Konstantin Ananyev
[dpdk-dev] [PATCH 0/6] add Tx preparation
> > On Fri, 26 Aug 2016 18:22:52 +0200 > Tomasz Kulasek wrote: > > > As discussed in that thread: > > > > http://dpdk.org/ml/archives/dev/2015-September/023603.html > > > > Different NIC models depending on HW offload requested might impose > > different requirements on packets to be TX-ed in terms of: > > > > - Max number of fragments per packet allowed > > - Max number of fragments per TSO segments > > - The way pseudo-header checksum should be pre-calculated > > - L3/L4 header fields filling > > - etc. > > > > > > MOTIVATION: > > --- > > > > 1) Some work cannot (and didn't should) be done in rte_eth_tx_burst. > >However, this work is sometimes required, and now, it's an > >application issue. > > Why not? You are adding an additional API burden on every application. > > > > > 2) Different hardware may have different requirements for TX offloads, > >other subset can be supported and so on. > > These need to be reported by API so that application can handle it. If you read the patch description, you'll see that we do both: - provide tx_prep() - "2) Also new fields will be introduced in rte_eth_desc_lim: nb_seg_max and nb_mtu_seg_max, providing an information about max segments in TSO and non-TSO packets acceptable by device. This information is useful for application to not create/limit malicious packet." > Doing these transformations in tx_prep seems late in the process. Why is that? It is totally up to the application to decide ahat stage it wants to call tx_prep() for each packet - just after it formed and mbuf to be TX-ed, or just before calling tx_burst() for it, or somewhere in btetween. > > > > > 3) Some parameters (e.g. number of segments in ixgbe driver) may hung > >device. These parameters may be vary for different devices. > > > >For example i40e HW allows 8 fragments per packet, but that is after > >TSO segmentation. While ixgbe has a 38-fragment pre-TSO limit. > > Seems better to handle these limits as exceptions in i40e_tx_burst etc; > rather than a pre-step. Look at how Linux driver API works, several > drivers have to have an exception linearize path. Hmm, doesn't it contradicts with your statement above: ' Doing these transformations in tx_prep seems late in the process.'? :) I suppose we all know that Linux kernel driver and DPDK PMD usage model is quite different. As a rule of thumb we try to avoid modifying packet data inside the tx_burst() itself. Having this functionality in a different function gives upper layer a choice when it is better to modify packet contents and hopefully hide/minimize memory access latencies. > > > > > 4) Fields in packet may require different initialization (like e.g. will > >require pseudo-header checksum precalculation, sometimes in a > >different way depending on packet type, and so on). Now application > >needs to care about it. > > Once again, the driver should do this in Tx. Once again, I really doubt it should. > > > > > > 5) Using additional API (rte_eth_tx_prep) before rte_eth_tx_burst let to > >prepare packet burst in acceptable form for specific device. > > > > 6) Some additional checks may be done in debug mode keeping tx_burst > >implementation clean. > > Most of this could be done by refactoring existing tx_burst in drivers. > Much of the code seems to be written as the "let's write a 2000 line function > because that is most efficient" rather than "let's write small > steps and let the compiler optimize it" I don't see how that could be easily done inside tx_burst() without signifcatn performance loss. Especially if we have a pipeline model, when we have one or several t produce mbufs to be TX-ed, and one or several lcores that doing actual TX for these packets. Konstantin
[dpdk-dev] [PATCH] acl: use rte_calloc for temporary memory allocation
2016-08-31 08:38, Vladyslav Buslov: > Would you accept this change as config file compile-time parameter with libc > calloc as default? > It is one line change only so it is easy to ifdef. The configuration should not be compile-time. Please think about a runtime configuration via an API.
[dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
Hi Neil, On 08/30/2016 03:23 PM, Neil Horman wrote: > On Fri, Aug 26, 2016 at 03:20:46PM +0200, 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 >> >> --- >> In this RFC, I supposed that all PCI drivers require a the loading of a >> uio/vfio module (except mlx*), this may be wrong. >> Comments are welcome! >> >> >> buildtools/pmdinfogen/pmdinfogen.c | 1 + >> buildtools/pmdinfogen/pmdinfogen.h | 1 + >> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++ >> drivers/net/bnx2x/bnx2x_ethdev.c| 4 >> drivers/net/bnxt/bnxt_ethdev.c | 2 ++ >> drivers/net/cxgbe/cxgbe_ethdev.c| 2 ++ >> drivers/net/e1000/em_ethdev.c | 2 ++ >> drivers/net/e1000/igb_ethdev.c | 4 >> drivers/net/ena/ena_ethdev.c| 2 ++ >> drivers/net/enic/enic_ethdev.c | 2 ++ >> drivers/net/fm10k/fm10k_ethdev.c| 2 ++ >> drivers/net/i40e/i40e_ethdev.c | 2 ++ >> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++ >> drivers/net/ixgbe/ixgbe_ethdev.c| 4 >> drivers/net/mlx4/mlx4.c | 2 ++ >> drivers/net/mlx5/mlx5.c | 3 +++ >> drivers/net/nfp/nfp_net.c | 2 ++ >> drivers/net/qede/qede_ethdev.c | 4 >> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++ >> drivers/net/thunderx/nicvf_ethdev.c | 2 ++ >> drivers/net/virtio/virtio_ethdev.c | 2 ++ >> drivers/net/vmxnet3/vmxnet3_ethdev.c| 2 ++ >> lib/librte_eal/common/include/rte_dev.h | 14 ++ >> tools/dpdk-pmdinfo.py | 5 - >> 24 files changed, 69 insertions(+), 1 deletion(-) >> > > Generally speaking, I like the idea, it makes sense to me in terms of using > pmdinfo to export this information > > That said, This may need to be a set of macros. By that I mean (and correct > me > if I'm wrong here), but the relationship between pmd's and kernel modules is > in > some cases, more complex than a 'requires' or 'depends' relationship. That is > to say, some pmd may need user space hardware access, but can use either uio > OR > vfio, but doesn't need both, and can continue to function if only one is > available. Other PMD's may be able to use vfio or uio, but can still function > without either. And some, as your patch implements, simply require one or the > other to function. As such it seems like you may want a few macros, in the > form > of: > > DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt loading, ignore any > failures > DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to be loaded after > request macro completes, fail if any are not loaded > > Thats just spitballing, mind you, theres probably a better way to do it, but > the > idea is to list a set of modules you would like to have, and then create a > parsable syntax to describe the modules that need to be loaded after the > request > is complete so that you can accurately codify the situations I described > above. Thank you for your feedback. However, I'm not sure I'm perfectly getting what you suggest. Do you think some PMDs could request a kernel module without really requiring it? Do you have an example in mind? The syntax I've submitted lets you define several lists of modules, so that the user or the script that starts the application can decide which kmod list is better according to the environment. For example, most drivers will advertise "uio,igb_uio:uio,uio_pci_generic:vfio,vfio-pci", and the user or script will have to choose between loading: - uio igb_uio - uio uio_pci_generic - vfio vfio-pci Olivier
[dpdk-dev] OpenSSL and non-BSD licenses in DPDK
On Wed, Aug 31, 2016 at 05:26:41PM +, Bodek, Zbigniew wrote: > I've seen some GPL stuff, mostly kernel modules from > Intel. So what with the above mentioned OpenSSL? The modules are that way to be compatible with the kernel. The rest is BSD. See: http://dpdk.org/dev on Licenses. Matthew.
[dpdk-dev] 17.02 Roadmap
Below are the features that we're planning to submit for the 17.02 release. We'll submit a patch to update the roadmap page with this info. Some things will obviously change during planning/development, so we'll provide a more detailed update in late September/early October. After that, things should hopefully be relatively stable. It would be good if others are also willing to share their plans so that we can build up a complete picture of what's planned for 17.02 and make sure there's no duplication. Consistent Filter API phase 2: Extend support for the Consistent Filter API that will be first implemented in 16.11 to IGB and FM10K. Elastic Flow Distributor: The Elastic Flow Distributor (EFD) is a flow-based load balancing library which scales linearly for both lookup and insert with the number of threads or cores. EFD lookup uses a "perfect hashing" scheme where only the information needed to compute a key's value (and not the key itself) is stored in the lookup table, thus reducing CPU cache storage requirements. Cryptodev: Additional Software Algorithms: - Optimize the AES-GCM software PMD. - Enhance the Intel(r) AES-NI MB PMD to add support for cipher-only and authentication-only operations. Add support for AES_CBC_MAC, AES_CMAC_128, AES_GMAC_128. - Add software support for: 3DES_ECB_128/192, AES_ECB_128/192/256, AES_F8, AES_XTS, ARC4. Run-Time Configuration of Flow Type (PCTYPE) and Packet Type (PTYPE) for I40E: At the moment all flow types and packet types in DPDK are statically defined. This makes impossible to add new values without first defining them statically and then recompiling DPDK. The ability to configure flow types and packet types at run time will be added for I40E. Extended Stats Latency and Bit Rate Statistics: Enhance the Extended NIC Stats (Xstats) implementation to support the collection and reporting of latency and bit rate measurements. Latency statistics will include min, max and average latency, and jitter. Bit rate statistics will include peak and average bit rate aggregated over a user-defined time period. This will be implemented for IXGBE and I40E. Hardware QoS for IXGBE and I40E: Implement support for Hardware QoS for IXGBE and I40E. This involves using DCB so that a PF or VF can receive packets for each of the Traffic Classes (TCs) based on the User Priority field (in the VLAN header). Bandwidth on transmit for each TC is programmable.
[dpdk-dev] [PATCH] acl: use rte_calloc for temporary memory allocation
Hi Vlad,
>
> Hi Konstantin,
>
> Thanks for your feedback.
>
> Would you accept this change as config file compile-time parameter with libc
> calloc as default?
> It is one line change only so it is easy to ifdef.
It is an option, but the main requirements from the community
is to minimize number of build time config options, and instead provide
ability to the user to configure things at runtime.
That's why I thought about something like:
+ /* use EAL hugepages for temporary memory allocations,
+ * might improve build time, build increases hugepages
+ * demand significantly.
+ */
#define RTE_ACL_CFG_FLAG_HMEM 1
struct rte_acl_config {
uint32_t num_categories; /**< Number of categories to build with. */
uint32_t num_fields; /**< Number of field definitions. */
struct rte_acl_field_def defs[RTE_ACL_MAX_FIELDS];
/**< array of field definitions. */
size_t max_size;
/**< max memory limit for internal run-time structures. */
+ uint64_t flags;
};
And then change tb_pool() to use either calloc() or rte_alloc() based on the
flags value.
Another, probably even better and more flexible way is to allow user to specify
his own alloc routine:
struct rte_acl_config {
uint32_t num_categories; /**< Number of categories to build with. */
uint32_t num_fields; /**< Number of field definitions. */
struct rte_acl_field_def defs[RTE_ACL_MAX_FIELDS];
/**< array of field definitions. */
size_t max_size;
/**< max memory limit for internal run-time structures. */
+ void *(tballoc)( (size_t, size_t);
+ void (*tbfree)(void *);
};
In that case user can provide his own alloc/free based on rte_calloc/rte_free
or even on something else.
The only drawback I see with that approaches, that in that case, you'll need to
follow
ABI compliance rules, which probably means that your change might not make
16.11.
Konstantin
>
> Regards,
> Vlad
>
> -Original Message-
> From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com]
> Sent: Wednesday, August 31, 2016 4:28 AM
> To: Vladyslav Buslov
> Cc: dev at dpdk.org
> Subject: RE: [PATCH] acl: use rte_calloc for temporary memory allocation
>
> Hi Vladyslav,
>
> > -Original Message-
> > From: Vladyslav Buslov [mailto:vladyslav.buslov at harmonicinc.com]
> > Sent: Tuesday, August 16, 2016 3:01 PM
> > To: Ananyev, Konstantin
> > Cc: dev at dpdk.org
> > Subject: [PATCH] acl: use rte_calloc for temporary memory allocation
> >
> > Acl build process uses significant amount of memory which degrades
> > performance by causing page walks when memory is allocated on regular heap
> > using libc calloc.
> >
> > This commit changes tb_mem to allocate temporary memory on huge pages with
> > rte_calloc.
>
> We deliberately used standard system memory allocation routines (calloc/free)
> here.
> With current design build phase was never considered to be an 'RT' phase
> operation.
> It is pretty cpu and memory expensive.
> So if we'll use RTE memory for build phase it could easily consume all (or
> most) of it, and might cause DPDK process failure or degradation.
> If you really feel that you (and other users) would benefit from using
> rte_calloc here (I personally still in doubt), then at least it should be a
> new field inside rte_acl_config, that would allow user to control that
> behavior.
> Though, as I said above, librte_acl was never designed to ' to allocate tens
> of thousands of ACLs at runtime'.
> To add ability to add/delete rules at runtime while keeping lookup time
> reasonably low some new approach need to be introduced.
> Konstantin
>
> >
> > Signed-off-by: Vladyslav Buslov
> > ---
> > lib/librte_acl/tb_mem.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_acl/tb_mem.c b/lib/librte_acl/tb_mem.c index
> > 157e608..c373673 100644
> > --- a/lib/librte_acl/tb_mem.c
> > +++ b/lib/librte_acl/tb_mem.c
> > @@ -52,7 +52,7 @@ tb_pool(struct tb_mem_pool *pool, size_t sz)
> > size_t size;
> >
> > size = sz + pool->alignment - 1;
> > - block = calloc(1, size + sizeof(*pool->block));
> > + block = rte_calloc("ACL_TBMEM_BLOCK", 1, size +
> > +sizeof(*pool->block), 0);
> > if (block == NULL) {
> > RTE_LOG(ERR, MALLOC, "%s(%zu)\n failed, currently allocated "
> > "by pool: %zu bytes\n", __func__, sz, pool->alloc);
> > --
> > 2.8.3
[dpdk-dev] [PATCH v8 01/25] eal: define macro container_of
Hi Thomas, On Tuesday 30 August 2016 07:12 PM, Thomas Monjalon wrote: > 2016-08-30 17:29, Shreyansh Jain: >> On Tuesday 30 August 2016 04:00 PM, Thomas Monjalon wrote: >>> 2016-08-30 09:57, Shreyansh Jain: Is there a better way to test that no driver breaks? Any particular parameters I should use for test-build.sh? >>> >>> Yes I suggest to create a file ~/.config/dpdk/devel.config to adapt the >>> configuration to your system. >>> Once you have installed the required dependencies, you can make this kind >>> of configuration: >> >> Ok. >> >>> mlxdep=$root/mlx/mofed-3.3-1.0.0.0 >>> szedep=$root/sze/usr-1.1.4 >> >> What does '$root' here refer to? > > It is the directory where I compile the DPDK dependencies. Ok - understood. I guessed the same > >> I am assuming 'mofed-3.3-1.0.0.0' and 'usr-1.1.4' are part of some >> dependencies that I should be revolving. Is that so? > > Yes, download and compile them as explain in the respective guides. Ok. > >> As of now I don't have much idea about this - I will have a look and >> ping back in case I am stuck. >> >>> if echo $DPDK_TARGET | grep -q '^x86_64' ; then >>> export DPDK_DEP_ARCHIVE=y >>> export DPDK_DEP_ZLIB=y >>> export DPDK_DEP_PCAP=y >>> export DPDK_DEP_SSL=y > > You need to install the packages to resolve these dependencies > (libarchive-dev, libzip-dev, libpcap-dev, libcrypto-dev). Thanks for the info. > >>> export DPDK_DEP_MOFED=y >>> export DPDK_DEP_SZE=y >>> export DPDK_DEP_CFLAGS="-I$mlxdep/include -I$szedep/include" >>> export DPDK_DEP_LDFLAGS="-L$mlxdep/lib -L$szedep/lib64 >>> -rpath=$szedep/lib64" >>> export AESNI_MULTI_BUFFER_LIB_PATH=$root/aesni/ipsec-043 >>> export LIBSSO_SNOW3G_PATH=$root/libsso/libsso-snow3g-0.3.1 >>> export LIBSSO_KASUMI_PATH=$root/libsso/libsso-kasumi-0.3.1 >>> fi >> >> Thanks. I will try the above. >> >>> I used 'x86_64-native-linuxapp-gcc+default+debug+shared' for all patches. >>> >>> It is a good idea to test also with clang (x86_64-native-linuxapp-clang) >>> and another arch (e.g. arm64-thunderx-linuxapp-gcc). >> >> Before releasing v9, I will do these steps. >> Thank you for suggestions. > > - Shreyansh
[dpdk-dev] [PATCH v8 10/25] eal/pci: Helpers for device name parsing/update
Hi,
On Tuesday 30 August 2016 10:04 PM, Pattan, Reshma wrote:
> Hi,
>
>> +/**
>> + * Utility function to write a pci device name, this device name can
>> +later be
>> + * used to retrieve the corresponding rte_pci_addr using
>> +eal_parse_pci_*
>> + * BDF helpers.
>> + *
>> + * @param addr
>> + * The PCI Bus-Device-Function address
>> + * @param output
>> + * The output buffer string
>> + * @param size
>> + * The output buffer size
>> + * @return
>> + * 0 on success, negative on error.
>> + */
>
> This function doesn't have any return value. Need to change the @return
> description.
I will correct this in v9. Thanks for review.
>
>> +static inline void
>> +rte_eal_pci_device_name(const struct rte_pci_addr *addr,
>> +char *output, size_t size)
>> +{
>> +RTE_VERIFY(size >= PCI_PRI_STR_SIZE);
>> +RTE_VERIFY(snprintf(output, size, PCI_PRI_FMT,
>> +addr->domain, addr->bus,
>> +addr->devid, addr->function) >= 0); }
>> +
>
> Thanks,
> Reshma
>
-
Shreyansh
--
-
Shreyansh
[dpdk-dev] [PATCH v2 4/4] doc: add basic invocation info for dpdk-devbind
This summarizes the "how to call dpdk-pmdinfo" in one place to be
picked up by html/pdf/man-page docs.
That knowledge was available before but spread in various docs along
examples (which are great and have to be kept) as well as in the
--usage/--help option of the tool itself.
As a root only program in sbin it should belong to section 8
"8 System administration commands (usually only for root)"
Signed-off-by: Christian Ehrhardt
---
doc/guides/conf.py | 4 +-
doc/guides/tools/devbind.rst | 143 +++
doc/guides/tools/index.rst | 1 +
mk/rte.sdkinstall.mk | 5 ++
4 files changed, 152 insertions(+), 1 deletion(-)
create mode 100644 doc/guides/tools/devbind.rst
diff --git a/doc/guides/conf.py b/doc/guides/conf.py
index c45c4be..149bcdb 100644
--- a/doc/guides/conf.py
+++ b/doc/guides/conf.py
@@ -113,7 +113,9 @@ man_pages = [("testpmd_app_ug/run_app", "testpmd",
("tools/proc_info", "dpdk-procinfo",
"access dpdk port stats and memory info", "", 1),
("tools/pmdinfo", "dpdk-pmdinfo",
- "dump a PMDs hardware support info", "", 1)]
+ "dump a PMDs hardware support info", "", 1),
+ ("tools/devbind", "dpdk-devbind",
+ "check device status and bind/unbind them from drivers", "", 8)]
:numref: fallback
# The following hook functions add some simple handling for the :numref:
diff --git a/doc/guides/tools/devbind.rst b/doc/guides/tools/devbind.rst
new file mode 100644
index 000..18a8059
--- /dev/null
+++ b/doc/guides/tools/devbind.rst
@@ -0,0 +1,143 @@
+
+.. BSD LICENSE
+Copyright(c) 2016 Canonical Limited. 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.
+
+
+dpdk-devbind Application
+
+
+The ``dpdk-devbind`` tool is a Data Plane Development Kit (DPDK) tool that
helps binding and unbinding devices from specific drivers.
+As well as checking their status in that regard.
+
+
+Running the Application
+---
+
+The tool has a number of command line options:
+
+.. code-block:: console
+
+ dpdk-devbind [options] DEVICE1 DEVICE2
+
+OPTIONS
+---
+
+* ``--help, --usage``
+
+Display usage information and quit
+
+* ``-s, --status``
+
+Print the current status of all known network interfaces.
+For each device, it displays the PCI domain, bus, slot and function,
+along with a text description of the device. Depending upon whether the
+device is being used by a kernel driver, the ``igb_uio`` driver, or no
+driver, other relevant information will be displayed:
+- the Linux interface name e.g. ``if=eth0``
+- the driver being used e.g. ``drv=igb_uio``
+- any suitable drivers not currently using that device e.g.
``unused=igb_uio``
+NOTE: if this flag is passed along with a bind/unbind option, the
+status display will always occur after the other operations have taken
+place.
+
+* ``-b driver, --bind=driver``
+
+Select the driver to use or "none" to unbind the device
+
+* ``-u, --unbind``
+
+Unbind a device (Equivalent to ``-b none``)
+
+* ``--force``
+
+By default, devices which are used by Linux - as indicated by having
+routes in the routing table - cannot be modified. Using the ``--force``
+flag overrides this behavior, allowing active links to be forcibly
+unbound.
[dpdk-dev] [PATCH v2 3/4] doc: add basic invocation info for dpdk-pmdinfo
This summarizes the "how to call dpdk-pmdinfo" in one place to be picked
up by html/pdf/man-page docs.
Signed-off-by: Christian Ehrhardt
---
doc/guides/conf.py | 4 +++-
doc/guides/tools/index.rst | 1 +
doc/guides/tools/pmdinfo.rst | 57
3 files changed, 61 insertions(+), 1 deletion(-)
create mode 100644 doc/guides/tools/pmdinfo.rst
diff --git a/doc/guides/conf.py b/doc/guides/conf.py
index 55b6b2f..c45c4be 100644
--- a/doc/guides/conf.py
+++ b/doc/guides/conf.py
@@ -111,7 +111,9 @@ man_pages = [("testpmd_app_ug/run_app", "testpmd",
("tools/pdump", "dpdk-pdump",
"enable packet capture on dpdk ports", "", 1),
("tools/proc_info", "dpdk-procinfo",
- "access dpdk port stats and memory info", "", 1)]
+ "access dpdk port stats and memory info", "", 1),
+ ("tools/pmdinfo", "dpdk-pmdinfo",
+ "dump a PMDs hardware support info", "", 1)]
:numref: fallback
# The following hook functions add some simple handling for the :numref:
diff --git a/doc/guides/tools/index.rst b/doc/guides/tools/index.rst
index d7654a2..80f2115 100644
--- a/doc/guides/tools/index.rst
+++ b/doc/guides/tools/index.rst
@@ -37,4 +37,5 @@ Tool User Guides
proc_info
pdump
+pmdinfo
diff --git a/doc/guides/tools/pmdinfo.rst b/doc/guides/tools/pmdinfo.rst
new file mode 100644
index 000..a90c59f
--- /dev/null
+++ b/doc/guides/tools/pmdinfo.rst
@@ -0,0 +1,57 @@
+
+.. BSD LICENSE
+Copyright(c) 2016 Canonical Limited. 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.
+
+
+dpdk-pmdinfo Application
+
+
+The ``dpdk-pmdinfo`` tool is a Data Plane Development Kit (DPDK) utility that
+can dump a PMDs hardware support info.
+
+
+Running the Application
+---
+
+The tool has a number of command line options:
+
+.. code-block:: console
+
+
+ dpdk-pmdinfo [-hrtp] [-d
+
+ -h, --helpShow a short help message and exit
+ -r, --raw Dump as raw json strings
+ -d FILE, --pcidb=FILE Specify a pci database to get vendor names from
+ -t, --table Output information on hw support as a hex table
+ -p, --plugindir Scan dpdk for autoload plugins
+
+.. Note::
+
+ * Parameters inside the square brackets represents optional parameters.
--
2.7.4
[dpdk-dev] [PATCH v2 2/4] doc: rendering and installation of man pages
This enables the rendering of rst into man pages as well as installing
them (if built) along the binaries. To do so there is a new make target
"doc-guides-man" which will render the rst files into man format.
Currently these three tools had docs that were compatible "enough" to
make up for a reasonable manpage.
- testpmd
- dpdk-pdump
- dpdk-procinfo
Since a man page should be installed along the binary they are not
installed in install-doc but install-runtime insteade. If not explicitly
built by the "doc-guides-man" target before calling install-runtime
there is no change to the old behaviour.
Signed-off-by: Christian Ehrhardt
---
doc/guides/conf.py | 8
mk/rte.sdkdoc.mk | 2 +-
mk/rte.sdkinstall.mk | 6 ++
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/doc/guides/conf.py b/doc/guides/conf.py
index cd6a4f7..55b6b2f 100644
--- a/doc/guides/conf.py
+++ b/doc/guides/conf.py
@@ -105,6 +105,14 @@ class CustomLatexFormatter(LatexFormatter):
# Replace the default latex formatter.
PygmentsBridge.latex_formatter = CustomLatexFormatter
+# Configuration for man pages
+man_pages = [("testpmd_app_ug/run_app", "testpmd",
+ "tests for dpdk pmds", "", 1),
+ ("tools/pdump", "dpdk-pdump",
+ "enable packet capture on dpdk ports", "", 1),
+ ("tools/proc_info", "dpdk-procinfo",
+ "access dpdk port stats and memory info", "", 1)]
+
:numref: fallback
# The following hook functions add some simple handling for the :numref:
# directive for Sphinx versions prior to 1.3.1. The functions replace the
diff --git a/mk/rte.sdkdoc.mk b/mk/rte.sdkdoc.mk
index 9952f25..21d9bdf 100644
--- a/mk/rte.sdkdoc.mk
+++ b/mk/rte.sdkdoc.mk
@@ -63,7 +63,7 @@ help:
all: api-html guides-html guides-pdf
.PHONY: clean
-clean: api-html-clean guides-html-clean guides-pdf-clean
+clean: api-html-clean guides-html-clean guides-pdf-clean guides-man-clean
.PHONY: api-html
api-html: api-html-clean
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index 5217063..533d369 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -66,6 +66,7 @@ includedir ?= $(prefix)/include/dpdk
datarootdir ?= $(prefix)/share
docdir ?= $(datarootdir)/doc/dpdk
datadir ?= $(datarootdir)/dpdk
+mandir ?= $(datarootdir)/man
sdkdir ?=$(datadir)
targetdir ?=$(datadir)/$(RTE_TARGET)
@@ -133,6 +134,11 @@ install-runtime:
$(DESTDIR)$(sbindir)/dpdk-devbind)
$(Q)$(call rte_symlink,$(DESTDIR)$(datadir)/tools/dpdk-pmdinfo.py, \
$(DESTDIR)$(bindir)/dpdk-pmdinfo)
+ifneq ($(wildcard $O/doc/man/*/*.1),)
+ $(Q)$(call rte_mkdir, $(DESTDIR)$(mandir))
+ $(Q)$(call rte_mkdir, $(DESTDIR)$(mandir)/man1)
+ $(Q)cp -a $O/doc/man/*/*.1 $(DESTDIR)$(mandir)/man1
+endif
install-kmod:
ifneq ($(wildcard $O/kmod/*),)
--
2.7.4
[dpdk-dev] [PATCH v2 1/4] doc: move tool guides in their own subdirectory
This is to clarify the scope of these documents that are more tools than sample applications. Also this is a preparation step to add more tools and generate man pages off of their rst files. Signed-off-by: Christian Ehrhardt --- doc/guides/index.rst | 1 + doc/guides/sample_app_ug/index.rst | 2 - doc/guides/sample_app_ug/pdump.rst | 144 - doc/guides/sample_app_ug/proc_info.rst | 71 doc/guides/tools/index.rst | 40 + doc/guides/tools/pdump.rst | 144 + doc/guides/tools/proc_info.rst | 71 7 files changed, 256 insertions(+), 217 deletions(-) delete mode 100644 doc/guides/sample_app_ug/pdump.rst delete mode 100644 doc/guides/sample_app_ug/proc_info.rst create mode 100644 doc/guides/tools/index.rst create mode 100644 doc/guides/tools/pdump.rst create mode 100644 doc/guides/tools/proc_info.rst diff --git a/doc/guides/index.rst b/doc/guides/index.rst index 0441859..57570f6 100644 --- a/doc/guides/index.rst +++ b/doc/guides/index.rst @@ -41,6 +41,7 @@ DPDK documentation nics/index cryptodevs/index sample_app_ug/index + tools/index testpmd_app_ug/index faq/index howto/index diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index 96bb317..6573452 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -72,11 +72,9 @@ Sample Applications User Guide dist_app vm_power_management tep_termination -proc_info ptpclient performance_thread ipsec_secgw -pdump **Figures** diff --git a/doc/guides/sample_app_ug/pdump.rst b/doc/guides/sample_app_ug/pdump.rst deleted file mode 100644 index ac0e7c9..000 --- a/doc/guides/sample_app_ug/pdump.rst +++ /dev/null @@ -1,144 +0,0 @@ - -.. BSD LICENSE -Copyright(c) 2016 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. - - -dpdk-pdump Application -== - -The ``dpdk-pdump`` tool is a Data Plane Development Kit (DPDK) tool that runs as -a DPDK secondary process and is capable of enabling packet capture on dpdk ports. - - .. Note:: - - * The ``dpdk-pdump`` tool depends on libpcap based PMD which is disabled -by default in the build configuration files, -owing to an external dependency on the libpcap development files -which must be installed on the board. -Once the libpcap development files are installed, the libpcap based PMD -can be enabled by setting CONFIG_RTE_LIBRTE_PMD_PCAP=y and recompiling the DPDK. - - -Running the Application - -The tool has a number of command line options: - -.. code-block:: console - - ./build/app/dpdk-pdump -- - --pdump '(port= | device_id=), - (queue=), - (rx-dev= | -tx-dev=), - [ring-size=], - [mbuf-size=], - [total-num-mbufs=]' - [--server-socket-path=] - [--client-socket-path=] - -The ``--pdump`` command line option is mandatory and it takes various sub arguments which are described in -below section. - - .. Note:: - - *
[dpdk-dev] [PATCH v2 0/4] provide man pages for binaries provided by DPDK
*Updates in v2* - rebased to latest upstream - moved tools to their own guide section - fixed some wording and indents - properly marked fixed-width text elements - fixed some rst issues in devbind doc Hi, this is about providing manpages for the binaries installed by DPDK. Eventually people using commands expect at least something reasonable avalable behind "man command". Still it is a try to stick to the rst/sphinx based doc creation. I found that for three of the 5 binaries that are usually installed the current rst files are sufficient to make a meaningful man page: - testpmd - dpdk-pdump - dpd-procinfo To be clear, this is only meant for the binaries installed by DPDK, there is no reason to render all the guides and howto's as one huge manpage. Also this series doesn't strive to render the api doc as man pages, while this certainly might be possible and even reasonable for section "3 Library calls (functions within program libraries)". Finally I must beg a pardon - I'm no makefile magician and sometimes even prefer things that work compared to long cryptic lines with many special chars. Yet if someone has something reasonable to unify the copy in patch #4 please let me know. Christian Ehrhardt (4): doc: move tool guides in their own subdirectory doc: rendering and installation of man pages doc: add basic invocation info for dpdk-pmdinfo doc: add basic invocation info for dpdk-devbind doc/guides/conf.py | 12 +++ doc/guides/index.rst | 1 + doc/guides/sample_app_ug/index.rst | 2 - doc/guides/sample_app_ug/pdump.rst | 144 - doc/guides/sample_app_ug/proc_info.rst | 71 doc/guides/tools/devbind.rst | 143 doc/guides/tools/index.rst | 42 ++ doc/guides/tools/pdump.rst | 144 + doc/guides/tools/pmdinfo.rst | 57 + doc/guides/tools/proc_info.rst | 71 mk/rte.sdkdoc.mk | 2 +- mk/rte.sdkinstall.mk | 11 +++ 12 files changed, 482 insertions(+), 218 deletions(-) delete mode 100644 doc/guides/sample_app_ug/pdump.rst delete mode 100644 doc/guides/sample_app_ug/proc_info.rst create mode 100644 doc/guides/tools/devbind.rst create mode 100644 doc/guides/tools/index.rst create mode 100644 doc/guides/tools/pdump.rst create mode 100644 doc/guides/tools/pmdinfo.rst create mode 100644 doc/guides/tools/proc_info.rst -- 2.7.4
[dpdk-dev] [PATCH 3/4] doc: add basic invocation info for dpdk-devbind
Hi, thanks for sharing your RST experience - I didn't see the rst issues before. Fixed them all and checked html/man output again - looking good to me. On Tue, Aug 30, 2016 at 5:05 PM, Mcnamara, John wrote: > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Christian Ehrhardt > > Sent: Thursday, August 4, 2016 12:17 PM > > To: christian.ehrhardt at canonical.com; thomas.monjalon at 6wind.com; > > dev at dpdk.org > > Subject: [dpdk-dev] [PATCH 3/4] doc: add basic invocation info for dpdk- > > devbind > > > > + > > +OPTIONS > > +--- > > + > > +* ``--help, --usage`` > > + > > +Display usage information and quit > > + > > +* ``-s, --status`` > > + > > +Print the current status of all known network interfaces. > > +For each device, it displays the PCI domain, bus, slot and > > function, > > +along with a text description of the device. Depending upon > > whether the > > +device is being used by a kernel driver, the igb_uio driver, or > > no > > +driver, other relevant information will be displayed: > > +* the Linux interface name e.g. if=eth0 > > +* the driver being used e.g. drv=igb_uio > > +* any suitable drivers not currently using that device > > +e.g. unused=igb_uio > > +NOTE: if this flag is passed along with a bind/unbind option, > the > > +status display will always occur after the other operations have > > taken > > +place. > > There are a few RST errors in this file. One of theme relates to the second > level bullet list above. There should be a blank line before and after the > list. > > Also, "e.g. unused=igb_uio" should be joined to, or aligned with, the > previous > line. > > Also, it would be better to quote any fixed width strings in the docs with > > quotes, like ``unused=igb_uio``. This could be applied to any of the > ``--options`` > in the text as well. > > +Examples > > + > > + > > +To display current device status: > > +.. code-block:: console > > + > > + dpdk-devbind --status > > + > > All the "code-block" directives should have a blank line before them. > However it is probably better to use the simpler :: directive, like: > > To display current device status:: > > dpdk-devbind --status > > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
[dpdk-dev] [PATCH 2/4] doc: add basic invocation info for dpdk-pmdinfo
On Tue, Aug 30, 2016 at 4:59 PM, Mcnamara, John wrote: > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Christian Ehrhardt > > Sent: Thursday, August 4, 2016 12:17 PM > > To: christian.ehrhardt at canonical.com; thomas.monjalon at 6wind.com; > > dev at dpdk.org > > Subject: [dpdk-dev] [PATCH 2/4] doc: add basic invocation info for dpdk- > > pmdinfo > > [...] > > --- a/doc/guides/sample_app_ug/index.rst > > +++ b/doc/guides/sample_app_ug/index.rst > > @@ -77,6 +77,7 @@ Sample Applications User Guide > > I think these docs would be better in a "doc/guides/tools" directory. > That would be clearer in terms to the documentation structure and > also in terms of their functionality > I agree that it represents the scope better then, but I was aligning myself to the pdump and procinfo tools that are already there. testpmd is a bit of an outlier, as that already has its own dir. But I assume given the suggestion to move the new ones we would want to move those other two as well then? I thank that would serve consistency then - I'll prep a patch with that as part of the series. [...] free-of-discussion ack to all other suggestions
[dpdk-dev] [dpdk-dev, RFC] drivers: advertise kmod dependencies in pmdinfo
On Wed, Aug 31, 2016 at 11:21:18AM +0200, Olivier Matz wrote: > Hi Neil, > > On 08/30/2016 03:23 PM, Neil Horman wrote: > > On Fri, Aug 26, 2016 at 03:20:46PM +0200, 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 > >> > >> --- > >> In this RFC, I supposed that all PCI drivers require a the loading of a > >> uio/vfio module (except mlx*), this may be wrong. > >> Comments are welcome! > >> > >> > >> buildtools/pmdinfogen/pmdinfogen.c | 1 + > >> buildtools/pmdinfogen/pmdinfogen.h | 1 + > >> drivers/crypto/qat/rte_qat_cryptodev.c | 2 ++ > >> drivers/net/bnx2x/bnx2x_ethdev.c| 4 > >> drivers/net/bnxt/bnxt_ethdev.c | 2 ++ > >> drivers/net/cxgbe/cxgbe_ethdev.c| 2 ++ > >> drivers/net/e1000/em_ethdev.c | 2 ++ > >> drivers/net/e1000/igb_ethdev.c | 4 > >> drivers/net/ena/ena_ethdev.c| 2 ++ > >> drivers/net/enic/enic_ethdev.c | 2 ++ > >> drivers/net/fm10k/fm10k_ethdev.c| 2 ++ > >> drivers/net/i40e/i40e_ethdev.c | 2 ++ > >> drivers/net/i40e/i40e_ethdev_vf.c | 2 ++ > >> drivers/net/ixgbe/ixgbe_ethdev.c| 4 > >> drivers/net/mlx4/mlx4.c | 2 ++ > >> drivers/net/mlx5/mlx5.c | 3 +++ > >> drivers/net/nfp/nfp_net.c | 2 ++ > >> drivers/net/qede/qede_ethdev.c | 4 > >> drivers/net/szedata2/rte_eth_szedata2.c | 2 ++ > >> drivers/net/thunderx/nicvf_ethdev.c | 2 ++ > >> drivers/net/virtio/virtio_ethdev.c | 2 ++ > >> drivers/net/vmxnet3/vmxnet3_ethdev.c| 2 ++ > >> lib/librte_eal/common/include/rte_dev.h | 14 ++ > >> tools/dpdk-pmdinfo.py | 5 - > >> 24 files changed, 69 insertions(+), 1 deletion(-) > >> > > > > Generally speaking, I like the idea, it makes sense to me in terms of using > > pmdinfo to export this information > > > > That said, This may need to be a set of macros. By that I mean (and > > correct me > > if I'm wrong here), but the relationship between pmd's and kernel modules > > is in > > some cases, more complex than a 'requires' or 'depends' relationship. That > > is > > to say, some pmd may need user space hardware access, but can use either > > uio OR > > vfio, but doesn't need both, and can continue to function if only one is > > available. Other PMD's may be able to use vfio or uio, but can still > > function > > without either. And some, as your patch implements, simply require one or > > the > > other to function. As such it seems like you may want a few macros, in the > > form > > of: > > > > DRIVER_REGISTER_KMOD_REQUEST - List of modules to attempt loading, ignore > > any > > failures > > DRIVER_REGISTER_KMOD_REQUIRE - List of modules required to be loaded after > > request macro completes, fail if any are not loaded > > > > Thats just spitballing, mind you, theres probably a better way to do it, > > but the > > idea is to list a set of modules you would like to have, and then create a > > parsable syntax to describe the modules that need to be loaded after the > > request > > is complete so that you can accurately codify the situations I described > > above. > > Thank you for your feedback. > However, I'm not sure I'm perfectly getting what you suggest. > > Do you think some PMDs could request a kernel module without really > requiring it? Do you have an example in mind? > Yes, thats precisely it. The most clear example I could think of (though I'm not sure if any pmd currently supports this), is a pmd that supports both UIO and VFIO communication with the kernel. Such a PMD requires that one of those two modules be loaded, but only one (i.e. both are not required), so if only the uio kernel module loads is a success case, likewise if only the vfio module loads can be treated as success. Both loading are clearly successful. Only if neither load do we have a failure case. I'm suggesting that the grammer that your exports define should take those cases into account. Its not always as simple as "I must have the following modules" > The syntax I've submitted lets you define several lists of modules, so > that the user or the script that starts the application can decide which > kmod list is better according to the environment. > If you have a human intervening in the module load process, sure, then its fine. But it seems that this particular feature that you're implemnting might have automated uses. That is to say the dpdk core library might be interested in parsing this particular information to direct module autoloading, and if thats desireable then you need to define these lists such that you can codify failure and success conditions. > For example, most drivers will advertise >
[dpdk-dev] [PATCH 4/5] net/ixgbe: implement new Rx checksum flag
Hi Olivier,
> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Friday, August 26, 2016 3:30 PM
> To: Wang, Xiao W ; Chen, Jing D
>
> Cc: dev at dpdk.org
> Subject: Re: [PATCH 4/5] net/ixgbe: implement new Rx checksum flag
>
> Hi Xiao,
>
> On 08/25/2016 07:48 PM, Xiao Wang wrote:
> > Add CKSUM_GOOD flag to distinguish a good checksum from an unknown
> one.
> >
> > Signed-off-by: Xiao Wang
> > ---
> > drivers/net/ixgbe/ixgbe_rxtx.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> > index 8a306b0..d2dc82a 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > @@ -1345,7 +1345,9 @@ rx_desc_error_to_pkt_flags(uint32_t rx_status)
> > * Bit 30: L4I, L4I integrity error
> > */
> > static uint64_t error_to_pkt_flags_map[4] = {
> > - 0, PKT_RX_L4_CKSUM_BAD, PKT_RX_IP_CKSUM_BAD,
> > + PKT_RX_IP_CKSUM_GOOD | PKT_RX_L4_CKSUM_GOOD,
> > + PKT_RX_IP_CKSUM_GOOD | PKT_RX_L4_CKSUM_BAD,
> > + PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_GOOD,
> > PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD
> > };
> > pkt_flags = error_to_pkt_flags_map[(rx_status >>
> >
>
> I think this would somehow conflict with the patch adding the support of
> Rx checksum offload in vector receive function:
>
> http://dpdk.org/dev/patchwork/patch/14630/
>
> Depending on which one is pushed first, the second one would need to be
> reworked.
>
> Olivier
Yes, since your patch supports cksum in vector Rx, I'll add the new cksum flags
for it
based on your patch.
Best Regards,
Xiao
[dpdk-dev] [PATCH 1/5] net/fm10k: add back Rx checksum offload
Hi Olivier,
> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Friday, August 26, 2016 3:27 PM
> To: Wang, Xiao W ; Chen, Jing D
>
> Cc: dev at dpdk.org
> Subject: Re: [PATCH 1/5] net/fm10k: add back Rx checksum offload
>
> Hi Xiao,
>
> On 08/25/2016 07:48 PM, Xiao Wang wrote:
> > A previous patch (http://dpdk.org/dev/patchwork/patch/12937/) removed
> > some necessary lines about Rx checksum by mistake, this patch adds
> > them back.
> >
> > Fixes: 6046898f5097 ("net/mbuf: remove unused Rx error flags")
> >
> > Signed-off-by: Xiao Wang
>
> Just a small comment about the title, what do you thinkg about:
> "net/fm10k: fix Rx checksum flags" ?
> I think having the word "fix" in the title would help for finding these
> commits for the stable version.
>
> Apart from that, thanks for fixing my mistake :)
>
>
> Regards,
> Olivier
I agree with you, will change the commit log in V2.
Best Regards,
Xiao
[dpdk-dev] [PATCH 2/5] net/fm10k: implement new Rx checksum flag
Hi Mark, > -Original Message- > From: Chen, Jing D > Sent: Monday, August 29, 2016 5:33 PM > To: Wang, Xiao W ; olivier.matz at 6wind.com > Cc: dev at dpdk.org > Subject: RE: [PATCH 2/5] net/fm10k: implement new Rx checksum flag > > Hi, > > > uint16_t > > diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c > > b/drivers/net/fm10k/fm10k_rxtx_vec.c > > index 9ea747e..8c08b44 100644 > > --- a/drivers/net/fm10k/fm10k_rxtx_vec.c > > +++ b/drivers/net/fm10k/fm10k_rxtx_vec.c > > @@ -95,8 +95,10 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct > rte_mbuf > > **rx_pkts) > > const __m128i l3l4cksum_flag = _mm_set_epi8(0, 0, 0, 0, > > 0, 0, 0, 0, > > 0, 0, 0, 0, > > - PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD, > > - PKT_RX_IP_CKSUM_BAD, PKT_RX_L4_CKSUM_BAD, 0); > > + (PKT_RX_IP_CKSUM_BAD | > PKT_RX_L4_CKSUM_BAD) >> 1, > > + (PKT_RX_IP_CKSUM_BAD | > PKT_RX_L4_CKSUM_GOOD) >> > > 1, > > + (PKT_RX_IP_CKSUM_GOOD | > PKT_RX_L4_CKSUM_BAD) >> > > 1, > > + (PKT_RX_IP_CKSUM_GOOD | > > PKT_RX_L4_CKSUM_GOOD) >> 1); > > Can we define a macro, like "#define RTE_CKSUM_SHIFT 1" to avoid numeric? Yes, I'll add a macro for this, but since this shift operation isn't commonly used by other pmds (igb and i40e don't support cksum offload in vector Rx, ixgbe cannot do this shift due to VLAN offload), I will make it a local macro definition. > > > > > const __m128i rxe_flag = _mm_set_epi8(0, 0, 0, 0, > > 0, 0, 0, 0, > > @@ -139,6 +141,7 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct > > rte_mbuf **rx_pkts) > > /* Process L4/L3 checksum error flags */ > > cksumflag = _mm_srli_epi16(cksumflag, L3L4EFLAG_SHIFT); > > cksumflag = _mm_shuffle_epi8(l3l4cksum_flag, cksumflag); > > + cksumflag = _mm_slli_epi16(cksumflag, 1); > > vtag1 = _mm_or_si128(cksumflag, vtag1); > > > > vol.dword = _mm_cvtsi128_si64(vtag1); > > -- > > 1.9.3 > > Besides that, just realize we should remove "hw_ip_checksum" check in func > fm10k_rx_vec_condition_check() since we already support it. > Can you help to make the change? Sure, will remove it in V2. Thanks for the comments, Xiao
[dpdk-dev] [PATCH 0/4] provide man pages for binaries provided by DPDK
On 08/30/2016 05:51 PM, Mcnamara, John wrote: >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Christian Ehrhardt >> Sent: Thursday, August 4, 2016 12:17 PM >> To: christian.ehrhardt at canonical.com; thomas.monjalon at 6wind.com; >> dev at dpdk.org >> Subject: [dpdk-dev] [PATCH 0/4] provide man pages for binaries provided by >> DPDK >> >> Hi, >> this is about providing manpages for the binaries installed by DPDK. >> Eventually people using commands expect at least something reasonable >> avalable behind "man command". >> > > Hi Christian, > > Thanks for that. It is really useful and the output looks very good. Seconded, nice work! - Panu -
[dpdk-dev] [PATCH 0/4] provide man pages for binaries provided by DPDK
Thanks for the review and the feedback. I'm trying to integrate the feedback and send a v2 today. On Wed, Aug 31, 2016 at 7:54 AM, Panu Matilainen wrote: > On 08/30/2016 05:51 PM, Mcnamara, John wrote: > >> -Original Message- >>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Christian Ehrhardt >>> Sent: Thursday, August 4, 2016 12:17 PM >>> To: christian.ehrhardt at canonical.com; thomas.monjalon at 6wind.com; >>> dev at dpdk.org >>> Subject: [dpdk-dev] [PATCH 0/4] provide man pages for binaries provided >>> by >>> DPDK >>> >>> Hi, >>> this is about providing manpages for the binaries installed by DPDK. >>> Eventually people using commands expect at least something reasonable >>> avalable behind "man command". >>> >>> >> Hi Christian, >> >> Thanks for that. It is really useful and the output looks very good. >> > > Seconded, nice work! > > - Panu - > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd
[dpdk-dev] [PATCH 4/4] doc: make the devbind man page be part of section 8
Damn, I'm payed by # of commits :-P
That can of course be squashed with the actual devbind patch.
I already thought about it before and hearing another voice asking for it
is enough to convince me.
On Tue, Aug 30, 2016 at 5:12 PM, Mcnamara, John
wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Christian Ehrhardt
> > Sent: Thursday, August 4, 2016 12:17 PM
> > To: christian.ehrhardt at canonical.com; thomas.monjalon at 6wind.com;
> > dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH 4/4] doc: make the devbind man page be part of
> > section 8
> >
> > As a root only program in sbin it should belong to section 8
> > "8 System administration commands (usually only for root)"
> >
> > Signed-off-by: Christian Ehrhardt
> > ---
> > doc/guides/conf.py | 2 +-
> > mk/rte.sdkinstall.mk | 5 +
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/conf.py b/doc/guides/conf.py index
> > ad8e8b3..52e2acf 100644
> > --- a/doc/guides/conf.py
> > +++ b/doc/guides/conf.py
> > @@ -102,7 +102,7 @@ man_pages = [("testpmd_app_ug/run_app", "testpmd",
> > ("sample_app_ug/pmdinfo", "dpdk-pmdinfo",
> >"dump a PMDs hardware support info", "", 1),
> > ("sample_app_ug/devbind", "dpdk-devbind",
> > - "check device status and bind/unbind them from drivers",
> > "", 1)]
> > + "check device status and bind/unbind them from drivers",
> > + "", 8)]
>
>
> Could this be rolled into one of the earlier patches?
>
>
>
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
[dpdk-dev] [PATCH] acl: use rte_calloc for temporary memory allocation
Hi Konstantin,
Thanks for your feedback.
Would you accept this change as config file compile-time parameter with libc
calloc as default?
It is one line change only so it is easy to ifdef.
Regards,
Vlad
-Original Message-
From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
Sent: Wednesday, August 31, 2016 4:28 AM
To: Vladyslav Buslov
Cc: dev at dpdk.org
Subject: RE: [PATCH] acl: use rte_calloc for temporary memory allocation
Hi Vladyslav,
> -Original Message-
> From: Vladyslav Buslov [mailto:vladyslav.buslov at harmonicinc.com]
> Sent: Tuesday, August 16, 2016 3:01 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: [PATCH] acl: use rte_calloc for temporary memory allocation
>
> Acl build process uses significant amount of memory which degrades
> performance by causing page walks when memory is allocated on regular heap
> using libc calloc.
>
> This commit changes tb_mem to allocate temporary memory on huge pages with
> rte_calloc.
We deliberately used standard system memory allocation routines (calloc/free)
here.
With current design build phase was never considered to be an 'RT' phase
operation.
It is pretty cpu and memory expensive.
So if we'll use RTE memory for build phase it could easily consume all (or
most) of it, and might cause DPDK process failure or degradation.
If you really feel that you (and other users) would benefit from using
rte_calloc here (I personally still in doubt), then at least it should be a new
field inside rte_acl_config, that would allow user to control that behavior.
Though, as I said above, librte_acl was never designed to ' to allocate tens of
thousands of ACLs at runtime'.
To add ability to add/delete rules at runtime while keeping lookup time
reasonably low some new approach need to be introduced.
Konstantin
>
> Signed-off-by: Vladyslav Buslov
> ---
> lib/librte_acl/tb_mem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_acl/tb_mem.c b/lib/librte_acl/tb_mem.c index
> 157e608..c373673 100644
> --- a/lib/librte_acl/tb_mem.c
> +++ b/lib/librte_acl/tb_mem.c
> @@ -52,7 +52,7 @@ tb_pool(struct tb_mem_pool *pool, size_t sz)
> size_t size;
>
> size = sz + pool->alignment - 1;
> - block = calloc(1, size + sizeof(*pool->block));
> + block = rte_calloc("ACL_TBMEM_BLOCK", 1, size +
> +sizeof(*pool->block), 0);
> if (block == NULL) {
> RTE_LOG(ERR, MALLOC, "%s(%zu)\n failed, currently allocated "
> "by pool: %zu bytes\n", __func__, sz, pool->alloc);
> --
> 2.8.3
[dpdk-dev] [PATCH v2] eal: restrict cores detection
On Wed, 31 Aug 2016 03:07:10 + Jianfeng Tan wrote: > This patch uses pthread_getaffinity_np() to narrow down detected > cores before parsing coremask (-c), corelist (-l), and coremap > (--lcores). > > The purpose of this patch is to leave out these core related options > when DPDK applications are deployed under container env, so that > users only specify core restriction as starting the instance. > > Note: previously, some users are using isolated CPUs, which could > be excluded by default. Please add commands like taskset to use > those cores. > > Test example: > $ taskset 0xc ./examples/helloworld/build/helloworld -m 1024 > > Signed-off-by: Jianfeng Tan > Acked-by: Neil Horman > --- > v2: > - Make it as default instead of adding the new options. > lib/librte_eal/common/eal_common_lcore.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/lib/librte_eal/common/eal_common_lcore.c > b/lib/librte_eal/common/eal_common_lcore.c > index 2cd4132..62e4f67 100644 > --- a/lib/librte_eal/common/eal_common_lcore.c > +++ b/lib/librte_eal/common/eal_common_lcore.c > @@ -57,6 +57,14 @@ rte_eal_cpu_init(void) > struct rte_config *config = rte_eal_get_configuration(); > unsigned lcore_id; > unsigned count = 0; > + rte_cpuset_t cs; > + pthread_t tid = pthread_self(); > + > + /* Add below method to obtain core restrictions, like ulimit, > + * cgroup.cpuset, etc. Will not use those cores, which are rebuffed. > + */ > + if (pthread_getaffinity_np(tid, sizeof(rte_cpuset_t), ) < 0) > + CPU_ZERO(); > This patch makes sense but the comment is hard to read because of wording and grammar. If you choose variable names better then there really is no need for a comment in many cases. Code is often easier to read/write than comments for non-native English speakers. Remove the comment and rename 'cs' as 'affinity_set' or something equally as descriptive.
[dpdk-dev] [PATCH] Performance optimization of ACL build process
On Tue, 16 Aug 2016 17:01:27 +0300 Vladyslav Buslov wrote: > Hello, > > In our application we need to be able to allocate tens of thousands of ACLs > at runtime. > Testing revealed significant performance problems. We were able to track them > to memset in calloc function which caused multiple page walks per invocation. > Modifying tb_mem to use huge page memory resulted ~2x performance gain for > that operation. > > Regards, > Vladyslav > > Vladyslav Buslov (1): > acl: use rte_calloc for temporary memory allocation > > lib/librte_acl/tb_mem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > What about making sure that the ACL code does it's own initialization of all fields and just use malloc rather than calloc?
[dpdk-dev] [PATCH] vhost: add pmd xstats
Hi, ALL: Physical NIC has a set of counters, such as u64 prc64; u64 prc127; u64 prc255; etc. but now, DPDK has counted the prc64 in two ways. Physical NIC counts prc64 with CRC by hardware. Virtio computes the counter like prc64 without CRC. This will cause the conflict, when a 64 packet from outer network is sent to VM(virtio), NIC will show prc64 + 1, virtio will actually receive the 64-4(CRC) = 60 bytes pkt, undersize(<64) counter will be increased. Should Vhost do like NIC's behavior or virtio's behavior? According to rfc2819 description as referece. etherStatsPkts64Octets OBJECT-TYPE SYNTAX Counter32 UNITS "Packets" "The total number of packets (including bad packets) received that were 64 octets in length (excluding framing bits but including FCS octets)." > -Original Message- > From: Yao, Lei A > Sent: Tuesday, August 30, 2016 11:22 AM > To: Xu, Qian Q ; Yang, Zhiyong > ; Panu Matilainen ; > Thomas Monjalon ; Yuanhan Liu > > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH] vhost: add pmd xstats > > Hi, Qian > > The test setup at my side is Vhost/VirtIO loopback with 64B packets. > > > -Original Message- > From: Xu, Qian Q > Sent: Tuesday, August 30, 2016 11:03 AM > To: Yao, Lei A ; Yang, Zhiyong > ; Panu Matilainen ; > Thomas Monjalon ; Yuanhan Liu > > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH] vhost: add pmd xstats > > Lei > Could you list the test setup for below findings? I think we need at least to > check below tests for mergeable=on/off path: > 1. Vhost/virtio loopback > 2. PVP test : virtio-pmd IO fwd and virtio-net IPV4 fwd > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yao, Lei A > Sent: Tuesday, August 30, 2016 10:46 AM > To: Yang, Zhiyong ; Panu Matilainen > ; Thomas Monjalon > ; Yuanhan Liu > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] vhost: add pmd xstats > > Hi, Zhiyong > > I have tested more xstats performance drop data at my side. > Vhost Xstats patch with mergeable on : ~3% Vhost Xstats patch with > mergeable off : ~9% > > Because Zhihong also submit patch to improve the performance on for the > mergeable on: http://dpdk.org/dev/patchwork/patch/15245/ ~15249. If > both patch integrated, the performance drop will be much higher > Vhsot Xstats patch + Vhost mergeable on patch with mergeable on : the > performance drop is around 6% > > > Best Regards > Lei > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yang, Zhiyong > Sent: Thursday, August 25, 2016 5:22 PM > To: Panu Matilainen ; Thomas Monjalon > ; Yuanhan Liu > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] vhost: add pmd xstats > > > > > -Original Message- > > From: Panu Matilainen [mailto:pmatilai at redhat.com] > > Sent: Wednesday, August 24, 2016 8:37 PM > > To: Thomas Monjalon ; Yuanhan Liu > > > > Cc: dev at dpdk.org; Yang, Zhiyong > > Subject: Re: [dpdk-dev] [PATCH] vhost: add pmd xstats > > > > On 08/24/2016 11:44 AM, Thomas Monjalon wrote: > > > 2016-08-24 13:46, Yuanhan Liu: > > >> On Tue, Aug 23, 2016 at 12:45:54PM +0300, Panu Matilainen wrote: > > >> Since collecting data of vhost_update_packet_xstats will have > > >> some effect on RX/TX performance, so, Setting compiling switch > > >> CONFIG_RTE_LIBRTE_PMD_VHOST_UPDATE_XSTATS=n by default > > in the > > > file > > >> config/common_base, if needing xstats data, you can enable it(y). > > > > > > NAK, such things need to be switchable at run-time. > > > > > > - Panu - > > > > Considering the following reasons using the compiler switch, not > > command-line at run-time. > > > > 1.Similar xstats update functions are always collecting stats > > data in the background when rx/tx are running, such as the > > physical NIC or virtio, which have no switch. Compiler switch for > > vhost pmd xstats is added as a option when performance is viewed > > as critical > > factor. > > > > 2. No data structure and API in any layer support the xstats > > update switch at run-time. Common data structure (struct > > rte_eth_dev_data) has no device-specific data member, if > > implementing enable/disable of vhost_update _packet_xstats at > > run-time, must define a > > flag(device-specific) in it, because the definition of struct > > vhost_queue in the driver code (eth_vhost_rx/eth_vhost_tx > > processing)is not visible from device perspective. > > > > 3. I tested RX/TX with v1 patch (y) as reference based on > > Intel(R) > > Xeon(R) CPU E5-2699 v3 @ 2.30GHz, for 64byts packets in burst > > mode, > > 32 packets in one RX/TX processing. Overhead of > > vhost_update_packet_xstats is less than 3% for the rx/tx > > processing. It looks that vhost_update_packet_xstats has a > > limited > > effect on performance drop. > > >>> > > >>> Well, either the
[dpdk-dev] [PATCH v2] eal: restrict cores detection
This patch uses pthread_getaffinity_np() to narrow down detected
cores before parsing coremask (-c), corelist (-l), and coremap
(--lcores).
The purpose of this patch is to leave out these core related options
when DPDK applications are deployed under container env, so that
users only specify core restriction as starting the instance.
Note: previously, some users are using isolated CPUs, which could
be excluded by default. Please add commands like taskset to use
those cores.
Test example:
$ taskset 0xc ./examples/helloworld/build/helloworld -m 1024
Signed-off-by: Jianfeng Tan
Acked-by: Neil Horman
---
v2:
- Make it as default instead of adding the new options.
lib/librte_eal/common/eal_common_lcore.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/eal_common_lcore.c
b/lib/librte_eal/common/eal_common_lcore.c
index 2cd4132..62e4f67 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -57,6 +57,14 @@ rte_eal_cpu_init(void)
struct rte_config *config = rte_eal_get_configuration();
unsigned lcore_id;
unsigned count = 0;
+ rte_cpuset_t cs;
+ pthread_t tid = pthread_self();
+
+ /* Add below method to obtain core restrictions, like ulimit,
+* cgroup.cpuset, etc. Will not use those cores, which are rebuffed.
+*/
+ if (pthread_getaffinity_np(tid, sizeof(rte_cpuset_t), ) < 0)
+ CPU_ZERO();
/*
* Parse the maximum set of logical cores, detect the subset of running
@@ -70,7 +78,8 @@ rte_eal_cpu_init(void)
/* in 1:1 mapping, record related cpu detected state */
lcore_config[lcore_id].detected = eal_cpu_detected(lcore_id);
- if (lcore_config[lcore_id].detected == 0) {
+ if (lcore_config[lcore_id].detected == 0 ||
+ !CPU_ISSET(lcore_id, )) {
config->lcore_role[lcore_id] = ROLE_OFF;
lcore_config[lcore_id].core_index = -1;
continue;
--
2.7.4
[dpdk-dev] [PATCH] acl: use rte_calloc for temporary memory allocation
Hi Vladyslav,
> -Original Message-
> From: Vladyslav Buslov [mailto:vladyslav.buslov at harmonicinc.com]
> Sent: Tuesday, August 16, 2016 3:01 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: [PATCH] acl: use rte_calloc for temporary memory allocation
>
> Acl build process uses significant amount of memory which degrades
> performance by causing page walks when memory is allocated on
> regular heap using libc calloc.
>
> This commit changes tb_mem to allocate temporary memory on huge pages with
> rte_calloc.
We deliberately used standard system memory allocation routines (calloc/free)
here.
With current design build phase was never considered to be an 'RT' phase
operation.
It is pretty cpu and memory expensive.
So if we'll use RTE memory for build phase it could easily consume all (or most)
of it, and might cause DPDK process failure or degradation.
If you really feel that you (and other users) would benefit from using
rte_calloc here (I personally still in doubt), then at least it should be a new
field inside rte_acl_config, that would allow user to control that behavior.
Though, as I said above, librte_acl was never designed to ' to allocate tens of
thousands of ACLs at runtime'.
To add ability to add/delete rules at runtime while keeping lookup time
reasonably low
some new approach need to be introduced.
Konstantin
>
> Signed-off-by: Vladyslav Buslov
> ---
> lib/librte_acl/tb_mem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_acl/tb_mem.c b/lib/librte_acl/tb_mem.c index
> 157e608..c373673 100644
> --- a/lib/librte_acl/tb_mem.c
> +++ b/lib/librte_acl/tb_mem.c
> @@ -52,7 +52,7 @@ tb_pool(struct tb_mem_pool *pool, size_t sz)
> size_t size;
>
> size = sz + pool->alignment - 1;
> - block = calloc(1, size + sizeof(*pool->block));
> + block = rte_calloc("ACL_TBMEM_BLOCK", 1, size + sizeof(*pool->block),
> +0);
> if (block == NULL) {
> RTE_LOG(ERR, MALLOC, "%s(%zu)\n failed, currently allocated "
> "by pool: %zu bytes\n", __func__, sz, pool->alloc);
> --
> 2.8.3
