[dpdk-dev] [PATCH v3] net/ena: fix out of order completion

[Rafal Kozik]

rx_buffer_info should be refill not linearly, but out of order.
IDs should be taken from empty_rx_reqs array.

rx_refill_buffer is introduced to temporary storage
bulk of mbufs taken from pool.

In case of error unused mbufs are put back to pool.

Fixes: c2034976673d ("net/ena: add Rx out of order completion")
Cc: sta...@dpdk.org

Signed-off-by: Rafal Kozik 
Acked-by: Michal Krawczyk 

---
v2:
Fix commit author.

v3:
Add () for readability.
---
 drivers/net/ena/ena_ethdev.c | 40 
 drivers/net/ena/ena_ethdev.h |  1 +
 2 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 3690afe..a07bd2b 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -776,6 +776,10 @@ static void ena_rx_queue_release(void *queue)
rte_free(ring->rx_buffer_info);
ring->rx_buffer_info = NULL;
 
+   if (ring->rx_refill_buffer)
+   rte_free(ring->rx_refill_buffer);
+   ring->rx_refill_buffer = NULL;
+
if (ring->empty_rx_reqs)
rte_free(ring->empty_rx_reqs);
ring->empty_rx_reqs = NULL;
@@ -1318,6 +1322,17 @@ static int ena_rx_queue_setup(struct rte_eth_dev *dev,
return -ENOMEM;
}
 
+   rxq->rx_refill_buffer = rte_zmalloc("rxq->rx_refill_buffer",
+   sizeof(struct rte_mbuf *) * nb_desc,
+   RTE_CACHE_LINE_SIZE);
+
+   if (!rxq->rx_refill_buffer) {
+   RTE_LOG(ERR, PMD, "failed to alloc mem for rx refill buffer\n");
+   rte_free(rxq->rx_buffer_info);
+   rxq->rx_buffer_info = NULL;
+   return -ENOMEM;
+   }
+
rxq->empty_rx_reqs = rte_zmalloc("rxq->empty_rx_reqs",
 sizeof(uint16_t) * nb_desc,
 RTE_CACHE_LINE_SIZE);
@@ -1325,6 +1340,8 @@ static int ena_rx_queue_setup(struct rte_eth_dev *dev,
RTE_LOG(ERR, PMD, "failed to alloc mem for empty rx reqs\n");
rte_free(rxq->rx_buffer_info);
rxq->rx_buffer_info = NULL;
+   rte_free(rxq->rx_refill_buffer);
+   rxq->rx_refill_buffer = NULL;
return -ENOMEM;
}
 
@@ -1346,7 +1363,7 @@ static int ena_populate_rx_queue(struct ena_ring *rxq, 
unsigned int count)
uint16_t ring_mask = ring_size - 1;
uint16_t next_to_use = rxq->next_to_use;
uint16_t in_use, req_id;
-   struct rte_mbuf **mbufs = &rxq->rx_buffer_info[0];
+   struct rte_mbuf **mbufs = rxq->rx_refill_buffer;
 
if (unlikely(!count))
return 0;
@@ -1354,13 +1371,8 @@ static int ena_populate_rx_queue(struct ena_ring *rxq, 
unsigned int count)
in_use = rxq->next_to_use - rxq->next_to_clean;
ena_assert_msg(((in_use + count) < ring_size), "bad ring state");
 
-   count = RTE_MIN(count,
-   (uint16_t)(ring_size - (next_to_use & ring_mask)));
-
/* get resources for incoming packets */
-   rc = rte_mempool_get_bulk(rxq->mb_pool,
- (void **)(&mbufs[next_to_use & ring_mask]),
- count);
+   rc = rte_mempool_get_bulk(rxq->mb_pool, (void **)mbufs, count);
if (unlikely(rc < 0)) {
rte_atomic64_inc(&rxq->adapter->drv_stats->rx_nombuf);
PMD_RX_LOG(DEBUG, "there are no enough free buffers");
@@ -1369,15 +1381,17 @@ static int ena_populate_rx_queue(struct ena_ring *rxq, 
unsigned int count)
 
for (i = 0; i < count; i++) {
uint16_t next_to_use_masked = next_to_use & ring_mask;
-   struct rte_mbuf *mbuf = mbufs[next_to_use_masked];
+   struct rte_mbuf *mbuf = mbufs[i];
struct ena_com_buf ebuf;
 
-   rte_prefetch0(mbufs[((next_to_use + 4) & ring_mask)]);
+   if (likely((i + 4) < count))
+   rte_prefetch0(mbufs[i + 4]);
 
req_id = rxq->empty_rx_reqs[next_to_use_masked];
rc = validate_rx_req_id(rxq, req_id);
if (unlikely(rc < 0))
break;
+   rxq->rx_buffer_info[req_id] = mbuf;
 
/* prepare physical address for DMA transaction */
ebuf.paddr = mbuf->buf_iova + RTE_PKTMBUF_HEADROOM;
@@ -1386,17 +1400,19 @@ static int ena_populate_rx_queue(struct ena_ring *rxq, 
unsigned int count)
rc = ena_com_add_single_rx_desc(rxq->ena_com_io_sq,
&ebuf, req_id);
if (unlikely(rc)) {
-   rte_mempool_put_bulk(rxq->mb_pool, (void **)(&mbuf),
-count - i);
RTE_LOG(WARNING, PMD, "failed adding rx desc\n");
+   rxq->rx_buffer_info[

Re: [dpdk-dev] [PATCH] doc: announce deprecation of dpaa2 exposed mem structure

[Hemant Agrawal]

Acked-by: Hemant Agrawal 

[dpdk-dev] MLX5 driver - number of descriptors overflow

[Amedeo Sapio]

Hello,

I experienced a problem with the MLX5 driver running a code that is working
fine with an Intel card. I have found that the reason of this error is an
overflow of the uint16_t number of descriptors in the mlx driver.

Here the details:

- The NIC is a Mellanox ConnectX-5 100G.

- This is a summary code that I run to initialize the port:

ret = rte_eth_dev_configure(dpdk_par.portid, 1, 1, &port_conf);

dpdk_par.port_rx_ring_size = dev_info.rx_desc_lim.nb_max;
dpdk_par.port_tx_ring_size = dev_info.tx_desc_lim.nb_max;

ret = rte_eth_dev_adjust_nb_rx_tx_desc(dpdk_par.portid,
&dpdk_par.port_rx_ring_size, &dpdk_par.port_tx_ring_size);

ret = rte_eth_rx_queue_setup(dpdk_par.portid, 0,
dpdk_par.port_rx_ring_size, rte_eth_dev_socket_id(dpdk_par.portid),
&rx_conf, dpdk_data.pool);
ret = rte_eth_tx_queue_setup(dpdk_par.portid, 0,
dpdk_par.port_tx_ring_size, rte_eth_dev_socket_id(dpdk_par.portid),
&tx_conf);

ret = rte_eth_dev_start(dpdk_par.portid);

- The "rte_eth_dev_start" function returns  -ENOMEM  =  -12 (Out of memory)

- I see that "dev_info.rx_desc_lim.nb_max" is 65535.  This value is rounded
to the next power of 2 in "mlx5_rx_queue_setup",  which overflows and
becomes 0.

I thought that  "rte_eth_dev_adjust_nb_rx_tx_desc" should have adjusted the
value, but clearly it has not.

Thanks,
---
Amedeo

[dpdk-dev] [PATCH] doc: add tested NXP NICs information

[Shreyansh Jain]

18.11-rc4 verification done on NXP SoCs with integrated NICs.

Signed-off-by: Shreyansh Jain 
---
 doc/guides/rel_notes/release_18_11.rst | 12 
 1 file changed, 12 insertions(+)

diff --git a/doc/guides/rel_notes/release_18_11.rst 
b/doc/guides/rel_notes/release_18_11.rst
index 32ff0e5c0..ff98b15b5 100644
--- a/doc/guides/rel_notes/release_18_11.rst
+++ b/doc/guides/rel_notes/release_18_11.rst
@@ -586,3 +586,15 @@ Tested Platforms
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
=
+
+* ARM SoC combinations from NXP (with integrated NICs)
+
+   * SoC:
+
+ * NXP/Freescale QorIQ LS1046A with ARM Cortex A72
+ * NXP/Freescale QorIQ LS2088A with ARM Cortex A72
+
+   * OS:
+
+ * Ubuntu 18.04.1 LTS with NXP QorIQ LSDK 1809 support packages
+ * Ubuntu 16.04.3 LTS with NXP QorIQ LSDK 1803 support packages
-- 
2.17.1

Re: [dpdk-dev] [PATCH] doc: deprecation notice for sched API change

[Mohammad Abdul Awal]

On 14/11/2018 15:36, Jasvinder Singh wrote:

There will be change in API functions because of mbuf sched field
updates, outlined in deprecation note of mbuf->hash.sched.

Signed-off-by: Jasvinder Singh 
Acked-by: Cristian Dumitrescu 
---
  doc/guides/rel_notes/deprecation.rst | 5 +
  1 file changed, 5 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 34b28234c..b54598d07 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -34,6 +34,11 @@ Deprecation Notices
is defined in librte_sched in a non-generic way. The new generic format
will contain: queue ID, traffic class, color. Field size will not change.
  
+* sched: Some API functions will change prototype due to the above

+  deprecation note for mbuf->hash.sched, e.g. rte_sched_port_pkt_write() and
+  rte_sched_port_pkt_read() will likely have an additional parameter
+  of type struct rte_sched_port.
+
  * mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later 
and
replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()``

Acked-by: Mohammad Abdul Awal 

[dpdk-dev] [PATCH] eventdev: fix missing unlock in eth Rx adapter

[nikhil . rao]

From: Nikhil Rao 

In the eth Rx adapter SW service function,
move the return to after the spinlock unlock.

Coverity issue: 302857
Fixes: a66a83744667 ("eventdev: fix Rx SW adapter stop")
CC: sta...@dpdk.org
Signed-off-by: Nikhil Rao 
---
 lib/librte_eventdev/rte_event_eth_rx_adapter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c 
b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
index 71d008cd1..8831bc35f 100644
--- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
@@ -1165,8 +1165,8 @@ rxa_service_func(void *args)
if (rte_spinlock_trylock(&rx_adapter->rx_lock) == 0)
return 0;
if (!rx_adapter->rxa_started) {
-   return 0;
rte_spinlock_unlock(&rx_adapter->rx_lock);
+   return 0;
}
 
stats = &rx_adapter->stats;
-- 
2.14.1.145.gb3622a4

[dpdk-dev] [PATCH] examples/ipv4_multicast: remove useless mbuf info copy

[Wei Zhao]

There is not need for these useless information and
it had better be removed in oder not to confusing users.

Signed-off-by: Wei Zhao 
---
 examples/ipv4_multicast/main.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/examples/ipv4_multicast/main.c b/examples/ipv4_multicast/main.c
index 428ca46..1eef291 100644
--- a/examples/ipv4_multicast/main.c
+++ b/examples/ipv4_multicast/main.c
@@ -254,18 +254,10 @@ mcast_out_pkt(struct rte_mbuf *pkt, int use_clone)
/* prepend new header */
hdr->next = pkt;
 
-
/* update header's fields */
hdr->pkt_len = (uint16_t)(hdr->data_len + pkt->pkt_len);
hdr->nb_segs = pkt->nb_segs + 1;
 
-   /* copy metadata from source packet*/
-   hdr->port = pkt->port;
-   hdr->vlan_tci = pkt->vlan_tci;
-   hdr->vlan_tci_outer = pkt->vlan_tci_outer;
-   hdr->tx_offload = pkt->tx_offload;
-   hdr->hash = pkt->hash;
-
__rte_mbuf_sanity_check(hdr, 1);
return hdr;
 }
-- 
2.7.5

Re: [dpdk-dev] [PATCH] examples/ipv4_multicast: remove useless mbuf info copy

[Zhao1, Wei]

Add the background for this patch 
https://mails.dpdk.org/archives/dev/2018-November/119391.html


> -Original Message-
> From: Zhao1, Wei
> Sent: Wednesday, November 21, 2018 5:49 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Ananyev, Konstantin ;
> Zhao1, Wei 
> Subject: [PATCH] examples/ipv4_multicast: remove useless mbuf info copy
> 
> There is not need for these useless information and it had better be
> removed in oder not to confusing users.
> 
> Signed-off-by: Wei Zhao 
> ---
>  examples/ipv4_multicast/main.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/examples/ipv4_multicast/main.c
> b/examples/ipv4_multicast/main.c index 428ca46..1eef291 100644
> --- a/examples/ipv4_multicast/main.c
> +++ b/examples/ipv4_multicast/main.c
> @@ -254,18 +254,10 @@ mcast_out_pkt(struct rte_mbuf *pkt, int use_clone)
>   /* prepend new header */
>   hdr->next = pkt;
> 
> -
>   /* update header's fields */
>   hdr->pkt_len = (uint16_t)(hdr->data_len + pkt->pkt_len);
>   hdr->nb_segs = pkt->nb_segs + 1;
> 
> - /* copy metadata from source packet*/
> - hdr->port = pkt->port;
> - hdr->vlan_tci = pkt->vlan_tci;
> - hdr->vlan_tci_outer = pkt->vlan_tci_outer;
> - hdr->tx_offload = pkt->tx_offload;
> - hdr->hash = pkt->hash;
> -
>   __rte_mbuf_sanity_check(hdr, 1);
>   return hdr;
>  }
> --
> 2.7.5

[dpdk-dev] [PATCH v1 0/2] change max core number to 256 for Arm64 platform

[Joyce Kong]

v1: change the max core setting to 256 for arm64 platform

Joyce Kong (2):
  config: enable more than 128 cores for Arm platform
  config: enable more than 128 cores for meson build

 config/arm/meson.build | 2 +-
 config/defconfig_arm64-armv8a-linuxapp-gcc | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
2.7.4

[dpdk-dev] [PATCH v1 1/2] config: enable more than 128 cores for Arm platform

[Joyce Kong]

When running dpdk applications on cores whose ids are bigger
than original max_core setting, eal error as below:
EAL: Detected 104 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: invalid core list
-l CORELIST core indexes between 0 and 128

The fix is to increase max_core to 256 on Arm platform.

Fixes: b3ce00e5 ("mk: introduce ARMv8 architecture")
Cc: sta...@dpdk.org

Signed-off-by: Joyce Kong 
Reviewed-by: Gavin Hu 
---
 config/defconfig_arm64-armv8a-linuxapp-gcc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 1842744..a6ed90c 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -6,3 +6,4 @@
 
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y
+CONFIG_RTE_MAX_LCORE=256
-- 
2.7.4

[dpdk-dev] [PATCH v1 2/2] config: enable more than 128 cores for meson build

[Joyce Kong]

When running dpdk applications on cores whose ids are bigger
than original max_core setting, eal error as below:
EAL: Detected 104 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: invalid core list
-l CORELIST core indexes between 0 and 128

The fix is to increase max_core to 256 on thundex platform
for meson build.

Fixes: 200b88cb ("build: detect micro-arch on ARM")
Cc: sta...@dpdk.org

Signed-off-by: Joyce Kong 
Reviewed-by: Gavin Hu 
---
 config/arm/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index b755138..020df09 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -51,7 +51,7 @@ flags_cavium = [
['RTE_MACHINE', '"thunderx"'],
['RTE_CACHE_LINE_SIZE', 128],
['RTE_MAX_NUMA_NODES', 2],
-   ['RTE_MAX_LCORE', 96],
+   ['RTE_MAX_LCORE', 256],
['RTE_MAX_VFIO_GROUPS', 128],
['RTE_USE_C11_MEM_MODEL', false]]
 flags_dpaa = [
-- 
2.7.4

Re: [dpdk-dev] [PATCH v1 0/2] change max core number to 256 for Arm64 platform

[Thomas Monjalon]

Hi,

21/11/2018 12:10, Joyce Kong:
> v1: change the max core setting to 256 for arm64 platform
> 
> Joyce Kong (2):
>   config: enable more than 128 cores for Arm platform
>   config: enable more than 128 cores for meson build

2 comments:

- It doesn't need to be split in 2 commits.
- Are you sure you want this change in 18.11? No risk?

[dpdk-dev] [PATCH v2] config: enable more than 128 cores for Arm64 platform

[Joyce Kong]

When running dpdk applications on cores whose ids are bigger
than original max_core setting, eal error as below:
EAL: Detected 104 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: invalid core list
-l CORELIST core indexes between 0 and 128

The fix is to increase max_core to 256 on Arm64 platform.

Fixes: b3ce00e5 ("mk: introduce ARMv8 architecture")
Cc: sta...@dpdk.org

Signed-off-by: Joyce Kong 
Reviewed-by: Gavin Hu 
---
 config/arm/meson.build | 2 +-
 config/defconfig_arm64-armv8a-linuxapp-gcc | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index b755138..020df09 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -51,7 +51,7 @@ flags_cavium = [
['RTE_MACHINE', '"thunderx"'],
['RTE_CACHE_LINE_SIZE', 128],
['RTE_MAX_NUMA_NODES', 2],
-   ['RTE_MAX_LCORE', 96],
+   ['RTE_MAX_LCORE', 256],
['RTE_MAX_VFIO_GROUPS', 128],
['RTE_USE_C11_MEM_MODEL', false]]
 flags_dpaa = [
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 1842744..a6ed90c 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -6,3 +6,4 @@
 
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y
+CONFIG_RTE_MAX_LCORE=256
-- 
2.7.4

[dpdk-dev] [PATCH] net/mlx5: fix TPID check for VLAN push action on E-Switch

[Viacheslav Ovsiienko]

The VLAN push action on E-Switch supports only 802.1Q (0x8100)
and 802.1AD (0x88A8) Tag Protocol ID (TPID) insertions. The
parameter check for RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN action
is added.

Fixes: 57123c00c1b8 ("net/mlx5: add Linux TC flower driver for E-Switch flow")

Signed-off-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/mlx5_flow_tcf.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_flow_tcf.c b/drivers/net/mlx5/mlx5_flow_tcf.c
index 2f6b7d6..22a866d 100644
--- a/drivers/net/mlx5/mlx5_flow_tcf.c
+++ b/drivers/net/mlx5/mlx5_flow_tcf.c
@@ -1887,9 +1887,23 @@ struct pedit_parser {
case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
current_action_flag = MLX5_FLOW_ACTION_OF_POP_VLAN;
break;
-   case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN:
+   case RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN: {
+   rte_be16_t ethertype;
+
current_action_flag = MLX5_FLOW_ACTION_OF_PUSH_VLAN;
+   if (!actions->conf)
+   break;
+   conf.of_push_vlan = actions->conf;
+   ethertype = conf.of_push_vlan->ethertype;
+   if (ethertype != RTE_BE16(ETH_P_8021Q) &&
+   ethertype != RTE_BE16(ETH_P_8021AD))
+   return rte_flow_error_set
+   (error, EINVAL,
+RTE_FLOW_ERROR_TYPE_ACTION, actions,
+"vlan push TPID must be "
+"802.1Q or 802.1AD");
break;
+   }
case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
if (!(action_flags & MLX5_FLOW_ACTION_OF_PUSH_VLAN))
return rte_flow_error_set
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v2] config: enable more than 128 cores for Arm64 platform

[Jerin Jacob]

-Original Message-
> Date: Wed, 21 Nov 2018 19:27:12 +0800
> From: Joyce Kong 
> To: dev@dpdk.org
> CC: tho...@monjalon.net, jerin.ja...@caviumnetworks.com,
>  honnappa.nagaraha...@arm.com, gavin...@arm.com, sta...@dpdk.org
> Subject: [PATCH v2] config: enable more than 128 cores for Arm64 platform
> X-Mailer: git-send-email 2.7.4
> 
> 
> When running dpdk applications on cores whose ids are bigger
> than original max_core setting, eal error as below:
> EAL: Detected 104 lcore(s)
> EAL: Detected 2 NUMA nodes
> EAL: invalid core list
> -l CORELIST core indexes between 0 and 128
> 
> The fix is to increase max_core to 256 on Arm64 platform.
> 
> Fixes: b3ce00e5 ("mk: introduce ARMv8 architecture")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Joyce Kong 
> Reviewed-by: Gavin Hu 
> ---
>  config/arm/meson.build | 2 +-
>  config/defconfig_arm64-armv8a-linuxapp-gcc | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index b755138..020df09 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -51,7 +51,7 @@ flags_cavium = [
> ['RTE_MACHINE', '"thunderx"'],
> ['RTE_CACHE_LINE_SIZE', 128],
> ['RTE_MAX_NUMA_NODES', 2],
> -   ['RTE_MAX_LCORE', 96],
> +   ['RTE_MAX_LCORE', 256],

This change makes thunderx config to 256 cores not armv8. 
For generic config, it needs to be under "flags_generic"
not under "flags_cavium". Just like you did for updating
defconfig_arm64-armv8a-linuxapp-gcc config instead of
defconfig_arm64-thunderx-linuxapp-gcc

> ['RTE_MAX_VFIO_GROUPS', 128],
> ['RTE_USE_C11_MEM_MODEL', false]]
>  flags_dpaa = [
> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
> b/config/defconfig_arm64-armv8a-linuxapp-gcc
> index 1842744..a6ed90c 100644
> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> @@ -6,3 +6,4 @@
> 
>  CONFIG_RTE_TOOLCHAIN="gcc"
>  CONFIG_RTE_TOOLCHAIN_GCC=y
> +CONFIG_RTE_MAX_LCORE=256
> --
> 2.7.4
> 

Re: [dpdk-dev] Question about telemetry on 18.11 release

[Ferruh Yigit]

On 11/21/2018 7:48 AM, Hideyuki Yamashita wrote:
> Hello,
> 
> I have some basic questions about telemetry API
> which is planned to be relaesed in 18.11.
> 
> Note that I have read the follwoing document.
> https://doc.dpdk.org/guides/howto/telemetry.html
> 
> Q1. In general dpdk application use polling when
> receiving packets. So CPU usage is always looks 100%
> when measured using e.g. vmstat even if there is no packet receiving.
> (CPU is busy for polling packets)
> Is that correct?
> 
> Q2. Is it correct understanding that dpdk application 
> can send "any" value(or metric) to client if client
> requested via "telemetry" framework?
> 
> Q3.Is it possible to query "real cpu usage" from dpdk
> application using "telemetry" framework?
> ("real cpu usage" I mean if 0 pakcket incoming,
> cpu usage indicates almost 0 %)
> 
> Q4. Is it possible to inform client about fault or some
> trouble from dpdk application?
> 
> Background  I ask above is that 
> - I am relative new to DPDK world and have almost no knowledge about
> "telemetry"
> - I am interested in how dpdk applications can "scales" on platform
> like OpenStack. I think some mesurement mechanism required
> and I thought it might be "telemetry" APIs.

Briefly I think yes, telemetry can be measurement mechanism and interface to
external application. Cc'ed Harry & Kevin for more detailed answers.

> 
> Thanks in advance.
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> 

Re: [dpdk-dev] [PATCH v1 0/2] change max core number to 256 for Arm64 platform

[Joyce Kong (Arm Technology China)]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Wednesday, November 21, 2018 7:14 PM
> To: Joyce Kong (Arm Technology China) 
> Cc: dev@dpdk.org; jerin.ja...@caviumnetworks.com; Honnappa Nagarahalli
> ; Gavin Hu (Arm Technology China)
> ; hemant.agra...@nxp.com
> Subject: Re: [PATCH v1 0/2] change max core number to 256 for Arm64
> platform
>
> Hi,
>
> 21/11/2018 12:10, Joyce Kong:
> > v1: change the max core setting to 256 for arm64 platform
> >
> > Joyce Kong (2):
> >   config: enable more than 128 cores for Arm platform
> >   config: enable more than 128 cores for meson build
>
> 2 comments:
>
> - It doesn't need to be split in 2 commits.
Combined into 1 commit in v2.

> - Are you sure you want this change in 18.11? No risk?
Yes, no risk.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

[dpdk-dev] Last call for deprecation notices

[Ferruh Yigit]

If there are any planned API/ABI change on v19.02, deprecation notice patches
for them should be sent, approved and merged withing v18.11 scope which is only
a few days away.

If you will be working on a feature for v19.02, please take some time think if
it will cause any API/ABI change.
And if it will so, please send the deprecation notice for it ASAP, otherwise
your feature can be blocked for the release because of API/ABI breakage it 
causes.

Thanks,
ferruh

[dpdk-dev] [PATCH 1/2] bitmap: remove useless code

[Anatoly Burakov]

RTE_BITMAP_OPTIMIZATIONS was never set to 0 and makes no sense
anyway, so remove all code related to it. Also, drop the "likely"
for bsf64 code, because it's a generic function and we cannot
make any assumptions about likely values of incoming arguments.

Signed-off-by: Anatoly Burakov 
Acked-by: Cristian Dumitrescu 
---
 lib/librte_eal/common/include/rte_bitmap.h | 33 +-
 1 file changed, 1 insertion(+), 32 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_bitmap.h 
b/lib/librte_eal/common/include/rte_bitmap.h
index 7a36ce73c..d2ed6204c 100644
--- a/lib/librte_eal/common/include/rte_bitmap.h
+++ b/lib/librte_eal/common/include/rte_bitmap.h
@@ -43,10 +43,6 @@ extern "C" {
 #include 
 #include 
 
-#ifndef RTE_BITMAP_OPTIMIZATIONS
-#define RTE_BITMAP_OPTIMIZATIONS1
-#endif
-
 /* Slab */
 #define RTE_BITMAP_SLAB_BIT_SIZE 64
 #define RTE_BITMAP_SLAB_BIT_SIZE_LOG26
@@ -97,43 +93,16 @@ __rte_bitmap_index2_set(struct rte_bitmap *bmp)
bmp->index2 = (((bmp->index1 << RTE_BITMAP_SLAB_BIT_SIZE_LOG2) + 
bmp->offset1) << RTE_BITMAP_CL_SLAB_SIZE_LOG2);
 }
 
-#if RTE_BITMAP_OPTIMIZATIONS
-
 static inline int
 rte_bsf64(uint64_t slab, uint32_t *pos)
 {
-   if (likely(slab == 0)) {
+   if (slab == 0)
return 0;
-   }
 
*pos = __builtin_ctzll(slab);
return 1;
 }
 
-#else
-
-static inline int
-rte_bsf64(uint64_t slab, uint32_t *pos)
-{
-   uint64_t mask;
-   uint32_t i;
-
-   if (likely(slab == 0)) {
-   return 0;
-   }
-
-   for (i = 0, mask = 1; i < RTE_BITMAP_SLAB_BIT_SIZE; i ++, mask <<= 1) {
-   if (unlikely(slab & mask)) {
-   *pos = i;
-   return 1;
-   }
-   }
-
-   return 0;
-}
-
-#endif
-
 static inline uint32_t
 __rte_bitmap_get_memory_footprint(uint32_t n_bits,
uint32_t *array1_byte_offset, uint32_t *array1_slabs,
-- 
2.17.1

[dpdk-dev] [PATCH 2/2] bitmap: deprecate and rename rte_bsf64

[Anatoly Burakov]

Rename rte_bsf64 to rte_bsf64_safe (this is a "safe" version in
that it prevents undefined behavior by checking if incoming
parameter is zero) and move it to common header.

Signed-off-by: Anatoly Burakov 
Acked-by: Cristian Dumitrescu 
Acked-by: Jasvinder Singh 
---
 doc/guides/rel_notes/deprecation.rst   |  5 +
 lib/librte_eal/common/include/rte_bitmap.h | 14 -
 lib/librte_eal/common/include/rte_common.h | 23 ++
 3 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 34b28234c..553e99171 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -22,6 +22,11 @@ Deprecation Notices
 
 + ``rte_eal_devargs_type_count``
 
+* eal: function ``rte_bsf64`` in ``rte_bitmap.h`` has been renamed to
+  ``rte_bsf64_safe`` and moved to ``rte_common.h``. A new ``rte_bsf64`` 
function
+  will be added in the next release in ``rte_common.h`` that follows convention
+  set by existing ``rte_bsf32`` function.
+
 * pci: Several exposed functions are misnamed.
   The following functions are deprecated starting from v17.11 and are replaced:
 
diff --git a/lib/librte_eal/common/include/rte_bitmap.h 
b/lib/librte_eal/common/include/rte_bitmap.h
index d2ed6204c..77727c828 100644
--- a/lib/librte_eal/common/include/rte_bitmap.h
+++ b/lib/librte_eal/common/include/rte_bitmap.h
@@ -93,14 +93,10 @@ __rte_bitmap_index2_set(struct rte_bitmap *bmp)
bmp->index2 = (((bmp->index1 << RTE_BITMAP_SLAB_BIT_SIZE_LOG2) + 
bmp->offset1) << RTE_BITMAP_CL_SLAB_SIZE_LOG2);
 }
 
-static inline int
+static inline int __rte_deprecated
 rte_bsf64(uint64_t slab, uint32_t *pos)
 {
-   if (slab == 0)
-   return 0;
-
-   *pos = __builtin_ctzll(slab);
-   return 1;
+   return rte_bsf64_safe(slab, pos);
 }
 
 static inline uint32_t
@@ -408,9 +404,8 @@ __rte_bitmap_scan_search(struct rte_bitmap *bmp)
value1 = bmp->array1[bmp->index1];
value1 &= __rte_bitmap_mask1_get(bmp);
 
-   if (rte_bsf64(value1, &bmp->offset1)) {
+   if (rte_bsf64_safe(value1, &bmp->offset1))
return 1;
-   }
 
__rte_bitmap_index1_inc(bmp);
bmp->offset1 = 0;
@@ -419,9 +414,8 @@ __rte_bitmap_scan_search(struct rte_bitmap *bmp)
for (i = 0; i < bmp->array1_size; i ++, __rte_bitmap_index1_inc(bmp)) {
value1 = bmp->array1[bmp->index1];
 
-   if (rte_bsf64(value1, &bmp->offset1)) {
+   if (rte_bsf64_safe(value1, &bmp->offset1))
return 1;
-   }
}
 
return 0;
diff --git a/lib/librte_eal/common/include/rte_common.h 
b/lib/librte_eal/common/include/rte_common.h
index 87f0f6302..d115b175c 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -491,6 +491,29 @@ rte_fls_u32(uint32_t x)
return (x == 0) ? 0 : 32 - __builtin_clz(x);
 }
 
+/**
+ * Searches the input parameter for the least significant set bit
+ * (starting from zero). Safe version (checks for input parameter being zero).
+ *
+ * @warning ``pos`` must be a valid pointer. It is not checked!
+ *
+ * @param v
+ * The input parameter.
+ * @param pos
+ * If ``v`` was not 0, this value will contain position of least 
significant
+ * bit within the input parameter.
+ * @return
+ * Returns 0 if ``v`` was 0, otherwise returns 1.
+ */
+static inline int
+rte_bsf64_safe(uint64_t v, uint32_t *pos)
+{
+   if (v == 0)
+   return 0;
+
+   *pos = __builtin_ctzll(v);
+   return 1;
+}
 
 #ifndef offsetof
 /** Return the offset of a field in a structure. */
-- 
2.17.1

Re: [dpdk-dev] [PATCH] eventdev: fix missing unlock in eth Rx adapter

[Jerin Jacob]

-Original Message-
> Date: Wed, 21 Nov 2018 03:39:15 +0530
> From: nikhil@intel.com
> To: dev@dpdk.org
> CC: Nikhil Rao , sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] eventdev: fix missing unlock in eth Rx adapter
> X-Mailer: git-send-email 2.14.1.145.gb3622a4
> 
> 
> From: Nikhil Rao 
> 
> In the eth Rx adapter SW service function,
> move the return to after the spinlock unlock.
> 
> Coverity issue: 302857
> Fixes: a66a83744667 ("eventdev: fix Rx SW adapter stop")
> CC: sta...@dpdk.org
> Signed-off-by: Nikhil Rao 

Acked-by: Jerin Jacob 

> ---
>  lib/librte_eventdev/rte_event_eth_rx_adapter.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c 
> b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> index 71d008cd1..8831bc35f 100644
> --- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> @@ -1165,8 +1165,8 @@ rxa_service_func(void *args)
> if (rte_spinlock_trylock(&rx_adapter->rx_lock) == 0)
> return 0;
> if (!rx_adapter->rxa_started) {
> -   return 0;
> rte_spinlock_unlock(&rx_adapter->rx_lock);
> +   return 0;
> }
> 
> stats = &rx_adapter->stats;
> --
> 2.14.1.145.gb3622a4
> 

[dpdk-dev] [PATCH] ethdev: fix memory leak on removing eth rxtx callback

[wanlebing]

eth rxtx callback is dynamically allocated using rte_zmalloc()
but not released. Fix it by calling rte_free() to free callback
when removing rxtx callback.

Signed-off-by: wanlebing 
Signed-off-by: wanlebing 
---
 lib/librte_ethdev/rte_ethdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 5f858174b..f00311047 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -3926,6 +3926,7 @@ rte_eth_remove_rx_callback(uint16_t port_id, uint16_t 
queue_id,
if (cb == user_cb) {
/* Remove the user cb from the callback list. */
*prev_cb = cb->next;
+   rte_free(cb);
ret = 0;
break;
}
@@ -3960,6 +3961,7 @@ rte_eth_remove_tx_callback(uint16_t port_id, uint16_t 
queue_id,
if (cb == user_cb) {
/* Remove the user cb from the callback list. */
*prev_cb = cb->next;
+   rte_free(cb);
ret = 0;
break;
}
-- 
2.14.1

Re: [dpdk-dev] [PATCH v4 4/9] app/procinfo: add support for show port

[Pattan, Reshma]

> -Original Message-
> From: Varghese, Vipin
> Sent: Tuesday, November 6, 2018 12:49 PM
> To: dev@dpdk.org; tho...@monjalon.net; Pattan, Reshma
> ; step...@networkplumber.org; Mcnamara, John
> 
> Cc: Byrne, Stephen1 ; Glynn, Michael J
> ; Patel, Amol ; Varghese,
> Vipin 
> Subject: [PATCH v4 4/9] app/procinfo: add support for show port


> + snprintf(bdr_str, 100, " Port (%u)", i);

%s/100/MAX_STRING_LEN ?

> + ret = rte_eth_dev_rss_hash_conf_get(i, &rss_conf);
> + if ((ret) || (rss_conf.rss_key == NULL))
> + continue;
> +
> + printf("\t  -- RSS len %u key (hex):",
> + rss_conf.rss_key_len);
> + for (k = 0; k < rss_conf.rss_key_len; k++)
> + printf(" %x", rss_conf.rss_key[k]);
> + printf("\t  -- hf 0x%"PRIx64"\n",
> + rss_conf.rss_hf);
> + }
> +

Should this be out of queues for loop? 

Thanks,
Reshma

Re: [dpdk-dev] [PATCH v4 5/9] app/procinfo: add support for show tm

[Pattan, Reshma]

> -Original Message-
> From: Varghese, Vipin
> Sent: Tuesday, November 6, 2018 12:49 PM
> To: dev@dpdk.org; tho...@monjalon.net; Pattan, Reshma
> ; step...@networkplumber.org; Mcnamara, John
> 
> Cc: Byrne, Stephen1 ; Glynn, Michael J
> ; Patel, Amol ; Varghese,
> Vipin 
> Subject: [PATCH v4 5/9] app/procinfo: add support for show tm


> + if ((ret) | (!is_leaf))
> +

Is the operator here should be || ?

[dpdk-dev] [PATCH] app/testpmd: fix mpls bos bit default value

[Saleh Alsouqi]

The Bottom-of-Stack (bos) bit of MPLS indicates
whether its the last MPLS layer (1) or not (0).

Indicating that the encapsulating MPLS is the
last MPLS layer in the packet as the default
behavior is more appropriate since multiple
encapsulation actions is not supported.

Fixes: 3e77031be855 ("app/testpmd: add MPLSoGRE encapsulation")
Fixes: a1191d39cb57 ("app/testpmd: add MPLSoUDP encapsulation")
cc: sta...@dpdk.org

Signed-off-by: Saleh AlSouqi 
---
 app/test-pmd/cmdline_flow.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 23ea7cc82..5c0108fa7 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -3808,6 +3808,7 @@ parse_vc_action_mplsogre_encap(struct context *ctx, const 
struct token *token,
header += sizeof(gre);
memcpy(mpls.label_tc_s, mplsogre_encap_conf.label,
   RTE_DIM(mplsogre_encap_conf.label));
+   mpls.label_tc_s[2] |= 0x1;
memcpy(header, &mpls, sizeof(mpls));
header += sizeof(mpls);
action_encap_data->conf.size = header -
@@ -3998,6 +3999,7 @@ parse_vc_action_mplsoudp_encap(struct context *ctx, const 
struct token *token,
header += sizeof(udp);
memcpy(mpls.label_tc_s, mplsoudp_encap_conf.label,
   RTE_DIM(mplsoudp_encap_conf.label));
+   mpls.label_tc_s[2] |= 0x1;
memcpy(header, &mpls, sizeof(mpls));
header += sizeof(mpls);
action_encap_data->conf.size = header -
-- 
2.14.1

Re: [dpdk-dev] [PATCH] ethdev: fix memory leak on removing eth rxtx callback

[Ferruh Yigit]

On 11/21/2018 1:11 PM, wanlebing wrote:
> eth rxtx callback is dynamically allocated using rte_zmalloc()
> but not released. Fix it by calling rte_free() to free callback
> when removing rxtx callback.

I guess they are not freed intentionally because there is no safe way to do it.
I remember Konstantin sent an RFC in the past to rework the callbacks, cc'ed him
for more details.

> 
> Signed-off-by: wanlebing 
> Signed-off-by: wanlebing 
> ---
>  lib/librte_ethdev/rte_ethdev.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 5f858174b..f00311047 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -3926,6 +3926,7 @@ rte_eth_remove_rx_callback(uint16_t port_id, uint16_t 
> queue_id,
>   if (cb == user_cb) {
>   /* Remove the user cb from the callback list. */
>   *prev_cb = cb->next;
> + rte_free(cb);
>   ret = 0;
>   break;
>   }
> @@ -3960,6 +3961,7 @@ rte_eth_remove_tx_callback(uint16_t port_id, uint16_t 
> queue_id,
>   if (cb == user_cb) {
>   /* Remove the user cb from the callback list. */
>   *prev_cb = cb->next;
> + rte_free(cb);
>   ret = 0;
>   break;
>   }
> 

Re: [dpdk-dev] [PATCH 1/2] doc: update Mellanox release notes

[Ferruh Yigit]

On 11/19/2018 12:46 PM, Shahaf Shuler wrote:
> Signed-off-by: Shahaf Shuler 

Series applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH] app/testpmd: fix mpls bos bit default value

[Ori Kam]

> -Original Message-
> From: Saleh Alsouqi
> Sent: Wednesday, November 21, 2018 4:47 PM
> To: wenzhuo...@intel.com; jingjing...@intel.com;
> bernard.iremon...@intel.com
> Cc: dev@dpdk.org; Ori Kam ; sta...@dpdk.org
> Subject: [PATCH] app/testpmd: fix mpls bos bit default value
> 
> The Bottom-of-Stack (bos) bit of MPLS indicates
> whether its the last MPLS layer (1) or not (0).
> 
> Indicating that the encapsulating MPLS is the
> last MPLS layer in the packet as the default
> behavior is more appropriate since multiple
> encapsulation actions is not supported.
> 
> Fixes: 3e77031be855 ("app/testpmd: add MPLSoGRE encapsulation")
> Fixes: a1191d39cb57 ("app/testpmd: add MPLSoUDP encapsulation")
> cc: sta...@dpdk.org
> 
> Signed-off-by: Saleh AlSouqi 
> ---
>  app/test-pmd/cmdline_flow.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 23ea7cc82..5c0108fa7 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -3808,6 +3808,7 @@ parse_vc_action_mplsogre_encap(struct context
> *ctx, const struct token *token,
>   header += sizeof(gre);
>   memcpy(mpls.label_tc_s, mplsogre_encap_conf.label,
>  RTE_DIM(mplsogre_encap_conf.label));
> + mpls.label_tc_s[2] |= 0x1;
>   memcpy(header, &mpls, sizeof(mpls));
>   header += sizeof(mpls);
>   action_encap_data->conf.size = header -
> @@ -3998,6 +3999,7 @@ parse_vc_action_mplsoudp_encap(struct context
> *ctx, const struct token *token,
>   header += sizeof(udp);
>   memcpy(mpls.label_tc_s, mplsoudp_encap_conf.label,
>  RTE_DIM(mplsoudp_encap_conf.label));
> + mpls.label_tc_s[2] |= 0x1;
>   memcpy(header, &mpls, sizeof(mpls));
>   header += sizeof(mpls);
>   action_encap_data->conf.size = header -
> --
> 2.14.1

Acked-by: Ori Kam 

Thanks,
Ori

Re: [dpdk-dev] [dpdk-stable] [PATCH v3] net/ena: fix out of order completion

[Ferruh Yigit]

On 11/21/2018 8:21 AM, Rafal Kozik wrote:
> rx_buffer_info should be refill not linearly, but out of order.
> IDs should be taken from empty_rx_reqs array.
> 
> rx_refill_buffer is introduced to temporary storage
> bulk of mbufs taken from pool.
> 
> In case of error unused mbufs are put back to pool.
> 
> Fixes: c2034976673d ("net/ena: add Rx out of order completion")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Rafal Kozik 
> Acked-by: Michal Krawczyk 

Hi Rafal,

This patch sent after rc4, I suggest pushing this out to next release, any
objection? Is this really a critical patch to get in at this stage?

Re: [dpdk-dev] [PATCH] app/testpmd: fix MPLSoUDP encapsulation

[Ferruh Yigit]

On 11/20/2018 8:23 AM, Ori Kam wrote:
> 
> 
>> -Original Message-
>> From: dev  On Behalf Of Dekel Peled
>> Sent: Monday, November 19, 2018 6:55 PM
>> To: wenzhuo...@intel.com; jingjing...@intel.com;
>> bernard.iremon...@intel.com
>> Cc: dev@dpdk.org; Ori Kam ; Shahaf Shuler
>> ; Dekel Peled 
>> Subject: [dpdk-dev] [PATCH] app/testpmd: fix MPLSoUDP encapsulation
>>
>> Set MPLS label value in appropriate location at mplsoudp_encap_conf,
>> so it is correctly copied to rte_flow_item_mpls.
>>
>> Fixes: a1191d39cb57 ("app/testpmd: add MPLSoUDP encapsulation")
>> Cc: or...@mellanox.com
>>
>> Signed-off-by: Dekel Peled 
>> ---
>>  app/test-pmd/cmdline.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
>> index 1275074..40e64cc 100644
>> --- a/app/test-pmd/cmdline.c
>> +++ b/app/test-pmd/cmdline.c
>> @@ -15804,10 +15804,10 @@ static void
>> cmd_set_mplsoudp_encap_parsed(void *parsed_result,
>>  struct cmd_set_mplsoudp_encap_result *res = parsed_result;
>>  union {
>>  uint32_t mplsoudp_label;
>> -uint8_t label[3];
>> +uint8_t label[4];
>>  } id = {
>>  .mplsoudp_label =
>> -rte_cpu_to_be_32(res->label) & RTE_BE32(0x00ff),
>> +rte_cpu_to_be_32(res->label<<4) &
>> RTE_BE32(0x00ff),
>>  };
>>
>>  if (strcmp(res->mplsoudp, "mplsoudp_encap") == 0)
>> --
>> 1.8.3.1
> 
> Acked-by: Ori Kam 

Hi Ori, Dekel,

What is the scope of this patch? Briefly how critical it is and what will be
broken and what is exposure of it?

Re: [dpdk-dev] [PATCH] ethdev: remove unused DEFERRED device state

[Ferruh Yigit]

On 11/20/2018 2:15 PM, Matan Azrad wrote:
> 
> 
> From: Ferruh Yigit
>> DEFERRED state replaced by ownership concept and it is no more used as
>> code comment states.
>>
>> ethdev ABI broken on this release use this opportunity to remove DEFERRED
>> state.
>>
>> Signed-off-by: Ferruh Yigit 
> Acked-by: Matan Azrad 

Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH] net/softnic: fix undefined dev info fields

[Ferruh Yigit]

On 11/20/2018 10:35 PM, Ferruh Yigit wrote:
> On 11/20/2018 1:00 PM, Jasvinder Singh wrote:
>> The memcpy operation overwrites the device info fields set
>> by ethdev API and leaves the device field undefined.
>> Thus, replaces memcpy by only updating the required fields
>> at the driver layer.
>>
>> error log: testpmd> show port info 1
>>
>>  Infos for port 1  
>> MAC address: 00:00:00:00:00:00
>> Device name: net_softnic0
>>
>> Segmentation fault.
>> port_infos_display (port_id=1) at /dpdk/app/test-pmd/config.c:418
>> if (dev_info.device->devargs && dev_info.device->devargs->args)
>>
>> Fixes: cc6d421574fe ("net/softnic: add softnic PMD")
>>
>> Signed-off-by: Jasvinder Singh 
> 
> Reviewed-by: Ferruh Yigit 
> 

Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH] app/testpmd: fix MPLSoUDP encapsulation

[Ori Kam]

> -Original Message-
> From: Ferruh Yigit 
> Sent: Wednesday, November 21, 2018 5:19 PM
> To: Ori Kam ; Dekel Peled ;
> wenzhuo...@intel.com; jingjing...@intel.com; bernard.iremon...@intel.com
> Cc: dev@dpdk.org; Shahaf Shuler 
> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix MPLSoUDP encapsulation
> 
> On 11/20/2018 8:23 AM, Ori Kam wrote:
> >
> >
> >> -Original Message-
> >> From: dev  On Behalf Of Dekel Peled
> >> Sent: Monday, November 19, 2018 6:55 PM
> >> To: wenzhuo...@intel.com; jingjing...@intel.com;
> >> bernard.iremon...@intel.com
> >> Cc: dev@dpdk.org; Ori Kam ; Shahaf Shuler
> >> ; Dekel Peled 
> >> Subject: [dpdk-dev] [PATCH] app/testpmd: fix MPLSoUDP encapsulation
> >>
> >> Set MPLS label value in appropriate location at mplsoudp_encap_conf,
> >> so it is correctly copied to rte_flow_item_mpls.
> >>
> >> Fixes: a1191d39cb57 ("app/testpmd: add MPLSoUDP encapsulation")
> >> Cc: or...@mellanox.com
> >>
> >> Signed-off-by: Dekel Peled 
> >> ---
> >>  app/test-pmd/cmdline.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> >> index 1275074..40e64cc 100644
> >> --- a/app/test-pmd/cmdline.c
> >> +++ b/app/test-pmd/cmdline.c
> >> @@ -15804,10 +15804,10 @@ static void
> >> cmd_set_mplsoudp_encap_parsed(void *parsed_result,
> >>struct cmd_set_mplsoudp_encap_result *res = parsed_result;
> >>union {
> >>uint32_t mplsoudp_label;
> >> -  uint8_t label[3];
> >> +  uint8_t label[4];
> >>} id = {
> >>.mplsoudp_label =
> >> -  rte_cpu_to_be_32(res->label) & RTE_BE32(0x00ff),
> >> +  rte_cpu_to_be_32(res->label<<4) &
> >> RTE_BE32(0x00ff),
> >>};
> >>
> >>if (strcmp(res->mplsoudp, "mplsoudp_encap") == 0)
> >> --
> >> 1.8.3.1
> >
> > Acked-by: Ori Kam 
> 
> Hi Ori, Dekel,
> 
> What is the scope of this patch? Briefly how critical it is and what will be
> broken and what is exposure of it?

The only issue is that we are setting incorrect MPLS label.
As defined by the MPLS spec the label is 20 bits, so this patch simply
pushes the label to the correct place.
I don't think that there any exposure from this patch.

Best,
Ori

[dpdk-dev] [PATCH] doc: announce kvargs API change

[Thomas Monjalon]

In some usages, kvlist is processed one time in rte_kvargs_process(),
and it is processed a second time if need to check whether it was matched.
In order to simplify implementation of kvargs checks, a new callback
may be used for "no match" cases.

The change of the function prototype would be as below:

 int
 rte_kvargs_process(const struct rte_kvargs *kvlist,
const char *key_match,
-   arg_handler_t handler,
+   arg_handler_t match_handler,
+   arg_handler_t no_match_handler,
void *opaque_arg)

Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/deprecation.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 34b28234c..7af65cd4b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -11,6 +11,10 @@ API and ABI deprecation notices are to be posted here.
 Deprecation Notices
 ---
 
+* kvargs: The function ``rte_kvargs_process`` will get a new parameter
+  for a function pointer called in case of no match of the key.
+  It will ease implementation of default values or check for mandatory keys.
+
 * eal: both declaring and identifying devices will be streamlined in v18.11.
   New functions will appear to query a specific port from buses, classes of
   device and device drivers. Device declaration will be made coherent with the
-- 
2.19.0

Re: [dpdk-dev] [dpdk-stable] [PATCH v3] net/ena: fix out of order completion

[Rafał Kozik]

Hello Ferruh,

this patch fix issue in Rx path which could have caused receive of
wrong packets.
If it is possible, I would be very grateful if this patch could be
applied to v18.11.

Best regards,
Rafal

śr., 21 lis 2018 o 16:16 Ferruh Yigit  napisał(a):
>
> On 11/21/2018 8:21 AM, Rafal Kozik wrote:
> > rx_buffer_info should be refill not linearly, but out of order.
> > IDs should be taken from empty_rx_reqs array.
> >
> > rx_refill_buffer is introduced to temporary storage
> > bulk of mbufs taken from pool.
> >
> > In case of error unused mbufs are put back to pool.
> >
> > Fixes: c2034976673d ("net/ena: add Rx out of order completion")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Rafal Kozik 
> > Acked-by: Michal Krawczyk 
>
> Hi Rafal,
>
> This patch sent after rc4, I suggest pushing this out to next release, any
> objection? Is this really a critical patch to get in at this stage?

Re: [dpdk-dev] mlx5 under FreeBSD

[Mit Matelske]

> 
> Rather than building a complex shim, why not just have an OS dependent section
> of the driver.  The bigger issue is that the kernel side functionality in BSD
> is different or missing.  For example TAP API is different and not 
> multi-queue.

Once I started working on it, I had to go this route.  I haven't been able to 
but much 
time into it yet, but it is coming along:

EAL: PCI device :b3:00.0 on NUMA socket 0
EAL:   probe driver: 15b3:1013 net_mlx5
net_mlx5: mlx5.c:1315: mlx5_pci_probe(): checking device "mlx5_0" uverbs0 
/sys/class/infiniband_verbs/uverbs0 /sys/class/infiniband/mlx5_0
net_mlx5: mlx5.c:1325: mlx5_pci_probe(): PCI information matches for device 
"mlx5_0"
net_mlx5: mlx5.c:1315: mlx5_pci_probe(): checking device "mlx5_1" uverbs1 
/sys/class/infiniband_verbs/uverbs1 /sys/class/infiniband/mlx5_1
net_mlx5: mlx5.c:1382: mlx5_pci_probe(): no switch support detected
net_mlx5: mlx5.c:796: mlx5_dev_spawn(): MPW isn't supported
net_mlx5: mlx5.c:852: mlx5_dev_spawn(): tunnel offloading disabled due to old 
OFED/rdma-core version
net_mlx5: mlx5.c:864: mlx5_dev_spawn(): MPLS over GRE/UDP tunnel offloading 
disabled due to old OFED/rdma-core version or firmware configuration
net_mlx5: mlx5.c:877: mlx5_dev_spawn(): naming Ethernet device ":b3:00.0"
net_mlx5: mlx5.c:1007: mlx5_dev_spawn(): checksum offloading is supported
net_mlx5: mlx5.c:1024: mlx5_dev_spawn(): maximum Rx indirection table size is 
512
net_mlx5: mlx5.c:1028: mlx5_dev_spawn(): VLAN stripping is not supported
net_mlx5: mlx5.c:1032: mlx5_dev_spawn(): FCS stripping configuration is not 
supported
net_mlx5: mlx5.c:1037: mlx5_dev_spawn(): hardware Rx end alignment padding is 
not supported
net_mlx5: mlx5.c:1052: mlx5_dev_spawn(): MPS is disabled
net_mlx5: mlx5.c:628: mlx5_uar_init_primary(): port 0 reserved UAR address 
space: 0x88000
net_mlx5: mlx5.c:1107: mlx5_dev_spawn(): port 0 MAC address is 00:90:0b:78:2a:ea
net_mlx5: mlx5.c:1114: mlx5_dev_spawn(): port 0 ifname is "mce0"
net_mlx5: mlx5.c:1127: mlx5_dev_spawn(): port 0 MTU is 1500
net_mlx5: mlx5.c:1142: mlx5_dev_spawn(): flow rules relying on switch offloads 
will not be supported: cannot open libmnl socket: Address family not supported 
by protocol family
net_mlx5: mlx5.c:1176: mlx5_dev_spawn(): port 0 forcing Ethernet interface up
net_mlx5: mlx5_ethdev.c:735: mlx5_link_update_unlocked_gs(): port 0 
ioctl(SIOCGIFFLAGS) failed: No such file or directory
net_mlx5: mlx5_ethdev.c:664: mlx5_link_update_unlocked_gset(): port 0 
ioctl(SIOCGIFFLAGS) failed: No such file or directory
net_mlx5: mlx5_rxq.c:2150: mlx5_hrxq_drop_new(): port 0 cannot allocate QP for 
drop queue
Segmentation fault (core dumped)

Working through mlx5_ethdev now...

Mit

Re: [dpdk-dev] [PATCH v4 8/9] app/procinfo: add support for show mempool

[Pattan, Reshma]

> -Original Message-
> From: Varghese, Vipin
> Sent: Tuesday, November 6, 2018 12:49 PM
> To: dev@dpdk.org; tho...@monjalon.net; Pattan, Reshma
> ; step...@networkplumber.org; Mcnamara, John
> 
> Cc: Byrne, Stephen1 ; Glynn, Michael J
> ; Patel, Amol ; Varghese,
> Vipin 
> + /* iterate each object */
> + int ret = rte_mempool_obj_iter(ptr,
> + mempool_itr_obj, NULL);

rte_mempool_obj_iter returns uint32_t,  so good to use  "ret" type to be 
uint32_t. So it will be in synch with below printf too.

> + printf("  - iterated %u objects\n", ret);

Thanks,
Reshma

Re: [dpdk-dev] [PATCH v5 0/4] introduces the enetc PMD driver

[Ferruh Yigit]

On 10/3/2018 8:48 PM, Ferruh Yigit wrote:
> On 10/3/2018 2:36 PM, Gagandeep Singh wrote:
>> *ENETC* PMD driver which integrates with the existing PCI bus.
>> Document is also part of the set
>>
>> v4->v5 Change-log:
>> * missing commit info added in patch [3/4]
>> * dev_close API implemented
>> * link_update API updated
>> * all comments handled
>>
>> v3->v4 Change-log:
>> * fixed patch set
>>
>> v2->v3 Change-log:
>> * Added a release note
>> * commom part of documentation is removed
>> * cflag Werror added in Makefile
>> * private list of RX/TX queues removed
>> * added the dev_start and dev_stop APIs
>> * added rx/tx queue release APIs
>> * packet parse type feature enabled
>>
>> v1->v2 Change-log:
>> * document improvement
>> * checkpatch warnings removed
>>
>> Gagandeep Singh (4):
>>   net/enetc: add ENETC PMD with basic operations
>>   net/enetc: enable Rx and Tx
>>   net/enetc: support packet parse type
>>   doc: add usage doc for ENETC PMD
> 
> For series,
> Reviewed-by: Ferruh Yigit 
> 
> Acked-by: Shreyansh Jain 
> 
> Series applied to dpdk-next-net/master, thanks.
> 

Can you please send a web page patch [1], to announce NIC support [2]?

You can benefit from recent samples like 'Marvell NETA' [3] or 'Aquantia
Atlantic' [4].

Thanks,
ferruh


[1]
https://git.dpdk.org/tools/dpdk-web/

[2]
https://core.dpdk.org/supported/

[3]
https://mails.dpdk.org/archives/web/2018-October/000908.html

[4]
https://mails.dpdk.org/archives/web/2018-November/000922.html

[dpdk-dev] [PATCH] net/mlx5: fix VLAN inner ethernet type on E-Switch

[Viacheslav Ovsiienko]

The TCA_FLOWER_KEY_VLAN_ETH_TYPE should be specified for the E-Switch
Flows with VLAN and L3 pattern items in the Netlink messages. The patch
adds missing flower key to the messages. This patch partially reverts to
the code smashed by http://patches.dpdk.org/patch/47781

Fixes: 251e8d02cf37 ("net/mlx5: add VXLAN to flow translate routine")

Signed-off-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/mlx5_flow_tcf.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_tcf.c b/drivers/net/mlx5/mlx5_flow_tcf.c
index 22a866d..fb284c3 100644
--- a/drivers/net/mlx5/mlx5_flow_tcf.c
+++ b/drivers/net/mlx5/mlx5_flow_tcf.c
@@ -3260,7 +3260,8 @@ struct pedit_parser {
assert(mask.ipv4);
spec.ipv4 = items->spec;
if (!decap.vxlan) {
-   if (!eth_type_set && !vlan_eth_type_set)
+   if (!eth_type_set ||
+   (!vlan_eth_type_set && vlan_present))
mnl_attr_put_u16
(nlh,
 vlan_present ?
@@ -3317,14 +3318,14 @@ struct pedit_parser {
assert(mask.ipv6);
spec.ipv6 = items->spec;
if (!decap.vxlan) {
-   if (!eth_type_set || !vlan_eth_type_set) {
+   if (!eth_type_set ||
+   (!vlan_eth_type_set && vlan_present))
mnl_attr_put_u16
(nlh,
 vlan_present ?
 TCA_FLOWER_KEY_VLAN_ETH_TYPE :
 TCA_FLOWER_KEY_ETH_TYPE,
 RTE_BE16(ETH_P_IPV6));
-   }
eth_type_set = 1;
vlan_eth_type_set = 1;
if (mask.ipv6 == &flow_tcf_mask_empty.ipv6)
-- 
1.8.3.1

[dpdk-dev] [PATCH] dev: don't remove devargs that are still referenced

[Darek Stojaczyk]

Even if a device failed to plug, it's still a device
object that references the devargs. Those devargs will
be freed automatically together with the device, but
can't be freed any earlier.

Fixes: 7e8b26650146 ("eal: fix hotplug add / remove")
Cc: gaetan.ri...@6wind.com

Signed-off-by: Darek Stojaczyk 
---
 lib/librte_eal/common/eal_common_dev.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_dev.c 
b/lib/librte_eal/common/eal_common_dev.c
index 1fdc9ab17..b6fc5e437 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -169,11 +169,10 @@ local_dev_probe(const char *devargs, struct rte_device 
**new_dev)
 
ret = dev->bus->plug(dev);
if (ret) {
-   if (rte_dev_is_probed(dev)) /* if already succeeded earlier */
-   return ret; /* no rollback */
-   RTE_LOG(ERR, EAL, "Driver cannot attach the device (%s)\n",
-   dev->name);
-   goto err_devarg;
+   if (!rte_dev_is_probed(dev)) /* if hasn't succeeded earlier */
+   RTE_LOG(ERR, EAL, "Driver cannot attach the device 
(%s)\n",
+   dev->name);
+   return ret;
}
 
*new_dev = dev;
-- 
2.17.1

[dpdk-dev] [PATCH] vfio: don't needlessly setup devices in secondary process

[Darek Stojaczyk]

Setting up a device that wasn't setup in the primary
process will possibly break the primary process. That's
because the IPC message to retrieve the group fd in the
primary will also *open* that group if it wasn't opened
before. Even though the secondary process closes that fd
soon after as a part of its error handling path, the
primary process leaks it.

What's worse, opening that fd on the primary will
increment the process-local counter of opened groups.
If it was 0 before, then the group will never be added
to the vfio container, nor dpdk memory will be ever
mapped.

This patch moves the proper error checks earlier in the
code to fuly prevent setting up devices in secondary
processes that weren't setup in the primary process.

Fixes: 2f4adfad0a69 ("vfio: add multiprocess support")
Cc: anatoly.bura...@intel.com

Signed-off-by: Darek Stojaczyk 
---
 drivers/bus/pci/linux/pci_vfio.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/bus/pci/linux/pci_vfio.c b/drivers/bus/pci/linux/pci_vfio.c
index ffd26f195..54a4c959e 100644
--- a/drivers/bus/pci/linux/pci_vfio.c
+++ b/drivers/bus/pci/linux/pci_vfio.c
@@ -794,11 +794,6 @@ pci_vfio_map_resource_secondary(struct rte_pci_device *dev)
snprintf(pci_addr, sizeof(pci_addr), PCI_PRI_FMT,
loc->domain, loc->bus, loc->devid, loc->function);
 
-   ret = rte_vfio_setup_device(rte_pci_get_sysfs_path(), pci_addr,
-   &vfio_dev_fd, &device_info);
-   if (ret)
-   return ret;
-
/* if we're in a secondary process, just find our tailq entry */
TAILQ_FOREACH(vfio_res, vfio_res_list, next) {
if (rte_pci_addr_cmp(&vfio_res->pci_addr,
@@ -810,9 +805,14 @@ pci_vfio_map_resource_secondary(struct rte_pci_device *dev)
if (vfio_res == NULL) {
RTE_LOG(ERR, EAL, "  %s cannot find TAILQ entry for PCI 
device!\n",
pci_addr);
-   goto err_vfio_dev_fd;
+   return -1;
}
 
+   ret = rte_vfio_setup_device(rte_pci_get_sysfs_path(), pci_addr,
+   &vfio_dev_fd, &device_info);
+   if (ret)
+   return ret;
+
/* map BARs */
maps = vfio_res->maps;
 
-- 
2.17.1

Re: [dpdk-dev] [PATCH] dev: don't remove devargs that are still referenced

[Thomas Monjalon]

21/11/2018 19:37, Darek Stojaczyk:
> Even if a device failed to plug, it's still a device
> object that references the devargs. Those devargs will
> be freed automatically together with the device, but
> can't be freed any earlier.

Thanks for the patch.
Please, be more specific about the bug.
You could add 2 more paragraphs:
- One before, to explain the tested scenario and the result.
- One after, to explain how it is fixed (changing the goto by a return).

[...]
>   ret = dev->bus->plug(dev);
>   if (ret) {
> - if (rte_dev_is_probed(dev)) /* if already succeeded earlier */
> - return ret; /* no rollback */
> - RTE_LOG(ERR, EAL, "Driver cannot attach the device (%s)\n",
> - dev->name);
> - goto err_devarg;
> + if (!rte_dev_is_probed(dev)) /* if hasn't succeeded earlier */
> + RTE_LOG(ERR, EAL, "Driver cannot attach the device 
> (%s)\n",
> + dev->name);
> + return ret;
>   }

[dpdk-dev] [PATCH] dev: don't try to rollback a device attach that failed

[Darek Stojaczyk]

If a device fails to attach before it's plugged,
the subsequent rollback will still try to detach it,
causing a segfault. Unplugging a device that wasn't
plugged isn't really supported, so this patch adds
an extra error check to prevent that from happening.

While here, fix this also for normal (non-rollback)
detach, which could also theoretically segfault on
non-plugged device.

Fixes: 244d5130719c ("eal: enable hotplug on multi-process")
Cc: qi.z.zh...@intel.com

Signed-off-by: Darek Stojaczyk 
---
 lib/librte_eal/common/hotplug_mp.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/lib/librte_eal/common/hotplug_mp.c 
b/lib/librte_eal/common/hotplug_mp.c
index 7c9fcc46c..d9e6790da 100644
--- a/lib/librte_eal/common/hotplug_mp.c
+++ b/lib/librte_eal/common/hotplug_mp.c
@@ -264,6 +264,19 @@ static void __handle_primary_request(void *param)
goto quit;
}
 
+   if (!rte_dev_is_probed(dev)) {
+   if (req->t == EAL_DEV_REQ_TYPE_ATTACH_ROLLBACK) {
+   /**
+* Don't fail the rollback just because there's
+* nothing to do.
+*/
+   ret = 0;
+   } else
+   ret = -ENODEV;
+
+   goto quit;
+   }
+
ret = local_dev_remove(dev);
 quit:
free(da->args);
-- 
2.17.1

[dpdk-dev] [PATCH v2] dev: don't remove devargs that are still referenced

[Darek Stojaczyk]

Even if a device failed to plug, it's still a device
object that references the devargs. Those devargs will
be freed automatically together with the device, but
freeing them any earlier - like it's done in the hotplug
error handling path right now - will give us a dangling
pointer and a segfault scenario.

Consider the following case:
 * secondary process receives the hotplug request IPC message
   * devargs are either created or updated
   * the bus is scanned
 * a new device object is created with the latest devargs
   * the device can't be plugged for whatever reason,
 bus->plug returns error
 * the devargs are freed, even though they're still referenced
   by the device object on the bus

For PCI devices, the generic device name comes from
a buffer within the devargs. Freeing those will make
EAL segfault whenever the device name is checked.

This patch just prevents the hotplug error handling
path from removing the devargs when there's a device
that references them. This is done by simply exiting
early from the hotplug function. As mentioned in the
beginning, those devargs will be freed later, together
with the device itself.

Fixes: 7e8b26650146 ("eal: fix hotplug add / remove")
Cc: gaetan.ri...@6wind.com
Cc: tho...@monjalon.net

Signed-off-by: Darek Stojaczyk 
---
 lib/librte_eal/common/eal_common_dev.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_dev.c 
b/lib/librte_eal/common/eal_common_dev.c
index 1fdc9ab17..b6fc5e437 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -169,11 +169,10 @@ local_dev_probe(const char *devargs, struct rte_device 
**new_dev)
 
ret = dev->bus->plug(dev);
if (ret) {
-   if (rte_dev_is_probed(dev)) /* if already succeeded earlier */
-   return ret; /* no rollback */
-   RTE_LOG(ERR, EAL, "Driver cannot attach the device (%s)\n",
-   dev->name);
-   goto err_devarg;
+   if (!rte_dev_is_probed(dev)) /* if hasn't succeeded earlier */
+   RTE_LOG(ERR, EAL, "Driver cannot attach the device 
(%s)\n",
+   dev->name);
+   return ret;
}
 
*new_dev = dev;
-- 
2.17.1

Re: [dpdk-dev] [PATCH v1 0/2] change max core number to 256 for Arm64 platform

[Stephen Hemminger]

On Wed, 21 Nov 2018 11:41:36 +
"Joyce Kong (Arm Technology China)"  wrote:

> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.


Please fix your mail system. Because technically sending mail to a mailing list 
with this footer means everyone on the list should delete the mail.

Re: [dpdk-dev] mlx5 under FreeBSD

[Stephen Hemminger]

On Wed, 21 Nov 2018 11:11:51 -0600 (CST)
Mit Matelske  wrote:

> > 
> > Rather than building a complex shim, why not just have an OS dependent 
> > section
> > of the driver.  The bigger issue is that the kernel side functionality in 
> > BSD
> > is different or missing.  For example TAP API is different and not 
> > multi-queue.  
> 
> Once I started working on it, I had to go this route.  I haven't been able to 
> but much 
> time into it yet, but it is coming along:
> 
> EAL: PCI device :b3:00.0 on NUMA socket 0
> EAL:   probe driver: 15b3:1013 net_mlx5
> net_mlx5: mlx5.c:1315: mlx5_pci_probe(): checking device "mlx5_0" uverbs0 
> /sys/class/infiniband_verbs/uverbs0 /sys/class/infiniband/mlx5_0
> net_mlx5: mlx5.c:1325: mlx5_pci_probe(): PCI information matches for device 
> "mlx5_0"
> net_mlx5: mlx5.c:1315: mlx5_pci_probe(): checking device "mlx5_1" uverbs1 
> /sys/class/infiniband_verbs/uverbs1 /sys/class/infiniband/mlx5_1
> net_mlx5: mlx5.c:1382: mlx5_pci_probe(): no switch support detected
> net_mlx5: mlx5.c:796: mlx5_dev_spawn(): MPW isn't supported
> net_mlx5: mlx5.c:852: mlx5_dev_spawn(): tunnel offloading disabled due to old 
> OFED/rdma-core version
> net_mlx5: mlx5.c:864: mlx5_dev_spawn(): MPLS over GRE/UDP tunnel offloading 
> disabled due to old OFED/rdma-core version or firmware configuration
> net_mlx5: mlx5.c:877: mlx5_dev_spawn(): naming Ethernet device ":b3:00.0"
> net_mlx5: mlx5.c:1007: mlx5_dev_spawn(): checksum offloading is supported
> net_mlx5: mlx5.c:1024: mlx5_dev_spawn(): maximum Rx indirection table size is 
> 512
> net_mlx5: mlx5.c:1028: mlx5_dev_spawn(): VLAN stripping is not supported
> net_mlx5: mlx5.c:1032: mlx5_dev_spawn(): FCS stripping configuration is not 
> supported
> net_mlx5: mlx5.c:1037: mlx5_dev_spawn(): hardware Rx end alignment padding is 
> not supported
> net_mlx5: mlx5.c:1052: mlx5_dev_spawn(): MPS is disabled
> net_mlx5: mlx5.c:628: mlx5_uar_init_primary(): port 0 reserved UAR address 
> space: 0x88000
> net_mlx5: mlx5.c:1107: mlx5_dev_spawn(): port 0 MAC address is 
> 00:90:0b:78:2a:ea
> net_mlx5: mlx5.c:1114: mlx5_dev_spawn(): port 0 ifname is "mce0"
> net_mlx5: mlx5.c:1127: mlx5_dev_spawn(): port 0 MTU is 1500
> net_mlx5: mlx5.c:1142: mlx5_dev_spawn(): flow rules relying on switch 
> offloads will not be supported: cannot open libmnl socket: Address family not 
> supported by protocol family
> net_mlx5: mlx5.c:1176: mlx5_dev_spawn(): port 0 forcing Ethernet interface up
> net_mlx5: mlx5_ethdev.c:735: mlx5_link_update_unlocked_gs(): port 0 
> ioctl(SIOCGIFFLAGS) failed: No such file or directory
> net_mlx5: mlx5_ethdev.c:664: mlx5_link_update_unlocked_gset(): port 0 
> ioctl(SIOCGIFFLAGS) failed: No such file or directory
> net_mlx5: mlx5_rxq.c:2150: mlx5_hrxq_drop_new(): port 0 cannot allocate QP 
> for drop queue
> Segmentation fault (core dumped)
> 
> Working through mlx5_ethdev now...
> 
> Mit

Also if you are targeting Azure or Hyper-V, then don't bother porting 
TAP/VDEV_NETVSC/Failsafe model
because that is being replaced by netvsc native PMD.  It would be easier to 
just get that working.
It would mean writing a  uio equivalent driver for FreeBSD.

Re: [dpdk-dev] [PATCH v4 4/9] app/procinfo: add support for show port

[Stephen Hemminger]

On Tue,  6 Nov 2018 18:19:07 +0530
Vipin Varghese  wrote:

Minor observations which are things that checkpatch etc won't see
but make the code easier to read/maintain.
 
> +/* border variable to hold for show */
> +char bdr_str[MAX_STRING_LEN];

Does this have to be global, could it just be static?

> + memset(&link, 0, sizeof(link));
> + memset(&dev_info, 0, sizeof(dev_info));
> + memset(&queue_info, 0, sizeof(queue_info));
> + memset(&stats, 0, sizeof(stats));
> + memset(&rss_conf, 0, sizeof(rss_conf));

These memset's should be unnecessary. For example, dev_info
is always cleared already inside rte_eth_dev_info_get().

> + if ((ret) || (rss_conf.rss_key == NULL))
> + continue;

Unnecessary parenthesis hurt readability in this if statement.

[dpdk-dev] [PATCH 1/2] net/qede: fix Tx offload mask

[Mody, Rasesh]

From: Shahed Shaikh 

Following commit updated the Tx offload mask
commit 1037ed842c37 ("mbuf: fix Tx offload mask").

So, not having PKT_TX_IPV6 and PKT_TX_IPV4 in qede PMDs supported
Tx offload mask breaks TSO support since application will fail in transmit
prepare function.

Fixes: 1037ed842c37 ("mbuf: fix Tx offload mask")
Cc: sta...@dpdk.org

Signed-off-by: Shahed Shaikh 
---
 drivers/net/qede/qede_rxtx.h |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/qede/qede_rxtx.h b/drivers/net/qede/qede_rxtx.h
index 0afadd8..454daa0 100644
--- a/drivers/net/qede/qede_rxtx.h
+++ b/drivers/net/qede/qede_rxtx.h
@@ -149,7 +149,9 @@
   PKT_TX_TCP_CKSUM | \
   PKT_TX_UDP_CKSUM | \
   PKT_TX_OUTER_IP_CKSUM| \
-  PKT_TX_TCP_SEG)
+  PKT_TX_TCP_SEG   | \
+  PKT_TX_IPV4  | \
+  PKT_TX_IPV6)
 
 #define QEDE_TX_OFFLOAD_MASK (QEDE_TX_CSUM_OFFLOAD_MASK | \
  PKT_TX_VLAN_PKT   | \
-- 
1.7.10.3

[dpdk-dev] [PATCH 2/2] doc: update QEDE PMD firmware version

[Mody, Rasesh]

Update QEDE PMD firmware version to 8.37.7.0

Signed-off-by: Rasesh Mody 
---
 doc/guides/nics/qede.rst |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
index cba3886..c0a3833 100644
--- a/doc/guides/nics/qede.rst
+++ b/doc/guides/nics/qede.rst
@@ -58,9 +58,9 @@ Supported QLogic Adapters
 Prerequisites
 -
 
-- Requires storm firmware version **8.33.12.0**. Firmware may be available
+- Requires storm firmware version **8.37.7.0**. Firmware may be available
   inbox in certain newer Linux distros under the standard directory
-  ``E.g. /lib/firmware/qed/qed_init_values-8.33.12.0.bin``.
+  ``E.g. /lib/firmware/qed/qed_init_values-8.37.7.0.bin``.
   If the required firmware files are not available then download it from
   `linux-firmware git repository 
`_
   or `QLogic Driver Download Center 
`_.
@@ -106,7 +106,7 @@ enabling debugging options may affect system performance.
 - ``CONFIG_RTE_LIBRTE_QEDE_FW`` (default **""**)
 
   Gives absolute path of firmware file.
-  ``Eg: "/lib/firmware/qed/qed_init_values-8.33.12.0.bin"``
+  ``Eg: "/lib/firmware/qed/qed_init_values-8.37.7.0.bin"``
   Empty string indicates driver will pick up the firmware file
   from the default location /lib/firmware/qed.
   CAUTION this option is more for custom firmware, it is not
-- 
1.7.10.3

Re: [dpdk-dev] [PATCH] app/testpmd: improve MAC swap performance

[Zhang, Qi Z]

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Tuesday, November 20, 2018 2:54 PM
> To: Zhang, Qi Z ; Richardson, Bruce
> ; Wiles, Keith 
> Cc: dev@dpdk.org; Lu, Wenzhuo ; Iremonger, Bernard
> ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] app/testpmd: improve MAC swap performance
> 
> 
> 
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Tuesday, November 20, 2018 5:26 PM
> > To: Zhang, Qi Z ; Richardson, Bruce
> > ; Wiles, Keith 
> > Cc: dev@dpdk.org; Lu, Wenzhuo ; Iremonger,
> > Bernard ; sta...@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH] app/testpmd: improve MAC swap
> > performance
> >
> >
> >
> > > -Original Message-
> > > From: Zhang, Qi Z
> > > Sent: Tuesday, November 20, 2018 4:58 PM
> > > To: Ananyev, Konstantin ; Richardson,
> > > Bruce ; Wiles, Keith
> > > 
> > > Cc: dev@dpdk.org; Lu, Wenzhuo ; Iremonger,
> > > Bernard ; sta...@dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH] app/testpmd: improve MAC swap
> > > performance
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Ananyev, Konstantin
> > > > Sent: Tuesday, November 20, 2018 1:17 AM
> > > > To: Zhang, Qi Z ; Richardson, Bruce
> > > > ; Wiles, Keith 
> > > > Cc: dev@dpdk.org; Lu, Wenzhuo ; Iremonger,
> > > > Bernard ; Zhang, Qi Z
> > > > ; sta...@dpdk.org
> > > > Subject: RE: [dpdk-dev] [PATCH] app/testpmd: improve MAC swap
> > > > performance
> > > >
> > > > Hi Qi,
> > > >
> > > > > -Original Message-
> > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
> > > > > Sent: Tuesday, November 20, 2018 4:46 AM
> > > > > To: Richardson, Bruce ; Wiles, Keith
> > > > > 
> > > > > Cc: dev@dpdk.org; Lu, Wenzhuo ; Iremonger,
> > > > > Bernard ; Zhang, Qi Z
> > > > > ; sta...@dpdk.org
> > > > > Subject: [dpdk-dev] [PATCH] app/testpmd: improve MAC swap
> > > > > performance
> > > > >
> > > > > The patch optimizes the mac swap operation by taking advantage
> > > > > of SSE instructions, it only impacts x86 platform.
> > > > >
> > > > > Cc: sta...@dpdk.org
> > > > >
> > > > > Signed-off-by: Qi Zhang 
> > > > > ---
> > > > >  app/test-pmd/macswap.c | 16 +++-
> > > > >  1 file changed, 15 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/app/test-pmd/macswap.c b/app/test-pmd/macswap.c
> > > > > index
> > > > > a8384d5b8..0722782b0 100644
> > > > > --- a/app/test-pmd/macswap.c
> > > > > +++ b/app/test-pmd/macswap.c
> > > > > @@ -78,7 +78,6 @@ pkt_burst_mac_swap(struct fwd_stream *fs)
> > > > >   struct rte_port  *txp;
> > > > >   struct rte_mbuf  *mb;
> > > > >   struct ether_hdr *eth_hdr;
> > > > > - struct ether_addr addr;
> > > > >   uint16_t nb_rx;
> > > > >   uint16_t nb_tx;
> > > > >   uint16_t i;
> > > > > @@ -95,6 +94,15 @@ pkt_burst_mac_swap(struct fwd_stream *fs)
> > > > >   start_tsc = rte_rdtsc();
> > > > >  #endif
> > > > >
> > > > > +#ifdef RTE_ARCH_X86
> > > > > + __m128i addr;
> > > > > + __m128i shfl_msk = _mm_set_epi8(15, 14, 13, 12,
> > > > > + 5, 4, 3, 2,
> > > > > + 1, 0, 11, 10,
> > > > > + 9, 8, 7, 6);
> > > > > +#else
> > > > > + struct ether_addr addr;
> > > > > +#endif
> > > >
> > > > I think it would better to place IA specific code into a separate
> > > > fnction (and probably into a separate .h file).
> > >
> > > OK, I will think about how to rework this.
> >
> > Ideally would be good to have an generic one, and IA optimized version.
> >
> > >
> > > > BTW, just curious what % of improvement it gives?
> > >
> > > So far , the only server I can test is a 1.6GHz Broadwell server with 2 
> > > ports on
> 1 i40e 25G.
> > > The macswap performance is increase from 16.8mpps to 20mpps (about
> > > 19% improvement)

I need to add a notice here, I found previous test is running on CPU from 
remote socket.
For the test on CPU from local socket on the same server, actually the mac swap 
performance is improved from 23.34 to 26.36, its about 12.9% increase, but 
still considerable.

> >
> > Quite a lot, definitely looks like worth it.
> 
> You probably can squeeze few more cycles doing it in bulks of 4 or so.

it's a good idea, based on my experience I can get more than 4% increase by 
batch with 4, 
it can reach 27.46mpps, so now its 17.7% increase, I will send patch later, 
please help to polish:)

Thanks
Qi

> Konstantin

Re: [dpdk-dev] Question about telemetry on 18.11 release

[Rami Rosen]

Hi Hideyuki,

Regarding your questions about DPDK CPU usage, etc:
I believe that due to the way PMDs are implemented, maybe one
should consider using DPDK RTE jobstats API for collecting stats for a DPDK
app. This API reflects better the actual DPDK app stats.
See an example in:
https://doc.dpdk.org/guides/sample_app_ug/l2_forward_job_stats.html
And also see:
https://doc.dpdk.org/api/rte__jobstats_8h_source.html

Regards,
Rami Rosen

בתאריך יום ד׳, 21 בנוב׳ 2018, 09:50, מאת Hideyuki Yamashita <
yamashita.hidey...@po.ntt-tx.co.jp>:

> Hello,
>
> I have some basic questions about telemetry API
> which is planned to be relaesed in 18.11.
>
> Note that I have read the follwoing document.
> https://doc.dpdk.org/guides/howto/telemetry.html
>
> Q1. In general dpdk application use polling when
> receiving packets. So CPU usage is always looks 100%
> when measured using e.g. vmstat even if there is no packet receiving.
> (CPU is busy for polling packets)
> Is that correct?
>
> Q2. Is it correct understanding that dpdk application
> can send "any" value(or metric) to client if client
> requested via "telemetry" framework?
>
> Q3.Is it possible to query "real cpu usage" from dpdk
> application using "telemetry" framework?
> ("real cpu usage" I mean if 0 pakcket incoming,
> cpu usage indicates almost 0 %)
>
> Q4. Is it possible to inform client about fault or some
> trouble from dpdk application?
>
> Background  I ask above is that
> - I am relative new to DPDK world and have almost no knowledge about
> "telemetry"
> - I am interested in how dpdk applications can "scales" on platform
> like OpenStack. I think some mesurement mechanism required
> and I thought it might be "telemetry" APIs.
>
> Thanks in advance.
>
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
>
>
>

[dpdk-dev] [PATCH] doc: hash library programmer guide improvement

[Yipeng Wang]

This commit improves the programmer guide of the hash
library to be more accurate on new features introduced
in 18.11.

Signed-off-by: Yipeng Wang 
Signed-off-by: Sameh Gobriel 
---
 doc/guides/prog_guide/hash_lib.rst | 145 ++---
 1 file changed, 85 insertions(+), 60 deletions(-)

diff --git a/doc/guides/prog_guide/hash_lib.rst 
b/doc/guides/prog_guide/hash_lib.rst
index f5beec1..85a6edf 100644
--- a/doc/guides/prog_guide/hash_lib.rst
+++ b/doc/guides/prog_guide/hash_lib.rst
@@ -14,55 +14,55 @@ For increased performance the DPDK Hash requires that all 
the keys have the same
 Hash API Overview
 -
 
-The main configuration parameters for the hash are:
+The main configuration parameters for the hash table are:
 
-*   Total number of hash entries
+*   Total number of hash entries in the table
 
 *   Size of the key in bytes
 
-*   An extra flag used to describe additional settings, for example the 
multithreading mode of operation (as will be described later)
+*   An extra flag to describe additional settings, for example the 
multithreading mode of operation and extendable bucket functionality (as will 
be described later)
 
-The hash also allows the configuration of some low-level implementation 
related parameters such as:
+The hash table also allows the configuration of some low-level implementation 
related parameters such as:
 
-*   Hash function to translate the key into a bucket index
+*   Hash function to translate the key into a hash value
 
-The main methods exported by the hash are:
+The main methods exported by the Hash Library are:
 
-*   Add entry with key: The key is provided as input. If a new entry is 
successfully added to the hash for the specified key,
-or there is already an entry in the hash for the specified key, then the 
position of the entry is returned.
-If the operation was not successful, for example due to lack of free 
entries in the hash, then a negative value is returned;
+*   Add entry with key: The key is provided as input. If the new entry is 
successfully added to the hash table for the specified key,
+or there is already an entry in the hash table for the specified key, then 
the position of the entry is returned.
+If the operation was not successful, for example due to lack of free 
entries in the hash table, then a negative value is returned.
 
 *   Delete entry with key: The key is provided as input. If an entry with the 
specified key is found in the hash,
-then the entry is removed from the hash and the position where the entry 
was found in the hash is returned.
-If no entry with the specified key exists in the hash, then a negative 
value is returned
+then the entry is removed from the hash table and the position where the 
entry was found in the hash table is returned.
+If no entry with the specified key exists in the hash table, then a 
negative value is returned
 
-*   Lookup for entry with key: The key is provided as input. If an entry with 
the specified key is found in the hash (lookup hit),
-then the position of the entry is returned, otherwise (lookup miss) a 
negative value is returned.
+*   Lookup for entry with key: The key is provided as input. If an entry with 
the specified key is found in the hash table (i.e., lookup hit),
+then the position of the entry is returned, otherwise (i.e., lookup miss) 
a negative value is returned.
 
-Apart from these methods explained above, the API provides the user with few 
more options:
+Apart from the basic methods explained above, the Hash Library API provides a 
few more advanced methods to query and update the hash table:
 
-*   Add / lookup / delete with key and precomputed hash: Both the key and its 
precomputed hash are provided as input. This allows
-the user to perform these operations faster, as hash is already computed.
+*   Add / lookup / delete entry with key and precomputed hash: Both the key 
and its precomputed hash are provided as input. This allows
+the user to perform these operations faster, as the hash value is already 
computed.
 
-*   Add / lookup with key and data: A pair of key-value is provided as input. 
This allows the user to store
-not only the key, but also data which may be either a 8-byte integer or a 
pointer to external data (if data size is more than 8 bytes).
+*   Add / lookup entry with key and data: A data is provided as input for add. 
Add allows the user to store
+not only the key, but also the data which may be either a 8-byte integer 
or a pointer to external data (if data size is more than 8 bytes).
 
-*   Combination of the two options above: User can provide key, precomputed 
hash and data.
+*   Combination of the two options above: User can provide key, precomputed 
hash, and data.
 
-*   Ability to not free the position of the entry in the hash upon calling 
delete. This is useful for multi-threaded scenarios where
+*   Ability to not free the position of the entry i

Re: [dpdk-dev] [PATCH] ethdev: fix memory leak on removing eth rxtx callback

[万乐冰]

cc konstantin.ananyev

konstantin.ananyev, please help.

Ferruh Yigit  于2018年11月21日周三 下午10:48写道：

> On 11/21/2018 1:11 PM, wanlebing wrote:
> > eth rxtx callback is dynamically allocated using rte_zmalloc()
> > but not released. Fix it by calling rte_free() to free callback
> > when removing rxtx callback.
>
> I guess they are not freed intentionally because there is no safe way to
> do it.
> I remember Konstantin sent an RFC in the past to rework the callbacks,
> cc'ed him
> for more details.
>
> >
> > Signed-off-by: wanlebing 
> > Signed-off-by: wanlebing 
> > ---
> >  lib/librte_ethdev/rte_ethdev.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_ethdev.c
> b/lib/librte_ethdev/rte_ethdev.c
> > index 5f858174b..f00311047 100644
> > --- a/lib/librte_ethdev/rte_ethdev.c
> > +++ b/lib/librte_ethdev/rte_ethdev.c
> > @@ -3926,6 +3926,7 @@ rte_eth_remove_rx_callback(uint16_t port_id,
> uint16_t queue_id,
> >   if (cb == user_cb) {
> >   /* Remove the user cb from the callback list. */
> >   *prev_cb = cb->next;
> > + rte_free(cb);
> >   ret = 0;
> >   break;
> >   }
> > @@ -3960,6 +3961,7 @@ rte_eth_remove_tx_callback(uint16_t port_id,
> uint16_t queue_id,
> >   if (cb == user_cb) {
> >   /* Remove the user cb from the callback list. */
> >   *prev_cb = cb->next;
> > + rte_free(cb);
> >   ret = 0;
> >   break;
> >   }
> >
>
>

[dpdk-dev] [PATCH] hash: fix out-of-bound write while freeing key slot

[Honnappa Nagarahalli]

Add a debug check for out-of-bound write while freeing the key slot.

Coverity issue: 325733
Fixes: e605a1d36ca7 ("hash: add lock-free r/w concurrency")
Cc: honnappa.nagaraha...@arm.com

Signed-off-by: Honnappa Nagarahalli 
Reviewed-by: Steve Capper 
Reviewed-by: Gavin Hu 
---
 lib/librte_hash/rte_cuckoo_hash.c |  4 
 lib/librte_hash/rte_cuckoo_hash.h | 11 +++
 2 files changed, 15 insertions(+)

diff --git a/lib/librte_hash/rte_cuckoo_hash.c 
b/lib/librte_hash/rte_cuckoo_hash.c
index 5ddcccd87..c35a60266 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -1272,6 +1272,9 @@ remove_entry(const struct rte_hash *h, struct 
rte_hash_bucket *bkt, unsigned i)
n_slots = rte_ring_mp_enqueue_burst(h->free_slots,
cached_free_slots->objs,
LCORE_CACHE_SIZE, NULL);
+   ERR_IF_TRUE((n_slots == 0),
+   "%s: could not enqueue free slots in global 
ring\n",
+   __func__);
cached_free_slots->len -= n_slots;
}
/* Put index of new free slot in cache. */
@@ -1477,6 +1480,7 @@ rte_hash_free_key_with_position(const struct rte_hash *h,
n_slots = rte_ring_mp_enqueue_burst(h->free_slots,
cached_free_slots->objs,
LCORE_CACHE_SIZE, NULL);
+   RETURN_IF_TRUE((n_slots == 0), -EFAULT);
cached_free_slots->len -= n_slots;
}
/* Put index of new free slot in cache. */
diff --git a/lib/librte_hash/rte_cuckoo_hash.h 
b/lib/librte_hash/rte_cuckoo_hash.h
index 5dfbbc48b..eacdaa8d4 100644
--- a/lib/librte_hash/rte_cuckoo_hash.h
+++ b/lib/librte_hash/rte_cuckoo_hash.h
@@ -29,6 +29,17 @@
 #define RETURN_IF_TRUE(cond, retval)
 #endif
 
+#if defined(RTE_LIBRTE_HASH_DEBUG)
+#define ERR_IF_TRUE(cond, fmt, args...) do { \
+   if (cond) { \
+   RTE_LOG(ERR, HASH, fmt, ##args); \
+   return; \
+   } \
+} while (0)
+#else
+#define ERR_IF_TRUE(cond, fmt, args...)
+#endif
+
 #include 
 #include 
 
-- 
2.17.1

[dpdk-dev] [PATCH] doc: update commands for pdump

[Tiwei Bie]

The --server-socket-path and --client-socket-path options
have already been removed. So also remove them from the doc
to avoid confusion.

Fixes: 09f4aa2b955f ("app/pdump: remove unused socket path options")
Cc: sta...@dpdk.org

Signed-off-by: Tiwei Bie 
---
 doc/guides/tools/pdump.rst | 10 --
 1 file changed, 10 deletions(-)

diff --git a/doc/guides/tools/pdump.rst b/doc/guides/tools/pdump.rst
index 5168c81ab..7c2b73e72 100644
--- a/doc/guides/tools/pdump.rst
+++ b/doc/guides/tools/pdump.rst
@@ -42,8 +42,6 @@ The tool has a number of command line options:
[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.
@@ -56,14 +54,6 @@ below section.
 
   * Multiple instances of ``--pdump`` can be passed to capture packets on 
different port and queue combinations.
 
-The ``--server-socket-path`` command line option is optional. This represents 
the server socket directory.
-If no value is passed default values are used i.e. ``/var/run/.dpdk/`` for 
root users and ``~/.dpdk/``
-for non root users.
-
-The ``--client-socket-path`` command line option is optional. This represents 
the client socket directory.
-If no value is passed default values are used i.e. ``/var/run/.dpdk/`` for 
root users and ``~/.dpdk/``
-for non root users.
-
 
 The ``--pdump`` parameters
 ~~
-- 
2.14.5

[dpdk-dev] [RFC] pdump: remove deprecated APIs

[Tiwei Bie]

We already changed to use generic IPC in pdump since below commit:

commit 660098d61f57 ("pdump: use generic multi-process channel")

The `rte_pdump_set_socket_dir()`, the `path` parameter of
`rte_pdump_init()` and the `enum rte_pdump_socktype` have been
deprecated since then. This commit removes these deprecated
APIs and also bumps the pdump ABI.

Signed-off-by: Tiwei Bie 
---
This patch is marked as RFC because the API and ABI changes should
also be documented by this patch in the `release_19_02.rst` which
doesn't exist currently. I will send a new version once we have it.

 app/test-pmd/testpmd.c |  2 +-
 doc/guides/prog_guide/pdump_lib.rst| 14 ++
 doc/guides/rel_notes/deprecation.rst   |  7 ---
 lib/librte_pdump/Makefile  |  2 +-
 lib/librte_pdump/meson.build   |  2 +-
 lib/librte_pdump/rte_pdump.c   |  9 +
 lib/librte_pdump/rte_pdump.h   | 34 +-
 lib/librte_pdump/rte_pdump_version.map |  1 -
 8 files changed, 7 insertions(+), 64 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 4c75587d0..a10bc40bb 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3104,7 +3104,7 @@ main(int argc, char** argv)
 
 #ifdef RTE_LIBRTE_PDUMP
/* initialize packet capture framework */
-   rte_pdump_init(NULL);
+   rte_pdump_init();
 #endif
 
count = 0;
diff --git a/doc/guides/prog_guide/pdump_lib.rst 
b/doc/guides/prog_guide/pdump_lib.rst
index ed3c15e58..afb5b3411 100644
--- a/doc/guides/prog_guide/pdump_lib.rst
+++ b/doc/guides/prog_guide/pdump_lib.rst
@@ -34,10 +34,6 @@ or disable the packet capture, and to uninitialize it:
 * ``rte_pdump_uninit()``:
   This API uninitializes the packet capture framework.
 
-* ``rte_pdump_set_socket_dir()``:
-  This API sets the server and client socket paths.
-  Note: This API is not thread-safe.
-
 
 Operation
 -
@@ -60,8 +56,8 @@ enabling or disabling the packet capture.
 Implementation Details
 --
 
-The library API ``rte_pdump_init()``, initializes the packet capture framework 
by creating the pthread and the server
-socket. The server socket in the pthread context will be listening to the 
client requests to enable or disable the
+The library API ``rte_pdump_init()``, initializes the packet capture framework 
by creating the pdump server by calling
+``rte_mp_action_register()`` function. The server will listen to the client 
requests to enable or disable the
 packet capture.
 
 The library APIs ``rte_pdump_enable()`` and ``rte_pdump_enable_by_deviceid()`` 
enables the packet capture.
@@ -82,12 +78,6 @@ received from the server, the client socket is closed.
 The library API ``rte_pdump_uninit()``, uninitializes the packet capture 
framework by closing the pthread and the
 server socket.
 
-The library API ``rte_pdump_set_socket_dir()``, sets the given path as either 
server socket path
-or client socket path based on the ``type`` argument of the API.
-If the given path is ``NULL``, default path will be selected, i.e. either 
``/var/run/.dpdk`` for root user or ``~/.dpdk``
-for non root user. Clients also need to call this API to set their server 
socket path if the server socket
-path is different from default path.
-
 
 Use Case: Packet Capturing
 --
diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 34b28234c..586bf98c5 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -48,10 +48,3 @@ Deprecation Notices
   PMDs that implement the latter.
   Target release for removal of the legacy API will be defined once most
   PMDs have switched to rte_flow.
-
-* pdump: As we changed to use generic IPC, some changes in APIs and structure
-  are expected in subsequent release.
-
-  - ``rte_pdump_set_socket_dir`` will be removed;
-  - The parameter, ``path``, of ``rte_pdump_init`` will be removed;
-  - The enum ``rte_pdump_socktype`` will be removed.
diff --git a/lib/librte_pdump/Makefile b/lib/librte_pdump/Makefile
index b241151dc..89593689a 100644
--- a/lib/librte_pdump/Makefile
+++ b/lib/librte_pdump/Makefile
@@ -12,7 +12,7 @@ LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_ethdev
 
 EXPORT_MAP := rte_pdump_version.map
 
-LIBABIVER := 2
+LIBABIVER := 3
 
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_PDUMP) := rte_pdump.c
diff --git a/lib/librte_pdump/meson.build b/lib/librte_pdump/meson.build
index be80904b9..b4b4f26c5 100644
--- a/lib/librte_pdump/meson.build
+++ b/lib/librte_pdump/meson.build
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2017 Intel Corporation
 
-version = 2
+version = 3
 sources = files('rte_pdump.c')
 headers = files('rte_pdump.h')
 allow_experimental_apis = true
diff --git a/lib/librte_pdump/rte_pdump.c b/lib/librte_pdump/rte_pdump.c
index 6c3a88581..4f38ac58b 100644
--- a/lib/librte_pdump/rte_pdump.c
+++ 

[dpdk-dev] [RFC 1/3] log: add TQS log type

[Honnappa Nagarahalli]

Signed-off-by: Honnappa Nagarahalli 
Reviewed-by: Steve Capper 
Reviewed-by: Gavin Hu 
---
 lib/librte_eal/common/include/rte_log.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_eal/common/include/rte_log.h 
b/lib/librte_eal/common/include/rte_log.h
index 2f789cb90..b4e91a4a5 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -61,6 +61,7 @@ extern struct rte_logs rte_logs;
 #define RTE_LOGTYPE_EFD   18 /**< Log related to EFD. */
 #define RTE_LOGTYPE_EVENTDEV  19 /**< Log related to eventdev. */
 #define RTE_LOGTYPE_GSO   20 /**< Log related to GSO. */
+#define RTE_LOGTYPE_TQS   21 /**< Log related to Thread Quiescent State. */
 
 /* these log types can be used in an application */
 #define RTE_LOGTYPE_USER1 24 /**< User-defined log type 1. */
-- 
2.17.1

[dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library

[Honnappa Nagarahalli]

Lock-less data structures provide scalability and determinism.
They enable use cases where locking may not be allowed
(for ex: real-time applications).

In the following paras, the term 'memory' refers to memory allocated
by typical APIs like malloc or anything that is representative of
memory, for ex: an index of a free element array.

Since these data structures are lock less, the writers and readers
are accessing the data structures simultaneously. Hence, while removing
an element from a data structure, the writers cannot return the memory
to the allocator, without knowing that the readers are not
referencing that element/memory anymore. Hence, it is required to
separate the operation of removing an element into 2 steps:

Delete: in this step, the writer removes the element from the
data structure but does not return the associated memory to the allocator.
This will ensure that new readers will not get a reference to the removed
element. Removing the reference is an atomic operation.

Free: in this step, the writer returns the memory to the
memory allocator, only after knowing that all the readers have stopped
referencing the removed element.

This library helps the writer determine when it is safe to free the
memory.

This library makes use of Thread Quiescent State (TQS). TQS can be
defined as 'any point in the thread execution where the thread does
not hold a reference to shared memory'. It is upto the application to
determine its quiescent state. Let us consider the following diagram:

Time -->

| |
  RT1   $D1+++***D2*|**+++|+++**D3*$
| |
  RT2  $D1++|+**D2|***++**D3*$
| |
  RT3  $D1+++***|D2***|++**D2*$
| |
|<--->|
   Del | Free
   |
  Cannot free memory
  during this period

RTx - Reader thread
< and > - Start and end of while(1) loop
***Dx*** - Reader thread is accessing the shared data structure Dx.
   i.e. critical section.
+++ - Reader thread is not accessing any shared data structure.
  i.e. non critical section or quiescent state.
Del - Point in time when the reference to the entry is removed using
  atomic operation.
Free - Point in time when the writer can free the entry.

As shown thread RT1 acesses data structures D1, D2 and D3. When it is
accessing D2, if the writer has to remove an element from D2, the
writer cannot return the memory associated with that element to the
allocator. The writer can return the memory to the allocator only after
the reader stops referencng D2. In other words, reader thread RT1
has to enter a quiescent state.

Similarly, since thread RT3 is also accessing D2, writer has to wait till
RT3 enters quiescent state as well.

However, the writer does not need to wait for RT2 to enter quiescent state.
Thread RT2 was not accessing D2 when the delete operation happened.
So, RT2 will not get a reference to the deleted entry.

It can be noted that, the critical sections for D2 and D3 are quiescent states
for D1. i.e. for a given data structure Dx, any point in the thread execution
that does not reference Dx is a quiescent state.

For DPDK applications, the start and end of while(1) loop (where no shared
data structures are getting accessed) act as perfect quiescent states. This
will combine all the shared data structure accesses into a single critical
section and keeps the over head introduced by this library to the minimum.

However, the length of the critical section and the number of reader threads
is proportional to the time taken to identify the end of critical section.
So, if the application desires, it should be possible to identify the end
of critical section for each data structure.

To provide the required flexibility, this library has a concept of TQS
variable. The application can create one or more TQS variables to help it
track the end of one or more critical sections.

The application can create a TQS variable using the API rte_tqs_alloc.
It takes a mask of lcore IDs that will report their quiescent states
using this variable. This mask can be empty to start with.

rte_tqs_register_lcore API will register a reader thread to report its
quiescent state. This can be called from any control plane thread or from
the reader thread. The application can create a TQS variable with no reader
threads and add the threads dynamically using this API.

The application can trigger the reader threads to report their quiescent
state status by calling the API rte_tqs_start. It is possible for multiple
writer threads to query the quiescent state status simultaneously. Hence,
rte_tqs_start returns a token to each caller.

The application has to 

[dpdk-dev] [RFC 2/3] tqs: add thread quiescent state library

[Honnappa Nagarahalli]

Add Thread Quiescent State (TQS) library. This library helps identify
the quiescent state of the reader threads so that the writers
can free the memory associated with the lock less data structures.

Signed-off-by: Honnappa Nagarahalli 
Reviewed-by: Steve Capper 
Reviewed-by: Gavin Hu 
---
 config/common_base |   6 +
 lib/Makefile   |   2 +
 lib/librte_tqs/Makefile|  23 ++
 lib/librte_tqs/meson.build |   5 +
 lib/librte_tqs/rte_tqs.c   | 249 
 lib/librte_tqs/rte_tqs.h   | 352 +
 lib/librte_tqs/rte_tqs_version.map |  16 ++
 lib/meson.build|   2 +-
 mk/rte.app.mk  |   1 +
 9 files changed, 655 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_tqs/Makefile
 create mode 100644 lib/librte_tqs/meson.build
 create mode 100644 lib/librte_tqs/rte_tqs.c
 create mode 100644 lib/librte_tqs/rte_tqs.h
 create mode 100644 lib/librte_tqs/rte_tqs_version.map

diff --git a/config/common_base b/config/common_base
index d12ae98bc..af40a9f81 100644
--- a/config/common_base
+++ b/config/common_base
@@ -792,6 +792,12 @@ CONFIG_RTE_LIBRTE_LATENCY_STATS=y
 #
 CONFIG_RTE_LIBRTE_TELEMETRY=n
 
+#
+# Compile librte_tqs
+#
+CONFIG_RTE_LIBRTE_TQS=y
+CONFIG_RTE_LIBRTE_TQS_DEBUG=n
+
 #
 # Compile librte_lpm
 #
diff --git a/lib/Makefile b/lib/Makefile
index b7370ef97..7095eac88 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -108,6 +108,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_BPF) += librte_bpf
 DEPDIRS-librte_bpf := librte_eal librte_mempool librte_mbuf librte_ethdev
 DIRS-$(CONFIG_RTE_LIBRTE_TELEMETRY) += librte_telemetry
 DEPDIRS-librte_telemetry := librte_eal librte_metrics librte_ethdev
+DIRS-$(CONFIG_RTE_LIBRTE_TQS) += librte_tqs
+DEPDIRS-librte_tqs := librte_eal
 
 ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
 DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
diff --git a/lib/librte_tqs/Makefile b/lib/librte_tqs/Makefile
new file mode 100644
index 0..059de53e2
--- /dev/null
+++ b/lib/librte_tqs/Makefile
@@ -0,0 +1,23 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2018 Arm Limited
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# library name
+LIB = librte_tqs.a
+
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
+LDLIBS += -lrte_eal
+
+EXPORT_MAP := rte_tqs_version.map
+
+LIBABIVER := 1
+
+# all source are stored in SRCS-y
+SRCS-$(CONFIG_RTE_LIBRTE_RING) := rte_tqs.c
+
+# install includes
+SYMLINK-$(CONFIG_RTE_LIBRTE_RING)-include := rte_tqs.h
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_tqs/meson.build b/lib/librte_tqs/meson.build
new file mode 100644
index 0..dd696ab07
--- /dev/null
+++ b/lib/librte_tqs/meson.build
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2018 Arm Limited
+
+sources = files('rte_tqs.c')
+headers = files('rte_tqs.h')
diff --git a/lib/librte_tqs/rte_tqs.c b/lib/librte_tqs/rte_tqs.c
new file mode 100644
index 0..cbc36864e
--- /dev/null
+++ b/lib/librte_tqs/rte_tqs.c
@@ -0,0 +1,249 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 2018 Arm Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rte_tqs.h"
+
+TAILQ_HEAD(rte_tqs_list, rte_tailq_entry);
+
+static struct rte_tailq_elem rte_tqs_tailq = {
+   .name = RTE_TAILQ_TQS_NAME,
+};
+EAL_REGISTER_TAILQ(rte_tqs_tailq)
+
+/* Allocate a new TQS variable with the name *name* in memory. */
+struct rte_tqs * __rte_experimental
+rte_tqs_alloc(const char *name, int socket_id, uint64_t lcore_mask)
+{
+   char tqs_name[RTE_TQS_NAMESIZE];
+   struct rte_tailq_entry *te, *tmp_te;
+   struct rte_tqs_list *tqs_list;
+   struct rte_tqs *v, *tmp_v;
+   int ret;
+
+   if (name == NULL) {
+   RTE_LOG(ERR, TQS, "Invalid input parameters\n");
+   rte_errno = -EINVAL;
+   return NULL;
+   }
+
+   te = rte_zmalloc("TQS_TAILQ_ENTRY", sizeof(*te), 0);
+   if (te == NULL) {
+   RTE_LOG(ERR, TQS, "Cannot reserve memory for tailq\n");
+   rte_errno = -ENOMEM;
+   return NULL;
+   }
+
+   snprintf(tqs_name, sizeof(tqs_name), "%s", name);
+   v = rte_zmalloc_socket(tqs_name, sizeof(struct rte_tqs),
+   RTE_CACHE_LINE_SIZE, socket_id);
+   if (v == NULL) {
+   RTE_LOG(ERR, TQS, "Cannot reserve memory for TQS variable\n");
+   rte_errno = -ENOMEM;
+   goto alloc_error;
+   }
+
+   ret = snprintf(v->name, sizeof(v->name), "%s", name);
+   if (ret < 0 || ret >= (int)sizeof(v->name)) {
+   rte_errno = -ENAMETOOLONG;
+   goto alloc_error;
+   }
+
+   te->data = (void *) v;
+   v->lcore_mask = lcore_mask;
+
+   rte_rwlock_write_lock(RTE_EAL_TAILQ_RWLOCK);
+
+   tqs_

[dpdk-dev] [RFC 3/3] test/tqs: Add API and functional tests

[Honnappa Nagarahalli]

From: Dharmik Thakkar 

Add API positive/negative test cases and functional tests.

Signed-off-by: Malvika Gupta 
Signed-off-by: Dharmik Thakkar 
Signed-off-by: Honnappa Nagarahalli 
Reviewed-by: Gavin Hu 
---
 test/test/Makefile |   2 +
 test/test/autotest_data.py |   6 +
 test/test/meson.build  |   5 +-
 test/test/test_tqs.c   | 540 +
 4 files changed, 552 insertions(+), 1 deletion(-)
 create mode 100644 test/test/test_tqs.c

diff --git a/test/test/Makefile b/test/test/Makefile
index ab4fec34a..7a07039e7 100644
--- a/test/test/Makefile
+++ b/test/test/Makefile
@@ -207,6 +207,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_KVARGS) += test_kvargs.c
 
 SRCS-$(CONFIG_RTE_LIBRTE_BPF) += test_bpf.c
 
+SRCS-$(CONFIG_RTE_LIBRTE_TQS) += test_tqs.c
+
 CFLAGS += -DALLOW_EXPERIMENTAL_API
 
 CFLAGS += -O3
diff --git a/test/test/autotest_data.py b/test/test/autotest_data.py
index 0fb7866db..e676757cd 100644
--- a/test/test/autotest_data.py
+++ b/test/test/autotest_data.py
@@ -676,6 +676,12 @@
 "Func":default_autotest,
 "Report":  None,
 },
+{
+"Name":"Thread Quiescent State autotest",
+"Command": "tqs_autotest",
+"Func":default_autotest,
+"Report":  None,
+},
 #
 # Please always make sure that ring_perf is the last test!
 #
diff --git a/test/test/meson.build b/test/test/meson.build
index 554e9945f..b80a449ad 100644
--- a/test/test/meson.build
+++ b/test/test/meson.build
@@ -100,6 +100,7 @@ test_sources = files('commands.c',
'test_timer.c',
'test_timer_perf.c',
'test_timer_racecond.c',
+   'tet_tqs.c',
'test_version.c',
'virtual_pmd.c'
 )
@@ -122,7 +123,8 @@ test_deps = ['acl',
'port',
'reorder',
'ring',
-   'timer'
+   'timer',
+   'tqs'
 ]
 
 test_names = [
@@ -228,6 +230,7 @@ test_names = [
'timer_autotest',
'timer_perf__autotest',
'timer_racecond_autotest',
+   'tqs_autotest',
'user_delay_us',
'version_autotest',
 ]
diff --git a/test/test/test_tqs.c b/test/test/test_tqs.c
new file mode 100644
index 0..8633a80a6
--- /dev/null
+++ b/test/test/test_tqs.c
@@ -0,0 +1,540 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (c) 2018 Arm Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+/* Check condition and return an error if true. */
+#define TQS_RETURN_IF_ERROR(tqs, cond, str, ...) do { \
+   if (cond) { \
+   printf("ERROR file %s, line %d: " str "\n", __FILE__, \
+   __LINE__, ##__VA_ARGS__); \
+   if (tqs) \
+   rte_tqs_free(tqs); \
+   return -1; \
+   } \
+} while (0)
+
+#define RTE_TQS_MAX_LCORE 64
+uint16_t enabled_core_ids[RTE_TQS_MAX_LCORE];
+uint64_t core_mask;
+uint32_t sw_token;
+uint16_t num_1qs = 1; /* Number of quiescent states = 1 */
+
+struct node {
+   int data;
+   struct node *next;
+};
+
+struct node *head = NULL, *lastNode;
+
+static inline int
+get_enabled_cores_mask(void)
+{
+   uint32_t i;
+   uint16_t core_id;
+   uint32_t max_cores = rte_lcore_count();
+
+   if (max_cores > RTE_TQS_MAX_LCORE) {
+   printf("Number of cores exceed %d\n", RTE_TQS_MAX_LCORE);
+   return -1;
+   }
+
+   core_id = 0;
+   core_mask = 0;
+   i = 0;
+   RTE_LCORE_FOREACH_SLAVE(core_id) {
+   enabled_core_ids[i] = core_id;
+   i++;
+   core_mask |= 1UL << core_id;
+   }
+
+   return 0;
+}
+
+/*
+ * rte_tqs_alloc: Allocate a TQS variable
+ */
+static int
+test_tqs_alloc(void)
+{
+   const char name32[] = "xyzxyzxyzxyzxyzxyzxyzxyzxyzx123";
+   const char name33[] = "xyzxyizxyzxyzxyzxyzxyzxyzxyzxyzxyz";
+   const char name3[] = "xyz";
+   struct rte_tqs *t;
+
+   printf("Test rte_tqs_alloc()\n");
+
+   t = rte_tqs_alloc(NULL, SOCKET_ID_ANY, core_mask);
+   TQS_RETURN_IF_ERROR(t, (t != NULL), "NULL TQS variable");
+
+   t = rte_tqs_alloc(name3, SOCKET_ID_ANY, core_mask);
+   TQS_RETURN_IF_ERROR(t, (t == NULL), "Variable name < %d",
+   RTE_TQS_NAMESIZE);
+   rte_tqs_free(t);
+
+   t = rte_tqs_alloc(name32, SOCKET_ID_ANY, core_mask);
+   TQS_RETURN_IF_ERROR(t, (t == NULL), "Variable name < %d",
+   RTE_TQS_NAMESIZE);
+   rte_tqs_free(t);
+
+   t = rte_tqs_alloc(name33, SOCKET_ID_ANY, core_mask);
+   TQS_RETURN_IF_ERROR(t, (t != NULL), "Variable name > %d",
+   RTE_TQS_NAMESIZE);
+
+   t = rte_tqs_alloc(name3, 0, core_mask);
+   TQS_RETURN_IF_ERROR(t, (t == NULL), "Valid socket ID");
+   rte_tqs_free(t);
+
+   t = rte_tqs_alloc(name3, 1, core_mask);
+   TQS_RETURN_IF_ERROR(t, (t != NULL), "Invalid socket ID");
+
+   t = rte_tqs_alloc(name3, SOCKET

[dpdk-dev] [PATCH v3] config: enable more than 128 cores for Arm64 platform

[Joyce Kong]

When running dpdk applications on cores whose ids are bigger
than original max_core setting, eal error as below:
EAL: Detected 104 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: invalid core list
-l CORELIST core indexes between 0 and 128

The fix is to increase max_core to 256 on Arm64 platform.

Fixes: b3ce00e5 ("mk: introduce ARMv8 architecture")
Cc: sta...@dpdk.org

Signed-off-by: Joyce Kong 
Reviewed-by: Gavin Hu 
---
 config/arm/meson.build | 5 +++--
 config/defconfig_arm64-armv8a-linuxapp-gcc | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index b755138..9b5f09c 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -46,13 +46,14 @@ flags_common_default = [
 
 flags_generic = [
['RTE_MACHINE', '"armv8a"'],
+['RTE_MAX_LCORE', 256],
['RTE_CACHE_LINE_SIZE', 128]]
 flags_cavium = [
['RTE_MACHINE', '"thunderx"'],
['RTE_CACHE_LINE_SIZE', 128],
['RTE_MAX_NUMA_NODES', 2],
-   ['RTE_MAX_LCORE', 96],
-   ['RTE_MAX_VFIO_GROUPS', 128],
+['RTE_MAX_LCORE', 256],
+['RTE_MAX_VFIO_GROUPS', 128],
['RTE_USE_C11_MEM_MODEL', false]]
 flags_dpaa = [
['RTE_MACHINE', '"dpaa"'],
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 1842744..a6ed90c 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -6,3 +6,4 @@
 
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y
+CONFIG_RTE_MAX_LCORE=256
-- 
2.7.4

Re: [dpdk-dev] [PATCH v2] config: enable more than 128 cores for Arm64 platform

[Joyce Kong (Arm Technology China)]

> -Original Message-
> From: Jerin Jacob 
> Sent: Wednesday, November 21, 2018 7:35 PM
> To: Joyce Kong (Arm Technology China) 
> Cc: dev@dpdk.org; tho...@monjalon.net; Honnappa Nagarahalli
> ; Gavin Hu (Arm Technology China)
> ; sta...@dpdk.org
> Subject: Re: [PATCH v2] config: enable more than 128 cores for Arm64
> platform
>
> -Original Message-
> > Date: Wed, 21 Nov 2018 19:27:12 +0800
> > From: Joyce Kong 
> > To: dev@dpdk.org
> > CC: tho...@monjalon.net, jerin.ja...@caviumnetworks.com,
> > honnappa.nagaraha...@arm.com, gavin...@arm.com, sta...@dpdk.org
> > Subject: [PATCH v2] config: enable more than 128 cores for Arm64
> > platform
> > X-Mailer: git-send-email 2.7.4
> >
> >
> > When running dpdk applications on cores whose ids are bigger than
> > original max_core setting, eal error as below:
> > EAL: Detected 104 lcore(s)
> > EAL: Detected 2 NUMA nodes
> > EAL: invalid core list
> > -l CORELIST core indexes between 0 and 128
> >
> > The fix is to increase max_core to 256 on Arm64 platform.
> >
> > Fixes: b3ce00e5 ("mk: introduce ARMv8 architecture")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Joyce Kong 
> > Reviewed-by: Gavin Hu 
> > ---
> >  config/arm/meson.build | 2 +-
> >  config/defconfig_arm64-armv8a-linuxapp-gcc | 1 +
> >  2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > b755138..020df09 100644
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > @@ -51,7 +51,7 @@ flags_cavium = [
> > ['RTE_MACHINE', '"thunderx"'],
> > ['RTE_CACHE_LINE_SIZE', 128],
> > ['RTE_MAX_NUMA_NODES', 2],
> > -   ['RTE_MAX_LCORE', 96],
> > +   ['RTE_MAX_LCORE', 256],
>
> This change makes thunderx config to 256 cores not armv8.
> For generic config, it needs to be under "flags_generic"
> not under "flags_cavium". Just like you did for updating defconfig_arm64-
> armv8a-linuxapp-gcc config instead of defconfig_arm64-thunderx-linuxapp-
> gcc
>

Config to 256 cores for both flags_generic and flags_cavium in V3.
For thunderx, it will do meson build according to flasg_cavium instead of 
flags_generic.
And there is no inheritance relationship between the two flags.

> > ['RTE_MAX_VFIO_GROUPS', 128],
> > ['RTE_USE_C11_MEM_MODEL', false]]  flags_dpaa = [ diff --git
> > a/config/defconfig_arm64-armv8a-linuxapp-gcc
> > b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > index 1842744..a6ed90c 100644
> > --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> > +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > @@ -6,3 +6,4 @@
> >
> >  CONFIG_RTE_TOOLCHAIN="gcc"
> >  CONFIG_RTE_TOOLCHAIN_GCC=y
> > +CONFIG_RTE_MAX_LCORE=256
> > --
> > 2.7.4
> >
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [dpdk-dev] [PATCH v3] config: enable more than 128 cores for Arm64 platform

[Jerin Jacob]

-Original Message-
> Date: Thu, 22 Nov 2018 15:01:14 +0800
> From: Joyce Kong 
> To: dev@dpdk.org
> CC: tho...@monjalon.net, jerin.ja...@caviumnetworks.com,
>  honnappa.nagaraha...@arm.com, gavin...@arm.com, sta...@dpdk.org
> Subject: [PATCH v3] config: enable more than 128 cores for Arm64 platform
> X-Mailer: git-send-email 2.7.4
> 
> 
> When running dpdk applications on cores whose ids are bigger
> than original max_core setting, eal error as below:
> EAL: Detected 104 lcore(s)
> EAL: Detected 2 NUMA nodes
> EAL: invalid core list
> -l CORELIST core indexes between 0 and 128
> 
> The fix is to increase max_core to 256 on Arm64 platform.
> 
> Fixes: b3ce00e5 ("mk: introduce ARMv8 architecture")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Joyce Kong 
> Reviewed-by: Gavin Hu 
> ---
>  config/arm/meson.build | 5 +++--
>  config/defconfig_arm64-armv8a-linuxapp-gcc | 1 +
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index b755138..9b5f09c 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -46,13 +46,14 @@ flags_common_default = [
> 
>  flags_generic = [
> ['RTE_MACHINE', '"armv8a"'],
> +['RTE_MAX_LCORE', 256],
> ['RTE_CACHE_LINE_SIZE', 128]]
>  flags_cavium = [
> ['RTE_MACHINE', '"thunderx"'],
> ['RTE_CACHE_LINE_SIZE', 128],
> ['RTE_MAX_NUMA_NODES', 2],
> -   ['RTE_MAX_LCORE', 96],
> -   ['RTE_MAX_VFIO_GROUPS', 128],
> +['RTE_MAX_LCORE', 256],

thunderx has only 96 cores. It the "thunderx2" which has more cores.
There no speerate config "thunderx2", it is using generic armv8 config.
So this specific line of change is not needed.

> +['RTE_MAX_VFIO_GROUPS', 128],
> ['RTE_USE_C11_MEM_MODEL', false]]
>  flags_dpaa = [
> ['RTE_MACHINE', '"dpaa"'],
> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
> b/config/defconfig_arm64-armv8a-linuxapp-gcc
> index 1842744..a6ed90c 100644
> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> @@ -6,3 +6,4 @@
> 
>  CONFIG_RTE_TOOLCHAIN="gcc"
>  CONFIG_RTE_TOOLCHAIN_GCC=y
> +CONFIG_RTE_MAX_LCORE=256
> --
> 2.7.4
> 

Re: [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library

[Ilya Maximets]

Hi.
Is the any differentiation points with liburcu [1] ?
Is there any profit having own implementation inside DPDK ?

[1] http://liburcu.org/
https://lwn.net/Articles/573424/

Best regards, Ilya Maximets.

> Lock-less data structures provide scalability and determinism.
> They enable use cases where locking may not be allowed
> (for ex: real-time applications).
> 
> In the following paras, the term 'memory' refers to memory allocated
> by typical APIs like malloc or anything that is representative of
> memory, for ex: an index of a free element array.
> 
> Since these data structures are lock less, the writers and readers
> are accessing the data structures simultaneously. Hence, while removing
> an element from a data structure, the writers cannot return the memory
> to the allocator, without knowing that the readers are not
> referencing that element/memory anymore. Hence, it is required to
> separate the operation of removing an element into 2 steps:
> 
> Delete: in this step, the writer removes the element from the
> data structure but does not return the associated memory to the allocator.
> This will ensure that new readers will not get a reference to the removed
> element. Removing the reference is an atomic operation.
> 
> Free: in this step, the writer returns the memory to the
> memory allocator, only after knowing that all the readers have stopped
> referencing the removed element.
> 
> This library helps the writer determine when it is safe to free the
> memory.
> 
> This library makes use of Thread Quiescent State (TQS). TQS can be
> defined as 'any point in the thread execution where the thread does
> not hold a reference to shared memory'. It is upto the application to
> determine its quiescent state. Let us consider the following diagram:
> 
> Time -->
> 
> | |
>   RT1   $D1+++***D2*|**+++|+++**D3*$
> | |
>   RT2  $D1++|+**D2|***++**D3*$
> | |
>   RT3  $D1+++***|D2***|++**D2*$
> | |
> |<--->|
>Del | Free
>|
>   Cannot free memory
>   during this period
> 
> RTx - Reader thread
> < and > - Start and end of while(1) loop
> ***Dx*** - Reader thread is accessing the shared data structure Dx.
>i.e. critical section.
> +++ - Reader thread is not accessing any shared data structure.
>   i.e. non critical section or quiescent state.
> Del - Point in time when the reference to the entry is removed using
>   atomic operation.
> Free - Point in time when the writer can free the entry.
> 
> As shown thread RT1 acesses data structures D1, D2 and D3. When it is
> accessing D2, if the writer has to remove an element from D2, the
> writer cannot return the memory associated with that element to the
> allocator. The writer can return the memory to the allocator only after
> the reader stops referencng D2. In other words, reader thread RT1
> has to enter a quiescent state.
> 
> Similarly, since thread RT3 is also accessing D2, writer has to wait till
> RT3 enters quiescent state as well.
> 
> However, the writer does not need to wait for RT2 to enter quiescent state.
> Thread RT2 was not accessing D2 when the delete operation happened.
> So, RT2 will not get a reference to the deleted entry.
> 
> It can be noted that, the critical sections for D2 and D3 are quiescent states
> for D1. i.e. for a given data structure Dx, any point in the thread execution
> that does not reference Dx is a quiescent state.
> 
> For DPDK applications, the start and end of while(1) loop (where no shared
> data structures are getting accessed) act as perfect quiescent states. This
> will combine all the shared data structure accesses into a single critical
> section and keeps the over head introduced by this library to the minimum.
> 
> However, the length of the critical section and the number of reader threads
> is proportional to the time taken to identify the end of critical section.
> So, if the application desires, it should be possible to identify the end
> of critical section for each data structure.
> 
> To provide the required flexibility, this library has a concept of TQS
> variable. The application can create one or more TQS variables to help it
> track the end of one or more critical sections.
> 
> The application can create a TQS variable using the API rte_tqs_alloc.
> It takes a mask of lcore IDs that will report their quiescent states
> using this variable. This mask can be empty to start with.
> 
> rte_tqs_register_lcore API will register a reader thread to report its
> quiescent state. This can be called from any control plane thread or from
> the reader thread. The 

[dpdk-dev] [PATCH v4] config: enable more than 128 cores for Arm64 platform

[Joyce Kong]

When running dpdk applications on cores whose ids are bigger
than original max_core setting, eal error as below:
EAL: Detected 104 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: invalid core list
-l CORELIST core indexes between 0 and 128

The fix is to increase max_core to 256 on Arm64 platform.

Fixes: b3ce00e5 ("mk: introduce ARMv8 architecture")
Cc: sta...@dpdk.org

Signed-off-by: Joyce Kong 
Reviewed-by: Gavin Hu 
---
 config/arm/meson.build | 1 +
 config/defconfig_arm64-armv8a-linuxapp-gcc | 1 +
 2 files changed, 2 insertions(+)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index b755138..3f91725 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -46,6 +46,7 @@ flags_common_default = [
 
 flags_generic = [
['RTE_MACHINE', '"armv8a"'],
+   ['RTE_MAX_LCORE', 256],
['RTE_CACHE_LINE_SIZE', 128]]
 flags_cavium = [
['RTE_MACHINE', '"thunderx"'],
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 1842744..a6ed90c 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -6,3 +6,4 @@
 
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y
+CONFIG_RTE_MAX_LCORE=256
-- 
2.7.4

Re: [dpdk-dev] [PATCH v3] config: enable more than 128 cores for Arm64 platform

[Joyce Kong (Arm Technology China)]

> -Original Message-
> From: Jerin Jacob 
> Sent: Thursday, November 22, 2018 3:09 PM
> To: Joyce Kong (Arm Technology China) 
> Cc: dev@dpdk.org; tho...@monjalon.net; Honnappa Nagarahalli
> ; Gavin Hu (Arm Technology China)
> ; sta...@dpdk.org
> Subject: Re: [PATCH v3] config: enable more than 128 cores for Arm64
> platform
>
> -Original Message-
> > Date: Thu, 22 Nov 2018 15:01:14 +0800
> > From: Joyce Kong 
> > To: dev@dpdk.org
> > CC: tho...@monjalon.net, jerin.ja...@caviumnetworks.com,
> > honnappa.nagaraha...@arm.com, gavin...@arm.com, sta...@dpdk.org
> > Subject: [PATCH v3] config: enable more than 128 cores for Arm64
> > platform
> > X-Mailer: git-send-email 2.7.4
> >
> >
> > When running dpdk applications on cores whose ids are bigger than
> > original max_core setting, eal error as below:
> > EAL: Detected 104 lcore(s)
> > EAL: Detected 2 NUMA nodes
> > EAL: invalid core list
> > -l CORELIST core indexes between 0 and 128
> >
> > The fix is to increase max_core to 256 on Arm64 platform.
> >
> > Fixes: b3ce00e5 ("mk: introduce ARMv8 architecture")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Joyce Kong 
> > Reviewed-by: Gavin Hu 
> > ---
> >  config/arm/meson.build | 5 +++--
> >  config/defconfig_arm64-armv8a-linuxapp-gcc | 1 +
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > b755138..9b5f09c 100644
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > @@ -46,13 +46,14 @@ flags_common_default = [
> >
> >  flags_generic = [
> > ['RTE_MACHINE', '"armv8a"'],
> > +['RTE_MAX_LCORE', 256],
> > ['RTE_CACHE_LINE_SIZE', 128]]
> >  flags_cavium = [
> > ['RTE_MACHINE', '"thunderx"'],
> > ['RTE_CACHE_LINE_SIZE', 128],
> > ['RTE_MAX_NUMA_NODES', 2],
> > -   ['RTE_MAX_LCORE', 96],
> > -   ['RTE_MAX_VFIO_GROUPS', 128],
> > +['RTE_MAX_LCORE', 256],
>
> thunderx has only 96 cores. It the "thunderx2" which has more cores.
> There no speerate config "thunderx2", it is using generic armv8 config.
> So this specific line of change is not needed.
>

Remove this specific line of change in V4.

> > +['RTE_MAX_VFIO_GROUPS', 128],
> > ['RTE_USE_C11_MEM_MODEL', false]]  flags_dpaa = [
> > ['RTE_MACHINE', '"dpaa"'],
> > diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc
> > b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > index 1842744..a6ed90c 100644
> > --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> > +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > @@ -6,3 +6,4 @@
> >
> >  CONFIG_RTE_TOOLCHAIN="gcc"
> >  CONFIG_RTE_TOOLCHAIN_GCC=y
> > +CONFIG_RTE_MAX_LCORE=256
> > --
> > 2.7.4
> >
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.