Re: [dpdk-dev] [PATCH v8 00/12] Implement the new ABI policy and add helper scripts

[Kinsella, Ray]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Wednesday 20 November 2019 20:18
> To: Burakov, Anatoly 
> Cc: dev@dpdk.org; Mcnamara, John ; Kinsella,
> Ray ; Richardson, Bruce
> ; david.march...@redhat.com
> Subject: Re: [dpdk-dev] [PATCH v8 00/12] Implement the new ABI policy
> and add helper scripts
> 
> 20/11/2019 18:23, Anatoly Burakov:
> > This patchset prepares the codebase for the new ABI policy and adds a
> > few helper scripts.
> >
> >  379 files changed, 1172 insertions(+), 3409 deletions(-)

[rk] +1
> Thanks for the great work Anatoly
> 
> Acked-by: Thomas Monjalon 
> 

Re: [dpdk-dev] [dpdk-stable] [PATCH] doc: minor fixes in tap guide

[Ferruh Yigit]

On 11/21/2019 4:59 PM, Stephen Hemminger wrote:
> On Thu, 21 Nov 2019 14:27:01 +0100
> Alejandra Ostruszka  wrote:
> 
>> Corrected one typo and ip address.
>>
>> Signed-off-by: Andrzej Ostruszka 
>>
>> Fixes: de96fe68ae95 ("net/tap: add basic flow API patterns and actions")
>> Cc: sta...@dpdk.org
>> ---
>>  doc/guides/nics/tap.rst | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
>> index 4b6d77d37..b6a626a40 100644
>> --- a/doc/guides/nics/tap.rst
>> +++ b/doc/guides/nics/tap.rst
>> @@ -76,7 +76,7 @@ Please change the IP addresses as you see fit.
>>  
>>  If routing is enabled on the host you can also communicate with the DPDK App
>>  over the internet via a standard socket layer application as long as you
>> -account for the protocol handing in the application.
>> +account for the protocol handling in the application.
>>  
>>  If you have a Network Stack in your DPDK application or something like it 
>> you
>>  can utilize that stack to handle the network protocols. Plus you would be 
>> able
>> @@ -134,7 +134,7 @@ Examples of testpmd flow rules
>>  
>>  Drop packets for destination IP 192.168.0.1::
>>  
>> -   testpmd> flow create 0 priority 1 ingress pattern eth / ipv4 dst is 
>> 1.1.1.1 \  
>> +   testpmd> flow create 0 priority 1 ingress pattern eth / ipv4 dst is 
>> 192.168.0.1 \
>>  / end actions drop / end
> 
> There is a standard RFC for what address to use in documentation.
> 
> RFC5735
>192.0.2.0/24 - This block is assigned as "TEST-NET-1" for use in
>documentation and example code.  It is often used in conjunction with
>domain names example.com or example.net in vendor and protocol
>documentation.  As described in [RFC5737], addresses within this
>block do not legitimately appear on the public Internet and can be
>used without any coordination with IANA or an Internet registry.  See
>[RFC1166].
> 
> 
> This is done so that users don't blindly cut/paste from documentation
> 

Good to know, thanks.

Alejandra, if you are OK I can update the IP address in the next-net?

Re: [dpdk-dev] [PATCH] examples/l2fwd-event: add missing SPDX license header

[Hemant Agrawal]

Hi Thomas,

Somehow the patchwork is not reflecting this ACK.

Please  apply this patch.

Regards,
Hemant

> -Original Message-
> From: dev  On Behalf Of Pavan Nikhilesh
> Bhagavatula
> Sent: Monday, November 11, 2019 6:52 PM
> To: Stephen Hemminger 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples/l2fwd-event: add missing SPDX
> license header
> 
> >Add same tag as other files in this example.
> >
> >Signed-off-by: Stephen Hemminger 
> 
> Acked-by: Pavan Nikhilesh 
> 
> >---
> > examples/l2fwd-event/l2fwd_common.c | 4 
> > examples/l2fwd-event/l2fwd_poll.c   | 4 
> > 2 files changed, 8 insertions(+)
> >
> >diff --git a/examples/l2fwd-event/l2fwd_common.c b/examples/l2fwd-
> >event/l2fwd_common.c index 4ba788550ca6..890d511db2d5 100644
> >--- a/examples/l2fwd-event/l2fwd_common.c
> >+++ b/examples/l2fwd-event/l2fwd_common.c
> >@@ -1,3 +1,7 @@
> >+/* SPDX-License-Identifier: BSD-3-Clause
> >+ * Copyright(C) 2019 Marvell International Ltd.
> >+ */
> >+
> > #include "l2fwd_common.h"
> >
> > int
> >diff --git a/examples/l2fwd-event/l2fwd_poll.c b/examples/l2fwd-
> >event/l2fwd_poll.c index cc96b14cb624..a3a3835582d2 100644
> >--- a/examples/l2fwd-event/l2fwd_poll.c
> >+++ b/examples/l2fwd-event/l2fwd_poll.c
> >@@ -1,3 +1,7 @@
> >+/* SPDX-License-Identifier: BSD-3-Clause
> >+ * Copyright(C) 2019 Marvell International Ltd.
> >+ */
> >+
> > #include "l2fwd_poll.h"
> >
> > static inline void
> >--
> >2.20.1

Re: [dpdk-dev] [PATCH] app/test_thash: replace license text with SPDX tag

[Hemant Agrawal]

Acked-by: Hemant Agrawal 

Re: [dpdk-dev] mbuf autotest fails with 19.11-rc3

[Olivier Matz]

Hi Jerin,

On Thu, Nov 21, 2019 at 12:24:24PM +, Jerin Jacob Kollanukkaran wrote:
> mbuf autotest fails with 19.11-rc3
> 
> $ echo "mbuf_autotest" | sudo ./build/app/test/dpdk-test -c 0x3
> 
> EAL: Detected 56 lcore(s)
> EAL: Detected 2 NUMA nodes
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> EAL: Selected IOVA mode 'PA'
> EAL: No available hugepages reported in hugepages-1048576kB
> EAL: Probing VFIO support...
> EAL: PCI device :01:00.0 on NUMA socket 0
> EAL:   probe driver: 8086:1521 net_e1000_igb
> EAL: PCI device :01:00.1 on NUMA socket 0
> EAL:   probe driver: 8086:1521 net_e1000_igb
> APP: HPET is not enabled, using TSC as default timer
> RTE>>mbuf_autotest
> Test mbuf dynamic fields and flags
> Reserved fields:
> Reserved flags:
> Free space in mbuf (0 = free, value = zone alignment):
>   : 00 00 00 00 00 00 00 00
>   0008: 00 00 00 00 00 00 00 00
>   0010: 00 00 00 00 00 00 00 00
>   0018: 00 00 00 00 00 00 00 00
>   0020: 00 00 00 00 00 00 00 00
>   0028: 00 00 00 00 00 00 00 00
>   0030: 00 00 00 00 00 00 00 00
>   0038: 00 00 00 00 00 00 00 00
>   0040: 00 00 00 00 00 00 00 00
>   0048: 00 00 00 00 00 00 00 00
>   0050: 00 00 00 00 00 00 00 00
>   0058: 00 00 00 00 00 00 00 00
>   0060: 00 00 00 00 00 00 00 00
>   0068: 00 00 00 00 00 00 00 00
>   0070: 10 10 10 10 10 10 10 10
>   0078: 10 10 10 10 10 10 10 10
> dynfield: offset=112, offset2=114, offset3=120
> dynflag: flag=23, flag2=24, flag3=40
> Reserved fields:
>   name=test-dynfield offset=112 size=1 align=1 flags=0
>   name=test-dynfield2 offset=114 size=2 align=2 flags=0
>   name=test-dynfield3 offset=120 size=1 align=1 flags=0
> Reserved flags:
>   name=test-dynflag bitnum=23 flags=0
>   name=test-dynflag2 bitnum=24 flags=0
>   name=test-dynflag3 bitnum=40 flags=0
> Free space in mbuf (0 = free, value = zone alignment):
>   : 00 00 00 00 00 00 00 00
>   0008: 00 00 00 00 00 00 00 00
>   0010: 00 00 00 00 00 00 00 00
>   0018: 00 00 00 00 00 00 00 00
>   0020: 00 00 00 00 00 00 00 00
>   0028: 00 00 00 00 00 00 00 00
>   0030: 00 00 00 00 00 00 00 00
>   0038: 00 00 00 00 00 00 00 00
>   0040: 00 00 00 00 00 00 00 00
>   0048: 00 00 00 00 00 00 00 00
>   0050: 00 00 00 00 00 00 00 00
>   0058: 00 00 00 00 00 00 00 00
>   0060: 00 00 00 00 00 00 00 00
>   0068: 00 00 00 00 00 00 00 00
>   0070: 00 01 00 00 04 04 04 04
>   0078: 00 01 02 02 04 04 04 04
> cannot allocate mbuf pool
> Test Failed

Could you please share some details about your configuration?
(amount of memory, arch, ...)

On my platform the test works, except if I use a very low amount
of memory (few MBs).

Thanks,
Olivier

[dpdk-dev] [PATCH] add top level SPDX license identifier.

[Hemant Agrawal]

This patch adds top level SPDX license identifiers for some of the dpdk
source and scripts, where the copyright owners have not yet agreed to
replace the full BSD-3 license plate.

This patch also add SPDX license tag for some of files with no
previous license plates. (DPDK is BSD-3)

Signed-off-by: Hemant Agrawal 
---
 app/test-pmd/flowgen.c |  7 ++-
 app/test-pmd/macswap.c |  6 ++
 app/test/test_cfgfile.c|  6 ++
 app/test/test_compressdev_test_buffer.h|  2 ++
 app/test/test_timer_racecond.c |  8 +++-
 devtools/cocci.sh  |  3 +--
 drivers/net/nfp/nfp_net.c  |  2 +-
 drivers/net/nfp/nfp_net_ctrl.h |  2 +-
 drivers/net/nfp/nfp_net_logs.h |  2 +-
 drivers/net/nfp/nfp_net_pmd.h  |  2 +-
 .../test/trs_aesgcm_inline_crypto_fallback_defs.sh |  2 +-
 .../test/tun_aesgcm_inline_crypto_fallback_defs.sh |  2 +-
 examples/performance-thread/l3fwd-thread/test.sh   |  1 +
 lib/librte_ethdev/rte_ethdev_pci.h |  6 ++
 lib/librte_ethdev/rte_ethdev_vdev.h|  6 ++
 lib/librte_port/rte_port_kni.c | 10 --
 lib/librte_port/rte_port_kni.h | 10 --
 17 files changed, 31 insertions(+), 46 deletions(-)

diff --git a/app/test-pmd/flowgen.c b/app/test-pmd/flowgen.c
index 03b72aaa5..a00d91a3a 100644
--- a/app/test-pmd/flowgen.c
+++ b/app/test-pmd/flowgen.c
@@ -1,8 +1,5 @@
-/*-
- *   BSD LICENSE
- *
- *   Copyright(c) 2010-2013 Tilera Corporation. All rights reserved.
- *   All rights reserved.
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2013 Tilera Corporation. All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
  *   modification, are permitted provided that the following conditions
diff --git a/app/test-pmd/macswap.c b/app/test-pmd/macswap.c
index 71af916fc..73f33f4b4 100644
--- a/app/test-pmd/macswap.c
+++ b/app/test-pmd/macswap.c
@@ -1,7 +1,5 @@
-/*-
- *   BSD LICENSE
- *
- *   Copyright(c) 2014 Tilera Corporation. All rights reserved.
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2014 Tilera Corporation. All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
  *   modification, are permitted provided that the following conditions
diff --git a/app/test/test_cfgfile.c b/app/test/test_cfgfile.c
index 37435b395..2fcedfce0 100644
--- a/app/test/test_cfgfile.c
+++ b/app/test/test_cfgfile.c
@@ -1,7 +1,5 @@
-/*-
- *   BSD LICENSE
- *
- *   Copyright(c) 2017 Wind River Systems Inc. All rights reserved.
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2017 Wind River Systems Inc. All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
  *   modification, are permitted provided that the following conditions
diff --git a/app/test/test_compressdev_test_buffer.h 
b/app/test/test_compressdev_test_buffer.h
index c0492f89a..db701c6a0 100644
--- a/app/test/test_compressdev_test_buffer.h
+++ b/app/test/test_compressdev_test_buffer.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ */
 #ifndef TEST_COMPRESSDEV_TEST_BUFFERS_H_
 #define TEST_COMPRESSDEV_TEST_BUFFERS_H_
 
diff --git a/app/test/test_timer_racecond.c b/app/test/test_timer_racecond.c
index a9e1daf16..58bcd73f7 100644
--- a/app/test/test_timer_racecond.c
+++ b/app/test/test_timer_racecond.c
@@ -1,8 +1,6 @@
-/*-
- *   BSD LICENSE
- *
- *   Copyright(c) 2015 Akamai Technologies.
- *   All rights reserved.
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2015 Akamai Technologies.
+ * All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
  *   modification, are permitted provided that the following conditions
diff --git a/devtools/cocci.sh b/devtools/cocci.sh
index 8b17a8ceb..ce8ab298e 100755
--- a/devtools/cocci.sh
+++ b/devtools/cocci.sh
@@ -1,7 +1,6 @@
 #! /bin/sh
 
-# BSD LICENSE
-#
+# SPDX-License-Identifier: BSD-3-Clause
 # Copyright 2015 EZchip Semiconductor Ltd.
 #
 # Redistribution and use in source and binary forms, with or without
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 450875ce2..ac693b8d0 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1,4 +1,4 @@
-/*
+/* SPDX-License-Identifier: BSD-3-Clause
  * Copyright (c) 2014-2018 Netronome Systems, Inc.
  * All rights reserved.
  *
diff --git a/drivers/net/nfp/nfp_net_ctrl.h b/drivers/net/nfp/nfp_net_ctrl.h
index fc3540a2e..958bfc6ec 100644
--- a/drivers/net/nfp/nfp_net_ctrl.h
+++ b/drivers/net/nfp/nfp_net_ctrl.h
@@ -1,4 +1,4 @@
-/*
+/* SPDX-License-Identifier: BSD-3-Clause
  * Copyright (c) 2014, 2015 Netronome Systems, Inc.
  * All rights res

[dpdk-dev] SPDX compliance for the 19.11 release

[Hemant Agrawal]

Hi all,
  Though large portion of DPDK code/scripts are now using SPDX license 
tags, there are still some old files having full license text without SPDX 
tags.  Their original authors/copyright holders are either not responding or 
not traceable.

Let's not wait for them forever.  Following patch just add the SPDX tags 
without removing the original license plate.

http://patchwork.dpdk.org/patch/63225/  "add top level SPDX license identifier."

Please review and ack it.

Also, following related patches are ready for merge.  (they are acked or 
submitted by the copyright holders)


  1.  https://patches.dpdk.org/patch/57613/ "app/test_thash: replace license 
text with SPDX tag"
  2.  http://patchwork.dpdk.org/patch/62801/  "examples/l2fwd-event: add 
missing SPDX license header"
  3.  https://patchwork.dpdk.org/patch/62804/ "devtools: add SPDX license 
tag check script"


Finally, following patch is still waiting the Governing Board exception 
approval:
http://patchwork.dpdk.org/patch/59976/  "[v2] pmdinfogen: add SPDX license tag"

Regards,
Hemant

Re: [dpdk-dev] [PATCH v2 3/3] ethdev: improve flow mark Rx offload deprecation notice

[Andrew Rybchenko]

On 11/22/19 1:01 AM, Thomas Monjalon wrote:
> 19/11/2019 13:12, Andrew Rybchenko:
>> The deprecation notice is required since it adds more requirements
>> when RTE flow mark and flag actions may be used and require
>> changes in applications.
> I am still not sure what is the best solution here.
> I continued to think about it in this thread:
>   http://mails.dpdk.org/archives/dev/2019-November/151960.html
>
> I think we cannot require any application change until 20.11
> in order to keep API (and behaviour) compatibility.

Expected, but still very disappointing.

The feature is implemented by Pavan (@ Marvell), supported by me,
used by Qi (@ Intel), looks better than alternatives from application
developer point of view [1] and finally postponed for 1 year without really
strong motivation. I disagree that it is tightly related to moving
mark/flag to
dynamic field/flag and absolutely blocked by it. Yes, I know that the are
concerns from the very beginning, but the problem is explained [2] and clear
and no full-featured alternative solution is suggested. Solution suggested
by Ori has many significant drawbacks as explained in [2] and highlighted
in further discussion.

[1] http://inbox.dpdk.org/dev/1573203631946.15...@kth.se/
[2]
http://inbox.dpdk.org/dev/f170105b-9c60-1b04-cb18-52e0951dd...@solarflare.com/

> If something would be implemented in 20.02,
> it must be a new and optional API.

Flow mark and flag may work without the offload with some drivers,
but some drivers require the offload to make it work. Flow API error
should contain message which says that the offload is disabled and
must be enabled.

> That's why I think no deprecation notice is required.
>
> [...]
>> +* ethdev: New offload flag ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in 
>> 20.02.
>> +  This will provide application an information if 
>> ``RTE_FLOW_ACTION_TYPE_MARK``
>> +  or ``RTE_FLOW_ACTION_TYPE_FLAG`` is supported and, what is more important,
>> +  allow an application to let PMD know that it would like to use these
>> +  features.
>> +  PMD may use the information to choose optimal datapath implementation and
>> +  configure HW appropriately to optimize performance and/or resources usage.

[dpdk-dev] [PATCH v2] app/testpmd: reduce memory consumption

[David Marchand]

Following [1], testpmd memory consumption has skyrocketted.
The rte_port structure has gotten quite fat.

struct rte_port {
[...]
  struct rte_eth_rxconf rx_conf[65536];/* 266280 3145728 */
  /* --- cacheline 53312 boundary (3411968 bytes) was 40 bytes ago --- */
  struct rte_eth_txconf tx_conf[65536];/* 3412008 3670016 */
  /* --- cacheline 110656 boundary (7081984 bytes) was 40 bytes ago --- */
[...]
  /* size: 8654936, cachelines: 135234, members: 31 */
[...]

testpmd handles RTE_MAX_ETHPORTS ports (32 by default) which means that it
needs ~256MB just for this internal representation.

The reason is that a testpmd rte_port (the name is quite confusing, as
it is a local type) maintains configurations for all queues of a port.
But where you would expect testpmd to use RTE_MAX_QUEUES_PER_PORT as the
maximum queue count, the rte_port uses MAX_QUEUE_ID set to 64k.

Prefer the ethdev maximum value.

After this patch:
struct rte_port {
[...]
  struct rte_eth_rxconf  rx_conf[1025];/*  8240 49200 */
  /* --- cacheline 897 boundary (57408 bytes) was 32 bytes ago --- */
  struct rte_eth_txconf  tx_conf[1025];/* 57440 57400 */
  /* --- cacheline 1794 boundary (114816 bytes) was 24 bytes ago --- */
[...]
  /* size: 139488, cachelines: 2180, members: 31 */
[...]

With this, we can ask for less memory in test-null.sh.

[1]: https://git.dpdk.org/dpdk/commit/?id=436b3a6b6e62

Signed-off-by: David Marchand 
Acked-by: Ferruh Yigit 
Acked-by: Thomas Monjalon 
---
Changelog since v1:
- updated test-null.sh

---
 app/test-pmd/testpmd.c |  6 +++---
 app/test-pmd/testpmd.h | 16 +++-
 devtools/test-null.sh  |  2 +-
 3 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 73ebf37aae..d28211ba52 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -979,7 +979,7 @@ check_socket_id(const unsigned int socket_id)
 queueid_t
 get_allowed_max_nb_rxq(portid_t *pid)
 {
-   queueid_t allowed_max_rxq = MAX_QUEUE_ID;
+   queueid_t allowed_max_rxq = RTE_MAX_QUEUES_PER_PORT;
bool max_rxq_valid = false;
portid_t pi;
struct rte_eth_dev_info dev_info;
@@ -1029,7 +1029,7 @@ check_nb_rxq(queueid_t rxq)
 queueid_t
 get_allowed_max_nb_txq(portid_t *pid)
 {
-   queueid_t allowed_max_txq = MAX_QUEUE_ID;
+   queueid_t allowed_max_txq = RTE_MAX_QUEUES_PER_PORT;
bool max_txq_valid = false;
portid_t pi;
struct rte_eth_dev_info dev_info;
@@ -1079,7 +1079,7 @@ check_nb_txq(queueid_t txq)
 queueid_t
 get_allowed_max_nb_hairpinq(portid_t *pid)
 {
-   queueid_t allowed_max_hairpinq = MAX_QUEUE_ID;
+   queueid_t allowed_max_hairpinq = RTE_MAX_QUEUES_PER_PORT;
portid_t pi;
struct rte_eth_hairpin_cap cap;
 
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 90694a3309..217d577018 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -58,8 +58,6 @@ typedef uint16_t portid_t;
 typedef uint16_t queueid_t;
 typedef uint16_t streamid_t;
 
-#define MAX_QUEUE_ID ((1 << (sizeof(queueid_t) * 8)) - 1)
-
 #if defined RTE_LIBRTE_PMD_SOFTNIC
 #define SOFTNIC1
 #else
@@ -179,22 +177,22 @@ struct rte_port {
uint8_t need_reconfig_queues; /**< need reconfiguring 
queues or not */
uint8_t rss_flag;   /**< enable rss or not */
uint8_t dcb_flag;   /**< enable dcb */
-   uint16_tnb_rx_desc[MAX_QUEUE_ID+1]; /**< per queue rx 
desc number */
-   uint16_tnb_tx_desc[MAX_QUEUE_ID+1]; /**< per queue tx 
desc number */
-   struct rte_eth_rxconf   rx_conf[MAX_QUEUE_ID+1]; /**< per queue rx 
configuration */
-   struct rte_eth_txconf   tx_conf[MAX_QUEUE_ID+1]; /**< per queue tx 
configuration */
+   uint16_tnb_rx_desc[RTE_MAX_QUEUES_PER_PORT+1]; /**< per 
queue rx desc number */
+   uint16_tnb_tx_desc[RTE_MAX_QUEUES_PER_PORT+1]; /**< per 
queue tx desc number */
+   struct rte_eth_rxconf   rx_conf[RTE_MAX_QUEUES_PER_PORT+1]; /**< per 
queue rx configuration */
+   struct rte_eth_txconf   tx_conf[RTE_MAX_QUEUES_PER_PORT+1]; /**< per 
queue tx configuration */
struct rte_ether_addr   *mc_addr_pool; /**< pool of multicast addrs */
uint32_tmc_addr_nb; /**< nb. of addr. in mc_addr_pool */
uint8_t slave_flag; /**< bonding slave port */
struct port_flow*flow_list; /**< Associated flows. */
-   const struct rte_eth_rxtx_callback *rx_dump_cb[MAX_QUEUE_ID+1];
-   const struct rte_eth_rxtx_callback *tx_dump_cb[MAX_QUEUE_ID+1];
+   const struct rte_eth_rxtx_callback 
*rx_dump_cb[RTE_MAX_QUEUES_PER_PORT+1];
+   const struct rte_eth_rxtx_callback 
*tx_dump_cb[RTE_MAX_QUEUES_PER_PORT+1];
 #ifdef SOFTNIC
struct softnic_port softport;  /**< softnic params */
 #endif
 

Re: [dpdk-dev] [PATCH v2 3/3] ethdev: improve flow mark Rx offload deprecation notice

[Thomas Monjalon]

22/11/2019 11:12, Andrew Rybchenko:
> On 11/22/19 1:01 AM, Thomas Monjalon wrote:
> > 19/11/2019 13:12, Andrew Rybchenko:
> >> The deprecation notice is required since it adds more requirements
> >> when RTE flow mark and flag actions may be used and require
> >> changes in applications.
> > I am still not sure what is the best solution here.
> > I continued to think about it in this thread:
> > http://mails.dpdk.org/archives/dev/2019-November/151960.html
> >
> > I think we cannot require any application change until 20.11
> > in order to keep API (and behaviour) compatibility.
> 
> Expected, but still very disappointing.
> 
> The feature is implemented by Pavan (@ Marvell), supported by me,
> used by Qi (@ Intel), looks better than alternatives from application
> developer point of view [1] and finally postponed for 1 year without really
> strong motivation.

I see different valuable point of views. This is enough motivation.

And no, it is not postponed by one year.
Next release can implement a new API.

> I disagree that it is tightly related to moving
> mark/flag to
> dynamic field/flag and absolutely blocked by it. Yes, I know that the are
> concerns from the very beginning, but the problem is explained [2] and clear
> and no full-featured alternative solution is suggested. Solution suggested
> by Ori has many significant drawbacks as explained in [2] and highlighted
> in further discussion.

I disagree with working only on mark action while there are a lot
of other configs which have to be implemented in drivers.

The reality is that some drivers decided to have some "optimizations"
disabling some features, and you want the application to opt-in
in order to allow your optimized paths.
Note that opt-in is different of really enabling an offload.
For some basic port-level features like RSS hash,
it is enabled with an offload flag before starting the port,
acting as an opt-in.
Some features have some dedicated API, which may be enabled after
starting the port, and no way to opt-in (or opt-out) before start.
A lot of features are using rte_flow API which is in this situation.
If we take the opt-in path, let's not do it only for the mark action,
but let's create a real API for it:
rte_eth_dev_optin()
rte_eth_dev_optinall()
rte_eth_dev_optoutl()

I think the motivation is strong enough.

> [1] http://inbox.dpdk.org/dev/1573203631946.15...@kth.se/
> [2]
> http://inbox.dpdk.org/dev/f170105b-9c60-1b04-cb18-52e0951dd...@solarflare.com/
> 
> > If something would be implemented in 20.02,
> > it must be a new and optional API.
> 
> Flow mark and flag may work without the offload with some drivers,
> but some drivers require the offload to make it work. Flow API error
> should contain message which says that the offload is disabled and
> must be enabled.

Yes, the PMD should return an explicit error about a feature being disabled.
How does it impact ethdev API?

> > That's why I think no deprecation notice is required.
> >
> > [...]
> >> +* ethdev: New offload flag ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in 
> >> 20.02.
> >> +  This will provide application an information if 
> >> ``RTE_FLOW_ACTION_TYPE_MARK``
> >> +  or ``RTE_FLOW_ACTION_TYPE_FLAG`` is supported and, what is more 
> >> important,
> >> +  allow an application to let PMD know that it would like to use these
> >> +  features.
> >> +  PMD may use the information to choose optimal datapath implementation 
> >> and
> >> +  configure HW appropriately to optimize performance and/or resources 
> >> usage.

[dpdk-dev] [PATCH v2] mk: remove library search path from binary

[Ferruh Yigit]

This patch functionally reverts the patch in fixes line to not have any
hardcoded library path in the final binary for the security reasons, in
case this binary distributed to production environment.

RPATH only added in RTE_DEVEL_BUILD case and this binary shouldn't
distributed, but still removing it to be cautious.

Fixes: 8919f73bcbaa ("mk: add build directory to library search path")
Cc: sta...@dpdk.org

Suggested-by: Bruce Richardson 
Signed-off-by: Ferruh Yigit 
---
v2:
* set 'build' if provided argument is testpmd path
---
 devtools/test-null.sh | 2 ++
 mk/rte.app.mk | 4 
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/devtools/test-null.sh b/devtools/test-null.sh
index 9f9a459f7..afcd8bb29 100755
--- a/devtools/test-null.sh
+++ b/devtools/test-null.sh
@@ -11,6 +11,7 @@ coremask=${2:-3} # default using cores 0 and 1
 eal_options=$3
 testpmd_options=$4
 
+[ -f "$testpmd" ] && build=$(dirname $(dirname $testpmd))
 [ -f "$testpmd" ] || testpmd=$build/app/dpdk-testpmd
 [ -f "$testpmd" ] || testpmd=$build/app/testpmd
 if [ ! -f "$testpmd" ] ; then
@@ -19,6 +20,7 @@ if [ ! -f "$testpmd" ] ; then
 fi
 
 if ldd $testpmd | grep -q librte_ ; then
+   export LD_LIBRARY_PATH=$build/lib:$LD_LIBRARY_PATH
libs='-d librte_mempool_ring.so -d librte_pmd_null.so'
 else
libs=
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index a278552c6..05ea034b9 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -379,10 +379,6 @@ filter-libs = \
 
 LDLIBS := $(call filter-libs,$(LDLIBS))
 
-ifeq ($(RTE_DEVEL_BUILD)$(CONFIG_RTE_BUILD_SHARED_LIB),yy)
-LDFLAGS += -rpath=$(RTE_SDK_BIN)/lib
-endif
-
 MAPFLAGS = -Map=$@.map --cref
 
 .PHONY: all
-- 
2.21.0

Re: [dpdk-dev] [PATCH v2 3/3] ethdev: improve flow mark Rx offload deprecation notice

[Andrew Rybchenko]

On 11/22/19 2:15 PM, Thomas Monjalon wrote:
> 22/11/2019 11:12, Andrew Rybchenko:
>> On 11/22/19 1:01 AM, Thomas Monjalon wrote:
>>> 19/11/2019 13:12, Andrew Rybchenko:
 The deprecation notice is required since it adds more requirements
 when RTE flow mark and flag actions may be used and require
 changes in applications.
>>> I am still not sure what is the best solution here.
>>> I continued to think about it in this thread:
>>> http://mails.dpdk.org/archives/dev/2019-November/151960.html
>>>
>>> I think we cannot require any application change until 20.11
>>> in order to keep API (and behaviour) compatibility.
>> Expected, but still very disappointing.
>>
>> The feature is implemented by Pavan (@ Marvell), supported by me,
>> used by Qi (@ Intel), looks better than alternatives from application
>> developer point of view [1] and finally postponed for 1 year without really
>> strong motivation.
> I see different valuable point of views. This is enough motivation.

It looks like I miss it in previous discussion, I would be thankful if
you give me links to read or hints how to find.

> And no, it is not postponed by one year.
> Next release can implement a new API.
>
>> I disagree that it is tightly related to moving
>> mark/flag to
>> dynamic field/flag and absolutely blocked by it. Yes, I know that the are
>> concerns from the very beginning, but the problem is explained [2] and clear
>> and no full-featured alternative solution is suggested. Solution suggested
>> by Ori has many significant drawbacks as explained in [2] and highlighted
>> in further discussion.
> I disagree with working only on mark action while there are a lot
> of other configs which have to be implemented in drivers.
>
> The reality is that some drivers decided to have some "optimizations"
> disabling some features, and you want the application to opt-in
> in order to allow your optimized paths.

Strictly speaking it is not about driver optimized paths only, but HW
configuration as well which can be done on start-up only (not dynamic) and
could be per-queue in fact.

> Note that opt-in is different of really enabling an offload.
> For some basic port-level features like RSS hash,
> it is enabled with an offload flag before starting the port,
> acting as an opt-in.

Could you highlight the difference between opt-in and offload.
What is the key difference which makes one solution better
than another? Why different mechanism is required?

> Some features have some dedicated API, which may be enabled after
> starting the port, and no way to opt-in (or opt-out) before start.

It sounds like you have examples in your mind. Please, share.

> A lot of features are using rte_flow API which is in this situation.
> If we take the opt-in path, let's not do it only for the mark action,
> but let's create a real API for it:
>   rte_eth_dev_optin()
>   rte_eth_dev_optinall()
>   rte_eth_dev_optoutl()

Introducing new types of controls would make configuration more and
more complex. I think that many different types of control would
over-complicate it. May be it is unavoidable, but it should be clear
why the problem cannot be solved using existing types of controls
(e.g. offloads).

> I think the motivation is strong enough.
>
>> [1] http://inbox.dpdk.org/dev/1573203631946.15...@kth.se/
>> [2]
>> http://inbox.dpdk.org/dev/f170105b-9c60-1b04-cb18-52e0951dd...@solarflare.com/
>>
>>> If something would be implemented in 20.02,
>>> it must be a new and optional API.
>> Flow mark and flag may work without the offload with some drivers,
>> but some drivers require the offload to make it work. Flow API error
>> should contain message which says that the offload is disabled and
>> must be enabled.
> Yes, the PMD should return an explicit error about a feature being disabled.
> How does it impact ethdev API?

It is still the offload discussed in the deprecation notice.
The solution is far from ideal, since allows the difference in PMDs
behaviour and an application debugged on one PMD may not
work using another PMD (unfortunately it is true in any case, but
such definition makes it 100% legal).

>>> That's why I think no deprecation notice is required.
>>>
>>> [...]
 +* ethdev: New offload flag ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in 
 20.02.
 +  This will provide application an information if 
 ``RTE_FLOW_ACTION_TYPE_MARK``
 +  or ``RTE_FLOW_ACTION_TYPE_FLAG`` is supported and, what is more 
 important,
 +  allow an application to let PMD know that it would like to use these
 +  features.
 +  PMD may use the information to choose optimal datapath implementation 
 and
 +  configure HW appropriately to optimize performance and/or resources 
 usage.

Re: [dpdk-dev] [PATCH] devtools: fix required memory for null test

[David Marchand]

On Wed, Nov 20, 2019 at 10:29 AM Thomas Monjalon  wrote:
>
> The testpmd fails in memory allocation since some ethdev structs
> have been extended.
> Increasing memory allocation from 150 to 300 MB makes it working again.
>
> Fixes: 436b3a6b6e62 ("ethdev: reserve space in main structs for extension")

Fixed with https://patchwork.dpdk.org/patch/63226/
Marking as rejected.

-- 
David Marchand

Re: [dpdk-dev] [PATCH v2] app/testpmd: reduce memory consumption

[Ferruh Yigit]

On 11/22/2019 10:43 AM, David Marchand wrote:
> diff --git a/devtools/test-null.sh b/devtools/test-null.sh
> index 9f9a459f76..6e5b1ad529 100755
> --- a/devtools/test-null.sh
> +++ b/devtools/test-null.sh
> @@ -25,6 +25,6 @@ else
>  fi
>  
>  (sleep 1 && echo stop) |
> -$testpmd -c $coremask --no-huge -m 150 \
> +$testpmd -c $coremask --no-huge -m 20 \
>   $libs --vdev net_null1 --vdev net_null2 $eal_options -- \
>   --no-mlockall --total-num-mbufs=2048 $testpmd_options -ia

What do you think to separate this part, and go with first version of the 
patchset?

And I am not sure if we should update at all, what is the benefit?

Also script fails after update, because of the additional physical devices and
their memory requirement, it is possible to make it run with additional testpmd
argument but fails by default.

Re: [dpdk-dev] [dpdk-stable] [PATCH] doc: minor fixes in tap guide

[Ferruh Yigit]

On 11/22/2019 9:19 AM, Ferruh Yigit wrote:
> On 11/21/2019 4:59 PM, Stephen Hemminger wrote:
>> On Thu, 21 Nov 2019 14:27:01 +0100
>> Alejandra Ostruszka  wrote:
>>
>>> Corrected one typo and ip address.
>>>
>>> Signed-off-by: Andrzej Ostruszka 
>>>
>>> Fixes: de96fe68ae95 ("net/tap: add basic flow API patterns and actions")
>>> Cc: sta...@dpdk.org
>>> ---
>>>  doc/guides/nics/tap.rst | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
>>> index 4b6d77d37..b6a626a40 100644
>>> --- a/doc/guides/nics/tap.rst
>>> +++ b/doc/guides/nics/tap.rst
>>> @@ -76,7 +76,7 @@ Please change the IP addresses as you see fit.
>>>  
>>>  If routing is enabled on the host you can also communicate with the DPDK 
>>> App
>>>  over the internet via a standard socket layer application as long as you
>>> -account for the protocol handing in the application.
>>> +account for the protocol handling in the application.
>>>  
>>>  If you have a Network Stack in your DPDK application or something like it 
>>> you
>>>  can utilize that stack to handle the network protocols. Plus you would be 
>>> able
>>> @@ -134,7 +134,7 @@ Examples of testpmd flow rules
>>>  
>>>  Drop packets for destination IP 192.168.0.1::
>>>  
>>> -   testpmd> flow create 0 priority 1 ingress pattern eth / ipv4 dst is 
>>> 1.1.1.1 \  
>>> +   testpmd> flow create 0 priority 1 ingress pattern eth / ipv4 dst is 
>>> 192.168.0.1 \
>>>  / end actions drop / end
>>
>> There is a standard RFC for what address to use in documentation.
>>
>> RFC5735
>>192.0.2.0/24 - This block is assigned as "TEST-NET-1" for use in
>>documentation and example code.  It is often used in conjunction with
>>domain names example.com or example.net in vendor and protocol
>>documentation.  As described in [RFC5737], addresses within this
>>block do not legitimately appear on the public Internet and can be
>>used without any coordination with IANA or an Internet registry.  See
>>[RFC1166].
>>
>>
>> This is done so that users don't blindly cut/paste from documentation
>>
> 
> Good to know, thanks.
> 
> Alejandra, if you are OK I can update the IP address in the next-net?
> 

updated to 192.0.2.1

Re: [dpdk-dev] [PATCH v2] mbuf: display more fields in dump

[Andrew Rybchenko]

On 11/21/19 9:30 PM, Stephen Hemminger wrote:
> The rte_pktmbuf_dump should display offset, refcount, and vlan
> info since these are often useful during debugging.
> 
> Signed-off-by: Stephen Hemminger 

May be it would be a bit better to split cosmetic changes into
separate patch(es), but anyway

Acked-by: Andrew Rybchenko 

[dpdk-dev] [Bug 370] Cannot hotplug VFIO devices if VFIO driver was not loaded at init

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=370

Bug ID: 370
   Summary: Cannot hotplug VFIO devices if VFIO driver was not
loaded at init
   Product: DPDK
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: core
  Assignee: dev@dpdk.org
  Reporter: anatoly.bura...@intel.com
  Target Milestone: ---

Currently, VFIO device initialization depends upon checking if VFIO is enabled.
That code looks like this:

> int
> rte_vfio_is_enabled(const char *modname)
> {
> const int mod_available = rte_eal_check_module(modname) > 0;
> return default_vfio_cfg->vfio_enabled && mod_available;
> }

The `default_vfio_cfg->vfio_enabled` is set at initialization time with
`rte_vfio_enable` function, and is never rechecked afterwards. This makes it so
that if `vfio` driver was not loaded at EAL initialization time, any subsequent
VFIO device initialization will fail.

To fix that, we would have to re-check the existence of a `vfio` driver every
time, however the current API gets in the way, because even though it stores
global state, it is implemented in a way that looks like it is supposed to be
generic and support multiple driver names (and is never used that way - the
only time this API is used is in the EAL initialization when checking for a
specific `vfio` driver - i think it's a safe assumption to make that whatever
implementation of VFIO is in use, it will depend upon the `vfio` kernel
module).

So, current API will need to be changed (it makes no sense anyway) before this
bug can be fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[dpdk-dev] [PATCH 1/6] net/hns3: fix RSS hardware configuration restore failure

[Wei Hu (Xavier)]

From: Hao Chen 

This patch fixes the bug that hardware configuration called
tc_size doesn't restore to the initial value when starting
the app, configuring PFC and then restarting the app,
because of the tc_mode didn't initial when rss is disabled.

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: sta...@dpdk.org

Signed-off-by: Hao Chen 
Signed-off-by: Wei Hu (Xavier) 
---
 drivers/net/hns3/hns3_rss.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/hns3/hns3_rss.c b/drivers/net/hns3/hns3_rss.c
index 6a5d63398..b8c20e6d9 100644
--- a/drivers/net/hns3/hns3_rss.c
+++ b/drivers/net/hns3/hns3_rss.c
@@ -525,10 +525,8 @@ hns3_config_rss(struct hns3_adapter *hns)
enum rte_eth_rx_mq_mode mq_mode = hw->data->dev_conf.rxmode.mq_mode;
 
/* When there is no open RSS, redirect the packet queue 0 */
-   if (((uint32_t)mq_mode & ETH_MQ_RX_RSS_FLAG) == 0) {
+   if (((uint32_t)mq_mode & ETH_MQ_RX_RSS_FLAG) == 0)
hns3_rss_uninit(hns);
-   return 0;
-   }
 
/* Configure RSS hash algorithm and hash key offset */
ret = hns3_set_rss_algo_key(hw, hash_algo, hash_key);
-- 
2.23.0

[dpdk-dev] [PATCH 0/6] Fixes for hns3 PMD driver

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

This series add some fixes for hns3 PMD driver.

Chengchang Tang (1):
  net/hns3: fix the error length limit of maiblox response

Hao Chen (1):
  net/hns3: fix RSS hardware configuration restore failure

Huisong Li (1):
  net/hns3: fix the strategy of getting link status for VF

Min Hu (Connor) (1):
  net/hns3: fix duplicate VLAN

Wei Hu (Xavier) (2):
  net/hns3: fix VF configuration table entries restore failure
  net/hns3: fix the failure sending packets less than 60 bytes

 drivers/net/hns3/hns3_ethdev.c|  5 +
 drivers/net/hns3/hns3_ethdev.h|  1 +
 drivers/net/hns3/hns3_ethdev_vf.c | 22 +-
 drivers/net/hns3/hns3_mbx.c   |  4 +---
 drivers/net/hns3/hns3_mbx.h   |  6 ++
 drivers/net/hns3/hns3_rss.c   |  4 +---
 drivers/net/hns3/hns3_rxtx.c  | 24 
 7 files changed, 51 insertions(+), 15 deletions(-)

-- 
2.23.0

[dpdk-dev] [PATCH 2/6] net/hns3: fix VF configuration table entries restore failure

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

When the application using VF device exits abnormally, for example,
when it is killed by 'kill -9', kernel PF netdev driver also stores
the corresponding configuration table entries of VF device.

This patch fixes it by adding message of deleting VF configuration
table entry corresponds to the revision of kernel hns3 netdev
driver, the new message is added to notify the kernel PF netdev
driver to clean up the VF configuration initialization during VF
initialization.

This revision is compatible with the old version of kernel hns3
netdev driver. The old version of kernel pf netdev driver will
ignore this message.

Fixes: a5475d61fa34 ("net/hns3: support VF")
Cc: sta...@dpdk.org

Signed-off-by: Hongbo Zheng 
Signed-off-by: Wei Hu (Xavier) 
---
 drivers/net/hns3/hns3_ethdev_vf.c | 14 ++
 drivers/net/hns3/hns3_mbx.h   |  6 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/net/hns3/hns3_ethdev_vf.c 
b/drivers/net/hns3/hns3_ethdev_vf.c
index 403674969..2274ac35e 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -1096,6 +1096,14 @@ hns3vf_init_hardware(struct hns3_adapter *hns)
return ret;
 }
 
+static int
+hns3vf_clear_vport_list(struct hns3_hw *hw)
+{
+   return hns3_send_mbx_msg(hw, HNS3_MBX_HANDLE_VF_TBL,
+HNS3_MBX_VPORT_LIST_CLEAR, NULL, 0, false,
+NULL, 0);
+}
+
 static int
 hns3vf_init_vf(struct rte_eth_dev *eth_dev)
 {
@@ -1147,6 +1155,12 @@ hns3vf_init_vf(struct rte_eth_dev *eth_dev)
 
rte_eth_random_addr(hw->mac.mac_addr); /* Generate a random mac addr */
 
+   ret = hns3vf_clear_vport_list(hw);
+   if (ret) {
+   PMD_INIT_LOG(ERR, "Failed to clear tbl list: %d", ret);
+   goto err_get_config;
+   }
+
ret = hns3vf_init_hardware(hns);
if (ret)
goto err_get_config;
diff --git a/drivers/net/hns3/hns3_mbx.h b/drivers/net/hns3/hns3_mbx.h
index ee6e82314..01eddb845 100644
--- a/drivers/net/hns3/hns3_mbx.h
+++ b/drivers/net/hns3/hns3_mbx.h
@@ -39,6 +39,8 @@ enum HNS3_MBX_OPCODE {
HNS3_MBX_SET_ALIVE, /* (VF -> PF) set alive state */
HNS3_MBX_SET_MTU,   /* (VF -> PF) set mtu */
HNS3_MBX_GET_QID_IN_PF, /* (VF -> PF) get queue id in pf */
+
+   HNS3_MBX_HANDLE_VF_TBL = 38,/* (VF -> PF) store/clear hw cfg tbl */
 };
 
 /* below are per-VF mac-vlan subcodes */
@@ -58,6 +60,10 @@ enum hns3_mbx_vlan_cfg_subcode {
HNS3_MBX_VLAN_RX_OFF_CFG,   /* set rx side vlan offload */
 };
 
+enum hns3_mbx_tbl_cfg_subcode {
+   HNS3_MBX_VPORT_LIST_CLEAR = 0,
+};
+
 #define HNS3_MBX_MAX_MSG_SIZE  16
 #define HNS3_MBX_MAX_RESP_DATA_SIZE8
 #define HNS3_MBX_RING_MAP_BASIC_MSG_NUM3
-- 
2.23.0

Re: [dpdk-dev] mbuf autotest fails with 19.11-rc3

[Jerin Jacob]

On Fri, Nov 22, 2019 at 6:52 PM Olivier Matz  wrote:
>
> Hi Jerin,

Hi Olivier,

>
> On Thu, Nov 21, 2019 at 12:24:24PM +, Jerin Jacob Kollanukkaran wrote:
> > mbuf autotest fails with 19.11-rc3
> >
> > $ echo "mbuf_autotest" | sudo ./build/app/test/dpdk-test -c 0x3
> >
> > EAL: Detected 56 lcore(s)
> > EAL: Detected 2 NUMA nodes
> > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> > EAL: Selected IOVA mode 'PA'
> > EAL: No available hugepages reported in hugepages-1048576kB
> > EAL: Probing VFIO support...
> > EAL: PCI device :01:00.0 on NUMA socket 0
> > EAL:   probe driver: 8086:1521 net_e1000_igb
> > EAL: PCI device :01:00.1 on NUMA socket 0
> > EAL:   probe driver: 8086:1521 net_e1000_igb
> > APP: HPET is not enabled, using TSC as default timer
> > RTE>>mbuf_autotest
> > Test mbuf dynamic fields and flags
> > Reserved fields:
> > Reserved flags:
> > Free space in mbuf (0 = free, value = zone alignment):
> >   : 00 00 00 00 00 00 00 00
> >   0008: 00 00 00 00 00 00 00 00
> >   0010: 00 00 00 00 00 00 00 00
> >   0018: 00 00 00 00 00 00 00 00
> >   0020: 00 00 00 00 00 00 00 00
> >   0028: 00 00 00 00 00 00 00 00
> >   0030: 00 00 00 00 00 00 00 00
> >   0038: 00 00 00 00 00 00 00 00
> >   0040: 00 00 00 00 00 00 00 00
> >   0048: 00 00 00 00 00 00 00 00
> >   0050: 00 00 00 00 00 00 00 00
> >   0058: 00 00 00 00 00 00 00 00
> >   0060: 00 00 00 00 00 00 00 00
> >   0068: 00 00 00 00 00 00 00 00
> >   0070: 10 10 10 10 10 10 10 10
> >   0078: 10 10 10 10 10 10 10 10
> > dynfield: offset=112, offset2=114, offset3=120
> > dynflag: flag=23, flag2=24, flag3=40
> > Reserved fields:
> >   name=test-dynfield offset=112 size=1 align=1 flags=0
> >   name=test-dynfield2 offset=114 size=2 align=2 flags=0
> >   name=test-dynfield3 offset=120 size=1 align=1 flags=0
> > Reserved flags:
> >   name=test-dynflag bitnum=23 flags=0
> >   name=test-dynflag2 bitnum=24 flags=0
> >   name=test-dynflag3 bitnum=40 flags=0
> > Free space in mbuf (0 = free, value = zone alignment):
> >   : 00 00 00 00 00 00 00 00
> >   0008: 00 00 00 00 00 00 00 00
> >   0010: 00 00 00 00 00 00 00 00
> >   0018: 00 00 00 00 00 00 00 00
> >   0020: 00 00 00 00 00 00 00 00
> >   0028: 00 00 00 00 00 00 00 00
> >   0030: 00 00 00 00 00 00 00 00
> >   0038: 00 00 00 00 00 00 00 00
> >   0040: 00 00 00 00 00 00 00 00
> >   0048: 00 00 00 00 00 00 00 00
> >   0050: 00 00 00 00 00 00 00 00
> >   0058: 00 00 00 00 00 00 00 00
> >   0060: 00 00 00 00 00 00 00 00
> >   0068: 00 00 00 00 00 00 00 00
> >   0070: 00 01 00 00 04 04 04 04
> >   0078: 00 01 02 02 04 04 04 04
> > cannot allocate mbuf pool
> > Test Failed
>
> Could you please share some details about your configuration?
> (amount of memory, arch, ...)

The QA reported this issue on an octeontx2 machine.
But when I tested on an x86 server it was reproducible(That above log
was with x86 server, 56 cores + 2 NUMA). So I thought
it is a generic issue(I did not spend any time debugging this). Now
debugged the failure on x86,
it was the case of low memory. I will debug more on the octeontx2 failure case.


>
> On my platform the test works, except if I use a very low amount
> of memory (few MBs).
>
> Thanks,
> Olivier

Re: [dpdk-dev] [PATCH v2] app/testpmd: reduce memory consumption

[Thomas Monjalon]

22/11/2019 13:24, Ferruh Yigit:
> On 11/22/2019 10:43 AM, David Marchand wrote:
> > diff --git a/devtools/test-null.sh b/devtools/test-null.sh
> > index 9f9a459f76..6e5b1ad529 100755
> > --- a/devtools/test-null.sh
> > +++ b/devtools/test-null.sh
> > @@ -25,6 +25,6 @@ else
> >  fi
> >  
> >  (sleep 1 && echo stop) |
> > -$testpmd -c $coremask --no-huge -m 150 \
> > +$testpmd -c $coremask --no-huge -m 20 \
> > $libs --vdev net_null1 --vdev net_null2 $eal_options -- \
> > --no-mlockall --total-num-mbufs=2048 $testpmd_options -ia
> 
> What do you think to separate this part, and go with first version of the 
> patchset?
> 
> And I am not sure if we should update at all, what is the benefit?

The benefit it to test that there is no anormal memory needs.

> Also script fails after update, because of the additional physical devices and
> their memory requirement, it is possible to make it run with additional 
> testpmd
> argument but fails by default.

This test is supposed to be for null devices only.
Why are you trying to add physical devices?
Oh wait, we miss an option -w 0 to be in whitelist mode?

Re: [dpdk-dev] [PATCH v2] app/testpmd: reduce memory consumption

[Ferruh Yigit]

On 11/22/2019 1:12 PM, Thomas Monjalon wrote:
> 22/11/2019 13:24, Ferruh Yigit:
>> On 11/22/2019 10:43 AM, David Marchand wrote:
>>> diff --git a/devtools/test-null.sh b/devtools/test-null.sh
>>> index 9f9a459f76..6e5b1ad529 100755
>>> --- a/devtools/test-null.sh
>>> +++ b/devtools/test-null.sh
>>> @@ -25,6 +25,6 @@ else
>>>  fi
>>>  
>>>  (sleep 1 && echo stop) |
>>> -$testpmd -c $coremask --no-huge -m 150 \
>>> +$testpmd -c $coremask --no-huge -m 20 \
>>> $libs --vdev net_null1 --vdev net_null2 $eal_options -- \
>>> --no-mlockall --total-num-mbufs=2048 $testpmd_options -ia
>>
>> What do you think to separate this part, and go with first version of the 
>> patchset?
>>
>> And I am not sure if we should update at all, what is the benefit?

Fair enough.

> 
> The benefit it to test that there is no anormal memory needs.
> 
>> Also script fails after update, because of the additional physical devices 
>> and
>> their memory requirement, it is possible to make it run with additional 
>> testpmd
>> argument but fails by default.
> 
> This test is supposed to be for null devices only.
> Why are you trying to add physical devices?
> Oh wait, we miss an option -w 0 to be in whitelist mode?
> 
I am not trying to add physical devices, they are already there in my
environment, yes adding "-w" can solve it.

Re: [dpdk-dev] [PATCH v2 3/3] ethdev: improve flow mark Rx offload deprecation notice

[Jerin Jacob]

On Fri, Nov 22, 2019 at 8:54 PM Andrew Rybchenko
 wrote:
>
> On 11/22/19 2:15 PM, Thomas Monjalon wrote:
> > 22/11/2019 11:12, Andrew Rybchenko:
> >> On 11/22/19 1:01 AM, Thomas Monjalon wrote:
> >>> 19/11/2019 13:12, Andrew Rybchenko:
>  The deprecation notice is required since it adds more requirements
>  when RTE flow mark and flag actions may be used and require
>  changes in applications.
> >>> I am still not sure what is the best solution here.
> >>> I continued to think about it in this thread:
> >>> http://mails.dpdk.org/archives/dev/2019-November/151960.html
> >>>
> >>> I think we cannot require any application change until 20.11
> >>> in order to keep API (and behaviour) compatibility.
> >> Expected, but still very disappointing.
> >>
> >> The feature is implemented by Pavan (@ Marvell), supported by me,
> >> used by Qi (@ Intel), looks better than alternatives from application
> >> developer point of view [1] and finally postponed for 1 year without really
> >> strong motivation.
> > I see different valuable point of views. This is enough motivation.
>
> It looks like I miss it in previous discussion, I would be thankful if
> you give me links to read or hints how to find.
>
> > And no, it is not postponed by one year.
> > Next release can implement a new API.
> >
> >> I disagree that it is tightly related to moving
> >> mark/flag to
> >> dynamic field/flag and absolutely blocked by it. Yes, I know that the are
> >> concerns from the very beginning, but the problem is explained [2] and 
> >> clear
> >> and no full-featured alternative solution is suggested. Solution suggested
> >> by Ori has many significant drawbacks as explained in [2] and highlighted
> >> in further discussion.
> > I disagree with working only on mark action while there are a lot
> > of other configs which have to be implemented in drivers.
> >
> > The reality is that some drivers decided to have some "optimizations"
> > disabling some features, and you want the application to opt-in
> > in order to allow your optimized paths.
>
> Strictly speaking it is not about driver optimized paths only, but HW
> configuration as well which can be done on start-up only (not dynamic) and
> could be per-queue in fact.
>
> > Note that opt-in is different of really enabling an offload.
> > For some basic port-level features like RSS hash,
> > it is enabled with an offload flag before starting the port,
> > acting as an opt-in.
>
> Could you highlight the difference between opt-in and offload.
> What is the key difference which makes one solution better
> than another? Why different mechanism is required?
>
> > Some features have some dedicated API, which may be enabled after
> > starting the port, and no way to opt-in (or opt-out) before start.
>
> It sounds like you have examples in your mind. Please, share.
>
> > A lot of features are using rte_flow API which is in this situation.
> > If we take the opt-in path, let's not do it only for the mark action,
> > but let's create a real API for it:
> >   rte_eth_dev_optin()
> >   rte_eth_dev_optinall()
> >   rte_eth_dev_optoutl()
>
> Introducing new types of controls would make configuration more and
> more complex. I think that many different types of control would
> over-complicate it. May be it is unavoidable, but it should be clear

I agree with Andrew here.
Another thing to consider is the behavior of pre rte_eth_dev_opt*()
API after reconfigure.
Does application needs to call these API again after the reconfigure to bring
back the old state prior to reconfiguring?


> why the problem cannot be solved using existing types of controls
> (e.g. offloads).

Re: [dpdk-dev] [PATCH] net/mlx5: fix validation of drop action

[Kevin Traynor]

Hi Dekel,

On 15/08/2019 10:26, Dekel Peled wrote:
> Function mlx5_flow_validate_action_drop() checks if another fate
> action is already present in this flow rule, using
> defined value MLX5_FLOW_FATE_ACTIONS.
> This patch enhances the check using value
> (MLX5_FLOW_FATE_ACTIONS | MLX5_FLOW_FATE_ESWITCH_ACTIONS)
> to make sure all relevant fate actions are checked.
> 
> Fixes: 23c1d42c7138 ("net/mlx5: split flow validation to dedicated function")

MLX5_FLOW_FATE_ESWITCH_ACTIONS is not available and causes build error
for 18.11. I think correct fixes tag is,
Fixes: 2e4c987aad91 ("net/mlx5: validate Direct Rule E-Switch")

which is not part of 18.11 stable. Will drop patch from 18.11 stable.
Let me know if there is something else needed.

thanks,
Kevin.

> Cc: sta...@dpdk.org
> 
> Signed-off-by: Dekel Peled 
> ---
>  drivers/net/mlx5/mlx5_flow.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index 9d2c8c9..2356c14 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -809,7 +809,8 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev 
> *dev, int32_t priority,
>   return rte_flow_error_set(error, EINVAL,
> RTE_FLOW_ERROR_TYPE_ACTION, NULL,
> "can't drop and mark in same flow");
> - if (action_flags & MLX5_FLOW_FATE_ACTIONS)
> + if (action_flags & (MLX5_FLOW_FATE_ACTIONS |
> + MLX5_FLOW_FATE_ESWITCH_ACTIONS))
>   return rte_flow_error_set(error, EINVAL,
> RTE_FLOW_ERROR_TYPE_ACTION, NULL,
> "can't have 2 fate actions in"
> 

[dpdk-dev] [PATCH] devtools: disable automatic probing in null testing

[Thomas Monjalon]

The script test-null.sh is supposed to do a quick and simple
run of testpmd with null PMD only, for sanity check.
As it is not supposed to test probing of any other PMD,
physical device probing is switched to whitelist mode
by using a fake PCI address (0:0.0).
It will also help to keep memory usage stable across platforms.

Signed-off-by: Thomas Monjalon 
---
 devtools/test-null.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/devtools/test-null.sh b/devtools/test-null.sh
index 9f9a459f76..d82c6ad193 100755
--- a/devtools/test-null.sh
+++ b/devtools/test-null.sh
@@ -26,5 +26,5 @@ fi
 
 (sleep 1 && echo stop) |
 $testpmd -c $coremask --no-huge -m 150 \
-   $libs --vdev net_null1 --vdev net_null2 $eal_options -- \
+   $libs -w 0:0.0 --vdev net_null1 --vdev net_null2 $eal_options -- \
--no-mlockall --total-num-mbufs=2048 $testpmd_options -ia
-- 
2.23.0

Re: [dpdk-dev] [PATCH] devtools: disable automatic probing in null testing

[Ferruh Yigit]

On 11/22/2019 1:48 PM, Thomas Monjalon wrote:
> The script test-null.sh is supposed to do a quick and simple
> run of testpmd with null PMD only, for sanity check.
> As it is not supposed to test probing of any other PMD,
> physical device probing is switched to whitelist mode
> by using a fake PCI address (0:0.0).
> It will also help to keep memory usage stable across platforms.
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  devtools/test-null.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/devtools/test-null.sh b/devtools/test-null.sh
> index 9f9a459f76..d82c6ad193 100755
> --- a/devtools/test-null.sh
> +++ b/devtools/test-null.sh
> @@ -26,5 +26,5 @@ fi
>  
>  (sleep 1 && echo stop) |
>  $testpmd -c $coremask --no-huge -m 150 \
> - $libs --vdev net_null1 --vdev net_null2 $eal_options -- \
> + $libs -w 0:0.0 --vdev net_null1 --vdev net_null2 $eal_options -- \
>   --no-mlockall --total-num-mbufs=2048 $testpmd_options -ia
> 

Tested-by: Ferruh Yigit 

Re: [dpdk-dev] [PATCH] devtools: disable automatic probing in null testing

[Gaëtan Rivet]

Hi Thomas,

On Fri, Nov 22, 2019 at 02:48:08PM +0100, Thomas Monjalon wrote:
> The script test-null.sh is supposed to do a quick and simple
> run of testpmd with null PMD only, for sanity check.
> As it is not supposed to test probing of any other PMD,
> physical device probing is switched to whitelist mode
> by using a fake PCI address (0:0.0).
> It will also help to keep memory usage stable across platforms.
> 

With https://patchwork.dpdk.org/patch/62014/, --manual-probe could be
used as a more standard way of workarounding the PCI bus.

This is a common issue, we should have cleaner way of addressing it than
using hacks relying on the PCI bus not panicking up upon finding an
inexistant address. Which is a questionable behavior, users should not
be encouraged to rely on it.

> Signed-off-by: Thomas Monjalon 
> ---
>  devtools/test-null.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/devtools/test-null.sh b/devtools/test-null.sh
> index 9f9a459f76..d82c6ad193 100755
> --- a/devtools/test-null.sh
> +++ b/devtools/test-null.sh
> @@ -26,5 +26,5 @@ fi
>  
>  (sleep 1 && echo stop) |
>  $testpmd -c $coremask --no-huge -m 150 \
> - $libs --vdev net_null1 --vdev net_null2 $eal_options -- \
> + $libs -w 0:0.0 --vdev net_null1 --vdev net_null2 $eal_options -- \
>   --no-mlockall --total-num-mbufs=2048 $testpmd_options -ia
> -- 
> 2.23.0
> 

-- 
Gaëtan Rivet
6WIND

Re: [dpdk-dev] [PATCH v2] app/testpmd: reduce memory consumption

[Ferruh Yigit]

On 11/22/2019 10:43 AM, David Marchand wrote:
> Following [1], testpmd memory consumption has skyrocketted.
> The rte_port structure has gotten quite fat.
> 
> struct rte_port {
> [...]
>   struct rte_eth_rxconf rx_conf[65536];/* 266280 3145728 */
>   /* --- cacheline 53312 boundary (3411968 bytes) was 40 bytes ago --- */
>   struct rte_eth_txconf tx_conf[65536];/* 3412008 3670016 */
>   /* --- cacheline 110656 boundary (7081984 bytes) was 40 bytes ago --- */
> [...]
>   /* size: 8654936, cachelines: 135234, members: 31 */
> [...]
> 
> testpmd handles RTE_MAX_ETHPORTS ports (32 by default) which means that it
> needs ~256MB just for this internal representation.
> 
> The reason is that a testpmd rte_port (the name is quite confusing, as
> it is a local type) maintains configurations for all queues of a port.
> But where you would expect testpmd to use RTE_MAX_QUEUES_PER_PORT as the
> maximum queue count, the rte_port uses MAX_QUEUE_ID set to 64k.
> 
> Prefer the ethdev maximum value.
> 
> After this patch:
> struct rte_port {
> [...]
>   struct rte_eth_rxconf  rx_conf[1025];/*  8240 49200 */
>   /* --- cacheline 897 boundary (57408 bytes) was 32 bytes ago --- */
>   struct rte_eth_txconf  tx_conf[1025];/* 57440 57400 */
>   /* --- cacheline 1794 boundary (114816 bytes) was 24 bytes ago --- */
> [...]
>   /* size: 139488, cachelines: 2180, members: 31 */
> [...]
> 
> With this, we can ask for less memory in test-null.sh.
> 
> [1]: https://git.dpdk.org/dpdk/commit/?id=436b3a6b6e62
> 
> Signed-off-by: David Marchand 
> Acked-by: Ferruh Yigit 
> Acked-by: Thomas Monjalon 

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

[dpdk-dev] [PATCH 6/6] net/hns3: fix duplicate VLAN

[Wei Hu (Xavier)]

From: "Min Hu (Connor)" 

When setting duplicate vlan, hns3 driver will also add vlan entry
to vlan linked list, and this is unreasonable.

This patch adds checking whether the VLAN to be added already exists
in the linked list and preventing adding duplicate vlan.

Fixes: 411d23b9eafb ("net/hns3: support VLAN")
Cc: sta...@dpdk.org

Signed-off-by: Min Hu (Connor) 
Signed-off-by: Wei Hu (Xavier) 
---
 drivers/net/hns3/hns3_ethdev.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 3435bce26..72315718a 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -282,6 +282,11 @@ hns3_add_dev_vlan_table(struct hns3_adapter *hns, uint16_t 
vlan_id,
struct hns3_hw *hw = &hns->hw;
struct hns3_pf *pf = &hns->pf;
 
+   LIST_FOREACH(vlan_entry, &pf->vlan_list, next) {
+   if (vlan_entry->vlan_id == vlan_id)
+   return;
+   }
+
vlan_entry = rte_zmalloc("hns3_vlan_tbl", sizeof(*vlan_entry), 0);
if (vlan_entry == NULL) {
hns3_err(hw, "Failed to malloc hns3 vlan table");
-- 
2.23.0

[dpdk-dev] [PATCH 0/6] Fixes for hns3 PMD driver

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

This series add some fixes for hns3 PMD driver.

Chengchang Tang (1):
  net/hns3: fix the error length limit of maiblox response

Hao Chen (1):
  net/hns3: fix RSS hardware configuration restore failure

Huisong Li (1):
  net/hns3: fix the strategy of getting link status for VF

Min Hu (Connor) (1):
  net/hns3: fix duplicate VLAN

Wei Hu (Xavier) (2):
  net/hns3: fix VF configuration table entries restore failure
  net/hns3: fix the failure sending packets less than 60 bytes

 drivers/net/hns3/hns3_ethdev.c|  5 +
 drivers/net/hns3/hns3_ethdev.h|  1 +
 drivers/net/hns3/hns3_ethdev_vf.c | 22 +-
 drivers/net/hns3/hns3_mbx.c   |  4 +---
 drivers/net/hns3/hns3_mbx.h   |  6 ++
 drivers/net/hns3/hns3_rss.c   |  4 +---
 drivers/net/hns3/hns3_rxtx.c  | 24 
 7 files changed, 51 insertions(+), 15 deletions(-)

-- 
2.23.0

[dpdk-dev] [PATCH 5/6] net/hns3: fix the strategy of getting link status for VF

[Wei Hu (Xavier)]

From: Huisong Li 

Currently, port link status is "up" in VF driver after user calling the
rte_eth_dev_stop API. This is unreasonable.

Therefore, this patch adjusts the strategy of getting link status from
PF driver for VF. VF drvier should stop getting link status from PF by
canceling the alarm that VF driver send mailbox message to PF driver,
when the rte_eth_dev_stop API is called. And VF driver should restore
the alarm when the rte_eth_dev_start API is called.

Fixes: a5475d61fa34 ("net/hns3: support VF")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Wei Hu (Xavier) 
---
 drivers/net/hns3/hns3_ethdev_vf.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/hns3/hns3_ethdev_vf.c 
b/drivers/net/hns3/hns3_ethdev_vf.c
index 2274ac35e..b1736e73a 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -1246,6 +1246,7 @@ hns3vf_dev_stop(struct rte_eth_dev *eth_dev)
hns3_dev_release_mbufs(hns);
hw->adapter_state = HNS3_NIC_CONFIGURED;
}
+   rte_eal_alarm_cancel(hns3vf_service_handler, eth_dev);
rte_spinlock_unlock(&hw->lock);
 }
 
@@ -1265,7 +1266,6 @@ hns3vf_dev_close(struct rte_eth_dev *eth_dev)
hns3_reset_abort(hns);
hw->adapter_state = HNS3_NIC_CLOSED;
rte_eal_alarm_cancel(hns3vf_keep_alive_handler, eth_dev);
-   rte_eal_alarm_cancel(hns3vf_service_handler, eth_dev);
hns3vf_configure_all_mc_mac_addr(hns, true);
hns3vf_remove_all_vlan_table(hns);
hns3vf_uninit_vf(eth_dev);
@@ -1286,8 +1286,6 @@ hns3vf_dev_link_update(struct rte_eth_dev *eth_dev,
struct hns3_mac *mac = &hw->mac;
struct rte_eth_link new_link;
 
-   hns3vf_request_link_info(hw);
-
memset(&new_link, 0, sizeof(new_link));
switch (mac->link_speed) {
case ETH_SPEED_NUM_10M:
@@ -1352,6 +1350,8 @@ hns3vf_dev_start(struct rte_eth_dev *eth_dev)
rte_spinlock_unlock(&hw->lock);
hns3_set_rxtx_function(eth_dev);
hns3_mp_req_start_rxtx(eth_dev);
+   rte_eal_alarm_set(HNS3VF_SERVICE_INTERVAL, hns3vf_service_handler,
+ eth_dev);
return 0;
 }
 
@@ -1789,8 +1789,6 @@ hns3vf_dev_init(struct rte_eth_dev *eth_dev)
}
rte_eal_alarm_set(HNS3VF_KEEP_ALIVE_INTERVAL, hns3vf_keep_alive_handler,
  eth_dev);
-   rte_eal_alarm_set(HNS3VF_SERVICE_INTERVAL, hns3vf_service_handler,
- eth_dev);
return 0;
 
 err_rte_zmalloc:
-- 
2.23.0

[dpdk-dev] [PATCH 2/6] net/hns3: fix VF configuration table entries restore failure

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

When the application using VF device exits abnormally, for example,
when it is killed by 'kill -9', kernel PF netdev driver also stores
the corresponding configuration table entries of VF device.

This patch fixes it by adding message of deleting VF configuration
table entry corresponds to the revision of kernel hns3 netdev
driver, the new message is added to notify the kernel PF netdev
driver to clean up the VF configuration initialization during VF
initialization.

This revision is compatible with the old version of kernel hns3
netdev driver. The old version of kernel pf netdev driver will
ignore this message.

Fixes: a5475d61fa34 ("net/hns3: support VF")
Cc: sta...@dpdk.org

Signed-off-by: Hongbo Zheng 
Signed-off-by: Wei Hu (Xavier) 
---
 drivers/net/hns3/hns3_ethdev_vf.c | 14 ++
 drivers/net/hns3/hns3_mbx.h   |  6 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/net/hns3/hns3_ethdev_vf.c 
b/drivers/net/hns3/hns3_ethdev_vf.c
index 403674969..2274ac35e 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -1096,6 +1096,14 @@ hns3vf_init_hardware(struct hns3_adapter *hns)
return ret;
 }
 
+static int
+hns3vf_clear_vport_list(struct hns3_hw *hw)
+{
+   return hns3_send_mbx_msg(hw, HNS3_MBX_HANDLE_VF_TBL,
+HNS3_MBX_VPORT_LIST_CLEAR, NULL, 0, false,
+NULL, 0);
+}
+
 static int
 hns3vf_init_vf(struct rte_eth_dev *eth_dev)
 {
@@ -1147,6 +1155,12 @@ hns3vf_init_vf(struct rte_eth_dev *eth_dev)
 
rte_eth_random_addr(hw->mac.mac_addr); /* Generate a random mac addr */
 
+   ret = hns3vf_clear_vport_list(hw);
+   if (ret) {
+   PMD_INIT_LOG(ERR, "Failed to clear tbl list: %d", ret);
+   goto err_get_config;
+   }
+
ret = hns3vf_init_hardware(hns);
if (ret)
goto err_get_config;
diff --git a/drivers/net/hns3/hns3_mbx.h b/drivers/net/hns3/hns3_mbx.h
index ee6e82314..01eddb845 100644
--- a/drivers/net/hns3/hns3_mbx.h
+++ b/drivers/net/hns3/hns3_mbx.h
@@ -39,6 +39,8 @@ enum HNS3_MBX_OPCODE {
HNS3_MBX_SET_ALIVE, /* (VF -> PF) set alive state */
HNS3_MBX_SET_MTU,   /* (VF -> PF) set mtu */
HNS3_MBX_GET_QID_IN_PF, /* (VF -> PF) get queue id in pf */
+
+   HNS3_MBX_HANDLE_VF_TBL = 38,/* (VF -> PF) store/clear hw cfg tbl */
 };
 
 /* below are per-VF mac-vlan subcodes */
@@ -58,6 +60,10 @@ enum hns3_mbx_vlan_cfg_subcode {
HNS3_MBX_VLAN_RX_OFF_CFG,   /* set rx side vlan offload */
 };
 
+enum hns3_mbx_tbl_cfg_subcode {
+   HNS3_MBX_VPORT_LIST_CLEAR = 0,
+};
+
 #define HNS3_MBX_MAX_MSG_SIZE  16
 #define HNS3_MBX_MAX_RESP_DATA_SIZE8
 #define HNS3_MBX_RING_MAP_BASIC_MSG_NUM3
-- 
2.23.0

[dpdk-dev] [PATCH 1/6] net/hns3: fix RSS hardware configuration restore failure

[Wei Hu (Xavier)]

From: Hao Chen 

This patch fixes the bug that hardware configuration called
tc_size doesn't restore to the initial value when starting
the app, configuring PFC and then restarting the app,
because of the tc_mode didn't initial when rss is disabled.

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: sta...@dpdk.org

Signed-off-by: Hao Chen 
Signed-off-by: Wei Hu (Xavier) 
---
 drivers/net/hns3/hns3_rss.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/hns3/hns3_rss.c b/drivers/net/hns3/hns3_rss.c
index 6a5d63398..b8c20e6d9 100644
--- a/drivers/net/hns3/hns3_rss.c
+++ b/drivers/net/hns3/hns3_rss.c
@@ -525,10 +525,8 @@ hns3_config_rss(struct hns3_adapter *hns)
enum rte_eth_rx_mq_mode mq_mode = hw->data->dev_conf.rxmode.mq_mode;
 
/* When there is no open RSS, redirect the packet queue 0 */
-   if (((uint32_t)mq_mode & ETH_MQ_RX_RSS_FLAG) == 0) {
+   if (((uint32_t)mq_mode & ETH_MQ_RX_RSS_FLAG) == 0)
hns3_rss_uninit(hns);
-   return 0;
-   }
 
/* Configure RSS hash algorithm and hash key offset */
ret = hns3_set_rss_algo_key(hw, hash_algo, hash_key);
-- 
2.23.0

[dpdk-dev] [PATCH 3/6] net/hns3: fix the failure sending packets less than 60 bytes

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

Ethernet minimum packet length is 64 bytes. If upper application
sends packets with less than 60 bytes in length(no CRC), driver
adds padding processing to avoid failure.

Fixes: bba636698316 ("net/hns3: support Rx/Tx and related operations")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Wei Hu (Xavier) 
---
 drivers/net/hns3/hns3_ethdev.h |  1 +
 drivers/net/hns3/hns3_rxtx.c   | 24 
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index 9710e45fb..e9a3fe410 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -43,6 +43,7 @@
 #define HNS3_MAX_MTU   (HNS3_MAX_FRAME_LEN - HNS3_ETH_OVERHEAD)
 #define HNS3_DEFAULT_MTU   1500UL
 #define HNS3_DEFAULT_FRAME_LEN (HNS3_DEFAULT_MTU + HNS3_ETH_OVERHEAD)
+#define HNS3_MIN_PKT_SIZE  60
 
 #define HNS3_4_TCS 4
 #define HNS3_8_TCS 8
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 1de238b4c..34cb7faf9 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -1598,13 +1598,29 @@ hns3_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts, uint16_t nb_pkts)
}
 
/*
-* If the length of the packet is too long or zero, the packet
-* will be ignored.
+* If packet length is greater than HNS3_MAX_FRAME_LEN
+* driver support, the packet will be ignored.
 */
-   if (unlikely(tx_pkt->pkt_len > HNS3_MAX_FRAME_LEN ||
-tx_pkt->pkt_len == 0))
+   if (unlikely(rte_pktmbuf_pkt_len(tx_pkt) > HNS3_MAX_FRAME_LEN))
break;
 
+   /*
+* If packet length is less than minimum packet size, driver
+* need to pad it.
+*/
+   if (unlikely(rte_pktmbuf_pkt_len(tx_pkt) < HNS3_MIN_PKT_SIZE)) {
+   uint16_t add_len;
+   char *appended;
+
+   add_len = HNS3_MIN_PKT_SIZE -
+rte_pktmbuf_pkt_len(tx_pkt);
+   appended = rte_pktmbuf_append(tx_pkt, add_len);
+   if (appended == NULL)
+   break;
+
+   memset(appended, 0, add_len);
+   }
+
m_seg = tx_pkt;
if (unlikely(nb_buf > HNS3_MAX_TX_BD_PER_PKT)) {
if (hns3_reassemble_tx_pkts(txq, tx_pkt, &new_pkt))
-- 
2.23.0

[dpdk-dev] [PATCH 4/6] net/hns3: fix the error length limit of maiblox response

[Wei Hu (Xavier)]

From: Chengchang Tang 

This patch removes the macro 'HNS3_REG_MSG_DATA_OFFSET' which is used to
prevent the array from accessing violation and it limits the response data
length to be 4. but the limit value is too short to get some longer
information such as 6 byte MAC address.

This patch modify the length of response data from mailbox to allows the
response data length to be 8. So that the VF driver could get more data
from PF drvier by mailbox.

Fixes: 463e748964f5 ("net/hns3: support mailbox")
Cc: sta...@dpdk.org

Signed-off-by: Chengchang Tang 
Signed-off-by: Wei Hu (Xavier) 
---
 drivers/net/hns3/hns3_mbx.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
index 2bfd97415..c1647af4b 100644
--- a/drivers/net/hns3/hns3_mbx.c
+++ b/drivers/net/hns3/hns3_mbx.c
@@ -24,7 +24,6 @@
 #include "hns3_logs.h"
 #include "hns3_intr.h"
 
-#define HNS3_REG_MSG_DATA_OFFSET   4
 #define HNS3_CMD_CODE_OFFSET   2
 
 static const struct errno_respcode_map err_code_map[] = {
@@ -320,8 +319,7 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
resp->resp_status = hns3_resp_to_errno(req->msg[3]);
 
temp = (uint8_t *)&req->msg[4];
-   for (i = 0; i < HNS3_MBX_MAX_RESP_DATA_SIZE &&
-i < HNS3_REG_MSG_DATA_OFFSET; i++) {
+   for (i = 0; i < HNS3_MBX_MAX_RESP_DATA_SIZE; i++) {
resp->additional_info[i] = *temp;
temp++;
}
-- 
2.23.0

Re: [dpdk-dev] [PATCH] doc: update qede PMD guide

[Ferruh Yigit]

On 11/22/2019 7:51 AM, Rasesh Mody wrote:
>  - Add note for Co-existence of DPDK and Linux drivers.
>  - Update the firmware version in example.
>  - Add Config note for potential error due to lack of memzone desciptor
>count.
> 
> Signed-off-by: Rasesh Mody 
> ---
>  doc/guides/nics/qede.rst | 25 -
>  1 file changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
> index 2f4045795..9c14dd006 100644
> --- a/doc/guides/nics/qede.rst
> +++ b/doc/guides/nics/qede.rst
> @@ -70,6 +70,10 @@ Co-existence considerations
>to the PFs of a given adapter and either qede PMD or Linux drivers
>(qed and qede) can be bound to the VFs of the adapter.
>  
> +- To use DPDK on some PFs and Linux drivers on other PFs of an adapter,
> +  create a VF each on the PFs where DPDK will be used, attach DPDK to
> +  these VFs and Linux drivers to the other PFs where no VFs are created.

But this won't be using DPDK on some PFs, you are indeed suggesting to create
VFs and use them via DPDK instead. And should the PF not bound to any kernel 
driver?

Re: [dpdk-dev] [PATCH] devtools: disable automatic probing in null testing

[Thomas Monjalon]

22/11/2019 15:03, Gaëtan Rivet:
> Hi Thomas,
> 
> On Fri, Nov 22, 2019 at 02:48:08PM +0100, Thomas Monjalon wrote:
> > The script test-null.sh is supposed to do a quick and simple
> > run of testpmd with null PMD only, for sanity check.
> > As it is not supposed to test probing of any other PMD,
> > physical device probing is switched to whitelist mode
> > by using a fake PCI address (0:0.0).
> > It will also help to keep memory usage stable across platforms.
> > 
> 
> With https://patchwork.dpdk.org/patch/62014/, --manual-probe could be
> used as a more standard way of workarounding the PCI bus.

I really would like we have a better bus API before
implementing some new command line options.
Command line options should be optional and considered only helpers
for internal applications.
Anyway it is another discussion, and I hope I will have time and courage
to participate in such rework soon.

> This is a common issue, we should have cleaner way of addressing it than
> using hacks relying on the PCI bus not panicking up upon finding an
> inexistant address. Which is a questionable behavior, users should not
> be encouraged to rely on it.

Yes

Re: [dpdk-dev] [dpdk-users] What is the 'unit of timestamp' assigned to mbuf packet in DPDK?

[Ferruh Yigit]

On 11/18/2019 2:29 PM, Gokul Bargaje wrote:
> Hi,
> 
> The timestamp assigned to packet at the time of enqueue (value of timestamp
> field in mbuf), is it in milliseconds or microseconds or in cpu cycles?

The unit is not defined [1]. 'rte_eth_read_clock()' was added [2] to help
converting it to time when it is clock counter.

[1]
918ae9dc775e ("mbuf: add a timestamp field")

[2]
5e741377657c ("ethdev: add API to read device clock")

> 
> How this timestamp is calculated? Is it calculated using the *rte_cycles.h*?
> 

[dpdk-dev] [PATCH v2] hash: added a new API to hash to query key id

[Kumar Amber]

Adding new API function to query the maximum key ID
that could possibly returned by add_key_functions. When
multi_key_add flag set, the maximum key id is larger
than the entry count specified by the user.

Signed-off-by: Kumar Amber 
---
 lib/librte_hash/rte_cuckoo_hash.c| 15 +++
 lib/librte_hash/rte_hash.h   | 25 +++--
 lib/librte_hash/rte_hash_version.map |  1 +
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/lib/librte_hash/rte_cuckoo_hash.c 
b/lib/librte_hash/rte_cuckoo_hash.c
index 87a4c01f2..3a94f10b8 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -506,6 +506,21 @@ rte_hash_hash(const struct rte_hash *h, const void *key)
return h->hash_func(key, h->key_len, h->hash_func_init_val);
 }
 
+uint32_t
+rte_hash_max_key_id(const struct rte_hash *h)
+{
+   RETURN_IF_TRUE((h == NULL), -EINVAL);
+   if (h->use_local_cache)
+   /*
+* Increase number of slots by total number of indices
+* that can be stored in the lcore caches
+*/
+   return (h->entries + ((RTE_MAX_LCORE - 1) *
+   (LCORE_CACHE_SIZE - 1)));
+   else
+   return h->entries;
+}
+
 int32_t
 rte_hash_count(const struct rte_hash *h)
 {
diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
index 0d73370dc..c87861e72 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -164,6 +164,23 @@ rte_hash_reset(struct rte_hash *h);
 int32_t
 rte_hash_count(const struct rte_hash *h);
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Return  the maximum key value ID that could possibly be returned by
+ * rte_hash_add_key function.
+ *
+ * @param h
+ *  Hash table to query from
+ * @return
+ *   - -EINVAL if parameters are invalid
+ *   - A value indicating the max key Id  key slots present in the table.
+ */
+__rte_experimental
+uint32_t
+rte_hash_max_key_id(const struct rte_hash *h);
+
 /**
  * Add a key-value pair to an existing hash table.
  * This operation is not multi-thread safe
@@ -234,7 +251,9 @@ rte_hash_add_key_with_hash_data(const struct rte_hash *h, 
const void *key,
  *   - -EINVAL if the parameters are invalid.
  *   - -ENOSPC if there is no space in the hash for this key.
  *   - A positive value that can be used by the caller as an offset into an
- * array of user data. This value is unique for this key.
+ * array of user data. This value is unique for this key. This
+ * unique key id may be larger than the user specified entry count
+ * when RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD flag is set.
  */
 int32_t
 rte_hash_add_key(const struct rte_hash *h, const void *key);
@@ -256,7 +275,9 @@ rte_hash_add_key(const struct rte_hash *h, const void *key);
  *   - -EINVAL if the parameters are invalid.
  *   - -ENOSPC if there is no space in the hash for this key.
  *   - A positive value that can be used by the caller as an offset into an
- * array of user data. This value is unique for this key.
+ * array of user data. This value is unique for this key. This
+ * unique key ID may be larger than the user specified entry count
+ * when RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD flag is set.
  */
 int32_t
 rte_hash_add_key_with_hash(const struct rte_hash *h, const void *key, 
hash_sig_t sig);
diff --git a/lib/librte_hash/rte_hash_version.map 
b/lib/librte_hash/rte_hash_version.map
index 734ae28b0..562ceb8bc 100644
--- a/lib/librte_hash/rte_hash_version.map
+++ b/lib/librte_hash/rte_hash_version.map
@@ -58,5 +58,6 @@ EXPERIMENTAL {
global:
 
rte_hash_free_key_with_position;
+rte_hash_max_key_id;
 
 };
-- 
2.17.1

Re: [dpdk-dev] Backporting rte_intr_ack

[Kevin Traynor]

On 19/11/2019 10:40, Thomas Monjalon wrote:
> 14/10/2019 17:55, David Marchand:
>> The api rte_intr_ack that has been introduced to fix a race condition
>> observed with (at least) qede drivers/hw.
>> This is an experimental api in master but it still fixes a problem, so
>> I'd like to see this in stable branches.
> 
> This is more a driver interface than an API.
> 
>> Opinions?
> 
> If it comes with a fix in a driver, I think it is worth backporting.
> 
> 

I think fine to backport as it solves an observed problem for qede.
However, a bit reluctant to update all the drivers to use it without
acks from their maintainers.

Discussed with David offline and idea to backport and only update qede
now. Other drivers can be updated if there is a request from
maintainers. How does it sound?

Re: [dpdk-dev] Backporting rte_intr_ack

[Thomas Monjalon]

22/11/2019 16:12, Kevin Traynor:
> On 19/11/2019 10:40, Thomas Monjalon wrote:
> > 14/10/2019 17:55, David Marchand:
> >> The api rte_intr_ack that has been introduced to fix a race condition
> >> observed with (at least) qede drivers/hw.
> >> This is an experimental api in master but it still fixes a problem, so
> >> I'd like to see this in stable branches.
> > 
> > This is more a driver interface than an API.
> > 
> >> Opinions?
> > 
> > If it comes with a fix in a driver, I think it is worth backporting.
> > 
> > 
> 
> I think fine to backport as it solves an observed problem for qede.
> However, a bit reluctant to update all the drivers to use it without
> acks from their maintainers.
> 
> Discussed with David offline and idea to backport and only update qede
> now. Other drivers can be updated if there is a request from
> maintainers. How does it sound?

It's better than nothing.
But it makes tracking of backports more difficult.
Is it a common practice to backport half of fixes?

Re: [dpdk-dev] [PATCH 2/6] net/hns3: fix VF configuration table entries restore failure

[Ferruh Yigit]

On 11/22/2019 12:06 PM, Wei Hu (Xavier) wrote:
> From: "Wei Hu (Xavier)" 
> 
> When the application using VF device exits abnormally, for example,
> when it is killed by 'kill -9', kernel PF netdev driver also stores
> the corresponding configuration table entries of VF device.
> 
> This patch fixes it by adding message of deleting VF configuration
> table entry corresponds to the revision of kernel hns3 netdev
> driver, the new message is added to notify the kernel PF netdev
> driver to clean up the VF configuration initialization during VF
> initialization.
> 
> This revision is compatible with the old version of kernel hns3
> netdev driver. The old version of kernel pf netdev driver will
> ignore this message.
> 
> Fixes: a5475d61fa34 ("net/hns3: support VF")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Hongbo Zheng 
> Signed-off-by: Wei Hu (Xavier) 

Hi Xavier,

We are trying the use unique identifier for same person as much as possible,
Above seems your personal email, I will update all occurrences as following, as
how git history knows you:
Wei Hu (Xavier) 

Please let us know if there is an objection/concern on this changes.

[dpdk-dev] [PATCH v3 3/5] event/octeontx2: improve chunk pool performance

[pbhagavatula]

From: Pavan Nikhilesh 

Enable mempool cache for internal mempool to improve alloc performance.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/event/octeontx2/otx2_tim_evdev.c  |  4 ++--
 drivers/event/octeontx2/otx2_tim_worker.h | 15 ++-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/event/octeontx2/otx2_tim_evdev.c 
b/drivers/event/octeontx2/otx2_tim_evdev.c
index e8316a6c7..206ed4331 100644
--- a/drivers/event/octeontx2/otx2_tim_evdev.c
+++ b/drivers/event/octeontx2/otx2_tim_evdev.c
@@ -124,6 +124,7 @@ tim_chnk_pool_create(struct otx2_tim_ring *tim_ring,
char pool_name[25];
int rc;
 
+   cache_sz /= rte_lcore_count();
/* Create chunk pool. */
if (rcfg->flags & RTE_EVENT_TIMER_ADAPTER_F_SP_PUT) {
mp_flags = MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET;
@@ -138,10 +139,9 @@ tim_chnk_pool_create(struct otx2_tim_ring *tim_ring,
cache_sz = RTE_MEMPOOL_CACHE_MAX_SIZE;
 
if (!tim_ring->disable_npa) {
-   /* NPA need not have cache as free is not visible to SW */
tim_ring->chunk_pool = rte_mempool_create_empty(pool_name,
tim_ring->nb_chunks, tim_ring->chunk_sz,
-   0, 0, rte_socket_id(), mp_flags);
+   cache_sz, 0, rte_socket_id(), mp_flags);
 
if (tim_ring->chunk_pool == NULL) {
otx2_err("Unable to create chunkpool.");
diff --git a/drivers/event/octeontx2/otx2_tim_worker.h 
b/drivers/event/octeontx2/otx2_tim_worker.h
index 7b771fbca..af2f864d7 100644
--- a/drivers/event/octeontx2/otx2_tim_worker.h
+++ b/drivers/event/octeontx2/otx2_tim_worker.h
@@ -144,8 +144,12 @@ static struct otx2_tim_ent *
 tim_clr_bkt(struct otx2_tim_ring * const tim_ring,
struct otx2_tim_bkt * const bkt)
 {
+#define TIM_MAX_OUTSTANDING_OBJ64
+   void *pend_chunks[TIM_MAX_OUTSTANDING_OBJ];
struct otx2_tim_ent *chunk;
struct otx2_tim_ent *pnext;
+   uint8_t objs = 0;
+
 
chunk = ((struct otx2_tim_ent *)(uintptr_t)bkt->first_chunk);
chunk = (struct otx2_tim_ent *)(uintptr_t)(chunk +
@@ -153,10 +157,19 @@ tim_clr_bkt(struct otx2_tim_ring * const tim_ring,
while (chunk) {
pnext = (struct otx2_tim_ent *)(uintptr_t)
((chunk + tim_ring->nb_chunk_slots)->w0);
-   rte_mempool_put(tim_ring->chunk_pool, chunk);
+   if (objs == TIM_MAX_OUTSTANDING_OBJ) {
+   rte_mempool_put_bulk(tim_ring->chunk_pool, pend_chunks,
+objs);
+   objs = 0;
+   }
+   pend_chunks[objs++] = chunk;
chunk = pnext;
}
 
+   if (objs)
+   rte_mempool_put_bulk(tim_ring->chunk_pool, pend_chunks,
+   objs);
+
return (struct otx2_tim_ent *)(uintptr_t)bkt->first_chunk;
 }
 
-- 
2.17.1

[dpdk-dev] [PATCH v3 4/5] event/octeontx2: update SSO buffers based on timer count

[pbhagavatula]

From: Pavan Nikhilesh 

Update SSO internal XAQ buffers based on number of timers in event timer
adapter.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/event/octeontx2/otx2_evdev.h   |  6 +-
 drivers/event/octeontx2/otx2_evdev_adptr.c | 84 +-
 drivers/event/octeontx2/otx2_tim_evdev.c   |  7 +-
 drivers/event/octeontx2/otx2_tim_evdev.h   |  1 +
 4 files changed, 74 insertions(+), 24 deletions(-)

diff --git a/drivers/event/octeontx2/otx2_evdev.h 
b/drivers/event/octeontx2/otx2_evdev.h
index 530060f81..231a12a52 100644
--- a/drivers/event/octeontx2/otx2_evdev.h
+++ b/drivers/event/octeontx2/otx2_evdev.h
@@ -14,6 +14,7 @@
 #include "otx2_dev.h"
 #include "otx2_ethdev.h"
 #include "otx2_mempool.h"
+#include "otx2_tim_evdev.h"
 
 #define EVENTDEV_NAME_OCTEONTX2_PMD otx2_eventdev
 
@@ -137,9 +138,12 @@ struct otx2_sso_evdev {
struct rte_mempool *xaq_pool;
uint64_t rx_offloads;
uint64_t tx_offloads;
+   uint64_t adptr_xae_cnt;
uint16_t rx_adptr_pool_cnt;
-   uint32_t adptr_xae_cnt;
uint64_t *rx_adptr_pools;
+   uint16_t tim_adptr_ring_cnt;
+   uint16_t *timer_adptr_rings;
+   uint64_t *timer_adptr_sz;
/* Dev args */
uint8_t dual_ws;
uint8_t selftest;
diff --git a/drivers/event/octeontx2/otx2_evdev_adptr.c 
b/drivers/event/octeontx2/otx2_evdev_adptr.c
index d8a06a593..233cba2aa 100644
--- a/drivers/event/octeontx2/otx2_evdev_adptr.c
+++ b/drivers/event/octeontx2/otx2_evdev_adptr.c
@@ -199,41 +199,87 @@ sso_rxq_disable(struct otx2_eth_dev *dev, uint16_t qid)
 void
 sso_updt_xae_cnt(struct otx2_sso_evdev *dev, void *data, uint32_t event_type)
 {
+   int i;
+
switch (event_type) {
case RTE_EVENT_TYPE_ETHDEV:
{
struct otx2_eth_rxq *rxq = data;
-   int i, match = false;
uint64_t *old_ptr;
 
for (i = 0; i < dev->rx_adptr_pool_cnt; i++) {
if ((uint64_t)rxq->pool == dev->rx_adptr_pools[i])
-   match = true;
-   }
-
-   if (!match) {
-   dev->rx_adptr_pool_cnt++;
-   old_ptr = dev->rx_adptr_pools;
-   dev->rx_adptr_pools = rte_realloc(dev->rx_adptr_pools,
- sizeof(uint64_t) *
- dev->rx_adptr_pool_cnt
- , 0);
-   if (dev->rx_adptr_pools == NULL) {
-   dev->adptr_xae_cnt += rxq->pool->size;
-   dev->rx_adptr_pools = old_ptr;
-   dev->rx_adptr_pool_cnt--;
return;
-   }
-   dev->rx_adptr_pools[dev->rx_adptr_pool_cnt - 1] =
-   (uint64_t)rxq->pool;
+   }
 
+   dev->rx_adptr_pool_cnt++;
+   old_ptr = dev->rx_adptr_pools;
+   dev->rx_adptr_pools = rte_realloc(dev->rx_adptr_pools,
+ sizeof(uint64_t) *
+ dev->rx_adptr_pool_cnt, 0);
+   if (dev->rx_adptr_pools == NULL) {
dev->adptr_xae_cnt += rxq->pool->size;
+   dev->rx_adptr_pools = old_ptr;
+   dev->rx_adptr_pool_cnt--;
+   return;
}
+   dev->rx_adptr_pools[dev->rx_adptr_pool_cnt - 1] =
+   (uint64_t)rxq->pool;
+
+   dev->adptr_xae_cnt += rxq->pool->size;
break;
}
case RTE_EVENT_TYPE_TIMER:
{
-   dev->adptr_xae_cnt += (*(uint64_t *)data);
+   struct otx2_tim_ring *timr = data;
+   uint16_t *old_ring_ptr;
+   uint64_t *old_sz_ptr;
+
+   for (i = 0; i < dev->tim_adptr_ring_cnt; i++) {
+   if (timr->ring_id != dev->timer_adptr_rings[i])
+   continue;
+   if (timr->nb_timers == dev->timer_adptr_sz[i])
+   return;
+   dev->adptr_xae_cnt -= dev->timer_adptr_sz[i];
+   dev->adptr_xae_cnt += timr->nb_timers;
+   dev->timer_adptr_sz[i] = timr->nb_timers;
+
+   return;
+   }
+
+   dev->tim_adptr_ring_cnt++;
+   old_ring_ptr = dev->timer_adptr_rings;
+   old_sz_ptr = dev->timer_adptr_sz;
+
+   dev->timer_adptr_rings = rte_realloc(dev->timer_adptr_rings,
+sizeof(uint16_t) *
+dev->tim_adptr_ring_cnt,
+0);
+   if (

[dpdk-dev] [PATCH v3 2/5] event/octeontx2: use opposite bucket to store current chunk

[pbhagavatula]

From: Pavan Nikhilesh 

Since TIM buckets are always aligned to 32B and our cache line size being
128B, we will always have a cache miss when reading current_chunk pointer.
Avoid the cache miss by storing the current_chunk pointer in the bucket
opposite to the current bucket.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/event/octeontx2/otx2_tim_worker.h | 69 ++-
 1 file changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/event/octeontx2/otx2_tim_worker.h 
b/drivers/event/octeontx2/otx2_tim_worker.h
index c896b5433..7b771fbca 100644
--- a/drivers/event/octeontx2/otx2_tim_worker.h
+++ b/drivers/event/octeontx2/otx2_tim_worker.h
@@ -115,20 +115,29 @@ tim_bkt_clr_nent(struct otx2_tim_bkt *bktp)
return __atomic_and_fetch(&bktp->w1, v, __ATOMIC_ACQ_REL);
 }
 
-static __rte_always_inline struct otx2_tim_bkt *
+static __rte_always_inline void
 tim_get_target_bucket(struct otx2_tim_ring * const tim_ring,
- const uint32_t rel_bkt, const uint8_t flag)
+ const uint32_t rel_bkt, struct otx2_tim_bkt **bkt,
+ struct otx2_tim_bkt **mirr_bkt, const uint8_t flag)
 {
const uint64_t bkt_cyc = rte_rdtsc() - tim_ring->ring_start_cyc;
uint32_t bucket = rte_reciprocal_divide_u64(bkt_cyc,
&tim_ring->fast_div) + rel_bkt;
+   uint32_t mirr_bucket = 0;
 
-   if (flag & OTX2_TIM_BKT_MOD)
+   if (flag & OTX2_TIM_BKT_MOD) {
bucket = bucket % tim_ring->nb_bkts;
-   if (flag & OTX2_TIM_BKT_AND)
+   mirr_bucket = (bucket + (tim_ring->nb_bkts >> 1)) %
+   tim_ring->nb_bkts;
+   }
+   if (flag & OTX2_TIM_BKT_AND) {
bucket = bucket & (tim_ring->nb_bkts - 1);
+   mirr_bucket = (bucket + (tim_ring->nb_bkts >> 1)) &
+   (tim_ring->nb_bkts - 1);
+   }
 
-   return &tim_ring->bkt[bucket];
+   *bkt = &tim_ring->bkt[bucket];
+   *mirr_bkt = &tim_ring->bkt[mirr_bucket];
 }
 
 static struct otx2_tim_ent *
@@ -153,6 +162,7 @@ tim_clr_bkt(struct otx2_tim_ring * const tim_ring,
 
 static struct otx2_tim_ent *
 tim_refill_chunk(struct otx2_tim_bkt * const bkt,
+struct otx2_tim_bkt * const mirr_bkt,
 struct otx2_tim_ring * const tim_ring)
 {
struct otx2_tim_ent *chunk;
@@ -162,8 +172,8 @@ tim_refill_chunk(struct otx2_tim_bkt * const bkt,
 (void **)&chunk)))
return NULL;
if (bkt->nb_entry) {
-   *(uint64_t *)(((struct otx2_tim_ent *)(uintptr_t)
-   bkt->current_chunk) +
+   *(uint64_t *)(((struct otx2_tim_ent *)
+   mirr_bkt->current_chunk) +
tim_ring->nb_chunk_slots) =
(uintptr_t)chunk;
} else {
@@ -180,6 +190,7 @@ tim_refill_chunk(struct otx2_tim_bkt * const bkt,
 
 static struct otx2_tim_ent *
 tim_insert_chunk(struct otx2_tim_bkt * const bkt,
+struct otx2_tim_bkt * const mirr_bkt,
 struct otx2_tim_ring * const tim_ring)
 {
struct otx2_tim_ent *chunk;
@@ -190,7 +201,7 @@ tim_insert_chunk(struct otx2_tim_bkt * const bkt,
*(uint64_t *)(chunk + tim_ring->nb_chunk_slots) = 0;
if (bkt->nb_entry) {
*(uint64_t *)(((struct otx2_tim_ent *)(uintptr_t)
-   bkt->current_chunk) +
+   mirr_bkt->current_chunk) +
tim_ring->nb_chunk_slots) = (uintptr_t)chunk;
} else {
bkt->first_chunk = (uintptr_t)chunk;
@@ -205,14 +216,15 @@ tim_add_entry_sp(struct otx2_tim_ring * const tim_ring,
 const struct otx2_tim_ent * const pent,
 const uint8_t flags)
 {
+   struct otx2_tim_bkt *mirr_bkt;
struct otx2_tim_ent *chunk;
struct otx2_tim_bkt *bkt;
uint64_t lock_sema;
int16_t rem;
 
-   bkt = tim_get_target_bucket(tim_ring, rel_bkt, flags);
-
 __retry:
+   tim_get_target_bucket(tim_ring, rel_bkt, &bkt, &mirr_bkt, flags);
+
/* Get Bucket sema*/
lock_sema = tim_bkt_fetch_sema_lock(bkt);
 
@@ -232,7 +244,7 @@ tim_add_entry_sp(struct otx2_tim_ring * const tim_ring,
: [hbt] "=&r" (hbt_state)
: [w1] "r" ((&bkt->w1))
: "memory"
-   );
+   );
 #else
do {
hbt_state = __atomic_load_n(&bkt->w1,
@@ -246,15 +258,14 @@ tim_add_entry_sp(struct otx2_tim_ring * const tim_ring,
}
}

[dpdk-dev] [PATCH v3 1/5] event/octeontx2: fix TIM HW race condition

[pbhagavatula]

From: Pavan Nikhilesh 

Fix HW race condition observed when timeout resolution is low (<5us).
When HW traverses a given TIM bucket it will clear chunk_remainder,
but since SW always decreases the chunk_remainder at the start of the
arm routine it might cause a race where SW updates chunk_remainder
after HW has cleared it that lead to nasty side effects.

Fixes: 95e4e4ec7469 ("event/octeontx2: add timer arm timeout burst")

Signed-off-by: Pavan Nikhilesh 
---
 drivers/event/octeontx2/otx2_tim_worker.h | 141 +++---
 1 file changed, 124 insertions(+), 17 deletions(-)

diff --git a/drivers/event/octeontx2/otx2_tim_worker.h 
b/drivers/event/octeontx2/otx2_tim_worker.h
index 50db6543c..c896b5433 100644
--- a/drivers/event/octeontx2/otx2_tim_worker.h
+++ b/drivers/event/octeontx2/otx2_tim_worker.h
@@ -7,6 +7,13 @@
 
 #include "otx2_tim_evdev.h"
 
+static inline uint8_t
+tim_bkt_fetch_lock(uint64_t w1)
+{
+   return (w1 >> TIM_BUCKET_W1_S_LOCK) &
+   TIM_BUCKET_W1_M_LOCK;
+}
+
 static inline int16_t
 tim_bkt_fetch_rem(uint64_t w1)
 {
@@ -188,7 +195,6 @@ tim_insert_chunk(struct otx2_tim_bkt * const bkt,
} else {
bkt->first_chunk = (uintptr_t)chunk;
}
-
return chunk;
 }
 
@@ -208,11 +214,38 @@ tim_add_entry_sp(struct otx2_tim_ring * const tim_ring,
 
 __retry:
/* Get Bucket sema*/
-   lock_sema = tim_bkt_fetch_sema(bkt);
+   lock_sema = tim_bkt_fetch_sema_lock(bkt);
 
/* Bucket related checks. */
-   if (unlikely(tim_bkt_get_hbt(lock_sema)))
-   goto __retry;
+   if (unlikely(tim_bkt_get_hbt(lock_sema))) {
+   if (tim_bkt_get_nent(lock_sema) != 0) {
+   uint64_t hbt_state;
+#ifdef RTE_ARCH_ARM64
+   asm volatile(
+   "   ldaxr %[hbt], [%[w1]]   \n"
+   "   tbz %[hbt], 33, dne%=   \n"
+   "   sevl\n"
+   "rty%=: wfe \n"
+   "   ldaxr %[hbt], [%[w1]]   \n"
+   "   tbnz %[hbt], 33, rty%=  \n"
+   "dne%=: \n"
+   : [hbt] "=&r" (hbt_state)
+   : [w1] "r" ((&bkt->w1))
+   : "memory"
+   );
+#else
+   do {
+   hbt_state = __atomic_load_n(&bkt->w1,
+   __ATOMIC_ACQUIRE);
+   } while (hbt_state & BIT_ULL(33));
+#endif
+
+   if (!(hbt_state & BIT_ULL(34))) {
+   tim_bkt_dec_lock(bkt);
+   goto __retry;
+   }
+   }
+   }
 
/* Insert the work. */
rem = tim_bkt_fetch_rem(lock_sema);
@@ -224,14 +257,15 @@ tim_add_entry_sp(struct otx2_tim_ring * const tim_ring,
chunk = tim_insert_chunk(bkt, tim_ring);
 
if (unlikely(chunk == NULL)) {
-   tim_bkt_set_rem(bkt, 0);
+   bkt->chunk_remainder = 0;
+   tim_bkt_dec_lock(bkt);
tim->impl_opaque[0] = 0;
tim->impl_opaque[1] = 0;
tim->state = RTE_EVENT_TIMER_ERROR;
return -ENOMEM;
}
bkt->current_chunk = (uintptr_t)chunk;
-   tim_bkt_set_rem(bkt, tim_ring->nb_chunk_slots - 1);
+   bkt->chunk_remainder = tim_ring->nb_chunk_slots - 1;
} else {
chunk = (struct otx2_tim_ent *)(uintptr_t)bkt->current_chunk;
chunk += tim_ring->nb_chunk_slots - rem;
@@ -241,6 +275,7 @@ tim_add_entry_sp(struct otx2_tim_ring * const tim_ring,
*chunk = *pent;
 
tim_bkt_inc_nent(bkt);
+   tim_bkt_dec_lock(bkt);
 
tim->impl_opaque[0] = (uintptr_t)chunk;
tim->impl_opaque[1] = (uintptr_t)bkt;
@@ -263,19 +298,60 @@ tim_add_entry_mp(struct otx2_tim_ring * const tim_ring,
 
 __retry:
bkt = tim_get_target_bucket(tim_ring, rel_bkt, flags);
-
/* Get Bucket sema*/
lock_sema = tim_bkt_fetch_sema_lock(bkt);
 
/* Bucket related checks. */
if (unlikely(tim_bkt_get_hbt(lock_sema))) {
-   tim_bkt_dec_lock(bkt);
-   goto __retry;
+   if (tim_bkt_get_nent(lock_sema) != 0) {
+   uint64_t hbt_state;
+#ifdef RTE_ARCH_ARM64
+   asm volatile(
+   "   ldaxr %[hbt], [%[w1]]   \n"
+   "   tbz %[hbt], 33, dne%=   \n"
+   "  

[dpdk-dev] [PATCH v3 5/5] event/octeontx2: update start timestamp periodically

[pbhagavatula]

From: Pavan Nikhilesh 

Update start timestamp periodically to prevent drift.

Signed-off-by: Pavan Nikhilesh 
---
 drivers/event/octeontx2/otx2_tim_evdev.c  | 28 +++
 drivers/event/octeontx2/otx2_tim_evdev.h  |  7 --
 drivers/event/octeontx2/otx2_tim_worker.c | 19 +++
 3 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/drivers/event/octeontx2/otx2_tim_evdev.c 
b/drivers/event/octeontx2/otx2_tim_evdev.c
index 5f0233f44..b275c6922 100644
--- a/drivers/event/octeontx2/otx2_tim_evdev.c
+++ b/drivers/event/octeontx2/otx2_tim_evdev.c
@@ -389,6 +389,31 @@ otx2_tim_ring_create(struct rte_event_timer_adapter *adptr)
return rc;
 }
 
+static void
+otx2_tim_calibrate_start_tsc(struct otx2_tim_ring *tim_ring)
+{
+#define OTX2_TIM_CALIB_ITER1E6
+   uint32_t real_bkt, bucket;
+   int icount, ecount = 0;
+   uint64_t bkt_cyc;
+
+   for (icount = 0; icount < OTX2_TIM_CALIB_ITER; icount++) {
+   real_bkt = otx2_read64(tim_ring->base + TIM_LF_RING_REL) >> 44;
+   bkt_cyc = rte_rdtsc();
+   bucket = (bkt_cyc - tim_ring->ring_start_cyc) /
+   tim_ring->tck_int;
+   bucket = bucket % (tim_ring->nb_bkts);
+   tim_ring->ring_start_cyc = bkt_cyc - (real_bkt *
+   tim_ring->tck_int);
+   if (bucket != real_bkt)
+   ecount++;
+   }
+   tim_ring->last_updt_cyc = bkt_cyc;
+   otx2_tim_dbg("Bucket mispredict %3.2f distance %d\n",
+100 - (((double)(icount - ecount) / (double)icount) * 100),
+bucket - real_bkt);
+}
+
 static int
 otx2_tim_ring_start(const struct rte_event_timer_adapter *adptr)
 {
@@ -423,8 +448,11 @@ otx2_tim_ring_start(const struct rte_event_timer_adapter 
*adptr)
tim_ring->ring_start_cyc = rsp->timestarted;
 #endif
tim_ring->tck_int = NSEC2TICK(tim_ring->tck_nsec, rte_get_timer_hz());
+   tim_ring->tot_int = tim_ring->tck_int * tim_ring->nb_bkts;
tim_ring->fast_div = rte_reciprocal_value_u64(tim_ring->tck_int);
 
+   otx2_tim_calibrate_start_tsc(tim_ring);
+
 fail:
return rc;
 }
diff --git a/drivers/event/octeontx2/otx2_tim_evdev.h 
b/drivers/event/octeontx2/otx2_tim_evdev.h
index f3fe9697a..56895dcbf 100644
--- a/drivers/event/octeontx2/otx2_tim_evdev.h
+++ b/drivers/event/octeontx2/otx2_tim_evdev.h
@@ -25,6 +25,7 @@
 #define TIM_LF_RAS_INT_W1S (0x308)
 #define TIM_LF_RAS_INT_ENA_W1S (0x310)
 #define TIM_LF_RAS_INT_ENA_W1C (0x318)
+#define TIM_LF_RING_REL(0x400)
 
 #define TIM_BUCKET_W1_S_CHUNK_REMAINDER(48)
 #define TIM_BUCKET_W1_M_CHUNK_REMAINDER((1ULL << (64 - \
@@ -139,13 +140,15 @@ struct otx2_tim_evdev {
 
 struct otx2_tim_ring {
uintptr_t base;
-   struct rte_reciprocal_u64 fast_div;
uint16_t nb_chunk_slots;
uint32_t nb_bkts;
+   uint64_t last_updt_cyc;
uint64_t ring_start_cyc;
+   uint64_t tck_int;
+   uint64_t tot_int;
struct otx2_tim_bkt *bkt;
struct rte_mempool *chunk_pool;
-   uint64_t tck_int;
+   struct rte_reciprocal_u64 fast_div;
rte_atomic64_t arm_cnt;
uint8_t prod_type_sp;
uint8_t enable_stats;
diff --git a/drivers/event/octeontx2/otx2_tim_worker.c 
b/drivers/event/octeontx2/otx2_tim_worker.c
index feba61cd4..104674c79 100644
--- a/drivers/event/octeontx2/otx2_tim_worker.c
+++ b/drivers/event/octeontx2/otx2_tim_worker.c
@@ -38,6 +38,23 @@ tim_format_event(const struct rte_event_timer * const tim,
entry->wqe = tim->ev.u64;
 }
 
+static inline void
+tim_sync_start_cyc(struct otx2_tim_ring *tim_ring)
+{
+   uint64_t cur_cyc = rte_rdtsc();
+   uint32_t real_bkt;
+
+   if (cur_cyc - tim_ring->last_updt_cyc > tim_ring->tot_int) {
+   real_bkt = otx2_read64(tim_ring->base + TIM_LF_RING_REL) >> 44;
+   cur_cyc = rte_rdtsc();
+
+   tim_ring->ring_start_cyc = cur_cyc -
+   (real_bkt * tim_ring->tck_int);
+   tim_ring->last_updt_cyc = cur_cyc;
+   }
+
+}
+
 static __rte_always_inline uint16_t
 tim_timer_arm_burst(const struct rte_event_timer_adapter *adptr,
struct rte_event_timer **tim,
@@ -49,6 +66,7 @@ tim_timer_arm_burst(const struct rte_event_timer_adapter 
*adptr,
uint16_t index;
int ret;
 
+   tim_sync_start_cyc(tim_ring);
for (index = 0; index < nb_timers; index++) {
if (tim_arm_checks(tim_ring, tim[index]))
break;
@@ -99,6 +117,7 @@ tim_timer_arm_tmo_brst(const struct rte_event_timer_adapter 
*adptr,
return 0;
}
 
+   tim_sync_start_cyc(tim_ring);
while (arr_idx < nb_timers) {
for (idx = 0; idx < OTX2_TIM_MAX_BURST && (arr_idx < nb_

[dpdk-dev] [PATCH] ci: add minimal check on testpmd

[David Marchand]

Try to start testpmd with two vdevs without hugepages.
This is a really basic check, but better than nothing.

Signed-off-by: David Marchand 
---
 .ci/linux-build.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index c570ba24e6..e37176e91c 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -32,6 +32,10 @@ OPTS="$OPTS --default-library=$DEF_LIB"
 meson build --werror -Dexamples=all $OPTS
 ninja -C build
 
+if [ "$AARCH64" != "1" ]; then
+./devtools/test-null.sh
+fi
+
 if [ "$RUN_TESTS" = "1" ]; then
 sudo meson test -C build --suite fast-tests -t 3
 fi
-- 
2.23.0

Re: [dpdk-dev] [PATCH] devtools: disable automatic probing in null testing

[David Marchand]

On Fri, Nov 22, 2019 at 2:56 PM Ferruh Yigit  wrote:
>
> On 11/22/2019 1:48 PM, Thomas Monjalon wrote:
> > The script test-null.sh is supposed to do a quick and simple
> > run of testpmd with null PMD only, for sanity check.
> > As it is not supposed to test probing of any other PMD,
> > physical device probing is switched to whitelist mode
> > by using a fake PCI address (0:0.0).
> > It will also help to keep memory usage stable across platforms.
> >
> > Signed-off-by: Thomas Monjalon 
> > ---
> >  devtools/test-null.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/devtools/test-null.sh b/devtools/test-null.sh
> > index 9f9a459f76..d82c6ad193 100755
> > --- a/devtools/test-null.sh
> > +++ b/devtools/test-null.sh
> > @@ -26,5 +26,5 @@ fi
> >
> >  (sleep 1 && echo stop) |
> >  $testpmd -c $coremask --no-huge -m 150 \
> > - $libs --vdev net_null1 --vdev net_null2 $eal_options -- \
> > + $libs -w 0:0.0 --vdev net_null1 --vdev net_null2 $eal_options -- \
> >   --no-mlockall --total-num-mbufs=2048 $testpmd_options -ia
> >
>
> Tested-by: Ferruh Yigit 

Ugly, but does the job.
Acked-by: David Marchand 


-- 
David Marchand

[dpdk-dev] [PATCH 1/8] doc: update Linux GSG system requirements section

[Bruce Richardson]

Update the system requirements section of the doc to cover builds with
meson and ninja. This involves updating the package dependencies to include
meson, ninja and python 3.5, and also updating the optional dependencies
section to explain that the components are enabled/disabled automatically
by meson.

As part of this update, the relevant sections were simplified to keep the
document shorter. For mandatory requirements, we can refer to the various
distro's development tools package groups rather than requiring gcc, core
tools etc. individually. The optional package list was very incomplete, and
if complete would duplicate information in the individual driver's guides.
Therefore we can simplify it by listing only the library optional
requirements and referring users to the driver docs to find details on
their dependencies.

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/sys_reqs.rst | 64 +++
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/doc/guides/linux_gsg/sys_reqs.rst 
b/doc/guides/linux_gsg/sys_reqs.rst
index d2359058b..c0b696069 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -37,32 +37,22 @@ Compilation of the DPDK
 The setup commands and installed packages needed on various systems may be 
different.
 For details on Linux distributions and the versions tested, please consult 
the DPDK Release Notes.
 
-*   GNU ``make``.
+*   General development tools including ``make``, and a supported C compiler 
such as ``gcc`` or ``clang``.
 
-*   coreutils: ``cmp``, ``sed``, ``grep``, ``arch``, etc.
+* For Red Hat/Fedora systems these can be installed using ``dnf 
groupinstall "Development Tools"``
 
-*   gcc: versions 4.9 or later is recommended for all platforms.
-On some distributions, some specific compiler flags and linker flags are 
enabled by
-default and affect performance (``-fstack-protector``, for example). 
Please refer to the documentation
-of your distribution and to ``gcc -dumpspecs``.
+* For Ubuntu/Debian systems these can be installed using ``apt install 
build-essential``
 
-*   libc headers, often packaged as ``gcc-multilib`` (``glibc-devel.i686`` / 
``libc6-dev-i386``;
-``glibc-devel.x86_64`` / ``libc6-dev`` for 64-bit compilation on Intel 
architecture;
-``glibc-devel.ppc64`` for 64 bit IBM Power architecture;)
+*   Python, recommended version 3.5+.
 
-*   Linux kernel headers or sources required to build kernel modules. (kernel 
- devel.x86_64;
-kernel - devel.ppc64)
+* Python v3.5+ is needed to build DPDK using meson and ninja
 
-*   Additional packages required for 32-bit compilation on 64-bit systems are:
+* Python 2.7+ or 3.2+, to use various helper scripts included in the DPDK 
package.
 
-* glibc.i686, libgcc.i686, libstdc++.i686 and glibc-devel.i686 for Intel 
i686/x86_64;
+*   Meson (v0.47.1+) and ninja
 
-* glibc.ppc64, libgcc.ppc64, libstdc++.ppc64 and glibc-devel.ppc64 for IBM 
ppc_64;
-
-.. note::
-
-   x86_x32 ABI is currently supported with distribution packages only on 
Ubuntu
-   higher than 13.10 or recent Debian distribution. The only supported  
compiler is gcc 4.9+.
+* Recommended to use the latest versions from Python's "pip" repository:
+  ``pip3 install meson ninja``
 
 *   Library for handling NUMA (Non Uniform Memory Access).
 
@@ -70,16 +60,7 @@ Compilation of the DPDK
 
 * libnuma-dev in Debian/Ubuntu;
 
-.. note::
-
-On systems with NUMA support, `libnuma-dev` (aka `numactl-devel`)
-is a recommended dependency when `--legacy-mem` switch is used,
-and a *required* dependency if default memory mode is used.
-While DPDK will compile and run without `libnuma`
-even on NUMA-enabled systems,
-both usability and performance will be degraded.
-
-*   Python, version 2.7+ or 3.2+, to use various helper scripts included in 
the DPDK package.
+*   Linux kernel headers or sources required to build kernel modules.
 
 .. note::
 
@@ -96,10 +77,29 @@ Compilation of the DPDK
 which allows users to take leading edge advantage of IBM's latest POWER 
hardware features on Linux. To install
 it, see the IBM official installation document.
 
-*   libpcap headers and libraries (libpcap-devel) to compile and use the 
libpcap-based poll-mode driver.
-This driver is disabled by default and can be enabled by setting 
``CONFIG_RTE_LIBRTE_PMD_PCAP=y`` in the build time config file.
+**Additional Libraries**
+
+A number of DPDK components, such as libraries and poll-mode drivers (PMDs) 
have additional dependencies.
+For DPDK builds using meson, the presence or absence of these dependencies 
will be
+automatically detected enabling or disabling the relevant components 
appropriately.
+
+For builds using make, these components are disabled in the default 
configuration and
+need to be enabled manually my changing the relevant setting to "y" in the 
build 

[dpdk-dev] [PATCH 4/8] doc: remove reference to old versions of FreeBSD

[Bruce Richardson]

FreeBSD 10 is now EOL and all testing with DPDK takes place on BSD versions
11 and 12, so we can just remove the note. The BSD ports are supported on
all non-EOL versions of BSD.

Signed-off-by: Bruce Richardson 
---
 doc/guides/freebsd_gsg/install_from_ports.rst | 6 --
 1 file changed, 6 deletions(-)

diff --git a/doc/guides/freebsd_gsg/install_from_ports.rst 
b/doc/guides/freebsd_gsg/install_from_ports.rst
index a895d6180..4b0447584 100644
--- a/doc/guides/freebsd_gsg/install_from_ports.rst
+++ b/doc/guides/freebsd_gsg/install_from_ports.rst
@@ -11,12 +11,6 @@ install it from the ports collection. Details of getting and 
using the ports
 collection are documented in the
 `FreeBSD Handbook 
`_.
 
-.. note::
-
-Testing has been performed using FreeBSD 10.0-RELEASE (x86_64) and 
requires the
-installation of the kernel sources, which should be included during the
-installation of FreeBSD.
-
 Installing the DPDK FreeBSD Port
 
 
-- 
2.21.0

[dpdk-dev] [PATCH 2/8] doc: add building with meson to linux GSG

[Bruce Richardson]

Add instructions on building DPDK and using the pkg-config file to the
linux GSG.

Signed-off-by: Bruce Richardson 
---
 doc/guides/linux_gsg/build_dpdk.rst | 94 +++--
 1 file changed, 90 insertions(+), 4 deletions(-)

diff --git a/doc/guides/linux_gsg/build_dpdk.rst 
b/doc/guides/linux_gsg/build_dpdk.rst
index 7c0329fcc..5710effbc 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -11,8 +11,8 @@ Compiling the DPDK Target from Source
 Parts of this process can also be done using the setup script described in
 the :ref:`linux_setup_script` section of this document.
 
-Install the DPDK and Browse Sources

+Uncompress DPDK and Browse Sources
+--
 
 First, uncompress the archive and move to the uncompressed DPDK source 
directory:
 
@@ -33,8 +33,94 @@ The DPDK is composed of several directories:
 
 *   config, buildtools, mk: Framework-related makefiles, scripts and 
configuration
 
-Installation of DPDK Target Environments
-
+Compiling and Installing DPDK System-wide
+-
+
+DPDK can be configured, built and installed on your system using the tools
+``meson`` and ``ninja``.
+
+.. note::
+
+  The older makefile-based build system used in older DPDK releases is
+  still present and it's use is described in section
+  `Installation of DPDK Target Environment using Make`_.
+
+DPDK Configuration
+~~
+
+To configure a DPDK build use:
+
+.. code-block:: console
+
+ meson  build
+
+where "build" is the desired output build directory, and "" can be
+empty or one of a number of meson or DPDK-specific build options, described
+later in this section. The configuration process will finish with a summary
+of what DPDK libraries and drivers are to be built and installed, and for
+each item disabled, a reason why that is the case. This information can be
+used, for example, to identify any missing required packages for a driver.
+
+Once configured, to build and then install DPDK system-wide use:
+
+.. code-block:: console
+
+cd build
+ninja
+ninja install
+
+Adjusting Build Options
+~~~
+
+DPDK has a number of options that can be adjusted as part of the build 
configuration process.
+These options can be listed by running ``meson configure`` inside a configured 
build folder.
+Many of these options come from the "meson" tool itself and can be seen 
documented on the
+`Meson Website `_.
+
+For example, to change the build-type from the default, "debugoptimized",
+to a regular "debug" build, you can either:
+
+* pass ``-Dbuildtype=debug`` or ``--buildtype=debug`` to meson when 
configuring the build folder initially
+
+* run ``meson configure -Dbuildtype=debug`` inside the build folder after the 
initial meson run.
+
+Other options are specific to the DPDK project but can be adjusted similarly.
+To set the "max_lcores" value to 256, for example, you can either:
+
+* pass ``-Dmax_lcores=256`` to meson when configuring the build folder 
initially
+
+* run ``meson configure -Dmax_lcores=256`` inside the build folder after the 
initial meson run.
+
+Building Applications Using Installed DPDK
+~~
+
+When installed system-wide, DPDK provides a pkg-config file ``libdpdk.pc`` for 
applications to query as part of their build.
+It's recommended that the pkg-config file be used, rather than hard-coding the 
parameters (cflags/ldflags)
+for DPDK into the application build process.
+
+An example of how to query and use the pkg-config file can be found in the 
``Makefile`` of each of the example applications included with DPDK.
+A simplified example snippet is shown below, where the target binary name has 
been stored in the variable ``$(APP)``
+and the sources for that build are stored in ``$(SRCS-y)``.
+
+.. code-block:: makefile
+
+PKGCONF = pkg-config
+
+CFLAGS += -O3 $(shell $(PKGCONF) --cflags libdpdk)
+LDFLAGS += $(shell $(PKGCONF) --libs libdpdk)
+
+$(APP): $(SRCS-y) Makefile
+$(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
+
+
+Installation of DPDK Target Environment using Make
+--
+
+.. note::
+
+   The building of DPDK using make will be deprecated in a future release. It
+   is therefore recommended that DPDK installation is done using meson and
+   ninja as described above.
 
 The format of a DPDK target is::
 
-- 
2.21.0

[dpdk-dev] [PATCH 5/8] doc: update examples output in FreeBSD GSG

[Bruce Richardson]

The output of running the helloworld example on FreeBSD was a little
out-of-date and can be shortened by using the latest version of DPDK.
Update appropriately.

Signed-off-by: Bruce Richardson 
---
 doc/guides/freebsd_gsg/install_from_ports.rst | 56 ---
 1 file changed, 22 insertions(+), 34 deletions(-)

diff --git a/doc/guides/freebsd_gsg/install_from_ports.rst 
b/doc/guides/freebsd_gsg/install_from_ports.rst
index 4b0447584..29f16cc6c 100644
--- a/doc/guides/freebsd_gsg/install_from_ports.rst
+++ b/doc/guides/freebsd_gsg/install_from_ports.rst
@@ -84,48 +84,36 @@ compiled and run as below:
   INSTALL-APP helloworld
   INSTALL-MAP helloworld.map
 
-sudo ./build/helloworld -l 0-3 -n 2
-
-EAL: Contigmem driver has 2 buffers, each of size 1GB
+sudo ./build//helloworld -l 0-3
 EAL: Sysctl reports 8 cpus
-EAL: Detected lcore 0
-EAL: Detected lcore 1
-EAL: Detected lcore 2
-EAL: Detected lcore 3
-EAL: Support maximum 64 logical core(s) by configuration.
-EAL: Detected 4 lcore(s)
-EAL: Setting up physically contiguous memory...
-EAL: Mapped memory segment 1 @ 0x80240: len 1073741824
-EAL: Mapped memory segment 2 @ 0x84240: len 1073741824
-EAL: WARNING: clock_gettime cannot use CLOCK_MONOTONIC_RAW and HPET
- is not available - clock timings may be less accurate.
-EAL: TSC frequency is ~3569023 KHz
-EAL: PCI scan found 24 devices
-EAL: Master core 0 is ready (tid=0x802006400)
-EAL: Core 1 is ready (tid=0x802006800)
-EAL: Core 3 is ready (tid=0x802007000)
-EAL: Core 2 is ready (tid=0x802006c00)
+EAL: Detected 8 lcore(s)
+EAL: Detected 1 NUMA nodes
+EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
+EAL: Selected IOVA mode 'PA'
+EAL: Contigmem driver has 2 buffers, each of size 1GB
+EAL: Mapped memory segment 0 @ 0x104000: physaddr:0x18000, len 
1073741824
+EAL: Mapped memory segment 1 @ 0x108000: physaddr:0x1c000, len 
1073741824
+EAL: PCI device :00:19.0 on NUMA socket 0
+EAL:   probe driver: 8086:153b net_e1000_em
+EAL:   :00:19.0 not managed by UIO driver, skipping
 EAL: PCI device :01:00.0 on NUMA socket 0
-EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
-EAL:   PCI memory mapped at 0x80074a000
-EAL:   PCI memory mapped at 0x8007ca000
+EAL:   probe driver: 8086:1572 net_i40e
+EAL:   :01:00.0 not managed by UIO driver, skipping
 EAL: PCI device :01:00.1 on NUMA socket 0
-EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
-EAL:   PCI memory mapped at 0x8007ce000
-EAL:   PCI memory mapped at 0x80084e000
-EAL: PCI device :02:00.0 on NUMA socket 0
-EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
-EAL:   PCI memory mapped at 0x800852000
-EAL:   PCI memory mapped at 0x8008d2000
-EAL: PCI device :02:00.1 on NUMA socket 0
-EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
-EAL:   PCI memory mapped at 0x801b3f000
-EAL:   PCI memory mapped at 0x8008d6000
+EAL:   probe driver: 8086:1572 net_i40e
+EAL:   :01:00.1 not managed by UIO driver, skipping
+EAL: PCI device :01:00.2 on NUMA socket 0
+EAL:   probe driver: 8086:1572 net_i40e
+EAL:   :01:00.2 not managed by UIO driver, skipping
+EAL: PCI device :01:00.3 on NUMA socket 0
+EAL:   probe driver: 8086:1572 net_i40e
+EAL:   :01:00.3 not managed by UIO driver, skipping
 hello from core 1
 hello from core 2
 hello from core 3
 hello from core 0
 
+
 .. note::
 
To run a DPDK process as a non-root user, adjust the permissions on
-- 
2.21.0

[dpdk-dev] [PATCH 6/8] doc: add meson install instructions for FreeBSD

[Bruce Richardson]

Update the FreeBSD GSG doc with instructions for installing using meson and
ninja rather than make.

Signed-off-by: Bruce Richardson 
---
 doc/guides/freebsd_gsg/build_dpdk.rst | 164 +++---
 1 file changed, 40 insertions(+), 124 deletions(-)

diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst 
b/doc/guides/freebsd_gsg/build_dpdk.rst
index 7abd85aa5..c5d5379f6 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -6,147 +6,63 @@
 Compiling the DPDK Target from Source
 =
 
-System Requirements

+Prerequisites
+-
 
-The DPDK and its applications require the GNU make system (gmake)
-to build on FreeBSD. Optionally, gcc may also be used in place of clang
-to build the DPDK, in which case it too must be installed prior to
-compiling the DPDK. The installation of these tools is covered in this
-section.
+The following FreeBSD packages are required to build DPDK:
 
-Compiling the DPDK requires the FreeBSD kernel sources, which should be
-included during the installation of FreeBSD on the development platform.
-The DPDK also requires the use of FreeBSD ports to compile and function.
+* meson
+* ninja
+* pkgconf
 
-To use the FreeBSD ports system, it is required to update and extract the 
FreeBSD
-ports tree by issuing the following commands:
+These can be installed using (as root)::
 
-.. code-block:: console
-
-portsnap fetch
-portsnap extract
-
-If the environment requires proxies for external communication, these can be 
set
-using:
-
-.. code-block:: console
-
-setenv http_proxy :
-setenv ftp_proxy :
-
-The FreeBSD ports below need to be installed prior to building the DPDK.
-In general these can be installed using the following set of commands::
-
-   cd /usr/ports/
-
-   make config-recursive
-
-   make install
-
-   make clean
-
-Each port location can be found using::
-
-   whereis 
-
-The ports required and their locations are as follows:
-
-* dialog4ports: ``/usr/ports/ports-mgmt/dialog4ports``
-
-* GNU make(gmake): ``/usr/ports/devel/gmake``
-
-* coreutils: ``/usr/ports/sysutils/coreutils``
-
-For compiling and using the DPDK with gcc, the compiler must be installed
-from the ports collection:
-
-* gcc: version 4.9 is recommended ``/usr/ports/lang/gcc49``.
-  Ensure that ``CPU_OPTS`` is selected (default is OFF).
-
-When running the make config-recursive command, a dialog may be presented to 
the
-user. For the installation of the DPDK, the default options were used.
-
-.. note::
+  pkg install meson pkgconf
 
-To avoid multiple dialogs being presented to the user during make install,
-it is advisable before running the make install command to re-run the
-make config-recursive command until no more dialogs are seen.
+To compile the required kernel modules for memory management and working
+with physical NIC devices, the kernel sources for FreeBSD also
+need to be installed. If not already present on the system, these can be
+installed via commands like the following, for FreeBSD 12.1 on x86_64::
 
+  fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.1-RELEASE/src.txz
+  tar -C / -xJvf src.txz
 
-Install the DPDK and Browse Sources

+To enable the telemetry library in DPDK, the jansson library also needs to
+be installed, and can be installed via::
 
-First, uncompress the archive and move to the DPDK source directory:
+  pkg install jansson
 
-.. code-block:: console
-
-unzip DPDK-.zip
-cd DPDK-
-
-The DPDK is composed of several directories:
-
-*   lib: Source code of DPDK libraries
-
-*   app: Source code of DPDK applications (automatic tests)
-
-*   examples: Source code of DPDK applications
-
-*   config, buildtools, mk: Framework-related makefiles, scripts and 
configuration
-
-Installation of the DPDK Target Environments
-
-
-The format of a DPDK target is::
-
-   ARCH-MACHINE-EXECENV-TOOLCHAIN
-
-Where:
+Individual drivers may have additional requirements. Consult the relevant
+driver guide for any driver-specific requirements of interest.
 
-* ``ARCH`` is: ``x86_64``
+Building DPDK
+-
 
-* ``MACHINE`` is: ``native``
+The following commands can be used to build and install DPDK on a system.
+The final, install, step generally needs to be run as root::
 
-* ``EXECENV`` is: ``freebsd``
+  meson build
+  cd build
+  ninja
+  ninja install
 
-* ``TOOLCHAIN`` is: ``gcc`` | ``clang``
-
-The configuration files for the DPDK targets can be found in the DPDK/config
-directory in the form of::
-
-defconfig_ARCH-MACHINE-EXECENV-TOOLCHAIN
+This will install the DPDK libraries and drivers to `/usr/local/lib` with a
+pkg-config file `libdpdk.pc` installed to `/usr/local/lib/pkgconfig`. The
+DPDK test applications, such as `dpdk-testpmd` are installed to
+`/usr/local/bin`. To use these applications, it is recommended that the
+`contigmem` and `

[dpdk-dev] [PATCH 0/8] GSG Documentation updates

[Bruce Richardson]

This patchset includes documentation updates for both the Linux and
FreeBSD Getting Started Guide Docs. The majority of changes are to add
information on building using meson and ninja, with some additional
cleanups being performed at the same time.

Bruce Richardson (8):
  doc: update Linux GSG system requirements section
  doc: add building with meson to linux GSG
  doc: reorder meson and make build instructions for arm
  doc: remove reference to old versions of FreeBSD
  doc: update examples output in FreeBSD GSG
  doc: add meson install instructions for FreeBSD
  doc: update documentation on build and running FreeBSD apps
  doc: drop EAL command-line reference from FreeBSD GSG

 doc/guides/freebsd_gsg/build_dpdk.rst | 164 +-
 doc/guides/freebsd_gsg/build_sample_apps.rst  | 118 +++--
 .../freebsd_gsg/freebsd_eal_parameters.rst|  20 ---
 doc/guides/freebsd_gsg/index.rst  |   1 -
 doc/guides/freebsd_gsg/install_from_ports.rst |  62 +++
 doc/guides/linux_gsg/build_dpdk.rst   |  94 +-
 .../linux_gsg/cross_build_dpdk_for_arm64.rst  |  32 ++--
 doc/guides/linux_gsg/sys_reqs.rst |  64 +++
 8 files changed, 228 insertions(+), 327 deletions(-)
 delete mode 100644 doc/guides/freebsd_gsg/freebsd_eal_parameters.rst

-- 
2.21.0

[dpdk-dev] [PATCH 3/8] doc: reorder meson and make build instructions for arm

[Bruce Richardson]

Since the meson instructions are the simpler of the two sets, and also the
ones most future-proof, put those first in the user documentation with make
instructions following them.

Signed-off-by: Bruce Richardson 
---
 .../linux_gsg/cross_build_dpdk_for_arm64.rst  | 32 ++-
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst 
b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
index e799b0ba4..8c87a595e 100644
--- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
+++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
@@ -77,8 +77,23 @@ Copy the NUMA header files and lib to the cross compiler's 
directories:
 
 .. _configure_and_cross_compile_dpdk_build:
 
-Configure and cross compile DPDK Build
---
+Cross Compiling DPDK using Meson
+
+
+To cross-compile DPDK on a desired target machine we can use the following
+command::
+
+   meson cross-build --cross-file 
+   ninja -C cross-build
+
+For example if the target machine is arm64 we can use the following
+command::
+
+   meson arm64-build --cross-file config/arm/arm64_armv8_linux_gcc
+   ninja -C arm64-build
+
+Configure and Cross Compile DPDK using Make
+---
 To configure a build, choose one of the target configurations, like 
arm64-dpaa-linux-gcc and arm64-thunderx-linux-gcc.
 
 .. code-block:: console
@@ -119,17 +134,4 @@ To compile for non-NUMA targets, without compiling the 
kernel modules, use the f
 
   make -j CROSS=aarch64-linux-gnu- CONFIG_RTE_KNI_KMOD=n 
CONFIG_RTE_EAL_IGB_UIO=n EXTRA_CFLAGS="-isystem /include" 
EXTRA_LDFLAGS="-L/lib -lnuma"
 
-Meson Cross Compiling DPDK
---
-
-To cross-compile DPDK on a desired target machine we can use the following
-command::
-
-   meson cross-build --cross-file 
-   ninja -C cross-build
-
-For example if the target machine is arm64 we can use the following
-command::
 
-   meson arm64-build --cross-file config/arm/arm64_armv8_linux_gcc
-   ninja -C arm64-build
-- 
2.21.0

[dpdk-dev] [PATCH 7/8] doc: update documentation on build and running FreeBSD apps

[Bruce Richardson]

Update the documentation on building and running apps on FreeBSD, taking
account of having used meson for building. We can also update the section
on the command-line parameters, rather than claiming to be a complete list
of parameters, it should describe how to get the complete list and only
cover a few important ones.

Signed-off-by: Bruce Richardson 
---
 doc/guides/freebsd_gsg/build_sample_apps.rst | 118 +--
 1 file changed, 27 insertions(+), 91 deletions(-)

diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst 
b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 0c1b9cb79..2a68f5fc3 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -12,68 +12,37 @@ environment. It also provides a pointer to where sample 
applications are stored.
 Compiling a Sample Application
 --
 
-Once a DPDK target environment directory has been created (such as
-``x86_64-native-freebsd-clang``), it contains all libraries and header files 
required
-to build an application.
+The DPDK example applications make use of the pkg-config file installed on
+the system when DPDK is installed, and so can be built using GNU make.
 
-When compiling an application in the FreeBSD environment on the DPDK,
-the following variables must be exported:
-
-*   ``RTE_SDK`` - Points to the DPDK installation directory.
-
-*   ``RTE_TARGET`` - Points to the DPDK target environment directory.
-For FreeBSD, this is the ``x86_64-native-freebsd-clang`` or
-``x86_64-native-freebsd-gcc`` directory.
-
-The following is an example of creating the ``helloworld`` application, which 
runs
-in the DPDK FreeBSD environment. While the example demonstrates compiling
-using gcc version 4.9, compiling with clang will be similar, except that the 
``CC=``
-parameter can probably be omitted. The ``helloworld`` example may be found in 
the
-``${RTE_SDK}/examples`` directory.
-
-The directory contains the ``main.c`` file. This file, when combined with the
-libraries in the DPDK target environment, calls the various functions to
-initialize the DPDK environment, then launches an entry point (dispatch
-application) for each core to be utilized. By default, the binary is generated
-in the build directory.
-
-.. code-block:: console
-
-setenv RTE_SDK /home/user/DPDK
-cd $(RTE_SDK)
-cd examples/helloworld/
-setenv RTE_SDK $HOME/DPDK
-setenv RTE_TARGET x86_64-native-freebsd-gcc
-
-gmake CC=gcc49
-  CC main.o
-  LD helloworld
-  INSTALL-APP helloworld
-  INSTALL-MAP helloworld.map
+.. note::
 
-ls build/app
-  helloworld helloworld.map
+   BSD make cannot be used to compile the DPDK example applications. GNU
+   make can be installed using `pkg install gmake` if not already installed
+   on the FreeBSD system.
 
-.. note::
+The following shows how to compile the helloworld example app, following
+the installation of DPDK using `ninja install` as described previously::
 
-In the above example, ``helloworld`` was in the directory structure of the
-DPDK. However, it could have been located outside the directory
-structure to keep the DPDK structure intact.  In the following case,
-the ``helloworld`` application is copied to a new directory as a new 
starting
-point.
+$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
 
-.. code-block:: console
+$ cd examples/helloworld/
 
-setenv RTE_SDK /home/user/DPDK
-cp -r $(RTE_SDK)/examples/helloworld my_rte_app
-cd my_rte_app/
-setenv RTE_TARGET x86_64-native-freebsd-gcc
+$ gmake
+cc -O3 -I/usr/local/include -include rte_config.h -march=native
+-D__BSD_VISIBLE  main.c -o build/helloworld-shared
+-L/usr/local/lib -lrte_telemetry -lrte_bpf -lrte_flow_classify
+-lrte_pipeline -lrte_table -lrte_port -lrte_fib -lrte_ipsec
+-lrte_stack -lrte_security -lrte_sched -lrte_reorder -lrte_rib
+-lrte_rcu -lrte_rawdev -lrte_pdump -lrte_member -lrte_lpm
+-lrte_latencystats -lrte_jobstats -lrte_ip_frag -lrte_gso -lrte_gro
+-lrte_eventdev -lrte_efd -lrte_distributor -lrte_cryptodev
+-lrte_compressdev -lrte_cfgfile -lrte_bitratestats -lrte_bbdev
+-lrte_acl -lrte_timer -lrte_hash -lrte_metrics -lrte_cmdline
+-lrte_pci -lrte_ethdev -lrte_meter -lrte_net -lrte_mbuf
+-lrte_mempool -lrte_ring -lrte_eal -lrte_kvargs
+ln -sf helloworld-shared build/helloworld
 
-gmake CC=gcc49
-  CC main.o
-  LD helloworld
-  INSTALL-APP helloworld
-  INSTALL-MAP helloworld.map
 
 .. _running_sample_app:
 
@@ -88,29 +57,15 @@ Running a Sample Application
 Abstraction Layer (EAL) library, which provides some options that are 
generic
 to every DPDK application.
 
-The following is the list of options that can be given to the EAL:
-
-.. code-block:: console
-
-./rte-app -l CORELIST [-n NUM] [-b ] \
-  [-r NUM] [-v] [--proc

[dpdk-dev] [PATCH 8/8] doc: drop EAL command-line reference from FreeBSD GSG

[Bruce Richardson]

The EAL command-line reference section duplicated material covered in a
previous chapter, was out of date, and generally is unnecessary as options
are best queried directly by passing "--help" to a DPDK binary. Therefore
we can drop this section to avoid having to try and keep it up-to-date in
the future.

Signed-off-by: Bruce Richardson 
---
 .../freebsd_gsg/freebsd_eal_parameters.rst| 20 ---
 doc/guides/freebsd_gsg/index.rst  |  1 -
 2 files changed, 21 deletions(-)
 delete mode 100644 doc/guides/freebsd_gsg/freebsd_eal_parameters.rst

diff --git a/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst 
b/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst
deleted file mode 100644
index fba467a2c..0
--- a/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst
+++ /dev/null
@@ -1,20 +0,0 @@
-..  SPDX-License-Identifier: BSD-3-Clause
-Copyright(c) 2018 Intel Corporation.
-
-EAL parameters
-==
-
-This document contains a list of all EAL parameters. These parameters can be
-used by any DPDK application running on FreeBSD.
-
-Common EAL parameters
--
-
-The following EAL parameters are common to all platforms supported by DPDK.
-
-.. include:: ../linux_gsg/eal_args.include.rst
-
-FreeBSD-specific EAL parameters

-
-There are currently no FreeBSD-specific EAL command-line parameters available.
diff --git a/doc/guides/freebsd_gsg/index.rst b/doc/guides/freebsd_gsg/index.rst
index 9af5988dc..fdb4df32e 100644
--- a/doc/guides/freebsd_gsg/index.rst
+++ b/doc/guides/freebsd_gsg/index.rst
@@ -14,4 +14,3 @@ Getting Started Guide for FreeBSD
 install_from_ports
 build_dpdk
 build_sample_apps
-freebsd_eal_parameters
-- 
2.21.0

Re: [dpdk-dev] [PATCH v3 1/5] event/octeontx2: fix TIM HW race condition

[Pavan Nikhilesh Bhagavatula]

+Cc: sta...@dpdk.org

>-Original Message-
>From: pbhagavat...@marvell.com 
>Sent: Friday, November 22, 2019 9:14 PM
>To: Jerin Jacob Kollanukkaran ; Pavan Nikhilesh
>Bhagavatula 
>Cc: dev@dpdk.org
>Subject: [dpdk-dev] [PATCH v3 1/5] event/octeontx2: fix TIM HW race
>condition
>
>From: Pavan Nikhilesh 
>
>Fix HW race condition observed when timeout resolution is low (<5us).
>When HW traverses a given TIM bucket it will clear chunk_remainder,
>but since SW always decreases the chunk_remainder at the start of the
>arm routine it might cause a race where SW updates chunk_remainder
>after HW has cleared it that lead to nasty side effects.
>
>Fixes: 95e4e4ec7469 ("event/octeontx2: add timer arm timeout burst")
>
>Signed-off-by: Pavan Nikhilesh 
>---
> drivers/event/octeontx2/otx2_tim_worker.h | 141
>+++---
> 1 file changed, 124 insertions(+), 17 deletions(-)
>
>diff --git a/drivers/event/octeontx2/otx2_tim_worker.h
>b/drivers/event/octeontx2/otx2_tim_worker.h
>index 50db6543c..c896b5433 100644
>--- a/drivers/event/octeontx2/otx2_tim_worker.h
>+++ b/drivers/event/octeontx2/otx2_tim_worker.h
>@@ -7,6 +7,13 @@
>
> #include "otx2_tim_evdev.h"
>
>+static inline uint8_t
>+tim_bkt_fetch_lock(uint64_t w1)
>+{
>+  return (w1 >> TIM_BUCKET_W1_S_LOCK) &
>+  TIM_BUCKET_W1_M_LOCK;
>+}
>+
> static inline int16_t
> tim_bkt_fetch_rem(uint64_t w1)
> {
>@@ -188,7 +195,6 @@ tim_insert_chunk(struct otx2_tim_bkt * const
>bkt,
>   } else {
>   bkt->first_chunk = (uintptr_t)chunk;
>   }
>-
>   return chunk;
> }
>
>@@ -208,11 +214,38 @@ tim_add_entry_sp(struct otx2_tim_ring *
>const tim_ring,
>
> __retry:
>   /* Get Bucket sema*/
>-  lock_sema = tim_bkt_fetch_sema(bkt);
>+  lock_sema = tim_bkt_fetch_sema_lock(bkt);
>
>   /* Bucket related checks. */
>-  if (unlikely(tim_bkt_get_hbt(lock_sema)))
>-  goto __retry;
>+  if (unlikely(tim_bkt_get_hbt(lock_sema))) {
>+  if (tim_bkt_get_nent(lock_sema) != 0) {
>+  uint64_t hbt_state;
>+#ifdef RTE_ARCH_ARM64
>+  asm volatile(
>+  "   ldaxr %[hbt], [%[w1]]
>   \n"
>+  "   tbz %[hbt], 33, dne%=
>   \n"
>+  "   sevl
>   \n"
>+  "rty%=: wfe
>   \n"
>+  "   ldaxr %[hbt], [%[w1]]
>   \n"
>+  "   tbnz %[hbt], 33, rty%=
>   \n"
>+  "dne%=:
>   \n"
>+  : [hbt] "=&r" (hbt_state)
>+  : [w1] "r" ((&bkt->w1))
>+  : "memory"
>+  );
>+#else
>+  do {
>+  hbt_state = __atomic_load_n(&bkt-
>>w1,
>+  __ATOMIC_ACQUIRE);
>+  } while (hbt_state & BIT_ULL(33));
>+#endif
>+
>+  if (!(hbt_state & BIT_ULL(34))) {
>+  tim_bkt_dec_lock(bkt);
>+  goto __retry;
>+  }
>+  }
>+  }
>
>   /* Insert the work. */
>   rem = tim_bkt_fetch_rem(lock_sema);
>@@ -224,14 +257,15 @@ tim_add_entry_sp(struct otx2_tim_ring *
>const tim_ring,
>   chunk = tim_insert_chunk(bkt, tim_ring);
>
>   if (unlikely(chunk == NULL)) {
>-  tim_bkt_set_rem(bkt, 0);
>+  bkt->chunk_remainder = 0;
>+  tim_bkt_dec_lock(bkt);
>   tim->impl_opaque[0] = 0;
>   tim->impl_opaque[1] = 0;
>   tim->state = RTE_EVENT_TIMER_ERROR;
>   return -ENOMEM;
>   }
>   bkt->current_chunk = (uintptr_t)chunk;
>-  tim_bkt_set_rem(bkt, tim_ring->nb_chunk_slots - 1);
>+  bkt->chunk_remainder = tim_ring->nb_chunk_slots - 1;
>   } else {
>   chunk = (struct otx2_tim_ent *)(uintptr_t)bkt-
>>current_chunk;
>   chunk += tim_ring->nb_chunk_slots - rem;
>@@ -241,6 +275,7 @@ tim_add_entry_sp(struct otx2_tim_ring * const
>tim_ring,
>   *chunk = *pent;
>
>   tim_bkt_inc_nent(bkt);
>+  tim_bkt_dec_lock(bkt);
>
>   tim->impl_opaque[0] = (uintptr_t)chunk;
>   tim->impl_opaque[1] = (uintptr_t)bkt;
>@@ -263,19 +298,60 @@ tim_add_entry_mp(struct otx2_tim_ring *
>const tim_ring,
>
> __retry:
>   bkt = tim_get_target_bucket(tim_ring, rel_bkt, flags);
>-
>   /* Get Bucket sema*/
>   lock_sema = tim_bkt_fetch_sema_lock(bkt);
>
>   /* Bucket related checks. */
>   if (unlikely(tim_bkt_get_hbt(lock_sema))) {
>-  tim_bkt_dec_lock(bkt);
>-  goto __retry;
>+  if (tim_bkt_get_ne

Re: [dpdk-dev] [PATCH] ci: add minimal check on testpmd

[Thomas Monjalon]

22/11/2019 16:54, David Marchand:
> --- a/.ci/linux-build.sh
> +++ b/.ci/linux-build.sh
> +if [ "$AARCH64" != "1" ]; then
> +./devtools/test-null.sh

You are missing the build directory as first parameter,
otherwise it won't find testpmd.

One nit: ./ is probably useless.

Re: [dpdk-dev] [PATCH 0/6] Fixes for hns3 PMD driver

[Ferruh Yigit]

On 11/22/2019 12:06 PM, Wei Hu (Xavier) wrote:
> From: "Wei Hu (Xavier)" 
> 
> This series add some fixes for hns3 PMD driver.
> 
> Chengchang Tang (1):
>   net/hns3: fix the error length limit of maiblox response
> 
> Hao Chen (1):
>   net/hns3: fix RSS hardware configuration restore failure
> 
> Huisong Li (1):
>   net/hns3: fix the strategy of getting link status for VF
> 
> Min Hu (Connor) (1):
>   net/hns3: fix duplicate VLAN
> 
> Wei Hu (Xavier) (2):
>   net/hns3: fix VF configuration table entries restore failure
>   net/hns3: fix the failure sending packets less than 60 bytes

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

Re: [dpdk-dev] Backporting rte_intr_ack

[Kevin Traynor]

On 22/11/2019 15:24, Thomas Monjalon wrote:
> 22/11/2019 16:12, Kevin Traynor:
>> On 19/11/2019 10:40, Thomas Monjalon wrote:
>>> 14/10/2019 17:55, David Marchand:
 The api rte_intr_ack that has been introduced to fix a race condition
 observed with (at least) qede drivers/hw.
 This is an experimental api in master but it still fixes a problem, so
 I'd like to see this in stable branches.
>>>
>>> This is more a driver interface than an API.
>>>
 Opinions?
>>>
>>> If it comes with a fix in a driver, I think it is worth backporting.
>>>
>>>
>>
>> I think fine to backport as it solves an observed problem for qede.
>> However, a bit reluctant to update all the drivers to use it without
>> acks from their maintainers.
>>
>> Discussed with David offline and idea to backport and only update qede
>> now. Other drivers can be updated if there is a request from
>> maintainers. How does it sound?
> 
> It's better than nothing.

Not sure whether it should be opt-in or opt-out for driver maintainers,
but if there is some bug found in this new experimental API it can break
many drivers, so was airing on the side of no regression. Open to other
suggestions. Btw, it is not urgent, as we have time before next release.

> But it makes tracking of backports more difficult.

Yes, a little. We can have a separate 18.11 only qede patch and not
claim to backport the commit which updates all drivers.

> Is it a common practice to backport half of fixes?
> 

I don't remember it before where it all can apply.

> 

Re: [dpdk-dev] [PATCH] app/testpmd: use rte_rand() instead of random()

[Ferruh Yigit]

On 11/21/2019 7:34 PM, pbhagavat...@marvell.com wrote:
> From: Pavan Nikhilesh 
> 
> Use rte_rand() instead of random() for better randomness.
> 
> Coverity Issue: 337666
> 
> Signed-off-by: Pavan Nikhilesh 

Reviewed-by: Ferruh Yigit 

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

Re: [dpdk-dev] [dpdk-users] What is the 'unit of timestamp' assigned to mbuf packet in DPDK?

[Gokul Bargaje]

Thank you for the clarification. But I am still unable to understand how
exactly timestamp is calculated before assigning to a timestamp field.
Could you please tell me the steps to calculate the timestamp in DPDK?

I have to implement the PIE AQM algorithm in DPDK and for that, I need to
calculate the total time spent by the packet waiting in queue (i.e. the
difference between enqueue time and dequeue time).

Thanks,
Gokul

On Fri, Nov 22, 2019 at 8:18 PM Ferruh Yigit  wrote:

> On 11/18/2019 2:29 PM, Gokul Bargaje wrote:
> > Hi,
> >
> > The timestamp assigned to packet at the time of enqueue (value of
> timestamp
> > field in mbuf), is it in milliseconds or microseconds or in cpu cycles?
>
> The unit is not defined [1]. 'rte_eth_read_clock()' was added [2] to help
> converting it to time when it is clock counter.
>
> [1]
> 918ae9dc775e ("mbuf: add a timestamp field")
>
> [2]
> 5e741377657c ("ethdev: add API to read device clock")
>
> >
> > How this timestamp is calculated? Is it calculated using the
> *rte_cycles.h*?
> >
>
>
>
>
>
>

Re: [dpdk-dev] [dpdk-users] What is the 'unit of timestamp' assigned to mbuf packet in DPDK?

[Stephen Hemminger]

On Fri, 22 Nov 2019 22:30:11 +0530
Gokul Bargaje  wrote:

> Thank you for the clarification. But I am still unable to understand how
> exactly timestamp is calculated before assigning to a timestamp field.
> Could you please tell me the steps to calculate the timestamp in DPDK?
> 
> I have to implement the PIE AQM algorithm in DPDK and for that, I need to
> calculate the total time spent by the packet waiting in queue (i.e. the
> difference between enqueue time and dequeue time).

The use of timestamp field is very spotty.
Only mellanox implements it.

[dpdk-dev] [PATCH v3] hash: added a new API to hash to query key id

[Kumar Amber]

Adding new API function to query the maximum key ID
that could possibly returned by rte_hash_add_key and
rte_hash_add_key_with_hash. When RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD
is set, the maximum key id is larger than the entry count specified
by the user.

Signed-off-by: Kumar Amber 
---
 lib/librte_hash/rte_cuckoo_hash.c| 15 +++
 lib/librte_hash/rte_hash.h   | 25 +++--
 lib/librte_hash/rte_hash_version.map |  1 +
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/lib/librte_hash/rte_cuckoo_hash.c 
b/lib/librte_hash/rte_cuckoo_hash.c
index 87a4c01f2..3a94f10b8 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -506,6 +506,21 @@ rte_hash_hash(const struct rte_hash *h, const void *key)
return h->hash_func(key, h->key_len, h->hash_func_init_val);
 }
 
+uint32_t
+rte_hash_max_key_id(const struct rte_hash *h)
+{
+   RETURN_IF_TRUE((h == NULL), -EINVAL);
+   if (h->use_local_cache)
+   /*
+* Increase number of slots by total number of indices
+* that can be stored in the lcore caches
+*/
+   return (h->entries + ((RTE_MAX_LCORE - 1) *
+   (LCORE_CACHE_SIZE - 1)));
+   else
+   return h->entries;
+}
+
 int32_t
 rte_hash_count(const struct rte_hash *h)
 {
diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
index 0d73370dc..c87861e72 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -164,6 +164,23 @@ rte_hash_reset(struct rte_hash *h);
 int32_t
 rte_hash_count(const struct rte_hash *h);
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Return  the maximum key value ID that could possibly be returned by
+ * rte_hash_add_key function.
+ *
+ * @param h
+ *  Hash table to query from
+ * @return
+ *   - -EINVAL if parameters are invalid
+ *   - A value indicating the max key Id  key slots present in the table.
+ */
+__rte_experimental
+uint32_t
+rte_hash_max_key_id(const struct rte_hash *h);
+
 /**
  * Add a key-value pair to an existing hash table.
  * This operation is not multi-thread safe
@@ -234,7 +251,9 @@ rte_hash_add_key_with_hash_data(const struct rte_hash *h, 
const void *key,
  *   - -EINVAL if the parameters are invalid.
  *   - -ENOSPC if there is no space in the hash for this key.
  *   - A positive value that can be used by the caller as an offset into an
- * array of user data. This value is unique for this key.
+ * array of user data. This value is unique for this key. This
+ * unique key id may be larger than the user specified entry count
+ * when RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD flag is set.
  */
 int32_t
 rte_hash_add_key(const struct rte_hash *h, const void *key);
@@ -256,7 +275,9 @@ rte_hash_add_key(const struct rte_hash *h, const void *key);
  *   - -EINVAL if the parameters are invalid.
  *   - -ENOSPC if there is no space in the hash for this key.
  *   - A positive value that can be used by the caller as an offset into an
- * array of user data. This value is unique for this key.
+ * array of user data. This value is unique for this key. This
+ * unique key ID may be larger than the user specified entry count
+ * when RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD flag is set.
  */
 int32_t
 rte_hash_add_key_with_hash(const struct rte_hash *h, const void *key, 
hash_sig_t sig);
diff --git a/lib/librte_hash/rte_hash_version.map 
b/lib/librte_hash/rte_hash_version.map
index 734ae28b0..562ceb8bc 100644
--- a/lib/librte_hash/rte_hash_version.map
+++ b/lib/librte_hash/rte_hash_version.map
@@ -58,5 +58,6 @@ EXPERIMENTAL {
global:
 
rte_hash_free_key_with_position;
+rte_hash_max_key_id;
 
 };
-- 
2.17.1

Re: [dpdk-dev] [PATCH v2 3/3] ethdev: improve flow mark Rx offload deprecation notice

[Thomas Monjalon]

22/11/2019 12:53, Andrew Rybchenko:
> On 11/22/19 2:15 PM, Thomas Monjalon wrote:
> > 22/11/2019 11:12, Andrew Rybchenko:
> >> On 11/22/19 1:01 AM, Thomas Monjalon wrote:
> >>> 19/11/2019 13:12, Andrew Rybchenko:
>  The deprecation notice is required since it adds more requirements
>  when RTE flow mark and flag actions may be used and require
>  changes in applications.
> >>> I am still not sure what is the best solution here.
> >>> I continued to think about it in this thread:
> >>>   http://mails.dpdk.org/archives/dev/2019-November/151960.html
> >>>
> >>> I think we cannot require any application change until 20.11
> >>> in order to keep API (and behaviour) compatibility.
> >> Expected, but still very disappointing.
> >>
> >> The feature is implemented by Pavan (@ Marvell), supported by me,
> >> used by Qi (@ Intel), looks better than alternatives from application
> >> developer point of view [1] and finally postponed for 1 year without really
> >> strong motivation.
> > 
> > I see different valuable point of views. This is enough motivation.
> 
> It looks like I miss it in previous discussion, I would be thankful if
> you give me links to read or hints how to find.

http://mails.dpdk.org/archives/dev/2019-November/150793.html

> > And no, it is not postponed by one year.
> > Next release can implement a new API.
> >
> >> I disagree that it is tightly related to moving
> >> mark/flag to
> >> dynamic field/flag and absolutely blocked by it. Yes, I know that the are
> >> concerns from the very beginning, but the problem is explained [2] and 
> >> clear
> >> and no full-featured alternative solution is suggested. Solution suggested
> >> by Ori has many significant drawbacks as explained in [2] and highlighted
> >> in further discussion.
> > 
> > I disagree with working only on mark action while there are a lot
> > of other configs which have to be implemented in drivers.
> >
> > The reality is that some drivers decided to have some "optimizations"
> > disabling some features, and you want the application to opt-in
> > in order to allow your optimized paths.
> 
> Strictly speaking it is not about driver optimized paths only, but HW
> configuration as well which can be done on start-up only (not dynamic) and
> could be per-queue in fact.

OK good point, we can optimize both driver and hardware configuration
before enabling a queue.
Note all these threads are long but one of the benefits
is to get the definition of the need, which was lacking.

> > Note that opt-in is different of really enabling an offload.
> > For some basic port-level features like RSS hash,
> > it is enabled with an offload flag before starting the port,
> > acting as an opt-in.
> 
> Could you highlight the difference between opt-in and offload.
> What is the key difference which makes one solution better
> than another? Why different mechanism is required?

Configuring a feature means providing all infos to make
the processing effective.
Opt-in a feature means asking for a processing to be available
when it will be configured later.
Configuration implies opt-in of course.

For now, we have only configuration APIs, no opt-in.

The need you want to address is to opt-in for a feature
before enabling a queue, and configure it later.

> > Some features have some dedicated API, which may be enabled after
> > starting the port, and no way to opt-in (or opt-out) before start.
> 
> It sounds like you have examples in your mind. Please, share.

All rte_flow examples are some examples of configuration API
which can be done after start, without a way to opt-in in advance.
Other examples of APIs not clearly forbidden to use after start:
- rte_eth_dev_set_mtu()
- rte_eth_dev_vlan_filter()
- rte_eth_dev_rss_reta_update()
- rte_eth_mirror_rule_set()
- rte_eth_dev_udp_tunnel_port_add()
- rte_eth_dev_l2_tunnel_offload_set
- rte_eth_timesync_enable()

> > A lot of features are using rte_flow API which is in this situation.
> > If we take the opt-in path, let's not do it only for the mark action,
> > but let's create a real API for it:
> > rte_eth_dev_optin()
> > rte_eth_dev_optinall()
> > rte_eth_dev_optoutl()
> 
> Introducing new types of controls would make configuration more and
> more complex. I think that many different types of control would
> over-complicate it. May be it is unavoidable, but it should be clear
> why the problem cannot be solved using existing types of controls
> (e.g. offloads).

The offload control is used as an effective configuration for now.
The features which are configured with DEV_RX_OFFLOAD_*
do not need any other API to be used.
Extending DEV_RX_OFFLOAD_* bits for enabling features which
must be configured via other API anyway, is possible.
The real problem is that features in DEV_RX_OFFLOAD_* are supposed
to be disabled by default. If we add some opt-in features here,
we cannot enable them by default for API compatibility and do the
right thing

Re: [dpdk-dev] [EXT] Re: [PATCH] doc: update qede PMD guide

[Rasesh Mody]

Hi Ferruh,

>From: Ferruh Yigit 
>Sent: Friday, November 22, 2019 6:33 AM
>
>External Email
>
>--
>On 11/22/2019 7:51 AM, Rasesh Mody wrote:
>>  - Add note for Co-existence of DPDK and Linux drivers.
>>  - Update the firmware version in example.
>>  - Add Config note for potential error due to lack of memzone desciptor
>>count.
>>
>> Signed-off-by: Rasesh Mody 
>> ---
>>  doc/guides/nics/qede.rst | 25 -
>>  1 file changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst index
>> 2f4045795..9c14dd006 100644
>> --- a/doc/guides/nics/qede.rst
>> +++ b/doc/guides/nics/qede.rst
>> @@ -70,6 +70,10 @@ Co-existence considerations
>>to the PFs of a given adapter and either qede PMD or Linux drivers
>>(qed and qede) can be bound to the VFs of the adapter.
>>
>> +- To use DPDK on some PFs and Linux drivers on other PFs of an
>> +adapter,
>> +  create a VF each on the PFs where DPDK will be used, attach DPDK to
>> +  these VFs and Linux drivers to the other PFs where no VFs are created.
>
>But this won't be using DPDK on some PFs, you are indeed suggesting to
>create VFs and use them via DPDK instead. And should the PF not bound to
>any kernel driver?

For sharing an adapter between DPDK and Linux drivers, we are suggesting to use 
DPDK on a VF created on PFs. All the PFs would be bound to Linux 
drivers(qed/qede). I'll send out a v2 with modified text for more clarity.

Thanks!
-Rasesh

[dpdk-dev] [PATCH v2] doc: update qede PMD guide

[Rasesh Mody]

 - Add note for sharing an adapter between DPDK and Linux drivers.
 - Update the firmware version in example.
 - Add Config note for potential error due to lack of memzone desciptor
   count.

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

diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
index 2f4045795..1b08eaafc 100644
--- a/doc/guides/nics/qede.rst
+++ b/doc/guides/nics/qede.rst
@@ -70,6 +70,12 @@ Co-existence considerations
   to the PFs of a given adapter and either qede PMD or Linux drivers
   (qed and qede) can be bound to the VFs of the adapter.
 
+- For sharing an adapter between DPDK and Linux drivers, SRIOV needs
+  to be enabled. Bind all the PFs to Linux Drivers(qed/qede). Create
+  a VF on PFs where DPDK is desired and bind these VFs to qede_pmd.
+  Binding of PFs simultaneously to DPDK and Linux drivers on a given
+  adapter is not supported.
+
 Supported QLogic Adapters
 -
 
@@ -82,9 +88,7 @@ Prerequisites
   inbox in certain newer Linux distros under the standard directory
   ``E.g. /lib/firmware/qed/qed_init_values-8.40.33.0.bin``.
   If the required firmware files are not available then download it from
-  `linux-firmware git repository 
`_
-  or `QLogic Driver Download Center 
`_.
-  To download firmware file from QLogic website, select adapter category, 
model and DPDK Poll Mode Driver.
+  `linux-firmware git repository 
`_.
 
 - Requires the NIC be updated minimally with **8.30.x.x** Management 
firmware(MFW) version supported for that NIC.
   It is highly recommended that the NIC be updated with the latest available 
management firmware version to get latest feature  set.
@@ -99,7 +103,6 @@ Prerequisites
   `QLogic Driver Download Center 
`_.
   For downloading PF driver, select adapter category, model and Linux distro.
 
-
 Performance note
 
 
@@ -126,12 +129,26 @@ 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.37.7.0.bin"``
+  ``Eg: "/lib/firmware/qed/qed_init_values-8.40.33.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
   recommended for use under normal condition.
 
+Config notes
+
+
+When there are multiple adapters and/or large number of Rx/Tx queues
+configured on the adapters, the default (2560) number of memzone
+descriptors may not be enough. Please increase the number of memzone
+descriptors to a higher number as needed. When sufficient number of
+memzone descriptors are not configured, user can potentially run into
+following error.
+ 
+   .. code-block:: console
+ 
+  EAL: memzone_reserve_aligned_thread_unsafe(): No more room in config
+
 Driver compilation and testing
 --
 
-- 
2.18.0

[dpdk-dev] [PATCH] build: fix windows build failure for 19.11

[Pallavi Kadam]

This patch fixes Windows build failure caused due to
'config: change ABI versioning to global' patch.
This patch can be merged in 19.11 release.

Signed-off-by: Bruce Richardson 
Reviewed-by: Ranjit Menon 
Tested-by: Pallavi Kadam 
---
 config/meson.build | 2 +-
 meson.build| 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/config/meson.build b/config/meson.build
index 3ffb73ab9..364a8d739 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -19,7 +19,7 @@ endforeach
 pver = meson.project_version().split('.')
 major_version = '@0@.@1@'.format(pver.get(0), pver.get(1))
 abi_version = run_command(find_program('cat', 'more'),
-   files('../ABI_VERSION')).stdout().strip()
+   abi_version_file).stdout().strip()
 # experimental libraries are versioned as 0.majorminor versions, e.g. 0.201
 ever = abi_version.split('.')
 experimental_abi_version = '0.@0@@1@'.format(ever.get(0), ever.get(1))
diff --git a/meson.build b/meson.build
index c5a3dda26..b7ae9c8d9 100644
--- a/meson.build
+++ b/meson.build
@@ -22,6 +22,7 @@ dpdk_extra_ldflags = []
 dpdk_app_link_libraries = []
 dpdk_libs_disabled = []
 dpdk_drvs_disabled = []
+abi_version_file = files('ABI_VERSION')
 
 # configure the build, and make sure configs here and in config folder are
 # able to be included in any file. We also store a global array of include dirs
-- 
2.18.0.windows.1

[dpdk-dev] [PATCH] net/mlx5: support more than 16 modify actions

[Bing Zhao]

In the root table, there is some limitation of total number of header
modify actions, 16 or 8 for each. But in other tables, there is no
such strict limitation. In an IPv6 case, the IP fields modifying
will occupy more actions than that in IPv4, so the total support
number should be increased in order to support as many actions as
possible for IPv6 + TCP packet.
And in the meanwhile, the memory consumption should also be taken
into consideration because sometimes only several actions are needed.
The root table checking could also be done in low layer driver and
the error code will be returned if the actions are not supported.

Signed-off-by: Bing Zhao 
---
 drivers/net/mlx5/mlx5_flow.h|  15 +++---
 drivers/net/mlx5/mlx5_flow_dv.c | 104 ++--
 2 files changed, 66 insertions(+), 53 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 3fff5dd..0ad0fc1 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -370,11 +370,14 @@ struct mlx5_flow_dv_tag_resource {
 
 /*
  * Number of modification commands.
- * If extensive metadata registers are supported
- * the maximal actions amount is 16 and 8 otherwise.
+ * If extensive metadata registers are supported, the maximal actions amount is
+ * 16 and 8 otherwise on root table. The validation could also be done in the
+ * lower driver layer.
+ * On non-root table, there is no limitation, but 32 is enough right now.
  */
-#define MLX5_MODIFY_NUM 16
-#define MLX5_MODIFY_NUM_NO_MREG 8
+#define MLX5_MAX_MODIFY_NUM32
+#define MLX5_ROOT_TBL_MODIFY_NUM   16
+#define MLX5_ROOT_TBL_MODIFY_NUM_NO_MREG   8
 
 /* Modify resource structure */
 struct mlx5_flow_dv_modify_hdr_resource {
@@ -385,9 +388,9 @@ struct mlx5_flow_dv_modify_hdr_resource {
/**< Verbs modify header action object. */
uint8_t ft_type; /**< Flow table type, Rx or Tx. */
uint32_t actions_num; /**< Number of modification actions. */
-   struct mlx5_modification_cmd actions[MLX5_MODIFY_NUM];
-   /**< Modification actions. */
uint64_t flags; /**< Flags for RDMA API. */
+   struct mlx5_modification_cmd actions[];
+   /**< Modification actions. */
 };
 
 /* Jump action resource structure. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 02f20fb..75d28bd 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -356,7 +356,7 @@ struct field_modify_info modify_tcp[] = {
uint32_t mask;
uint32_t data;
 
-   if (i >= MLX5_MODIFY_NUM)
+   if (i >= MLX5_MAX_MODIFY_NUM)
return rte_flow_error_set(error, EINVAL,
 RTE_FLOW_ERROR_TYPE_ACTION, NULL,
 "too many items to modify");
@@ -397,11 +397,11 @@ struct field_modify_info modify_tcp[] = {
++i;
++field;
} while (field->size);
-   resource->actions_num = i;
-   if (!resource->actions_num)
+   if (resource->actions_num == i)
return rte_flow_error_set(error, EINVAL,
  RTE_FLOW_ERROR_TYPE_ACTION, NULL,
  "invalid modification flow item");
+   resource->actions_num = i;
return 0;
 }
 
@@ -562,7 +562,7 @@ struct field_modify_info modify_tcp[] = {
struct mlx5_modification_cmd *actions = &resource->actions[i];
struct field_modify_info *field = modify_vlan_out_first_vid;
 
-   if (i >= MLX5_MODIFY_NUM)
+   if (i >= MLX5_MAX_MODIFY_NUM)
return rte_flow_error_set(error, EINVAL,
 RTE_FLOW_ERROR_TYPE_ACTION, NULL,
 "too many items to modify");
@@ -895,7 +895,7 @@ struct field_modify_info modify_tcp[] = {
struct mlx5_modification_cmd *actions = resource->actions;
uint32_t i = resource->actions_num;
 
-   if (i >= MLX5_MODIFY_NUM)
+   if (i >= MLX5_MAX_MODIFY_NUM)
return rte_flow_error_set(error, EINVAL,
  RTE_FLOW_ERROR_TYPE_ACTION, NULL,
  "too many items to modify");
@@ -907,10 +907,6 @@ struct field_modify_info modify_tcp[] = {
actions[i].data1 = rte_cpu_to_be_32(conf->data);
++i;
resource->actions_num = i;
-   if (!resource->actions_num)
-   return rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ACTION, NULL,
- "invalid modification flow item");
return 0;
 }
 
@@ -2241,7 +2237,6 @@ struct field_modify_info modify_tcp[] = {
domain = sh->rx_domain;
else
domain = sh->tx_domain;
-
/* Lookup a matching resource from cache. */
LIST_FOREACH(cache_resource