Re: [dpdk-dev] [PATCH v4 2/3] examples/ipsec-secgw: add target queues in flow actions

[Anoob Joseph]

Hi Nelio,


On 12/14/2017 08:44 PM, Nelio Laranjeiro wrote:

Mellanox INNOVA NIC needs to have final target queue actions to perform
inline crypto.

Signed-off-by: Nelio Laranjeiro 

---

Changes in v4:

  * remove Egress code.

Changes in v3:

  * removed PASSTHRU test for ingress.
  * removed check on configured queues for the queue action.

Changes in v2:

  * Test the rule by PASSTHRU/RSS/QUEUE and apply the first one validated.
---
  examples/ipsec-secgw/ipsec.c | 53 ++--
  examples/ipsec-secgw/ipsec.h |  2 +-
  2 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 17bd7620d..8e8dc6df7 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -142,6 +142,7 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa 
*sa)
rte_eth_dev_get_sec_ctx(
sa->portid);
const struct rte_security_capability *sec_cap;
+   int ret = 0;
  
  			sa->sec_session = rte_security_session_create(ctx,

&sess_conf, ipsec_ctx->session_pool);
@@ -201,15 +202,63 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct 
ipsec_sa *sa)
sa->action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
sa->action[0].conf = sa->sec_session;
  
-			sa->action[1].type = RTE_FLOW_ACTION_TYPE_END;
This is reverted in the second patch, right? Are you planning to revise 
the patch fixing this? I'm fine with the changes, otherwise.

-
sa->attr.egress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
sa->attr.ingress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
+   if (sa->attr.ingress) {
+   uint8_t rss_key[40];
+   struct rte_eth_rss_conf rss_conf = {
+   .rss_key = rss_key,
+   .rss_key_len = 40,
+   };
+   struct rte_eth_dev *eth_dev;
+   union {
+   struct rte_flow_action_rss rss;
+   struct {
+   const struct rte_eth_rss_conf *rss_conf;
+   uint16_t num;
+   uint16_t queue[RTE_MAX_QUEUES_PER_PORT];
+   } local;
+   } action_rss;
+   unsigned int i;
+   unsigned int j;
+
+   sa->action[2].type = RTE_FLOW_ACTION_TYPE_END;
+   /* Try RSS. */
+   sa->action[1].type = RTE_FLOW_ACTION_TYPE_RSS;
+   sa->action[1].conf = &action_rss;
+   eth_dev = ctx->device;
+   rte_eth_dev_rss_hash_conf_get(sa->portid,
+ &rss_conf);
+   for (i = 0, j = 0;
+i < eth_dev->data->nb_rx_queues; ++i)
+   if (eth_dev->data->rx_queues[i])
+   action_rss.local.queue[j++] = i;
+   action_rss.local.num = j;
+   action_rss.local.rss_conf = &rss_conf;
+   ret = rte_flow_validate(sa->portid, &sa->attr,
+   sa->pattern, sa->action,
+   &err);
+   if (!ret)
+   goto flow_create;
+   /* Try Queue. */
+   sa->action[1].type = RTE_FLOW_ACTION_TYPE_QUEUE;
+   sa->action[1].conf =
+   &(struct rte_flow_action_queue){
+   .index = 0,
+   };
+   ret = rte_flow_validate(sa->portid, &sa->attr,
+   sa->pattern, sa->action,
+   &err);
+   if (ret)
+   goto flow_create_failure;
+   }
+flow_create:
sa->flow = rte_flow_create(sa->portid,
&sa->attr, sa->pattern, sa->action, &err);

Re: [dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW active pool

[Jerin Jacob]

-Original Message-
> Date: Fri, 15 Dec 2017 15:54:42 +0530
> From: Hemant Agrawal 
> To: olivier.m...@6wind.com, santosh.shu...@caviumnetworks.com
> CC: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW
>  active pool
> X-Mailer: git-send-email 2.7.4
> 
> With this patch the specific HW mempool are no longer required to be
> specified in the config file at compile. A default active hw mempool
> can be detected dynamically and published to default mempools ops
> config at run time. Only one type of HW mempool can be active default.

For me, it looks very reasonable approach as it caters the basic use
case without any change in the application nor the 
additional(--mbuf-pool-ops-name)
EAL command line scheme to select different mempool ops.
Though, this option will not enough cater all the use case. I think, we can have
three options and the following order of precedence to select the mempool ops

1) This patch(update active mempool based on the device probe())
2) Selection of mempool ops though --mbuf-pool-ops-name= EAL commandline 
argument.
Which can overridden the scheme(1)
3) More sophisticated mempool section based on
a) The ethdev PMD capability exposed through existing 
rte_eth_dev_pool_ops_supported()
b) Add mempool ops option in rte_pktmbuf_pool_create()
http://dpdk.org/ml/archives/dev/2017-December/083985.html
c) Use (a) and (b) to select the update the mempool ops with
some "weight" based algorithm like
http://dpdk.org/dev/patchwork/patch/32245/

> 
> Signed-off-by: Hemant Agrawal 
> ---
>  lib/librte_mbuf/rte_mbuf.c | 33 -
>  lib/librte_mbuf/rte_mbuf.h | 13 +
>  2 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> index 7543662..e074afa 100644
> --- a/lib/librte_mbuf/rte_mbuf.c
> +++ b/lib/librte_mbuf/rte_mbuf.c
> @@ -148,6 +148,37 @@ rte_pktmbuf_init(struct rte_mempool *mp,
>   m->next = NULL;
>  }
>  
> +static const char *active_mbuf_pool_ops_name;

Global variable will create issue in multi process case.

> +
> +int
> +rte_pktmbuf_reg_active_mempool_ops(const char *ops_name)
> +{
> + if (active_mbuf_pool_ops_name == NULL) {
> + active_mbuf_pool_ops_name = ops_name;

I think, if we could update "internal_config.mbuf_pool_ops_name" value then
we don't need any extra global variable.

Re: [dpdk-dev] [PATCH 2/2] dpaa2: register dpaa2 mempool ops as active mempool

[Jerin Jacob]

-Original Message-
> Date: Fri, 15 Dec 2017 15:54:43 +0530
> From: Hemant Agrawal 
> To: olivier.m...@6wind.com, santosh.shu...@caviumnetworks.com
> CC: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 2/2] dpaa2: register dpaa2 mempool ops as active
>  mempool
> X-Mailer: git-send-email 2.7.4
> 
> Detect if the DPAA2 mempool objects are present and they can
> serve as default mempool.
> 
> Signed-off-by: Hemant Agrawal 
> ---
>  config/defconfig_arm64-dpaa2-linuxapp-gcc | 1 -
>  drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c  | 6 ++
>  drivers/bus/fslmc/portal/dpaa2_hw_pvt.h   | 2 ++
>  drivers/mempool/dpaa2/dpaa2_hw_mempool.c  | 2 +-
>  4 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
> b/config/defconfig_arm64-dpaa2-linuxapp-gcc
> index 91f4993..703e8b3 100644
> --- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
> +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
> @@ -53,7 +53,6 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n
>  # Compile Support Libraries for DPAA2
>  #
>  CONFIG_RTE_LIBRTE_DPAA2_MEMPOOL=y
> -CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS="dpaa2"
>  CONFIG_RTE_LIBRTE_DPAA2_USE_PHYS_IOVA=n
>  
>  #
> diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c 
> b/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
> index 334e1f5..5a6f292 100644
> --- a/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
> +++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
> @@ -64,6 +64,7 @@ dpaa2_create_dpbp_device(int vdev_fd __rte_unused,
>  {
>   struct dpaa2_dpbp_dev *dpbp_node;
>   int ret;
> + static int active_pool;
>  
>   /* Allocate DPAA2 dpbp handle */
>   dpbp_node = rte_malloc(NULL, sizeof(struct dpaa2_dpbp_dev), 0);
> @@ -100,6 +101,11 @@ dpaa2_create_dpbp_device(int vdev_fd __rte_unused,
>  
>   RTE_LOG(DEBUG, PMD, "DPAA2: Added [dpbp.%d]\n", dpbp_id);
>  
> + if (!active_pool) {

I think, this global variable can be avoided. Why it needs to be under 
active_pool?

Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for pktmbuf pool create API

[Jerin Jacob]

-Original Message-
> Date: Fri, 15 Dec 2017 16:11:22 +0530
> From: Hemant Agrawal 
> To: olivier.m...@6wind.com
> CC: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2] doc: announce ABI change for pktmbuf pool
>  create API
> X-Mailer: git-send-email 2.7.4
> 
> Introduce a new argument ops_name in rte_mempool_set_ops_byname
> for allowing the application to optionally specify the mempool ops.
> 
> Signed-off-by: Hemant Agrawal 

Acked-by: Jerin Jacob 

> ---
> v2: fix checkpatch error
> 
>  doc/guides/rel_notes/deprecation.rst | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index 13e8543..968ca14 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -53,3 +53,6 @@ Deprecation Notices
>  
>  * librte_meter: The API will change to accommodate configuration profiles.
>Most of the API functions will have an additional opaque parameter.
> +
> +* librte_mbuf: a new optional parameter for representing name of mempool_ops
> +  will be added to the API ``rte_pktmbuf_pool_create``.
> -- 
> 2.7.4
> 

Re: [dpdk-dev] [PATCH] net/octeontx: advertise supported mbuf pool ops

[santosh]

On Thursday 14 December 2017 02:01 PM, Pavan Nikhilesh wrote:
> Advertise mempool/octeontx as the only supported mempool ops when the
> application checks using `rte_eth_dev_pool_ops_supported`.
>
> Signed-off-by: Pavan Nikhilesh 
> ---

Acked-by: Santosh Shukla 

Re: [dpdk-dev] [PATCH 0/6] event/dpaa: Support for eventdev

[Jerin Jacob]

-Original Message-
> Date: Fri, 15 Dec 2017 18:29:27 +0530
> From: Sunil Kumar Kori 
> To: jerin.ja...@caviumnetworks.com
> CC: dev@dpdk.org, hemant.agra...@nxp.com
> Subject: [PATCH 0/6] event/dpaa: Support for eventdev
> X-Mailer: git-send-email 2.9.3
> 
> Event device support for atomic and parallel queues.
> 
> This patch set includes following changes:
>   1. Configuration of atomic and parallel queues with given event device.
>   2. Also maintains previous dequeue method, via poll mode queues.
>   3. Added Rx functions to dequeue data from portal.
>   4. DCA consumption logic for atomic queues.
>   5. Dynamic Logging macros for event device
> 
> Sunil Kumar Kori (6):
>   bus/dpaa: added event dequeue and consumption support
>   bus/dpaa: add dpaa eventdev dynamic log support
>   net/dpaa: ethdev Rx queue configurations with eventdev
>   event/dpaa: add eventdev PMD
>   config: enabling compilation of DPAA eventdev PMD
>   doc: add DPAA eventdev guide
> 
>  config/common_base|   4 +
>  config/defconfig_arm64-dpaa-linuxapp-gcc  |   3 +
>  doc/guides/eventdevs/dpaa.rst | 144 +
>  doc/guides/eventdevs/index.rst|   1 +
>  drivers/bus/dpaa/base/qbman/qman.c|  90 ++-
>  drivers/bus/dpaa/dpaa_bus.c   |   6 +
>  drivers/bus/dpaa/include/fsl_qman.h   |  26 +-
>  drivers/bus/dpaa/rte_bus_dpaa_version.map |   6 +
>  drivers/bus/dpaa/rte_dpaa_bus.h   |  14 +
>  drivers/bus/dpaa/rte_dpaa_logs.h  |  16 +
>  drivers/event/Makefile|   1 +
>  drivers/event/dpaa/Makefile   |  37 ++
>  drivers/event/dpaa/dpaa_eventdev.c| 652 
> ++
>  drivers/event/dpaa/dpaa_eventdev.h|  86 +++
>  drivers/event/dpaa/rte_pmd_dpaa_event_version.map |   4 +
>  drivers/net/dpaa/Makefile |   2 +
>  drivers/net/dpaa/dpaa_ethdev.c| 110 +++-
>  drivers/net/dpaa/dpaa_ethdev.h|  29 +
>  drivers/net/dpaa/dpaa_rxtx.c  |  79 ++-
>  drivers/net/dpaa/rte_pmd_dpaa_version.map |   2 +
>  mk/rte.app.mk |   1 +

Please update the MAINTAINERS file and release notes.

>  21 files changed, 1296 insertions(+), 17 deletions(-)
>  create mode 100644 doc/guides/eventdevs/dpaa.rst
>  create mode 100644 drivers/event/dpaa/Makefile
>  create mode 100644 drivers/event/dpaa/dpaa_eventdev.c
>  create mode 100644 drivers/event/dpaa/dpaa_eventdev.h
>  create mode 100644 drivers/event/dpaa/rte_pmd_dpaa_event_version.map
> 
> -- 
> 2.9.3
> 

Re: [dpdk-dev] [RFC v2 PATCH 0/8] event: eventdev OPDL PMD

[Jerin Jacob]

-Original Message-
> Date: Fri, 15 Dec 2017 11:26:21 +
> From: Liang Ma 
> To: jerin.ja...@caviumnetworks.com
> CC: dev@dpdk.org, harry.van.haa...@intel.com, bruce.richard...@intel.com,
>  deepak.k.j...@intel.com, john.ge...@intel.com, peter.mccar...@intel.com,
>  sea...@gmail.com
> Subject: [RFC v2 PATCH 0/8] event: eventdev OPDL PMD
> X-Mailer: git-send-email 2.7.5
> 
> The OPDL (Ordered Packet Distribution Library) eventdev is a specific
> implementation of the eventdev API. It is particularly suited to packet
> processing workloads that have high throughput and low latency 
> requirements. All packets follow the same path through the device.
> The order which packets  follow is determinted by the order in which
> queues are set up. Packets are left on the ring until they are transmitted.
> As a result packets do not go out of order.
> 
> Liang Ma (8):
>   event/opdl:  add the opdl ring infrastructure library
>   event/opdl: add the opdl pmd header and init helper function
>   event/opdl: add the opdl pmd main body and xstats helper function
>   eventdev/opdl: opdl eventdev pmd unit test function
>   lib/librte_eventdev: extend the eventdev capability flags
>   event/*: apply the three new capability flags for sw/dppa2/octeontx
>   event/opdl: update the build system to enable compilation
>   doc: add eventdev opdl pmd docuement
> 
>  config/common_base|6 +
>  doc/guides/eventdevs/index.rst|1 +
>  doc/guides/eventdevs/opdl.rst |  162 +++
>  drivers/event/Makefile|1 +
>  drivers/event/dpaa2/dpaa2_eventdev.c  |5 +-
>  drivers/event/octeontx/ssovf_evdev.c  |5 +-
>  drivers/event/opdl/Makefile   |   66 ++
>  drivers/event/opdl/opdl_evdev.c   |  744 +
>  drivers/event/opdl/opdl_evdev.h   |  354 ++
>  drivers/event/opdl/opdl_evdev_init.c  |  951 
>  drivers/event/opdl/opdl_evdev_xstats.c|  205 
>  drivers/event/opdl/opdl_ring.c| 1232 
> +
>  drivers/event/opdl/opdl_ring.h|  601 ++
>  drivers/event/opdl/opdl_test.c| 1079 ++
>  drivers/event/opdl/rte_pmd_evdev_opdl_version.map |3 +
>  drivers/event/sw/sw_evdev.c   |5 +-
>  lib/librte_eventdev/rte_eventdev.h|   22 +
>  mk/rte.app.mk |1 +

Please update the MAINTAINERS file and the release note.

Re: [dpdk-dev] [PATCH 2/2] dpaa2: register dpaa2 mempool ops as active mempool

[Hemant Agrawal]

On 12/18/2017 2:27 PM, Jerin Jacob wrote:

...


diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c 
b/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
index 334e1f5..5a6f292 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
@@ -64,6 +64,7 @@ dpaa2_create_dpbp_device(int vdev_fd __rte_unused,
 {
struct dpaa2_dpbp_dev *dpbp_node;
int ret;
+   static int active_pool;

/* Allocate DPAA2 dpbp handle */
dpbp_node = rte_malloc(NULL, sizeof(struct dpaa2_dpbp_dev), 0);
@@ -100,6 +101,11 @@ dpaa2_create_dpbp_device(int vdev_fd __rte_unused,

RTE_LOG(DEBUG, PMD, "DPAA2: Added [dpbp.%d]\n", dpbp_id);

+   if (!active_pool) {


I think, this global variable can be avoided. Why it needs to be under
active_pool?

This code register the active pool when it physically detect a instance 
of hw mempool on bus. There can be more than one objects of dpaa2 
mempool. Yes! we can do avoid it as the current registration code 
proposal will not allow re-registration.

Re: [dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW active pool

[Hemant Agrawal]

On 12/15/2017 9:22 PM, Stephen Hemminger wrote:

On Fri, 15 Dec 2017 15:54:42 +0530
Hemant Agrawal  wrote:


+   if ((strcmp(default_ops, RTE_MBUF_DEFAULT_MEMPOOL_OPS) == 0) &&
+   (active_mbuf_pool_ops_name != NULL))


Why not have less parenthesis () in conditionals?


I will change it in next version.

Re: [dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW active pool

[Hemant Agrawal]

On 12/18/2017 2:25 PM, Jerin Jacob wrote:

-Original Message-

Date: Fri, 15 Dec 2017 15:54:42 +0530
From: Hemant Agrawal 
To: olivier.m...@6wind.com, santosh.shu...@caviumnetworks.com
CC: dev@dpdk.org
Subject: [dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW
 active pool
X-Mailer: git-send-email 2.7.4

With this patch the specific HW mempool are no longer required to be
specified in the config file at compile. A default active hw mempool
can be detected dynamically and published to default mempools ops
config at run time. Only one type of HW mempool can be active default.


For me, it looks very reasonable approach as it caters the basic use
case without any change in the application nor the 
additional(--mbuf-pool-ops-name)
EAL command line scheme to select different mempool ops.
Though, this option will not enough cater all the use case. I think, we can have
three options and the following order of precedence to select the mempool ops

1) This patch(update active mempool based on the device probe())
2) Selection of mempool ops though --mbuf-pool-ops-name= EAL commandline 
argument.
Which can overridden the scheme(1)
3) More sophisticated mempool section based on
a) The ethdev PMD capability exposed through existing 
rte_eth_dev_pool_ops_supported()
b) Add mempool ops option in rte_pktmbuf_pool_create()
http://dpdk.org/ml/archives/dev/2017-December/083985.html
c) Use (a) and (b) to select the update the mempool ops with
some "weight" based algorithm like
http://dpdk.org/dev/patchwork/patch/32245/



Yes! We need more options to fine tune control over the mempool uses, 
specially when dealing with HW mempools.


Once the above mentioned mechanisms will be in place, it will be much 
easier and flexible.




Signed-off-by: Hemant Agrawal 
---
 lib/librte_mbuf/rte_mbuf.c | 33 -
 lib/librte_mbuf/rte_mbuf.h | 13 +
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 7543662..e074afa 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -148,6 +148,37 @@ rte_pktmbuf_init(struct rte_mempool *mp,
m->next = NULL;
 }

+static const char *active_mbuf_pool_ops_name;


Global variable will create issue in multi process case.


+
+int
+rte_pktmbuf_reg_active_mempool_ops(const char *ops_name)
+{
+   if (active_mbuf_pool_ops_name == NULL) {
+   active_mbuf_pool_ops_name = ops_name;


I think, if we could update "internal_config.mbuf_pool_ops_name" value then
we don't need any extra global variable.



That is a good suggestion.
Also, We may need additional variable in internal config to indicate 
that this is a application provided ops_name - so that it should not be 
overwritten.

Re: [dpdk-dev] [PATCH v2 1/2] net/octeontx: add channel to port id mapping

[santosh]

On Saturday 09 December 2017 06:25 PM, Pavan Nikhilesh wrote:
> The channel to port id map is used by event octeontx to map the received
> wqe to the respective ethdev port.
>
> Signed-off-by: Pavan Nikhilesh 
> ---
>
>  v2 changes:
>   - Used extern instead of defining global variable
>
>  drivers/net/octeontx/octeontx_ethdev.c| 6 ++
>  drivers/net/octeontx/octeontx_ethdev.h| 6 ++
>  drivers/net/octeontx/rte_pmd_octeontx_version.map | 6 ++
>  3 files changed, 18 insertions(+)
>
> diff --git a/drivers/net/octeontx/octeontx_ethdev.c 
> b/drivers/net/octeontx/octeontx_ethdev.c
> index bd24ec330..46cb061b4 100644
> --- a/drivers/net/octeontx/octeontx_ethdev.c
> +++ b/drivers/net/octeontx/octeontx_ethdev.c
> @@ -54,6 +54,9 @@ struct octeontx_vdev_init_params {
>   uint8_t nr_port;
>  };
>
> +uint16_t
> +octeontx_pchan_map[OCTEONTX_MAX_BGX_PORTS][OCTEONTX_MAX_LMAC_PER_BGX];
> +
>  enum octeontx_link_speed {
>   OCTEONTX_LINK_SPEED_SGMII,
>   OCTEONTX_LINK_SPEED_XAUI,
> @@ -1133,6 +1136,9 @@ octeontx_create(struct rte_vdev_device *dev, int port, 
> uint8_t evdev,
>   nic->num_tx_queues);
>   PMD_INIT_LOG(DEBUG, "speed %d mtu %d", nic->speed, nic->mtu);
>
> + octeontx_pchan_map[(nic->base_ochan >> 8) & 0x7]
> + [(nic->base_ochan >> 4) & 0xF] = data->port_id;
> +
>   return data->port_id;
>
>  err:
> diff --git a/drivers/net/octeontx/octeontx_ethdev.h 
> b/drivers/net/octeontx/octeontx_ethdev.h
> index c47d4c6d3..f046595a8 100644
> --- a/drivers/net/octeontx/octeontx_ethdev.h
> +++ b/drivers/net/octeontx/octeontx_ethdev.h
> @@ -52,12 +52,18 @@
>  #define OCTEONTX_VDEV_NR_PORT_ARG("nr_port")
>  #define OCTEONTX_MAX_NAME_LEN32
>
> +#define OCTEONTX_MAX_BGX_PORTS   4
> +#define OCTEONTX_MAX_LMAC_PER_BGX4
> +
>  static inline struct octeontx_nic *
>  octeontx_pmd_priv(struct rte_eth_dev *dev)
>  {
>   return dev->data->dev_private;
>  }
>
> +extern uint16_t
> +octeontx_pchan_map[OCTEONTX_MAX_BGX_PORTS][OCTEONTX_MAX_LMAC_PER_BGX];
> +
>  /* Octeontx ethdev nic */
>  struct octeontx_nic {
>   struct rte_eth_dev *dev;
> diff --git a/drivers/net/octeontx/rte_pmd_octeontx_version.map 
> b/drivers/net/octeontx/rte_pmd_octeontx_version.map
> index a70bd197b..3ec12ddb1 100644
> --- a/drivers/net/octeontx/rte_pmd_octeontx_version.map
> +++ b/drivers/net/octeontx/rte_pmd_octeontx_version.map
> @@ -2,3 +2,9 @@ DPDK_17.11 {
>
>   local: *;
>  };
> +
> +DPDK_18.04 {
> + global:
> +
> + octeontx_pchan_map;
> +};

nits: better be rte_octeontx_pchan_map
refer 
http://dpdk.org/browse/dpdk/tree/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map#n4

Acked-by: Santosh Shukla 

Re: [dpdk-dev] [PATCH v2 2/2] event/octeontx: fix Rx adapter port id mapping

[santosh]

On Saturday 09 December 2017 06:25 PM, Pavan Nikhilesh wrote:
> When octeontx event dev receives a packet for the event Rx adapter, the
> mbuf port id should contain the appropriate ethdev id instead of
> internal channel info.
>
> Fixes: 45a914c5bd71 ("event/octeontx: support event Rx adapter")
>
> Signed-off-by: Pavan Nikhilesh 
> ---

Acked-by: Santosh Shukla 

Re: [dpdk-dev] [PATCH v4 2/3] examples/ipsec-secgw: add target queues in flow actions

[Nélio Laranjeiro]

Hi Anoob,

On Mon, Dec 18, 2017 at 01:53:50PM +0530, Anoob Joseph wrote:
> Hi Nelio,
> 
> 
> On 12/14/2017 08:44 PM, Nelio Laranjeiro wrote:
> > Mellanox INNOVA NIC needs to have final target queue actions to perform
> > inline crypto.
> > 
> > Signed-off-by: Nelio Laranjeiro 
> > 
> > ---
> > 
> > Changes in v4:
> > 
> >   * remove Egress code.
> > 
> > Changes in v3:
> > 
> >   * removed PASSTHRU test for ingress.
> >   * removed check on configured queues for the queue action.
> > 
> > Changes in v2:
> > 
> >   * Test the rule by PASSTHRU/RSS/QUEUE and apply the first one validated.
> > ---
> >   examples/ipsec-secgw/ipsec.c | 53 
> > ++--
> >   examples/ipsec-secgw/ipsec.h |  2 +-
> >   2 files changed, 52 insertions(+), 3 deletions(-)
> > 
> > diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> > index 17bd7620d..8e8dc6df7 100644
> > --- a/examples/ipsec-secgw/ipsec.c
> > +++ b/examples/ipsec-secgw/ipsec.c
> > @@ -142,6 +142,7 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct 
> > ipsec_sa *sa)
> > rte_eth_dev_get_sec_ctx(
> > sa->portid);
> > const struct rte_security_capability *sec_cap;
> > +   int ret = 0;
> > sa->sec_session = rte_security_session_create(ctx,
> > &sess_conf, ipsec_ctx->session_pool);
> > @@ -201,15 +202,63 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct 
> > ipsec_sa *sa)
> > sa->action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
> > sa->action[0].conf = sa->sec_session;
> > -   sa->action[1].type = RTE_FLOW_ACTION_TYPE_END;
> This is reverted in the second patch, right? Are you planning to revise the
> patch fixing this? I'm fine with the changes, otherwise.


Yes I will send a v5 fixing this point.

Thanks,

-- 
Nélio Laranjeiro
6WIND

[dpdk-dev] [PATCH v5 1/3] examples/ipsec-secgw: fix missing ingress flow attribute

[Nelio Laranjeiro]

Generic flow API have both direction bits, ingress and egress for rules
which may work on both sides.

Fixes: ec17993a145a ("examples/ipsec-secgw: support security offload")
Cc: akhil.go...@nxp.com

Signed-off-by: Nelio Laranjeiro 
Acked-by: Radu Nicolau 
Acked-by: Anoob Joseph 
---
 examples/ipsec-secgw/ipsec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index ec8bf95e1..17bd7620d 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -205,6 +205,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa 
*sa)
 
sa->attr.egress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
+   sa->attr.ingress = (sa->direction ==
+   RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
sa->flow = rte_flow_create(sa->portid,
&sa->attr, sa->pattern, sa->action, &err);
if (sa->flow == NULL) {
-- 
2.11.0

[dpdk-dev] [PATCH v5 2/3] examples/ipsec-secgw: add target queues in flow actions

[Nelio Laranjeiro]

Mellanox INNOVA NIC needs to have final target queue actions to perform
inline crypto.

Signed-off-by: Nelio Laranjeiro 

---

Changes in v5:

 * Add back default second action.

Changes in v4:

 * remove Egress code.

Changes in v3:

 * removed PASSTHRU test for ingress.
 * removed check on configured queues for the queue action.

Changes in v2:

 * Test the rule by PASSTHRU/RSS/QUEUE and apply the first one validated.
---
 examples/ipsec-secgw/ipsec.c | 51 
 examples/ipsec-secgw/ipsec.h |  2 +-
 2 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 17bd7620d..37a6416ed 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -142,6 +142,7 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa 
*sa)
rte_eth_dev_get_sec_ctx(
sa->portid);
const struct rte_security_capability *sec_cap;
+   int ret = 0;
 
sa->sec_session = rte_security_session_create(ctx,
&sess_conf, ipsec_ctx->session_pool);
@@ -207,9 +208,59 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct 
ipsec_sa *sa)
RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
sa->attr.ingress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
+   if (sa->attr.ingress) {
+   uint8_t rss_key[40];
+   struct rte_eth_rss_conf rss_conf = {
+   .rss_key = rss_key,
+   .rss_key_len = 40,
+   };
+   struct rte_eth_dev *eth_dev;
+   union {
+   struct rte_flow_action_rss rss;
+   struct {
+   const struct rte_eth_rss_conf *rss_conf;
+   uint16_t num;
+   uint16_t queue[RTE_MAX_QUEUES_PER_PORT];
+   } local;
+   } action_rss;
+   unsigned int i;
+   unsigned int j;
+
+   sa->action[2].type = RTE_FLOW_ACTION_TYPE_END;
+   /* Try RSS. */
+   sa->action[1].type = RTE_FLOW_ACTION_TYPE_RSS;
+   sa->action[1].conf = &action_rss;
+   eth_dev = ctx->device;
+   rte_eth_dev_rss_hash_conf_get(sa->portid,
+ &rss_conf);
+   for (i = 0, j = 0;
+i < eth_dev->data->nb_rx_queues; ++i)
+   if (eth_dev->data->rx_queues[i])
+   action_rss.local.queue[j++] = i;
+   action_rss.local.num = j;
+   action_rss.local.rss_conf = &rss_conf;
+   ret = rte_flow_validate(sa->portid, &sa->attr,
+   sa->pattern, sa->action,
+   &err);
+   if (!ret)
+   goto flow_create;
+   /* Try Queue. */
+   sa->action[1].type = RTE_FLOW_ACTION_TYPE_QUEUE;
+   sa->action[1].conf =
+   &(struct rte_flow_action_queue){
+   .index = 0,
+   };
+   ret = rte_flow_validate(sa->portid, &sa->attr,
+   sa->pattern, sa->action,
+   &err);
+   if (ret)
+   goto flow_create_failure;
+   }
+flow_create:
sa->flow = rte_flow_create(sa->portid,
&sa->attr, sa->pattern, sa->action, &err);
if (sa->flow == NULL) {
+flow_create_failure:
RTE_LOG(ERR, IPSEC,
"Failed to create ipsec flow msg: %s\n",
err.message);
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index 775b316ff..3c367d392 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/i

[dpdk-dev] [PATCH v5 3/3] examples/ipsec-secgw: add Egress flow actions

[Nelio Laranjeiro]

Add Egress flow create for devices supporting
RTE_SECURITY_TX_HW_TRAILER_OFFLOAD.

Signed-off-by: Nelio Laranjeiro 

--

Changes in v5:

 * removed default second end actions wrongly added in this patch.
---
 examples/ipsec-secgw/ipsec.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 37a6416ed..580e09a3a 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -255,6 +255,13 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct 
ipsec_sa *sa)
&err);
if (ret)
goto flow_create_failure;
+   } else if (sa->attr.egress &&
+  (sa->ol_flags &
+   RTE_SECURITY_TX_HW_TRAILER_OFFLOAD)) {
+   sa->action[1].type =
+   RTE_FLOW_ACTION_TYPE_PASSTHRU;
+   sa->action[2].type =
+   RTE_FLOW_ACTION_TYPE_END;
}
 flow_create:
sa->flow = rte_flow_create(sa->portid,
-- 
2.11.0

Re: [dpdk-dev] [PATCH] ethdev: fix setting of MAC address

[Andrew Rybchenko]

On 12/14/2017 08:15 PM, Olivier Matz wrote:

From: Laurent Hardy 

When a new mac address is set, it is saved in dev->data->mac_addrs
before the ethdev handler is called.

First, it is inconsistent with the other ethdev functions
rte_eth_dev_mac_addr_remove() and rte_eth_dev_mac_addr_add().

Moreover, it prevents the drivers from wrongly comparing the old address
and the new one, like it's done in i40evf driver:

if (is_same_ether_addr(mac_addr, dev->data->mac_addrs))
return;

Fixes: 943c2d899a0c ("net/i40e: set VF MAC from VF")
Fixes: 854d8ad4ef68 ("ethdev: add default mac address modifier")
Cc: sta...@dpdk.org

Signed-off-by: Laurent Hardy 
---
  lib/librte_ether/rte_ethdev.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 4f492e3db..297c02a54 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2643,11 +2643,11 @@ rte_eth_dev_default_mac_addr_set(uint16_t port_id, 
struct ether_addr *addr)
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mac_addr_set, -ENOTSUP);
  
+	(*dev->dev_ops->mac_addr_set)(dev, addr);

+
/* Update default address in NIC data structure */
ether_addr_copy(addr, &dev->data->mac_addrs[0]);
  
-	(*dev->dev_ops->mac_addr_set)(dev, addr);

-
return 0;
  }


NACK, unfortunately it will break net/sfc in one of branches when a new MAC
is set using restart. It relies on the fact that a new MAC is already 
available in

device data.

Re: [dpdk-dev] [PATCH v2] lib/cmdline: init CLI parsing memory

[Adrien Mazarguil]

On Thu, Dec 14, 2017 at 04:35:45PM +0100, Olivier MATZ wrote:
> Hi Xueming,
> 
> On Sat, Dec 09, 2017 at 11:39:23PM +0800, Xueming Li wrote:
> > Initialize result memory every time before parsing. Also save
> > successfully parsed result before further ambiguous command detection to
> > avoid result being tainted by later parsing.
> > 
> > Signed-off-by: Xueming Li 
> 
> I'm ok with the content of the patch, but this has 2 be split in 2
> commits, which fixes different things.
> 
> 1/ cmdline: fix dynamic tokens parsing
> 
>[contains what Adrien suggested = all your patch but memset]
> 
>When using dynamic tokens, the result buffer contains pointers
>to some location inside the result buffer. When the content of
>the temporary buffer is copied in the final one, these pointers
>still point to the temporary buffer.
> 
>This works until the temporary buffer is kept intact, but the
>next commit introduces a memset() that breaks this assumption.
> 
>This commit renames the buffers, and ensures that the pointers
>point to the valid location, by recopying the buffer before
>invoking f().
> 
>Fixes: 9b3fbb051d2e ("cmdline: fix parsing")
>Cc: sta...@dpdk.org
> 
> 
> 2/ cmdline: avoid garbage in unused fields of parsed result
> 
>[contains the memset() only]
> 
>The result buffer was not initialized before parsing, inducing
>garbage in unused fields or padding of the parsed structure.
> 
>Initialize the result buffer each time before parsing.
> 
>Fixes: af75078fece3 ("first public release")
>Cc: sta...@dpdk.org
> 
> 
> Thoughts?
> Adrien, are you also ok?

Yes I fully agree, splitting this in two patches is also what I had in mind.
Xueming, do you plan to submit v3 accordingly?

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH] ethdev: fix setting of MAC address

[Igor Ryzhov]

Hello Andrew,

Don't you think that it's not correct that net/sfc works that way?

If we go further, dev->dev_ops->mac_addr_set not only should be called
before ether_addr_copy.
It should return status code, and in case of error ether_addr_copy
shouldn't be called at all.
Am I wrong?

Best regards,
Igor

On Mon, Dec 18, 2017 at 1:35 PM, Andrew Rybchenko  wrote:

> On 12/14/2017 08:15 PM, Olivier Matz wrote:
>
>> From: Laurent Hardy 
>>
>> When a new mac address is set, it is saved in dev->data->mac_addrs
>> before the ethdev handler is called.
>>
>> First, it is inconsistent with the other ethdev functions
>> rte_eth_dev_mac_addr_remove() and rte_eth_dev_mac_addr_add().
>>
>> Moreover, it prevents the drivers from wrongly comparing the old address
>> and the new one, like it's done in i40evf driver:
>>
>> if (is_same_ether_addr(mac_addr, dev->data->mac_addrs))
>> return;
>>
>> Fixes: 943c2d899a0c ("net/i40e: set VF MAC from VF")
>> Fixes: 854d8ad4ef68 ("ethdev: add default mac address modifier")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Laurent Hardy 
>> ---
>>   lib/librte_ether/rte_ethdev.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.
>> c
>> index 4f492e3db..297c02a54 100644
>> --- a/lib/librte_ether/rte_ethdev.c
>> +++ b/lib/librte_ether/rte_ethdev.c
>> @@ -2643,11 +2643,11 @@ rte_eth_dev_default_mac_addr_set(uint16_t
>> port_id, struct ether_addr *addr)
>> dev = &rte_eth_devices[port_id];
>> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mac_addr_set, -ENOTSUP);
>>   + (*dev->dev_ops->mac_addr_set)(dev, addr);
>> +
>> /* Update default address in NIC data structure */
>> ether_addr_copy(addr, &dev->data->mac_addrs[0]);
>>   - (*dev->dev_ops->mac_addr_set)(dev, addr);
>> -
>> return 0;
>>   }
>>
>
> NACK, unfortunately it will break net/sfc in one of branches when a new MAC
> is set using restart. It relies on the fact that a new MAC is already
> available in
> device data.
>

Re: [dpdk-dev] [PATCH v3 4/4] doc: update documentation for flow classify lib

[Kovacevic, Marko]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jasvinder Singh
> Sent: Friday, December 15, 2017 10:39 AM
> To: dev@dpdk.org
> Cc: Iremonger, Bernard 
> Subject: [dpdk-dev] [PATCH v3 4/4] doc: update documentation for flow classify
> lib
> 
> Updates the documentation for flow classification library and sample
> application.
> 
> Signed-off-by: Jasvinder Singh 


> v3:
> - add validate API desciption to programmers guide

Small typo desciption/   description


> @@ -225,11 +236,16 @@ The ``Classifier`` has the following internal 
> structures:
>  /* Input parameters */
>  char name[RTE_FLOW_CLASSIFIER_MAX_NAME_SZ];
>  int socket_id;
> -enum rte_flow_classify_table_type type;
> 
> -/* Internal tables */
> -struct rte_table tables[RTE_FLOW_CLASSIFY_TABLE_MAX];
> +/* Internal */
> +/* ntuple_fliter */

Small typo above.   Ntuple_fliter/  ntuple_filter.


> +struct rte_eth_ntuple_filter ntuple_filter;
> +
> +/* clasifier tables */

Same above clasifier /   classifier

 
>  To create an ACL table the ``rte_table_acl_params`` structure must be @@ -
> 314,14 +329,14 @@ and SCTP.
>  RTE_FLOW_ITEM_TYPE_END,
>  };
> 
> -The internal function ``flow_classify_parse_flow`` parses the
> +The API function ``rte_flow_classify_validate`` parses the
>  IPv4 5-tuple pattern, attributes and actions and returns the 5-tuple data in 
> the
> ``rte_eth_ntuple_filter`` structure.
> 
>  .. code-block:: c
> 
>  static int
> -flow_classify_parse_flow(
> +rte_flow_classify_validate(struct rte_flow_classifier *cls,
> const struct rte_flow_attr *attr,
> const struct rte_flow_item pattern[],
> const struct rte_flow_action actions[], @@ -333,7 +348,7 
> @@
> Adding Flow Rules  The ``rte_flow_classify_table_entry_add`` API creates an
> ``rte_flow_classify`` object which contains the flow_classify id and type, the
> action, a union of add and delete keys and a union of rules.
> -It uses the ``flow_classify_parse_flow`` internal function for parsing the
> +It uses the ``rte_flow_classify_validate`` api function for parsing the

Above api/  API


Otherwise everything else seem ok

Acked-by: Marko Kovacevic 

Re: [dpdk-dev] [PATCH v2 1/8] event/opdl: add the opdl ring infrastructure library

[Ma, Liang]

On 15 Dec 16:23, Neil Horman wrote:
> On Fri, Dec 15, 2017 at 01:50:41PM +, Ma, Liang wrote:
> > On 15 Dec 07:38, Neil Horman wrote:
> > > On Fri, Dec 15, 2017 at 11:26:22AM +, Liang Ma wrote:
> > > > OPDL ring is the core infrastructure of OPDL PMD. OPDL ring library
> > > > provide the core data structure and core helper function set. The Ring
> > > > implements a single ring multi-port/stage pipelined packet distribution
> > > > mechanism. This mechanism has the following characteristics:
> > > > 
> > > > • No multiple queue cost, therefore, latency is significant reduced.
> > > > • Fixed dependencies between queue/ports is more suitable for complex.
> > > >   fixed pipelines of stateless packet processing (static pipeline).
> > > > • Has decentralized distribution (no scheduling core).
> > > > • Packets remain in order (no reorder core(s)).
> > > > 
> > > > Signed-off-by: Liang Ma 
> > > > Signed-off-by: Peter, Mccarthy 
> > > > ---
> > > >  drivers/event/opdl/Makefile   |   66 ++
> > > >  drivers/event/opdl/opdl_ring.c| 1232 
> > > > +
> > > >  drivers/event/opdl/opdl_ring.h|  601 ++
> > > >  drivers/event/opdl/rte_pmd_evdev_opdl_version.map |3 +
> > > >  4 files changed, 1902 insertions(+)
> > > >  create mode 100644 drivers/event/opdl/Makefile
> > > >  create mode 100644 drivers/event/opdl/opdl_ring.c
> > > >  create mode 100644 drivers/event/opdl/opdl_ring.h
> > > >  create mode 100644 drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> > > > 
> > > >
> > > 
> > > > +
> > > > +#endif  /* _OPDL_H_ */
> > > > diff --git a/drivers/event/opdl/rte_pmd_evdev_opdl_version.map 
> > > > b/drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> > > > new file mode 100644
> > > > index 000..5352e7e
> > > > --- /dev/null
> > > > +++ b/drivers/event/opdl/rte_pmd_evdev_opdl_version.map
> > > > @@ -0,0 +1,3 @@
> > > > +DPDK_17.05 {
> > > > +   local: *;
> > > > +};
> > > you need to ennumerate the functions you want to globally export here, or 
> > > this won't work
> > > as a shared library.  This also suggests you haven't tested this as a DSO 
> > > yet,
> > > please do so.
> > > 
> > > Neil
> > FYI, the subject of email has indicated that's part of the PMD.
> I apologize, I didn't realize it was its own pmd, rather than part of the 
> other
> pmds.  I missed the pathing and thought you were creating a separate library 
> for
> others to consume, rather than a PMD to be accessed via the ethdev api
> 
> > there is no need to export any function globally.
> > you can reference 
> > drivers/event/octeontx/rte_pmd_octeontx_ssovf_version.map
> > /drivers/event/dpaa2/rte_pmd_dpaa2_event_version.map
> > drivers/event/sw/rte_pmd_sw_event_version.map
> > 
> > BTW: I do test with shared library build. 
> What did you test with?  I ask because with gcc version 7.2.1, the build 
> throws
> several warnings that error the build out:
I test with Gcc 6.3.1 and some older version, no warning report. 
gcc 7.2.1 is not in our test list rightnow, I will investigate the issue. 
> 
> /home/nhorman/git/dpdk/drivers/event/opdl/opdl_evdev_init.c: In function 
> ‘create_queues_and_rings’:
> /home/nhorman/git/dpdk/drivers/event/opdl/opdl_evdev_init.c:570:17: error: 
> ‘%s’ directive writing up to 63 bytes into a region of size 32 
> [-Werror=format-overflow=]
>   sprintf(name, "%s_%u", device->service_name, device->nb_opdls);
>  ^~
> /home/nhorman/git/dpdk/drivers/event/opdl/opdl_evdev_init.c:570:2: note: 
> ‘sprintf’ output between 3 and 75 bytes into a destination of size 32
>   sprintf(name, "%s_%u", device->service_name, device->nb_opdls);
>   ^~
> /home/nhorman/git/dpdk/drivers/event/opdl/opdl_evdev_init.c:570:17: error: 
> ‘%s’ directive writing up to 63 bytes into a region of size 32 
> [-Werror=format-overflow=]
>   sprintf(name, "%s_%u", device->service_name, device->nb_opdls);
>  ^~
> /home/nhorman/git/dpdk/drivers/event/opdl/opdl_evdev_init.c:570:2: note: 
> ‘sprintf’ output between 3 and 75 bytes into a destination of size 32
>   sprintf(name, "%s_%u", device->service_name, device->nb_opdls);
>   ^~
> cc1: all warnings being treated as errors
> 
> 
> It looks like you're trying to write a string to a 32 byte array, but the 
> first
> component of that string (service_name) can be as long as 63 bytes, and the
> nb_opdls can be up to 75 bytes long. I'm guessing you want to use snprintf 
> there
> rather than sprintf with a limit of RTE_MEMZONE_NAMESIZE - LIB_NAME (to 
> account
> for the added characters in opdl_ring_create?
> 
> Neil
> 
> > > 
> > > > -- 
> > > > 2.7.5
> > > > 
> > > > --
> > > > Intel Research and Development Ireland Limited
> > > > Registered in Ireland
> > > > Registered Office: Collinstown Indus

Re: [dpdk-dev] how to iterator all malloc_elem of a malloc_heap

[Burakov, Anatoly]

On 16-Dec-17 2:35 PM, liupan1234 wrote:

Hi All,


struct malloc_heap {
 rte_spinlock_t lock;
 LIST_HEAD(, malloc_elem) free_head[RTE_HEAP_NUM_FREELISTS];
 unsigned alloc_count;
 size_t total_size;
} __rte_cache_aligned;


I found there are free list of one malloc heap, it there any way to get used 
list? I want to get it to do some statistic.


Thanks
Pan


Hi Pan,

There isn't a way to do that at the moment.

--
Thanks,
Anatoly

Re: [dpdk-dev] shared memory statistic

[Burakov, Anatoly]

On 15-Dec-17 3:39 AM, liupan1234 wrote:

Hi all,


I have an urgent question:


1) when an app runs, how to get the really memory it used in real time? for 
example, it use -m param to specify 1G memory, but it only used 500 MB, how to 
get this info
2) When several apps runs with shared memory: shm 0, is there any method to get 
the memory used info for each process?


Thanks
Pan



For 1, i'm assuming you mean "how much of allocated memory is in use by 
DPDK". I don't think there is a unified API to do that, the closest you 
can get is check heap statistics (since all DPDK memory allocation is 
done through rte_malloc one way or another) and, check them against 
physical memory layout (available via rte_eal_get_physmem_layout()), 
which will give you a list of all memsegs DPDK currently has allocated.


For question 2, DPDK processes share all memory with each other, so 
there isn't any way to tell which process owns which memory.


--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] ethdev: fix setting of MAC address

[Andrew Rybchenko]

On 12/18/2017 01:53 PM, Igor Ryzhov wrote:


On Mon, Dec 18, 2017 at 1:35 PM, Andrew Rybchenko 
mailto:arybche...@solarflare.com>> wrote:


On 12/14/2017 08:15 PM, Olivier Matz wrote:

From: Laurent Hardy mailto:laurent.ha...@6wind.com>>

When a new mac address is set, it is saved in dev->data->mac_addrs
before the ethdev handler is called.

First, it is inconsistent with the other ethdev functions
rte_eth_dev_mac_addr_remove() and rte_eth_dev_mac_addr_add().

Moreover, it prevents the drivers from wrongly comparing the
old address
and the new one, like it's done in i40evf driver:

        if (is_same_ether_addr(mac_addr, dev->data->mac_addrs))
                return;

Fixes: 943c2d899a0c ("net/i40e: set VF MAC from VF")
Fixes: 854d8ad4ef68 ("ethdev: add default mac address modifier")
Cc: sta...@dpdk.org 

Signed-off-by: Laurent Hardy mailto:laurent.ha...@6wind.com>>
---
  lib/librte_ether/rte_ethdev.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c
b/lib/librte_ether/rte_ethdev.c
index 4f492e3db..297c02a54 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2643,11 +2643,11 @@
rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct
ether_addr *addr)
        dev = &rte_eth_devices[port_id];
        RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mac_addr_set,
-ENOTSUP);
  +     (*dev->dev_ops->mac_addr_set)(dev, addr);
+
        /* Update default address in NIC data structure */
        ether_addr_copy(addr, &dev->data->mac_addrs[0]);
  -     (*dev->dev_ops->mac_addr_set)(dev, addr);
-
        return 0;
  }


NACK, unfortunately it will break net/sfc in one of branches when
a new MAC
is set using restart. It relies on the fact that a new MAC is
already available in
device data.



> Hello Andrew,
>
> Don't you think that it's not correct that net/sfc works that way?
>
> If we go further, dev->dev_ops->mac_addr_set not only should be 
called before ether_addr_copy.
It should  return status code, and in case of error ether_addr_copy shouldn't be 

called at all.

Am I wrong?


Current behaviour is convenient. Alternative will require copy of MAC 
address
to set in device private data and one more copy in the function to 
rollback in

the case of failure. If there are good reasons to change behaviour, I don't
mind but PMDs should be reviewed carefully and fixed before the change.

[dpdk-dev] [PATCH 0/2] next-build: add test app to build

[Harry van Haaren]

This patchset adds the test/test/test app to the Meson build.
In doing so, the test app is improved to allow running a unit
test by setting an environment variable. This allows the meson
test infrastructure to integrate with the DPDK tests. Some nice
improvements from the above integration, including debug aids...

Run all autotests:
$ meson test

Run a specific test:
$ meson test ring_perf_autotest

Run a specific test multiple times, eg brute-forcing race conditions:
$ meson test eventdev_sw_autotest --repeat=3

Run a specific test multiple times in gdb, eg to drop to GDB if race found:
$ meson test eventdev_sw_autotest --repeat=3 --gdb


Meson also provides various options to "wrap" the test binary,
which can be used for running in eg: Valgrind or other tools. For
more information about Meson and its testing capabilities, see here:
http://mesonbuild.com/Unit-tests.html

Cheers, -Harry


Harry van Haaren (2):
  test: use env variable to run test if set
  meson: add tests app to build

 meson.build   |   1 +
 meson_options.txt |   2 +
 test/meson.build  |  32 +++
 test/test/meson.build | 248 ++
 test/test/test.c  |  25 -
 5 files changed, 307 insertions(+), 1 deletion(-)
 create mode 100644 test/meson.build
 create mode 100644 test/test/meson.build

-- 
2.7.4

[dpdk-dev] [PATCH 2/2] meson: add tests app to build

[Harry van Haaren]

This patch enables the test/test app to be built. It also adds
the test binary to be a meson-test, which allows the meson test
infrastructure to be used to run tests.

Tests are listed using the same test binary, however each test
sets a different DPDK_TEST environment variable. The string contents
of this DPDK_TEST env var is entered in the command line interface.
As such, the familiar test names such as "ring_perf_autotest" etc
are valid tests to run using this meson test infrastructure.

Note that the tests are run serially, given that we cannot run
multiple primary processes at a time. As each test must initialize
EAL this takes some time depending on the number of hugepages.
In future, we could improve this to run multiple tests from one
EAL init, but it is out of scope for this patchset.

Finally, an option to build the tests is added to the meson build
options. When disabled, the unit test code in test/test is not
compiled. The default is set to 'true'. To disable, run:

$ meson configure -Dtests=false

Signed-off-by: Harry van Haaren 
---
 meson.build   |   1 +
 meson_options.txt |   2 +
 test/meson.build  |  32 +++
 test/test/meson.build | 248 ++
 4 files changed, 283 insertions(+)
 create mode 100644 test/meson.build
 create mode 100644 test/test/meson.build

diff --git a/meson.build b/meson.build
index 04eea72..9132594 100644
--- a/meson.build
+++ b/meson.build
@@ -60,6 +60,7 @@ subdir('drivers')
 # build binaries and installable tools
 subdir('usertools')
 subdir('app')
+subdir('test')
 
 # build any examples explicitly requested - useful for developers
 if get_option('examples') != ''
diff --git a/meson_options.txt b/meson_options.txt
index f2558fe..1a674aa 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -18,3 +18,5 @@ option('per_library_versions', type: 'boolean', value: true,
description: 'true: each lib gets its own version number, false: DPDK 
version used for each lib')
 option('use_hpet', type: 'boolean', value: false,
description: 'use HPET timer in EAL')
+option('tests', type: 'boolean', value: true,
+   description: 'build unit tests')
diff --git a/test/meson.build b/test/meson.build
new file mode 100644
index 000..4250eb7
--- /dev/null
+++ b/test/meson.build
@@ -0,0 +1,32 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2017 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+subdir('test')
diff --git a/test/test/meson.build b/test/test/meson.build
new file mode 100644
index 000..1a4f894
--- /dev/null
+++ b/test/test/meson.build
@@ -0,0 +1,248 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2017 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#

[dpdk-dev] [PATCH 1/2] test: use env variable to run test if set

[Harry van Haaren]

This commit paves the way for the meson tests in the next
patch. With this patch the test binary checks the DPDK_TEST
environment variable and if set, the contents of the var
are inserted on the test app command line, and run.

This allows testing of various different unit tests without
manual interaction with the RTE>> test prompt, instead automating
it using the DPDK_TEST environment variable.

If the DPDK_TEST env variable is not set, or has zero lenght,
the test app behaves as normal.

Signed-off-by: Harry van Haaren 
---
 test/test/test.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/test/test/test.c b/test/test/test.c
index 0e6ff7c..fb4d475 100644
--- a/test/test/test.c
+++ b/test/test/test.c
@@ -102,6 +102,8 @@ do_recursive_call(void)
return -1;
 }
 
+static int last_test_result;
+
 int
 main(int argc, char **argv)
 {
@@ -140,7 +142,27 @@ main(int argc, char **argv)
if (cl == NULL) {
return -1;
}
-   cmdline_interact(cl);
+
+   char *dpdk_test = getenv("DPDK_TEST");
+   if (dpdk_test && strlen(dpdk_test)) {
+   char buf[1024];
+   snprintf(buf, sizeof(buf), "%s\n", dpdk_test);
+   if (cmdline_in(cl, buf, strlen(buf)) < 0) {
+   printf("error on cmdline input\n");
+   return -1;
+   }
+
+   /* check the last unit test suite return, and error out if
+* it failed - this causes Meson to pick up the failure.
+*/
+   if (last_test_result) {
+   cmdline_stdin_exit(cl);
+   exit(-1);
+   }
+
+   } else {
+   cmdline_interact(cl);
+   }
cmdline_stdin_exit(cl);
 #endif
 
@@ -231,6 +253,8 @@ unit_test_suite_runner(struct unit_test_suite *suite)
printf(" + Tests Failed :  %2d\n", failed);
printf(" + --- 
+\n");
 
+   last_test_result = failed;
+
if (failed)
return -1;
 
-- 
2.7.4

[dpdk-dev] [PATCH v4 1/4] Introducing SPDX License Identifiers

[Hemant Agrawal]

The DPDK uses the Open Source BSD-3-Clause license for the core libraries
and drivers. The kernel components are naturally GPLv2 licensed.

Many of the files in the DPDK source code contain the full text of the
applicable license. For example, most of the BSD-3-Clause files contain a
full copy of the BSD-3-Clause license text.

Including big blocks of License headers in all files blows up the source
code with mostly redundant information.  An additional problem is that even
the same licenses are referred to by a number of slightly varying text
blocks (full, abbreviated, different indentation, line wrapping and/or
white space, with obsolete address information, ...) which makes validation
and automatic processing a nightmare.

To make this easier, DPDK uses of a single line reference to
Unique License Identifiers in source files as defined by the Linux
Foundation's SPDX project https://spdk.org.

Adding license information in this fashion, rather than adding full license
text, can be more efficient for developers; decreases errors; and improves
automated detection of licenses. The current set of valid, predefined SPDX
identifiers is set forth on the SPDX License List at
https://spdx.org/licenses/.

For example, to label a file as subject to the BSD-3-Clause license,
the following text would be used as the top line of the file.

SPDX-License-Identifier: BSD-3-Clause

Note: Any new file contributions in DPDK shall adhere to the above scheme.
It is also recommended to replace or at least amend the existing license
text in the code with SPDX-License-Identifiers.

Any exception to DPDK IP policies shall be approved by DPDK tech board and
DPDK Governing Board. Steps for any exception approval:
1. Mention the appropriate license identifier form SPDX. If the license is
   not listed in SPDX Licenses. It is the submitters responsibiliity to get
   it first listed.
2. Get the required approval from the DPDK Technical Board. Technical board
   may advise the author to check alternate means first. If no other
   alternatives are found and the merit of the contributions are important
   for DPDK's mission, it may decide on such exception with two-thirds vote
   of the members.
3. Technical board then approach Governing board for such limited approval
   for the given contribution only.

Any approvals shall be documented in "licenses/exceptions.txt" with record
dates.

Note: From the legal point of view, this patch is supposed to be only a
change to the textual representation of the license information, but in no
way any change to the actual license terms. With this patch applied, all
files will still be licensed under the same terms they were before.

Signed-off-by: Hemant Agrawal 
Acked-by: Stephen Hemminger 
---
 README   |  4 +-
 doc/guides/contributing/patches.rst  | 23 +++
 license/README   | 77 
 license/bsd-3-clause.txt |  9 +
 license/exceptions.txt   | 18 +
 LICENSE.GPL => license/gpl-2.0.txt   | 14 +++
 LICENSE.LGPL => license/lgpl-2.1.txt | 18 -
 7 files changed, 145 insertions(+), 18 deletions(-)
 create mode 100644 license/README
 create mode 100644 license/bsd-3-clause.txt
 create mode 100644 license/exceptions.txt
 rename LICENSE.GPL => license/gpl-2.0.txt (98%)
 rename LICENSE.LGPL => license/lgpl-2.1.txt (99%)

diff --git a/README b/README
index 29ba0e0..55df158 100644
--- a/README
+++ b/README
@@ -1,8 +1,8 @@
 DPDK is a set of libraries and drivers for fast packet processing.
 It supports many processor architectures and both FreeBSD and Linux.
 
-The DPDK uses the Open Source BSD license for the core libraries and
-drivers. The kernel components are GPLv2 licensed.
+The DPDK uses the Open Source BSD-3-Clause license for the core libraries
+and drivers. The kernel components are GPL-2.0 licensed.
 
 Please check the doc directory for release notes,
 API documentation, and sample application information.
diff --git a/doc/guides/contributing/patches.rst 
b/doc/guides/contributing/patches.rst
index 40983c1..64408e7 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,29 @@ It is also worth registering for the DPDK `Patchwork 
`_ for further 
information.
 
+Source License
+--
+
+The DPDK uses the Open Source BSD-3-Clause license for the core libraries and
+drivers. The kernel components are GPL-2.0 licensed. DPDK uses single line
+reference to Unique License Identifiers in source files as defined by the Linux
+Foundation's `SPDX project `_.
+
+DPDK uses first line of the file to be SPDX tag. In case of *#!* scripts, SPDX
+tag can be placed in 2nd line of the file.
+
+For example, to label a file as subject to the

[dpdk-dev] [PATCH v4 2/4] change root makefile license to SPDX tag

[Hemant Agrawal]

Signed-off-by: Hemant Agrawal 
---
 GNUmakefile | 29 +
 Makefile| 29 +
 2 files changed, 2 insertions(+), 56 deletions(-)

diff --git a/GNUmakefile b/GNUmakefile
index 45b7fbb..2ff3e4b 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -1,33 +1,6 @@
-#   BSD LICENSE
+# SPDX-License-Identifier: BSD-3-Clause
 #
 #   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
-#   All rights reserved.
-#
-#   Redistribution and use in source and binary forms, with or without
-#   modification, are permitted provided that the following conditions
-#   are met:
-#
-# * Redistributions of source code must retain the above copyright
-#   notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-#   notice, this list of conditions and the following disclaimer in
-#   the documentation and/or other materials provided with the
-#   distribution.
-# * Neither the name of Intel Corporation nor the names of its
-#   contributors may be used to endorse or promote products derived
-#   from this software without specific prior written permission.
-#
-#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 #
 # Head Makefile for compiling rte SDK
diff --git a/Makefile b/Makefile
index f4b807e..f87b84a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,33 +1,6 @@
-#   BSD LICENSE
+# SPDX-License-Identifier: BSD-3-Clause
 #
 #   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-#   All rights reserved.
-#
-#   Redistribution and use in source and binary forms, with or without
-#   modification, are permitted provided that the following conditions
-#   are met:
-#
-# * Redistributions of source code must retain the above copyright
-#   notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-#   notice, this list of conditions and the following disclaimer in
-#   the documentation and/or other materials provided with the
-#   distribution.
-# * Neither the name of Intel Corporation nor the names of its
-#   contributors may be used to endorse or promote products derived
-#   from this software without specific prior written permission.
-#
-#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 .error Error please compile using GNU Make (gmake)
 
-- 
2.7.4

[dpdk-dev] [PATCH v4 4/4] change NXP dpaa code License text to SPDX tags

[Hemant Agrawal]

Signed-off-by: Hemant Agrawal 
---
 config/defconfig_arm64-dpaa-linuxapp-gcc  | 30 ++---
 doc/guides/cryptodevs/dpaa_sec.rst| 31 +++---
 doc/guides/nics/dpaa.rst  | 31 +++---
 doc/guides/prog_guide/rte_security.rst| 31 +++---
 drivers/bus/dpaa/Makefile | 29 ++--
 drivers/bus/dpaa/base/fman/fman.c | 37 ++-
 drivers/bus/dpaa/base/fman/fman_hw.c  | 27 ++
 drivers/bus/dpaa/base/fman/netcfg_layer.c | 37 ++-
 drivers/bus/dpaa/base/fman/of.c   | 37 ++-
 drivers/bus/dpaa/base/qbman/bman.c| 37 ++-
 drivers/bus/dpaa/base/qbman/bman.h| 37 ++-
 drivers/bus/dpaa/base/qbman/bman_driver.c | 37 ++-
 drivers/bus/dpaa/base/qbman/bman_priv.h   | 37 ++-
 drivers/bus/dpaa/base/qbman/dpaa_alloc.c  | 37 ++-
 drivers/bus/dpaa/base/qbman/dpaa_sys.c| 37 ++-
 drivers/bus/dpaa/base/qbman/dpaa_sys.h| 37 ++-
 drivers/bus/dpaa/base/qbman/process.c | 37 ++-
 drivers/bus/dpaa/base/qbman/qman.c| 37 ++-
 drivers/bus/dpaa/base/qbman/qman.h| 37 ++-
 drivers/bus/dpaa/base/qbman/qman_driver.c | 37 ++-
 drivers/bus/dpaa/base/qbman/qman_priv.h   | 37 ++-
 drivers/bus/dpaa/dpaa_bus.c   | 30 ++---
 drivers/bus/dpaa/include/compat.h | 35 +
 drivers/bus/dpaa/include/dpaa_bits.h  | 30 ++---
 drivers/bus/dpaa/include/dpaa_list.h  | 30 ++---
 drivers/bus/dpaa/include/dpaa_rbtree.h| 30 ++---
 drivers/bus/dpaa/include/fman.h   | 35 +
 drivers/bus/dpaa/include/fsl_bman.h   | 35 +
 drivers/bus/dpaa/include/fsl_fman.h   | 37 ++-
 drivers/bus/dpaa/include/fsl_fman_crc64.h | 35 +
 drivers/bus/dpaa/include/fsl_qman.h   | 35 +
 drivers/bus/dpaa/include/fsl_usd.h| 35 +
 drivers/bus/dpaa/include/netcfg.h | 35 +
 drivers/bus/dpaa/include/of.h | 37 ++-
 drivers/bus/dpaa/include/process.h| 35 +
 drivers/bus/dpaa/rte_dpaa_bus.h   | 30 ++---
 drivers/bus/dpaa/rte_dpaa_logs.h  | 30 ++---
 drivers/crypto/dpaa_sec/Makefile  | 29 ++--
 drivers/crypto/dpaa_sec/dpaa_sec.c| 30 ++---
 drivers/crypto/dpaa_sec/dpaa_sec.h| 30 ++---
 drivers/crypto/dpaa_sec/dpaa_sec_log.h| 28 +--
 drivers/mempool/dpaa/Makefile | 29 ++--
 drivers/mempool/dpaa/dpaa_mempool.c   | 30 ++---
 drivers/mempool/dpaa/dpaa_mempool.h   | 30 ++---
 drivers/mempool/ring/Makefile | 30 ++---
 drivers/mempool/stack/Makefile| 30 ++---
 drivers/net/dpaa/Makefile | 29 ++--
 drivers/net/dpaa/dpaa_ethdev.c| 30 ++---
 drivers/net/dpaa/dpaa_ethdev.h| 30 ++---
 drivers/net/dpaa/dpaa_rxtx.c  | 30 ++---
 drivers/net/dpaa/dpaa_rxtx.h  | 30 ++---
 mk/machine/dpaa/rte.vars.mk   | 30 ++---
 52 files changed, 98 insertions(+), 1615 deletions(-)

diff --git a/config/defconfig_arm64-dpaa-linuxapp-gcc 
b/config/defconfig_arm64-dpaa-linuxapp-gcc
index e577432..5618ad7 100644
--- a/config/defconfig_arm64-dpaa-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa-linuxapp-gcc
@@ -1,33 +1,7 @@
-#   BSD LICENSE
+# SPDX-License-Identifier: BSD-3-Clause
 #
 #   Copyright 2016 Freescale Semiconductor, Inc.
-#   Copyright 2017 NXP.
-#
-#   Redistribution and use in source and binary forms, with or without
-#   modification, are permitted provided that the following conditions
-#   are met:
-#
-# * Redistributions of source code must retain the above copyright
-#   notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-#   notice, this list of conditions and the following disclaimer in
-#   the documentation and/or other materials provided with the
-#   distribution.
-# * Ne

[dpdk-dev] Next technical board meeting on 2017-12-20

[Hemant Agrawal]

The next techboard meeting will take place on 2017-12-20  i.e. this Wednesday, 
at 3pm UTC. 

Meeting place: IRC #dpdk-board

Please send on any items requiring techboard attention.

Regards,
/Hemant

> -Original Message-
> From: techboard [mailto:techboard-boun...@dpdk.org] On Behalf Of
> Richardson, Bruce
> Sent: Tuesday, December 12, 2017 10:57 PM
> To: techbo...@dpdk.org
> Cc: dev@dpdk.org
> Subject: [dpdk-techboard] Minutes of technical board meeting 2017-12-06
> 
> Attendees:
> Bruce, Hemant, Jerin, Konstantin, Olivier, Thomas, Yuanhan
> 
> Absent:
> Stephen, Jan
> 
> Due to discontinued involvement in DPDK, Jan has now resigned from the
> technical board.
> The tech board wishes to thank him for his contributions to DPDK and tech-
> board over the last few years and wish him well in his other endeavours.
> The topic of a possible replacement for Jan on the tech-board will be
> discussed at the next meeting.
> 
> Topic: Management of old patches in patchwork
> * Unanimous agreement that old patches should be rejected in patchwork
>   after a reasonable period, set initially at 3 releases (9 months).
> * After a release, all patches dated older than 3 releases previously,
>   e.g. after 17.11, any patches submitted before the release of 17.02,
>   will be marked as rejected and a mail reply sent to the appropriate
>   mailing list thread informing people of the same.
> * To have patches reconsidered for future inclusion, a new version of
>   the patches should be submitted to the mailing list.
> 
> * Bruce to update the documentation with this new policy.
> * Thomas to request support from patchwork and DPDK community to
>   automate/script the implementation of this policy.
> 
> Topic: Licensing
> * No major updates. Discussion in progress on a number of items that
>   need relicensing or exceptions.
> 
> Topic: Technical Board Voting
> * For charter changes the governing board requires a 2/3 majority. The
>   technical board has no such special case for charter or policy
>   changes.
> * Following brief discussion, most seemed happy with the current
>   situation where a simple majority suffices for such decisions.
> 
> Next Meeting:
> * 2017-12-20 @ 3pm UTC
> * Hemant to chair discussion

Re: [dpdk-dev] [PATCH v3 4/4] doc: update documentation for flow classify lib

[Singh, Jasvinder]

> -Original Message-
> From: Kovacevic, Marko
> Sent: Monday, December 18, 2017 11:05 AM
> To: Singh, Jasvinder ; dev@dpdk.org
> Cc: Iremonger, Bernard 
> Subject: RE: [dpdk-dev] [PATCH v3 4/4] doc: update documentation for flow
> classify lib
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jasvinder Singh
> > Sent: Friday, December 15, 2017 10:39 AM
> > To: dev@dpdk.org
> > Cc: Iremonger, Bernard 
> > Subject: [dpdk-dev] [PATCH v3 4/4] doc: update documentation for flow
> > classify lib
> >
> > Updates the documentation for flow classification library and sample
> > application.
> >
> > Signed-off-by: Jasvinder Singh 
> 
> 
> > v3:
> > - add validate API desciption to programmers guide
> 
> Small typo desciption/   description
> 
> 
> > @@ -225,11 +236,16 @@ The ``Classifier`` has the following internal
> structures:
> >  /* Input parameters */
> >  char name[RTE_FLOW_CLASSIFIER_MAX_NAME_SZ];
> >  int socket_id;
> > -enum rte_flow_classify_table_type type;
> >
> > -/* Internal tables */
> > -struct rte_table tables[RTE_FLOW_CLASSIFY_TABLE_MAX];
> > +/* Internal */
> > +/* ntuple_fliter */
> 
> Small typo above.   Ntuple_fliter/  ntuple_filter.
> 
> 
> > +struct rte_eth_ntuple_filter ntuple_filter;
> > +
> > +/* clasifier tables */
> 
> Same above clasifier /   classifier
> 
> 
> >  To create an ACL table the ``rte_table_acl_params`` structure must be
> > @@ -
> > 314,14 +329,14 @@ and SCTP.
> >  RTE_FLOW_ITEM_TYPE_END,
> >  };
> >
> > -The internal function ``flow_classify_parse_flow`` parses the
> > +The API function ``rte_flow_classify_validate`` parses the
> >  IPv4 5-tuple pattern, attributes and actions and returns the 5-tuple
> > data in the ``rte_eth_ntuple_filter`` structure.
> >
> >  .. code-block:: c
> >
> >  static int
> > -flow_classify_parse_flow(
> > +rte_flow_classify_validate(struct rte_flow_classifier *cls,
> > const struct rte_flow_attr *attr,
> > const struct rte_flow_item pattern[],
> > const struct rte_flow_action actions[], @@ -333,7
> > +348,7 @@ Adding Flow Rules  The ``rte_flow_classify_table_entry_add``
> > API creates an ``rte_flow_classify`` object which contains the
> > flow_classify id and type, the action, a union of add and delete keys and a
> union of rules.
> > -It uses the ``flow_classify_parse_flow`` internal function for
> > parsing the
> > +It uses the ``rte_flow_classify_validate`` api function for parsing
> > +the
> 
> Above api/  API
> 
> 
> Otherwise everything else seem ok
> 
> Acked-by: Marko Kovacevic 
> 

Thanks Marko for review. I will fix them in next version.

Jasvinder

Re: [dpdk-dev] [PATCH v2] lib/cmdline: init CLI parsing memory

[Xueming(Steven) Li]

No problem, make enough sense for v3.

> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Monday, December 18, 2017 6:51 PM
> To: Olivier MATZ 
> Cc: Xueming(Steven) Li ; dev@dpdk.org
> Subject: Re: [PATCH v2] lib/cmdline: init CLI parsing memory
> 
> On Thu, Dec 14, 2017 at 04:35:45PM +0100, Olivier MATZ wrote:
> > Hi Xueming,
> >
> > On Sat, Dec 09, 2017 at 11:39:23PM +0800, Xueming Li wrote:
> > > Initialize result memory every time before parsing. Also save
> > > successfully parsed result before further ambiguous command
> > > detection to avoid result being tainted by later parsing.
> > >
> > > Signed-off-by: Xueming Li 
> >
> > I'm ok with the content of the patch, but this has 2 be split in 2
> > commits, which fixes different things.
> >
> > 1/ cmdline: fix dynamic tokens parsing
> >
> >[contains what Adrien suggested = all your patch but memset]
> >
> >When using dynamic tokens, the result buffer contains pointers
> >to some location inside the result buffer. When the content of
> >the temporary buffer is copied in the final one, these pointers
> >still point to the temporary buffer.
> >
> >This works until the temporary buffer is kept intact, but the
> >next commit introduces a memset() that breaks this assumption.
> >
> >This commit renames the buffers, and ensures that the pointers
> >point to the valid location, by recopying the buffer before
> >invoking f().
> >
> >Fixes: 9b3fbb051d2e ("cmdline: fix parsing")
> >Cc: sta...@dpdk.org
> >
> >
> > 2/ cmdline: avoid garbage in unused fields of parsed result
> >
> >[contains the memset() only]
> >
> >The result buffer was not initialized before parsing, inducing
> >garbage in unused fields or padding of the parsed structure.
> >
> >Initialize the result buffer each time before parsing.
> >
> >Fixes: af75078fece3 ("first public release")
> >Cc: sta...@dpdk.org
> >
> >
> > Thoughts?
> > Adrien, are you also ok?
> 
> Yes I fully agree, splitting this in two patches is also what I had in
> mind.
> Xueming, do you plan to submit v3 accordingly?
> 
> --
> Adrien Mazarguil
> 6WIND

Re: [dpdk-dev] [PATCH 1/2] test: use env variable to run test if set

[Bruce Richardson]

On Mon, Dec 18, 2017 at 11:53:57AM +, Harry van Haaren wrote:
> This commit paves the way for the meson tests in the next
> patch. With this patch the test binary checks the DPDK_TEST
> environment variable and if set, the contents of the var
> are inserted on the test app command line, and run.
> 
> This allows testing of various different unit tests without
> manual interaction with the RTE>> test prompt, instead automating
> it using the DPDK_TEST environment variable.
> 
> If the DPDK_TEST env variable is not set, or has zero lenght,
> the test app behaves as normal.
> 
> Signed-off-by: Harry van Haaren 
> ---

This is very useful, even without the meson test part added in the next
patch.

Probably a matter of personal taste, but I think I would prefer to see
the tests to be run specified as args on the cmdline rather than passed
through the environment. I'd tend to view environment variables as
things to use for long-lasting values, rather than parameters you might
want to change between each run. Using cmdline args would also save you
having to split commands, since you'd get the list pre-split in
argv.

/Bruce

Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for pktmbuf pool create API

[Wiles, Keith]

> On Dec 15, 2017, at 4:41 AM, Hemant Agrawal  wrote:
> 
> Introduce a new argument ops_name in rte_mempool_set_ops_byname
> for allowing the application to optionally specify the mempool ops.
> 
> Signed-off-by: Hemant Agrawal 
> ---
> v2: fix checkpatch error
> 
> doc/guides/rel_notes/deprecation.rst | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index 13e8543..968ca14 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -53,3 +53,6 @@ Deprecation Notices
> 
> * librte_meter: The API will change to accommodate configuration profiles.
>   Most of the API functions will have an additional opaque parameter.
> +
> +* librte_mbuf: a new optional parameter for representing name of mempool_ops
> +  will be added to the API ``rte_pktmbuf_pool_create``.


Sorry, for the late response I was on vacation.

My question is why do we need to change rte_pktmbuf_pool_create ABI yet again, 
why could we not add a new API to just set the name of the pool after it is 
created. This would allow all current applications to work without any ABI 
breakage and only require adding a new API call for anyone that wants the name. 
The rte_pktmbuf_pool_create() routine could assign a default name or some 
incrementing style name as the default. e.g. ‘pktmbuf_%d’ with a static 
incrementing variable or whatever you like.

Sorry if this was asked and answered before.

> -- 
> 2.7.4
> 

Regards,
Keith

Re: [dpdk-dev] [PATCH 2/2] meson: add tests app to build

[Bruce Richardson]

On Mon, Dec 18, 2017 at 11:53:58AM +, Harry van Haaren wrote:
> This patch enables the test/test app to be built. It also adds
> the test binary to be a meson-test, which allows the meson test
> infrastructure to be used to run tests.
> 
> Tests are listed using the same test binary, however each test
> sets a different DPDK_TEST environment variable. The string contents
> of this DPDK_TEST env var is entered in the command line interface.
> As such, the familiar test names such as "ring_perf_autotest" etc
> are valid tests to run using this meson test infrastructure.
> 
> Note that the tests are run serially, given that we cannot run
> multiple primary processes at a time. As each test must initialize
> EAL this takes some time depending on the number of hugepages.
> In future, we could improve this to run multiple tests from one
> EAL init, but it is out of scope for this patchset.
> 
> Finally, an option to build the tests is added to the meson build
> options. When disabled, the unit test code in test/test is not
> compiled. The default is set to 'true'. To disable, run:
> 
> $ meson configure -Dtests=false
> 
> Signed-off-by: Harry van Haaren 
> ---


> +
> +test_names = [
> + 'acl_autotest',
> + 'alarm_autotest',
> + 'atomic_autotest',
> + 'byteorder_autotest',
> + 'cmdline_autotest',
> + 'common_autotest',
> + 'cpuflags_autotest',
> + 'crc_autotest',
> + 'cycles_autotest',
> + 'debug_autotest',
> + 'devargs_autotest',
> + 'distributor_autotest',
> + 'distributor_perf_autotest',
> + 'eal_flags_autotest',
> + 'eal_fs_autotest',
> + 'efd_autotest',
> + 'efd_perf_autotest',
> + 'errno_autotest',
> + 'event_ring_autotest',
> + 'eventdev_common_autotest',
> + 'eventdev_octeontx_autotest',
> + 'eventdev_sw_autotest',
> + 'func_reentrancy_autotest',
> + 'has_scaling_autotest',
> + 'hash_autotest',
> + 'hash_functions_autotest',
> + 'hash_multiwriter_autotest',
> + 'hash_perf_autotest',
> + 'interrupt_autotest',
> + 'kni_autotest',
> + 'kvargs_autotest',
> + 'logs_autotest',
> + 'lpm6_autotest',
> + 'lpm6_perf_autotest',
> + 'lpm_autotest',
> + 'lpm_perf_autotest',
> + 'malloc_autotest',
> + 'mbuf_autotest',
> + 'memcpy_autotest',
> + 'memcpy_perf_autotest',
> + 'memory_autotest',
> + 'mempool_autotest',
> + 'mempool_perf_autotest',
> + 'memzone_autotest',
> + 'meter_autotest',
> + 'multiprocess_autotest',
> + 'per_lcore_autotest',
> + 'pmd_perf_autotest',
> + 'power_acpi_cpufreq_autotest',
> + 'power_autotest',
> + 'power_kvm_vm_autotest',
> + 'prefetch_autotest',
> + 'red_all',
> + 'red_autotest',
> + 'red_perf',
> + 'reorder_autotest',
> + 'ring_autotest',
> + 'ring_perf_autotest',
> + 'rwlock_autotest',
> + 'sched_autotest',
> + 'service_autotest',
> + 'spinlock_autotest',
> + 'table_autotest',
> + 'tailq_autotest',
> + 'thash_autotest',
> + 'timer_autotest',
> + 'timer_perf__autotest',
> + 'timer_racecond_autotest',
> + 'user_delay_us',
> + 'version_autotest',
> +]

I think we should find a way to remove this long list of test names in
the build file. The list of available tests is built up dynamically
inside the test binary, so I'm wondering if we can add to the binary an
"all" option to run each autotest straight after each other?

> +
> +if dpdk_conf.has('RTE_LIBRTE_PDUMP')
> + test_deps += 'pdump'
> +endif
> +if dpdk_conf.has('RTE_LIBRTE_I40E_PMD')
> + test_deps += 'pmd_i40e'
> +endif
> +if dpdk_conf.has('RTE_LIBRTE_IXGBE_PMD')
> + test_deps += 'pmd_ixgbe'
> +endif
> +

This should be moved up beside the other dependencies

> +test_dep_objs = []
> +foreach d:test_deps
> + def_lib = get_option('default_library')
> + test_dep_objs += get_variable(def_lib + '_rte_' + d)
> +endforeach
> +
> +link_libs = []
> +if get_option('default_library') == 'static'
> + link_libs = dpdk_drivers
> +endif
> +

A note for the future: since much of this looks similar to that in
testpmd we should look to see if we can find a way to easily consolidate
these build commands inside a foreach loop like is done for the libs,
drivers and examples.

> +if get_option('tests')
> + dpdk_test = executable('dpdk-test',
> + test_sources,
> + link_whole: link_libs,
> + dependencies: test_dep_objs,
> + install_rpath: driver_install_path,
> + install: false)
> +
> + # some perf tests (eg: memcpy perf autotest)take very long
> + # to complete, so timeout to 10 minutes
> + timeout_seconds = 600
> +
> + foreach t:test_names
> + test(t, dpdk_test,
> + env : ['DPDK_TEST='+t],
> + timeout : timeout_seconds,
> + is_parallel : false)
> + endforeach
> +endif
> -- 
> 2.7.4
> 

Re: [dpdk-dev] [PATCH 0/2] next-build: add test app to build

[Bruce Richardson]

On Mon, Dec 18, 2017 at 11:53:56AM +, Harry van Haaren wrote:
> This patchset adds the test/test/test app to the Meson build.
> In doing so, the test app is improved to allow running a unit
> test by setting an environment variable. This allows the meson
> test infrastructure to integrate with the DPDK tests. Some nice
> improvements from the above integration, including debug aids...
> 
> Run all autotests:
> $ meson test
> 

meson or ninja?

> Run a specific test:
> $ meson test ring_perf_autotest
> 
> Run a specific test multiple times, eg brute-forcing race conditions:
> $ meson test eventdev_sw_autotest --repeat=3
> 
> Run a specific test multiple times in gdb, eg to drop to GDB if race found:
> $ meson test eventdev_sw_autotest --repeat=3 --gdb
> 

The "repeat" and "gdb" arguments come built-in in meson, right, not from
this patchset?

> 
> Meson also provides various options to "wrap" the test binary,
> which can be used for running in eg: Valgrind or other tools. For
> more information about Meson and its testing capabilities, see here:
> http://mesonbuild.com/Unit-tests.html
> 
> Cheers, -Harry
> 
> 
> Harry van Haaren (2):
>   test: use env variable to run test if set
>   meson: add tests app to build
> 
>  meson.build   |   1 +
>  meson_options.txt |   2 +
>  test/meson.build  |  32 +++
>  test/test/meson.build | 248 
> ++
>  test/test/test.c  |  25 -
>  5 files changed, 307 insertions(+), 1 deletion(-)
>  create mode 100644 test/meson.build
>  create mode 100644 test/test/meson.build
> 
> -- 
> 2.7.4
> 

[dpdk-dev] [PATCH] maintainers: resign from maintenance

[Sergio Gonzalez Monroy]

I will not be directly working on the DPDK project anymore.

Signed-off-by: Sergio Gonzalez Monroy 
---
 MAINTAINERS | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f0baeb4..64f154a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -113,7 +113,7 @@ F: test/test/test_tailq.c
 F: test/test/test_version.c
 
 Memory Allocation
-M: Sergio Gonzalez Monroy 
+M: Anatoly Burakov 
 F: lib/librte_eal/common/include/rte_mem*
 F: lib/librte_eal/common/include/rte_malloc.h
 F: lib/librte_eal/common/*malloc*
@@ -133,7 +133,7 @@ F: examples/l2fwd-keepalive/
 F: doc/guides/sample_app_ug/keep_alive.rst
 
 Secondary process
-M: Sergio Gonzalez Monroy 
+M: Anatoly Burakov 
 K: RTE_PROC_
 F: doc/guides/prog_guide/multi_proc_support.rst
 F: test/test/test_mp_secondary.c
@@ -203,19 +203,16 @@ F: drivers/bus/pci/linux/*vfio*
 
 FreeBSD EAL (with overlaps)
 M: Bruce Richardson 
-M: Sergio Gonzalez Monroy 
 F: lib/librte_eal/bsdapp/Makefile
 F: lib/librte_eal/bsdapp/eal/
 F: doc/guides/freebsd_gsg/
 
 FreeBSD contigmem
 M: Bruce Richardson 
-M: Sergio Gonzalez Monroy 
 F: lib/librte_eal/bsdapp/contigmem/
 
 FreeBSD UIO
 M: Bruce Richardson 
-M: Sergio Gonzalez Monroy 
 F: lib/librte_eal/bsdapp/nic_uio/
 
 
@@ -966,7 +963,6 @@ M: Pablo de Lara 
 F: examples/helloworld/
 F: doc/guides/sample_app_ug/hello_world.rst
 
-M: Sergio Gonzalez Monroy 
 M: Radu Nicolau 
 F: examples/ipsec-secgw/
 F: doc/guides/sample_app_ug/ipsec_secgw.rst
-- 
2.9.5

Re: [dpdk-dev] [PATCH v3 5/5] bbdev: documentation

[Kovacevic, Marko]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Amr Mokhtar
> Sent: Thursday, December 7, 2017 9:41 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; Burakov, Anatoly ; De
> Lara Guarch, Pablo ; Power, Niall
> ; Macnamara, Chris ;
> Mokhtar, Amr 
> Subject: [dpdk-dev] [PATCH v3 5/5] bbdev: documentation
> 
> - Wireless Baseband Device Library Programmer’s Guide
> - test-bbdev User Guide
> - BBDEV Sample Application User Guides
> - Baseband Device Drivers Guides
> - Doxygen API
> 
> Signed-off-by: Amr Mokhtar 
> ---
>  doc/api/doxy-api-index.md  |   1 +
>  doc/api/doxy-api.conf  |   1 +
>  doc/guides/bbdevs/index.rst|  40 +++
>  doc/guides/bbdevs/null.rst |  77 +
>  doc/guides/bbdevs/turbo_sw.rst | 175 ++
>  doc/guides/index.rst   |   1 +
>  doc/guides/prog_guide/bbdev.rst| 613
> +
>  doc/guides/prog_guide/index.rst|   1 +
>  doc/guides/sample_app_ug/bbdev_app.rst | 160 +
>  doc/guides/sample_app_ug/index.rst |   1 +
>  doc/guides/tools/index.rst |   1 +
>  doc/guides/tools/testbbdev.rst | 600
> 
>  12 files changed, 1671 insertions(+)
>  create mode 100644 doc/guides/bbdevs/index.rst
>  create mode 100644 doc/guides/bbdevs/null.rst
>  create mode 100644 doc/guides/bbdevs/turbo_sw.rst
>  create mode 100644 doc/guides/prog_guide/bbdev.rst
>  create mode 100644 doc/guides/sample_app_ug/bbdev_app.rst
>  create mode 100644 doc/guides/tools/testbbdev.rst
> 
> diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
> index 3492702..8d7ff89 100644
> --- a/doc/api/doxy-api-index.md
> +++ b/doc/api/doxy-api-index.md
> @@ -50,6 +50,7 @@ The public API headers are grouped by topics:
>[bitrate](@ref rte_bitrate.h),
>[latency](@ref rte_latencystats.h),
>[devargs](@ref rte_devargs.h),
> +  [bbdev]  (@ref rte_bbdev.h),
>[PCI](@ref rte_pci.h)
> 
>  - **device specific**:
> diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
> index b2cbe94..241cae3 100644
> --- a/doc/api/doxy-api.conf
> +++ b/doc/api/doxy-api.conf
> @@ -39,6 +39,7 @@ INPUT   = doc/api/doxy-api-index.md \
>lib/librte_eal/common/include \
>lib/librte_eal/common/include/generic \
>lib/librte_acl \
> +  lib/librte_bbdev \
>lib/librte_bitratestats \
>lib/librte_cfgfile \
>lib/librte_cmdline \
> diff --git a/doc/guides/bbdevs/index.rst b/doc/guides/bbdevs/index.rst
> new file mode 100644
> index 000..c9aa1b0
> --- /dev/null
> +++ b/doc/guides/bbdevs/index.rst
> @@ -0,0 +1,40 @@
> +..
> +   BSD LICENSE
> +
> +   Copyright(c) 2017 Intel Corporation. All rights reserved.
> +
> +   Redistribution and use in source and binary forms, with or without
> +   modification, are permitted provided that the following conditions
> +   are met:
> +
> + * Redistributions of source code must retain the above copyright
> +   notice, this list of conditions and the following disclaimer.
> + * Redistributions in binary form must reproduce the above copyright
> +   notice, this list of conditions and the following disclaimer in
> +   the documentation and/or other materials provided with the
> +   distribution.
> + * Neither the name of Intel Corporation nor the names of its
> +   contributors may be used to endorse or promote products derived
> +   from this software without specific prior written permission.
> +
> +   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> +   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
> FOR
> +   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> +   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> +   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> +   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> USE,
> +   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> ON ANY
> +   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> +   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> +
> +Baseband Device Drivers
> +===
> +
> +.. toctree::
> +:maxdepth: 2
> +:numbered:
> +
> +null
> +turbo_sw
> diff --git a/doc/guides/bbdevs/null.rst b/doc/guides/bbdevs/null.rst
> new file mode 100644
> index 000..0f40232
> --- /dev/null
> +++ b/doc/guides/bbdevs/null.rst
> @@ -0,0 +1,77 @@
> +..
> +   BSD LICENSE
> +
> +   Copyright(

Re: [dpdk-dev] [PATCH] maintainers: resign from maintenance

[Bruce Richardson]

On Mon, Dec 18, 2017 at 02:02:06PM +, Sergio Gonzalez Monroy wrote:
> I will not be directly working on the DPDK project anymore.
> 
> Signed-off-by: Sergio Gonzalez Monroy 
> ---

With regret.

Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v4 2/4] change root makefile license to SPDX tag

[Bruce Richardson]

On Mon, Dec 18, 2017 at 06:09:02PM +0530, Hemant Agrawal wrote:
> Signed-off-by: Hemant Agrawal 
> ---
>  GNUmakefile | 29 +
>  Makefile| 29 +
>  2 files changed, 2 insertions(+), 56 deletions(-)
> 
Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for pktmbuf pool create API

[Neil Horman]

On Mon, Dec 18, 2017 at 01:51:52PM +, Wiles, Keith wrote:
> 
> 
> > On Dec 15, 2017, at 4:41 AM, Hemant Agrawal  wrote:
> > 
> > Introduce a new argument ops_name in rte_mempool_set_ops_byname
> > for allowing the application to optionally specify the mempool ops.
> > 
> > Signed-off-by: Hemant Agrawal 
> > ---
> > v2: fix checkpatch error
> > 
> > doc/guides/rel_notes/deprecation.rst | 3 +++
> > 1 file changed, 3 insertions(+)
> > 
> > diff --git a/doc/guides/rel_notes/deprecation.rst 
> > b/doc/guides/rel_notes/deprecation.rst
> > index 13e8543..968ca14 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -53,3 +53,6 @@ Deprecation Notices
> > 
> > * librte_meter: The API will change to accommodate configuration profiles.
> >   Most of the API functions will have an additional opaque parameter.
> > +
> > +* librte_mbuf: a new optional parameter for representing name of 
> > mempool_ops
> > +  will be added to the API ``rte_pktmbuf_pool_create``.
> 
> 
> Sorry, for the late response I was on vacation.
> 
> My question is why do we need to change rte_pktmbuf_pool_create ABI yet 
> again, why could we not add a new API to just set the name of the pool after 
> it is created. This would allow all current applications to work without any 
> ABI breakage and only require adding a new API call for anyone that wants the 
> name. The rte_pktmbuf_pool_create() routine could assign a default name or 
> some incrementing style name as the default. e.g. ‘pktmbuf_%d’ with a static 
> incrementing variable or whatever you like.
> 
> Sorry if this was asked and answered before.
+1, that seems like the more flexible solution.
Neil

> 
> > -- 
> > 2.7.4
> > 
> 
> Regards,
> Keith
> 

Re: [dpdk-dev] [PATCH 1/2] test: use env variable to run test if set

[Jerin Jacob]

-Original Message-
> Date: Mon, 18 Dec 2017 11:53:57 +
> From: Harry van Haaren 
> To: dev@dpdk.org
> CC: bruce.richard...@intel.com, Harry van Haaren
>  
> Subject: [dpdk-dev] [PATCH 1/2] test: use env variable to run test if set
> X-Mailer: git-send-email 2.7.4
> 
> This commit paves the way for the meson tests in the next
> patch. With this patch the test binary checks the DPDK_TEST
> environment variable and if set, the contents of the var
> are inserted on the test app command line, and run.
> 
> This allows testing of various different unit tests without
> manual interaction with the RTE>> test prompt, instead automating
> it using the DPDK_TEST environment variable.

Another alternative is to pipe the command.
example:
echo "eventdev_common_autotest" | sudo ./build/app/test 

Re: [dpdk-dev] [PATCH v2] virtio_net: kick guest even when virtio queue is full

[Patrik Andersson R]

Hi Maxime,

apologies for the late answer.

Yes I would think that it would solve the problem that we had. But
there is a slight risk that a driver in a VM (not within our area of 
influence) was partly responsible for the severity of the fault and 
that we might again experience some difficulties even with your
change. Though the risk is likely to be very low.

However, if your patch protects the file descriptors when in use I 
would consider that a better solution than doing the extra writes
on the full queue.

I would recommend going with your solution rather than the one
suggested by us.

Regards,

Patrik



Från: Maxime Coquelin 
Skickat: den 8 december 2017 17:11
Till: Ágota Benyhe; dev@dpdk.org
Kopia: Patrik Andersson R; Yuanhan Liu; Jianfeng Tan
Ämne: Re: [dpdk-dev] [PATCH v2] virtio_net: kick guest even when virtio queue 
is full
  

Hi Agota, Patrick,

On 12/05/2017 12:30 PM, Agota Benyhe wrote:
> From: Patrik Andersson R
> 
> Changing the vring call file descriptor during virtio device enqueue
> operation may lead to "kick" on a file descriptor that is closed. As
> a consequence the guest might not be notified of new packets in the
> enqueue.
> 
> The suggested change will add some extra load on DPDK and on the
> guest if the queue is frequently full. Any application using DPDK
> should avoid attempting retransmissions when the zero packets are
> enqueued.
> 
> To overcome this problem, the kick operation in virtio_dev_merge_rx()
> was excluded from the pkt_idx > 0 condition. A similar change was
> done in virtio_dev_rx().
> 
> Signed-off-by: Patrik Andersson R
> Signed-off-by: Agota Benyhe
> ---
>   lib/librte_vhost/virtio_net.c | 23 +--
>   1 file changed, 13 insertions(+), 10 deletions(-)

We are working on a patch that protects enqueue & dequeue paths from
vhost-user requests handling.
For your case, it would protect call_fd to be changed while vring is
being processed by the PMD thread.

Do you think that would solve the problem you are facing?

Regards,
Maxime

Re: [dpdk-dev] [PATCH v1] net/tap: allow user mac to be passed as args

[Varghese, Vipin]

On 11/30/2017 11:49 AM, Vipin Varghese wrote:
> One of the uses cases from customer site is use TAP PMD to intake user 
> specific MAC address during probe. This allows applications make use 
> of interfaces with desired MAC.
> 
> Extending MAC argumentinfrastructure for tap PMD; we pass custom MAC 
> address in string format (sample - 11:22:33:44:55:66).

Overall lgtm, please check a few comments below.

> 
> Signed-off-by: Vipin Varghese 
> ---
>  drivers/net/tap/rte_eth_tap.c | 56 
> +++
>  1 file changed, 52 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/tap/rte_eth_tap.c 
> b/drivers/net/tap/rte_eth_tap.c index 6b27679..0c53458 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -81,6 +81,8 @@
>  #define FLOWER_KERNEL_VERSION KERNEL_VERSION(4, 2, 0)  #define 
> FLOWER_VLAN_KERNEL_VERSION KERNEL_VERSION(4, 9, 0)
>  
> +static unsigned char user_mac[ETHER_ADDR_LEN];
> +
>  static struct rte_vdev_driver pmd_tap_drv;
>  
>  static const char *valid_arguments[] = { @@ -1291,13 +1293,20 @@ enum 
> ioctl_mode {
>   pmd->txq[i].fd = -1;
>   }
>  
> - if (fixed_mac_type) {
> + if (fixed_mac_type == 1) {

Instead of hardcoded type values 1 & 2, can you please use macros?
>> Ok, Adding MACROs MAC_STRING_NULL, MAC_STRING_FIXED and MAC_STRING_USER

>   /* fixed mac = 00:64:74:61:70: */
>   static int iface_idx;
>   char mac[ETHER_ADDR_LEN] = "\0dtap";
>  
>   mac[ETHER_ADDR_LEN - 1] = iface_idx++;
>   rte_memcpy(&pmd->eth_addr, mac, ETHER_ADDR_LEN);
> + } else if (fixed_mac_type == 2) {
> + /* user mac is recieved */

s/recieved/received
>> Ok

> + RTE_LOG(INFO, PMD,
> + "Using user MAC (%02x:%02x:%02x:%02x:%02x:%02x)\n",
> + user_mac[0], user_mac[1], user_mac[2],
> + user_mac[3], user_mac[4], user_mac[5]);
> + rte_memcpy(&pmd->eth_addr, user_mac, ETHER_ADDR_LEN);
>   } else {
>   eth_random_addr((uint8_t *)&pmd->eth_addr);
>   }
> @@ -1471,9 +1480,48 @@ enum ioctl_mode {
>const char *value,
>void *extra_args)
>  {
> - if (value &&
> - !strncasecmp(ETH_TAP_MAC_FIXED, value, strlen(ETH_TAP_MAC_FIXED)))
> - *(int *)extra_args = 1;
> + char macTemp[20], *macByte = NULL;
> + unsigned int index = 0;
> +
> + if (value) {
> + if (!strncasecmp(ETH_TAP_MAC_FIXED, value,
> + strlen(ETH_TAP_MAC_FIXED))) {
> + *(int *)extra_args = 1;
> + } else {
> + RTE_LOG(INFO, PMD, "User shared MAC param (%s)\n",
> + value);

Is this log needs to be in INFO level, since there is already and info level 
log when MAC set, what about making this debug?
>> Ok

> +
> + /* desired format aa:bb:cc:dd:ee:ff:11 */

Can you please update RTE_PMD_REGISTER_PARAM_STRING with new param, put 
expected format info there as well?
>> Ok

> + if (strlen(value) == 17) {
> + strncpy(macTemp, value, 18);
> +
> + macByte = strtok(macTemp, ":");
> + while ((macByte != NULL) &&
> + (strspn(macByte, 
> "0123456789ABCDEFabcdef")) &&
> + (strspn((macByte + 1), 
> "0123456789ABCDEFabcdef")) &&
> + (strlen(macByte) == 2)) {
> + user_mac[index] = strtoul(macByte, 
> NULL, 16);
> + macByte = strtok(NULL, ":");
> + index += 1;
> + }

I would extract the string to mac logic into its own function, but up to you.
>> not done

> +
> + if (index != 6) {
> + RTE_LOG(ERR, PMD, " failure in MAC 
> value (%s) at %u\n",
> + macByte, index + 1);
> + return -1;

And this is not related to this patch, but just as reminder, when a virtual 
driver probe fails vdev bus stops probing with an error, so all remaining 
virtual devices are not probed, in case one might want to fix ;)

> + }
> +
> + RTE_LOG(DEBUG, PMD, " User MAC (%s) 
> considered\n",

"User defined MAC" ? And can you please add an port identifier, port_id or 
device name or interface name, for the case there are multiple tap device to 
identify which one get user defined MAC.
VV> not done, each device in DPDK rte_eal_init is sequentially scanned and 
probed, hence log starts with 'iface,[parameters]', then probe, create and init 
is called for TAP PMD one after another. 
With minimalistic logging style the curr

Re: [dpdk-dev] [PATCH 0/2] next-build: add test app to build

[Van Haaren, Harry]

> From: Richardson, Bruce
> Sent: Monday, December 18, 2017 1:57 PM
> To: Van Haaren, Harry 
> Cc: dev@dpdk.org
> Subject: Re: [PATCH 0/2] next-build: add test app to build
> 
> On Mon, Dec 18, 2017 at 11:53:56AM +, Harry van Haaren wrote:
> > This patchset adds the test/test/test app to the Meson build.
> > In doing so, the test app is improved to allow running a unit
> > test by setting an environment variable. This allows the meson
> > test infrastructure to integrate with the DPDK tests. Some nice
> > improvements from the above integration, including debug aids...
> >
> > Run all autotests:
> > $ meson test
> >
> 
> meson or ninja?

meson. If I'm understanding correctly the "meson test" command invokes
the ninja test runner, however some of the argument mushing (eg: --gdb)
is performed by meson before launching ninja.


> > Run a specific test:
> > $ meson test ring_perf_autotest
> >
> > Run a specific test multiple times, eg brute-forcing race conditions:
> > $ meson test eventdev_sw_autotest --repeat=3
> >
> > Run a specific test multiple times in gdb, eg to drop to GDB if race
> found:
> > $ meson test eventdev_sw_autotest --repeat=3 --gdb
> >
> 
> The "repeat" and "gdb" arguments come built-in in meson, right, not from
> this patchset?

Yes correct, Meson provides this functionality.

Re: [dpdk-dev] [PATCH 1/2] test: use env variable to run test if set

[Van Haaren, Harry]

> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Monday, December 18, 2017 2:59 PM
> To: Van Haaren, Harry 
> Cc: dev@dpdk.org; Richardson, Bruce 
> Subject: Re: [dpdk-dev] [PATCH 1/2] test: use env variable to run test if
> set
> 
> -Original Message-
> > Date: Mon, 18 Dec 2017 11:53:57 +
> > From: Harry van Haaren 
> > To: dev@dpdk.org
> > CC: bruce.richard...@intel.com, Harry van Haaren
> >  
> > Subject: [dpdk-dev] [PATCH 1/2] test: use env variable to run test if set
> > X-Mailer: git-send-email 2.7.4
> >
> > This commit paves the way for the meson tests in the next
> > patch. With this patch the test binary checks the DPDK_TEST
> > environment variable and if set, the contents of the var
> > are inserted on the test app command line, and run.
> >
> > This allows testing of various different unit tests without
> > manual interaction with the RTE>> test prompt, instead automating
> > it using the DPDK_TEST environment variable.
> 
> Another alternative is to pipe the command.
> example:
> echo "eventdev_common_autotest" | sudo ./build/app/test


With the current implementation, meson handles which tests to run, and the 
command line. This gives us a clean interface from which to run tests. Note 
that the following command will run the tests requested:

$ meson test ring_autotest ring_perf_autotest acl_autotest

Meson itself supports two methods of launching tests from the same binary: argv 
and env variables. In this implementation, the DPDK_TEST env is set by the test 
runner - and the user doesn't have to use it manually at all, and it is not 
exported in the shell after the tests have run.

In short - I don't see added value in reworking this to argc argv, or in using 
terminal tricks like echo "test" | sudo ./test.

Actually, the current method has an easter egg included:
If a developer is focused on a single test-case (TDD anyone? :), then they 
could use the DPDK_TEST env var as a feature, $ export DPDK_TEST=ring_autotest  
and run that test automatically when the binary is launched.

Re: [dpdk-dev] [PATCH 2/2] meson: add tests app to build

[Van Haaren, Harry]

> From: Richardson, Bruce
> Sent: Monday, December 18, 2017 1:55 PM
> To: Van Haaren, Harry 
> Cc: dev@dpdk.org
> Subject: Re: [PATCH 2/2] meson: add tests app to build
> 
> On Mon, Dec 18, 2017 at 11:53:58AM +, Harry van Haaren wrote:
> > This patch enables the test/test app to be built. It also adds
> > the test binary to be a meson-test, which allows the meson test
> > infrastructure to be used to run tests.
> >
> > Tests are listed using the same test binary, however each test
> > sets a different DPDK_TEST environment variable. The string contents
> > of this DPDK_TEST env var is entered in the command line interface.
> > As such, the familiar test names such as "ring_perf_autotest" etc
> > are valid tests to run using this meson test infrastructure.
> >
> > Note that the tests are run serially, given that we cannot run
> > multiple primary processes at a time. As each test must initialize
> > EAL this takes some time depending on the number of hugepages.
> > In future, we could improve this to run multiple tests from one
> > EAL init, but it is out of scope for this patchset.
> >
> > Finally, an option to build the tests is added to the meson build
> > options. When disabled, the unit test code in test/test is not
> > compiled. The default is set to 'true'. To disable, run:
> >
> > $ meson configure -Dtests=false
> >
> > Signed-off-by: Harry van Haaren 
> > ---
> 
> 
> > +
> > +test_names = [
> > +   'acl_autotest',
> > +   'alarm_autotest',

> > +   'user_delay_us',
> > +   'version_autotest',
> > +]
> 
> I think we should find a way to remove this long list of test names in
> the build file. The list of available tests is built up dynamically
> inside the test binary, so I'm wondering if we can add to the binary an
> "all" option to run each autotest straight after each other?


Agree - it would be nice if we don't have to specify tests here. We could add a 
flag the test binary, to output the tests that it contains? Then its about 
having Meson read this file before running tests, to "gather" the tests 
available..

There's options, but they will probably all be more complex than just having a 
list of tests.

Re Run all tests: Currently   $ meson test will run all unit tests.


> > +
> > +if dpdk_conf.has('RTE_LIBRTE_PDUMP')
> > +   test_deps += 'pdump'
> > +endif
> > +if dpdk_conf.has('RTE_LIBRTE_I40E_PMD')
> > +   test_deps += 'pmd_i40e'
> > +endif
> > +if dpdk_conf.has('RTE_LIBRTE_IXGBE_PMD')
> > +   test_deps += 'pmd_ixgbe'
> > +endif
> > +
> 
> This should be moved up beside the other dependencies
> 
> > +test_dep_objs = []
> > +foreach d:test_deps
> > +   def_lib = get_option('default_library')
> > +   test_dep_objs += get_variable(def_lib + '_rte_' + d)
> > +endforeach
> > +
> > +link_libs = []
> > +if get_option('default_library') == 'static'
> > +   link_libs = dpdk_drivers
> > +endif
> > +
> 
> A note for the future: since much of this looks similar to that in
> testpmd we should look to see if we can find a way to easily consolidate
> these build commands inside a foreach loop like is done for the libs,
> drivers and examples.

+1, good idea for a cleanup later.

Meson >= 0.44 has a "disabler" concept[1], which is a clean way to disable 
components in the build if dependencies aren't found. Eg: specific tests or 
sample apps, can be disabled from the build without the if() logic required as 
below.

[1] http://mesonbuild.com/Disabler.html


> > +if get_option('tests')
> > +   dpdk_test = executable('dpdk-test',
> > +   test_sources,
> > +   link_whole: link_libs,
> > +   dependencies: test_dep_objs,
> > +   install_rpath: driver_install_path,
> > +   install: false)
> > +
> > +   # some perf tests (eg: memcpy perf autotest)take very long
> > +   # to complete, so timeout to 10 minutes
> > +   timeout_seconds = 600
> > +
> > +   foreach t:test_names
> > +   test(t, dpdk_test,
> > +   env : ['DPDK_TEST='+t],
> > +   timeout : timeout_seconds,
> > +   is_parallel : false)
> > +   endforeach
> > +endif
> > --
> > 2.7.4
> >

[dpdk-dev] [PATCH v2 2/2] eal/x86: Use lock-prefixed instructions to reduce cost of rte_smp_mb()

[Konstantin Ananyev]

On x86 it  is possible to use lock-prefixed instructions to get
the similar effect as mfence.
As pointed by Java guys, on most modern HW that gives a better
performance than using mfence:
https://shipilev.net/blog/2014/on-the-fence-with-dependencies/
That patch adopts that technique for rte_smp_mb() implementation.
On BDW 2.2 mb_autotest on single lcore reports 2X cycle reduction,
i.e. from ~110 to ~55 cycles per operation.

Signed-off-by: Konstantin Ananyev 
---
 .../common/include/arch/x86/rte_atomic.h   | 44 +-
 1 file changed, 42 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic.h 
b/lib/librte_eal/common/include/arch/x86/rte_atomic.h
index 4eac66631..8b68ba327 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_atomic.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_atomic.h
@@ -55,12 +55,52 @@ extern "C" {
 
 #definerte_rmb() _mm_lfence()
 
-#define rte_smp_mb() rte_mb()
-
 #define rte_smp_wmb() rte_compiler_barrier()
 
 #define rte_smp_rmb() rte_compiler_barrier()
 
+/*
+ * From Intel Software Development Manual; Vol 3;
+ * 8.2.2 Memory Ordering in P6 and More Recent Processor Families:
+ * ...
+ * . Reads are not reordered with other reads.
+ * . Writes are not reordered with older reads.
+ * . Writes to memory are not reordered with other writes,
+ *   with the following exceptions:
+ *   . streaming stores (writes) executed with the non-temporal move
+ * instructions (MOVNTI, MOVNTQ, MOVNTDQ, MOVNTPS, and MOVNTPD); and
+ *   . string operations (see Section 8.2.4.1).
+ *  ...
+ * . Reads may be reordered with older writes to different locations but not
+ * with older writes to the same location.
+ * . Reads or writes cannot be reordered with I/O instructions,
+ * locked instructions, or serializing instructions.
+ * . Reads cannot pass earlier LFENCE and MFENCE instructions.
+ * . Writes ... cannot pass earlier LFENCE, SFENCE, and MFENCE instructions.
+ * . LFENCE instructions cannot pass earlier reads.
+ * . SFENCE instructions cannot pass earlier writes ...
+ * . MFENCE instructions cannot pass earlier reads, writes ...
+ *
+ * As pointed by Java guys, that makes possible to use lock-prefixed
+ * instructions to get the same effect as mfence and on most modern HW
+ * that gives a better perfomance then using mfence:
+ * https://shipilev.net/blog/2014/on-the-fence-with-dependencies/
+ * Basic idea is to use lock prefixed add with some dummy memory location
+ * as the destination. From their experiments 128B(2 cache lines) below
+ * current stack pointer looks like a good candidate.
+ * So below we use that techinque for rte_smp_mb() implementation.
+ */
+
+static __rte_always_inline void
+rte_smp_mb(void)
+{
+#ifdef RTE_ARCH_I686
+   asm volatile("lock addl $0, -128(%%esp); " ::: "memory");
+#else
+   asm volatile("lock addl $0, -128(%%rsp); " ::: "memory");
+#endif
+}
+
 #define rte_io_mb() rte_mb()
 
 #define rte_io_wmb() rte_compiler_barrier()
-- 
2.13.5

[dpdk-dev] [PATCH v2 1/2] test/test: introduce new test-case for rte_smp_mb()

[Konstantin Ananyev]

Simple functional test for rte_smp_mb() implementations.
Also when executed on a single lcore could be used as rough
estimation how many cycles particular implementation of rte_smp_mb()
might take.

Signed-off-by: Konstantin Ananyev 
---
 test/test/Makefile  |   1 +
 test/test/test_mb.c | 315 
 2 files changed, 316 insertions(+)
 create mode 100644 test/test/test_mb.c

diff --git a/test/test/Makefile b/test/test/Makefile
index bb54c9808..3134283a8 100644
--- a/test/test/Makefile
+++ b/test/test/Makefile
@@ -95,6 +95,7 @@ SRCS-y += test_spinlock.c
 SRCS-y += test_memory.c
 SRCS-y += test_memzone.c
 SRCS-y += test_bitmap.c
+SRCS-y += test_mb.c
 
 SRCS-y += test_ring.c
 SRCS-y += test_ring_perf.c
diff --git a/test/test/test_mb.c b/test/test/test_mb.c
new file mode 100644
index 0..52c73fb6b
--- /dev/null
+++ b/test/test/test_mb.c
@@ -0,0 +1,315 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2017 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+ /*
+  * This is a simple functional test for rte_smp_mb() implementation.
+  * I.E. make sure that LOAD and STORE operations that precede the
+  * rte_smp_mb() call are globally visible across the lcores
+  * before the the LOAD and STORE operations that follows it.
+  * The test uses simple implementation of Peterson's lock algorithm
+  * (https://en.wikipedia.org/wiki/Peterson%27s_algorithm)
+  * for two execution units to make sure that rte_smp_mb() prevents
+  * store-load reordering to happen.
+  * Also when executed on a single lcore could be used as a approxiamate
+  * estimation of number of cycles particular implementation of rte_smp_mb()
+  * will take.
+  */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+#define ADD_MAX8
+#define ITER_MAX   0x100
+
+enum plock_use_type {
+   USE_MB,
+   USE_SMP_MB,
+   USE_NUM
+};
+
+struct plock {
+   volatile uint32_t flag[2];
+   volatile uint32_t victim;
+   enum plock_use_type utype;
+};
+
+/*
+ * Lock plus protected by it two counters.
+ */
+struct plock_test {
+   struct plock lock;
+   uint32_t val;
+   uint32_t iter;
+};
+
+/*
+ * Each active lcore shares plock_test struct with it's left and right
+ * neighbours.
+ */
+struct lcore_plock_test {
+   struct plock_test *pt[2]; /* shared, lock-protected data */
+   uint32_t sum[2];  /* local copy of the shared data */
+   uint32_t iter;/* number of iterations to perfom */
+   uint32_t lc;  /* given lcore id */
+};
+
+static inline void
+store_load_barrier(uint32_t utype)
+{
+   if (utype == USE_MB)
+   rte_mb();
+   else if (utype == USE_SMP_MB)
+   rte_smp_mb();
+   else
+   RTE_VERIFY(0);
+}
+
+/*
+ * Peterson lock implementation.
+ */
+static void
+plock_lock(struct plock *l, uint32_t self)
+{
+   uint32_t other;
+
+   other = self ^ 1;
+
+   l->flag[self] = 1;
+   l->victim = self;
+
+   store_load_barrier(l->utype);
+
+   while (l->flag[other] == 1 && l->victim == self)
+   rte_pause();
+}
+
+static void
+plock_unlock(struct plock *l, uint32_t self)
+{
+   rte_smp_wmb();
+ 

[dpdk-dev] [PATCH v2 0/2] eal/x86: Optimize rte_smp_mb() and create a new test case for it

[Konstantin Ananyev]

v2 changes:
  Address Bruce code-review comments:
  - get rid of macros to simplify the code
  - add more comments to the test case

Konstantin Ananyev (2):
  test/test: introduce new test-case for rte_smp_mb()
  eal/x86: Use lock-prefixed instructions to reduce cost of rte_smp_mb()

 .../common/include/arch/x86/rte_atomic.h   |  44 ++-
 test/test/Makefile |   1 +
 test/test/test_mb.c| 315 +
 3 files changed, 358 insertions(+), 2 deletions(-)
 create mode 100644 test/test/test_mb.c

-- 
2.13.5

Re: [dpdk-dev] [PATCH 1/2] test: use env variable to run test if set

[Jerin Jacob]

-Original Message-
> Date: Mon, 18 Dec 2017 15:24:22 +
> From: "Van Haaren, Harry" 
> To: Jerin Jacob 
> CC: "dev@dpdk.org" , "Richardson, Bruce"
>  
> Subject: RE: [dpdk-dev] [PATCH 1/2] test: use env variable to run test if
>  set
> 
> > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > Sent: Monday, December 18, 2017 2:59 PM
> > To: Van Haaren, Harry 
> > Cc: dev@dpdk.org; Richardson, Bruce 
> > Subject: Re: [dpdk-dev] [PATCH 1/2] test: use env variable to run test if
> > set
> > 
> > -Original Message-
> > > Date: Mon, 18 Dec 2017 11:53:57 +
> > > From: Harry van Haaren 
> > > To: dev@dpdk.org
> > > CC: bruce.richard...@intel.com, Harry van Haaren
> > >  
> > > Subject: [dpdk-dev] [PATCH 1/2] test: use env variable to run test if set
> > > X-Mailer: git-send-email 2.7.4
> > >
> > > This commit paves the way for the meson tests in the next
> > > patch. With this patch the test binary checks the DPDK_TEST
> > > environment variable and if set, the contents of the var
> > > are inserted on the test app command line, and run.
> > >
> > > This allows testing of various different unit tests without
> > > manual interaction with the RTE>> test prompt, instead automating
> > > it using the DPDK_TEST environment variable.
> > 
> > Another alternative is to pipe the command.
> > example:
> > echo "eventdev_common_autotest" | sudo ./build/app/test
> 
> 
> With the current implementation, meson handles which tests to run, and the 
> command line. This gives us a clean interface from which to run tests. Note 
> that the following command will run the tests requested:
> 
> $ meson test ring_autotest ring_perf_autotest acl_autotest
> 
> Meson itself supports two methods of launching tests from the same binary: 
> argv and env variables. In this implementation, the DPDK_TEST env is set by 
> the test runner - and the user doesn't have to use it manually at all, and it 
> is not exported in the shell after the tests have run.
> 
> In short - I don't see added value in reworking this to argc argv, or in 
> using terminal tricks like echo "test" | sudo ./test.
> 
> Actually, the current method has an easter egg included:
> If a developer is focused on a single test-case (TDD anyone? :), then they 
> could use the DPDK_TEST env var as a feature, $ export 
> DPDK_TEST=ring_autotest  and run that test automatically when the binary is 
> launched.

Yup. I don't see any harm in exposing DPDK_TEST means of test selection.

Re: [dpdk-dev] [PATCH v2 2/2] eal/x86: Use lock-prefixed instructions to reduce cost of rte_smp_mb()

[Bruce Richardson]

On Mon, Dec 18, 2017 at 03:34:13PM +, Konstantin Ananyev wrote:
> On x86 it  is possible to use lock-prefixed instructions to get
> the similar effect as mfence.
> As pointed by Java guys, on most modern HW that gives a better
> performance than using mfence:
> https://shipilev.net/blog/2014/on-the-fence-with-dependencies/
> That patch adopts that technique for rte_smp_mb() implementation.
> On BDW 2.2 mb_autotest on single lcore reports 2X cycle reduction,
> i.e. from ~110 to ~55 cycles per operation.
> 
> Signed-off-by: Konstantin Ananyev 
> ---
Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v4 2/4] change root makefile license to SPDX tag

[Bruce Richardson]

On Mon, Dec 18, 2017 at 06:09:02PM +0530, Hemant Agrawal wrote:
> Signed-off-by: Hemant Agrawal 
> ---
>  GNUmakefile | 29 +
>  Makefile| 29 +
>  2 files changed, 2 insertions(+), 56 deletions(-)
> 
> diff --git a/GNUmakefile b/GNUmakefile
> index 45b7fbb..2ff3e4b 100644
> --- a/GNUmakefile
> +++ b/GNUmakefile
> @@ -1,33 +1,6 @@
> -#   BSD LICENSE
> +# SPDX-License-Identifier: BSD-3-Clause
>  #
>  #   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.

Actually, minor comment, can we remove the blank line between the SPDX
identifier and the copyright? Given that in the majority of cases, we
will only have one line each, having a space between them is a) probably
unnecessary, and b) looks weird IMHO.

I'm currently working on a patchset to update the meson.build files, and
I think having:

# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation

looks better as a header than two one-line paragraphs.

/Bruce

Re: [dpdk-dev] [PATCH] igb_uio: allow multi-process access

[Wang, Xiao W]

Hi,

> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Tuesday, December 12, 2017 9:39 AM
> To: Wang, Xiao W 
> Cc: Yigit, Ferruh ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] igb_uio: allow multi-process access
> 
> On Fri,  8 Dec 2017 17:57:33 -0800
> Xiao Wang  wrote:
> 
> > In some case, one device are accessed by different processes via
> > different BARs, so one uio device may be opened by more than one
> > process, for this case we just need to enable interrupt once, and
> > pci_clear_master only when the last process closed.
> >
> > Fixes: 5f6ff30dc507 ("igb_uio: fix interrupt enablement after FLR in VM")
> 
> 
> Yes, this makes sense.
> 
> >
> > Signed-off-by: Xiao Wang 
> > ---
> >  lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > index a3a98c1..c239d98 100644
> > --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > @@ -45,6 +45,7 @@ struct rte_uio_pci_dev {
> > struct uio_info info;
> > struct pci_dev *pdev;
> > enum rte_intr_mode mode;
> > +   uint32_t ref_cnt;
> 
> Simple unsigned reference count is not SMP safe on all architectures.
> In kernel it is recommended to use refcount_t and associated API's.
> Note: refcount_t was introduced in last 2 years and some DPDK users
> still have ancient kernels.

I think atomic_t associated API will be enough, without worry about kernel 
version.

> 
> >  };
> >
> >  static char *intr_mode;
> > @@ -336,6 +337,9 @@ struct rte_uio_pci_dev {
> > struct pci_dev *dev = udev->pdev;
> > int err;
> >
> > +   if (++(udev->ref_cnt) > 1)
> > +   return 0;
> 
> Do not use (unnecessary) parenthesis. C precedence order is well defined.

Agree. Will change it in v2.

Thanks for your comments,
Xiao

Re: [dpdk-dev] [PATCH v4 2/4] change root makefile license to SPDX tag

[Thomas Monjalon]

18/12/2017 16:52, Bruce Richardson:
> On Mon, Dec 18, 2017 at 06:09:02PM +0530, Hemant Agrawal wrote:
> > --- a/GNUmakefile
> > +++ b/GNUmakefile
> > @@ -1,33 +1,6 @@
> > -#   BSD LICENSE
> > +# SPDX-License-Identifier: BSD-3-Clause
> >  #
> >  #   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
> 
> Actually, minor comment, can we remove the blank line between the SPDX
> identifier and the copyright? Given that in the majority of cases, we
> will only have one line each, having a space between them is a) probably
> unnecessary, and b) looks weird IMHO.
> 
> I'm currently working on a patchset to update the meson.build files, and
> I think having:
> 
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2017 Intel Corporation
> 
> looks better as a header than two one-line paragraphs.

+1, I agree with Bruce

Re: [dpdk-dev] [RFC] eventdev: add crypto adapter API header

[Eads, Gage]

> -Original Message-
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Monday, December 18, 2017 12:30 AM
> To: Eads, Gage 
> Cc: Gujjar, Abhinandan S ; dev@dpdk.org;
> Vangati, Narender ; Rao, Nikhil
> ; hemant.agra...@nxp.com; Doherty, Declan
> ; nidadavolu.mur...@cavium.com;
> nithin.dabilpu...@cavium.com; narayanaprasad.athr...@cavium.com
> Subject: Re: [RFC] eventdev: add crypto adapter API header
> 
> -Original Message-
> > Date: Thu, 14 Dec 2017 18:52:02 +
> > From: "Eads, Gage" 
> > To: Jerin Jacob 
> > CC: "Gujjar, Abhinandan S" , "dev@dpdk.org"
> >  , "Vangati, Narender" ,
> > "Rao,  Nikhil" , "hemant.agra...@nxp.com"
> >  , "Doherty, Declan"
> > ,  "nidadavolu.mur...@cavium.com"
> > ,  "nithin.dabilpu...@cavium.com"
> > ,  "narayanaprasad.athr...@cavium.com"
> > 
> > Subject: RE: [RFC] eventdev: add crypto adapter API header
> >
> >
> >
> > > -Original Message-
> > > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > > Sent: Wednesday, December 13, 2017 8:49 PM
> > > To: Eads, Gage 
> > > Cc: Gujjar, Abhinandan S ;
> > > dev@dpdk.org; Vangati, Narender ; Rao,
> > > Nikhil ; hemant.agra...@nxp.com; Doherty,
> > > Declan ; nidadavolu.mur...@cavium.com;
> > > nithin.dabilpu...@cavium.com; narayanaprasad.athr...@cavium.com
> > > Subject: Re: [RFC] eventdev: add crypto adapter API header
> > >
> > > -Original Message-
> > > > Date: Wed, 13 Dec 2017 23:35:48 +
> > > > From: "Eads, Gage" 
> > > > To: Jerin Jacob , "Gujjar, Abhinandan
> S"
> > > >  
> > > > CC: "dev@dpdk.org" , "Vangati, Narender"
> > > >  , "Rao, Nikhil"
> > > > , "hemant.agra...@nxp.com"
> , "Doherty, Declan"
> > > >  , "nidadavolu.mur...@cavium.com"
> > > >  , "nithin.dabilpu...@cavium.com"
> > > >  ,
> "narayanaprasad.athr...@cavium.com"
> > > >  
> > > > Subject: RE: [RFC] eventdev: add crypto adapter API header
> > > >
> > > > Hey Jerin,
> > >
> > > Hey Gage,
> > >
> > > >
> > > > 
> > > >
> > > > > > +
> > > > > > + /**
> > > > > > + * @warning
> > > > > > + * @b EXPERIMENTAL: this enum may change without prior notice
> > > > > > + *
> > > > > > + * Crypto event adapter type
> > > > > > + */
> > > > > > +enum rte_event_crypto_adapter_type {
> > > > > > +   RTE_EVENT_CRYPTO_ADAPTER_RX_ONLY = 1,
> > > > > > +   /**< Start only Rx part of crypto adapter.
> > > > > > +   * Packets dequeued from cryptodev are new to eventdev and
> > > > > > +   * events will be treated as RTE_EVENT_OP_NEW */
> > > > > > +   RTE_EVENT_CRYPTO_ADAPTER_RX_TX,
> > > > > > +   /**< Start both Rx & Tx part of crypto adapter.
> > > > > > +   * Packet's event context will be retained and
> > > > > > +   * event will be treated as RTE_EVENT_OP_FORWARD */ };
> > > > >
> > > > > How about leveraging ev.op based schematics as mentioned above?
> > > >
> > > > That could work, but perhaps the ev.op should be configured once
> > > > up front, as
> > > I see it being a function of the application architecture. A couple
> > > possible designs, for example:
> > > > - Worker enqueues into cryptodev, adapter polls for response: the
> > > > adapter
> > > port would always use OP_NEW here.
> > > > - Worker sends a crypto request event to the adapter, which gives
> > > > the request to the cryptodev and polls for response: the adapter
> > > > port would always use OP_FWD here. (This ties in with my implicit
> > > > release patch
> > > > (http://dpdk.org/ml/archives/dev/2017-December/083535.html))
> > > > - Etc.
> > >
> > > Yes. Semantically both approaches will work. I was trying to avoid
> > > extra clutter(enum rte_event_crypto_adapter_type) in adapter API.
> > > I don't see any problem in moving ev.op to adapter configuration
> > > time if it helps the SW driver.
> > >
> > > IMO, We can change RTE_EVENT_CRYPTO_ADAPTER_RX_ONLY and
> > > RTE_EVENT_CRYPTO_ADAPTER_RX_TX to more appropriate name,
> something
> > > like,
> RTE_EVENT_CRYPTO_ADAPTER_TYPE_OP_NEW/RTE_EVENT_CRYPTO_ADAPTE
> > > R_TYPE_OP_FWD
> > > or something like that.
> > >
> >
> > I agree that the two naming schemes are equivalent, but since this option
> would control the adapter's behavior (Rx only vs. Rx + Tx), (IMO) I think
> Abhinandan's original names do a better job of conveying what effect these two
> options have on the adapter, compared to the op type names.
> 
> The only concern with Rx/Tx terminology was, It is mostly used in the ethdev
> domain.
> In crypto domain, typically, we use enqueue/dequeue.
> The only difference between two modes is if adapter enqueue the events with
> RTE_EVENT_OP_NEW vs RTE_EVENT_OP_FORWARD then (IMO) we can change
> something related to that name to avoid adding a new terminology.
> 

Oh, sure -- enqueue/dequeue makes sense here. I'd still prefer DEQ_ONLY or 
DEQ_ENQ, but the event_op names work just as well.

Speaking of the crypto domain, the cryptodev enqueue and dequeue operations 
both take crypto op pointers. The original RFC had the request event pointing 
to an mbuf (which had a crypto_op point

Re: [dpdk-dev] [RFC PATCH 0/3] ethdev: few changes in rte_ethdev layer

[Jerin Jacob]

-Original Message-
> Date: Thu, 14 Dec 2017 13:57:02 +
> From: "Ananyev, Konstantin" 
> To: Jerin Jacob 
> CC: "dev@dpdk.org" , "shah...@mellanox.com"
>  
> Subject: RE: [dpdk-dev] [RFC PATCH 0/3] ethdev: few changes in rte_ethdev
>  layer
> 
> Hi Jerin,

Hi Konstantin,

> 
> > 
> > Hi Konstantin,
> > 
> > > The series introduces 2 main changes:
> > >
> > > 1.Introduce a separate data structure (rte_eth_queue_local)
> > > to store local to given process (i.e. no-shareable) information
> > > for each configured rx/tx queue.
> > > Memory for that structure is allocated/freed dynamically during
> > > rte_eth_dev_configure().
> > > Reserve a space for queue specific (rx|tx)_pkt_burst(),
> > > tx_pkt_prepare() function pointers inside that structure.
> > > Move rx/tx callback related information inside that structure.
> > > That introduces a change in current behavior: all callbacks for
> > > un-configured queues will be automatically removed.
> > > Also as size of struct rte_eth_dev changes that patch is an ABI breakage,
> > > so deprecation notice for 18.05 is filled.
> > > Further suggestions how to introduce the same functionality
> > > without ABI breakage are welcome.
> > 
> > Are we doing this to enable, Tx/Rx queue specific burst functions to
> > invoke based on new TX/RX queue specific offloads framework.
> > Meaning, if a offload configured for the given queue,
> > driver can select a different function pointer for Rx/Tx burst functions.
> 
> Yes that's the stretch goal.
> We do need some extra space for rx/tx callbacks (use field) that needs to
> be cache aligned and we plan to make rx/tx function per queue.
> So I thought it would be a good opportunity to do these 2 things in one go -
> to minimize number of ABI breakages. 

Makes sense.

> 
> > 
> > >
> > > 2. Make it safe to remove rx/tx callback at runtime.
> > > Right now it is not possible for the application to figure out
> > > when it is safe to free removed callback handle and
> > > associated with it resources(unless the queue is stopped).
> > > That's probably not a big problem if all callbacks are static
> > > hange through whole application lifetime)
> > > and/or application doesn't allocate any resources for the callback 
> > > handler.
> > > Though if callbacks have to be added/removed dynamically and
> > > callback handler would require more resources to operate properly -
> > > then it might become an issue.
> > > So patch #2 fixes that problem - now as soon as
> > > rte_eth_remove_(rx|tx)_callback() completes successfully, application
> > > can safely free all associated with the removed callback resources.
> > >
> > > Performance impact:
> > > If application doesn't use RX/TX callbacks, then the tests I run didn't
> > > reveal any performance degradation.
> > > Though if application do use RX/TX callbacks - patch #2 does introduce
> > > some slowdown.
> > >
> > > To be more specific here, on BDW (E5-2699 v4) 2.2GHz, 4x10Gb (X520-4)
> > > with http://dpdk.org/dev/patchwork/patch/31864/ patch installed I got:
> > > 1) testpmd ... --latencystats=1 - slowdown < 1%
> > > 2) examples//l3fwd ... --parse-ptype - - slowdown < 1%
> > > 3) examples/rxtx_callbacks - slowdown ~8%
> > > All that in terms of packet throughput (Mpps).
> > 
> > We tried on an arm64 machine; We got following result on host and guest
> > using l3fwd.
> 
> Thanks for testing it.
> So these numbers below - are for l3fwd running with or without rx callback 
> installed?
> i.e. with or without '--parse-ptype' option (and on a NIC with/without ptype 
> HW support)?

without '--parse-ptype' option(i.e without rx callback installed).
That makes it sad, Even though application is not using the rx callback,
We need to pay on a average 3% drop in performance(based on the
use case/arch/SoC/topology etc)

> 
> > 
> > 
> > Note:
> > +ve number means "Performance regression with patches"
> > -ve number means "Performance improvement with patches"
> > 
> > Relative performance difference in percentage:
> > 
> > % difference on host (2 x 40G)
> > pkt_sz  1c  2c  4c  8c
> > 64  1.410.180.510.29
> > 72  0.500.530.090.19
> > 128 0.310.310.420.00
> > 256 -0.44   -0.44   0.000.00
> > 512 1.941.940.010.01
> > 10240.000.010.000.01
> > 15180.020.010.020.02
> > 
> > % difference on guest (2 x 40G)
> > pkt_sz  1c  2c  4c  8c
> > 64  5.782.30-2.45   -0.01
> > 72  1.131.131.31-4.29
> > 128 1.361.361.54-0.82
> > 256 2.022.03-0.01   -0.35
> > 512 4.054.040.00-0.46
> > 10240.390.380.00-0.74
> > 15180.000.00-0.05   -4.20
> > 
> > I think, it is because we added more code under
> > the RTE_ETHDEV_RXTX_CALLBACKS and it is enabled by
> > default.
> > 
> > I think, the impact will vary based on
> > architecture and underneath i-cache, d-cache and IPC.
> > 
> > I am just thinking

[dpdk-dev] [PATCH v1 0/3] Introduce virtual PMD for Hyper-V/Azure platforms

[Adrien Mazarguil]

Virtual machines hosted by Hyper-V/Azure platforms are fitted with
simplified virtual network devices named NetVSC that are used for fast
communication between VM to VM, VM to hypervisor, and the outside.

They appear as standard system netdevices to user-land applications, the
main difference being they are implemented on top of VMBUS [1] instead of
emulated PCI devices.

While this reads like a case for a standard DPDK PMD, there is more to it.

To accelerate outside communication, NetVSC devices as they appear in a VM
can be paired with physical SR-IOV virtual function (VF) devices owned by
that same VM [2]. Both netdevices share the same MAC address in that case.

When paired, egress and most of the ingress traffic flow through the VF
device, while part of it (e.g. multicasts, hypervisor control data) still
flows through NetVSC. Moreover VF devices are not retained and disappear
during VM migration; from a VM standpoint, they can be hot-plugged anytime
with NetVSC acting as a fallback.

Running DPDK applications in such a context involves driving VF devices
using their dedicated PMDs in a vendor-independent fashion (to benefit from
maximum performance without writing dedicated code) while simultaneously
listening to NetVSC and handling the related hot-plug events.

This new virtual PMD (referred to as "hyperv" from this point on)
automatically coordinates the Hyper-V/Azure-specific management part
described above by relying on vendor-specific, failsafe and tap PMDs to
expose a single consolidated Ethernet device usable directly by existing
applications.

 .--.
 | DPDK application |
 `+-'
  |
   .--+--.
   | DPDK ethdev |
   `--+--'   Control
  | |
 .+.v..
 |   failsafe PMD  +-+ hyperv PMD |
 `--+---+--' `'
|   |
|  .|.
|  :|:
   .+. :   .+.   :
   | tap PMD | :   | any PMD |   :
   `+' :   `+'   : <-- Hot-pluggable
|  :|:
 .--+---.  :  .-+-.  :
 | NetVSC-based |  :  | SR-IOV VF |  :
 |   netdevice  |  :  |   device  |  :
 `--'  :  `---'  :
   :.:

Note this diagram differs from that of the original RFC [3], with hyperv no
longer acting as a data plane layer.

This initial version of the driver only works in whitelist mode. Users have
to provide the --vdev net_hyperv EAL option at least once to trigger it.

Subsequent work will add support for blacklist mode based on automatic
detection of the host environment.

[1] http://dpdk.org/ml/archives/dev/2017-January/054165.html
[2] 
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-hyper-v
[3] http://dpdk.org/ml/archives/dev/2017-November/082339.html

Adrien Mazarguil (3):
  net/hyperv: introduce MS Hyper-V platform driver
  net/hyperv: implement core functionality
  net/hyperv: add "force" parameter

 MAINTAINERS   |   6 +
 config/common_base|   6 +
 config/common_linuxapp|   1 +
 doc/guides/nics/features/hyperv.ini   |  12 +
 doc/guides/nics/hyperv.rst| 119 +++
 doc/guides/nics/index.rst |   1 +
 drivers/net/Makefile  |   1 +
 drivers/net/hyperv/Makefile   |  58 ++
 drivers/net/hyperv/hyperv.c   | 799 +
 drivers/net/hyperv/rte_pmd_hyperv_version.map |   4 +
 mk/rte.app.mk |   1 +
 11 files changed, 1008 insertions(+)
 create mode 100644 doc/guides/nics/features/hyperv.ini
 create mode 100644 doc/guides/nics/hyperv.rst
 create mode 100644 drivers/net/hyperv/Makefile
 create mode 100644 drivers/net/hyperv/hyperv.c
 create mode 100644 drivers/net/hyperv/rte_pmd_hyperv_version.map

-- 
2.11.0

[dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Adrien Mazarguil]

As described in more details in the attached documentation (see patch
contents), this virtual device driver manages NetVSC interfaces in virtual
machines hosted by Hyper-V/Azure platforms.

This driver does not manage traffic nor Ethernet devices directly; it acts
as a thin configuration layer that automatically instantiates and controls
fail-safe PMD instances combining tap and PCI sub-devices, so that each
NetVSC interface is exposed as a single consolidated port to DPDK
applications.

PCI sub-devices being hot-pluggable (e.g. during VM migration),
applications automatically benefit from increased throughput when present
and automatic fallback on NetVSC otherwise without interruption thanks to
fail-safe's hot-plug handling.

Once initialized, the sole job of the hyperv driver is to regularly scan
for PCI devices to associate with NetVSC interfaces and feed their
addresses to corresponding fail-safe instances.

Signed-off-by: Adrien Mazarguil 
---
 doc/guides/nics/hyperv.rst  |  65 
 drivers/net/hyperv/Makefile |   4 +
 drivers/net/hyperv/hyperv.c | 654 ++-
 3 files changed, 722 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/hyperv.rst b/doc/guides/nics/hyperv.rst
index 28c4443d6..8f7a8b153 100644
--- a/doc/guides/nics/hyperv.rst
+++ b/doc/guides/nics/hyperv.rst
@@ -37,6 +37,50 @@ machines running on Microsoft Hyper-V_ (including Azure) 
platforms.
 
 .. _Hyper-V: 
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-hyper-v
 
+Implementation details
+--
+
+Each instance of this driver effectively needs to drive two devices: the
+NetVSC interface proper and its SR-IOV VF (referred to as "physical" from
+this point on) counterpart sharing the same MAC address.
+
+Physical devices are part of the host system and cannot be maintained during
+VM migration. From a VM standpoint they appear as hot-plug devices that come
+and go without prior notice.
+
+When the physical device is present, egress and most of the ingress traffic
+flows through it; only multicasts and other hypervisor control still flow
+through NetVSC. Otherwise, NetVSC acts as a fallback for all traffic.
+
+To avoid unnecessary code duplication and ensure maximum performance,
+handling of physical devices is left to their original PMDs; this virtual
+device driver (also known as *vdev*) manages other PMDs as summarized by the
+following block diagram::
+
+ .--.
+ | DPDK application |
+ `+-'
+  |
+   .--+--.
+   | DPDK ethdev |
+   `--+--'   Control
+  | |
+ .+.v..
+ |   failsafe PMD  +-+ hyperv PMD |
+ `--+---+--' `'
+|   |
+|  .|.
+|  :|:
+   .+. :   .+.   :
+   | tap PMD | :   | any PMD |   :
+   `+' :   `+'   : <-- Hot-pluggable
+|  :|:
+ .--+---.  :  .-+-.  :
+ | NetVSC-based |  :  | SR-IOV VF |  :
+ |   netdevice  |  :  |   device  |  :
+ `--'  :  `---'  :
+   :.:
+
 Build options
 -
 
@@ -47,3 +91,24 @@ Build options
 - ``CONFIG_RTE_LIBRTE_HYPERV_DEBUG`` (default ``n``)
 
Toggle additional debugging code.
+
+Run-time parameters
+---
+
+To invoke this PMD, applications have to explicitly provide the
+``--vdev=net_hyperv`` EAL option.
+
+The following device parameters are supported:
+
+- ``iface`` [string]
+
+  Provide a specific NetVSC interface (netdevice) name to attach this PMD
+  to. Can be provided multiple times for additional instances.
+
+- ``mac`` [string]
+
+  Same as ``iface`` except a suitable NetVSC interface is located using its
+  MAC address.
+
+Not specifying either ``iface`` or ``mac`` makes this PMD attach itself to
+all NetVSC interfaces found on the system.
diff --git a/drivers/net/hyperv/Makefile b/drivers/net/hyperv/Makefile
index 82c720353..0a7d2986c 100644
--- a/drivers/net/hyperv/Makefile
+++ b/drivers/net/hyperv/Makefile
@@ -40,6 +40,9 @@ EXPORT_MAP := rte_pmd_hyperv_version.map
 CFLAGS += -O3
 CFLAGS += -g
 CFLAGS += -std=c11 -pedantic -Wall -Wextra
+CFLAGS += -D_XOPEN_SOURCE=600
+CFLAGS += -D_BSD_SOURCE
+CFLAGS += -D_DEFAULT_SOURCE
 CFLAGS += $(WERROR_FLAGS)
 
 # Dependencies.
@@ -47,6 +50,7 @@ LDLIBS += -lrte_bus_vdev
 LDLIBS += -lrte_eal
 LDLIBS += -lrte_ethdev
 LDLIBS += -lrte_kvargs
+LDLIBS += -lrte_net
 
 # Source files.
 SRCS-$(CONFIG_RTE_LIBRTE_HYPERV_PMD) += hyperv.c
diff --git a/drivers/net/hyperv/hyperv.c b/drivers/net/hyperv/hyperv.c
index 2f940c76f..bad224be9 100644
--- a/drivers/net/hyperv/hyperv.c
+++ b/drivers/net/hyperv/hyperv.c
@@ -31,17 +31,40 @@
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF

[dpdk-dev] [PATCH v1 1/3] net/hyperv: introduce MS Hyper-V platform driver

[Adrien Mazarguil]

This patch lays the groundwork for this PMD (draft documentation, copyright
notices, code base skeleton and build system hooks). While it can be
successfully compiled and invoked, it's an empty shell at this stage.

Signed-off-by: Adrien Mazarguil 
---
 MAINTAINERS   |   6 +
 config/common_base|   6 +
 config/common_linuxapp|   1 +
 doc/guides/nics/features/hyperv.ini   |  12 ++
 doc/guides/nics/hyperv.rst|  49 
 doc/guides/nics/index.rst |   1 +
 drivers/net/Makefile  |   1 +
 drivers/net/hyperv/Makefile   |  54 +
 drivers/net/hyperv/hyperv.c   | 135 +
 drivers/net/hyperv/rte_pmd_hyperv_version.map |   4 +
 mk/rte.app.mk |   1 +
 11 files changed, 270 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5a63b40c2..fe686f4c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -451,6 +451,12 @@ F: drivers/net/mrvl/
 F: doc/guides/nics/mrvl.rst
 F: doc/guides/nics/features/mrvl.ini
 
+Microsoft hyperv
+M: Adrien Mazarguil 
+F: drivers/net/hyperv/
+F: doc/guides/nics/hyperv.rst
+F: doc/guides/nics/features/hyperv.ini
+
 Netcope szedata2
 M: Matej Vido 
 F: drivers/net/szedata2/
diff --git a/config/common_base b/config/common_base
index b8ee8f91c..8bc83c8c9 100644
--- a/config/common_base
+++ b/config/common_base
@@ -280,6 +280,12 @@ CONFIG_RTE_LIBRTE_NFP_DEBUG=n
 CONFIG_RTE_LIBRTE_MRVL_PMD=n
 
 #
+# Compile Microsoft Hyper-V/Azure driver
+#
+CONFIG_RTE_LIBRTE_HYPERV_PMD=n
+CONFIG_RTE_LIBRTE_HYPERV_DEBUG=n
+
+#
 # Compile burst-oriented Broadcom BNXT PMD driver
 #
 CONFIG_RTE_LIBRTE_BNXT_PMD=y
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 74c7d64ec..fac6cb172 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -47,6 +47,7 @@ CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_PMD_TAP=y
 CONFIG_RTE_LIBRTE_AVP_PMD=y
+CONFIG_RTE_LIBRTE_HYPERV_PMD=y
 CONFIG_RTE_LIBRTE_NFP_PMD=y
 CONFIG_RTE_LIBRTE_POWER=y
 CONFIG_RTE_VIRTIO_USER=y
diff --git a/doc/guides/nics/features/hyperv.ini 
b/doc/guides/nics/features/hyperv.ini
new file mode 100644
index 0..170912c25
--- /dev/null
+++ b/doc/guides/nics/features/hyperv.ini
@@ -0,0 +1,12 @@
+;
+; Supported features of the 'hyperv' network poll mode driver.
+;
+; Refer to default.ini for the full list of available PMD features.
+;
+[Features]
+ARMv7= Y
+ARMv8= Y
+Power8   = Y
+x86-32   = Y
+x86-64   = Y
+Usage doc= Y
diff --git a/doc/guides/nics/hyperv.rst b/doc/guides/nics/hyperv.rst
new file mode 100644
index 0..28c4443d6
--- /dev/null
+++ b/doc/guides/nics/hyperv.rst
@@ -0,0 +1,49 @@
+..  BSD LICENSE
+Copyright 2017 6WIND S.A.
+Copyright 2017 Mellanox
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of 6WIND S.A. nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+HYPERV poll mode driver
+===
+
+The HYPERV PMD (librte_pmd_hyperv) provides support for NetVSC interfaces
+and associated SR-IOV virtual function (VF) devices found in Linux virtual
+machines running on Microsoft Hyper-V_ (including Azure) platforms.
+
+.. _Hyper-V: 
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-hyper-v
+
+Build options
+-
+
+- ``CONFIG_RTE_LIBRTE_HYPERV_PMD`` (default ``y``)
+
+   Toggle compilation of this driver.
+
+- ``

[dpdk-dev] [PATCH v1 3/3] net/hyperv: add "force" parameter

[Adrien Mazarguil]

This parameter allows specifying any non-NetVSC interface to use with tap
sub-devices for development purposes.

Signed-off-by: Adrien Mazarguil 
---
 doc/guides/nics/hyperv.rst  |  5 +
 drivers/net/hyperv/hyperv.c | 26 +++---
 2 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/doc/guides/nics/hyperv.rst b/doc/guides/nics/hyperv.rst
index 8f7a8b153..9b5220919 100644
--- a/doc/guides/nics/hyperv.rst
+++ b/doc/guides/nics/hyperv.rst
@@ -110,5 +110,10 @@ The following device parameters are supported:
   Same as ``iface`` except a suitable NetVSC interface is located using its
   MAC address.
 
+- ``force`` [int]
+
+  If nonzero, forces the use of specified interfaces even if not detected as
+  NetVSC.
+
 Not specifying either ``iface`` or ``mac`` makes this PMD attach itself to
 all NetVSC interfaces found on the system.
diff --git a/drivers/net/hyperv/hyperv.c b/drivers/net/hyperv/hyperv.c
index bad224be9..d9d9bbcd5 100644
--- a/drivers/net/hyperv/hyperv.c
+++ b/drivers/net/hyperv/hyperv.c
@@ -62,6 +62,7 @@
 #define HYPERV_DRIVER net_hyperv
 #define HYPERV_ARG_IFACE "iface"
 #define HYPERV_ARG_MAC "mac"
+#define HYPERV_ARG_FORCE "force"
 #define HYPERV_PROBE_MS 1000
 
 #define NETVSC_CLASS_ID "{f8615163-df3e-46c5-913f-f2d2f965ed0e}"
@@ -504,6 +505,9 @@ hyperv_alarm(void *arg)
  *   - struct rte_kvargs *kvargs:
  * Device arguments provided to current driver instance.
  *
+ *   - int force:
+ * Accept specified interface even if not detected as NetVSC.
+ *
  *   - unsigned int specified:
  * Number of specific netdevices provided as device arguments.
  *
@@ -521,6 +525,7 @@ hyperv_netvsc_probe(const struct if_nameindex *iface,
 {
const char *name = va_arg(ap, const char *);
struct rte_kvargs *kvargs = va_arg(ap, struct rte_kvargs *);
+   int force = va_arg(ap, int);
unsigned int specified = va_arg(ap, unsigned int);
unsigned int *matched = va_arg(ap, unsigned int *);
unsigned int i;
@@ -567,9 +572,11 @@ hyperv_netvsc_probe(const struct if_nameindex *iface,
if (!hyperv_iface_is_netvsc(iface)) {
if (!specified)
return 0;
-   WARN("interface \"%s\" (index %u) is not NetVSC, skipping",
-iface->if_name, iface->if_index);
-   return 0;
+   WARN("interface \"%s\" (index %u) is not NetVSC, %s",
+iface->if_name, iface->if_index,
+force ? "using anyway (forced)" : "skipping");
+   if (!force)
+   return 0;
}
/* Create interface context. */
ctx = calloc(1, sizeof(*ctx));
@@ -700,6 +707,7 @@ hyperv_vdev_probe(struct rte_vdev_device *dev)
static const char *const hyperv_arg[] = {
HYPERV_ARG_IFACE,
HYPERV_ARG_MAC,
+   HYPERV_ARG_FORCE,
NULL,
};
const char *name = rte_vdev_device_name(dev);
@@ -708,6 +716,7 @@ hyperv_vdev_probe(struct rte_vdev_device *dev)
 hyperv_arg);
unsigned int specified = 0;
unsigned int matched = 0;
+   int force = 0;
unsigned int i;
int ret;
 
@@ -719,13 +728,15 @@ hyperv_vdev_probe(struct rte_vdev_device *dev)
for (i = 0; i != kvargs->count; ++i) {
const struct rte_kvargs_pair *pair = &kvargs->pairs[i];
 
-   if (!strcmp(pair->key, HYPERV_ARG_IFACE) ||
-   !strcmp(pair->key, HYPERV_ARG_MAC))
+   if (!strcmp(pair->key, HYPERV_ARG_FORCE))
+   force = !!atoi(pair->value);
+   else if (!strcmp(pair->key, HYPERV_ARG_IFACE) ||
+!strcmp(pair->key, HYPERV_ARG_MAC))
++specified;
}
rte_eal_alarm_cancel(hyperv_alarm, NULL);
/* Gather interfaces. */
-   ret = hyperv_foreach_iface(hyperv_netvsc_probe, name, kvargs,
+   ret = hyperv_foreach_iface(hyperv_netvsc_probe, name, kvargs, force,
   specified, &matched);
if (ret < 0)
goto error;
@@ -784,4 +795,5 @@ RTE_PMD_REGISTER_VDEV(HYPERV_DRIVER, hyperv_vdev);
 RTE_PMD_REGISTER_ALIAS(HYPERV_DRIVER, eth_hyperv);
 RTE_PMD_REGISTER_PARAM_STRING(net_hyperv,
  HYPERV_ARG_IFACE "= "
- HYPERV_ARG_MAC "=");
+ HYPERV_ARG_MAC "= "
+ HYPERV_ARG_FORCE "=");
-- 
2.11.0

Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Wiles, Keith]

> On Dec 18, 2017, at 10:46 AM, Adrien Mazarguil  
> wrote:
> 
> As described in more details in the attached documentation (see patch
> contents), this virtual device driver manages NetVSC interfaces in virtual
> machines hosted by Hyper-V/Azure platforms.
> 
> This driver does not manage traffic nor Ethernet devices directly; it acts
> as a thin configuration layer that automatically instantiates and controls
> fail-safe PMD instances combining tap and PCI sub-devices, so that each
> NetVSC interface is exposed as a single consolidated port to DPDK
> applications.
> 
> PCI sub-devices being hot-pluggable (e.g. during VM migration),
> applications automatically benefit from increased throughput when present
> and automatic fallback on NetVSC otherwise without interruption thanks to
> fail-safe's hot-plug handling.
> 
> Once initialized, the sole job of the hyperv driver is to regularly scan
> for PCI devices to associate with NetVSC interfaces and feed their
> addresses to corresponding fail-safe instances.
> 
> Signed-off-by: Adrien Mazarguil 
> ---
> doc/guides/nics/hyperv.rst  |  65 
> drivers/net/hyperv/Makefile |   4 +
> drivers/net/hyperv/hyperv.c | 654 ++-
> 3 files changed, 722 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/nics/hyperv.rst b/doc/guides/nics/hyperv.rst
> index 28c4443d6..8f7a8b153 100644
> --- a/doc/guides/nics/hyperv.rst
> +++ b/doc/guides/nics/hyperv.rst
> @@ -37,6 +37,50 @@ machines running on Microsoft Hyper-V_ (including Azure) 
> platforms.
> 
> .. _Hyper-V: 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-hyper-v
> 
> +Implementation details
> +--
> +
> +Each instance of this driver effectively needs to drive two devices: the
> +NetVSC interface proper and its SR-IOV VF (referred to as "physical" from
> +this point on) counterpart sharing the same MAC address.
> +
> +Physical devices are part of the host system and cannot be maintained during
> +VM migration. From a VM standpoint they appear as hot-plug devices that come
> +and go without prior notice.
> +
> +When the physical device is present, egress and most of the ingress traffic
> +flows through it; only multicasts and other hypervisor control still flow
> +through NetVSC. Otherwise, NetVSC acts as a fallback for all traffic.
> +
> +To avoid unnecessary code duplication and ensure maximum performance,
> +handling of physical devices is left to their original PMDs; this virtual
> +device driver (also known as *vdev*) manages other PMDs as summarized by the
> +following block diagram::
> +
> + .--.
> + | DPDK application |
> + `+-'
> +  |
> +   .--+--.
> +   | DPDK ethdev |
> +   `--+--'   Control
> +  | |
> + .+.v..
> + |   failsafe PMD  +-+ hyperv PMD |
> + `--+---+--' `'
> +|   |
> +|  .|.
> +|  :|:
> +   .+. :   .+.   :
> +   | tap PMD | :   | any PMD |   :
> +   `+' :   `+'   : <-- Hot-pluggable
> +|  :|:
> + .--+---.  :  .-+-.  :
> + | NetVSC-based |  :  | SR-IOV VF |  :
> + |   netdevice  |  :  |   device  |  :
> + `--'  :  `---'  :
> +   :.:
> +
> Build options
> -
> 
> @@ -47,3 +91,24 @@ Build options
> - ``CONFIG_RTE_LIBRTE_HYPERV_DEBUG`` (default ``n``)
> 
>Toggle additional debugging code.
> +
> +Run-time parameters
> +---
> +
> +To invoke this PMD, applications have to explicitly provide the
> +``--vdev=net_hyperv`` EAL option.
> +
> +The following device parameters are supported:
> +
> +- ``iface`` [string]
> +
> +  Provide a specific NetVSC interface (netdevice) name to attach this PMD
> +  to. Can be provided multiple times for additional instances.
> +
> +- ``mac`` [string]
> +
> +  Same as ``iface`` except a suitable NetVSC interface is located using its
> +  MAC address.
> +
> +Not specifying either ``iface`` or ``mac`` makes this PMD attach itself to
> +all NetVSC interfaces found on the system.
> diff --git a/drivers/net/hyperv/Makefile b/drivers/net/hyperv/Makefile
> index 82c720353..0a7d2986c 100644
> --- a/drivers/net/hyperv/Makefile
> +++ b/drivers/net/hyperv/Makefile
> @@ -40,6 +40,9 @@ EXPORT_MAP := rte_pmd_hyperv_version.map
> CFLAGS += -O3
> CFLAGS += -g
> CFLAGS += -std=c11 -pedantic -Wall -Wextra
> +CFLAGS += -D_XOPEN_SOURCE=600
> +CFLAGS += -D_BSD_SOURCE
> +CFLAGS += -D_DEFAULT_SOURCE
> CFLAGS += $(WERROR_FLAGS)
> 
> # Dependencies.
> @@ -47,6 +50,7 @@ LDLIBS += -lrte_bus_vdev
> LDLIBS += -lrte_eal
> LDLIBS += -lrte_ethdev
> LDLIBS += -lrte_kvargs
> +LDLIBS += -lrte_net
> 
> # 

Re: [dpdk-dev] [PATCH] build: replace license text with SPDX ids in meson files

[Bruce Richardson]

On Mon, Dec 18, 2017 at 04:27:48PM +, Luca Boccassi wrote:
> On Mon, 2017-12-18 at 16:00 +, Bruce Richardson wrote:
> > Signed-off-by: Bruce Richardson 
> > ---
> >  app/meson.build| 32 ++
> > 

> 
> Reviewed-by: Luca Boccassi 
> 
> LGTM
>
Thanks, though replying without trimming to a patch that big makes
patchwork (and some readers) cry!!

Re: [dpdk-dev] [PATCH] build: replace license text with SPDX ids in meson files

[Bruce Richardson]

On Mon, Dec 18, 2017 at 04:27:48PM +, Luca Boccassi wrote:
> On Mon, 2017-12-18 at 16:00 +, Bruce Richardson wrote:
> > Signed-off-by: Bruce Richardson 
> > ---
> 
> Reviewed-by: Luca Boccassi 
> 
Applied to dpdk-next-build.

Re: [dpdk-dev] [PATCH] build: replace license text with SPDX ids in meson files

[Luca Boccassi]

On Mon, 2017-12-18 at 17:41 +, Bruce Richardson wrote:
> On Mon, Dec 18, 2017 at 04:27:48PM +, Luca Boccassi wrote:
> > On Mon, 2017-12-18 at 16:00 +, Bruce Richardson wrote:
> > > Signed-off-by: Bruce Richardson 
> > > ---
> > >  app/meson.build| 32 ++
> > > 
> > > 
> 
> 
> > 
> > Reviewed-by: Luca Boccassi 
> > 
> > LGTM
> > 
> 
> Thanks, though replying without trimming to a patch that big makes
> patchwork (and some readers) cry!!

Ahah sorry, was too lazy to cut :-P

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Adrien Mazarguil]

On Mon, Dec 18, 2017 at 05:04:23PM +, Wiles, Keith wrote:
> > On Dec 18, 2017, at 10:46 AM, Adrien Mazarguil  
> > wrote:
> > 
> > As described in more details in the attached documentation (see patch
> > contents), this virtual device driver manages NetVSC interfaces in virtual
> > machines hosted by Hyper-V/Azure platforms.
> > 
> > This driver does not manage traffic nor Ethernet devices directly; it acts
> > as a thin configuration layer that automatically instantiates and controls
> > fail-safe PMD instances combining tap and PCI sub-devices, so that each
> > NetVSC interface is exposed as a single consolidated port to DPDK
> > applications.
> > 
> > PCI sub-devices being hot-pluggable (e.g. during VM migration),
> > applications automatically benefit from increased throughput when present
> > and automatic fallback on NetVSC otherwise without interruption thanks to
> > fail-safe's hot-plug handling.
> > 
> > Once initialized, the sole job of the hyperv driver is to regularly scan
> > for PCI devices to associate with NetVSC interfaces and feed their
> > addresses to corresponding fail-safe instances.
> > 
> > Signed-off-by: Adrien Mazarguil 
> > ---
> > doc/guides/nics/hyperv.rst  |  65 
> > drivers/net/hyperv/Makefile |   4 +
> > drivers/net/hyperv/hyperv.c | 654 ++-
> > 3 files changed, 722 insertions(+), 1 deletion(-)

> > diff --git a/drivers/net/hyperv/hyperv.c b/drivers/net/hyperv/hyperv.c
> > index 2f940c76f..bad224be9 100644
> > --- a/drivers/net/hyperv/hyperv.c
> > +++ b/drivers/net/hyperv/hyperv.c

> > +/**
> > + * Convert a MAC address string to binary form.
> > + *
> > + * Note: this function should be exposed by rte_ether.h as the reverse of
> > + * ether_format_addr().
> > + *
> > + * Several MAC string formats are supported on input for convenience:
> > + *
> > + * 1. "12:34:56:78:9a:bc"
> > + * 2. "12-34-56-78-9a-bc"
> > + * 3. "123456789abc"
> > + * 4. Upper/lowercase hexadecimal.
> > + * 5. Any combination of the above, e.g. "12:34-5678-9aBC".
> > + * 6. Partial addresses are allowed, with low-order bytes filled first:
> > + *- "5:6:78c" translates to "00:00:05:06:07:8c",
> > + *- "5678c" translates to "00:00:00:05:67:8c".
> > + *
> > + * Non-hexadecimal characters, unknown separators and strings specifying
> > + * more than 6 bytes are not allowed.
> > + *
> > + * @param[out] eth_addr
> > + *   Pointer to conversion result buffer.
> > + * @param[in] str
> > + *   MAC address string to convert.
> > + *
> > + * @return
> > + *   0 on success, -EINVAL in case of unsupported format.
> > + */
> > +static int
> > +ether_addr_from_str(struct ether_addr *eth_addr, const char *str)
> > +{
> > +   static const uint8_t conv[0x100] = {
> > +   ['0'] = 0x80, ['1'] = 0x81, ['2'] = 0x82, ['3'] = 0x83,
> > +   ['4'] = 0x84, ['5'] = 0x85, ['6'] = 0x86, ['7'] = 0x87,
> > +   ['8'] = 0x88, ['9'] = 0x89, ['a'] = 0x8a, ['b'] = 0x8b,
> > +   ['c'] = 0x8c, ['d'] = 0x8d, ['e'] = 0x8e, ['f'] = 0x8f,
> > +   ['A'] = 0x8a, ['B'] = 0x8b, ['C'] = 0x8c, ['D'] = 0x8d,
> > +   ['E'] = 0x8e, ['F'] = 0x8f, [':'] = 0x40, ['-'] = 0x40,
> > +   ['\0'] = 0x60,
> > +   };
> > +   uint64_t addr = 0;
> > +   uint64_t buf = 0;
> > +   unsigned int i = 0;
> > +   unsigned int n = 0;
> > +   uint8_t tmp;
> > +
> > +   do {
> > +   tmp = conv[(int)*(str++)];
> > +   if (!tmp)
> > +   return -EINVAL;
> > +   if (tmp & 0x40) {
> > +   i += (i & 1) + (!i << 1);
> > +   addr = (addr << (i << 2)) | buf;
> > +   n += i;
> > +   buf = 0;
> > +   i = 0;
> > +   } else {
> > +   buf = (buf << 4) | (tmp & 0xf);
> > +   ++i;
> > +   }
> > +   } while (!(tmp & 0x20));
> > +   if (n > 12)
> > +   return -EINVAL;
> > +   i = RTE_DIM(eth_addr->addr_bytes);
> > +   while (i) {
> > +   eth_addr->addr_bytes[--i] = addr & 0xff;
> > +   addr >>= 8;
> > +   }
> > +   return 0;
> > +}
> 
> You already called this out above, why not just push this into rte_ether.h 
> file. I know I could use it if it were public.

Hehe, that was to highlight how this driver didn't require any modifications
in public APIs. I planned to do just that in v2 or in a subsequent patch.


> > +/**
> > + * Retrieve the last component of a path.
> > + *
> > + * This is a simplified basename() that does not modify its input buffer to
> > + * handle trailing backslashes.
> > + *
> > + * @param[in] path
> > + *Path to retrieve the last component from.
> > + *
> > + * @return
> > + *Pointer to the last component.
> > + */
> > +static const char *
> > +hyperv_basename(const char *path)
> > +{
> > +   const char *tmp = path;
> > +
> > +   while (*tmp)
> > +   if (*(tmp++) == '/')
> > +   path = tmp;
> > +   return path;
> > +}
> 
> Why not just user rinde

Re: [dpdk-dev] [PATCH 0/6] next-build: create both static and shared libs

[Aaron Conole]

Luca Boccassi  writes:

> On Tue, 2017-12-12 at 17:14 +, Bruce Richardson wrote:
>> On Tue, Dec 12, 2017 at 04:59:34PM +, Bruce Richardson wrote:
>> > This patchset changes the meson+ninja build system to always create
>> > both
>> > static and shared libraries when doing a build. The applications
>> > compiled
>> > as part of a build use either the shared or static libraries
>> > depending on
>> > what the default_library build setting is.
>> > 
>> > NOTE:
>> > The main difficulty with this change is adjusting the pkgconfig
>> > file so
>> > that external apps, like the examples, can be built using either
>> > the static
>> > or shared libraries. One of the key issues was the fact that
>> > running
>> > "pkg-config --static --libs libdpdk" outputs first the normal libs,
>> > and
>> > then the extra static ones. This is a problem because the driver
>> > libs are
>> > for static only builds, but need to come before, not after the
>> > standard
>> > DDPK libraries.  It also procludes adding in the -Wl,-Bstatic flag
>> > into the output for the standard libraries to link them statically.
>> > 
>> > There were two options considered for mananging the pkg-config
>> > settings.
>> > 1. Creating a separate .pc file for static builds with exactly the
>> > flags
>> > needed.
>> > 2. Modifying the single .pc file so that it was "good enough" to
>> > enable
>> > static builds without too much work.
>> > 
>> > For this version of this set, I took option #2. To link using
>> > dynamic libs,
>> > all is as normal, to use static libs, the user needs to prepend
>> > "-Wl,-Bstatic" before the "pkgconfig --static" library output. This
>> > can be
>> > seen in the changes to the example application makefiles, which now
>> > support
>> > building the examples using shared or static DPDK libs.
>> > 
>> 
>> Just to emphasise that I'm looking for input into whether I took the
>> right choice here. Option #1 has some advantages in that we can tune
>> the
>> output specifically for the static build case, but I wasn't sure
>> whether
>> it would be the done thing to have two different .pc files for a
>> single
>> package. Feedback from packagers welcome!
>> 
>> /Bruce
>
> I don't link #1 too much - too "special". I think an additional flag is
> more friendly.

I agree with this.

> A good solution would be a Cflags.private feature, sadly that is not
> supported by pkgconfig despite many requests for it.
>
> A possible way to sugar-coat it could be to add a custom variable, and
> then instruct the users to do something like:
>
> $(shell pkg-config --variable=ldflags.static libdpdk) $(shell pkg-
> config --static --libs libdpdk)

I don't think this is needed.  Most linkers (and libtool based linkers
as well) have no 'distinction' between static / dynamic - just the
static option gets passed.

In this case, I think it's fine to require the application build system
to expose such a distinct option to the user doing the builds.  There's
generally no good reasons to want static builds (well... okay that's a
bit strong, but hopefully I don't get my head chewed off) anyway, so
making them slightly more work is okay by me.

> Unfortunately, again, --variable cannot be used together with --libs in
> the same call.

Re: [dpdk-dev] [PATCH v1 0/3] Introduce virtual PMD for Hyper-V/Azure platforms

[Stephen Hemminger]

On Mon, 18 Dec 2017 17:46:19 +0100
Adrien Mazarguil  wrote:

> Virtual machines hosted by Hyper-V/Azure platforms are fitted with
> simplified virtual network devices named NetVSC that are used for fast
> communication between VM to VM, VM to hypervisor, and the outside.
> 
> They appear as standard system netdevices to user-land applications, the
> main difference being they are implemented on top of VMBUS [1] instead of
> emulated PCI devices.
> 
> While this reads like a case for a standard DPDK PMD, there is more to it.
> 
> To accelerate outside communication, NetVSC devices as they appear in a VM
> can be paired with physical SR-IOV virtual function (VF) devices owned by
> that same VM [2]. Both netdevices share the same MAC address in that case.
> 
> When paired, egress and most of the ingress traffic flow through the VF
> device, while part of it (e.g. multicasts, hypervisor control data) still
> flows through NetVSC. Moreover VF devices are not retained and disappear
> during VM migration; from a VM standpoint, they can be hot-plugged anytime
> with NetVSC acting as a fallback.
> 
> Running DPDK applications in such a context involves driving VF devices
> using their dedicated PMDs in a vendor-independent fashion (to benefit from
> maximum performance without writing dedicated code) while simultaneously
> listening to NetVSC and handling the related hot-plug events.
> 
> This new virtual PMD (referred to as "hyperv" from this point on)
> automatically coordinates the Hyper-V/Azure-specific management part
> described above by relying on vendor-specific, failsafe and tap PMDs to
> expose a single consolidated Ethernet device usable directly by existing
> applications.
> 
>  .--.
>  | DPDK application |
>  `+-'
>   |
>.--+--.
>| DPDK ethdev |
>`--+--'   Control
>   | |
>  .+.v..
>  |   failsafe PMD  +-+ hyperv PMD |
>  `--+---+--' `'
> |   |
> |  .|.
> |  :|:
>.+. :   .+.   :
>| tap PMD | :   | any PMD |   :
>`+' :   `+'   : <-- Hot-pluggable
> |  :|:
>  .--+---.  :  .-+-.  :
>  | NetVSC-based |  :  | SR-IOV VF |  :
>  |   netdevice  |  :  |   device  |  :
>  `--'  :  `---'  :
>:.:
> 
> Note this diagram differs from that of the original RFC [3], with hyperv no
> longer acting as a data plane layer.
> 
> This initial version of the driver only works in whitelist mode. Users have
> to provide the --vdev net_hyperv EAL option at least once to trigger it.
> 
> Subsequent work will add support for blacklist mode based on automatic
> detection of the host environment.
> 
> [1] http://dpdk.org/ml/archives/dev/2017-January/054165.html
> [2] 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-hyper-v
> [3] http://dpdk.org/ml/archives/dev/2017-November/082339.html
> 
> Adrien Mazarguil (3):
>   net/hyperv: introduce MS Hyper-V platform driver
>   net/hyperv: implement core functionality
>   net/hyperv: add "force" parameter
> 
>  MAINTAINERS   |   6 +
>  config/common_base|   6 +
>  config/common_linuxapp|   1 +
>  doc/guides/nics/features/hyperv.ini   |  12 +
>  doc/guides/nics/hyperv.rst| 119 +++
>  doc/guides/nics/index.rst |   1 +
>  drivers/net/Makefile  |   1 +
>  drivers/net/hyperv/Makefile   |  58 ++
>  drivers/net/hyperv/hyperv.c   | 799 +
>  drivers/net/hyperv/rte_pmd_hyperv_version.map |   4 +
>  mk/rte.app.mk |   1 +
>  11 files changed, 1008 insertions(+)
>  create mode 100644 doc/guides/nics/features/hyperv.ini
>  create mode 100644 doc/guides/nics/hyperv.rst
>  create mode 100644 drivers/net/hyperv/Makefile
>  create mode 100644 drivers/net/hyperv/hyperv.c
>  create mode 100644 drivers/net/hyperv/rte_pmd_hyperv_version.map
> 

Please don't call this drivers/net/hyperv/
that name conflicts with the real netvsc PMD that I am working on.

Maybe vdev-netvsc?

Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Stephen Hemminger]

On Mon, 18 Dec 2017 17:46:23 +0100
Adrien Mazarguil  wrote:

> +static int
> +ether_addr_from_str(struct ether_addr *eth_addr, const char *str)
> +{
> + static const uint8_t conv[0x100] = {
> + ['0'] = 0x80, ['1'] = 0x81, ['2'] = 0x82, ['3'] = 0x83,
> + ['4'] = 0x84, ['5'] = 0x85, ['6'] = 0x86, ['7'] = 0x87,
> + ['8'] = 0x88, ['9'] = 0x89, ['a'] = 0x8a, ['b'] = 0x8b,
> + ['c'] = 0x8c, ['d'] = 0x8d, ['e'] = 0x8e, ['f'] = 0x8f,
> + ['A'] = 0x8a, ['B'] = 0x8b, ['C'] = 0x8c, ['D'] = 0x8d,
> + ['E'] = 0x8e, ['F'] = 0x8f, [':'] = 0x40, ['-'] = 0x40,
> + ['\0'] = 0x60,
> + };
> + uint64_t addr = 0;
> + uint64_t buf = 0;
> + unsigned int i = 0;
> + unsigned int n = 0;
> + uint8_t tmp;
> +
> + do {
> + tmp = conv[(int)*(str++)];
> + if (!tmp)
> + return -EINVAL;
> + if (tmp & 0x40) {
> + i += (i & 1) + (!i << 1);
> + addr = (addr << (i << 2)) | buf;
> + n += i;
> + buf = 0;
> + i = 0;
> + } else {
> + buf = (buf << 4) | (tmp & 0xf);
> + ++i;
> + }
> + } while (!(tmp & 0x20));
> + if (n > 12)
> + return -EINVAL;
> + i = RTE_DIM(eth_addr->addr_bytes);
> + while (i) {
> + eth_addr->addr_bytes[--i] = addr & 0xff;
> + addr >>= 8;
> + }
> + return 0;
> +}
> +


Why not ether_ntoa?

Re: [dpdk-dev] [PATCH v1 1/3] net/hyperv: introduce MS Hyper-V platform driver

[Stephen Hemminger]

On Mon, 18 Dec 2017 17:46:21 +0100
Adrien Mazarguil  wrote:

> +#ifdef RTE_LIBRTE_HYPERV_DEBUG
> +
> +#define PMD_DRV_LOG(level, ...) \
> + RTE_LOG(level, PMD, \
> + RTE_FMT("%s:%u: %s(): " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
> + strrchr("/" __FILE__, '/') + 1, \
> + __LINE__, \
> + __func__, \
> + RTE_FMT_TAIL(__VA_ARGS__,)))
> +
> +#else /* RTE_LIBRTE_HYPERV_DEBUG */
> +
> +#define PMD_DRV_LOG(level, ...) \
> + RTE_LOG(level, PMD, \
> + RTE_FMT(RTE_STR(HYPERV_DRIVER) ": " \
> + RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
> + RTE_FMT_TAIL(__VA_ARGS__,)))
> +
> +#endif /* RTE_LIBRTE_HYPERV_DEBUG */
> +
> +#define DEBUG(...) PMD_DRV_LOG(DEBUG, __VA_ARGS__)
> +#define INFO(...) PMD_DRV_LOG(INFO, __VA_ARGS__)
> +#define WARN(...) PMD_DRV_LOG(WARNING, __VA_ARGS__)
> +#define ERROR(...) PMD_DRV_LOG(ERR, __VA_ARGS__)
> +

Please don't use DEBUG() etc macros. It makes it easier for tools that do
global updates or scans if all drivers use the same model of PMD_DRV_LOG

Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Stephen Hemminger]

On Mon, 18 Dec 2017 17:46:23 +0100
Adrien Mazarguil  wrote:

>  
>  /**
> + * Destroy a hyperv context instance.
> + *
> + * @param ctx
> + *   Context to destroy.
> + */
> +static void
> +hyperv_ctx_destroy(struct hyperv_ctx *ctx)
> +{
> + if (ctx->pipe[0] != -1)
> + close(ctx->pipe[0]);
> + if (ctx->pipe[1] != -1)
> + close(ctx->pipe[1]);
> + /* Poisoning for debugging purposes. */
> + memset(ctx, 0x22, sizeof(*ctx));

Don't leave debug code in submitted drivers

> + free(ctx);
> +}
> +
> +/**
> + * Iterate over system network interfaces.
> + *
> + * This function runs a given callback function for each netdevice found on
> + * the system.
> + *
> + * @param func
> + *   Callback function pointer. List traversal is aborted when this function
> + *   returns a nonzero value.
> + * @param ...
> + *   Variable parameter list passed as @p va_list to @p func.
> + *
> + * @return
> + *   0 when the entire list is traversed successfully, a negative error code
> + *   in case or failure, or the nonzero value returned by @p func when list
> + *   traversal is aborted.
> + */
> +static int
> +hyperv_foreach_iface(int (*func)(const struct if_nameindex *iface,
> +  const struct ether_addr *eth_addr,
> +  va_list ap), ...)
> +{
> + struct if_nameindex *iface = if_nameindex();
> + int s = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
> + unsigned int i;
> + int ret = 0;
> +
> + if (!iface) {
> + ret = -ENOBUFS;
> + ERROR("cannot retrieve system network interfaces");
> + goto error;
> + }
> + if (s == -1) {
> + ret = -errno;
> + ERROR("cannot open socket: %s", rte_strerror(errno));
> + goto error;
> + }
> + for (i = 0; iface[i].if_name; ++i) {
> + struct ifreq req;
> + struct ether_addr eth_addr;
> + va_list ap;
> +
> + strncpy(req.ifr_name, iface[i].if_name, sizeof(req.ifr_name));
> + if (ioctl(s, SIOCGIFHWADDR, &req) == -1) {
> + WARN("cannot retrieve information about interface"
> +  " \"%s\": %s",
> +  req.ifr_name, rte_strerror(errno));
> + continue;
> + }
> + memcpy(eth_addr.addr_bytes, req.ifr_hwaddr.sa_data,
> +RTE_DIM(eth_addr.addr_bytes));
> + va_start(ap, func);
> + ret = func(&iface[i], ð_addr, ap);
> + va_end(ap);
> + if (ret)
> + break;
> + }
> +error:
> + if (s != -1)
> + close(s);
> + if (iface)
> + if_freenameindex(iface);
> + return ret;
> +}
> +
> +/**
> + * Determine if a network interface is NetVSC.
> + *
> + * @param[in] iface
> + *   Pointer to netdevice description structure (name and index).
> + *
> + * @return
> + *   A nonzero value when interface is detected as NetVSC. In case of error,
> + *   rte_errno is updated and 0 returned.
> + */
> +static int
> +hyperv_iface_is_netvsc(const struct if_nameindex *iface)
> +{
> + static const char temp[] = "/sys/class/net/%s/device/class_id";
> + char path[snprintf(NULL, 0, temp, iface->if_name) + 1];

Doing this snprintf is gross. Either use PATH_MAX or asprintf

> + FILE *f;
> + int ret;
> + int len = 0;
> +
> + snprintf(path, sizeof(path), temp, iface->if_name);
> + f = fopen(path, "r");
> + if (!f) {
> + rte_errno = errno;
> + return 0;
> + }
> + ret = fscanf(f, NETVSC_CLASS_ID "%n", &len);
> + if (ret == EOF)
> + rte_errno = errno;
> + ret = len == (int)strlen(NETVSC_CLASS_ID);
> + fclose(f);
> + return ret;
> +}
> +
> +/**
> + * Retrieve the last component of a path.
> + *
> + * This is a simplified basename() that does not modify its input buffer to
> + * handle trailing backslashes.
> + *
> + * @param[in] path
> + *Path to retrieve the last component from.
> + *
> + * @return
> + *Pointer to the last component.
> + */
> +static const char *
> +hyperv_basename(const char *path)
> +{
> + const char *tmp = path;
> +
> + while (*tmp)
> + if (*(tmp++) == '/')

Too may ()

> + path = tmp;
> + return path;
> +}
> +
> +/**
> + * Retrieve network interface data from sysfs symbolic link.
> + *
> + * @param[out] buf
> + *   Output data buffer.
> + * @param size
> + *   Output buffer size.
> + * @param[in] if_name
> + *   Netdevice name.
> + * @param[in] relpath
> + *   Symbolic link path relative to netdevice sysfs entry.
> + *
> + * @return
> + *   0 on success, a negative error code otherwise.
> + */
> +static int
> +hyperv_sysfs_readlink(char *buf, size_t size, const char *if_name,
> +   const char *relpath)
> +{
> + int ret;
> +
> + ret = snprintf(buf, size, "/sys/class/net/%s/%s", if_name, re

Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Wiles, Keith]

> On Dec 18, 2017, at 11:59 AM, Adrien Mazarguil  
> wrote:

>> Not to criticize style, but a few blank lines could help in readability for 
>> these files IMHO. Unless blank lines are illegal :-)
> 
> It's a matter of taste, I think people tend to add random blank lines where
> they think doing so clarifies things for themselves, resulting in
> inconsistent coding style not much clearer for everyone after several
> iterations.
> 
> As a maintainer I've grown tired of discussions related to blank lines while
> reviewing patches. That's why except for a few special cases, I now enforce
> exactly the bare minimum of one blank line between variable declarations and
> the rest of the code inside each block.
> 
> If doing so makes a function unreadable then perhaps it needs to be split :)
> I'm sure you'll understand!

I do not really understand the problem as I have not seen any complaints about 
blank lines unless two or more in a row. I have never seen someone complain 
about a given blank line in a function, unless a missing one to split up the 
declared variables and code in a function or block of code.

It is a shame you have decided to take the minimum approach to blank lines, IMO 
it does not make a lot of sense. I only bring it up to help others with reading 
your code like our customers.

We do not have rule for this so I can not force anyone to add blank lines for 
readability, so I have to live with it. :-(

> 
> Regards,
> 
> -- 
> Adrien Mazarguil
> 6WIND

Regards,
Keith

Re: [dpdk-dev] [PATCH v1 0/3] Introduce virtual PMD for Hyper-V/Azure platforms

[Thomas Monjalon]

18/12/2017 19:23, Stephen Hemminger:
> Please don't call this drivers/net/hyperv/
> that name conflicts with the real netvsc PMD that I am working on.
> 
> Maybe vdev-netvsc?

I expect your PMD to be in drivers/net/netvsc/
Why is it conflicting with drivers/net/hyperv/ ?

Re: [dpdk-dev] [PATCH v1 0/3] Introduce virtual PMD for Hyper-V/Azure platforms

[Adrien Mazarguil]

On Mon, Dec 18, 2017 at 10:23:04AM -0800, Stephen Hemminger wrote:
> On Mon, 18 Dec 2017 17:46:19 +0100
> Adrien Mazarguil  wrote:
> 
> > Virtual machines hosted by Hyper-V/Azure platforms are fitted with
> > simplified virtual network devices named NetVSC that are used for fast
> > communication between VM to VM, VM to hypervisor, and the outside.
> > 
> > They appear as standard system netdevices to user-land applications, the
> > main difference being they are implemented on top of VMBUS [1] instead of
> > emulated PCI devices.
> > 
> > While this reads like a case for a standard DPDK PMD, there is more to it.
> > 
> > To accelerate outside communication, NetVSC devices as they appear in a VM
> > can be paired with physical SR-IOV virtual function (VF) devices owned by
> > that same VM [2]. Both netdevices share the same MAC address in that case.
> > 
> > When paired, egress and most of the ingress traffic flow through the VF
> > device, while part of it (e.g. multicasts, hypervisor control data) still
> > flows through NetVSC. Moreover VF devices are not retained and disappear
> > during VM migration; from a VM standpoint, they can be hot-plugged anytime
> > with NetVSC acting as a fallback.
> > 
> > Running DPDK applications in such a context involves driving VF devices
> > using their dedicated PMDs in a vendor-independent fashion (to benefit from
> > maximum performance without writing dedicated code) while simultaneously
> > listening to NetVSC and handling the related hot-plug events.
> > 
> > This new virtual PMD (referred to as "hyperv" from this point on)
> > automatically coordinates the Hyper-V/Azure-specific management part
> > described above by relying on vendor-specific, failsafe and tap PMDs to
> > expose a single consolidated Ethernet device usable directly by existing
> > applications.
> > 
> >  .--.
> >  | DPDK application |
> >  `+-'
> >   |
> >.--+--.
> >| DPDK ethdev |
> >`--+--'   Control
> >   | |
> >  .+.v..
> >  |   failsafe PMD  +-+ hyperv PMD |
> >  `--+---+--' `'
> > |   |
> > |  .|.
> > |  :|:
> >.+. :   .+.   :
> >| tap PMD | :   | any PMD |   :
> >`+' :   `+'   : <-- Hot-pluggable
> > |  :|:
> >  .--+---.  :  .-+-.  :
> >  | NetVSC-based |  :  | SR-IOV VF |  :
> >  |   netdevice  |  :  |   device  |  :
> >  `--'  :  `---'  :
> >:.:
> > 
> > Note this diagram differs from that of the original RFC [3], with hyperv no
> > longer acting as a data plane layer.
> > 
> > This initial version of the driver only works in whitelist mode. Users have
> > to provide the --vdev net_hyperv EAL option at least once to trigger it.
> > 
> > Subsequent work will add support for blacklist mode based on automatic
> > detection of the host environment.
> > 
> > [1] http://dpdk.org/ml/archives/dev/2017-January/054165.html
> > [2] 
> > https://docs.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-hyper-v
> > [3] http://dpdk.org/ml/archives/dev/2017-November/082339.html
> > 
> > Adrien Mazarguil (3):
> >   net/hyperv: introduce MS Hyper-V platform driver
> >   net/hyperv: implement core functionality
> >   net/hyperv: add "force" parameter
> > 
> >  MAINTAINERS   |   6 +
> >  config/common_base|   6 +
> >  config/common_linuxapp|   1 +
> >  doc/guides/nics/features/hyperv.ini   |  12 +
> >  doc/guides/nics/hyperv.rst| 119 +++
> >  doc/guides/nics/index.rst |   1 +
> >  drivers/net/Makefile  |   1 +
> >  drivers/net/hyperv/Makefile   |  58 ++
> >  drivers/net/hyperv/hyperv.c   | 799 +
> >  drivers/net/hyperv/rte_pmd_hyperv_version.map |   4 +
> >  mk/rte.app.mk |   1 +
> >  11 files changed, 1008 insertions(+)
> >  create mode 100644 doc/guides/nics/features/hyperv.ini
> >  create mode 100644 doc/guides/nics/hyperv.rst
> >  create mode 100644 drivers/net/hyperv/Makefile
> >  create mode 100644 drivers/net/hyperv/hyperv.c
> >  create mode 100644 drivers/net/hyperv/rte_pmd_hyperv_version.map
> > 
> 
> Please don't call this drivers/net/hyperv/
> that name conflicts with the real netvsc PMD that I am working on.
> 
> Maybe vdev-netvsc?

No problem with that, if vdev-netvsc is good for you, I can update it in v2
if needed.

I'm just curious, I was under the impression both drivers would remain kind
of complementary pending various API updates, 

Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Adrien Mazarguil]

On Mon, Dec 18, 2017 at 10:26:29AM -0800, Stephen Hemminger wrote:
> On Mon, 18 Dec 2017 17:46:23 +0100
> Adrien Mazarguil  wrote:
> 
> > +static int
> > +ether_addr_from_str(struct ether_addr *eth_addr, const char *str)
> > +{
> > +   static const uint8_t conv[0x100] = {
> > +   ['0'] = 0x80, ['1'] = 0x81, ['2'] = 0x82, ['3'] = 0x83,
> > +   ['4'] = 0x84, ['5'] = 0x85, ['6'] = 0x86, ['7'] = 0x87,
> > +   ['8'] = 0x88, ['9'] = 0x89, ['a'] = 0x8a, ['b'] = 0x8b,
> > +   ['c'] = 0x8c, ['d'] = 0x8d, ['e'] = 0x8e, ['f'] = 0x8f,
> > +   ['A'] = 0x8a, ['B'] = 0x8b, ['C'] = 0x8c, ['D'] = 0x8d,
> > +   ['E'] = 0x8e, ['F'] = 0x8f, [':'] = 0x40, ['-'] = 0x40,
> > +   ['\0'] = 0x60,
> > +   };
> > +   uint64_t addr = 0;
> > +   uint64_t buf = 0;
> > +   unsigned int i = 0;
> > +   unsigned int n = 0;
> > +   uint8_t tmp;
> > +
> > +   do {
> > +   tmp = conv[(int)*(str++)];
> > +   if (!tmp)
> > +   return -EINVAL;
> > +   if (tmp & 0x40) {
> > +   i += (i & 1) + (!i << 1);
> > +   addr = (addr << (i << 2)) | buf;
> > +   n += i;
> > +   buf = 0;
> > +   i = 0;
> > +   } else {
> > +   buf = (buf << 4) | (tmp & 0xf);
> > +   ++i;
> > +   }
> > +   } while (!(tmp & 0x20));
> > +   if (n > 12)
> > +   return -EINVAL;
> > +   i = RTE_DIM(eth_addr->addr_bytes);
> > +   while (i) {
> > +   eth_addr->addr_bytes[--i] = addr & 0xff;
> > +   addr >>= 8;
> > +   }
> > +   return 0;
> > +}
> > +
> 
> 
> Why not ether_ntoa?

Good question. For the following reasons:

- I forgot about the existence of ether_ntoa() and didn't look it up seeing
  struct ether_addr is (re-)defined by rte_ether.h. What happens when one
  includes netinet/ether.h together with that file results in various
  conflicts that trigger a compilation error. This problem should be
  addressed first.

- ether_ntoa() returns a static buffer and is not reentrant, ether_ntoa_r()
  is but as a GNU extension, I'm not sure it exists on other OSes. Even if
  this driver is currently targeted at Linux, this is likely not the case
  for other DPDK code relying on rte_ether.h.

- I had ether_addr_from_str()'s code already ready and lying around for a
  future update in testpmd's flow command parser. No other MAC-48 conversion
  function I know of is as flexible as this version. The ability to omit ":"
  and entering partial addresses is a big plus IMO.

I think both can coexist on their own merits. Since rte_ether.h needs to be
fixed either way, how about I move this function in a separate commit and
address the conflict with netinet/ether.h while there?

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Adrien Mazarguil]

On Mon, Dec 18, 2017 at 10:34:12AM -0800, Stephen Hemminger wrote:
> On Mon, 18 Dec 2017 17:46:23 +0100
> Adrien Mazarguil  wrote:
> 
> >  
> >  /**
> > + * Destroy a hyperv context instance.
> > + *
> > + * @param ctx
> > + *   Context to destroy.
> > + */
> > +static void
> > +hyperv_ctx_destroy(struct hyperv_ctx *ctx)
> > +{
> > +   if (ctx->pipe[0] != -1)
> > +   close(ctx->pipe[0]);
> > +   if (ctx->pipe[1] != -1)
> > +   close(ctx->pipe[1]);
> > +   /* Poisoning for debugging purposes. */
> > +   memset(ctx, 0x22, sizeof(*ctx));
> 
> Don't leave debug code in submitted drivers

Granted this line should be behind #ifdef RTE_LIBRTE_HYPERV_DEBUG.

Surely you don't mean *no* debugging code at all? This memset() allows an
application to crash early in case its control path parallelizes things it
shouldn't.

> 
> > +   free(ctx);
> > +}
> > +
> > +/**
> > + * Iterate over system network interfaces.
> > + *
> > + * This function runs a given callback function for each netdevice found on
> > + * the system.
> > + *
> > + * @param func
> > + *   Callback function pointer. List traversal is aborted when this 
> > function
> > + *   returns a nonzero value.
> > + * @param ...
> > + *   Variable parameter list passed as @p va_list to @p func.
> > + *
> > + * @return
> > + *   0 when the entire list is traversed successfully, a negative error 
> > code
> > + *   in case or failure, or the nonzero value returned by @p func when list
> > + *   traversal is aborted.
> > + */
> > +static int
> > +hyperv_foreach_iface(int (*func)(const struct if_nameindex *iface,
> > +const struct ether_addr *eth_addr,
> > +va_list ap), ...)
> > +{
> > +   struct if_nameindex *iface = if_nameindex();
> > +   int s = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
> > +   unsigned int i;
> > +   int ret = 0;
> > +
> > +   if (!iface) {
> > +   ret = -ENOBUFS;
> > +   ERROR("cannot retrieve system network interfaces");
> > +   goto error;
> > +   }
> > +   if (s == -1) {
> > +   ret = -errno;
> > +   ERROR("cannot open socket: %s", rte_strerror(errno));
> > +   goto error;
> > +   }
> > +   for (i = 0; iface[i].if_name; ++i) {
> > +   struct ifreq req;
> > +   struct ether_addr eth_addr;
> > +   va_list ap;
> > +
> > +   strncpy(req.ifr_name, iface[i].if_name, sizeof(req.ifr_name));
> > +   if (ioctl(s, SIOCGIFHWADDR, &req) == -1) {
> > +   WARN("cannot retrieve information about interface"
> > +" \"%s\": %s",
> > +req.ifr_name, rte_strerror(errno));
> > +   continue;
> > +   }
> > +   memcpy(eth_addr.addr_bytes, req.ifr_hwaddr.sa_data,
> > +  RTE_DIM(eth_addr.addr_bytes));
> > +   va_start(ap, func);
> > +   ret = func(&iface[i], ð_addr, ap);
> > +   va_end(ap);
> > +   if (ret)
> > +   break;
> > +   }
> > +error:
> > +   if (s != -1)
> > +   close(s);
> > +   if (iface)
> > +   if_freenameindex(iface);
> > +   return ret;
> > +}
> > +
> > +/**
> > + * Determine if a network interface is NetVSC.
> > + *
> > + * @param[in] iface
> > + *   Pointer to netdevice description structure (name and index).
> > + *
> > + * @return
> > + *   A nonzero value when interface is detected as NetVSC. In case of 
> > error,
> > + *   rte_errno is updated and 0 returned.
> > + */
> > +static int
> > +hyperv_iface_is_netvsc(const struct if_nameindex *iface)
> > +{
> > +   static const char temp[] = "/sys/class/net/%s/device/class_id";
> > +   char path[snprintf(NULL, 0, temp, iface->if_name) + 1];
> 
> Doing this snprintf is gross. Either use PATH_MAX or asprintf

I don't think allocating more stack space than necessary or on the heap with
a possible allocation failure to deal with is any better, sorry.

Prove this snprintf() call can fail and you'll have a point.

> > +   FILE *f;
> > +   int ret;
> > +   int len = 0;
> > +
> > +   snprintf(path, sizeof(path), temp, iface->if_name);
> > +   f = fopen(path, "r");
> > +   if (!f) {
> > +   rte_errno = errno;
> > +   return 0;
> > +   }
> > +   ret = fscanf(f, NETVSC_CLASS_ID "%n", &len);
> > +   if (ret == EOF)
> > +   rte_errno = errno;
> > +   ret = len == (int)strlen(NETVSC_CLASS_ID);
> > +   fclose(f);
> > +   return ret;
> > +}
> > +
> > +/**
> > + * Retrieve the last component of a path.
> > + *
> > + * This is a simplified basename() that does not modify its input buffer to
> > + * handle trailing backslashes.
> > + *
> > + * @param[in] path
> > + *Path to retrieve the last component from.
> > + *
> > + * @return
> > + *Pointer to the last component.
> > + */
> > +static const char *
> > +hyperv_basename(const char *path)
> > +{
> > +   const char *tmp = path;
> > +
> > +   while (*tmp)
> > +   if (*(tmp++) == '/')
> 
> Too may ()

Will

Re: [dpdk-dev] [PATCH v1 1/3] net/hyperv: introduce MS Hyper-V platform driver

[Thomas Monjalon]

18/12/2017 19:28, Stephen Hemminger:
> On Mon, 18 Dec 2017 17:46:21 +0100
> Adrien Mazarguil  wrote:
> 
> > +#ifdef RTE_LIBRTE_HYPERV_DEBUG
> > +
> > +#define PMD_DRV_LOG(level, ...) \
> > +   RTE_LOG(level, PMD, \
> > +   RTE_FMT("%s:%u: %s(): " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
> > +   strrchr("/" __FILE__, '/') + 1, \
> > +   __LINE__, \
> > +   __func__, \
> > +   RTE_FMT_TAIL(__VA_ARGS__,)))
> > +
> > +#else /* RTE_LIBRTE_HYPERV_DEBUG */
> > +
> > +#define PMD_DRV_LOG(level, ...) \
> > +   RTE_LOG(level, PMD, \
> > +   RTE_FMT(RTE_STR(HYPERV_DRIVER) ": " \
> > +   RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
> > +   RTE_FMT_TAIL(__VA_ARGS__,)))
> > +
> > +#endif /* RTE_LIBRTE_HYPERV_DEBUG */
> > +
> > +#define DEBUG(...) PMD_DRV_LOG(DEBUG, __VA_ARGS__)
> > +#define INFO(...) PMD_DRV_LOG(INFO, __VA_ARGS__)
> > +#define WARN(...) PMD_DRV_LOG(WARNING, __VA_ARGS__)
> > +#define ERROR(...) PMD_DRV_LOG(ERR, __VA_ARGS__)
> > +
> 
> Please don't use DEBUG() etc macros. It makes it easier for tools that do
> global updates or scans if all drivers use the same model of PMD_DRV_LOG

The new standard is to use dynamic logtype.

Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Thomas Monjalon]

18/12/2017 21:21, Adrien Mazarguil:
> On Mon, Dec 18, 2017 at 10:26:29AM -0800, Stephen Hemminger wrote:
> > On Mon, 18 Dec 2017 17:46:23 +0100
> > Adrien Mazarguil  wrote:
> > 
> > > +static int
> > > +ether_addr_from_str(struct ether_addr *eth_addr, const char *str)
> > > +{
> > > + static const uint8_t conv[0x100] = {
> > > + ['0'] = 0x80, ['1'] = 0x81, ['2'] = 0x82, ['3'] = 0x83,
> > > + ['4'] = 0x84, ['5'] = 0x85, ['6'] = 0x86, ['7'] = 0x87,
> > > + ['8'] = 0x88, ['9'] = 0x89, ['a'] = 0x8a, ['b'] = 0x8b,
> > > + ['c'] = 0x8c, ['d'] = 0x8d, ['e'] = 0x8e, ['f'] = 0x8f,
> > > + ['A'] = 0x8a, ['B'] = 0x8b, ['C'] = 0x8c, ['D'] = 0x8d,
> > > + ['E'] = 0x8e, ['F'] = 0x8f, [':'] = 0x40, ['-'] = 0x40,
> > > + ['\0'] = 0x60,
> > > + };
> > > + uint64_t addr = 0;
> > > + uint64_t buf = 0;
> > > + unsigned int i = 0;
> > > + unsigned int n = 0;
> > > + uint8_t tmp;
> > > +
> > > + do {
> > > + tmp = conv[(int)*(str++)];
> > > + if (!tmp)
> > > + return -EINVAL;
> > > + if (tmp & 0x40) {
> > > + i += (i & 1) + (!i << 1);
> > > + addr = (addr << (i << 2)) | buf;
> > > + n += i;
> > > + buf = 0;
> > > + i = 0;
> > > + } else {
> > > + buf = (buf << 4) | (tmp & 0xf);
> > > + ++i;
> > > + }
> > > + } while (!(tmp & 0x20));
> > > + if (n > 12)
> > > + return -EINVAL;
> > > + i = RTE_DIM(eth_addr->addr_bytes);
> > > + while (i) {
> > > + eth_addr->addr_bytes[--i] = addr & 0xff;
> > > + addr >>= 8;
> > > + }
> > > + return 0;
> > > +}
> > > +
> > 
> > 
> > Why not ether_ntoa?
> 
> Good question. For the following reasons:
> 
> - I forgot about the existence of ether_ntoa() and didn't look it up seeing
>   struct ether_addr is (re-)defined by rte_ether.h. What happens when one
>   includes netinet/ether.h together with that file results in various
>   conflicts that trigger a compilation error. This problem should be
>   addressed first.
> 
> - ether_ntoa() returns a static buffer and is not reentrant, ether_ntoa_r()
>   is but as a GNU extension, I'm not sure it exists on other OSes. Even if
>   this driver is currently targeted at Linux, this is likely not the case
>   for other DPDK code relying on rte_ether.h.
> 
> - I had ether_addr_from_str()'s code already ready and lying around for a
>   future update in testpmd's flow command parser. No other MAC-48 conversion
>   function I know of is as flexible as this version. The ability to omit ":"
>   and entering partial addresses is a big plus IMO.
> 
> I think both can coexist on their own merits. Since rte_ether.h needs to be
> fixed either way, how about I move this function in a separate commit and
> address the conflict with netinet/ether.h while there?

Looks to be a good plan.

[dpdk-dev] [PATCH] net/pcap: convert license headers to SPDX tags

[Ferruh Yigit]

Signed-off-by: Ferruh Yigit 
---
 doc/guides/nics/pcap_ring.rst   | 29 +
 drivers/net/pcap/Makefile   | 35 ---
 drivers/net/pcap/rte_eth_pcap.c | 35 ---
 3 files changed, 9 insertions(+), 90 deletions(-)

diff --git a/doc/guides/nics/pcap_ring.rst b/doc/guides/nics/pcap_ring.rst
index 5e4f5f605..5e0bab969 100644
--- a/doc/guides/nics/pcap_ring.rst
+++ b/doc/guides/nics/pcap_ring.rst
@@ -1,32 +1,5 @@
-..  BSD LICENSE
+..  SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-* Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
-* Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in
-the documentation and/or other materials provided with the
-distribution.
-* Neither the name of Intel Corporation nor the names of its
-contributors may be used to endorse or promote products derived
-from this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 Libpcap and Ring Based Poll Mode Drivers
 
diff --git a/drivers/net/pcap/Makefile b/drivers/net/pcap/Makefile
index b6487d42b..16738a233 100644
--- a/drivers/net/pcap/Makefile
+++ b/drivers/net/pcap/Makefile
@@ -1,34 +1,7 @@
-#   BSD LICENSE
-#
-#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-#   Copyright(c) 2014 6WIND S.A.
-#   All rights reserved.
-#
-#   Redistribution and use in source and binary forms, with or without
-#   modification, are permitted provided that the following conditions
-#   are met:
-#
-# * Redistributions of source code must retain the above copyright
-#   notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-#   notice, this list of conditions and the following disclaimer in
-#   the documentation and/or other materials provided with the
-#   distribution.
-# * Neither the name of Intel Corporation nor the names of its
-#   contributors may be used to endorse or promote products derived
-#   from this software without specific prior written permission.
-#
-#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+# Copyright(c) 2014 6WIND S.A.
+# All rights reserved.
 
 include $(RTE_SDK)/mk/rte.vars.mk
 
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 5a86752f9..74581616d 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -1,35 +1,8 @@
 /*-
- *   BSD LICENSE
- *
- *   Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
- *   Copyright(c) 2014 6WIND S.A.
- *   All rights reserved.
- *
- *   Redistribution and use in source and binary forms, with or without
- *   modification, are permitted provided that the following conditions
- *   are met:
- *
- * * Redistributions of source code must retain the above copyright
- *   not

Re: [dpdk-dev] [RFC v3 0/1] Compression API in DPDK

[Ahmed Mansour]

Hi Fiona,

On 12/15/2017 11:16 PM, Trahe, Fiona wrote:

> With the vast amounts of data being transported around networks and stored in
> storage systems, reducing data size is becoming ever more important. There
> are both software libraries and hardware devices available that provide
> compression, but no common API. This RFC proposes a compression API for
> DPDK to address this need.
>
> Features:
> • Deflate Algorithm 
> (https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc1951&data=02%7C01%7Cahmed.mansour%40nxp.com%7C76241a2796db4701ef0108d54634a70f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636492114308805852&sdata=yglh48%2F8IuEn%2F7YCL49FlyhGyCnNRX4g4xx2WJQesFs%3D&reserved=0)
> • LZS algorithm 
> (https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2395&data=02%7C01%7Cahmed.mansour%40nxp.com%7C76241a2796db4701ef0108d54634a70f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636492114308805852&sdata=BlfNe3pRXpEFJE4KS8Spk8bJ5GWPDqADhZYoD7SKvjk%3D&reserved=0)
> • Static and Dynamic Huffman encoding.
> • Compression levels
> • Checksum generation
> • Asynchronous burst API
> • Session-based (a session contains immutable data only and is useable 
> across devices)
> • stream-based to maintain state and history data for stateful flows.
>
> Note 1: Split of functionality above/below API
> When considering whether features should be supported on the API or not, the
> decision was based on the following:
> The purpose of the API is to decouple the application from the 
> compute-intensive
> functions needed for compression by abstracting them under a common API. These
> can then be implemented by either hardware accelerators or optimised software
> libraries. Where features are not compute-intensive and unlikely to be
> offloaded or optimised, there’s nothing to be gained by each PMD having
> to separately implement them, and it makes more sense for them to be done
> above the API. So the following are not handled on the API and can be done 
> above.
> • Prepending/appending protocol headers (gzip, zlib)

Agreed with the notion, however the header and footer handling can be 
added as an option. PMDs can support or not support each format. We 
(NXP) support auto padding of gzip and zlib headers as well as DEFLATE only.

> • File-handling, breaking files up into packets, reassembling.
> • Synchronous API
> • Serialisation of stateful requests
>
>
Is stateful planned for next phase? During design discussions we uncovered many 
API design
considerations necessary for stateful use. Chained stateful support in the 
future might not be
possible without compatibility breaking  

> Note 2: The tricky question of where the API belongs
> We considered
> 1. Extending cryptodev
> 2. New acceldev APIs for device handling + compressdev APIs for data path
> 3. New acceldev for all APIs
> 4. New compressdev API
> We've gone with option 4, a compressdev API.  See original RFC [1] for 
> reasons.
> We explored wrapping this around a generic acceldev that would be hidden from 
> the API
> but could be common to cryptodev, compressdev and other accelerators on the 
> PMD interface,
> but this added complexity and indirection and didn't add enough value, so 
> we've abandoned it.
>
Makes sense. compression is common enough to be attempted to be a 
different device category.


> Opens:
>  - Define structures and API for proposed hash functionality
>  - Agree on stateful behaviour

What are the the current thoughts for stateful behavior?

>  - Complete capability APIs

A capability API is very much required as different HW/SW can have 
different capabilities.


regards,
Ahmed

[dpdk-dev] [PATCH 1/2] kni: convert license headers to SPDX tags

[Ferruh Yigit]

Signed-off-by: Ferruh Yigit 
---
 doc/guides/prog_guide/kernel_nic_interface.rst | 29 +--
 doc/guides/sample_app_ug/kernel_nic_interface.rst  | 29 +--
 examples/kni/Makefile  | 32 +---
 examples/kni/main.c| 32 +---
 .../linuxapp/eal/include/exec-env/rte_kni_common.h | 57 +-
 lib/librte_eal/linuxapp/kni/Makefile   | 32 +---
 lib/librte_eal/linuxapp/kni/ethtool/README | 30 +---
 .../linuxapp/kni/ethtool/igb/e1000_82575.c | 18 +--
 .../linuxapp/kni/ethtool/igb/e1000_82575.h | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_api.c   | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_api.h   | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_defines.h   | 19 +---
 lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_hw.h | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_i210.c  | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_i210.h  | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_mac.c   | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_mac.h   | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_manage.c| 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_manage.h| 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_mbx.c   | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_mbx.h   | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_nvm.c   | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_nvm.h   | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_osdep.h | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_phy.c   | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_phy.h   | 19 +---
 .../linuxapp/kni/ethtool/igb/e1000_regs.h  | 19 +---
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h  | 19 +---
 .../linuxapp/kni/ethtool/igb/igb_ethtool.c | 19 +---
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c | 19 +---
 .../linuxapp/kni/ethtool/igb/igb_param.c   | 19 +---
 .../linuxapp/kni/ethtool/igb/igb_regtest.h | 19 +---
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_vmdq.c | 19 +---
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_vmdq.h | 19 +---
 lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h  | 19 +---
 lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe.h  | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_82598.c   | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_82598.h   | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_82599.c   | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_82599.h   | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_api.c | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_api.h | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_common.c  | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_common.h  | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_dcb.h | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_fcoe.h| 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_main.c| 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_mbx.h | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_osdep.h   | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_phy.c | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_phy.h | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_type.h| 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_x540.c| 19 +---
 .../linuxapp/kni/ethtool/ixgbe/ixgbe_x540.h| 19 +---
 .../linuxapp/kni/ethtool/ixgbe/kcompat.c   | 19 +---
 .../linuxapp/kni/ethtool/ixgbe/kcompat.h   | 19 +---
 lib/librte_eal/linuxapp/kni/kni_dev.h  | 23 +
 lib/librte_eal/linuxapp/kni/kni_ethtool.c  | 23 +
 lib/librte_eal/linuxapp/kni/kni_fifo.h | 23 +
 lib/librte_eal/linuxapp/kni/kni_misc.c | 23 +
 lib/librte_eal/linuxapp/kni/kni_net.c  | 23 +
 lib/librte_kni/Makefile| 30 +---
 lib/librte_kni/rte_kni.c   | 32 +---
 lib/librte_kni/rte_kni.h   | 32 +---
 lib/librte_kni/rte_kni_fifo.h  | 32 +---
 test/test/test_kni.c   | 32 +---
 67 files changed, 130 insertions(+), 1333 deletions(-)

diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst 
b/doc/guides/prog_guide/kernel_nic_interface.rst
index 4b2dd770f..9127eb8c1 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -1,32 +1,5 @@
-..  BSD LICENSE
+..  SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
-All rights reserved.
-
-   

[dpdk-dev] [PATCH 2/2] net/kni: convert license headers to SPDX tags

[Ferruh Yigit]

Signed-off-by: Ferruh Yigit 
---
 doc/guides/nics/kni.rst   | 29 +
 drivers/net/kni/Makefile  | 31 ++-
 drivers/net/kni/rte_eth_kni.c | 32 ++--
 3 files changed, 5 insertions(+), 87 deletions(-)

diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst
index 77542b56e..b69e302e5 100644
--- a/doc/guides/nics/kni.rst
+++ b/doc/guides/nics/kni.rst
@@ -1,32 +1,5 @@
-..  BSD LICENSE
+..  SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2017 Intel Corporation. All rights reserved.
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-* Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
-* Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in
-the documentation and/or other materials provided with the
-distribution.
-* Neither the name of Intel Corporation nor the names of its
-contributors may be used to endorse or promote products derived
-from this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 KNI Poll Mode Driver
 ==
diff --git a/drivers/net/kni/Makefile b/drivers/net/kni/Makefile
index a3f51f929..9af213354 100644
--- a/drivers/net/kni/Makefile
+++ b/drivers/net/kni/Makefile
@@ -1,32 +1,5 @@
-#   BSD LICENSE
-#
-#   Copyright(c) 2017 Intel Corporation. All rights reserved.
-#
-#   Redistribution and use in source and binary forms, with or without
-#   modification, are permitted provided that the following conditions
-#   are met:
-#
-# * Redistributions of source code must retain the above copyright
-#   notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-#   notice, this list of conditions and the following disclaimer in
-#   the documentation and/or other materials provided with the
-#   distribution.
-# * Neither the name of Intel Corporation nor the names of its
-#   contributors may be used to endorse or promote products derived
-#   from this software without specific prior written permission.
-#
-#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2017 Intel Corporation. All rights reserved.
 
 include $(RTE_SDK)/mk/rte.vars.mk
 
diff --git a/drivers/net/kni/rte_eth_kni.c b/drivers/net/kni/rte_eth_kni.c
index 8f269532d..9974a844f 100644
--- a/drivers/net/kni/rte_eth_kni.c
+++ b/drivers/net/kni/rte_eth_kni.c
@@ -1,34 +1,6 @@
 /*-
- *   BSD LICENSE
- *
- *   Copyright(c) 2017 Intel Corporation. All rights reserved.
- *   All rights reserved.
- *
- *   Redistribution and use in source and binary forms, with or without
- *   modification, are permitted provided that the following conditions
- *   are met:
- *
- * * Redistributions of source code must retain the above copyright
- *   notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- *   notice, this list of conditions and the following disclaimer in
- *   the documentation and/or other material

[dpdk-dev] [PATCH] igb_uio: convert license headers to SPDX tags

[Ferruh Yigit]

Signed-off-by: Ferruh Yigit 
---
 lib/librte_eal/linuxapp/igb_uio/Makefile  | 32 ++-
 lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 23 ++
 2 files changed, 4 insertions(+), 51 deletions(-)

diff --git a/lib/librte_eal/linuxapp/igb_uio/Makefile 
b/lib/librte_eal/linuxapp/igb_uio/Makefile
index ec6e702f0..bfb265d2f 100644
--- a/lib/librte_eal/linuxapp/igb_uio/Makefile
+++ b/lib/librte_eal/linuxapp/igb_uio/Makefile
@@ -1,33 +1,5 @@
-#   BSD LICENSE
-#
-#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
-#   All rights reserved.
-#
-#   Redistribution and use in source and binary forms, with or without
-#   modification, are permitted provided that the following conditions
-#   are met:
-#
-# * Redistributions of source code must retain the above copyright
-#   notice, this list of conditions and the following disclaimer.
-# * Redistributions in binary form must reproduce the above copyright
-#   notice, this list of conditions and the following disclaimer in
-#   the documentation and/or other materials provided with the
-#   distribution.
-# * Neither the name of Intel Corporation nor the names of its
-#   contributors may be used to endorse or promote products derived
-#   from this software without specific prior written permission.
-#
-#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
 
 include $(RTE_SDK)/mk/rte.vars.mk
 
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c 
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index a3a98c173..d0e4fd966 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -1,25 +1,6 @@
 /*-
- * GPL LICENSE SUMMARY
- *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
- *
- *   This program is free software; you can redistribute it and/or modify
- *   it under the terms of version 2 of the GNU General Public License as
- *   published by the Free Software Foundation.
- *
- *   This program is distributed in the hope that it will be useful, but
- *   WITHOUT ANY WARRANTY; without even the implied warranty of
- *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- *   General Public License for more details.
- *
- *   You should have received a copy of the GNU General Public License
- *   along with this program; if not, write to the Free Software
- *   Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
- *   The full GNU General Public License is included in this distribution
- *   in the file called LICENSE.GPL.
- *
- *   Contact Information:
- *   Intel Corporation
+ * SPDX-License-Identifier: GPL-2.0
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
2.14.3

[dpdk-dev] [PATCH] doc: convert license headers to SPDX tags for NIC docs

[Ferruh Yigit]

Signed-off-by: Ferruh Yigit 
---
 doc/guides/nics/build_and_test.rst | 28 +---
 doc/guides/nics/features.rst   | 29 +
 doc/guides/nics/overview.rst   | 28 +---
 3 files changed, 3 insertions(+), 82 deletions(-)

diff --git a/doc/guides/nics/build_and_test.rst 
b/doc/guides/nics/build_and_test.rst
index 2d70af88a..25b78b31c 100644
--- a/doc/guides/nics/build_and_test.rst
+++ b/doc/guides/nics/build_and_test.rst
@@ -1,32 +1,6 @@
-..  BSD LICENSE
+..  SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2017 Cavium, Inc.
 
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-* Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
-* Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in
-the documentation and/or other materials provided with the
-distribution.
-* Neither the name of Cavium, Inc. nor the names of its
-contributors may be used to endorse or promote products derived
-from this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-OWNER(S) OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
 .. _pmd_build_and_test:
 
 Compiling and testing a PMD for a NIC
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index d5bf38a21..24ae53bc3 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -1,32 +1,5 @@
-..  BSD LICENSE
+..  SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2017 Intel Corporation. All rights reserved.
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-* Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
-* Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in
-the documentation and/or other materials provided with the
-distribution.
-* Neither the name of Intel Corporation nor the names of its
-contributors may be used to endorse or promote products derived
-from this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 Features Overview
 =
diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index 0df0ef81a..20cd52b09 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -1,32 +1,6 @@
-..  BSD LICENSE
+..  SPDX-License-Identifier: BSD-3-Clause
 Copyright 2016 6WIND S.A.
 
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-* Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
-* Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in
-the documentation and/or other materials provided with the
-distribution.
-* Neither the name of 6WIND S.A. nor the names of

Re: [dpdk-dev] [PATCH v1 1/3] net/hyperv: introduce MS Hyper-V platform driver

[Stephen Hemminger]

On Mon, 18 Dec 2017 20:54:16 +0100
Thomas Monjalon  wrote:

> > > +#endif /* RTE_LIBRTE_HYPERV_DEBUG */
> > > +
> > > +#define DEBUG(...) PMD_DRV_LOG(DEBUG, __VA_ARGS__)
> > > +#define INFO(...) PMD_DRV_LOG(INFO, __VA_ARGS__)
> > > +#define WARN(...) PMD_DRV_LOG(WARNING, __VA_ARGS__)
> > > +#define ERROR(...) PMD_DRV_LOG(ERR, __VA_ARGS__)
> > > +  
> > 
> > Please don't use DEBUG() etc macros. It makes it easier for tools that do
> > global updates or scans if all drivers use the same model of PMD_DRV_LOG  
> 
> The new standard is to use dynamic logtype.

Agree, please use dynamic logging, and also don't redefine new macros like 
DEBUG/INFO/WARN/ERROR.
Instead use PMD_DRV_LOG or equivalent macros.

The base rule here is that all drivers should look the same as much
as reasonably possible. This makes reviewers of other subsystems more likely
to see problems. It also allows for later changes where some developer does a 
global
improvement across many PMD's.

Drivers should not be snowflakes, each one is not unique.

Re: [dpdk-dev] [PATCH] net/pcap: convert license headers to SPDX tags

[Ferruh Yigit]

On 12/18/2017 1:06 PM, Ferruh Yigit wrote:
> Signed-off-by: Ferruh Yigit 

<...>

> + * SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> + * Copyright(c) 2014 6WIND S.A.
> + * All rights reserved.
>   */

Hi Hemant, Thomas,

Can you please suggest about extra "All rights reserved." line.

It is in the part of the BSD header, and I _assume_ that has been intended to
cover all "Copyright" lines above it.
But since some of the Copyright holders (at least Intel ones) already has that
in same line with copyright and I _assume_ this is intentional because of legal
requirements, can we remove that line.

I guess we have two options while removing it, applying it to all previous
Copyright lines (B) or just remove it (A):

(A)
 SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
 Copyright(c) 2014 6WIND S.A.

(B)
 SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
 Copyright(c) 2014 6WIND S.A. All rights reserved.


Can we go with option (A)?

Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

[Stephen Hemminger]

On Mon, 18 Dec 2017 22:03:55 +0100
Thomas Monjalon  wrote:

> > 
> > Good question. For the following reasons:
> > 
> > - I forgot about the existence of ether_ntoa() and didn't look it up seeing
> >   struct ether_addr is (re-)defined by rte_ether.h. What happens when one
> >   includes netinet/ether.h together with that file results in various
> >   conflicts that trigger a compilation error. This problem should be
> >   addressed first.
> > 
> > - ether_ntoa() returns a static buffer and is not reentrant, ether_ntoa_r()
> >   is but as a GNU extension, I'm not sure it exists on other OSes. Even if
> >   this driver is currently targeted at Linux, this is likely not the case
> >   for other DPDK code relying on rte_ether.h.
> > 
> > - I had ether_addr_from_str()'s code already ready and lying around for a
> >   future update in testpmd's flow command parser. No other MAC-48 conversion
> >   function I know of is as flexible as this version. The ability to omit ":"
> >   and entering partial addresses is a big plus IMO.
> > 
> > I think both can coexist on their own merits. Since rte_ether.h needs to be
> > fixed either way, how about I move this function in a separate commit and
> > address the conflict with netinet/ether.h while there?  
> 
> Looks to be a good plan.

Agree, rte_ether is where it should go. Please put functions for parsing there.
The name and logic conflict between netinet/ether.h and rte is both a blessing
and a curse. Although the definitions of ether_addr overlap, they are 
equivalent.

Re: [dpdk-dev] [PATCH] net/pcap: convert license headers to SPDX tags

[Thomas Monjalon]

18/12/2017 22:18, Ferruh Yigit:
> On 12/18/2017 1:06 PM, Ferruh Yigit wrote:
> > Signed-off-by: Ferruh Yigit 
> 
> <...>
> 
> > + * SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> > + * Copyright(c) 2014 6WIND S.A.
> > + * All rights reserved.
> >   */
> 
> Hi Hemant, Thomas,
> 
> Can you please suggest about extra "All rights reserved." line.
> 
> It is in the part of the BSD header, and I _assume_ that has been intended to
> cover all "Copyright" lines above it.
> But since some of the Copyright holders (at least Intel ones) already has that
> in same line with copyright and I _assume_ this is intentional because of 
> legal
> requirements, can we remove that line.
> 
> I guess we have two options while removing it, applying it to all previous
> Copyright lines (B) or just remove it (A):
> 
> (A)
>  SPDX-License-Identifier: BSD-3-Clause
>  Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
>  Copyright(c) 2014 6WIND S.A.
> 
> (B)
>  SPDX-License-Identifier: BSD-3-Clause
>  Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
>  Copyright(c) 2014 6WIND S.A. All rights reserved.
> 
> Can we go with option (A)?

I have absolutely no idea about "All rights reserved".
Please get some inputs from Intel lawyers.

Re: [dpdk-dev] [RFC v3 1/1] lib: add compressdev API

[Ahmed Mansour]

On 12/15/2017 11:19 PM, Trahe, Fiona wrote:
.. 

> +
> +/** Compression Algorithms */
> +enum rte_comp_algorithm {
> + RTE_COMP_NULL = 0,
> + /**< No compression.
> +  * Pass-through, data is copied unchanged from source buffer to
> +  * destination buffer.
> +  */
> + RTE_COMP_DEFLATE,
> + /**< DEFLATE compression algorithm
> +  * 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc1951&data=02%7C01%7Cahmed.mansour%40nxp.com%7Cf3edbd70b38b49eb1f0308d54634e444%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636492115333128845&sdata=B3G0aIncVAK17dXlnSivXi0e56h2D7pEQZ9gK%2Fh3qZQ%3D&reserved=0
> +  */
> + RTE_COMP_LZS,
> + /**< LZS compression algorithm
> +  * 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2395&data=02%7C01%7Cahmed.mansour%40nxp.com%7Cf3edbd70b38b49eb1f0308d54634e444%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636492115333128845&sdata=aNRFIfkelXlCUUgpp%2BzCYaTu28tp6fF0m6k7F13w1Ps%3D&reserved=0
> +  */
> + RTE_COMP_ALGO_LIST_END
> +};
> +
> +/**< Compression Level.
> + * The number is interpreted by each PMD differently. However, lower numbers
> + * give fastest compression, at the expense of compression ratio while
> + * higher numbers may give better compression ratios but are likely slower.
> + */
> +#define  RTE_COMP_LEVEL_PMD_DEFAULT  (-1)
> +/** Use PMD Default */
> +#define  RTE_COMP_LEVEL_NONE (0)
> +/** Output uncompressed blocks if supported by the specified algorithm */
> +#define RTE_COMP_LEVEL_MIN   (1)
> +/** Use minimum compression level supported by the PMD */
> +#define RTE_COMP_LEVEL_MAX   (9)
> +/** Use maximum compression level supported by the PMD */
> +
> +/** Compression checksum types */
> +enum rte_comp_checksum_type {
> + RTE_COMP_NONE,
> + /**< No checksum generated */
> + RTE_COMP_CRC32,
> + /**< Generates a CRC32 checksum, as used by gzip */
> + RTE_COMP_ADLER32,
> + /**< Generates an Adler-32 checksum, as used by zlib */
> + RTE_COMP_CRC32_ADLER32,
> + /**< Generates both Adler-32 and CRC32 checksums, concatenated.
> +  * CRC32 is in the lower 32bits, Adler-32 in the upper 32 bits.
> +  */

What would be a real life use case for returning both CRC32 and ADLER32?
Packaging the data once as Gzip and once as zlib?

> +};
> +
> +/*
> + * enum rte_comp_hash_algo {
> + *   RTE_COMP_HASH_NONE,
> + *   RTE_COMP_HASH_SHA1,
> + *   RTE_COMP_HASH_SHA256,
> + * };
> + * Need further input from cavium on this
> + * xform will need a flag with above enum value
> + * op will need to provide a virt/phys ptr to a data buffer of appropriate 
> size.
> + * And via capability PMD can say whether supported or not.
> + */
> +
> +/** Compression Huffman Type - used by DEFLATE algorithm */
> +enum rte_comp_huffman {
> + RTE_COMP_DEFAULT,
> + /**< PMD may choose which Huffman codes to use */
> + RTE_COMP_FIXED,
> + /**< Use Fixed Huffman codes */
> + RTE_COMP_DYNAMIC,
> + /**< Use Dynamic Huffman codes */
> +};
> +
> +
> +enum rte_comp_flush_flag {
> + RTE_COMP_FLUSH_NONE,
> + /**< Data is not flushed. Output may remain in the compressor and be
> +  * processed during a following op. It may not be possible to decompress
> +  * output until a later op with some other flush flag has been sent.
> +  */
> + RTE_COMP_FLUSH_SYNC,
> + /**< All data should be flushed to output buffer. Output data can be
> +  * decompressed. However state and history is not cleared, so future
> +  * ops may use history from this op */
> + RTE_COMP_FLUSH_FULL,
> + /**< All data should be flushed to output buffer. Output data can be
> +  * decompressed. State and history data is cleared, so future
> +  * ops will be independent of ops processed before this.
> +  */
> + RTE_COMP_FLUSH_FINAL
> + /**< Same as RTE_COMP_FLUSH_FULL but also bfinal bit is set in last 
> block
> +  */
> +  /* TODO:
> +   * describe flag meanings for decompression.
> +   * describe behavous in OUT_OF_SPACE case.
> +   * At least the last flag is specific to deflate algo. Should this be
> +   * called rte_comp_deflate_flush_flag? And should there be
> +   * comp_op_deflate_params in the op? */

What about Z_BLOCK and Z_TREES? Those are needed for sfwr zlib.net 
replacements.

> +};
> +
> +/** Compression transform types */
> +enum rte_comp_xform_type {
> + RTE_COMP_COMPRESS,
> + /**< Compression service - compress */
> + RTE_COMP_DECOMPRESS,
> + /**< Compression service - decompress */
> +};
> +

... 

> +struct rte_comp_session;
> +/**
> + * Compression Operation.
> + *
> + * This structure contains data relating to performing a compression
> + * operation on the referenced mbuf data buffers.
> + *
> + * All compression operations are Out-of-place (OOP) operations,
> + * as the size of t

[dpdk-dev] [PATCH v2 01/12] app/eventdev: add packet distribution logs

[Pavan Nikhilesh]

Add logs for packet distribution across worker cores to be printed
along with the test results.

Signed-off-by: Pavan Nikhilesh 
Acked-by: Jerin Jacob 
---
 app/test-eventdev/evt_main.c |  3 +++
 app/test-eventdev/test_perf_common.c | 12 
 2 files changed, 15 insertions(+)

diff --git a/app/test-eventdev/evt_main.c b/app/test-eventdev/evt_main.c
index 1c3a7faeb..bde388b97 100644
--- a/app/test-eventdev/evt_main.c
+++ b/app/test-eventdev/evt_main.c
@@ -57,6 +57,9 @@ signal_handler(int signum)

rte_eal_mp_wait_lcore();

+   if (test->ops.test_result)
+   test->ops.test_result(test, &opt);
+
if (test->ops.eventdev_destroy)
test->ops.eventdev_destroy(test, &opt);

diff --git a/app/test-eventdev/test_perf_common.c 
b/app/test-eventdev/test_perf_common.c
index 9aff31f20..428af4ae2 100644
--- a/app/test-eventdev/test_perf_common.c
+++ b/app/test-eventdev/test_perf_common.c
@@ -36,8 +36,20 @@ int
 perf_test_result(struct evt_test *test, struct evt_options *opt)
 {
RTE_SET_USED(opt);
+   int i;
+   uint64_t total = 0;
struct test_perf *t = evt_test_priv(test);

+   printf("Packet distribution across worker cores :\n");
+   for (i = 0; i < t->nb_workers; i++)
+   total += t->worker[i].processed_pkts;
+   for (i = 0; i < t->nb_workers; i++)
+   printf("Worker %d packets: "CLGRN"%"PRIx64" "CLNRM"percentage:"
+   CLGRN" %3.2f\n"CLNRM, i,
+   t->worker[i].processed_pkts,
+   (((double)t->worker[i].processed_pkts)/total)
+   * 100);
+
return t->result;
 }

--
2.14.1

[dpdk-dev] [PATCH v2 03/12] app/eventdev: add mempool setup and destroy

[Pavan Nikhilesh]

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/test_pipeline_common.c | 29 +
 app/test-eventdev/test_pipeline_common.h |  2 ++
 2 files changed, 31 insertions(+)

diff --git a/app/test-eventdev/test_pipeline_common.c 
b/app/test-eventdev/test_pipeline_common.c
index 6e9088719..d34003362 100644
--- a/app/test-eventdev/test_pipeline_common.c
+++ b/app/test-eventdev/test_pipeline_common.c
@@ -32,6 +32,35 @@
 
 #include "test_pipeline_common.h"
 
+int
+pipeline_mempool_setup(struct evt_test *test, struct evt_options *opt)
+{
+   struct test_pipeline *t = evt_test_priv(test);
+
+   t->pool = rte_pktmbuf_pool_create(test->name, /* mempool name */
+   opt->pool_sz, /* number of elements*/
+   512, /* cache size*/
+   0,
+   RTE_MBUF_DEFAULT_BUF_SIZE,
+   opt->socket_id); /* flags */
+
+   if (t->pool == NULL) {
+   evt_err("failed to create mempool");
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
+void
+pipeline_mempool_destroy(struct evt_test *test, struct evt_options *opt)
+{
+   RTE_SET_USED(opt);
+   struct test_pipeline *t = evt_test_priv(test);
+
+   rte_mempool_free(t->pool);
+}
+
 int
 pipeline_test_setup(struct evt_test *test, struct evt_options *opt)
 {
diff --git a/app/test-eventdev/test_pipeline_common.h 
b/app/test-eventdev/test_pipeline_common.h
index f87d02d6b..35367d546 100644
--- a/app/test-eventdev/test_pipeline_common.h
+++ b/app/test-eventdev/test_pipeline_common.h
@@ -79,6 +79,8 @@ struct test_pipeline {
 } __rte_cache_aligned;
 
 int pipeline_test_setup(struct evt_test *test, struct evt_options *opt);
+int pipeline_mempool_setup(struct evt_test *test, struct evt_options *opt);
 void pipeline_test_destroy(struct evt_test *test, struct evt_options *opt);
+void pipeline_mempool_destroy(struct evt_test *test, struct evt_options *opt);
 
 #endif /* _TEST_PIPELINE_COMMON_ */
-- 
2.14.1

[dpdk-dev] [PATCH v2 02/12] app/eventdev: add pipeline test setup and destroy

[Pavan Nikhilesh]

Pipeline test has the queue and all types queue variants.
Introduce test_pipeline_common* to share the common code between those
tests.

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/Makefile   |  2 +
 app/test-eventdev/test_pipeline_common.c | 71 +++
 app/test-eventdev/test_pipeline_common.h | 84 
 3 files changed, 157 insertions(+)
 create mode 100644 app/test-eventdev/test_pipeline_common.c
 create mode 100644 app/test-eventdev/test_pipeline_common.h

diff --git a/app/test-eventdev/Makefile b/app/test-eventdev/Makefile
index dcb2ac476..f2fb665d8 100644
--- a/app/test-eventdev/Makefile
+++ b/app/test-eventdev/Makefile
@@ -51,4 +51,6 @@ SRCS-y += test_perf_common.c
 SRCS-y += test_perf_queue.c
 SRCS-y += test_perf_atq.c
 
+SRCS-y += test_pipeline_common.c
+
 include $(RTE_SDK)/mk/rte.app.mk
diff --git a/app/test-eventdev/test_pipeline_common.c 
b/app/test-eventdev/test_pipeline_common.c
new file mode 100644
index 0..6e9088719
--- /dev/null
+++ b/app/test-eventdev/test_pipeline_common.c
@@ -0,0 +1,71 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) Cavium, Inc 2017.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Cavium, Inc nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "test_pipeline_common.h"
+
+int
+pipeline_test_setup(struct evt_test *test, struct evt_options *opt)
+{
+   void *test_pipeline;
+
+   test_pipeline = rte_zmalloc_socket(test->name,
+   sizeof(struct test_pipeline), RTE_CACHE_LINE_SIZE,
+   opt->socket_id);
+   if (test_pipeline  == NULL) {
+   evt_err("failed to allocate test_pipeline memory");
+   goto nomem;
+   }
+   test->test_priv = test_pipeline;
+
+   struct test_pipeline *t = evt_test_priv(test);
+
+   t->nb_workers = evt_nr_active_lcores(opt->wlcores);
+   t->outstand_pkts = opt->nb_pkts * evt_nr_active_lcores(opt->wlcores);
+   t->done = false;
+   t->nb_flows = opt->nb_flows;
+   t->result = EVT_TEST_FAILED;
+   t->opt = opt;
+   opt->prod_type = EVT_PROD_TYPE_ETH_RX_ADPTR;
+   memcpy(t->sched_type_list, opt->sched_type_list,
+   sizeof(opt->sched_type_list));
+   return 0;
+nomem:
+   return -ENOMEM;
+}
+
+void
+pipeline_test_destroy(struct evt_test *test, struct evt_options *opt)
+{
+   RTE_SET_USED(opt);
+
+   rte_free(test->test_priv);
+}
diff --git a/app/test-eventdev/test_pipeline_common.h 
b/app/test-eventdev/test_pipeline_common.h
new file mode 100644
index 0..f87d02d6b
--- /dev/null
+++ b/app/test-eventdev/test_pipeline_common.h
@@ -0,0 +1,84 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) Cavium, Inc 2017.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Cavium, Inc nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permi

[dpdk-dev] [PATCH v2 04/12] app/eventdev: add pipeline opt dump and check functions

[Pavan Nikhilesh]

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/test_pipeline_common.c | 84 
 app/test-eventdev/test_pipeline_common.h |  3 ++
 2 files changed, 87 insertions(+)

diff --git a/app/test-eventdev/test_pipeline_common.c 
b/app/test-eventdev/test_pipeline_common.c
index d34003362..d2ffcbe08 100644
--- a/app/test-eventdev/test_pipeline_common.c
+++ b/app/test-eventdev/test_pipeline_common.c
@@ -32,6 +32,90 @@
 
 #include "test_pipeline_common.h"
 
+int
+pipeline_test_result(struct evt_test *test, struct evt_options *opt)
+{
+   RTE_SET_USED(opt);
+   int i;
+   uint64_t total = 0;
+   struct test_pipeline *t = evt_test_priv(test);
+
+   printf("Packet distribution across worker cores :\n");
+   for (i = 0; i < t->nb_workers; i++)
+   total += t->worker[i].processed_pkts;
+   for (i = 0; i < t->nb_workers; i++)
+   printf("Worker %d packets: "CLGRN"%"PRIx64" "CLNRM"percentage:"
+   CLGRN" %3.2f\n"CLNRM, i,
+   t->worker[i].processed_pkts,
+   (((double)t->worker[i].processed_pkts)/total)
+   * 100);
+   return t->result;
+}
+
+void
+pipeline_opt_dump(struct evt_options *opt, uint8_t nb_queues)
+{
+   evt_dump("nb_worker_lcores", "%d", evt_nr_active_lcores(opt->wlcores));
+   evt_dump_worker_lcores(opt);
+   evt_dump_nb_stages(opt);
+   evt_dump("nb_evdev_ports", "%d", pipeline_nb_event_ports(opt));
+   evt_dump("nb_evdev_queues", "%d", nb_queues);
+   evt_dump_queue_priority(opt);
+   evt_dump_sched_type_list(opt);
+   evt_dump_producer_type(opt);
+}
+
+int
+pipeline_opt_check(struct evt_options *opt, uint64_t nb_queues)
+{
+   unsigned int lcores;
+   /*
+* N worker + 1 master
+*/
+   lcores = 2;
+
+   if (!rte_eth_dev_count()) {
+   evt_err("test needs minimum 1 ethernet dev");
+   return -1;
+   }
+
+   if (rte_lcore_count() < lcores) {
+   evt_err("test need minimum %d lcores", lcores);
+   return -1;
+   }
+
+   /* Validate worker lcores */
+   if (evt_lcores_has_overlap(opt->wlcores, rte_get_master_lcore())) {
+   evt_err("worker lcores overlaps with master lcore");
+   return -1;
+   }
+   if (evt_has_disabled_lcore(opt->wlcores)) {
+   evt_err("one or more workers lcores are not enabled");
+   return -1;
+   }
+   if (!evt_has_active_lcore(opt->wlcores)) {
+   evt_err("minimum one worker is required");
+   return -1;
+   }
+
+   if (nb_queues > EVT_MAX_QUEUES) {
+   evt_err("number of queues exceeds %d", EVT_MAX_QUEUES);
+   return -1;
+   }
+   if (pipeline_nb_event_ports(opt) > EVT_MAX_PORTS) {
+   evt_err("number of ports exceeds %d", EVT_MAX_PORTS);
+   return -1;
+   }
+
+   if (evt_has_invalid_stage(opt))
+   return -1;
+
+   if (evt_has_invalid_sched_type(opt))
+   return -1;
+
+   return 0;
+}
+
 int
 pipeline_mempool_setup(struct evt_test *test, struct evt_options *opt)
 {
diff --git a/app/test-eventdev/test_pipeline_common.h 
b/app/test-eventdev/test_pipeline_common.h
index 35367d546..e709a1000 100644
--- a/app/test-eventdev/test_pipeline_common.h
+++ b/app/test-eventdev/test_pipeline_common.h
@@ -78,8 +78,11 @@ struct test_pipeline {
uint8_t sched_type_list[EVT_MAX_STAGES] __rte_cache_aligned;
 } __rte_cache_aligned;
 
+int pipeline_test_result(struct evt_test *test, struct evt_options *opt);
+int pipeline_opt_check(struct evt_options *opt, uint64_t nb_queues);
 int pipeline_test_setup(struct evt_test *test, struct evt_options *opt);
 int pipeline_mempool_setup(struct evt_test *test, struct evt_options *opt);
+void pipeline_opt_dump(struct evt_options *opt, uint8_t nb_queues);
 void pipeline_test_destroy(struct evt_test *test, struct evt_options *opt);
 void pipeline_mempool_destroy(struct evt_test *test, struct evt_options *opt);
 
-- 
2.14.1

[dpdk-dev] [PATCH v2 05/12] app/eventdev: add perf ethport setup and destroy

[Pavan Nikhilesh]

Add common ethdev port setup and destroy along with event dev destroy.

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/test_pipeline_common.c | 98 
 app/test-eventdev/test_pipeline_common.h |  3 +
 2 files changed, 101 insertions(+)

diff --git a/app/test-eventdev/test_pipeline_common.c 
b/app/test-eventdev/test_pipeline_common.c
index d2ffcbe08..eb3ab6d44 100644
--- a/app/test-eventdev/test_pipeline_common.c
+++ b/app/test-eventdev/test_pipeline_common.c
@@ -116,6 +116,104 @@ pipeline_opt_check(struct evt_options *opt, uint64_t 
nb_queues)
return 0;
 }
 
+#define NB_RX_DESC 128
+#define NB_TX_DESC 512
+int
+pipeline_ethdev_setup(struct evt_test *test, struct evt_options *opt)
+{
+   int i;
+   uint8_t nb_queues = 1;
+   uint8_t mt_state = 0;
+   struct test_pipeline *t = evt_test_priv(test);
+   struct rte_eth_conf port_conf = {
+   .rxmode = {
+   .mq_mode = ETH_MQ_RX_RSS,
+   .max_rx_pkt_len = ETHER_MAX_LEN,
+   .split_hdr_size = 0,
+   .header_split   = 0,
+   .hw_ip_checksum = 0,
+   .hw_vlan_filter = 0,
+   .hw_vlan_strip  = 0,
+   .hw_vlan_extend = 0,
+   .jumbo_frame= 0,
+   .hw_strip_crc   = 1,
+   },
+   .rx_adv_conf = {
+   .rss_conf = {
+   .rss_key = NULL,
+   .rss_hf = ETH_RSS_IP,
+   },
+   },
+   };
+
+   RTE_SET_USED(opt);
+   if (!rte_eth_dev_count()) {
+   evt_err("No ethernet ports found.\n");
+   return -ENODEV;
+   }
+
+   for (i = 0; i < rte_eth_dev_count(); i++) {
+   struct rte_eth_dev_info dev_info;
+
+   memset(&dev_info, 0, sizeof(struct rte_eth_dev_info));
+   rte_eth_dev_info_get(i, &dev_info);
+   mt_state = !(dev_info.tx_offload_capa &
+   DEV_TX_OFFLOAD_MT_LOCKFREE);
+
+   if (rte_eth_dev_configure(i, nb_queues, nb_queues,
+   &port_conf)
+   < 0) {
+   evt_err("Failed to configure eth port [%d]\n", i);
+   return -EINVAL;
+   }
+
+   if (rte_eth_rx_queue_setup(i, 0, NB_RX_DESC,
+   rte_socket_id(), NULL, t->pool) < 0) {
+   evt_err("Failed to setup eth port [%d] rx_queue: %d.\n",
+   i, 0);
+   return -EINVAL;
+   }
+   if (rte_eth_tx_queue_setup(i, 0, NB_TX_DESC,
+   rte_socket_id(), NULL) < 0) {
+   evt_err("Failed to setup eth port [%d] tx_queue: %d.\n",
+   i, 0);
+   return -EINVAL;
+   }
+
+   t->mt_unsafe |= mt_state;
+   t->tx_buf[i] =
+   rte_malloc(NULL, RTE_ETH_TX_BUFFER_SIZE(BURST_SIZE), 0);
+   if (t->tx_buf[i] == NULL)
+   rte_panic("Unable to allocate Tx buffer memory.");
+   rte_eth_promiscuous_enable(i);
+   }
+
+   return 0;
+}
+
+void
+pipeline_ethdev_destroy(struct evt_test *test, struct evt_options *opt)
+{
+   int i;
+   RTE_SET_USED(test);
+   RTE_SET_USED(opt);
+
+   for (i = 0; i < rte_eth_dev_count(); i++) {
+   rte_event_eth_rx_adapter_stop(i);
+   rte_eth_dev_stop(i);
+   rte_eth_dev_close(i);
+   }
+}
+
+void
+pipeline_eventdev_destroy(struct evt_test *test, struct evt_options *opt)
+{
+   RTE_SET_USED(test);
+
+   rte_event_dev_stop(opt->dev_id);
+   rte_event_dev_close(opt->dev_id);
+}
+
 int
 pipeline_mempool_setup(struct evt_test *test, struct evt_options *opt)
 {
diff --git a/app/test-eventdev/test_pipeline_common.h 
b/app/test-eventdev/test_pipeline_common.h
index e709a1000..204033a01 100644
--- a/app/test-eventdev/test_pipeline_common.h
+++ b/app/test-eventdev/test_pipeline_common.h
@@ -81,9 +81,12 @@ struct test_pipeline {
 int pipeline_test_result(struct evt_test *test, struct evt_options *opt);
 int pipeline_opt_check(struct evt_options *opt, uint64_t nb_queues);
 int pipeline_test_setup(struct evt_test *test, struct evt_options *opt);
+int pipeline_ethdev_setup(struct evt_test *test, struct evt_options *opt);
 int pipeline_mempool_setup(struct evt_test *test, struct evt_options *opt);
 void pipeline_opt_dump(struct evt_options *opt, uint8_t nb_queues);
 void pipeline_test_destroy(struct evt_test *test, struct evt_options *opt);
+void pipeline_eventdev_destroy(struct evt_test *test, struct evt_options *opt);
+void pipeline_e

[dpdk-dev] [PATCH v2 06/12] app/eventdev: add event port setup and Rx adapter setup

[Pavan Nikhilesh]

Setup one port per worker and link to all queues and setup producer port
based on Rx adapter capabilities.

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/test_pipeline_common.c | 102 +++
 app/test-eventdev/test_pipeline_common.h |   4 ++
 2 files changed, 106 insertions(+)

diff --git a/app/test-eventdev/test_pipeline_common.c 
b/app/test-eventdev/test_pipeline_common.c
index eb3ab6d44..df7521453 100644
--- a/app/test-eventdev/test_pipeline_common.c
+++ b/app/test-eventdev/test_pipeline_common.c
@@ -191,6 +191,108 @@ pipeline_ethdev_setup(struct evt_test *test, struct 
evt_options *opt)
return 0;
 }
 
+int
+pipeline_event_port_setup(struct evt_test *test, struct evt_options *opt,
+   uint16_t nb_queues, const struct rte_event_port_conf p_conf)
+{
+   int ret;
+   uint8_t port;
+   struct test_pipeline *t = evt_test_priv(test);
+
+
+   /* setup one port per worker, linking to all queues */
+   for (port = 0; port < evt_nr_active_lcores(opt->wlcores); port++) {
+   struct worker_data *w = &t->worker[port];
+
+   w->dev_id = opt->dev_id;
+   w->port_id = port;
+   w->t = t;
+   w->processed_pkts = 0;
+
+   ret = rte_event_port_setup(opt->dev_id, port, &p_conf);
+   if (ret) {
+   evt_err("failed to setup port %d", port);
+   return ret;
+   }
+
+   ret = rte_event_port_link(opt->dev_id, port, NULL, NULL, 0);
+   if (ret != nb_queues) {
+   evt_err("failed to link all queues to port %d", port);
+   return -EINVAL;
+   }
+   }
+
+   return 0;
+}
+
+int
+pipeline_event_rx_adapter_setup(struct evt_options *opt, uint8_t stride,
+   struct rte_event_port_conf prod_conf)
+{
+   int ret = 0;
+   uint16_t prod;
+   struct rte_event_eth_rx_adapter_queue_conf queue_conf;
+
+   memset(&queue_conf, 0,
+   sizeof(struct rte_event_eth_rx_adapter_queue_conf));
+   queue_conf.ev.sched_type = opt->sched_type_list[0];
+   for (prod = 0; prod < rte_eth_dev_count(); prod++) {
+   uint32_t cap;
+
+   ret = rte_event_eth_rx_adapter_caps_get(opt->dev_id,
+   prod, &cap);
+   if (ret) {
+   evt_err("failed to get event rx adapter[%d]"
+   " capabilities",
+   opt->dev_id);
+   return ret;
+   }
+   queue_conf.ev.queue_id = prod * stride;
+   ret = rte_event_eth_rx_adapter_create(prod, opt->dev_id,
+   &prod_conf);
+   if (ret) {
+   evt_err("failed to create rx adapter[%d]", prod);
+   return ret;
+   }
+   ret = rte_event_eth_rx_adapter_queue_add(prod, prod, -1,
+   &queue_conf);
+   if (ret) {
+   evt_err("failed to add rx queues to adapter[%d]", prod);
+   return ret;
+   }
+
+   if (!(cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT)) {
+   uint32_t service_id;
+
+   rte_event_eth_rx_adapter_service_id_get(prod,
+   &service_id);
+   ret = evt_service_setup(service_id);
+   if (ret) {
+   evt_err("Failed to setup service core"
+   " for Rx adapter\n");
+   return ret;
+   }
+   }
+
+   ret = rte_eth_dev_start(prod);
+   if (ret) {
+   evt_err("Ethernet dev [%d] failed to start."
+   " Using synthetic producer", prod);
+   return ret;
+   }
+
+   ret = rte_event_eth_rx_adapter_start(prod);
+   if (ret) {
+   evt_err("Rx adapter[%d] start failed", prod);
+   return ret;
+   }
+   printf("%s: Port[%d] using Rx adapter[%d] started\n", __func__,
+   prod, prod);
+   }
+
+   return ret;
+}
+
 void
 pipeline_ethdev_destroy(struct evt_test *test, struct evt_options *opt)
 {
diff --git a/app/test-eventdev/test_pipeline_common.h 
b/app/test-eventdev/test_pipeline_common.h
index 204033a01..412c6095e 100644
--- a/app/test-eventdev/test_pipeline_common.h
+++ b/app/test-eventdev/test_pipeline_common.h
@@ -82,7 +82,11 @@ int pipeline_test_result(struct evt_test *test, struct 
evt_options *opt);
 int pipeline_opt_check(struct evt_options *opt, uint64_t nb_queues);
 int pipeline_test_setup(struct evt_test *test, s

[dpdk-dev] [PATCH v2 08/12] app/eventdev: add pipeline queue test

[Pavan Nikhilesh]

This is a pipeline queue test case that aims at testing the following:
1. Measure the end-to-end performance of an event dev with a ethernet dev.
2. Maintain packet ordering from Rx to Tx.

The pipeline queue test configures the eventdev with Q queues and P ports,
where Q is (nb_ethdev * nb_stages) + nb_ethdev and P is nb_workers.

The user can choose the number of workers and number of stages through the
--wlcores and the --stlist application command line arguments respectively.
The probed ethernet devices act as producer(s) for this application.

The ethdevs are configured as event Rx adapters that enables them to
injects events to eventdev based the first stage schedule type list
requested by the user through --stlist the command line argument.

Based on the number of stages to process(selected through --stlist),
the application forwards the event to next upstream queue and when it
reaches last stage in the pipeline if the event type is ATOMIC it is
enqueued onto ethdev Tx queue else to maintain ordering the event type is
set to ATOMIC and enqueued onto the last stage queue.
On packet Tx, application increments the number events processed and print
periodically in one second to get the number of events processed in one
second.

Note: The --prod_type_ethdev is mandatory for running the application.

Example command to run pipeline queue test:
sudo build/app/dpdk-test-eventdev -c 0xf -s 0x8 --vdev=event_sw0 -- \
--test=pipeline_queue --wlcore=1 --prod_type_ethdev --stlist=ao

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/Makefile  |   1 +
 app/test-eventdev/test_pipeline_queue.c | 193 
 2 files changed, 194 insertions(+)
 create mode 100644 app/test-eventdev/test_pipeline_queue.c

diff --git a/app/test-eventdev/Makefile b/app/test-eventdev/Makefile
index f2fb665d8..30bebfb2f 100644
--- a/app/test-eventdev/Makefile
+++ b/app/test-eventdev/Makefile
@@ -52,5 +52,6 @@ SRCS-y += test_perf_queue.c
 SRCS-y += test_perf_atq.c
 
 SRCS-y += test_pipeline_common.c
+SRCS-y += test_pipeline_queue.c
 
 include $(RTE_SDK)/mk/rte.app.mk
diff --git a/app/test-eventdev/test_pipeline_queue.c 
b/app/test-eventdev/test_pipeline_queue.c
new file mode 100644
index 0..851027cb7
--- /dev/null
+++ b/app/test-eventdev/test_pipeline_queue.c
@@ -0,0 +1,193 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) Cavium, Inc 2017.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Cavium, Inc nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "test_pipeline_common.h"
+
+/* See http://dpdk.org/doc/guides/tools/testeventdev.html for test details */
+
+static __rte_always_inline int
+pipeline_queue_nb_event_queues(struct evt_options *opt)
+{
+   uint16_t eth_count = rte_eth_dev_count();
+
+   return (eth_count * opt->nb_stages) + eth_count;
+}
+
+static int
+worker_wrapper(void *arg)
+{
+   RTE_SET_USED(arg);
+   rte_panic("invalid worker\n");
+}
+
+static int
+pipeline_queue_launch_lcores(struct evt_test *test, struct evt_options *opt)
+{
+   return pipeline_launch_lcores(test, opt, worker_wrapper);
+}
+
+static int
+pipeline_queue_eventdev_setup(struct evt_test *test, struct evt_options *opt)
+{
+   int ret;
+   int nb_ports;
+   int nb_queues;
+   int nb_stages = opt->nb_stages;
+   uint8_t queue;
+   struct rte_event_dev_info info;
+
+   nb_ports = evt_nr_active_lcores(opt->wlcores);
+   nb_queues = rte_eth_dev_count() * (nb_stages);
+   nb_queues += rte_eth_dev

[dpdk-dev] [PATCH v2 07/12] app/eventdev: launch pipeline lcores

[Pavan Nikhilesh]

The event master lcore's test termination and the logic to print the mpps
are common for the queue and all types queue test.

Move them as the common function.

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/test_pipeline_common.c | 64 
 app/test-eventdev/test_pipeline_common.h |  2 +
 2 files changed, 66 insertions(+)

diff --git a/app/test-eventdev/test_pipeline_common.c 
b/app/test-eventdev/test_pipeline_common.c
index df7521453..9a70943b6 100644
--- a/app/test-eventdev/test_pipeline_common.c
+++ b/app/test-eventdev/test_pipeline_common.c
@@ -65,6 +65,70 @@ pipeline_opt_dump(struct evt_options *opt, uint8_t nb_queues)
evt_dump_producer_type(opt);
 }
 
+static inline uint64_t
+processed_pkts(struct test_pipeline *t)
+{
+   uint8_t i;
+   uint64_t total = 0;
+
+   rte_smp_rmb();
+   for (i = 0; i < t->nb_workers; i++)
+   total += t->worker[i].processed_pkts;
+
+   return total;
+}
+
+int
+pipeline_launch_lcores(struct evt_test *test, struct evt_options *opt,
+   int (*worker)(void *))
+{
+   int ret, lcore_id;
+   struct test_pipeline *t = evt_test_priv(test);
+
+   int port_idx = 0;
+   /* launch workers */
+   RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+   if (!(opt->wlcores[lcore_id]))
+   continue;
+
+   ret = rte_eal_remote_launch(worker,
+&t->worker[port_idx], lcore_id);
+   if (ret) {
+   evt_err("failed to launch worker %d", lcore_id);
+   return ret;
+   }
+   port_idx++;
+   }
+
+   uint64_t perf_cycles = rte_get_timer_cycles();
+   const uint64_t perf_sample = rte_get_timer_hz();
+
+   static float total_mpps;
+   static uint64_t samples;
+
+   uint64_t prev_pkts = 0;
+
+   while (t->done == false) {
+   const uint64_t new_cycles = rte_get_timer_cycles();
+
+   if ((new_cycles - perf_cycles) > perf_sample) {
+   const uint64_t curr_pkts = processed_pkts(t);
+
+   float mpps = (float)(curr_pkts - prev_pkts)/100;
+
+   prev_pkts = curr_pkts;
+   perf_cycles = new_cycles;
+   total_mpps += mpps;
+   ++samples;
+   printf(CLGRN"\r%.3f mpps avg %.3f mpps"CLNRM,
+   mpps, total_mpps/samples);
+   fflush(stdout);
+   }
+   }
+   printf("\n");
+   return 0;
+}
+
 int
 pipeline_opt_check(struct evt_options *opt, uint64_t nb_queues)
 {
diff --git a/app/test-eventdev/test_pipeline_common.h 
b/app/test-eventdev/test_pipeline_common.h
index 412c6095e..26d265a3d 100644
--- a/app/test-eventdev/test_pipeline_common.h
+++ b/app/test-eventdev/test_pipeline_common.h
@@ -87,6 +87,8 @@ int pipeline_event_rx_adapter_setup(struct evt_options *opt, 
uint8_t stride,
 int pipeline_mempool_setup(struct evt_test *test, struct evt_options *opt);
 int pipeline_event_port_setup(struct evt_test *test, struct evt_options *opt,
uint16_t nb_queues, const struct rte_event_port_conf p_conf);
+int pipeline_launch_lcores(struct evt_test *test, struct evt_options *opt,
+   int (*worker)(void *));
 void pipeline_opt_dump(struct evt_options *opt, uint8_t nb_queues);
 void pipeline_test_destroy(struct evt_test *test, struct evt_options *opt);
 void pipeline_eventdev_destroy(struct evt_test *test, struct evt_options *opt);
-- 
2.14.1

[dpdk-dev] [PATCH v2 09/12] app/eventdev: add pipeline queue worker functions

[Pavan Nikhilesh]

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/test_pipeline_common.h |  80 +++
 app/test-eventdev/test_pipeline_queue.c  | 367 ++-
 2 files changed, 446 insertions(+), 1 deletion(-)

diff --git a/app/test-eventdev/test_pipeline_common.h 
b/app/test-eventdev/test_pipeline_common.h
index 26d265a3d..009b20a7d 100644
--- a/app/test-eventdev/test_pipeline_common.h
+++ b/app/test-eventdev/test_pipeline_common.h
@@ -78,6 +78,86 @@ struct test_pipeline {
uint8_t sched_type_list[EVT_MAX_STAGES] __rte_cache_aligned;
 } __rte_cache_aligned;
 
+#define BURST_SIZE 16
+
+static __rte_always_inline void
+pipeline_fwd_event(struct rte_event *ev, uint8_t sched)
+{
+   ev->event_type = RTE_EVENT_TYPE_CPU;
+   ev->op = RTE_EVENT_OP_FORWARD;
+   ev->sched_type = sched;
+}
+
+static __rte_always_inline void
+pipeline_event_enqueue(const uint8_t dev, const uint8_t port,
+   struct rte_event *ev)
+{
+   while (rte_event_enqueue_burst(dev, port, ev, 1) != 1)
+   rte_pause();
+}
+
+static __rte_always_inline void
+pipeline_event_enqueue_burst(const uint8_t dev, const uint8_t port,
+   struct rte_event *ev, const uint16_t nb_rx)
+{
+   uint16_t enq;
+
+   enq = rte_event_enqueue_burst(dev, port, ev, nb_rx);
+   while (enq < nb_rx) {
+   enq += rte_event_enqueue_burst(dev, port,
+   ev + enq, nb_rx - enq);
+   }
+}
+
+static __rte_always_inline void
+pipeline_tx_pkt_safe(struct rte_mbuf *mbuf)
+{
+   while (rte_eth_tx_burst(mbuf->port, 0, &mbuf, 1) != 1)
+   rte_pause();
+}
+
+static __rte_always_inline void
+pipeline_tx_pkt_unsafe(struct rte_mbuf *mbuf, struct test_pipeline *t)
+{
+   rte_spinlock_t *lk = &t->tx_lk[mbuf->port];
+
+   rte_spinlock_lock(lk);
+   pipeline_tx_pkt_safe(mbuf);
+   rte_spinlock_unlock(lk);
+}
+
+static __rte_always_inline void
+pipeline_tx_unsafe_burst(struct rte_mbuf *mbuf, struct test_pipeline *t)
+{
+   uint16_t port = mbuf->port;
+   rte_spinlock_t *lk = &t->tx_lk[port];
+
+   rte_spinlock_lock(lk);
+   rte_eth_tx_buffer(port, 0, t->tx_buf[port], mbuf);
+   rte_spinlock_unlock(lk);
+}
+
+static __rte_always_inline void
+pipeline_tx_flush(struct test_pipeline *t, const uint8_t nb_ports)
+{
+   int i;
+   rte_spinlock_t *lk;
+
+   for (i = 0; i < nb_ports; i++) {
+   lk = &t->tx_lk[i];
+
+   rte_spinlock_lock(lk);
+   rte_eth_tx_buffer_flush(i, 0, t->tx_buf[i]);
+   rte_spinlock_unlock(lk);
+   }
+}
+
+static inline int
+pipeline_nb_event_ports(struct evt_options *opt)
+{
+   return evt_nr_active_lcores(opt->wlcores);
+}
+
 int pipeline_test_result(struct evt_test *test, struct evt_options *opt);
 int pipeline_opt_check(struct evt_options *opt, uint64_t nb_queues);
 int pipeline_test_setup(struct evt_test *test, struct evt_options *opt);
diff --git a/app/test-eventdev/test_pipeline_queue.c 
b/app/test-eventdev/test_pipeline_queue.c
index 851027cb7..f89adc4b4 100644
--- a/app/test-eventdev/test_pipeline_queue.c
+++ b/app/test-eventdev/test_pipeline_queue.c
@@ -42,10 +42,375 @@ pipeline_queue_nb_event_queues(struct evt_options *opt)
return (eth_count * opt->nb_stages) + eth_count;
 }
 
+static int
+pipeline_queue_worker_single_stage_safe(void *arg)
+{
+   struct worker_data *w  = arg;
+   struct test_pipeline *t = w->t;
+   const uint8_t dev = w->dev_id;
+   const uint8_t port = w->port_id;
+   struct rte_event ev;
+
+   while (t->done == false) {
+   uint16_t event = rte_event_dequeue_burst(dev, port, &ev, 1, 0);
+
+   if (!event) {
+   rte_pause();
+   continue;
+   }
+
+   if (ev.sched_type == RTE_SCHED_TYPE_ATOMIC) {
+   pipeline_tx_pkt_safe(ev.mbuf);
+   w->processed_pkts++;
+   } else {
+   ev.queue_id++;
+   pipeline_fwd_event(&ev, RTE_SCHED_TYPE_ATOMIC);
+   pipeline_event_enqueue(dev, port, &ev);
+   }
+   }
+
+   return 0;
+}
+
+static int
+pipeline_queue_worker_single_stage_unsafe(void *arg)
+{
+   struct worker_data *w  = arg;
+   struct test_pipeline *t = w->t;
+   const uint8_t dev = w->dev_id;
+   const uint8_t port = w->port_id;
+   struct rte_event ev;
+
+   while (t->done == false) {
+   uint16_t event = rte_event_dequeue_burst(dev, port, &ev, 1, 0);
+
+   if (!event) {
+   rte_pause();
+   continue;
+   }
+
+   if (ev.sched_type == RTE_SCHED_TYPE_ATOMIC) {
+   pipeline_tx_pkt_unsafe(ev.mbuf, t);
+   w->processed_pkts++;
+   } else {
+   ev.queue_id++;
+   

[dpdk-dev] [PATCH v2 10/12] app/eventdev: add pipeline atq test

[Pavan Nikhilesh]

This is a pipeline test case that aims at testing the following with
``all types queue`` eventdev scheme.
1. Measure the end-to-end performance of an event dev with a ethernet dev.
2. Maintain packet ordering from Rx to Tx.

The atq queue test functions as same as ``pipeline_queue`` test.
The difference is, It uses, ``all type queue scheme`` instead of separate
queues for each stage and thus reduces the number of queues required to
realize the use case.

Note: The --prod_type_ethdev is mandatory for running the application.

Example command to run pipeline atq test:
sudo build/app/dpdk-test-eventdev -c 0xf -s 0x8 --vdev=event_sw0 -- \
--test=pipeline_atq --wlcore=1 --prod_type_ethdev --stlist=ao

Signed-off-by: Pavan Nikhilesh 
---
 app/test-eventdev/Makefile|   1 +
 app/test-eventdev/test_pipeline_atq.c | 187 ++
 2 files changed, 188 insertions(+)
 create mode 100644 app/test-eventdev/test_pipeline_atq.c

diff --git a/app/test-eventdev/Makefile b/app/test-eventdev/Makefile
index 30bebfb2f..6e3e36fb8 100644
--- a/app/test-eventdev/Makefile
+++ b/app/test-eventdev/Makefile
@@ -53,5 +53,6 @@ SRCS-y += test_perf_atq.c
 
 SRCS-y += test_pipeline_common.c
 SRCS-y += test_pipeline_queue.c
+SRCS-y += test_pipeline_atq.c
 
 include $(RTE_SDK)/mk/rte.app.mk
diff --git a/app/test-eventdev/test_pipeline_atq.c 
b/app/test-eventdev/test_pipeline_atq.c
new file mode 100644
index 0..f625b04b1
--- /dev/null
+++ b/app/test-eventdev/test_pipeline_atq.c
@@ -0,0 +1,187 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright (C) Cavium, Inc 2017.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Cavium, Inc nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "test_pipeline_common.h"
+
+/* See http://dpdk.org/doc/guides/tools/testeventdev.html for test details */
+
+static __rte_always_inline int
+pipeline_atq_nb_event_queues(struct evt_options *opt)
+{
+   uint16_t eth_count = rte_eth_dev_count();
+
+   return (eth_count * opt->nb_stages);
+}
+
+static int
+worker_wrapper(void *arg)
+{
+   RTE_SET_USED(arg);
+   rte_panic("invalid worker\n");
+}
+
+static int
+pipeline_atq_launch_lcores(struct evt_test *test, struct evt_options *opt)
+{
+   return pipeline_launch_lcores(test, opt, worker_wrapper);
+}
+
+static int
+pipeline_atq_eventdev_setup(struct evt_test *test, struct evt_options *opt)
+{
+   int ret;
+   int nb_ports;
+   int nb_queues;
+   int nb_stages = opt->nb_stages;
+   uint8_t queue;
+   struct rte_event_dev_info info;
+
+   nb_ports = evt_nr_active_lcores(opt->wlcores);
+   nb_queues = rte_eth_dev_count() * (nb_stages);
+
+   rte_event_dev_info_get(opt->dev_id, &info);
+
+   const struct rte_event_dev_config config = {
+   .nb_event_queues = nb_queues,
+   .nb_event_ports = nb_ports,
+   .nb_events_limit  = info.max_num_events,
+   .nb_event_queue_flows = opt->nb_flows,
+   .nb_event_port_dequeue_depth =
+   info.max_event_port_dequeue_depth,
+   .nb_event_port_enqueue_depth =
+   info.max_event_port_enqueue_depth,
+   };
+   ret = rte_event_dev_configure(opt->dev_id, &config);
+   if (ret) {
+   evt_err("failed to configure eventdev %d", opt->dev_id);
+   return ret;
+   }
+
+   struct rte_event_queue_conf q_conf = {
+