Re: [dpdk-dev] [PATCH] vhost: fix return value on enqueue path

[Maxime Coquelin]

On 09/06/2018 06:59 AM, Tiwei Bie wrote:

Fixes: 62250c1d0978 ("vhost: extract split ring handling from Rx and Tx 
functions")
Fixes: a922401f35cc ("vhost: add Rx support for packed ring")
Cc: sta...@dpdk.org

Signed-off-by: Tiwei Bie 
---
  lib/librte_vhost/virtio_net.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)


Applied to dpdk-next-virtio/master.

Thanks,
Maxime

Re: [dpdk-dev] [PATCH] examples/vhost_crypto: add multi-core support

[Maxime Coquelin]

Hi Fan,

On 06/22/2018 02:36 PM, Fan Zhang wrote:

Originally vhost_crypto sample application only supports single
core. This patch adds the multi-core support with more flexible
options.

Signed-off-by: Fan Zhang 
---
  doc/guides/sample_app_ug/vhost_crypto.rst |  26 +-
  examples/vhost_crypto/main.c  | 480 +-
  2 files changed, 282 insertions(+), 224 deletions(-)




Sorry for the late review.
The patch looks good to me:

Reviewed-by: Maxime Coquelin 

Maxime

[dpdk-dev] Using example flow_filtering

[Matteo Lanzuisi]

Hi all,

maybe a bug or something I'm doing wrong: I'm using the example 
flow_filtering on a RedHat 7.5, kernel 3.10.0-862.6.3.el7.x86_64 with 
i40e and X710.


DPDK is 18.08 and configuration is x86_64-native-linuxapp-gcc

I changed the SRC_IP and DST_IP this way

#define SRC_IP ((83<<24) + (175<<16) + (7<<8) + 228) /* src ip = 
83.175.7.228 */
#define DEST_IP ((83<<24) + (175<<16) + (7<<8) + 226) /* dest ip = 
83.175.7.226 */


for test purpose and set EMPTY_MASK to both.

If I understood well, putting EMPTY_MASK on both, all incoming traffic 
is going to be sent to queue 1 (selected_queue) but all I have is that 
all packets are sent to queue 0 (MACs are 00:00:00:00:00:00 in my sample 
capture)


src=00:00:00:00:00:00 - dst=00:00:00:00:00:00 - queue=0x0
src=00:00:00:00:00:00 - dst=00:00:00:00:00:00 - queue=0x0
src=00:00:00:00:00:00 - dst=00:00:00:00:00:00 - queue=0x0
src=00:00:00:00:00:00 - dst=00:00:00:00:00:00 - queue=0x0

Am I doing something wrong?

Thank you and regards.

Matteo

Re: [dpdk-dev] [PATCH v4] net/i40e: add interface to choose latest vector path

[Zhang, Qi Z]

> -Original Message-
> From: Li, Xiaoyun
> Sent: Monday, September 10, 2018 6:18 PM
> To: Xing, Beilei ; Zhang, Qi Z 
> Cc: dev@dpdk.org; Yang, Zhiyong ; Richardson,
> Bruce ; Hunt, David ; Li,
> Xiaoyun 
> Subject: [PATCH v4] net/i40e: add interface to choose latest vector path
> 
> Right now, vector path is limited to only use on later platform.
> This patch adds a devarg use-latest-vec to allow the users to use the latest
> vector path that the platform supported. Namely, using AVX2 vector path on
> broadwell is possible.
> 
> Signed-off-by: Xiaoyun Li 
> ---
> v4:
>  * Polish the codes.
> v3:
>  * Polish the doc and commit log.
> v2:
>  * Correct the calling of the wrong function last time.
>  * Fix seg fault bug.
> ---
>  doc/guides/nics/i40e.rst   |   8 ++
>  doc/guides/rel_notes/release_18_11.rst |   4 +
>  drivers/net/i40e/i40e_ethdev.c |  46 ++-
>  drivers/net/i40e/i40e_ethdev.h |   3 +
>  drivers/net/i40e/i40e_rxtx.c   | 103 -
>  5 files changed, 128 insertions(+), 36 deletions(-)
> 
> diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index
> 65d87f869..643e6a062 100644
> --- a/doc/guides/nics/i40e.rst
> +++ b/doc/guides/nics/i40e.rst
> @@ -163,6 +163,14 @@ Runtime Config Options
>Currently hot-plugging of representor ports is not supported so all 
> required
>representors must be specified on the creation of the PF.
> 
> +- ``Use latest vector`` (default ``disable``)
> +
> +  Vector path was limited to use only on later platform. But users may
> + want the  latest vector path. For example, VPP users may want to use
> + AVX2 vector path on HSW/BDW  because it can get better perf. So
> + ``devargs`` parameter ``use-latest-vec`` is  introduced, for example::
> +-w 84:00.0,use-latest-vec=1
> +
>  Driver compilation and testing
>  --
> 
> diff --git a/doc/guides/rel_notes/release_18_11.rst
> b/doc/guides/rel_notes/release_18_11.rst
> index 3ae6b3f58..34af591a2 100644
> --- a/doc/guides/rel_notes/release_18_11.rst
> +++ b/doc/guides/rel_notes/release_18_11.rst
> @@ -54,6 +54,10 @@ New Features
>   Also, make sure to start the actual text at the margin.
>   =
> 
> +* **Added a devarg to use the latest vector path.**
> +  A new devarg ``use-latest-vec`` was introduced to allow users to
> +choose
> +  the latest vector path that the platform supported. For example, VPP
> +users
> +  can use AVX2 vector path on BDW/HSW to get better performance.
> 
>  API Changes
>  ---
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 85a6a867f..72377d0b6 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -44,6 +44,7 @@
>  #define ETH_I40E_FLOATING_VEB_LIST_ARG   "floating_veb_list"
>  #define ETH_I40E_SUPPORT_MULTI_DRIVER"support-multi-driver"
>  #define ETH_I40E_QUEUE_NUM_PER_VF_ARG"queue-num-per-vf"
> +#define ETH_I40E_USE_LATEST_VEC  "use-latest-vec"
> 
>  #define I40E_CLEAR_PXE_WAIT_MS 200
> 
> @@ -408,6 +409,7 @@ static const char *const valid_keys[] = {
>   ETH_I40E_FLOATING_VEB_LIST_ARG,
>   ETH_I40E_SUPPORT_MULTI_DRIVER,
>   ETH_I40E_QUEUE_NUM_PER_VF_ARG,
> + ETH_I40E_USE_LATEST_VEC,
>   NULL};
> 
>  static const struct rte_pci_id pci_id_i40e_map[] = { @@ -1201,6 +1203,46 @@
> i40e_aq_debug_write_global_register(struct i40e_hw *hw,
>   return i40e_aq_debug_write_register(hw, reg_addr, reg_val,
> cmd_details);  }
> 
> +static int
> +i40e_parse_latest_vec(struct rte_eth_dev *dev) {
> + struct i40e_adapter *ad =
> + I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
> + int kvargs_count, use_latest_vec;
> + struct rte_kvargs *kvlist;
> +
> + ad->use_latest_vec = false;
> +
> + if (!dev->device->devargs)
> + return 0;
> +
> + kvlist = rte_kvargs_parse(dev->device->devargs->args, valid_keys);
> + if (!kvlist)
> + return -EINVAL;
> +
> + kvargs_count = rte_kvargs_count(kvlist, ETH_I40E_USE_LATEST_VEC);
> + if (!kvargs_count) {
> + rte_kvargs_free(kvlist);
> + return 0;
> + }
> +
> + if (kvargs_count > 1)
> + PMD_DRV_LOG(WARNING, "More than one argument \"%s\" and
> only "
> + "the first one is used !",
> + ETH_I40E_USE_LATEST_VEC);
> +
> + use_latest_vec = atoi((&kvlist->pairs[0])->value);
> +
> + rte_kvargs_free(kvlist);
> +
> + if (use_latest_vec != 0 && use_latest_vec != 1)
> + PMD_DRV_LOG(WARNING, "Value should be 0 or 1, set it as 1!");
> +
> + ad->use_latest_vec = (bool)use_latest_vec;
> +
> + return 0;
> +}
> +
>  static int
>  eth_i40e_dev_init(struct rte_eth_dev *dev, void *init_params __rte_unused)
> { @@ -1263,6 +1305,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev, void
> *init_params 

Re: [dpdk-dev] [PATCH v4] net/i40e: add interface to choose latest vector path

[Zhang, Qi Z]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhang, Qi Z
> Sent: Wednesday, September 12, 2018 3:45 PM
> To: Li, Xiaoyun ; Xing, Beilei 
> Cc: dev@dpdk.org; Yang, Zhiyong ; Richardson,
> Bruce ; Hunt, David 
> Subject: Re: [dpdk-dev] [PATCH v4] net/i40e: add interface to choose latest
> vector path
> 
> 
> 
> > -Original Message-
> > From: Li, Xiaoyun
> > Sent: Monday, September 10, 2018 6:18 PM
> > To: Xing, Beilei ; Zhang, Qi Z
> > 
> > Cc: dev@dpdk.org; Yang, Zhiyong ; Richardson,
> > Bruce ; Hunt, David
> > ; Li, Xiaoyun 
> > Subject: [PATCH v4] net/i40e: add interface to choose latest vector
> > path
> >
> > Right now, vector path is limited to only use on later platform.
> > This patch adds a devarg use-latest-vec to allow the users to use the
> > latest vector path that the platform supported. Namely, using AVX2
> > vector path on broadwell is possible.
> >
> > Signed-off-by: Xiaoyun Li 
> > ---
> > v4:
> >  * Polish the codes.
> > v3:
> >  * Polish the doc and commit log.
> > v2:
> >  * Correct the calling of the wrong function last time.
> >  * Fix seg fault bug.
> > ---
> >  doc/guides/nics/i40e.rst   |   8 ++
> >  doc/guides/rel_notes/release_18_11.rst |   4 +
> >  drivers/net/i40e/i40e_ethdev.c |  46 ++-
> >  drivers/net/i40e/i40e_ethdev.h |   3 +
> >  drivers/net/i40e/i40e_rxtx.c   | 103 -
> >  5 files changed, 128 insertions(+), 36 deletions(-)
> >
> > diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index
> > 65d87f869..643e6a062 100644
> > --- a/doc/guides/nics/i40e.rst
> > +++ b/doc/guides/nics/i40e.rst
> > @@ -163,6 +163,14 @@ Runtime Config Options
> >Currently hot-plugging of representor ports is not supported so all
> required
> >representors must be specified on the creation of the PF.
> >
> > +- ``Use latest vector`` (default ``disable``)
> > +
> > +  Vector path was limited to use only on later platform. But users
> > + may want the  latest vector path. For example, VPP users may want to
> > + use
> > + AVX2 vector path on HSW/BDW  because it can get better perf. So
> > + ``devargs`` parameter ``use-latest-vec`` is  introduced, for example::
> > +-w 84:00.0,use-latest-vec=1
> > +
> >  Driver compilation and testing
> >  --
> >
> > diff --git a/doc/guides/rel_notes/release_18_11.rst
> > b/doc/guides/rel_notes/release_18_11.rst
> > index 3ae6b3f58..34af591a2 100644
> > --- a/doc/guides/rel_notes/release_18_11.rst
> > +++ b/doc/guides/rel_notes/release_18_11.rst
> > @@ -54,6 +54,10 @@ New Features
> >   Also, make sure to start the actual text at the margin.
> >   =
> >
> > +* **Added a devarg to use the latest vector path.**
> > +  A new devarg ``use-latest-vec`` was introduced to allow users to
> > +choose
> > +  the latest vector path that the platform supported. For example,
> > +VPP users
> > +  can use AVX2 vector path on BDW/HSW to get better performance.
> >
> >  API Changes
> >  ---
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 85a6a867f..72377d0b6 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -44,6 +44,7 @@
> >  #define ETH_I40E_FLOATING_VEB_LIST_ARG "floating_veb_list"
> >  #define ETH_I40E_SUPPORT_MULTI_DRIVER  "support-multi-driver"
> >  #define ETH_I40E_QUEUE_NUM_PER_VF_ARG  "queue-num-per-vf"
> > +#define ETH_I40E_USE_LATEST_VEC"use-latest-vec"
> >
> >  #define I40E_CLEAR_PXE_WAIT_MS 200
> >
> > @@ -408,6 +409,7 @@ static const char *const valid_keys[] = {
> > ETH_I40E_FLOATING_VEB_LIST_ARG,
> > ETH_I40E_SUPPORT_MULTI_DRIVER,
> > ETH_I40E_QUEUE_NUM_PER_VF_ARG,
> > +   ETH_I40E_USE_LATEST_VEC,
> > NULL};
> >
> >  static const struct rte_pci_id pci_id_i40e_map[] = { @@ -1201,6
> > +1203,46 @@ i40e_aq_debug_write_global_register(struct i40e_hw *hw,
> > return i40e_aq_debug_write_register(hw, reg_addr, reg_val,
> > cmd_details);  }
> >
> > +static int
> > +i40e_parse_latest_vec(struct rte_eth_dev *dev) {
> > +   struct i40e_adapter *ad =
> > +   I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
> > +   int kvargs_count, use_latest_vec;
> > +   struct rte_kvargs *kvlist;
> > +
> > +   ad->use_latest_vec = false;
> > +
> > +   if (!dev->device->devargs)
> > +   return 0;
> > +
> > +   kvlist = rte_kvargs_parse(dev->device->devargs->args, valid_keys);
> > +   if (!kvlist)
> > +   return -EINVAL;
> > +
> > +   kvargs_count = rte_kvargs_count(kvlist, ETH_I40E_USE_LATEST_VEC);
> > +   if (!kvargs_count) {
> > +   rte_kvargs_free(kvlist);
> > +   return 0;
> > +   }
> > +
> > +   if (kvargs_count > 1)
> > +   PMD_DRV_LOG(WARNING, "More than one argument \"%s\" and
> > only "
> > +   "the first one is used !",
> > +   E

Re: [dpdk-dev] [PATCH v5 01/11] net/virtio: vring init for packed queues

[Maxime Coquelin]

On 09/06/2018 08:19 PM, Jens Freimann wrote:

vq->vq_free_cnt = vq->vq_nentries;
memset(vq->vq_descx, 0, sizeof(struct vq_desc_extra) * vq->vq_nentries);
+   vq->vq_used_cons_idx = 0;
+   vq->vq_avail_idx = 0;
+   if (vtpci_packed_queue(vq->hw)) {
+   vring_desc_init_packed(vr, size);
+   } else {
+   vq->vq_desc_head_idx = 0;
+   vq->vq_desc_tail_idx = (uint16_t)(vq->vq_nentries - 1);
  
-	vring_desc_init(vr->desc, size);

+   vring_desc_init(vr->desc, size);
+   }


Maybe worth renaming to vring_desc_init_split() for consistency.

Maxime

Re: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while fiber link update

[Ilya Maximets]

On 12.09.2018 09:49, Zhang, Qi Z wrote:
> 
> 
>> -Original Message-
>> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
>> Sent: Monday, September 10, 2018 11:09 PM
>> To: Zhang, Qi Z ; dev@dpdk.org
>> Cc: Lu, Wenzhuo ; Ananyev, Konstantin
>> ; Laurent Hardy
>> ; Dai, Wei ;
>> sta...@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while fiber link
>> update
>>
>> On 04.09.2018 09:08, Zhang, Qi Z wrote:
>>> Hi Ilya:
>>>
 -Original Message-
 From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ilya Maximets
 Sent: Friday, August 31, 2018 8:40 PM
 To: dev@dpdk.org
 Cc: Lu, Wenzhuo ; Ananyev, Konstantin
 ; Laurent Hardy
 ; Dai, Wei ; Ilya
 Maximets ; sta...@dpdk.org
 Subject: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while fiber
 link update

 If the multispeed fiber link is in DOWN state, ixgbe_setup_link could
 take around a second of busy polling. This is highly inconvenient for
 the case where single thread periodically checks the link statuses.
 For example, OVS main thread periodically updates the link statuses
 and hangs for a really long time busy waiting on ixgbe_setup_link()
 for a DOWN fiber ports. For case with 3 down ports it hangs for a 3
 seconds and unable to do anything including packet processing.
 Fix that by shifting that workaround to a separate thread by alarm
 handler that will try to set up link if it is DOWN.
>>>
>>> Does that mean we will block the interrupt thread for 3 seconds?
>>
>> Three times for one second. Other work could be scheduled between.
>> IMHO, it's much better than blocking usual caller for 3 seconds.
>>
>>> Also, can we guarantee there will not be any race condition if we call
>> ixgbe_setup_link at another thread, the base code API is not assumed to be
>> thread-safe as I know.
>>
>> The only user of 'ixgbe_setup_link' is 'ixgbe_dev_start', but it could be 
>> called
>> only if device stopped. 'ixgbe_dev_stop' cancels the alarm.
>> Race with 'link_update' avoided by 'IXGBE_FLAG_NEED_LINK_CONFIG' flag.
> 
> I guess, it' not only about when ixgb_setup_link race with itself, but also 
> when it race with other APIs.
> Also the concern is, even in current version, we can prove there is no issue, 
> how can we guarantee we are safe for future base code update? It's not 
> designed as thread-safe.
> For my option, the change is risky.

In current implementation interrupt handler already calls the
'ixgbe_dev_link_update' which subsequently calls 'ixgbe_setup_link'
in our case if LSC interrupts enabled. So, my change makes the driver
even safer by moving 'ixgbe_setup_link' to the same interrupt thread.
Otherwise two threads (interrupts handler and the link status
checking thread) could call 'ixgbe_setup_link' simultaneously.

> 
> Btw, since ixgbe support LSC, it is not necessary for "single thread 
> periodically checks the link statuses", right?

In current implementation it will take at least 5 seconds (4 + 1)
for the interrupt handler to detect DOWN link state for ixgbe
multispeed fiber. This is too much for many real world cases.

> 
>>
>>>
>>> Regards
>>> Qi
>>>

 Fixes: c12d22f65b13 ("net/ixgbe: ensure link status is updated")
 CC: sta...@dpdk.org

 Signed-off-by: Ilya Maximets 
 ---
  drivers/net/ixgbe/ixgbe_ethdev.c | 43
 
  1 file changed, 32 insertions(+), 11 deletions(-)

 diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
 b/drivers/net/ixgbe/ixgbe_ethdev.c
 index 26b192737..a33b9a6e8 100644
 --- a/drivers/net/ixgbe/ixgbe_ethdev.c
 +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
 @@ -221,6 +221,8 @@ static int ixgbe_dev_interrupt_action(struct
 rte_eth_dev *dev,
  struct rte_intr_handle *handle);  static 
 void
 ixgbe_dev_interrupt_handler(void *param);  static void
 ixgbe_dev_interrupt_delayed_handler(void *param);
 +static void ixgbe_dev_setup_link_alarm_handler(void *param);
 +
  static int ixgbe_add_rar(struct rte_eth_dev *dev, struct ether_addr
 *mac_addr,
 uint32_t index, uint32_t pool);
  static void ixgbe_remove_rar(struct rte_eth_dev *dev, uint32_t
 index); @@
 -2791,6 +2793,8 @@ ixgbe_dev_stop(struct rte_eth_dev *dev)

PMD_INIT_FUNC_TRACE();

 +  rte_eal_alarm_cancel(ixgbe_dev_setup_link_alarm_handler, dev);
 +
/* disable interrupts */
ixgbe_disable_intr(hw);

 @@ -3969,6 +3973,25 @@ ixgbevf_check_link(struct ixgbe_hw *hw,
 ixgbe_link_speed *speed,
return ret_val;
  }

 +static void
 +ixgbe_dev_setup_link_alarm_handler(void *param) {
 +  struct rte_eth_dev *dev = (struct rte_eth_dev *)param;
 +  struct ixgbe_hw *hw =
 IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
 +  struct ixgbe_interrupt *intr =
 +  IXGBE_DEV_PRIVATE_TO_INTR(dev->data->

[dpdk-dev] [PATCH 1/2] app/testpmd: add a generic way for dumping packets

[Raslan Darawsheh]

verbosity for the received/sent packets is needed in all of the
forwarding engines so moving it to be in a separate function.

Signed-off-by: Raslan Darawsheh 
---
 app/test-pmd/Makefile  |   1 +
 app/test-pmd/testpmd.h |   2 +
 app/test-pmd/util.c| 143 +
 3 files changed, 146 insertions(+)
 create mode 100644 app/test-pmd/util.c

diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index 2b4d604..e2c7845 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -35,6 +35,7 @@ SRCS-y += csumonly.c
 SRCS-y += icmpecho.c
 SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
 SRCS-$(CONFIG_RTE_LIBRTE_BPF) += bpf_cmd.c
+SRCS-y += util.c
 
 ifeq ($(CONFIG_RTE_LIBRTE_PMD_SOFTNIC), y)
 SRCS-y += softnicfwd.c
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index a1f6614..a0d9ce1 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -743,6 +743,8 @@ int check_nb_rxq(queueid_t rxq);
 queueid_t get_allowed_max_nb_txq(portid_t *pid);
 int check_nb_txq(queueid_t txq);
 
+void dump_pkt_burst(struct fwd_stream *fs, struct rte_mbuf *pkts_burst[],
+   uint16_t nb_rx, int direction);
 /*
  * Work-around of a compilation error with ICC on invocations of the
  * rte_be_to_cpu_16() function.
diff --git a/app/test-pmd/util.c b/app/test-pmd/util.c
new file mode 100644
index 000..87cbbcd
--- /dev/null
+++ b/app/test-pmd/util.c
@@ -0,0 +1,143 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2018 Mellanox technology.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "testpmd.h"
+
+static inline void
+print_ether_addr(const char *what, struct ether_addr *eth_addr)
+{
+   char buf[ETHER_ADDR_FMT_SIZE];
+   ether_format_addr(buf, ETHER_ADDR_FMT_SIZE, eth_addr);
+   printf("%s%s", what, buf);
+}
+
+void
+dump_pkt_burst(struct fwd_stream *fs, struct rte_mbuf **pkts_burst,
+  uint16_t nb_pkts, int direction)
+{
+   struct rte_mbuf  *mb;
+   struct ether_hdr *eth_hdr;
+   uint16_t eth_type;
+   uint64_t ol_flags;
+   uint16_t i, packet_type;
+   uint16_t is_encapsulation;
+   char buf[256];
+   struct rte_net_hdr_lens hdr_lens;
+   uint32_t sw_packet_type;
+
+   printf("port %u/queue %u: %s %u packets\n",
+  direction ? fs->rx_port : fs->tx_port,
+  direction ? (unsigned int) fs->rx_queue :
+  (unsigned int) fs->tx_queue,
+  direction ? "received" : "sent",
+  (unsigned int) nb_pkts);
+   for (i = 0; i < nb_pkts; i++) {
+   mb = pkts_burst[i];
+   eth_hdr = rte_pktmbuf_mtod(mb, struct ether_hdr *);
+   eth_type = RTE_BE_TO_CPU_16(eth_hdr->ether_type);
+   ol_flags = mb->ol_flags;
+   packet_type = mb->packet_type;
+   is_encapsulation = RTE_ETH_IS_TUNNEL_PKT(packet_type);
+
+   print_ether_addr("  src=", ð_hdr->s_addr);
+   print_ether_addr(" - dst=", ð_hdr->d_addr);
+   printf(" - type=0x%04x - length=%u - nb_segs=%d",
+  eth_type, (unsigned int) mb->pkt_len,
+  (int)mb->nb_segs);
+   printf(" - RSS hash=0x%x", (unsigned int) mb->hash.rss);
+   printf(" - RSS queue=0x%x", (unsigned int) fs->rx_queue);
+   if (ol_flags & PKT_RX_FDIR) {
+   printf(" - FDIR matched ");
+   if (ol_flags & PKT_RX_FDIR_ID)
+   printf("ID=0x%x",
+  mb->hash.fdir.hi);
+   else if (ol_flags & PKT_RX_FDIR_FLX)
+   printf("flex bytes=0x%08x %08x",
+  mb->hash.fdir.hi, mb->hash.fdir.lo);
+   else
+   printf("hash=0x%x ID=0x%x ",
+  mb->hash.fdir.hash, mb->hash.fdir.id);
+   }
+   if (ol_flags & PKT_RX_TIMESTAMP)
+   printf(" - timestamp %"PRIu64" ", mb->timestamp);
+   if (ol_flags & PKT_RX_VLAN_STRIPPED)
+   printf(" - VLAN tci=0x%x", mb->vlan_tci);
+   if (ol_flags & PKT_RX_QINQ_STRIPPED)
+   printf(" - QinQ VLAN tci=0x%x, VLAN tci outer=0x%x",
+  mb->vlan_tci, mb->vlan_tci_outer);
+   if (mb->packet_type) {
+   rte_get_ptype_name(mb->packet_type, buf, sizeof(buf));
+   printf(" - hw ptype: %s", buf);
+   }
+   sw_packet_type = rte_net_get_ptype(mb, &hdr_lens,
+  RTE_PTYPE_ALL_MASK);
+   rte_get_ptype_name(sw_packet_type, buf, sizeof(buf));
+   printf(" - sw ptype: %s", buf);
+   if (sw_packet_type & RTE_PTYPE_L2_MASK)
+ 

[dpdk-dev] [PATCH 2/2] app/testpmd: use the generic function to dump packets

[Raslan Darawsheh]

use the generic function to dump packets for several forwarding
engines.

To dump received packets first bit of verbosity need to be set and for sent
packets verbosity second bit need to be set.

for example:
dump rx : set verbose 1
dump tx : set verbose 2
dump rx and tx : set verbose 3

Signed-off-by: Raslan Darawsheh 
---
 app/test-pmd/iofwd.c   |   2 +
 app/test-pmd/macfwd.c  |   4 ++
 app/test-pmd/macswap.c |   4 ++
 app/test-pmd/rxonly.c  | 136 ++---
 4 files changed, 15 insertions(+), 131 deletions(-)

diff --git a/app/test-pmd/iofwd.c b/app/test-pmd/iofwd.c
index 9dce76e..7c09271 100644
--- a/app/test-pmd/iofwd.c
+++ b/app/test-pmd/iofwd.c
@@ -69,6 +69,8 @@ pkt_burst_io_forward(struct fwd_stream *fs)
if (unlikely(nb_rx == 0))
return;
fs->rx_packets += nb_rx;
+   if (unlikely(verbose_level & 0x1))
+   dump_pkt_burst(fs, pkts_burst, nb_rx, 1);
 
 #ifdef RTE_TEST_PMD_RECORD_BURST_STATS
fs->rx_burst_stats.pkt_burst_spread[nb_rx]++;
diff --git a/app/test-pmd/macfwd.c b/app/test-pmd/macfwd.c
index 7cac757..b1b00bc 100644
--- a/app/test-pmd/macfwd.c
+++ b/app/test-pmd/macfwd.c
@@ -78,6 +78,8 @@ pkt_burst_mac_forward(struct fwd_stream *fs)
fs->rx_burst_stats.pkt_burst_spread[nb_rx]++;
 #endif
fs->rx_packets += nb_rx;
+   if (unlikely(verbose_level & 0x1))
+   dump_pkt_burst(fs, pkts_burst, nb_rx, 1);
txp = &ports[fs->tx_port];
tx_offloads = txp->dev_conf.txmode.offloads;
if (tx_offloads & DEV_TX_OFFLOAD_VLAN_INSERT)
@@ -117,6 +119,8 @@ pkt_burst_mac_forward(struct fwd_stream *fs)
}
 
fs->tx_packets += nb_tx;
+   if (unlikely(verbose_level & 0x2))
+   dump_pkt_burst(fs, pkts_burst, nb_tx, 0);
 #ifdef RTE_TEST_PMD_RECORD_BURST_STATS
fs->tx_burst_stats.pkt_burst_spread[nb_tx]++;
 #endif
diff --git a/app/test-pmd/macswap.c b/app/test-pmd/macswap.c
index a8384d5..5611bf8 100644
--- a/app/test-pmd/macswap.c
+++ b/app/test-pmd/macswap.c
@@ -107,6 +107,8 @@ pkt_burst_mac_swap(struct fwd_stream *fs)
fs->rx_burst_stats.pkt_burst_spread[nb_rx]++;
 #endif
fs->rx_packets += nb_rx;
+   if (unlikely(verbose_level & 0x1))
+   dump_pkt_burst(fs, pkts_burst, nb_rx, 1);
txp = &ports[fs->tx_port];
tx_offloads = txp->dev_conf.txmode.offloads;
if (tx_offloads & DEV_TX_OFFLOAD_VLAN_INSERT)
@@ -147,6 +149,8 @@ pkt_burst_mac_swap(struct fwd_stream *fs)
}
}
fs->tx_packets += nb_tx;
+   if (unlikely(verbose_level & 0x2))
+   dump_pkt_burst(fs, pkts_burst, nb_tx, 0);
 #ifdef RTE_TEST_PMD_RECORD_BURST_STATS
fs->tx_burst_stats.pkt_burst_spread[nb_tx]++;
 #endif
diff --git a/app/test-pmd/rxonly.c b/app/test-pmd/rxonly.c
index a93d806..f9bfdeb 100644
--- a/app/test-pmd/rxonly.c
+++ b/app/test-pmd/rxonly.c
@@ -40,14 +40,6 @@
 
 #include "testpmd.h"
 
-static inline void
-print_ether_addr(const char *what, struct ether_addr *eth_addr)
-{
-   char buf[ETHER_ADDR_FMT_SIZE];
-   ether_format_addr(buf, ETHER_ADDR_FMT_SIZE, eth_addr);
-   printf("%s%s", what, buf);
-}
-
 /*
  * Received a burst of packets.
  */
@@ -55,16 +47,8 @@ static void
 pkt_burst_receive(struct fwd_stream *fs)
 {
struct rte_mbuf  *pkts_burst[MAX_PKT_BURST];
-   struct rte_mbuf  *mb;
-   struct ether_hdr *eth_hdr;
-   uint16_t eth_type;
-   uint64_t ol_flags;
uint16_t nb_rx;
-   uint16_t i, packet_type;
-   uint16_t is_encapsulation;
-   char buf[256];
-   struct rte_net_hdr_lens hdr_lens;
-   uint32_t sw_packet_type;
+   uint16_t i;
 
 #ifdef RTE_TEST_PMD_RECORD_CORE_CYCLES
uint64_t start_tsc;
@@ -90,120 +74,10 @@ pkt_burst_receive(struct fwd_stream *fs)
/*
 * Dump each received packet if verbose_level > 0.
 */
-   if (verbose_level > 0)
-   printf("port %u/queue %u: received %u packets\n",
-  fs->rx_port,
-  (unsigned) fs->rx_queue,
-  (unsigned) nb_rx);
-   for (i = 0; i < nb_rx; i++) {
-   mb = pkts_burst[i];
-   if (verbose_level == 0) {
-   rte_pktmbuf_free(mb);
-   continue;
-   }
-   eth_hdr = rte_pktmbuf_mtod(mb, struct ether_hdr *);
-   eth_type = RTE_BE_TO_CPU_16(eth_hdr->ether_type);
-   ol_flags = mb->ol_flags;
-   packet_type = mb->packet_type;
-   is_encapsulation = RTE_ETH_IS_TUNNEL_PKT(packet_type);
-
-   print_ether_addr("  src=", ð_hdr->s_addr);
-   print_ether_addr(" - dst=", ð_hdr->d_addr);
-   printf(" - type=0x%04x - length=%u - nb_segs=%d",
-  eth_type, (unsigned) mb->pkt_len,
-  (int)mb->nb_segs);
-   if (ol_flags & PKT_RX_RSS_

Re: [dpdk-dev] Deadlock when start virtio_user + vhost_kernel

[Jason Wang]

On 2018年09月12日 12:27, Tiwei Bie wrote:

On Wed, Sep 12, 2018 at 11:47:20AM +0800, Jason Wang wrote:

Hi:

Try to launch virtio_user + vhost_kernel with: testpmd
--vdev=virtio_user0,path=/dev/vhost-net -- -i

It seems we get a deadlock on
rte_rwlock_read_lock(&mcfg->memory_hotplug_lock)

Yes, you're right. There is a deadlock here.
FYI, it can be fixed by below patch:
http://patches.dpdk.org/patch/44290/


Thanks for the pointer, this fixes the deadlock.




calltrace:

Thread 1 "testpmd" received signal SIGINT, Interrupt.
rte_memseg_contig_walk (func=func@entry=0x55a5e630 ,
arg=arg@entry=0x7fffcec0)
     at /home/devel/git/dpdk/lib/librte_eal/common/eal_common_memory.c:469
469 rte_rwlock_read_lock(&mcfg->memory_hotplug_lock);
(gdb) bt
#0  rte_memseg_contig_walk (func=func@entry=0x55a5e630
, arg=arg@entry=0x7fffcec0)
     at /home/devel/git/dpdk/lib/librte_eal/common/eal_common_memory.c:469
#1  0x55a5e9b1 in prepare_vhost_memory_kernel () at
/home/devel/git/dpdk/drivers/net/virtio/virtio_user/vhost_kernel.c:118
#2  vhost_kernel_ioctl (dev=0x7ffbf5fb3300, req=,
arg=)
     at
/home/devel/git/dpdk/drivers/net/virtio/virtio_user/vhost_kernel.c:190
#3  0x55a5f211 in virtio_user_mem_event_cb (type=,
addr=, len=, arg=0x7ffbf5fb3300)
     at
/home/devel/git/dpdk/drivers/net/virtio/virtio_user/virtio_user_dev.c:297
#4  0x5574814b in eal_memalloc_mem_event_notify
(event=event@entry=RTE_MEM_EVENT_ALLOC, start=start@entry=0x7ffbf600,
     len=len@entry=94371840) at
/home/devel/git/dpdk/lib/librte_eal/common/eal_common_memalloc.c:248
#5  0x557563f6 in try_expand_heap_primary (contig=false, bound=0,
align=64, flags=0, socket=0, elt_size=0, pg_sz=,
     heap=0x77ff667c) at
/home/devel/git/dpdk/lib/librte_eal/common/malloc_heap.c:344
#6  try_expand_heap (heap=heap@entry=0x77ff667c, pg_sz=,
elt_size=elt_size@entry=92403968, socket=socket@entry=0,
     flags=flags@entry=0, align=align@entry=64, bound=0, contig=false) at
/home/devel/git/dpdk/lib/librte_eal/common/malloc_heap.c:426
#7  0x55756928 in alloc_more_mem_on_socket
(heap=heap@entry=0x77ff667c, size=size@entry=92403968,
socket=socket@entry=0,
     flags=flags@entry=0, align=align@entry=64, bound=bound@entry=0,
contig=false) at
/home/devel/git/dpdk/lib/librte_eal/common/malloc_heap.c:554
#8  0x55756e37 in heap_alloc_on_socket (contig=false, bound=0,
align=64, flags=0, socket=0, size=92403968, type=)
     at /home/devel/git/dpdk/lib/librte_eal/common/malloc_heap.c:590
#9  malloc_heap_alloc (type=, size=92403968,
socket_arg=, flags=0, align=, bound=0,
contig=false)
     at /home/devel/git/dpdk/lib/librte_eal/common/malloc_heap.c:626
#10 0x55753fc1 in rte_zmalloc () at
/home/devel/git/dpdk/lib/librte_eal/common/rte_malloc.c:74
#11 0x556192f9 in init_port () at
/home/devel/git/dpdk/app/test-pmd/testpmd.c:2645
#12 main (argc=4, argv=0x7fffdb18) at
/home/devel/git/dpdk/app/test-pmd/testpmd.c:2734

And I also get this warning:

vhost_kernel_ioctl(): VHOST_SET_OWNER failed: Device or resource busy

Since below commit:
bce7e9050f9b ("net/virtio-user: fix start with kernel vhost")
https://github.com/DPDK/dpdk/commit/bce7e9050f9b

The vhost SET_OWNER will be done in virtio_user_start_device()
unconditionally. It caused above harmless but annoying warning.


Ok, but it's better to remove it anyway in the future.

Thanks


Both looks like a bug that needs to be fixed.

Thanks

Re: [dpdk-dev] [PATCH v5 03/11] net/virtio: add packed virtqueue helpers

[Maxime Coquelin]

On 09/06/2018 08:19 PM, Jens Freimann wrote:

Add helper functions to set/clear and check descriptor flags.

Signed-off-by: Jens Freimann 
---
  drivers/net/virtio/virtio_ring.h | 26 ++
  drivers/net/virtio/virtqueue.h   | 19 +++
  2 files changed, 45 insertions(+)

diff --git a/drivers/net/virtio/virtio_ring.h b/drivers/net/virtio/virtio_ring.h
index e2c597434..f3b23f419 100644
--- a/drivers/net/virtio/virtio_ring.h
+++ b/drivers/net/virtio/virtio_ring.h
@@ -78,6 +78,8 @@ struct vring_packed_desc_event {
  
  struct vring {

unsigned int num;
+   unsigned int avail_wrap_counter;
+   unsigned int used_wrap_counter;
union {
struct vring_desc_packed *desc_packed;
struct vring_desc *desc;
@@ -92,6 +94,30 @@ struct vring {
};
  };
  
+static inline void

+_set_desc_avail(struct vring_desc_packed *desc, int wrap_counter)
+{
+   desc->flags |= VRING_DESC_F_AVAIL(wrap_counter) |
+  VRING_DESC_F_USED(!wrap_counter);


It implies the avail and used bits to be cleared beforehand.
Maybe it would be safer to clear them in the helper?


+}
+
+static inline void
+set_desc_avail(struct vring *vr, struct vring_desc_packed *desc)
+{
+   _set_desc_avail(desc, vr->avail_wrap_counter);
+}
+
+static inline int
+desc_is_used(struct vring_desc_packed *desc, struct vring *vr)
+{
+   uint16_t used, avail;
+
+   used = !!(desc->flags & VRING_DESC_F_USED(1));
+   avail = !!(desc->flags & VRING_DESC_F_AVAIL(1));
+
+   return used == avail && used == vr->used_wrap_counter;
+}
+
  /* The standard layout for the ring is a continuous chunk of memory which
   * looks like this.  We assume num is a power of 2.
   *
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index d2a0b651a..53fce61b4 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -245,6 +245,25 @@ struct virtio_tx_region {
   __attribute__((__aligned__(16)));
  };
  
+static inline uint16_t

+increment_pq_index(uint16_t idx, size_t ring_size)
+{
+   return ++idx >= ring_size ? 0 : idx;
+}


Not sure this helper is really useful, as it ends up
doing two checks in a row.


+
+static inline uint16_t
+update_pq_avail_index(struct virtqueue *vq)
+{
+   uint16_t idx;
+
+   idx = increment_pq_index(vq->vq_avail_idx, vq->vq_nentries);
+   if (idx == 0)
+   vq->vq_ring.avail_wrap_counter ^= 1;



+   vq->vq_avail_idx = idx;
+
+   return vq->vq_avail_idx;
+}


So it could be simplified to:

{
if (++vq->vq_avail_idx >= vq->vq_entries) {
vq->vq_avail_idx = 0;
vq->vq_ring.avail_wrap_counter ^= 1;
}

return vq->vq_avail_idx;
}


+
  static inline void
  vring_desc_init_packed(struct vring *vr, int n)
  {

Re: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while fiber link update

[Zhang, Qi Z]

> -Original Message-
> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
> Sent: Wednesday, September 12, 2018 4:05 PM
> To: Zhang, Qi Z ; dev@dpdk.org
> Cc: Lu, Wenzhuo ; Ananyev, Konstantin
> ; Laurent Hardy
> ; Dai, Wei ;
> sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while fiber link
> update
> 
> On 12.09.2018 09:49, Zhang, Qi Z wrote:
> >
> >
> >> -Original Message-
> >> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
> >> Sent: Monday, September 10, 2018 11:09 PM
> >> To: Zhang, Qi Z ; dev@dpdk.org
> >> Cc: Lu, Wenzhuo ; Ananyev, Konstantin
> >> ; Laurent Hardy
> >> ; Dai, Wei ;
> >> sta...@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while
> >> fiber link update
> >>
> >> On 04.09.2018 09:08, Zhang, Qi Z wrote:
> >>> Hi Ilya:
> >>>
>  -Original Message-
>  From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ilya Maximets
>  Sent: Friday, August 31, 2018 8:40 PM
>  To: dev@dpdk.org
>  Cc: Lu, Wenzhuo ; Ananyev, Konstantin
>  ; Laurent Hardy
>  ; Dai, Wei ; Ilya
>  Maximets ; sta...@dpdk.org
>  Subject: [dpdk-dev] [PATCH] net/ixgbe: fix busy polling while fiber
>  link update
> 
>  If the multispeed fiber link is in DOWN state, ixgbe_setup_link
>  could take around a second of busy polling. This is highly
>  inconvenient for the case where single thread periodically checks the 
>  link
> statuses.
>  For example, OVS main thread periodically updates the link statuses
>  and hangs for a really long time busy waiting on ixgbe_setup_link()
>  for a DOWN fiber ports. For case with 3 down ports it hangs for a 3
>  seconds and unable to do anything including packet processing.
>  Fix that by shifting that workaround to a separate thread by alarm
>  handler that will try to set up link if it is DOWN.
> >>>
> >>> Does that mean we will block the interrupt thread for 3 seconds?
> >>
> >> Three times for one second. Other work could be scheduled between.
> >> IMHO, it's much better than blocking usual caller for 3 seconds.
> >>
> >>> Also, can we guarantee there will not be any race condition if we
> >>> call
> >> ixgbe_setup_link at another thread, the base code API is not assumed
> >> to be thread-safe as I know.
> >>
> >> The only user of 'ixgbe_setup_link' is 'ixgbe_dev_start', but it
> >> could be called only if device stopped. 'ixgbe_dev_stop' cancels the alarm.
> >> Race with 'link_update' avoided by 'IXGBE_FLAG_NEED_LINK_CONFIG' flag.
> >
> > I guess, it' not only about when ixgb_setup_link race with itself, but also
> when it race with other APIs.
> > Also the concern is, even in current version, we can prove there is no 
> > issue,
> how can we guarantee we are safe for future base code update? It's not
> designed as thread-safe.
> > For my option, the change is risky.
> 
> In current implementation interrupt handler already calls the
> 'ixgbe_dev_link_update' which subsequently calls 'ixgbe_setup_link'
> in our case if LSC interrupts enabled. So, my change makes the driver even
> safer by moving 'ixgbe_setup_link' to the same interrupt thread.
> Otherwise two threads (interrupts handler and the link status checking thread)
> could call 'ixgbe_setup_link' simultaneously.

Ok, you are right, seems the concern I have is already exist , your patch does 
not introduce new issue.
So I have no objection if this will fix some issue.
But let's check if any ixgbe experts will comment.

Regards
Qi

> 
> >
> > Btw, since ixgbe support LSC, it is not necessary for "single thread
> periodically checks the link statuses", right?
> 
> In current implementation it will take at least 5 seconds (4 + 1) for the 
> interrupt
> handler to detect DOWN link state for ixgbe multispeed fiber. This is too much
> for many real world cases.
> 
> >
> >>
> >>>
> >>> Regards
> >>> Qi
> >>>
> 
>  Fixes: c12d22f65b13 ("net/ixgbe: ensure link status is updated")
>  CC: sta...@dpdk.org
> 
>  Signed-off-by: Ilya Maximets 
>  ---
>   drivers/net/ixgbe/ixgbe_ethdev.c | 43
>  
>   1 file changed, 32 insertions(+), 11 deletions(-)
> 
>  diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
>  b/drivers/net/ixgbe/ixgbe_ethdev.c
>  index 26b192737..a33b9a6e8 100644
>  --- a/drivers/net/ixgbe/ixgbe_ethdev.c
>  +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
>  @@ -221,6 +221,8 @@ static int ixgbe_dev_interrupt_action(struct
>  rte_eth_dev *dev,
> struct rte_intr_handle *handle);  
>  static void
>  ixgbe_dev_interrupt_handler(void *param);  static void
>  ixgbe_dev_interrupt_delayed_handler(void *param);
>  +static void ixgbe_dev_setup_link_alarm_handler(void *param);
>  +
>   static int ixgbe_add_rar(struct rte_eth_dev *dev, struct
>  ether_addr *mac_addr,
>    uint32_t index, uint32_t 

[dpdk-dev] [PATCH v2] ethdev: fix missing names in Tx offload name array

[Dekel Peled]

Patch 5355f443 added two definitions of DEV_TX_OFFLOAD_xxx.
If new Tx offload capabilities are defined, they also must be mentioned
in rte_tx_offload_names in rte_ethdev.c file.

This patch adds the required lines in array rte_tx_offload_names.

Fixes: 5355f4439e2e ("ethdev: introduce generic IP/UDP tunnel checksum and TSO")

Cc: xuemi...@mellanox.com

Signed-off-by: Dekel Peled 
---
v2:
* Discard change of comments location in file rte_ethdev.h.
---

 lib/librte_ethdev/rte_ethdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 3f8de93..5004b9f 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -156,6 +156,8 @@ struct rte_eth_xstats_name_off {
RTE_TX_OFFLOAD_BIT2STR(MULTI_SEGS),
RTE_TX_OFFLOAD_BIT2STR(MBUF_FAST_FREE),
RTE_TX_OFFLOAD_BIT2STR(SECURITY),
+   RTE_TX_OFFLOAD_BIT2STR(UDP_TNL_TSO),
+   RTE_TX_OFFLOAD_BIT2STR(IP_TNL_TSO),
 };
 
 #undef RTE_TX_OFFLOAD_BIT2STR
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v2] ethdev: fix missing names in Tx offload name array

[Andrew Rybchenko]

On 09/12/2018 11:28 AM, Dekel Peled wrote:

Patch 5355f443 added two definitions of DEV_TX_OFFLOAD_xxx.
If new Tx offload capabilities are defined, they also must be mentioned
in rte_tx_offload_names in rte_ethdev.c file.

This patch adds the required lines in array rte_tx_offload_names.

Fixes: 5355f4439e2e ("ethdev: introduce generic IP/UDP tunnel checksum and TSO")

Cc: xuemi...@mellanox.com

Signed-off-by: Dekel Peled 


Acked-by: Andrew Rybchenko 

Re: [dpdk-dev] [PATCH v5 2/4] net/ixgbe: install ethdev hotplug handler in ixgbe

[Jeff Guo]

hi, ferruh


On 8/25/2018 12:22 AM, Ferruh Yigit wrote:

On 7/11/2018 12:51 PM, Jeff Guo wrote:

This patch aim to enable hotplug detect in ixgbe PMD. Firstly it
set the flags RTE_PCI_DRV_INTR_RMV in drv_flags to announce the hotplug
ability, and then use rte_eth_dev_event_handler_install to install
the hotplug event handler for ethdev. When eal detect the hotplug event,
it will call the ethdev callback to process it. If the event is hotplug
removal, it will trigger the RTE_ETH_EVENT_INTR_RMV event into ethdev
callback to let app process the hotplug for this ethdev.

This is an example for other driver, that if any driver support hotplug
feature could be use this way to install hotplug handler.

Signed-off-by: Jeff Guo 
Acked-by: Wenzhuo Lu 
---
v5->v4:
no change.
---
  drivers/net/ixgbe/ixgbe_ethdev.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 87d2ad0..e7ae9bf 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1678,6 +1678,9 @@ eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev)
rte_intr_enable(intr_handle);
ixgbevf_intr_enable(eth_dev);
  
+	/* install the dev event handler for ethdev. */

+   rte_eth_dev_event_handler_install(eth_dev);
+
PMD_INIT_LOG(DEBUG, "port %d vendorID=0x%x deviceID=0x%x mac.type=%s",
 eth_dev->data->port_id, pci_dev->id.vendor_id,
 pci_dev->id.device_id, "ixgbe_mac_82599_vf");
@@ -1718,6 +1721,9 @@ eth_ixgbevf_dev_uninit(struct rte_eth_dev *eth_dev)
rte_intr_callback_unregister(intr_handle,
 ixgbevf_dev_interrupt_handler, eth_dev);
  
+	/* uninstall the dev event handler for ethdev. */

+   rte_eth_dev_event_handler_uninstall(eth_dev);
+
return 0;
  }
  
@@ -1801,7 +1807,7 @@ static int eth_ixgbe_pci_remove(struct rte_pci_device *pci_dev)

  static struct rte_pci_driver rte_ixgbe_pmd = {
.id_table = pci_id_ixgbe_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC |
-RTE_PCI_DRV_IOVA_AS_VA,
+RTE_PCI_DRV_IOVA_AS_VA | RTE_PCI_DRV_INTR_RMV,

Instead of each driver explicitly install/uninstall handler, can it be possible
to do this in a common code for drivers that report RTE_PCI_DRV_INTR_RMV 
support?
With this you may not need helper functions but implement them as static
functions in common code.


make sense, I think offload the install/uninstall to step into the 
device class helper should be a better option, since we could check if 
the driver support

hotplug by RTE_PCI_DRV_INTR_RMV.


Also should registered_callback remove eth_dev? (after calling user registered
callbacks)


The eth_dev should be remove as any other device user space resources, 
the process should be include in the currently user registered callback.



And what is the relation of RTE_ETH_DEV_REMOVED state, which is to say device
removed and remove callback?


The state of RTE_ETH_DEV_REMOVED means that ether device have already 
been removed, it should be use to let to check and stop any request from 
the app.
that is device class interface layer event, just manage by the layer and 
app.



Lastly, do you think can there be cases driver specific actions needs to be
taken, so should driver provide a callback for removal?


so far, i think the callback should be the same functional for hotplug, 
so the answer is there can be but no needs to taken other specific 
actions, just let it handler by bus layer but not driver.

[dpdk-dev] Reg: "Query in DPDK HQOS "

[Prabakar Prabakar]

Hi
i have query with respect to HQos.

why number of queues in traffic class is fixed to *4*.  And it was
mentioned that "*cannot be changed*".

RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS  *4*

link :
http://doc.dpdk.org/api-17.11/rte__sched_8h.html#a326fddd15331c0fd66c7a181a6b43e29

Any reason behind this, Please help.


Regards,
Prabakar k

[dpdk-dev] [PATCH] app/testpmd: fix metering and policing cli command

[Jasvinder Singh]

Fixes bad arguments error for cli commands related to adding
meter profile for srtcm_rfc2697, trtcm_rfc2698 and trtcm_rfc4115.

error log:
testpmd> add port meter profile trtcm_rfc2698 2 0 312500 312500 250 
250
Bad arguments

Fixes: 30ffb4e67ee3 ("app/testpmd: add commands traffic metering and policing")

Signed-off-by: Jasvinder Singh 
---
 app/test-pmd/cmdline_mtr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index f908fb3..32a4730 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -414,9 +414,9 @@ cmdline_parse_inst_t cmd_add_port_meter_profile_srtcm = {
(void *)&cmd_add_port_meter_profile_srtcm_port,
(void *)&cmd_add_port_meter_profile_srtcm_meter,
(void *)&cmd_add_port_meter_profile_srtcm_profile,
+   (void *)&cmd_add_port_meter_profile_srtcm_srtcm_rfc2697,
(void *)&cmd_add_port_meter_profile_srtcm_port_id,
(void *)&cmd_add_port_meter_profile_srtcm_profile_id,
-   (void *)&cmd_add_port_meter_profile_srtcm_srtcm_rfc2697,
(void *)&cmd_add_port_meter_profile_srtcm_cir,
(void *)&cmd_add_port_meter_profile_srtcm_cbs,
(void *)&cmd_add_port_meter_profile_srtcm_ebs,
@@ -521,9 +521,9 @@ cmdline_parse_inst_t cmd_add_port_meter_profile_trtcm = {
(void *)&cmd_add_port_meter_profile_trtcm_port,
(void *)&cmd_add_port_meter_profile_trtcm_meter,
(void *)&cmd_add_port_meter_profile_trtcm_profile,
+   (void *)&cmd_add_port_meter_profile_trtcm_trtcm_rfc2698,
(void *)&cmd_add_port_meter_profile_trtcm_port_id,
(void *)&cmd_add_port_meter_profile_trtcm_profile_id,
-   (void *)&cmd_add_port_meter_profile_trtcm_trtcm_rfc2698,
(void *)&cmd_add_port_meter_profile_trtcm_cir,
(void *)&cmd_add_port_meter_profile_trtcm_pir,
(void *)&cmd_add_port_meter_profile_trtcm_cbs,
@@ -633,9 +633,9 @@ cmdline_parse_inst_t 
cmd_add_port_meter_profile_trtcm_rfc4115 = {
(void *)&cmd_add_port_meter_profile_trtcm_rfc4115_port,
(void *)&cmd_add_port_meter_profile_trtcm_rfc4115_meter,
(void *)&cmd_add_port_meter_profile_trtcm_rfc4115_profile,
+   (void *)&cmd_add_port_meter_profile_trtcm_rfc4115_trtcm_rfc4115,
(void *)&cmd_add_port_meter_profile_trtcm_rfc4115_port_id,
(void *)&cmd_add_port_meter_profile_trtcm_rfc4115_profile_id,
-   (void *)&cmd_add_port_meter_profile_trtcm_rfc4115_trtcm_rfc4115,
(void *)&cmd_add_port_meter_profile_trtcm_rfc4115_cir,
(void *)&cmd_add_port_meter_profile_trtcm_rfc4115_eir,
(void *)&cmd_add_port_meter_profile_trtcm_rfc4115_cbs,
-- 
2.9.3

Re: [dpdk-dev] [PATCH v5 03/11] net/virtio: add packed virtqueue helpers

[Jens Freimann]

On Wed, Sep 12, 2018 at 10:25:57AM +0200, Maxime Coquelin wrote:



On 09/06/2018 08:19 PM, Jens Freimann wrote:

Add helper functions to set/clear and check descriptor flags.

Signed-off-by: Jens Freimann 
---
 drivers/net/virtio/virtio_ring.h | 26 ++
 drivers/net/virtio/virtqueue.h   | 19 +++
 2 files changed, 45 insertions(+)

diff --git a/drivers/net/virtio/virtio_ring.h b/drivers/net/virtio/virtio_ring.h
index e2c597434..f3b23f419 100644
--- a/drivers/net/virtio/virtio_ring.h
+++ b/drivers/net/virtio/virtio_ring.h
@@ -78,6 +78,8 @@ struct vring_packed_desc_event {
 struct vring {
unsigned int num;
+   unsigned int avail_wrap_counter;
+   unsigned int used_wrap_counter;
union {
struct vring_desc_packed *desc_packed;
struct vring_desc *desc;
@@ -92,6 +94,30 @@ struct vring {
};
 };
+static inline void
+_set_desc_avail(struct vring_desc_packed *desc, int wrap_counter)
+{
+   desc->flags |= VRING_DESC_F_AVAIL(wrap_counter) |
+  VRING_DESC_F_USED(!wrap_counter);


It implies the avail and used bits to be cleared beforehand.
Maybe it would be safer to clear them in the helper?


Safer but also less explicit for someone who just reads the higher
level function. But I think it's better to go for the safer version
here.  




+}
+
+static inline void
+set_desc_avail(struct vring *vr, struct vring_desc_packed *desc)
+{
+   _set_desc_avail(desc, vr->avail_wrap_counter);
+}
+
+static inline int
+desc_is_used(struct vring_desc_packed *desc, struct vring *vr)
+{
+   uint16_t used, avail;
+
+   used = !!(desc->flags & VRING_DESC_F_USED(1));
+   avail = !!(desc->flags & VRING_DESC_F_AVAIL(1));
+
+   return used == avail && used == vr->used_wrap_counter;
+}
+
 /* The standard layout for the ring is a continuous chunk of memory which
  * looks like this.  We assume num is a power of 2.
  *
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index d2a0b651a..53fce61b4 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -245,6 +245,25 @@ struct virtio_tx_region {
   __attribute__((__aligned__(16)));
 };
+static inline uint16_t
+increment_pq_index(uint16_t idx, size_t ring_size)
+{
+   return ++idx >= ring_size ? 0 : idx;
+}


Not sure this helper is really useful, as it ends up
doing two checks in a row.


+
+static inline uint16_t
+update_pq_avail_index(struct virtqueue *vq)
+{
+   uint16_t idx;
+
+   idx = increment_pq_index(vq->vq_avail_idx, vq->vq_nentries);
+   if (idx == 0)
+   vq->vq_ring.avail_wrap_counter ^= 1;



+   vq->vq_avail_idx = idx;
+
+   return vq->vq_avail_idx;
+}


So it could be simplified to:

{
if (++vq->vq_avail_idx >= vq->vq_entries) {
vq->vq_avail_idx = 0;
vq->vq_ring.avail_wrap_counter ^= 1;
}

return vq->vq_avail_idx;


yes, I will either change to what you suggested or
get rid of the helper completely since it is only used in
very few places.

Thanks for the review!

regards,
Jens 

Re: [dpdk-dev] [PATCH v5 01/11] net/virtio: vring init for packed queues

[Jens Freimann]

On Wed, Sep 12, 2018 at 10:02:30AM +0200, Maxime Coquelin wrote:



On 09/06/2018 08:19 PM, Jens Freimann wrote:

vq->vq_free_cnt = vq->vq_nentries;
memset(vq->vq_descx, 0, sizeof(struct vq_desc_extra) * vq->vq_nentries);
+   vq->vq_used_cons_idx = 0;
+   vq->vq_avail_idx = 0;
+   if (vtpci_packed_queue(vq->hw)) {
+   vring_desc_init_packed(vr, size);
+   } else {
+   vq->vq_desc_head_idx = 0;
+   vq->vq_desc_tail_idx = (uint16_t)(vq->vq_nentries - 1);
-   vring_desc_init(vr->desc, size);
+   vring_desc_init(vr->desc, size);
+   }


Maybe worth renaming to vring_desc_init_split() for consistency.


yes, I'll rename it.

regards,
Jens 

Re: [dpdk-dev] [PATCH v5 04/11] net/virtio: flush packed receive virtqueues

[Maxime Coquelin]

On 09/06/2018 08:19 PM, Jens Freimann wrote:

Flush used descriptors in packed receive virtqueue. As descriptors
can be chained we need to look at the stored number of used descriptors
to find out the length of the chain.

Signed-off-by: Jens Freimann 
---
  drivers/net/virtio/virtqueue.c | 17 +
  1 file changed, 17 insertions(+)

diff --git a/drivers/net/virtio/virtqueue.c b/drivers/net/virtio/virtqueue.c
index 56a77cc71..d0520dad1 100644
--- a/drivers/net/virtio/virtqueue.c
+++ b/drivers/net/virtio/virtqueue.c
@@ -58,12 +58,29 @@ virtqueue_detach_unused(struct virtqueue *vq)
  void
  virtqueue_rxvq_flush(struct virtqueue *vq)
  {
+   struct vring_desc_packed *descs = vq->vq_ring.desc_packed;
struct virtnet_rx *rxq = &vq->rxq;
struct virtio_hw *hw = vq->hw;
struct vring_used_elem *uep;
struct vq_desc_extra *dxp;
uint16_t used_idx, desc_idx;
uint16_t nb_used, i;
+   uint16_t size = vq->vq_nentries;
+
+   if (vtpci_packed_queue(vq->hw)) {
+   i = vq->vq_used_cons_idx;
+   while (desc_is_used(&descs[i], &vq->vq_ring) &&
+   i < vq->vq_nentries) {

It may be preferable to ensure 'i' is within the ring size before using
it in desc_is_used(). And raise (at least) an error message if it isn't.


+   dxp = &vq->vq_descx[i];
+   if (dxp->cookie != NULL)
+   rte_pktmbuf_free(dxp->cookie);
+   vq->vq_free_cnt += dxp->ndescs;
+   i = i + dxp->ndescs;
+   i = i >= size ? i - size : i;
+   dxp->ndescs = 0;
+   }
+   return;
+   }
  
  	nb_used = VIRTQUEUE_NUSED(vq);
  

Re: [dpdk-dev] [PATCH v5 05/11] net/virtio: dump packed virtqueue data

[Maxime Coquelin]

On 09/06/2018 08:19 PM, Jens Freimann wrote:

Add support to dump packed virtqueue data to the
VIRTQUEUE_DUMP() macro.

Signed-off-by: Jens Freimann 
---
  drivers/net/virtio/virtqueue.h | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 53fce61b4..531ba8c65 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -384,6 +384,12 @@ virtqueue_notify(struct virtqueue *vq)
uint16_t used_idx, nused; \
used_idx = (vq)->vq_ring.used->idx; \
nused = (uint16_t)(used_idx - (vq)->vq_used_cons_idx); \
+   if (vtpci_packed_queue((vq)->hw)) { \
+ PMD_INIT_LOG(DEBUG, \
+ "VQ: - size=%d; free=%d; last_used_idx=%d;", \
+ (vq)->vq_nentries, (vq)->vq_free_cnt, nused); \
+ break; \
+   } \
PMD_INIT_LOG(DEBUG, \
  "VQ: - size=%d; free=%d; used=%d; desc_head_idx=%d;" \
  " avail.idx=%d; used_cons_idx=%d; used.idx=%d;" \



Reviewed-by: Maxime Coquelin 

Thanks,
Maxime

Re: [dpdk-dev] [PATCH v5 06/11] net/virtio-user: add option to use packed queues

[Maxime Coquelin]

On 09/06/2018 08:19 PM, Jens Freimann wrote:

From: Yuanhan Liu 

Add option to enable packed queue support for virtio-user
devices.

Signed-off-by: Yuanhan Liu 
---
  drivers/net/virtio/virtio_user/virtio_user_dev.c | 10 --
  drivers/net/virtio/virtio_user/virtio_user_dev.h |  2 +-
  drivers/net/virtio/virtio_user_ethdev.c  | 14 +-
  3 files changed, 22 insertions(+), 4 deletions(-)



Shouldn't this patch be better placed at the end of the series to avoid
negotiating packed ring feature while the datapaths aren't implemented?


diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c 
b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index 7df600b02..9979bea0d 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -372,12 +372,13 @@ virtio_user_dev_setup(struct virtio_user_dev *dev)
 1ULL << VIRTIO_NET_F_GUEST_TSO4  |   \
 1ULL << VIRTIO_NET_F_GUEST_TSO6  |   \
 1ULL << VIRTIO_F_IN_ORDER|   \
-1ULL << VIRTIO_F_VERSION_1)
+1ULL << VIRTIO_F_VERSION_1   |   \
+1ULL << VIRTIO_F_RING_PACKED)
  
  int

  virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
 int cq, int queue_size, const char *mac, char **ifname,
-int mrg_rxbuf, int in_order)
+int mrg_rxbuf, int in_order, int packed_vq)
  {
pthread_mutex_init(&dev->mutex, NULL);
snprintf(dev->path, PATH_MAX, "%s", path);
@@ -432,6 +433,11 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char 
*path, int queues,
dev->unsupported_features |= (1ull << VIRTIO_F_IN_ORDER);
}
  
+	if (packed_vq)

+   dev->device_features |= (1ull << VIRTIO_F_RING_PACKED);
+   else
+   dev->device_features &= ~(1ull << VIRTIO_F_RING_PACKED);
+
if (dev->mac_specified) {
dev->device_features |= (1ull << VIRTIO_NET_F_MAC);
} else {
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.h 
b/drivers/net/virtio/virtio_user/virtio_user_dev.h
index d6e0e137b..7f46ba1d9 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.h
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.h
@@ -49,7 +49,7 @@ int virtio_user_start_device(struct virtio_user_dev *dev);
  int virtio_user_stop_device(struct virtio_user_dev *dev);
  int virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
 int cq, int queue_size, const char *mac, char **ifname,
-int mrg_rxbuf, int in_order);
+int mrg_rxbuf, int in_order, int packed_vq);
  void virtio_user_dev_uninit(struct virtio_user_dev *dev);
  void virtio_user_handle_cq(struct virtio_user_dev *dev, uint16_t queue_idx);
  uint8_t virtio_user_handle_mq(struct virtio_user_dev *dev, uint16_t q_pairs);
diff --git a/drivers/net/virtio/virtio_user_ethdev.c 
b/drivers/net/virtio/virtio_user_ethdev.c
index 525d16cab..72ac86186 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -364,6 +364,8 @@ static const char *valid_args[] = {
VIRTIO_USER_ARG_MRG_RXBUF,
  #define VIRTIO_USER_ARG_IN_ORDER   "in_order"
VIRTIO_USER_ARG_IN_ORDER,
+#define VIRTIO_USER_ARG_PACKED_VQ "packed_vq"
+   VIRTIO_USER_ARG_PACKED_VQ,
NULL
  };
  
@@ -473,6 +475,7 @@ virtio_user_pmd_probe(struct rte_vdev_device *dev)

char *ifname = NULL;
char *mac_addr = NULL;
int ret = -1;
+   uint64_t packed_vq = 0;
  
  	kvlist = rte_kvargs_parse(rte_vdev_device_args(dev), valid_args);

if (!kvlist) {
@@ -556,6 +559,15 @@ virtio_user_pmd_probe(struct rte_vdev_device *dev)
cq = 1;
}
  
+	if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_PACKED_VQ) == 1) {

+   if (rte_kvargs_process(kvlist, VIRTIO_USER_ARG_PACKED_VQ,
+  &get_integer_arg, &packed_vq) < 0) {
+   PMD_INIT_LOG(ERR, "error to parse %s",
+VIRTIO_USER_ARG_PACKED_VQ);
+   goto end;
+   }
+   }
+
if (queues > 1 && cq == 0) {
PMD_INIT_LOG(ERR, "multi-q requires ctrl-q");
goto end;
@@ -603,7 +615,7 @@ virtio_user_pmd_probe(struct rte_vdev_device *dev)
vu_dev->is_server = false;
if (virtio_user_dev_init(hw->virtio_user_dev, path, queues, cq,
 queue_size, mac_addr, &ifname, mrg_rxbuf,
-in_order) < 0) {
+in_order, packed_vq) < 0) {
PMD_INIT_LOG(ERR, "virtio_user_dev_init fails");
virtio_user_eth_dev_free(eth_dev);
goto end;

Re: [dpdk-dev] Change in binary name w/ meson build

[Bruce Richardson]

On Wed, Sep 12, 2018 at 06:21:06AM +, Shahaf Shuler wrote:
> Friday, September 7, 2018 6:24 PM, Bruce Richardson:
> > Subject: Re: [dpdk-dev] Change in binary name w/ meson build
> > 
> > On Fri, Sep 07, 2018 at 03:13:43PM +0100, Bruce Richardson wrote:
> > > On Wed, Sep 05, 2018 at 11:52:10AM +, Shahaf Shuler wrote:
> > > >Hi Bruce,
> > > >
> > > >
> > > >Playing w/ meson build I got to know that the binary name for testpmd
> > > >got changed to dpdk-testpmd.
> > > >
> > > >
> > > >Not sure if it was discussed or not before, but such change will 
> > > > affect
> > > >all the automation used to run testpmd w/ the old build system.
> > > >
> > > >
> > > >What is the reason for the change in the name?
> > >
> > > The primary driver was that the autotest binary could not be called "test"
> > > any more, since that is a reserved name. When appending a dpdk prefix
> > > to the test binary, I felt for consistency that other binaries should
> > > have a dpdk prefix too, to indicate that they come from DPDK. If this
> > > is a problem, we can remove the prefix from the binaries easily enough.
> > >
> > Also to point out that when building with meson the scripting is going to 
> > have
> > to change anyway, right. The actual build commands are different, the
> > configuration commands are different, and the directories the resulting
> > binaries are placed in are different too. Therefore, I'd like to keep the 
> > name
> > prefixes if possible, since for automated tooling on DPDK there are going to
> > have to be lots of other changes anyway.
> > 
> > For packagers, the rename I understand could be problematic, but that could
> > probably be solved by symlinks in the install phase.
> 
> I am fine w/ the testpmd -> dpdk-testpmd change as it is more correct to put 
> it explicitly under the dpdk namespace.
> I was raising this point because I am not sure it was explicitly mentioned on 
> the release notes and was hoping to get feedback also from the people who 
> build dpdk for distro
> 
Agreed, I should have got wider feedback for this change at the time, but
it's not to late to fix if it is problematic, I think. I too like having
the namespacing, though.

/Bruce

Re: [dpdk-dev] Change in binary name w/ meson build

[Luca Boccassi]

On Wed, 2018-09-12 at 10:30 +0100, Bruce Richardson wrote:
> On Wed, Sep 12, 2018 at 06:21:06AM +, Shahaf Shuler wrote:
> > Friday, September 7, 2018 6:24 PM, Bruce Richardson:
> > > Subject: Re: [dpdk-dev] Change in binary name w/ meson build
> > > 
> > > On Fri, Sep 07, 2018 at 03:13:43PM +0100, Bruce Richardson wrote:
> > > > On Wed, Sep 05, 2018 at 11:52:10AM +, Shahaf Shuler wrote:
> > > > >    Hi Bruce,
> > > > > 
> > > > > 
> > > > >    Playing w/ meson build I got to know that the binary name
> > > > > for testpmd
> > > > >    got changed to dpdk-testpmd.
> > > > > 
> > > > > 
> > > > >    Not sure if it was discussed or not before, but such
> > > > > change will affect
> > > > >    all the automation used to run testpmd w/ the old build
> > > > > system.
> > > > > 
> > > > > 
> > > > >    What is the reason for the change in the name?
> > > > 
> > > > The primary driver was that the autotest binary could not be
> > > > called "test"
> > > > any more, since that is a reserved name. When appending a dpdk
> > > > prefix
> > > > to the test binary, I felt for consistency that other binaries
> > > > should
> > > > have a dpdk prefix too, to indicate that they come from DPDK.
> > > > If this
> > > > is a problem, we can remove the prefix from the binaries easily
> > > > enough.
> > > > 
> > > 
> > > Also to point out that when building with meson the scripting is
> > > going to have
> > > to change anyway, right. The actual build commands are different,
> > > the
> > > configuration commands are different, and the directories the
> > > resulting
> > > binaries are placed in are different too. Therefore, I'd like to
> > > keep the name
> > > prefixes if possible, since for automated tooling on DPDK there
> > > are going to
> > > have to be lots of other changes anyway.
> > > 
> > > For packagers, the rename I understand could be problematic, but
> > > that could
> > > probably be solved by symlinks in the install phase.
> > 
> > I am fine w/ the testpmd -> dpdk-testpmd change as it is more
> > correct to put it explicitly under the dpdk namespace.
> > I was raising this point because I am not sure it was explicitly
> > mentioned on the release notes and was hoping to get feedback also
> > from the people who build dpdk for distro
> > 
> 
> Agreed, I should have got wider feedback for this change at the time,
> but
> it's not to late to fix if it is problematic, I think. I too like
> having
> the namespacing, though.
> 
> /Bruce

I can ship backward-compatibility symlinks easily for binary programs
in Debian/Ubuntu (unlike for libraries where it's a bit more
difficult), so personally I'm OK with namespacing things.

Christian?

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [PATCH] doc: support building HTML guides with meson

[Bruce Richardson]

On Tue, Sep 11, 2018 at 10:47:58PM +0100, Luca Boccassi wrote:
> On Tue, 2018-09-11 at 21:36 +0100, Luca Boccassi wrote:
> > On Tue, 2018-09-11 at 17:13 +0100, Bruce Richardson wrote:
> > > Signed-off-by: Bruce Richardson 
> > > ---
> > > NOTE: this patch depends upon:
> > > http://patches.dpdk.org/project/dpdk/list/?series=1232
> > 
> > Just a reminder that's v2, and the patch won't apply cleanly on the
> > latest revision
> > 
> > >  doc/api/meson.build|  3 ++-
> > >  doc/guides/meson.build | 16 
> > >  doc/meson.build| 11 +++
> > >  3 files changed, 29 insertions(+), 1 deletion(-)
> > >  create mode 100644 doc/guides/meson.build
> > > 
> > > diff --git a/doc/api/meson.build b/doc/api/meson.build
> > > index 5dfa0fe04..f9bee4dac 100644
> > > --- a/doc/api/meson.build
> > > +++ b/doc/api/meson.build
> > > @@ -50,5 +50,6 @@ if doxygen.found()
> > >   install_dir: htmldir,
> > >   build_by_default: false)
> > >  
> > > - run_target('doc', command: 'true', depends: doxy_build)
> > > + doc_targets += doxy_build
> > > + doc_target_names += 'Doxygen_API'
> > >  endif
> > > diff --git a/doc/guides/meson.build b/doc/guides/meson.build
> > > new file mode 100644
> > > index 0..6d1e2990d
> > > --- /dev/null
> > > +++ b/doc/guides/meson.build
> > > @@ -0,0 +1,16 @@
> > > +# SPDX-License-Identifier: BSD-3-Clause
> > > +# Copyright(c) 2017 Intel Corporation
> > 
> > s/2017/2018
> > 
> > > +sphinx = find_program('sphinx-build', required:
> > > get_option('enable_docs'))
> > > +
> > > +if sphinx.found()
> > > + html_guides_build = custom_target('html_guides_build',
> > > + input: meson.current_source_dir(),
> > > + output: 'index.html',
> > 
> > As we discussed I don't have a good solution, but right now running
> > ninja will rebuild these sphinx docs again and again, which will be a
> > bit annoying when using enable_docs=true as it will always happen.
> > Changing output to 'html' fixes the issue and it makes it build only
> > once, but then they won't rebuild if the docs change as you noted.
> > 
> > > + command: [sphinx, '-b', 'html', '@INPUT@',
> > > meson.current_build_dir() + '/html'],
> > > + build_by_default: false,
> > > + install: get_option('enable_docs'))
> > > +
> > > + doc_targets += html_guides_build
> > > + doc_target_names += 'HTML_Guides'
> > > +endif
> > > diff --git a/doc/meson.build b/doc/meson.build
> > > index afca2e713..c5410d85d 100644
> > > --- a/doc/meson.build
> > > +++ b/doc/meson.build
> > > @@ -1,4 +1,15 @@
> > >  # SPDX-License-Identifier: BSD-3-Clause
> > >  # Copyright(c) 2018 Luca Boccassi 
> > >  
> > > +doc_targets = []
> > > +doc_target_names = []
> > >  subdir('api')
> > > +subdir('guides')
> > > +
> > > +if doc_targets.length() == 0
> > > + message = 'No docs targets found'
> > > +else
> > > + message = 'Building docs:'
> > > +endif
> > > +run_target('doc', command: ['echo', message, doc_target_names],
> > > + depends: doc_targets)
> > 
> > One thing that's missing is the install_dir, without which ninja
> > install doesn't work (actually errors out for the whole tree).
> > 
> > To keep the install the same as the legacy makefiles this diff is
> > needed (I need to change the outdir in the doxygen stuff too, v5
> > coming) (in the build dir it will be slightly awkward as it's
> > build/doc/guides/guides and build/doc/api/api, but I can't find
> > another
> > way to get it to work and install in the expected directories):
> > 
> > --- a/doc/guides/meson.build
> > +++ b/doc/guides/meson.build
> > @@ -4,12 +4,14 @@
> >  sphinx = find_program('sphinx-build', required:
> > get_option('enable_docs'))
> >  
> >  if sphinx.found()
> > +   htmldir = join_paths('share', 'doc', 'dpdk')
> > html_guides_build = custom_target('html_guides_build',
> > input: meson.current_source_dir(),
> > -   output: 'index.html',
> > -   command: [sphinx, '-b', 'html', '@INPUT@',
> > meson.current_build_dir() + '/html'],
> > +   output: 'guides',
> > +   command: [sphinx, '-b', 'html', '@INPUT@',
> > meson.current_build_dir() + '/guides'],
> > build_by_default: false,
> > -   install: get_option('enable_docs'))
> > +   install: get_option('enable_docs'),
> > +   install_dir: htmldir)
> >  
> > doc_targets += html_guides_build
> > doc_target_names += 'HTML_Guides'
> 
> Couple more issues: I diffed the installed doc with ye olde make and
> this one, and:
> 
> 1) This one will install sphinx temporary cache files, which among
> other things will screw up reproducible builds. It's easy to get rid of
> the .doctrees by adding the following to the sphinx command:
> 
>  '-d', meson.current_build_dir() + '/.doctrees'
> 
> so that the doctrees are stored in the build directory, rather than in
> the output directory, and so they will not be installed.
> But the .buildinfo file, 

Re: [dpdk-dev] [PATCH] doc: support building HTML guides with meson

[Luca Boccassi]

On Wed, 2018-09-12 at 10:36 +0100, Bruce Richardson wrote:
> On Tue, Sep 11, 2018 at 10:47:58PM +0100, Luca Boccassi wrote:
> > On Tue, 2018-09-11 at 21:36 +0100, Luca Boccassi wrote:
> > > On Tue, 2018-09-11 at 17:13 +0100, Bruce Richardson wrote:
> > > > Signed-off-by: Bruce Richardson 
> > > > ---
> > > > NOTE: this patch depends upon:
> > > > http://patches.dpdk.org/project/dpdk/list/?series=1232
> > > 
> > > Just a reminder that's v2, and the patch won't apply cleanly on
> > > the
> > > latest revision
> > > 
> > > >  doc/api/meson.build|  3 ++-
> > > >  doc/guides/meson.build | 16 
> > > >  doc/meson.build| 11 +++
> > > >  3 files changed, 29 insertions(+), 1 deletion(-)
> > > >  create mode 100644 doc/guides/meson.build
> > > > 
> > > > diff --git a/doc/api/meson.build b/doc/api/meson.build
> > > > index 5dfa0fe04..f9bee4dac 100644
> > > > --- a/doc/api/meson.build
> > > > +++ b/doc/api/meson.build
> > > > @@ -50,5 +50,6 @@ if doxygen.found()
> > > >     install_dir: htmldir,
> > > >     build_by_default: false)
> > > >  
> > > > -   run_target('doc', command: 'true', depends:
> > > > doxy_build)
> > > > +   doc_targets += doxy_build
> > > > +   doc_target_names += 'Doxygen_API'
> > > >  endif
> > > > diff --git a/doc/guides/meson.build b/doc/guides/meson.build
> > > > new file mode 100644
> > > > index 0..6d1e2990d
> > > > --- /dev/null
> > > > +++ b/doc/guides/meson.build
> > > > @@ -0,0 +1,16 @@
> > > > +# SPDX-License-Identifier: BSD-3-Clause
> > > > +# Copyright(c) 2017 Intel Corporation
> > > 
> > > s/2017/2018
> > > 
> > > > +sphinx = find_program('sphinx-build', required:
> > > > get_option('enable_docs'))
> > > > +
> > > > +if sphinx.found()
> > > > +   html_guides_build = custom_target('html_guides_build',
> > > > +   input: meson.current_source_dir(),
> > > > +   output: 'index.html',
> > > 
> > > As we discussed I don't have a good solution, but right now
> > > running
> > > ninja will rebuild these sphinx docs again and again, which will
> > > be a
> > > bit annoying when using enable_docs=true as it will always
> > > happen.
> > > Changing output to 'html' fixes the issue and it makes it build
> > > only
> > > once, but then they won't rebuild if the docs change as you
> > > noted.
> > > 
> > > > +   command: [sphinx, '-b', 'html', '@INPUT@',
> > > > meson.current_build_dir() + '/html'],
> > > > +   build_by_default: false,
> > > > +   install: get_option('enable_docs'))
> > > > +
> > > > +   doc_targets += html_guides_build
> > > > +   doc_target_names += 'HTML_Guides'
> > > > +endif
> > > > diff --git a/doc/meson.build b/doc/meson.build
> > > > index afca2e713..c5410d85d 100644
> > > > --- a/doc/meson.build
> > > > +++ b/doc/meson.build
> > > > @@ -1,4 +1,15 @@
> > > >  # SPDX-License-Identifier: BSD-3-Clause
> > > >  # Copyright(c) 2018 Luca Boccassi 
> > > >  
> > > > +doc_targets = []
> > > > +doc_target_names = []
> > > >  subdir('api')
> > > > +subdir('guides')
> > > > +
> > > > +if doc_targets.length() == 0
> > > > +   message = 'No docs targets found'
> > > > +else
> > > > +   message = 'Building docs:'
> > > > +endif
> > > > +run_target('doc', command: ['echo', message,
> > > > doc_target_names],
> > > > +   depends: doc_targets)
> > > 
> > > One thing that's missing is the install_dir, without which ninja
> > > install doesn't work (actually errors out for the whole tree).
> > > 
> > > To keep the install the same as the legacy makefiles this diff is
> > > needed (I need to change the outdir in the doxygen stuff too, v5
> > > coming) (in the build dir it will be slightly awkward as it's
> > > build/doc/guides/guides and build/doc/api/api, but I can't find
> > > another
> > > way to get it to work and install in the expected directories):
> > > 
> > > --- a/doc/guides/meson.build
> > > +++ b/doc/guides/meson.build
> > > @@ -4,12 +4,14 @@
> > >  sphinx = find_program('sphinx-build', required:
> > > get_option('enable_docs'))
> > >  
> > >  if sphinx.found()
> > > +   htmldir = join_paths('share', 'doc', 'dpdk')
> > > html_guides_build = custom_target('html_guides_build',
> > > input: meson.current_source_dir(),
> > > -   output: 'index.html',
> > > -   command: [sphinx, '-b', 'html', '@INPUT@',
> > > meson.current_build_dir() + '/html'],
> > > +   output: 'guides',
> > > +   command: [sphinx, '-b', 'html', '@INPUT@',
> > > meson.current_build_dir() + '/guides'],
> > > build_by_default: false,
> > > -   install: get_option('enable_docs'))
> > > +   install: get_option('enable_docs'),
> > > +   install_dir: htmldir)
> > >  
> > > doc_targets += html_guides_build
> > > doc_target_names += 'HTML_Guides'
> > 
> > Couple more issues: I diffed the installed doc with ye olde make
> 

Re: [dpdk-dev] [PATCH v5 04/11] net/virtio: flush packed receive virtqueues

[Jens Freimann]

On Wed, Sep 12, 2018 at 11:12:50AM +0200, Maxime Coquelin wrote:

On 09/06/2018 08:19 PM, Jens Freimann wrote:

[...]

+   if (vtpci_packed_queue(vq->hw)) {
+   i = vq->vq_used_cons_idx;
+   while (desc_is_used(&descs[i], &vq->vq_ring) &&
+   i < vq->vq_nentries) {

It may be preferable to ensure 'i' is within the ring size before using
it in desc_is_used(). And raise (at least) an error message if it isn't.


Yes, I'll fix this. Thanks!

regards,
Jens 

Re: [dpdk-dev] [PATCH] doc: support building HTML guides with meson

[Bruce Richardson]

On Wed, Sep 12, 2018 at 10:48:15AM +0100, Luca Boccassi wrote:
> On Wed, 2018-09-12 at 10:36 +0100, Bruce Richardson wrote:
> > On Tue, Sep 11, 2018 at 10:47:58PM +0100, Luca Boccassi wrote:
> > > On Tue, 2018-09-11 at 21:36 +0100, Luca Boccassi wrote:
> > > > On Tue, 2018-09-11 at 17:13 +0100, Bruce Richardson wrote:
> > > > > Signed-off-by: Bruce Richardson 
> > > > > ---
> > > > > NOTE: this patch depends upon:
> > > > > http://patches.dpdk.org/project/dpdk/list/?series=1232
> > > > 
> > > > Just a reminder that's v2, and the patch won't apply cleanly on
> > > > the
> > > > latest revision
> > > > 
> > > > >  doc/api/meson.build|  3 ++-
> > > > >  doc/guides/meson.build | 16 
> > > > >  doc/meson.build| 11 +++
> > > > >  3 files changed, 29 insertions(+), 1 deletion(-)
> > > > >  create mode 100644 doc/guides/meson.build
> > > > > 
> > > > > diff --git a/doc/api/meson.build b/doc/api/meson.build
> > > > > index 5dfa0fe04..f9bee4dac 100644
> > > > > --- a/doc/api/meson.build
> > > > > +++ b/doc/api/meson.build
> > > > > @@ -50,5 +50,6 @@ if doxygen.found()
> > > > >   install_dir: htmldir,
> > > > >   build_by_default: false)
> > > > >  
> > > > > - run_target('doc', command: 'true', depends:
> > > > > doxy_build)
> > > > > + doc_targets += doxy_build
> > > > > + doc_target_names += 'Doxygen_API'
> > > > >  endif
> > > > > diff --git a/doc/guides/meson.build b/doc/guides/meson.build
> > > > > new file mode 100644
> > > > > index 0..6d1e2990d
> > > > > --- /dev/null
> > > > > +++ b/doc/guides/meson.build
> > > > > @@ -0,0 +1,16 @@
> > > > > +# SPDX-License-Identifier: BSD-3-Clause
> > > > > +# Copyright(c) 2017 Intel Corporation
> > > > 
> > > > s/2017/2018
> > > > 
> > > > > +sphinx = find_program('sphinx-build', required:
> > > > > get_option('enable_docs'))
> > > > > +
> > > > > +if sphinx.found()
> > > > > + html_guides_build = custom_target('html_guides_build',
> > > > > + input: meson.current_source_dir(),
> > > > > + output: 'index.html',
> > > > 
> > > > As we discussed I don't have a good solution, but right now
> > > > running
> > > > ninja will rebuild these sphinx docs again and again, which will
> > > > be a
> > > > bit annoying when using enable_docs=true as it will always
> > > > happen.
> > > > Changing output to 'html' fixes the issue and it makes it build
> > > > only
> > > > once, but then they won't rebuild if the docs change as you
> > > > noted.
> > > > 
> > > > > + command: [sphinx, '-b', 'html', '@INPUT@',
> > > > > meson.current_build_dir() + '/html'],
> > > > > + build_by_default: false,
> > > > > + install: get_option('enable_docs'))
> > > > > +
> > > > > + doc_targets += html_guides_build
> > > > > + doc_target_names += 'HTML_Guides'
> > > > > +endif
> > > > > diff --git a/doc/meson.build b/doc/meson.build
> > > > > index afca2e713..c5410d85d 100644
> > > > > --- a/doc/meson.build
> > > > > +++ b/doc/meson.build
> > > > > @@ -1,4 +1,15 @@
> > > > >  # SPDX-License-Identifier: BSD-3-Clause
> > > > >  # Copyright(c) 2018 Luca Boccassi 
> > > > >  
> > > > > +doc_targets = []
> > > > > +doc_target_names = []
> > > > >  subdir('api')
> > > > > +subdir('guides')
> > > > > +
> > > > > +if doc_targets.length() == 0
> > > > > + message = 'No docs targets found'
> > > > > +else
> > > > > + message = 'Building docs:'
> > > > > +endif
> > > > > +run_target('doc', command: ['echo', message,
> > > > > doc_target_names],
> > > > > + depends: doc_targets)
> > > > 
> > > > One thing that's missing is the install_dir, without which ninja
> > > > install doesn't work (actually errors out for the whole tree).
> > > > 
> > > > To keep the install the same as the legacy makefiles this diff is
> > > > needed (I need to change the outdir in the doxygen stuff too, v5
> > > > coming) (in the build dir it will be slightly awkward as it's
> > > > build/doc/guides/guides and build/doc/api/api, but I can't find
> > > > another
> > > > way to get it to work and install in the expected directories):
> > > > 
> > > > --- a/doc/guides/meson.build
> > > > +++ b/doc/guides/meson.build
> > > > @@ -4,12 +4,14 @@
> > > >  sphinx = find_program('sphinx-build', required:
> > > > get_option('enable_docs'))
> > > >  
> > > >  if sphinx.found()
> > > > +   htmldir = join_paths('share', 'doc', 'dpdk')
> > > > html_guides_build = custom_target('html_guides_build',
> > > > input: meson.current_source_dir(),
> > > > -   output: 'index.html',
> > > > -   command: [sphinx, '-b', 'html', '@INPUT@',
> > > > meson.current_build_dir() + '/html'],
> > > > +   output: 'guides',
> > > > +   command: [sphinx, '-b', 'html', '@INPUT@',
> > > > meson.current_build_dir() + '/guides'],
> > > > build_by_default: false,
> > > > -   install: get_option('enable_docs'))
> > > > + 

Re: [dpdk-dev] [PATCH v2] app/testpmd: optimize membuf pool allocation

[Iremonger, Bernard]

> -Original Message-
> From: phil.y...@arm.com [mailto:phil.y...@arm.com]
> Sent: Wednesday, September 12, 2018 2:54 AM
> To: dev@dpdk.org
> Cc: Iremonger, Bernard ; gavin...@arm.com;
> sta...@dpdk.org; phil.y...@arm.com
> Subject: [PATCH v2] app/testpmd: optimize membuf pool allocation
> 
> By default, testpmd will create membuf pool for all NUMA nodes and ignore EAL
> configuration.
> 
> Count the number of available NUMA according to EAL core mask or core list
> configuration. Optimized by only creating membuf pool for those nodes.
> 
> Fixes: c9cafcc ("app/testpmd: fix mempool creation by socket id")
> 
> Signed-off-by: Phil Yang 
> Acked-by: Gavin Hu 

Acked-by: Bernard Iremonger 

[dpdk-dev] [PATCH v5] net/i40e: add interface to choose latest vector path

[Xiaoyun Li]

Right now, vector path is limited to only use on later platform.
This patch adds a devarg use-latest-vec to allow the users to
use the latest vector path that the platform supported. Namely,
using AVX2 vector path on broadwell is possible.

Signed-off-by: Xiaoyun Li 
---
v5:
 * Simpify the rx set function.
v4:
 * Polish the codes.
v3:
 * Polish the doc and commit log.
v2:
 * Correct the calling of the wrong function last time.
 * Fix seg fault bug.
---
 doc/guides/nics/i40e.rst   |   8 ++
 doc/guides/rel_notes/release_18_11.rst |   4 +
 drivers/net/i40e/i40e_ethdev.c |  46 +++-
 drivers/net/i40e/i40e_ethdev.h |   3 +
 drivers/net/i40e/i40e_rxtx.c   | 143 +
 5 files changed, 136 insertions(+), 68 deletions(-)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 65d87f869..643e6a062 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -163,6 +163,14 @@ Runtime Config Options
   Currently hot-plugging of representor ports is not supported so all required
   representors must be specified on the creation of the PF.
 
+- ``Use latest vector`` (default ``disable``)
+
+  Vector path was limited to use only on later platform. But users may want the
+  latest vector path. For example, VPP users may want to use AVX2 vector path 
on HSW/BDW
+  because it can get better perf. So ``devargs`` parameter ``use-latest-vec`` 
is
+  introduced, for example::
+-w 84:00.0,use-latest-vec=1
+
 Driver compilation and testing
 --
 
diff --git a/doc/guides/rel_notes/release_18_11.rst 
b/doc/guides/rel_notes/release_18_11.rst
index 3ae6b3f58..34af591a2 100644
--- a/doc/guides/rel_notes/release_18_11.rst
+++ b/doc/guides/rel_notes/release_18_11.rst
@@ -54,6 +54,10 @@ New Features
  Also, make sure to start the actual text at the margin.
  =
 
+* **Added a devarg to use the latest vector path.**
+  A new devarg ``use-latest-vec`` was introduced to allow users to choose
+  the latest vector path that the platform supported. For example, VPP users
+  can use AVX2 vector path on BDW/HSW to get better performance.
 
 API Changes
 ---
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 85a6a867f..72377d0b6 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -44,6 +44,7 @@
 #define ETH_I40E_FLOATING_VEB_LIST_ARG "floating_veb_list"
 #define ETH_I40E_SUPPORT_MULTI_DRIVER  "support-multi-driver"
 #define ETH_I40E_QUEUE_NUM_PER_VF_ARG  "queue-num-per-vf"
+#define ETH_I40E_USE_LATEST_VEC"use-latest-vec"
 
 #define I40E_CLEAR_PXE_WAIT_MS 200
 
@@ -408,6 +409,7 @@ static const char *const valid_keys[] = {
ETH_I40E_FLOATING_VEB_LIST_ARG,
ETH_I40E_SUPPORT_MULTI_DRIVER,
ETH_I40E_QUEUE_NUM_PER_VF_ARG,
+   ETH_I40E_USE_LATEST_VEC,
NULL};
 
 static const struct rte_pci_id pci_id_i40e_map[] = {
@@ -1201,6 +1203,46 @@ i40e_aq_debug_write_global_register(struct i40e_hw *hw,
return i40e_aq_debug_write_register(hw, reg_addr, reg_val, cmd_details);
 }
 
+static int
+i40e_parse_latest_vec(struct rte_eth_dev *dev)
+{
+   struct i40e_adapter *ad =
+   I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
+   int kvargs_count, use_latest_vec;
+   struct rte_kvargs *kvlist;
+
+   ad->use_latest_vec = false;
+
+   if (!dev->device->devargs)
+   return 0;
+
+   kvlist = rte_kvargs_parse(dev->device->devargs->args, valid_keys);
+   if (!kvlist)
+   return -EINVAL;
+
+   kvargs_count = rte_kvargs_count(kvlist, ETH_I40E_USE_LATEST_VEC);
+   if (!kvargs_count) {
+   rte_kvargs_free(kvlist);
+   return 0;
+   }
+
+   if (kvargs_count > 1)
+   PMD_DRV_LOG(WARNING, "More than one argument \"%s\" and only "
+   "the first one is used !",
+   ETH_I40E_USE_LATEST_VEC);
+
+   use_latest_vec = atoi((&kvlist->pairs[0])->value);
+
+   rte_kvargs_free(kvlist);
+
+   if (use_latest_vec != 0 && use_latest_vec != 1)
+   PMD_DRV_LOG(WARNING, "Value should be 0 or 1, set it as 1!");
+
+   ad->use_latest_vec = (bool)use_latest_vec;
+
+   return 0;
+}
+
 static int
 eth_i40e_dev_init(struct rte_eth_dev *dev, void *init_params __rte_unused)
 {
@@ -1263,6 +1305,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev, void 
*init_params __rte_unused)
 
/* Check if need to support multi-driver */
i40e_support_multi_driver(dev);
+   i40e_parse_latest_vec(dev);
 
/* Make sure all is clean before doing PF reset */
i40e_clear_hw(hw);
@@ -12527,4 +12570,5 @@ RTE_PMD_REGISTER_PARAM_STRING(net_i40e,
  ETH_I40E_FLOATING_VEB_ARG "=1"
  ETH_I40E_FLOATING_VEB_LIST_ARG "="
  ETH_I40E

Re: [dpdk-dev] [PATCH v1 2/7] lib/power: add changes for host commands/policies

[Hunt, David]

Hi Stephen,

On 30/8/2018 5:59 PM, Stephen Hemminger wrote:

On Thu, 30 Aug 2018 11:54:17 +0100
David Hunt  wrote:


Signed-off-by: David Hunt 
---
  lib/librte_power/channel_commands.h | 4 
  1 file changed, 4 insertions(+)

diff --git a/lib/librte_power/channel_commands.h 
b/lib/librte_power/channel_commands.h
index ee638eefa..a82724911 100644
--- a/lib/librte_power/channel_commands.h
+++ b/lib/librte_power/channel_commands.h
@@ -19,6 +19,7 @@ extern "C" {
  #define CPU_POWER   1
  #define CPU_POWER_CONNECT   2
  #define PKT_POLICY  3
+#define PKT_POLICY_REMOVE   4
  
  /* CPU Power Command Scaling */

  #define CPU_POWER_SCALE_UP  1
@@ -58,6 +59,8 @@ struct traffic {
uint32_t max_max_packet_thresh;
  };
  
+enum core_type { VIRTUAL = 0, PHYSICAL };

+

Why this enum, looks like a boolean to me.


I'll change this to a 'bool' in the next version.

Thanks,
Dave.

Re: [dpdk-dev] [PATCH v1 1/7] examples/power: add checks around hypervisor

[Hunt, David]

Hi Stephen,


On 30/8/2018 5:59 PM, Stephen Hemminger wrote:

On Thu, 30 Aug 2018 11:54:16 +0100
David Hunt  wrote:

Minor nits


+static unsigned int global_hypervisor_available;

Please use bool for boolean values.


Will change in next revision.



  /*
   * Represents a single Virtual Machine
@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned 
vcpu)
  {
struct virtual_machine_info *vm_info =
(struct virtual_machine_info *)chan_info->priv_info;
-   return rte_atomic64_read(&vm_info->pcpu_mask[vcpu]);
+
+   if ((global_hypervisor_available) && (vm_info != NULL))


  parenthesis are unnecessary here.


Fixed in next version.



I know this is pre-existing, but please don't use CamelCase:

+   if (virNodeGetInfo(global_vir_conn_ptr, &info)) {


Unfortunately I've no control over this, it's part of the libvirt API.

Thanks,
Dave.

Re: [dpdk-dev] [PATCH v1 5/7] examples/power: add json string handling

[Hunt, David]

Hi Stephen,


On 30/8/2018 6:00 PM, Stephen Hemminger wrote:

On Thu, 30 Aug 2018 11:54:20 +0100
David Hunt  wrote:


Add JSON string handling to vm_power_manager for JSON strings received
through the fifo. The format of the JSON strings are detailed in the
next patch, the vm_power_manager user guide documentation updates.

This patch introduces a new dependency on Jansson, a C library for
encoding, decoding and manipulating JSON data. To compile the sample app
you now need to have installed libjansson4 and libjansson-dev (these may
be named slightly differently depending on your Operating System)

Signed-off-by: David Hunt 

If you introduce new dependency then it has to be in documentation,
and off by default in Makefile, and checked in meson build.


Sure, I've added a check in the Makefile for the existence of the 
library, and it will build in the

JSON handling if present, otherwise warn the user and build without.

Thanks,
Dave.

Re: [dpdk-dev] Reg: "Query in DPDK HQOS "

[Dumitrescu, Cristian]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Prabakar Prabakar
> Sent: Wednesday, September 12, 2018 10:01 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] Reg: "Query in DPDK HQOS "
> 
> Hi
> i have query with respect to HQos.
> 
> why number of queues in traffic class is fixed to *4*.  And it was
> mentioned that "*cannot be changed*".
> 
> RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS  *4*
> 
> link :
> http://doc.dpdk.org/api-
> 17.11/rte__sched_8h.html#a326fddd15331c0fd66c7a181a6b43e29
> 
> Any reason behind this, Please help.
> 
> 
> Regards,
> Prabakar k

Hi Prabakar,

This assumption is built into multiple places throughout the implementation. 
This comment means that changing the value of this parameter to any value other 
than 4 will not be picked up seamlessly, i.e. the code will no longer work 
correctly, therefore it should not be changed.

Regards,
Cristian

Re: [dpdk-dev] [PATCH v1 6/7] doc/vm_power_manager: add JSON interface API info

[Hunt, David]

Hi Lei,


On 4/9/2018 6:17 AM, Yao, Lei A wrote:



-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Hunt
Sent: Thursday, August 30, 2018 6:54 PM
To: dev@dpdk.org
Cc: Mcnamara, John ; Hunt, David

Subject: [dpdk-dev] [PATCH v1 6/7] doc/vm_power_manager: add JSON
interface API info

Signed-off-by: David Hunt 
---
  .../sample_app_ug/vm_power_management.rst | 195
++
  1 file changed, 195 insertions(+)

diff --git a/doc/guides/sample_app_ug/vm_power_management.rst
b/doc/guides/sample_app_ug/vm_power_management.rst
index 855570d6b..13a325eae 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -337,6 +337,201 @@ monitoring of branch ratio on cores doing busy
polling via PMDs.
and will need to be adjusted for different workloads.


+
+JSON API
+
+

--snip--

+:Pair Name: "quiet_hours"
+:Description: The hours of the day in which we scale down the cores for
quiet
+  times.
+:Type: array of integers
+:Values: array with list of hour numbers, (0-23)
+:Required: only for TIME policy
+:Example:
+
+  .. code-block:: console
+
+"quiet_hours":[ 2, 3, 4, 5, 6 ]
+

Do you think we need document following three key here?
min_packet_thresh
avg_packet_thresh
max_packet_thresh
I see them in the code but not documented.



Good catch. I missed these in the docs. Also I checked the code there 
these are

used, and only two are needed. These are avg and max.
Below, avg, the freq is set to minimum
Between avg and max, the freq us set to medium
Above max, the freq is set to maximum.

I'll remove the minimum from the code, seeing as it's not used, and 
document avg and max.


Rgds,
Dave.

--snip--

Re: [dpdk-dev] [PATCH 01/21] net/atlantic: atlantic PMD driver skeleton

[Igor Russkikh]

On 11.09.2018 20:02, Stephen Hemminger wrote:
> On Fri,  7 Sep 2018 18:21:39 +0300
> Igor Russkikh  wrote:
> 
>> +#CFLAGS_BASE_DRIVER = -Wno-unused-parameter -Wno-unused-value
>> +CFLAGS_BASE_DRIVER += -Wno-strict-aliasing -Wno-format-extra-args
> 
> Can't you fix your code to get rid of these errors?

Thanks Stephen for all your comments, we are in progress fixing them,
as well as some bsd build failures we've got from patchwork automation.

Re: [dpdk-dev] [PATCH v1 4/7] examples/power: add host channel to power manager

[Hunt, David]

Hi Lei,


On 4/9/2018 8:31 AM, Yao, Lei A wrote:



-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Hunt
Sent: Thursday, August 30, 2018 6:54 PM
To: dev@dpdk.org
Cc: Mcnamara, John ; Hunt, David

Subject: [dpdk-dev] [PATCH v1 4/7] examples/power: add host channel to
power manager

This patch adds a fifo channel to the vm_power_manager app through which
we can send commands and polices. Intended for sending JSON strings.
The fifo is at /tmp/powermonitor/fifo.0

Signed-off-by: David Hunt 
---
  examples/vm_power_manager/channel_manager.c | 108
+++
  examples/vm_power_manager/channel_manager.h |  17 ++-
  examples/vm_power_manager/channel_monitor.c | 146
+++-
  examples/vm_power_manager/main.c|   2 +
  4 files changed, 238 insertions(+), 35 deletions(-)

diff --git a/examples/vm_power_manager/channel_manager.c
b/examples/vm_power_manager/channel_manager.c
index 2bb8641d3..bcd106be1 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -13,6 +13,7 @@


--snip--



@@ -160,8 +199,13 @@ update_policy(struct channel_packet *pkt)
unsigned int updated = 0;
int i;

+
+   RTE_LOG(INFO, CHANNEL_MONITOR,
+   "Updating policy for %s\n", pkt->vm_name);
+
for (i = 0; i < MAX_VMS; i++) {
if (strcmp(policies[i].pkt.vm_name, pkt->vm_name) == 0) {

I suggest add warning log here when no VM can match the policy name
which we send through the fifo.0. Otherwise, the user can't aware the
policy won't be applied.


There's already a flag here called "updated" that if it falls through 
this loop without finding the policy name, it adds a new one, so no need 
for the message.
I will however re-word the "Updating policy" message to read "Applying 
policy". "Applying" is less confusing.


Thanks,
Dave.


---snip---

Re: [dpdk-dev] [PATCH] doc: support building HTML guides with meson

[Luca Boccassi]

On Wed, 2018-09-12 at 11:13 +0100, Bruce Richardson wrote:
> On Wed, Sep 12, 2018 at 10:48:15AM +0100, Luca Boccassi wrote:
> > On Wed, 2018-09-12 at 10:36 +0100, Bruce Richardson wrote:
> > > On Tue, Sep 11, 2018 at 10:47:58PM +0100, Luca Boccassi wrote:
> > > > On Tue, 2018-09-11 at 21:36 +0100, Luca Boccassi wrote:
> > > > > On Tue, 2018-09-11 at 17:13 +0100, Bruce Richardson wrote:
> > > > > > Signed-off-by: Bruce Richardson  > > > > > >
> > > > > > ---
> > > > > > NOTE: this patch depends upon:
> > > > > > http://patches.dpdk.org/project/dpdk/list/?series=1232
> > > > > 
> > > > > Just a reminder that's v2, and the patch won't apply cleanly
> > > > > on
> > > > > the
> > > > > latest revision
> > > > > 
> > > > > >  doc/api/meson.build|  3 ++-
> > > > > >  doc/guides/meson.build | 16 
> > > > > >  doc/meson.build| 11 +++
> > > > > >  3 files changed, 29 insertions(+), 1 deletion(-)
> > > > > >  create mode 100644 doc/guides/meson.build
> > > > > > 
> > > > > > diff --git a/doc/api/meson.build b/doc/api/meson.build
> > > > > > index 5dfa0fe04..f9bee4dac 100644
> > > > > > --- a/doc/api/meson.build
> > > > > > +++ b/doc/api/meson.build
> > > > > > @@ -50,5 +50,6 @@ if doxygen.found()
> > > > > >     install_dir: htmldir,
> > > > > >     build_by_default: false)
> > > > > >  
> > > > > > -   run_target('doc', command: 'true', depends:
> > > > > > doxy_build)
> > > > > > +   doc_targets += doxy_build
> > > > > > +   doc_target_names += 'Doxygen_API'
> > > > > >  endif
> > > > > > diff --git a/doc/guides/meson.build
> > > > > > b/doc/guides/meson.build
> > > > > > new file mode 100644
> > > > > > index 0..6d1e2990d
> > > > > > --- /dev/null
> > > > > > +++ b/doc/guides/meson.build
> > > > > > @@ -0,0 +1,16 @@
> > > > > > +# SPDX-License-Identifier: BSD-3-Clause
> > > > > > +# Copyright(c) 2017 Intel Corporation
> > > > > 
> > > > > s/2017/2018
> > > > > 
> > > > > > +sphinx = find_program('sphinx-build', required:
> > > > > > get_option('enable_docs'))
> > > > > > +
> > > > > > +if sphinx.found()
> > > > > > +   html_guides_build =
> > > > > > custom_target('html_guides_build',
> > > > > > +   input: meson.current_source_dir(),
> > > > > > +   output: 'index.html',
> > > > > 
> > > > > As we discussed I don't have a good solution, but right now
> > > > > running
> > > > > ninja will rebuild these sphinx docs again and again, which
> > > > > will
> > > > > be a
> > > > > bit annoying when using enable_docs=true as it will always
> > > > > happen.
> > > > > Changing output to 'html' fixes the issue and it makes it
> > > > > build
> > > > > only
> > > > > once, but then they won't rebuild if the docs change as you
> > > > > noted.
> > > > > 
> > > > > > +   command: [sphinx, '-b', 'html', '@INPUT@',
> > > > > > meson.current_build_dir() + '/html'],
> > > > > > +   build_by_default: false,
> > > > > > +   install: get_option('enable_docs'))
> > > > > > +
> > > > > > +   doc_targets += html_guides_build
> > > > > > +   doc_target_names += 'HTML_Guides'
> > > > > > +endif
> > > > > > diff --git a/doc/meson.build b/doc/meson.build
> > > > > > index afca2e713..c5410d85d 100644
> > > > > > --- a/doc/meson.build
> > > > > > +++ b/doc/meson.build
> > > > > > @@ -1,4 +1,15 @@
> > > > > >  # SPDX-License-Identifier: BSD-3-Clause
> > > > > >  # Copyright(c) 2018 Luca Boccassi 
> > > > > >  
> > > > > > +doc_targets = []
> > > > > > +doc_target_names = []
> > > > > >  subdir('api')
> > > > > > +subdir('guides')
> > > > > > +
> > > > > > +if doc_targets.length() == 0
> > > > > > +   message = 'No docs targets found'
> > > > > > +else
> > > > > > +   message = 'Building docs:'
> > > > > > +endif
> > > > > > +run_target('doc', command: ['echo', message,
> > > > > > doc_target_names],
> > > > > > +   depends: doc_targets)
> > > > > 
> > > > > One thing that's missing is the install_dir, without which
> > > > > ninja
> > > > > install doesn't work (actually errors out for the whole
> > > > > tree).
> > > > > 
> > > > > To keep the install the same as the legacy makefiles this
> > > > > diff is
> > > > > needed (I need to change the outdir in the doxygen stuff too,
> > > > > v5
> > > > > coming) (in the build dir it will be slightly awkward as it's
> > > > > build/doc/guides/guides and build/doc/api/api, but I can't
> > > > > find
> > > > > another
> > > > > way to get it to work and install in the expected
> > > > > directories):
> > > > > 
> > > > > --- a/doc/guides/meson.build
> > > > > +++ b/doc/guides/meson.build
> > > > > @@ -4,12 +4,14 @@
> > > > >  sphinx = find_program('sphinx-build', required:
> > > > > get_option('enable_docs'))
> > > > >  
> > > > >  if sphinx.found()
> > > > > +   htmldir = join_paths('share', 'doc', 'dpdk')
> > > > > html_guides_build =
> > > > > custom_target('html_guides_build',
> > > > > input: meson.current_source_dir(),
> > > > > -   output: 'index.html'

Re: [dpdk-dev] [PATCH v2] eal: add strscpy function

[Ferruh Yigit]

On 9/11/2018 4:00 PM, Gaetan Rivet wrote:
> The strncpy function has long been deemed unsafe for use,
> in favor of strlcpy or snprintf.
> 
> While snprintf is standard and strlcpy is still largely available,
> they both have issues regarding error checking and performance.
> 
> Both will force reading the source buffer past the requested size
> if the input is not a proper c-string, and will return the expected
> number of bytes copied, meaning that error checking needs to verify
> that the number of bytes copied is not superior to the destination
> size.
> 
> This contributes to awkward code flow, unclear error checking and
> potential issues with malformed input.
> 
> The function strscpy has been discussed for some time already and
> has been made available in the linux kernel[1].
> 
> Propose this new function as a safe alternative.
> 
> [1]: http://git.kernel.org/linus/30c44659f4a3
> 
> Signed-off-by: Gaetan Rivet 
> Acked-by: Juhamatti Kuusisaari 

Acked-by: Ferruh Yigit 

[dpdk-dev] [PATCH v2 0/7] add json power policy interface for containers

[David Hunt]

Patch v2:
  * Fixed review comments from Stephen Hemminger and Lei A Yao.
  * Added a check in the Makefile for libjansson-dev. Will Warn user and build
without JSON functionality if not present, will build including JSON
functionality if it is present.

The current vm_power_manager example app has the capability to accept power
policies from virtual machines via virtio-serial channels. These power
policies  allow a virtual machine to give information to the power manager
to allow the power manager take care of the power management of the virtual
machine based on the information in the policy.

This power policy functionality is limited to virtual machines sending
the policies to the power manager (which runs in the Host OS), and a solution
was needed for additional methods of sending power policies to the power
manager app.

The main use-case for this modification is for containers and host
applications that wish to send polices to the power manager.

This patchset adds the capability to send power polices and power commands
to the vm_power_manager app via JSON strings through a fifo on the file
system.
For example, given the following file, policy.json:

{"policy": {
  "name": "ubuntu2",
  "command": "create",
  "policy_type": "TIME",
  "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ],
  "quiet_hours":[ 2, 3, 4, 5, 6 ],
  "core_list":[ 11, 12, 13 ]
}}

Then running the command:

cat policy.json >/tmp/powermonitor/fifo.0

The policy is sent to the vm_power_manager. The power manager app then parses
the JSON data, and inserts the policy into the array of policies.

Part of the patch series contains documentation updates to give all the
details of the valid name-value pairs, the data types, etc.

[1/7] examples/power: add checks around hypervisor
[2/7] lib/power: add changes for host commands/policies
[3/7] examples/power: add necessary changes to guest app
[4/7] examples/power: add host channel to power manager
[5/7] examples/power: add json string handling
[6/7] doc/vm_power_manager: add JSON interface API info
[7/7] examples/power: add json example files

[dpdk-dev] [PATCH v2 1/7] examples/power: add checks around hypervisor

[David Hunt]

Allow vm_power_manager to run without requiring qemu to be present
on the machine. This will be required for instances where the JSON
interface is used for commands and polices, without any VMs present.
A use case for this is a container enviromnent.

Signed-off-by: David Hunt 
---
 examples/vm_power_manager/channel_manager.c | 71 +
 examples/vm_power_manager/channel_monitor.c |  2 +-
 2 files changed, 44 insertions(+), 29 deletions(-)

diff --git a/examples/vm_power_manager/channel_manager.c 
b/examples/vm_power_manager/channel_manager.c
index 927fc35ab..2e471d0c1 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -43,7 +43,8 @@ static unsigned char *global_cpumaps;
 static virVcpuInfo *global_vircpuinfo;
 static size_t global_maplen;
 
-static unsigned global_n_host_cpus;
+static unsigned int global_n_host_cpus;
+static bool global_hypervisor_available;
 
 /*
  * Represents a single Virtual Machine
@@ -198,7 +199,11 @@ get_pcpus_mask(struct channel_info *chan_info, unsigned 
vcpu)
 {
struct virtual_machine_info *vm_info =
(struct virtual_machine_info *)chan_info->priv_info;
-   return rte_atomic64_read(&vm_info->pcpu_mask[vcpu]);
+
+   if (global_hypervisor_available && (vm_info != NULL))
+   return rte_atomic64_read(&vm_info->pcpu_mask[vcpu]);
+   else
+   return 0;
 }
 
 static inline int
@@ -559,6 +564,8 @@ get_all_vm(int *num_vm, int *num_vcpu)
VIR_CONNECT_LIST_DOMAINS_PERSISTENT;
unsigned int domain_flag = VIR_DOMAIN_VCPU_CONFIG;
 
+   if (!global_hypervisor_available)
+   return;
 
memset(global_cpumaps, 0, CHANNEL_CMDS_MAX_CPUS*global_maplen);
if (virNodeGetInfo(global_vir_conn_ptr, &node_info)) {
@@ -768,38 +775,42 @@ connect_hypervisor(const char *path)
}
return 0;
 }
-
 int
-channel_manager_init(const char *path)
+channel_manager_init(const char *path __rte_unused)
 {
virNodeInfo info;
 
LIST_INIT(&vm_list_head);
if (connect_hypervisor(path) < 0) {
-   RTE_LOG(ERR, CHANNEL_MANAGER, "Unable to initialize channel 
manager\n");
-   return -1;
-   }
-
-   global_maplen = VIR_CPU_MAPLEN(CHANNEL_CMDS_MAX_CPUS);
+   global_n_host_cpus = 64;
+   global_hypervisor_available = 0;
+   RTE_LOG(INFO, CHANNEL_MANAGER, "Unable to initialize channel 
manager\n");
+   } else {
+   global_hypervisor_available = 1;
+
+   global_maplen = VIR_CPU_MAPLEN(CHANNEL_CMDS_MAX_CPUS);
+
+   global_vircpuinfo = rte_zmalloc(NULL,
+   sizeof(*global_vircpuinfo) *
+   CHANNEL_CMDS_MAX_CPUS, RTE_CACHE_LINE_SIZE);
+   if (global_vircpuinfo == NULL) {
+   RTE_LOG(ERR, CHANNEL_MANAGER, "Error allocating memory 
for CPU Info\n");
+   goto error;
+   }
+   global_cpumaps = rte_zmalloc(NULL,
+   CHANNEL_CMDS_MAX_CPUS * global_maplen,
+   RTE_CACHE_LINE_SIZE);
+   if (global_cpumaps == NULL)
+   goto error;
 
-   global_vircpuinfo = rte_zmalloc(NULL, sizeof(*global_vircpuinfo) *
-   CHANNEL_CMDS_MAX_CPUS, RTE_CACHE_LINE_SIZE);
-   if (global_vircpuinfo == NULL) {
-   RTE_LOG(ERR, CHANNEL_MANAGER, "Error allocating memory for CPU 
Info\n");
-   goto error;
-   }
-   global_cpumaps = rte_zmalloc(NULL, CHANNEL_CMDS_MAX_CPUS * 
global_maplen,
-   RTE_CACHE_LINE_SIZE);
-   if (global_cpumaps == NULL) {
-   goto error;
+   if (virNodeGetInfo(global_vir_conn_ptr, &info)) {
+   RTE_LOG(ERR, CHANNEL_MANAGER, "Unable to retrieve node 
Info\n");
+   goto error;
+   }
+   global_n_host_cpus = (unsigned int)info.cpus;
}
 
-   if (virNodeGetInfo(global_vir_conn_ptr, &info)) {
-   RTE_LOG(ERR, CHANNEL_MANAGER, "Unable to retrieve node Info\n");
-   goto error;
-   }
 
-   global_n_host_cpus = (unsigned)info.cpus;
 
if (global_n_host_cpus > CHANNEL_CMDS_MAX_CPUS) {
RTE_LOG(WARNING, CHANNEL_MANAGER, "The number of host CPUs(%u) 
exceeds the "
@@ -811,7 +822,8 @@ channel_manager_init(const char *path)
 
return 0;
 error:
-   disconnect_hypervisor();
+   if (global_hypervisor_available)
+   disconnect_hypervisor();
return -1;
 }
 
@@ -838,7 +850,10 @@ channel_manager_exit(void)
rte_free(vm_info);
}
 
-   rte_free(global_cpumaps);
-   rte_free(global_vircpuinfo);
-   disconnect_hypervisor();
+   if (global_hypervisor_available) {
+   /* Only needed if hyper

[dpdk-dev] [PATCH v2 3/7] examples/power: add necessary changes to guest app

[David Hunt]

The changes here are minimal, as the guest app functionality is not
changing at all, but there is a new element in the channel_packet
struct that needs to have a default set (channel_packet->core_type).

Signed-off-by: David Hunt 
---
 examples/vm_power_manager/guest_cli/vm_power_cli_guest.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c 
b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
index 0db1b804f..88b825c3b 100644
--- a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
+++ b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
@@ -92,6 +92,7 @@ set_policy_defaults(struct channel_packet *pkt)
pkt->timer_policy.hours_to_use_traffic_profile[0] = 8;
pkt->timer_policy.hours_to_use_traffic_profile[1] = 10;
 
+   pkt->core_type = VIRTUAL;
pkt->workload = LOW;
pkt->policy_to_use = TIME;
pkt->command = PKT_POLICY;
-- 
2.17.1

[dpdk-dev] [PATCH v2 2/7] lib/power: add changes for host commands/policies

[David Hunt]

Signed-off-by: David Hunt 
---
 lib/librte_power/channel_commands.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/librte_power/channel_commands.h 
b/lib/librte_power/channel_commands.h
index ee638eefa..e7b93a797 100644
--- a/lib/librte_power/channel_commands.h
+++ b/lib/librte_power/channel_commands.h
@@ -19,6 +19,7 @@ extern "C" {
 #define CPU_POWER   1
 #define CPU_POWER_CONNECT   2
 #define PKT_POLICY  3
+#define PKT_POLICY_REMOVE   4
 
 /* CPU Power Command Scaling */
 #define CPU_POWER_SCALE_UP  1
@@ -58,6 +59,9 @@ struct traffic {
uint32_t max_max_packet_thresh;
 };
 
+#define CORE_TYPE_VIRTUAL 0
+#define CORE_TYPE_PHYSICAL 1
+
 struct channel_packet {
uint64_t resource_id; /**< core_num, device */
uint32_t unit;/**< scale down/up/min/max */
@@ -70,6 +74,7 @@ struct channel_packet {
uint8_t vcpu_to_control[MAX_VCPU_PER_VM];
uint8_t num_vcpu;
struct timer_profile timer_policy;
+   bool core_type;
enum workload workload;
enum policy_to_use policy_to_use;
struct t_boost_status t_boost_status;
-- 
2.17.1

[dpdk-dev] [PATCH v2 4/7] examples/power: add host channel to power manager

[David Hunt]

This patch adds a fifo channel to the vm_power_manager app through which
we can send commands and polices. Intended for sending JSON strings.
The fifo is at /tmp/powermonitor/fifo.0

Signed-off-by: David Hunt 
---
 examples/vm_power_manager/channel_manager.c | 108 +++
 examples/vm_power_manager/channel_manager.h |  17 ++-
 examples/vm_power_manager/channel_monitor.c | 146 +++-
 examples/vm_power_manager/main.c|   2 +
 4 files changed, 238 insertions(+), 35 deletions(-)

diff --git a/examples/vm_power_manager/channel_manager.c 
b/examples/vm_power_manager/channel_manager.c
index 2e471d0c1..88ae108a6 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -284,6 +285,38 @@ open_non_blocking_channel(struct channel_info *info)
return 0;
 }
 
+static int
+open_host_channel(struct channel_info *info)
+{
+   int flags;
+
+   info->fd = open(info->channel_path, O_RDWR | O_RSYNC);
+   if (info->fd == -1) {
+   RTE_LOG(ERR, CHANNEL_MANAGER, "Error(%s) opening fifo for 
'%s'\n",
+   strerror(errno),
+   info->channel_path);
+   return -1;
+   }
+
+   /* Get current flags */
+   flags = fcntl(info->fd, F_GETFL, 0);
+   if (flags < 0) {
+   RTE_LOG(WARNING, CHANNEL_MANAGER, "Error(%s) fcntl get flags 
socket for"
+   "'%s'\n", strerror(errno), info->channel_path);
+   return 1;
+   }
+   /* Set to Non Blocking */
+   flags |= O_NONBLOCK;
+   if (fcntl(info->fd, F_SETFL, flags) < 0) {
+   RTE_LOG(WARNING, CHANNEL_MANAGER,
+   "Error(%s) setting non-blocking "
+   "socket for '%s'\n",
+   strerror(errno), info->channel_path);
+   return -1;
+   }
+   return 0;
+}
+
 static int
 setup_channel_info(struct virtual_machine_info **vm_info_dptr,
struct channel_info **chan_info_dptr, unsigned channel_num)
@@ -294,6 +327,7 @@ setup_channel_info(struct virtual_machine_info 
**vm_info_dptr,
chan_info->channel_num = channel_num;
chan_info->priv_info = (void *)vm_info;
chan_info->status = CHANNEL_MGR_CHANNEL_DISCONNECTED;
+   chan_info->type = CHANNEL_TYPE_BINARY;
if (open_non_blocking_channel(chan_info) < 0) {
RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open channel: "
"'%s' for VM '%s'\n",
@@ -316,6 +350,35 @@ setup_channel_info(struct virtual_machine_info 
**vm_info_dptr,
return 0;
 }
 
+static int
+setup_host_channel_info(struct channel_info **chan_info_dptr,
+   unsigned int channel_num)
+{
+   struct channel_info *chan_info = *chan_info_dptr;
+
+   chan_info->channel_num = channel_num;
+   chan_info->priv_info = (void *)0;
+   chan_info->status = CHANNEL_MGR_CHANNEL_DISCONNECTED;
+   chan_info->type = CHANNEL_TYPE_JSON;
+   sprintf(chan_info->channel_path, "%sfifo.0", CHANNEL_MGR_SOCKET_PATH);
+
+   if (open_host_channel(chan_info) < 0) {
+   RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open host channel: "
+   "'%s'\n",
+   chan_info->channel_path);
+   return -1;
+   }
+   if (add_channel_to_monitor(&chan_info) < 0) {
+   RTE_LOG(ERR, CHANNEL_MANAGER, "Could add channel: "
+   "'%s' to epoll ctl\n",
+   chan_info->channel_path);
+   return -1;
+
+   }
+   chan_info->status = CHANNEL_MGR_CHANNEL_CONNECTED;
+   return 0;
+}
+
 int
 add_all_channels(const char *vm_name)
 {
@@ -470,6 +533,51 @@ add_channels(const char *vm_name, unsigned *channel_list,
return num_channels_enabled;
 }
 
+int
+add_host_channel(void)
+{
+   struct channel_info *chan_info;
+   char socket_path[PATH_MAX];
+   int num_channels_enabled = 0;
+   int ret;
+
+   snprintf(socket_path, sizeof(socket_path), "%sfifo.%u",
+   CHANNEL_MGR_SOCKET_PATH, 0);
+
+   errno = 0;
+   ret = mkfifo(socket_path, 0666);
+   if ((errno != EEXIST) && (ret < 0)) {
+   printf(" %d %d, %d\n", ret, EEXIST, errno);
+   RTE_LOG(ERR, CHANNEL_MANAGER, "Cannot create fifo '%s' error: "
+   "%s\n", socket_path, strerror(errno));
+   return 0;
+   }
+
+   errno = 0;
+   if (access(socket_path, F_OK) < 0) {
+   RTE_LOG(ERR, CHANNEL_MANAGER, "Channel path '%s' error: "
+   "%s\n", socket_path, strerror(errno));
+   return 0;
+   }
+   chan_info = rte_malloc(NULL, sizeof(*chan_info),
+   RTE_CACHE_LIN

[dpdk-dev] [PATCH v2 5/7] examples/power: add json string handling

[David Hunt]

Add JSON string handling to vm_power_manager for JSON strings received
through the fifo. The format of the JSON strings are detailed in the
next patch, the vm_power_manager user guide documentation updates.

This patch introduces a new dependency on Jansson, a C library for
encoding, decoding and manipulating JSON data. To compile the sample app
you now need to have installed libjansson4 and libjansson-dev (these may
be named slightly differently depending on your Operating System)

Signed-off-by: David Hunt 
---
 examples/vm_power_manager/Makefile  |   6 +
 examples/vm_power_manager/channel_monitor.c | 297 +---
 2 files changed, 258 insertions(+), 45 deletions(-)

diff --git a/examples/vm_power_manager/Makefile 
b/examples/vm_power_manager/Makefile
index 13a5205ba..50147c05d 100644
--- a/examples/vm_power_manager/Makefile
+++ b/examples/vm_power_manager/Makefile
@@ -31,6 +31,12 @@ CFLAGS += $(WERROR_FLAGS)
 
 LDLIBS += -lvirt
 
+JANSSON := $(shell pkg-config --exists jansson; echo $$?)
+ifeq ($(JANSSON), 0)
+LDLIBS += $(shell pkg-config --libs jansson)
+CFLAGS += -DUSE_JANSSON
+endif
+
 ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
 
 ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
diff --git a/examples/vm_power_manager/channel_monitor.c 
b/examples/vm_power_manager/channel_monitor.c
index 17383e9d2..655f5e279 100644
--- a/examples/vm_power_manager/channel_monitor.c
+++ b/examples/vm_power_manager/channel_monitor.c
@@ -9,11 +9,18 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
-
+#include 
+#include 
+#ifdef USE_JANSSON
+#include 
+#else
+#pragma message "Jansson dev libs unavailable, not including JSON parsing"
+#endif
 #include 
 #include 
 #include 
@@ -35,6 +42,8 @@
 
 uint64_t vsi_pkt_count_prev[384];
 uint64_t rdtsc_prev[384];
+#define MAX_JSON_STRING_LEN 1024
+char json_data[MAX_JSON_STRING_LEN];
 
 double time_period_ms = 1;
 static volatile unsigned run_loop = 1;
@@ -43,6 +52,132 @@ static unsigned int policy_is_set;
 static struct epoll_event *global_events_list;
 static struct policy policies[MAX_VMS];
 
+#ifdef USE_JANSSON
+static int
+parse_json_to_pkt(json_t *element, struct channel_packet *pkt)
+{
+   const char *key;
+   json_t *value;
+   int ret;
+
+   memset(pkt, 0, sizeof(struct channel_packet));
+
+   pkt->nb_mac_to_monitor = 0;
+   pkt->t_boost_status.tbEnabled = false;
+   pkt->workload = LOW;
+   pkt->policy_to_use = TIME;
+   pkt->command = PKT_POLICY;
+   pkt->core_type = CORE_TYPE_PHYSICAL;
+
+   json_object_foreach(element, key, value) {
+   if (!strcmp(key, "policy")) {
+   /* Recurse in to get the contents of profile */
+   ret = parse_json_to_pkt(value, pkt);
+   if (ret)
+   return ret;
+   } else if (!strcmp(key, "instruction")) {
+   /* Recurse in to get the contents of instruction */
+   ret = parse_json_to_pkt(value, pkt);
+   if (ret)
+   return ret;
+   } else if (!strcmp(key, "name")) {
+   strcpy(pkt->vm_name, json_string_value(value));
+   } else if (!strcmp(key, "command")) {
+   char command[32];
+   snprintf(command, 32, "%s", json_string_value(value));
+   if (!strcmp(command, "power")) {
+   pkt->command = CPU_POWER;
+   } else if (!strcmp(command, "create")) {
+   pkt->command = PKT_POLICY;
+   } else if (!strcmp(command, "destroy")) {
+   pkt->command = PKT_POLICY_REMOVE;
+   } else {
+   RTE_LOG(ERR, CHANNEL_MONITOR,
+   "Invalid command received in JSON\n");
+   return -1;
+   }
+   } else if (!strcmp(key, "policy_type")) {
+   char command[32];
+   snprintf(command, 32, "%s", json_string_value(value));
+   if (!strcmp(command, "TIME")) {
+   pkt->policy_to_use = TIME;
+   } else if (!strcmp(command, "TRAFFIC")) {
+   pkt->policy_to_use = TRAFFIC;
+   } else if (!strcmp(command, "WORKLOAD")) {
+   pkt->policy_to_use = WORKLOAD;
+   } else if (!strcmp(command, "BRANCH_RATIO")) {
+   pkt->policy_to_use = BRANCH_RATIO;
+   } else {
+   RTE_LOG(ERR, CHANNEL_MONITOR,
+   "Wrong policy_type received in JSON\n");
+   return -1;
+   }
+   

[dpdk-dev] [PATCH v2 6/7] doc/vm_power_manager: add JSON interface API info

[David Hunt]

Signed-off-by: David Hunt 
---
 .../sample_app_ug/vm_power_management.rst | 236 ++
 1 file changed, 236 insertions(+)

diff --git a/doc/guides/sample_app_ug/vm_power_management.rst 
b/doc/guides/sample_app_ug/vm_power_management.rst
index 855570d6b..b5b0179d2 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -337,6 +337,242 @@ monitoring of branch ratio on cores doing busy polling 
via PMDs.
   and will need to be adjusted for different workloads.
 
 
+
+JSON API
+
+
+In addition to the command line interface for host command and a virtio-serial
+interface for VM power policies, there is also a JSON interface through which
+power commands and policies can be sent. This functionality adds a dependency
+on the Jansson library, and the Jansson development package must be installed
+on the system before the JSON parsing functionality is included in the app.
+This is achieved by:
+
+  .. code-block:: console
+
+apt-get install libjansson-dev
+
+The command and package name may be different depending on your operating
+system. It's worth noting that the app will successfully build without this
+package present, but a warning is shown during compilation, and the JSON
+parsing functionality will not be present in the app.
+
+Sending a command or policy to the power manager application is achieved by
+simply opening a fifo file, writing a JSON string to that fifo, and closing
+the file.
+
+The fifo is at /tmp/powermonitor/fifo.0
+
+The jason string can be a policy or instruction, and takes the following
+format:
+
+  .. code-block:: console
+
+{"packet_type": {
+  "pair_1": value,
+  "pair_2": value
+}}
+
+The 'packet_type' header can contain one of two values, depending on
+whether a policy or power command is being sent. The two possible values are
+"policy" and "instruction", and the expected name-value pairs is different
+depending on which type is being sent.
+
+The pairs are the format of standard JSON name-value pairs. The value type
+varies between the different name/value pairs, and may be intgers, strings,
+arrays, etc. Examples of policies follow later in this document. The allowed
+names and value types are as follows:
+
+
+:Pair Name: "name"
+:Description: Name of the VM or Host. Allows the parser to associate the
+  policy with the relevant VM or Host OS.
+:Type: string
+:Values: any valid string
+:Required: yes
+:Example:
+
+  .. code-block:: console
+
+""name", "ubuntu2"
+
+
+:Pair Name: "command"
+:Description: The type of packet we're sending to the power manager. We can be
+  creating or destroying a policy, or sending a direct command to adjust
+  the frequency of a core, similar to the command line interface.
+:Type: string
+:Values:
+
+  :"CREATE": used when creating a new policy,
+  :"DESTROY": used when removing a policy,
+  :"POWER": used when sending an immediate command, max, min, etc.
+:Required: yes
+:Example:
+
+.. code-block:: console
+
+  "command", "CREATE"
+
+
+:Pair Name: "policy_type"
+:Description: Type of policy to apply. Please see vm_power_manager 
documentation
+  for more information on the types of policies that may be used.
+:Type: string
+:Values:
+
+  :"TIME": Time-of-day policy. Frequencies of the relevant cores are
+scaled up/down depending on busy and quiet hours.
+  :"TRAFFIC": This policy takes statistics from the NIC and scales up
+and down accordingly.
+  :"WORKLOAD": This policy looks at how heavily loaded the cores are,
+and scales up and down accordingly.
+  :"BRANCH_RATIO": This out-of-band policy can look at the ratio between
+branch hits and misses on a core, and is useful for detecting
+how much packet processing a core is doing.
+:Required: only for CREATE/DESTROY command
+:Example:
+
+  .. code-block:: console
+
+"policy_type", "TIME"
+
+:Pair Name: "busy_hours"
+:Description: The hours of the day in which we scale up the cores for busy
+  times.
+:Type: array of integers
+:Values: array with list of hour numbers, (0-23)
+:Required: only for TIME policy
+:Example:
+
+  .. code-block:: console
+
+"busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ]
+
+:Pair Name: "quiet_hours"
+:Description: The hours of the day in which we scale down the cores for quiet
+  times.
+:Type: array of integers
+:Values: array with list of hour numbers, (0-23)
+:Required: only for TIME policy
+:Example:
+
+  .. code-block:: console
+
+"quiet_hours":[ 2, 3, 4, 5, 6 ]
+
+:Pair Name: "avg_packet_thresh"
+:Description: Threshold below which the frequency will be set to min for
+  the TRAFFIC policy. If the traffic rate is above this and below max, the
+  frequency will be set to medium.
+:Type: integer
+:Values: The number of packets below which the TRAFFIC policy applies the
+  minimum frequency, or medium frequency if between avg and max thresholds.
+:Required: only for TRAFFIC policy
+:Example:
+
+  .. code-block:: console
+
+ 

[dpdk-dev] [PATCH v2 7/7] examples/power: add json example files

[David Hunt]

This patch provides some example files in the json_examples sub-directory
for sending to the fifo.

Signed-off-by: David Hunt 
---
 examples/vm_power_manager/json_examples/README| 6 ++
 examples/vm_power_manager/json_examples/create.json   | 8 
 examples/vm_power_manager/json_examples/destroy.json  | 4 
 examples/vm_power_manager/json_examples/set_core_max.json | 6 ++
 examples/vm_power_manager/json_examples/set_core_min.json | 6 ++
 5 files changed, 30 insertions(+)
 create mode 100644 examples/vm_power_manager/json_examples/README
 create mode 100644 examples/vm_power_manager/json_examples/create.json
 create mode 100644 examples/vm_power_manager/json_examples/destroy.json
 create mode 100644 examples/vm_power_manager/json_examples/set_core_max.json
 create mode 100644 examples/vm_power_manager/json_examples/set_core_min.json

diff --git a/examples/vm_power_manager/json_examples/README 
b/examples/vm_power_manager/json_examples/README
new file mode 100644
index 0..a94c6b14b
--- /dev/null
+++ b/examples/vm_power_manager/json_examples/README
@@ -0,0 +1,6 @@
+Sample files for sending to the vm_power_manager through the fifo.
+
+Simply cat the file to /tmp/powermonitor/fifo.0 when the vm_power_manager
+application is running.
+
+E.g. cat create.json >/tmp/powermonitor/fifo.0
diff --git a/examples/vm_power_manager/json_examples/create.json 
b/examples/vm_power_manager/json_examples/create.json
new file mode 100644
index 0..a7133d9a1
--- /dev/null
+++ b/examples/vm_power_manager/json_examples/create.json
@@ -0,0 +1,8 @@
+{"policy": {
+  "name": "policy-1",
+  "command": "create",
+  "policy_type": "TIME",
+  "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ],
+  "quiet_hours":[ 2, 3, 4, 5, 6 ],
+  "core_list":[ 11, 12 ]
+}}
diff --git a/examples/vm_power_manager/json_examples/destroy.json 
b/examples/vm_power_manager/json_examples/destroy.json
new file mode 100644
index 0..587c9e7e9
--- /dev/null
+++ b/examples/vm_power_manager/json_examples/destroy.json
@@ -0,0 +1,4 @@
+{"policy": {
+  "name": "policy-1",
+  "command": "destroy"
+}}
diff --git a/examples/vm_power_manager/json_examples/set_core_max.json 
b/examples/vm_power_manager/json_examples/set_core_max.json
new file mode 100644
index 0..497030a44
--- /dev/null
+++ b/examples/vm_power_manager/json_examples/set_core_max.json
@@ -0,0 +1,6 @@
+{"instruction": {
+  "name": "set_power",
+  "command": "power",
+  "unit": "SCALE_MAX",
+  "resource_id": 10
+}}
diff --git a/examples/vm_power_manager/json_examples/set_core_min.json 
b/examples/vm_power_manager/json_examples/set_core_min.json
new file mode 100644
index 0..76d934fd8
--- /dev/null
+++ b/examples/vm_power_manager/json_examples/set_core_min.json
@@ -0,0 +1,6 @@
+{"instruction": {
+  "name": "set_power",
+  "command": "power",
+  "unit": "SCALE_MIN",
+  "resource_id": 10
+}}
-- 
2.17.1

Re: [dpdk-dev] [RFC] ethdev: complete closing to free all resources

[Thomas Monjalon]

10/09/2018 10:54, Andrew Rybchenko:
> On 09/10/2018 11:42 AM, Thomas Monjalon wrote:
> > 10/09/2018 10:03, Andrew Rybchenko:
> >> On 09/08/2018 02:39 AM, Thomas Monjalon wrote:
> >>> After closing a port, it cannot be restarted.
> >>> So there is no reason to not free all associated resources.
> >>>
> >>> The last step was done with rte_eth_dev_detach() which is deprecated.
> >>> Instead of removing the associated rte_device, the driver should check
> >>> if no more port (ethdev, cryptodev, etc) is still open for the device.
> >>> Then the device resources can be freed by the driver inside the
> >>> dev_close() driver callback operation.
> >>>
> >>> The last ethdev freeing (dev_private and final release), which were done
> >>> by rte_eth_dev_detach(), are now done at the end of rte_eth_dev_close().
> >> For me, it sounds more logical to kill dev_close and keep detach.
> >> IMHO, dev_close is artificial and hardly useful. detach is a local pair
> >> to attach.
> > I don't get your point.
> >
> > In order to free a port, we need close + detach.
> > We can keep only one.
> > I choose close because:
> > 1) attach/detach are deprecated
> > 2) probe/close is a more obvious pair
> > 3) we need the driver to free the lower level resources
> 
> Yes, I'm sorry I used bad terminology.
> We have probe/remove pair for both PCI and vdev drivers and I mean
> that remove is a better candidate to be kept (as a pair for probe which
> allocates all resources).

OK, yes probe/remove is the pair at EAL level.
But if we want to request removal at ethdev level, rte_eth_dev_close
is the function.

Note that there is no function to request creation of an ethdev port.
Adding a new port is done only by the PMD during probing (rte_bus level).

Re: [dpdk-dev] [PATCH v5 07/11] net/virtio: implement transmit path for packed queues

[Maxime Coquelin]

On 09/06/2018 08:19 PM, Jens Freimann wrote:

This implements the transmit path for devices with
support for packed virtqueues.

Add the feature bit and enable code to
add buffers to vring and mark descriptors as available.

Signed-off-by: Jens Freiman 
---
  drivers/net/virtio/virtio_ethdev.c |   8 +-
  drivers/net/virtio/virtio_ethdev.h |   2 +
  drivers/net/virtio/virtio_rxtx.c   | 113 -
  3 files changed, 121 insertions(+), 2 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index ad91f7f82..d2c5755bb 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -384,6 +384,8 @@ virtio_init_queue(struct rte_eth_dev *dev, uint16_t 
vtpci_queue_idx)
vq->hw = hw;
vq->vq_queue_index = vtpci_queue_idx;
vq->vq_nentries = vq_size;
+   if (vtpci_packed_queue(hw))
+   vq->vq_ring.avail_wrap_counter = 1;
  
  	/*

 * Reserve a memzone for vring elements
@@ -1338,7 +1340,11 @@ set_rxtx_funcs(struct rte_eth_dev *eth_dev)
eth_dev->rx_pkt_burst = &virtio_recv_pkts;
}
  
-	if (hw->use_inorder_tx) {

+   if (vtpci_packed_queue(hw)) {
+   PMD_INIT_LOG(INFO, "virtio: using virtio 1.1 Tx path on port 
%u",
+   eth_dev->data->port_id);
+   eth_dev->tx_pkt_burst = virtio_xmit_pkts_packed;
+   } else if (hw->use_inorder_tx) {
PMD_INIT_LOG(INFO, "virtio: using inorder Tx path on port %u",
eth_dev->data->port_id);
eth_dev->tx_pkt_burst = virtio_xmit_pkts_inorder;
diff --git a/drivers/net/virtio/virtio_ethdev.h 
b/drivers/net/virtio/virtio_ethdev.h
index b726ad108..04161b461 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -79,6 +79,8 @@ uint16_t virtio_recv_mergeable_pkts_inorder(void *rx_queue,
  
  uint16_t virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,

uint16_t nb_pkts);
+uint16_t virtio_xmit_pkts_packed(void *tx_queue, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts);
  
  uint16_t virtio_xmit_pkts_inorder(void *tx_queue, struct rte_mbuf **tx_pkts,

uint16_t nb_pkts);
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index eb891433e..12787070e 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -38,6 +38,112 @@
  #define  VIRTIO_DUMP_PACKET(m, len) do { } while (0)
  #endif
  
+

+/* Cleanup from completed transmits. */
+static void
+virtio_xmit_cleanup_packed(struct virtqueue *vq)
+{
+   uint16_t idx;
+   uint16_t size = vq->vq_nentries;
+   struct vring_desc_packed *desc = vq->vq_ring.desc_packed;
+   struct vq_desc_extra *dxp;
+
+   idx = vq->vq_used_cons_idx;
+   while (desc_is_used(&desc[idx], &vq->vq_ring) &&
+  vq->vq_free_cnt < size) {
+   dxp = &vq->vq_descx[idx];
+   vq->vq_free_cnt += dxp->ndescs;
+   idx = dxp->ndescs;
+   idx = idx >= size ? idx - size : idx;
+   }
+}
+
+uint16_t
+virtio_xmit_pkts_packed(void *tx_queue, struct rte_mbuf **tx_pkts,
+uint16_t nb_pkts)
+{
+   struct virtnet_tx *txvq = tx_queue;
+   struct virtqueue *vq = txvq->vq;
+   uint16_t i;
+   struct vring_desc_packed *desc = vq->vq_ring.desc_packed;
+   uint16_t idx, prev;
+   struct vq_desc_extra *dxp;
+
+   if (unlikely(nb_pkts < 1))
+   return nb_pkts;
+
+   PMD_TX_LOG(DEBUG, "%d packets to xmit", nb_pkts);
+
+   if (likely(vq->vq_free_cnt < vq->vq_free_thresh))
+   virtio_xmit_cleanup_packed(vq);
+
+   for (i = 0; i < nb_pkts; i++) {
+   struct rte_mbuf *txm = tx_pkts[i];
+   struct virtio_tx_region *txr = txvq->virtio_net_hdr_mz->addr;
+   uint16_t head_idx;
+   int wrap_counter;
+   int descs_used;
+
+   if (unlikely(txm->nb_segs + 1 > vq->vq_free_cnt)) {
+   virtio_xmit_cleanup_packed(vq);
+
+   if (unlikely(txm->nb_segs + 1 > vq->vq_free_cnt)) {
+   PMD_TX_LOG(ERR,
+  "No free tx descriptors to 
transmit");
+   break;
+   }
+   }
+
+   txvq->stats.bytes += txm->pkt_len;
+
+   vq->vq_free_cnt -= txm->nb_segs + 1;
+
+   wrap_counter = vq->vq_ring.avail_wrap_counter;
+   idx = vq->vq_avail_idx;
+   head_idx = idx;
+
+   dxp = &vq->vq_descx[idx];
+   if (dxp->cookie != NULL)
+   rte_pktmbuf_free(dxp->cookie);
+   dxp->cookie = txm;
+
+   desc[idx].addr  = txvq->virtio_net_hdr_mem +
+ RTE_PTR_DIFF(&txr[idx].tx_hdr, txr);
+ 

Re: [dpdk-dev] [PATCH] net/ixgbe: Strip SR-IOV transparent VLANs in VF

[Ananyev, Konstantin]

Hi Robert,

> -Original Message-
> From: robertshear...@gmail.com [mailto:robertshear...@gmail.com]
> Sent: Friday, August 24, 2018 5:35 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; Ananyev, Konstantin 
> ; Robert Shearman
> 
> Subject: [PATCH] net/ixgbe: Strip SR-IOV transparent VLANs in VF
> 
> From: Robert Shearman 
> 
> SR-IOV VFs support "transparent" VLANs. Traffic from/to a VM
> associated with a VF has a VLAN tag inserted/stripped in a manner
> intended to be totally transparent to the VM.  On a Linux hypervisor
> the vlan can be specified by "ip link set  vf  vlan ".
> The VM VF driver is not configured to use any VLAN and the VM should
> never see the transparent VLAN for that reason.  However, in practice
> these VLAN headers are being received by the VM which discards the
> packets as that VLAN is unknown to it.  The Linux kernel ixbge driver
> explicitly removes the VLAN in this case (presumably due to the
> hardware not being able to do this) but the DPDK driver does not.
> 
> This patch mirrors the kernel driver behaviour by removing the VLAN on
> the VF side. This is done by checking the VLAN in the VFTA, where the
> hypervisor will have set the bit in the VFTA corresponding to the VLAN
> if transparent VLANs were being used for the VF. If the VLAN is set in
> the VFTA then it is known that it's a transparent VLAN case and so the
> VLAN is stripped from the mbuf. To limit any potential performance
> impact on the PF data path, the RX path is split into PF and VF
> versions with the transparent VLAN stripping only done in the VF
> path. Measurements with our application show ~2% performance hit for
> the VF case and none for the PF case.

I did some perf measurements too, and unfortunately I am seeing ~4 % drop 
(tespmd iofwd on one core over 4x10Gb: from  ~44.7 Mpps to ~43Mpps, that's on 
BDX 2.2GHz).
As you mentioned above:
" VM VF driver is not configured to use any VLAN and the VM should
never see the transparent VLAN for that reason."
I wonder would it be sufficient for your purposes if VF RX function just ignore
HW descriptor values and never set  PKT_RX_VLAN | PKT_RX_VLAN_STRIPPED?
I think that could be done pretty easily (by setting rxq->vlan_flags).
In that case no changes in RX code will be required no perf changes).
It can be controlled by DEV_RX_OFFLOAD_VLAN_STRIP, not sure would it be 
sufficient for you.  
BTW, in your case how hypervisor will propagate new VFTA table to VF?
Presumably same way could be used to propagate rx offload flags?
Konstantin

> 
> Signed-off-by: Robert Shearman 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c| 18 +++
>  drivers/net/ixgbe/ixgbe_ethdev.h| 38 +++
>  drivers/net/ixgbe/ixgbe_rxtx.c  | 83 +---
>  drivers/net/ixgbe/ixgbe_rxtx.h  | 31 +++-
>  drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c |  7 +++
>  drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c  | 84 
> ++---
>  6 files changed, 238 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 26b1927..3f88a02 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -604,7 +604,7 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
>   .vlan_filter_set  = ixgbevf_vlan_filter_set,
>   .vlan_strip_queue_set = ixgbevf_vlan_strip_queue_set,
>   .vlan_offload_set = ixgbevf_vlan_offload_set,
> - .rx_queue_setup   = ixgbe_dev_rx_queue_setup,
> + .rx_queue_setup   = ixgbevf_dev_rx_queue_setup,
>   .rx_queue_release = ixgbe_dev_rx_queue_release,
>   .rx_descriptor_done   = ixgbe_dev_rx_descriptor_done,
>   .rx_descriptor_status = ixgbe_dev_rx_descriptor_status,
> @@ -1094,7 +1094,7 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev, void 
> *init_params __rte_unused)
>"Using default TX function.");
>   }
> 
> - ixgbe_set_rx_function(eth_dev);
> + ixgbe_set_rx_function(eth_dev, true);
> 
>   return 0;
>   }
> @@ -1576,7 +1576,7 @@ eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev)
>"No TX queues configured yet. Using 
> default TX function.");
>   }
> 
> - ixgbe_set_rx_function(eth_dev);
> + ixgbe_set_rx_function(eth_dev, true);
> 
>   return 0;
>   }
> @@ -1839,8 +1839,8 @@ ixgbe_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
> vlan_id, int on)
>   uint32_t vid_idx;
>   uint32_t vid_bit;
> 
> - vid_idx = (uint32_t) ((vlan_id >> 5) & 0x7F);
> - vid_bit = (uint32_t) (1 << (vlan_id & 0x1F));
> + vid_idx = ixgbe_vfta_index(vlan_id);
> + vid_bit = ixgbe_vfta_bit(vlan_id);
>   vfta = IXGBE_READ_REG(hw, IXGBE_VFTA(vid_idx));
>   if (on)
>   vfta |= vid_bit;
> @@ -3807,7 +3807,9 @@ ixgbe_dev_supported_ptypes_get(struct rte_eth_dev *dev)
> 

Re: [dpdk-dev] [PATCH 1/2] app/testpmd: add a generic way for dumping packets

[Thomas Monjalon]

12/09/2018 10:06, Raslan Darawsheh:
> verbosity for the received/sent packets is needed in all of the
> forwarding engines so moving it to be in a separate function.
> 
> Signed-off-by: Raslan Darawsheh 
> ---
>  app/test-pmd/Makefile  |   1 +
>  app/test-pmd/testpmd.h |   2 +
>  app/test-pmd/util.c| 143 
> +
>  3 files changed, 146 insertions(+)

If you are moving code from app/test-pmd/rxonly.c, you should
update this file in the same patch, so it will appear more clearly as a move.
Then the second patch would be only about adding the feature to more engines.

Re: [dpdk-dev] eventdev: method for finding out unlink status

[Van Haaren, Harry]

> From: Elo, Matias (Nokia - FI/Espoo) [mailto:matias@nokia.com]
> Sent: Wednesday, September 5, 2018 8:49 AM
> To: Van Haaren, Harry 
> Cc: Jerin Jacob ; dev@dpdk.org
> Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
> 
> 
> >>
> >> I'm not sure I understand the issue here.
> >> Is anybody suggesting to make unlink() blocking?
> >>
> >> For certain PMDs, perhaps it must be a synchronous handled unlink().
> >> For other PMDs (eg event/sw) there are multiple threads involved,
> >> so it must be async. Hence, APIs should be async to avoid blocking the
> caller.
> >>
> >> With an async API, if you don't want the async behaviuor, it is
> >> easy to build the sync version: call it in a loop, optionally with a
> delay().
> >
> > Correct. My point was, rte_event_port_unlink() can be blocking as it
> > is a slow path API(does not really matter how long it waits).
> > If you think, it can be called in fastpath and/or application can
> > leverage some cpu cycles on completing the async call then you can add
> > at the cost of new API unlinks_in_progress() and make sure to update the
> documentation
> > about unlink() that it can be async call(currently it is documented as a
> sync
> > call).
> 
> Did you come to an agreement how to solve this issue? Any solution (e.g.
> make
> rte_event_port_unlink() blocking with SW eventdev) would be welcomed since
> this
> issue is currently blocking my work with eventdev.


I'll work on a patch and document async behavior as Jerin suggested.

I think we may still need to drain the port after unlinks_in_progress() returns
zero, as there may still be events in the port buffers until all unlinks are 
done.

That would make the final application code-path as follows:


/* control path core */
unlink();
while(unlinks_in_progress() > 0) {
delay();
}

/* we know there are no more events being scheduled to the port.
   Could flag to data-path core here that unlinks are acked */

while(dequeue_burst(events, ... ) > 0) {
free_events();
}

/* now we know there are no events in the port itself either.
   Application can perform whatever it wants with the data-path core */

The final dequeueing could also be handled in the data-path core,
and only break out of its loop when the unlink-ack and zero packets returned 
from dequeue.


I'll send a v1 patchset for your reviews - I think that might make things 
clearer.

Thanks, -Harry

Re: [dpdk-dev] [PATCH v2 0/5] vhost_user.c code cleanup

[Nikolay Nikolaev]

Hello Maxime,

I'll rebase and fix Ilya's comments. Thanks for the reviews.

regards,
Nikolay Nikolaev

On Tue, Sep 11, 2018 at 12:38 PM Maxime Coquelin 
wrote:

> Hi Nikolay,
>
> On 07/19/2018 09:13 PM, Nikolay Nikolaev wrote:
> > vhost: vhost_user.c code cleanup
> >
> > This patchesries introduce a set of code redesigns in vhost_user.c.
> >
> > The goal is to unify and simplify vhost-user message handling. The
> > patches do not intend to introduce any functional changes.
> >
> > v2 changes:
> >   - Fix the comments by Tiwei Bie
> >   - Keep the old behavior
> > - Fall through when the callback returns VH_RESULT_ERR
> > - Fall through if the request is out of range
> >
> > ---
> >
> > Nikolay Nikolaev (5):
> >vhost: unify VhostUserMsg usage
> >vhost: make message handling functions prepare the reply
> >vhost: handle unsupported message types in functions
> >vhost: unify message handling function signature
> >vhost: message handling implemented as a callback array
> >
> >
> >   lib/librte_vhost/vhost_user.c |  392
> ++---
> >   1 file changed, 208 insertions(+), 184 deletions(-)
> >
> > --
> > Signature
> >
>
> Could you please rebase and fix the series (see Iliya comments) on top
> of git://dpdk.org/next/dpdk-next-virtio master branch?
>
> Thanks,
> Maxime
>

Re: [dpdk-dev] [RFC] ethdev: complete closing to free all resources

[Andrew Rybchenko]

On 09/12/2018 05:57 PM, Thomas Monjalon wrote:

10/09/2018 10:54, Andrew Rybchenko:

On 09/10/2018 11:42 AM, Thomas Monjalon wrote:

10/09/2018 10:03, Andrew Rybchenko:

On 09/08/2018 02:39 AM, Thomas Monjalon wrote:

After closing a port, it cannot be restarted.
So there is no reason to not free all associated resources.

The last step was done with rte_eth_dev_detach() which is deprecated.
Instead of removing the associated rte_device, the driver should check
if no more port (ethdev, cryptodev, etc) is still open for the device.
Then the device resources can be freed by the driver inside the
dev_close() driver callback operation.

The last ethdev freeing (dev_private and final release), which were done
by rte_eth_dev_detach(), are now done at the end of rte_eth_dev_close().

For me, it sounds more logical to kill dev_close and keep detach.
IMHO, dev_close is artificial and hardly useful. detach is a local pair
to attach.

I don't get your point.

In order to free a port, we need close + detach.
We can keep only one.
I choose close because:
1) attach/detach are deprecated
2) probe/close is a more obvious pair
3) we need the driver to free the lower level resources

Yes, I'm sorry I used bad terminology.
We have probe/remove pair for both PCI and vdev drivers and I mean
that remove is a better candidate to be kept (as a pair for probe which
allocates all resources).

OK, yes probe/remove is the pair at EAL level.
But if we want to request removal at ethdev level, rte_eth_dev_close
is the function.

Note that there is no function to request creation of an ethdev port.
Adding a new port is done only by the PMD during probing (rte_bus level).


The overall picture is too vague. May be it is simply incomplete looking
at the patch only. I understand that restructuring is required looking at
rte_eth_dev_destroy() (which is used by i40e and ixgbe drivers only) and
rte_eth_dev_pci_release() used by other PCI drivers.

Right now it looks symmetric at least on drivers level which provides
init callback to probe to do driver-specific job and uninit callback to
remove to free driver-specific resources.

I can't say if the patch is right or wrong direction since final design
is unclear.

[dpdk-dev] [PATCH 1/3] event: add function for reading unlink in progress

[Harry van Haaren]

This commit introduces a new function in the eventdev API,
which allows applications to read the number of unlink requests
in progress on a particular port of an eventdev instance.

This information allows applications to verify when no more packets
from a particular queue (or any queue) will arrive at a port.
The application could decide to stop polling, or put the core into
a sleep state if it wishes, as it is ensured that no new packets
will arrive at a particular port anymore if all queues are unlinked.

Suggested-by: Matias Elo 
Signed-off-by: Harry van Haaren 

---

Cc: jerin.ja...@caviumnetworks.com

Hey, I've added this API as __rte_experimental, so we should be OK to
include in 18.11, and then possibly remove the experimental tag in
a later release, assuming it serves its purpose correctly.

For context, see thread here:
http://mails.dpdk.org/archives/dev/2018-September/111499.html

@Matias, is that workable for you?
@Jerin, is this acceptable as maintainer?

Cheers, -Harry
---
 lib/librte_eventdev/rte_eventdev.c   | 22 +++
 lib/librte_eventdev/rte_eventdev.h   | 28 ++--
 lib/librte_eventdev/rte_eventdev_pmd.h   | 19 +
 lib/librte_eventdev/rte_eventdev_version.map |  1 +
 4 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eventdev/rte_eventdev.c 
b/lib/librte_eventdev/rte_eventdev.c
index 801810edd..0a8572b7b 100644
--- a/lib/librte_eventdev/rte_eventdev.c
+++ b/lib/librte_eventdev/rte_eventdev.c
@@ -980,6 +980,28 @@ rte_event_port_unlink(uint8_t dev_id, uint8_t port_id,
return diag;
 }
 
+int __rte_experimental
+rte_event_port_unlinks_in_progress(uint8_t dev_id, uint8_t port_id)
+{
+   struct rte_eventdev *dev;
+
+   RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+   dev = &rte_eventdevs[dev_id];
+   if (!is_valid_port(dev, port_id)) {
+   RTE_EDEV_LOG_ERR("Invalid port_id=%" PRIu8, port_id);
+   return -EINVAL;
+   }
+
+   /* Return 0 if the PMD does not implement unlinks in progress.
+* This allows PMDs which handle unlink synchronously to not implement
+* this function at all.
+*/
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->port_unlinks_in_progress, 0);
+
+   return (*dev->dev_ops->port_unlinks_in_progress)(dev,
+   dev->data->ports[port_id]);
+}
+
 int
 rte_event_port_links_get(uint8_t dev_id, uint8_t port_id,
 uint8_t queues[], uint8_t priorities[])
diff --git a/lib/librte_eventdev/rte_eventdev.h 
b/lib/librte_eventdev/rte_eventdev.h
index b6fd6ee7f..d07e297bc 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -1656,8 +1656,9 @@ rte_event_port_link(uint8_t dev_id, uint8_t port_id,
  * event port designated by its *port_id* on the event device designated
  * by its *dev_id*.
  *
- * The unlink establishment shall disable the event port *port_id* from
- * receiving events from the specified event queue *queue_id*
+ * The unlink call issues an async request to disable the event port *port_id*
+ * from receiving events from the specified event queue *queue_id*. See
+ * *rte_event_port_unlinks_in_progress* to poll for completed unlinks.
  *
  * Event queue(s) to event port unlink establishment can be changed at runtime
  * without re-configuring the device.
@@ -1694,6 +1695,29 @@ int
 rte_event_port_unlink(uint8_t dev_id, uint8_t port_id,
  uint8_t queues[], uint16_t nb_unlinks);
 
+/**
+ * Returns the number of unlinks in progress.
+ *
+ * This function provides the application with a method to detect when an
+ * unlink has been completed by the implementation. See *rte_event_port_unlink*
+ * on how to issue unlink requests.
+ *
+ * @param dev_id
+ *   The indentifier of the device.
+ *
+ * @param port_id
+ *   Event port identifier to select port to check for unlinks in progress.
+ *
+ * @return
+ * The number of unlinks that are in progress. A return of zero indicates that
+ * there are no outstanding unlink requests. A positive return value indicates
+ * the number of unlinks that are in progress, but are not yet complete.
+ * A negative return value indicates an error, -EINVAL indicates an invalid
+ * parameter passed for *dev_id* or *port_id*.
+ */
+int __rte_experimental
+rte_event_port_unlinks_in_progress(uint8_t dev_id, uint8_t port_id);
+
 /**
  * Retrieve the list of source event queues and its associated service priority
  * linked to the destination event port designated by its *port_id*
diff --git a/lib/librte_eventdev/rte_eventdev_pmd.h 
b/lib/librte_eventdev/rte_eventdev_pmd.h
index 3fbb4d2b2..65645730a 100644
--- a/lib/librte_eventdev/rte_eventdev_pmd.h
+++ b/lib/librte_eventdev/rte_eventdev_pmd.h
@@ -332,6 +332,23 @@ typedef int (*eventdev_port_link_t)(struct rte_eventdev 
*dev, void *port,
 typedef int (*eventdev_port_unlink_t)(struct rte_eventdev *dev, void *port,
uint8_t queues[], u

[dpdk-dev] [PATCH 3/3] event/sw: add unit test for unlinks in progress

[Harry van Haaren]

This commit adds a unit test that checks the behaviour
of the unlinks_in_progress() function, ensuring that the
returned values are the number of unlinks requested,
until the scheduler runs and "acks" the requests, after
which the count should be zero again.

Signed-off-by: Harry van Haaren 
---
 drivers/event/sw/sw_evdev_selftest.c | 76 
 1 file changed, 76 insertions(+)

diff --git a/drivers/event/sw/sw_evdev_selftest.c 
b/drivers/event/sw/sw_evdev_selftest.c
index c40912db5..374abef7c 100644
--- a/drivers/event/sw/sw_evdev_selftest.c
+++ b/drivers/event/sw/sw_evdev_selftest.c
@@ -1903,6 +1903,77 @@ qid_priorities(struct test *t)
return 0;
 }
 
+static int
+unlink_in_progress(struct test *t)
+{
+   /* Test unlinking API, in particular that when an unlink request has
+* not yet been seen by the scheduler thread, that the
+* unlink_in_progress() function returns the number of unlinks.
+*/
+   unsigned int i;
+   /* Create instance with 1 ports, and 3 qids */
+   if (init(t, 3, 1) < 0 ||
+   create_ports(t, 1) < 0) {
+   printf("%d: Error initializing device\n", __LINE__);
+   return -1;
+   }
+
+   for (i = 0; i < 3; i++) {
+   /* Create QID */
+   const struct rte_event_queue_conf conf = {
+   .schedule_type = RTE_SCHED_TYPE_ATOMIC,
+   /* increase priority (0 == highest), as we go */
+   .priority = RTE_EVENT_DEV_PRIORITY_NORMAL - i,
+   .nb_atomic_flows = 1024,
+   .nb_atomic_order_sequences = 1024,
+   };
+
+   if (rte_event_queue_setup(evdev, i, &conf) < 0) {
+   printf("%d: error creating qid %d\n", __LINE__, i);
+   return -1;
+   }
+   t->qid[i] = i;
+   }
+   t->nb_qids = i;
+   /* map all QIDs to port */
+   rte_event_port_link(evdev, t->port[0], NULL, NULL, 0);
+
+   if (rte_event_dev_start(evdev) < 0) {
+   printf("%d: Error with start call\n", __LINE__);
+   return -1;
+   }
+
+   /* unlink all ports to have outstanding unlink requests */
+   int ret = rte_event_port_unlink(evdev, t->port[0], NULL, 0);
+   if (ret < 0) {
+   printf("%d: Failed to unlink queues\n", __LINE__);
+   return -1;
+   }
+
+   /* get active unlinks here, expect 3 */
+   int unlinks_in_progress =
+   rte_event_port_unlinks_in_progress(evdev, t->port[0]);
+   if (unlinks_in_progress != 3) {
+   printf("%d: Expected num unlinks in progress == 3, got %d\n",
+   __LINE__, unlinks_in_progress);
+   return -1;
+   }
+
+   /* run scheduler service on this thread to ack the unlinks */
+   rte_service_run_iter_on_app_lcore(t->service_id, 1);
+
+   /* active unlinks expected as 0 as scheduler thread has acked */
+   unlinks_in_progress =
+   rte_event_port_unlinks_in_progress(evdev, t->port[0]);
+   if (unlinks_in_progress != 0) {
+   printf("%d: Expected num unlinks in progress == 0, got %d\n",
+   __LINE__, unlinks_in_progress);
+   }
+
+   cleanup(t);
+   return 0;
+}
+
 static int
 load_balancing(struct test *t)
 {
@@ -3260,6 +3331,11 @@ test_sw_eventdev(void)
printf("ERROR - QID Priority test FAILED.\n");
goto test_fail;
}
+   ret = unlink_in_progress(t);
+   if (ret != 0) {
+   printf("ERROR - Unlink in progress test FAILED.\n");
+   goto test_fail;
+   }
printf("*** Running Ordered Reconfigure test...\n");
ret = ordered_reconfigure(t);
if (ret != 0) {
-- 
2.17.1

[dpdk-dev] [PATCH 2/3] event/sw: implement unlinks in progress function

[Harry van Haaren]

This commit adds a counter to each port, which counts the
number of unlinks that have been performed. When the scheduler
thread starts its scheduling routine, it "acks" all unlinks that
have been requested, and the application is gauranteed that no
more events will be scheduled to the port from the unlinked queue.

Signed-off-by: Harry van Haaren 
---
 drivers/event/sw/sw_evdev.c   | 12 
 drivers/event/sw/sw_evdev.h   |  8 
 drivers/event/sw/sw_evdev_scheduler.c |  7 ++-
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index a6bb91388..9e1412537 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -113,9 +113,20 @@ sw_port_unlink(struct rte_eventdev *dev, void *port, 
uint8_t queues[],
}
}
}
+
+   p->unlinks_in_progress += unlinked;
+   rte_smp_mb();
+
return unlinked;
 }
 
+static int
+sw_port_unlinks_in_progress(struct rte_eventdev *dev, void *port)
+{
+   struct sw_port *p = port;
+   return p->unlinks_in_progress;
+}
+
 static int
 sw_port_setup(struct rte_eventdev *dev, uint8_t port_id,
const struct rte_event_port_conf *conf)
@@ -925,6 +936,7 @@ sw_probe(struct rte_vdev_device *vdev)
.port_release = sw_port_release,
.port_link = sw_port_link,
.port_unlink = sw_port_unlink,
+   .port_unlinks_in_progress = sw_port_unlinks_in_progress,
 
.eth_rx_adapter_caps_get = sw_eth_rx_adapter_caps_get,
 
diff --git a/drivers/event/sw/sw_evdev.h b/drivers/event/sw/sw_evdev.h
index d90b96d4b..7c77b2495 100644
--- a/drivers/event/sw/sw_evdev.h
+++ b/drivers/event/sw/sw_evdev.h
@@ -148,6 +148,14 @@ struct sw_port {
/* A numeric ID for the port */
uint8_t id;
 
+   /* An atomic counter for when the port has been unlinked, and the
+* scheduler has not yet acked this unlink - hence there may still be
+* events in the buffers going to the port. When the unlinks in
+* progress is read by the scheduler, no more events will be pushed to
+* the port - hence the scheduler core can just assign zero.
+*/
+   uint8_t unlinks_in_progress;
+
int16_t is_directed; /** Takes from a single directed QID */
/**
 * For loadbalanced we can optimise pulling packets from
diff --git a/drivers/event/sw/sw_evdev_scheduler.c 
b/drivers/event/sw/sw_evdev_scheduler.c
index e3a41e02f..9b54d5ce7 100644
--- a/drivers/event/sw/sw_evdev_scheduler.c
+++ b/drivers/event/sw/sw_evdev_scheduler.c
@@ -517,13 +517,18 @@ sw_event_schedule(struct rte_eventdev *dev)
/* Pull from rx_ring for ports */
do {
in_pkts = 0;
-   for (i = 0; i < sw->port_count; i++)
+   for (i = 0; i < sw->port_count; i++) {
+   /* ack the unlinks in progress as done */
+   if (sw->ports[i].unlinks_in_progress)
+   sw->ports[i].unlinks_in_progress = 0;
+
if (sw->ports[i].is_directed)
in_pkts += 
sw_schedule_pull_port_dir(sw, i);
else if (sw->ports[i].num_ordered_qids > 0)
in_pkts += sw_schedule_pull_port_lb(sw, 
i);
else
in_pkts += 
sw_schedule_pull_port_no_reorder(sw, i);
+   }
 
/* QID scan for re-ordered */
in_pkts += sw_schedule_reorder(sw, 0,
-- 
2.17.1

[dpdk-dev] [PATCH v2 01/10] net/softnic: add metering and policing support

[Jasvinder Singh]

Enable metering and policing support for softnic.

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/Makefile|  1 +
 drivers/net/softnic/meson.build |  1 +
 drivers/net/softnic/rte_eth_softnic.c   | 10 
 drivers/net/softnic/rte_eth_softnic_internals.h |  5 
 drivers/net/softnic/rte_eth_softnic_meter.c | 31 +
 5 files changed, 48 insertions(+)
 create mode 100644 drivers/net/softnic/rte_eth_softnic_meter.c

diff --git a/drivers/net/softnic/Makefile b/drivers/net/softnic/Makefile
index 12515b1..720f067b 100644
--- a/drivers/net/softnic/Makefile
+++ b/drivers/net/softnic/Makefile
@@ -34,6 +34,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += 
rte_eth_softnic_pipeline.c
 SRCS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += rte_eth_softnic_thread.c
 SRCS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += rte_eth_softnic_cli.c
 SRCS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += rte_eth_softnic_flow.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += rte_eth_softnic_meter.c
 SRCS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += parser.c
 SRCS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += conn.c
 
diff --git a/drivers/net/softnic/meson.build b/drivers/net/softnic/meson.build
index 56e5e2b..6b7a6cc 100644
--- a/drivers/net/softnic/meson.build
+++ b/drivers/net/softnic/meson.build
@@ -14,6 +14,7 @@ sources = files('rte_eth_softnic_tm.c',
'rte_eth_softnic_thread.c',
'rte_eth_softnic_cli.c',
'rte_eth_softnic_flow.c',
+   'rte_eth_softnic_meter.c',
'parser.c',
'conn.c')
 deps += ['pipeline', 'port', 'table', 'sched']
diff --git a/drivers/net/softnic/rte_eth_softnic.c 
b/drivers/net/softnic/rte_eth_softnic.c
index ae2a438..659a1b4 100644
--- a/drivers/net/softnic/rte_eth_softnic.c
+++ b/drivers/net/softnic/rte_eth_softnic.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rte_eth_softnic.h"
 #include "rte_eth_softnic_internals.h"
@@ -228,6 +229,14 @@ pmd_tm_ops_get(struct rte_eth_dev *dev __rte_unused, void 
*arg)
return 0;
 }
 
+static int
+pmd_mtr_ops_get(struct rte_eth_dev *dev __rte_unused, void *arg)
+{
+   *(const struct rte_mtr_ops **)arg = &pmd_mtr_ops;
+
+   return 0;
+}
+
 static const struct eth_dev_ops pmd_ops = {
.dev_configure = pmd_dev_configure,
.dev_start = pmd_dev_start,
@@ -239,6 +248,7 @@ static const struct eth_dev_ops pmd_ops = {
.tx_queue_setup = pmd_tx_queue_setup,
.filter_ctrl = pmd_filter_ctrl,
.tm_ops_get = pmd_tm_ops_get,
+   .mtr_ops_get = pmd_mtr_ops_get,
 };
 
 static uint16_t
diff --git a/drivers/net/softnic/rte_eth_softnic_internals.h 
b/drivers/net/softnic/rte_eth_softnic_internals.h
index a1a2e15..92be4e8 100644
--- a/drivers/net/softnic/rte_eth_softnic_internals.h
+++ b/drivers/net/softnic/rte_eth_softnic_internals.h
@@ -572,6 +572,11 @@ flow_attr_map_get(struct pmd_internals *softnic,
 extern const struct rte_flow_ops pmd_flow_ops;
 
 /**
+ * Meter
+ */
+extern const struct rte_mtr_ops pmd_mtr_ops;
+
+/**
  * MEMPOOL
  */
 int
diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c 
b/drivers/net/softnic/rte_eth_softnic_meter.c
new file mode 100644
index 000..0a5409b
--- /dev/null
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "rte_eth_softnic_internals.h"
+
+const struct rte_mtr_ops pmd_mtr_ops = {
+   .capabilities_get = NULL,
+
+   .meter_profile_add = NULL,
+   .meter_profile_delete = NULL,
+
+   .create = NULL,
+   .destroy = NULL,
+   .meter_enable = NULL,
+   .meter_disable = NULL,
+
+   .meter_profile_update = NULL,
+   .meter_dscp_table_update = NULL,
+   .policer_actions_update = NULL,
+   .stats_update = NULL,
+
+   .stats_read = NULL,
+};
-- 
2.9.3

[dpdk-dev] [PATCH v2 00/10] net/softnic: implement metering and policing API

[Jasvinder Singh]

This patchset adds the metering and policing API support for the
softnic. The metering and policing action can be enabled through the
flow rules.

This series is prepared on top of following patchset;
https://mails.dpdk.org/archives/dev/2018-September/111379.html

v2 changes:
- fix copyright year for rte_eth_softnic_meter.c
- Place all checks in a separate functions while creating meter object
- Use softnic_pipeline_table_mtr_profile_add() api to add meter profile
  instead of implementing new function
- Use stats type indicator to determine the stats_mask for meter stats read 
 
Jasvinder Singh (10):
  net/softnic: add metering and policing support
  net/softnic: add meter profile
  net/softnic: delete meter profile
  net/softnic: create meter object
  net/softnic: destroy meter object
  net/softnic: update meter profile
  net/softnic: update dscp table
  net/softnic: update policer actions
  net/softnic: meter stats read
  net/softnic: enable flow rule with meter action

 drivers/net/softnic/Makefile|   1 +
 drivers/net/softnic/meson.build |   1 +
 drivers/net/softnic/rte_eth_softnic.c   |  13 +
 drivers/net/softnic/rte_eth_softnic_flow.c  | 153 +
 drivers/net/softnic/rte_eth_softnic_internals.h |  66 +++
 drivers/net/softnic/rte_eth_softnic_meter.c | 713 
 drivers/net/softnic/rte_eth_softnic_pipeline.c  |  13 +
 7 files changed, 960 insertions(+)
 create mode 100644 drivers/net/softnic/rte_eth_softnic_meter.c

-- 
2.9.3

[dpdk-dev] [PATCH v2 02/10] net/softnic: add meter profile

[Jasvinder Singh]

Implement meter profile add function.

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/rte_eth_softnic.c   |   3 +
 drivers/net/softnic/rte_eth_softnic_internals.h |  31 ++
 drivers/net/softnic/rte_eth_softnic_meter.c | 122 +++-
 3 files changed, 155 insertions(+), 1 deletion(-)

diff --git a/drivers/net/softnic/rte_eth_softnic.c 
b/drivers/net/softnic/rte_eth_softnic.c
index 659a1b4..b7b2383 100644
--- a/drivers/net/softnic/rte_eth_softnic.c
+++ b/drivers/net/softnic/rte_eth_softnic.c
@@ -191,6 +191,7 @@ pmd_dev_stop(struct rte_eth_dev *dev)
softnic_mempool_free(p);
 
tm_hierarchy_free(p);
+   softnic_mtr_free(p);
 }
 
 static void
@@ -291,6 +292,7 @@ pmd_init(struct pmd_params *params)
 
/* Resources */
tm_hierarchy_init(p);
+   softnic_mtr_init(p);
 
softnic_mempool_init(p);
softnic_swq_init(p);
@@ -345,6 +347,7 @@ pmd_free(struct pmd_internals *p)
softnic_mempool_free(p);
 
tm_hierarchy_free(p);
+   softnic_mtr_free(p);
 
rte_free(p);
 }
diff --git a/drivers/net/softnic/rte_eth_softnic_internals.h 
b/drivers/net/softnic/rte_eth_softnic_internals.h
index 92be4e8..1db9310 100644
--- a/drivers/net/softnic/rte_eth_softnic_internals.h
+++ b/drivers/net/softnic/rte_eth_softnic_internals.h
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rte_eth_softnic.h"
 #include "conn.h"
@@ -68,6 +69,24 @@ struct flow_internals {
 };
 
 /**
+ * Meter
+ */
+
+/* MTR meter profile */
+struct softnic_mtr_meter_profile {
+   TAILQ_ENTRY(softnic_mtr_meter_profile) node;
+   uint32_t meter_profile_id;
+   struct rte_mtr_meter_profile params;
+   uint32_t n_users;
+};
+
+TAILQ_HEAD(softnic_mtr_meter_profile_list, softnic_mtr_meter_profile);
+
+struct mtr_internals {
+   struct softnic_mtr_meter_profile_list meter_profiles;
+};
+
+/**
  * MEMPOOL
  */
 struct softnic_mempool_params {
@@ -525,6 +544,8 @@ struct pmd_internals {
} soft;
 
struct flow_internals flow;
+   struct mtr_internals mtr;
+
struct softnic_conn *conn;
struct softnic_mempool_list mempool_list;
struct softnic_swq_list swq_list;
@@ -574,6 +595,16 @@ extern const struct rte_flow_ops pmd_flow_ops;
 /**
  * Meter
  */
+int
+softnic_mtr_init(struct pmd_internals *p);
+
+void
+softnic_mtr_free(struct pmd_internals *p);
+
+struct softnic_mtr_meter_profile *
+softnic_mtr_meter_profile_find(struct pmd_internals *p,
+   uint32_t meter_profile_id);
+
 extern const struct rte_mtr_ops pmd_mtr_ops;
 
 /**
diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c 
b/drivers/net/softnic/rte_eth_softnic_meter.c
index 0a5409b..1222866 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -11,10 +11,130 @@
 
 #include "rte_eth_softnic_internals.h"
 
+int
+softnic_mtr_init(struct pmd_internals *p)
+{
+   /* Initialize meter profiles list */
+   TAILQ_INIT(&p->mtr.meter_profiles);
+
+   return 0;
+}
+
+void
+softnic_mtr_free(struct pmd_internals *p)
+{
+   /* Remove meter profiles */
+   for ( ; ; ) {
+   struct softnic_mtr_meter_profile *mp;
+
+   mp = TAILQ_FIRST(&p->mtr.meter_profiles);
+   if (mp == NULL)
+   break;
+
+   TAILQ_REMOVE(&p->mtr.meter_profiles, mp, node);
+   free(mp);
+   }
+}
+
+struct softnic_mtr_meter_profile *
+softnic_mtr_meter_profile_find(struct pmd_internals *p,
+   uint32_t meter_profile_id)
+{
+   struct softnic_mtr_meter_profile_list *mpl = &p->mtr.meter_profiles;
+   struct softnic_mtr_meter_profile *mp;
+
+   TAILQ_FOREACH(mp, mpl, node)
+   if (meter_profile_id == mp->meter_profile_id)
+   return mp;
+
+   return NULL;
+}
+
+static int
+meter_profile_check(struct rte_eth_dev *dev,
+   uint32_t meter_profile_id,
+   struct rte_mtr_meter_profile *profile,
+   struct rte_mtr_error *error)
+{
+   struct pmd_internals *p = dev->data->dev_private;
+   struct softnic_mtr_meter_profile *mp;
+
+   /* Meter profile ID must be valid. */
+   if (meter_profile_id == UINT32_MAX)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_METER_PROFILE_ID,
+   NULL,
+   "Meter profile id not valid");
+
+   /* Meter profile must not exist. */
+   mp = softnic_mtr_meter_profile_find(p, meter_profile_id);
+   if (mp)
+   return -rte_mtr_error_set(error,
+   EEXIST,
+   RTE_MTR_ERROR_TYPE_METER_PROFILE_ID,
+   NULL,
+   "Meter prfile already exists");
+
+   /* Profile must not be NULL. */
+   if (profile == NULL)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+  

[dpdk-dev] [PATCH v2 03/10] net/softnic: delete meter profile

[Jasvinder Singh]

Implement meter profile delete function.

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/rte_eth_softnic_meter.c | 35 -
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c 
b/drivers/net/softnic/rte_eth_softnic_meter.c
index 1222866..f3205bd 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -131,11 +131,44 @@ pmd_mtr_meter_profile_add(struct rte_eth_dev *dev,
return 0;
 }
 
+/* MTR meter profile delete */
+static int
+pmd_mtr_meter_profile_delete(struct rte_eth_dev *dev,
+   uint32_t meter_profile_id,
+   struct rte_mtr_error *error)
+{
+   struct pmd_internals *p = dev->data->dev_private;
+   struct softnic_mtr_meter_profile *mp;
+
+   /* Meter profile must exist */
+   mp = softnic_mtr_meter_profile_find(p, meter_profile_id);
+   if (mp == NULL)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_METER_PROFILE_ID,
+   NULL,
+   "Meter profile id invalid");
+
+   /* Check unused */
+   if (mp->n_users)
+   return -rte_mtr_error_set(error,
+   EBUSY,
+   RTE_MTR_ERROR_TYPE_METER_PROFILE_ID,
+   NULL,
+   "Meter profile in use");
+
+   /* Remove from list */
+   TAILQ_REMOVE(&p->mtr.meter_profiles, mp, node);
+   free(mp);
+
+   return 0;
+}
+
 const struct rte_mtr_ops pmd_mtr_ops = {
.capabilities_get = NULL,
 
.meter_profile_add = pmd_mtr_meter_profile_add,
-   .meter_profile_delete = NULL,
+   .meter_profile_delete = pmd_mtr_meter_profile_delete,
 
.create = NULL,
.destroy = NULL,
-- 
2.9.3

[dpdk-dev] [PATCH v2 04/10] net/softnic: create meter object

[Jasvinder Singh]

implement meter object create function.

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/rte_eth_softnic_internals.h |  15 +++
 drivers/net/softnic/rte_eth_softnic_meter.c | 123 +++-
 2 files changed, 137 insertions(+), 1 deletion(-)

diff --git a/drivers/net/softnic/rte_eth_softnic_internals.h 
b/drivers/net/softnic/rte_eth_softnic_internals.h
index 1db9310..50b7295 100644
--- a/drivers/net/softnic/rte_eth_softnic_internals.h
+++ b/drivers/net/softnic/rte_eth_softnic_internals.h
@@ -82,8 +82,19 @@ struct softnic_mtr_meter_profile {
 
 TAILQ_HEAD(softnic_mtr_meter_profile_list, softnic_mtr_meter_profile);
 
+/* MTR meter object */
+struct softnic_mtr {
+   TAILQ_ENTRY(softnic_mtr) node;
+   uint32_t mtr_id;
+   struct rte_mtr_params params;
+   struct rte_flow *flow;
+};
+
+TAILQ_HEAD(softnic_mtr_list, softnic_mtr);
+
 struct mtr_internals {
struct softnic_mtr_meter_profile_list meter_profiles;
+   struct softnic_mtr_list mtrs;
 };
 
 /**
@@ -601,6 +612,10 @@ softnic_mtr_init(struct pmd_internals *p);
 void
 softnic_mtr_free(struct pmd_internals *p);
 
+struct softnic_mtr *
+softnic_mtr_find(struct pmd_internals *p,
+   uint32_t mtr_id);
+
 struct softnic_mtr_meter_profile *
 softnic_mtr_meter_profile_find(struct pmd_internals *p,
uint32_t meter_profile_id);
diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c 
b/drivers/net/softnic/rte_eth_softnic_meter.c
index f3205bd..12dd79c 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -17,12 +17,27 @@ softnic_mtr_init(struct pmd_internals *p)
/* Initialize meter profiles list */
TAILQ_INIT(&p->mtr.meter_profiles);
 
+   /* Initialize MTR objects list */
+   TAILQ_INIT(&p->mtr.mtrs);
+
return 0;
 }
 
 void
 softnic_mtr_free(struct pmd_internals *p)
 {
+   /* Remove MTR objects */
+   for ( ; ; ) {
+   struct softnic_mtr *m;
+
+   m = TAILQ_FIRST(&p->mtr.mtrs);
+   if (m == NULL)
+   break;
+
+   TAILQ_REMOVE(&p->mtr.mtrs, m, node);
+   free(m);
+   }
+
/* Remove meter profiles */
for ( ; ; ) {
struct softnic_mtr_meter_profile *mp;
@@ -164,13 +179,119 @@ pmd_mtr_meter_profile_delete(struct rte_eth_dev *dev,
return 0;
 }
 
+struct softnic_mtr *
+softnic_mtr_find(struct pmd_internals *p, uint32_t mtr_id)
+{
+   struct softnic_mtr_list *ml = &p->mtr.mtrs;
+   struct softnic_mtr *m;
+
+   TAILQ_FOREACH(m, ml, node)
+   if (m->mtr_id == mtr_id)
+   return m;
+
+   return NULL;
+}
+
+
+static int
+mtr_check(struct pmd_internals *p,
+   uint32_t mtr_id,
+   struct rte_mtr_params *params,
+   int shared,
+   struct rte_mtr_error *error)
+{
+   /* MTR id valid  */
+   if (softnic_mtr_find(p, mtr_id))
+   return -rte_mtr_error_set(error,
+   EEXIST,
+   RTE_MTR_ERROR_TYPE_MTR_ID,
+   NULL,
+   "MTR object already exists");
+
+   /* MTR params must not be NULL */
+   if (params == NULL)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_MTR_PARAMS,
+   NULL,
+   "MTR object params null");
+
+   /* Previous meter color not supported */
+   if (params->use_prev_mtr_color)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_MTR_PARAMS,
+   NULL,
+   "Previous meter color not supported");
+
+   /* Shared MTR object not supported */
+   if (shared)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_SHARED,
+   NULL,
+   "Shared MTR object not supported");
+
+   return 0;
+}
+
+/* MTR object create */
+static int
+pmd_mtr_create(struct rte_eth_dev *dev,
+   uint32_t mtr_id,
+   struct rte_mtr_params *params,
+   int shared,
+   struct rte_mtr_error *error)
+{
+   struct pmd_internals *p = dev->data->dev_private;
+   struct softnic_mtr_list *ml = &p->mtr.mtrs;
+   struct softnic_mtr_meter_profile *mp;
+   struct softnic_mtr *m;
+   int status;
+
+   /* Check parameters */
+   status = mtr_check(p, mtr_id, params, shared, error);
+   if (status)
+   return status;
+
+   /* Meter profile must exist */
+   mp = softnic_mtr_meter_profile_find(p, params->meter_profile_id);
+   if (mp == NULL)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_METER_PROFILE_ID,
+   NULL,
+   "Meter profile id

[dpdk-dev] [PATCH v2 05/10] net/softnic: destroy meter object

[Jasvinder Singh]

Implement meter object destroy function.

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/rte_eth_softnic_meter.c | 49 -
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c 
b/drivers/net/softnic/rte_eth_softnic_meter.c
index 12dd79c..5103bda 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -285,6 +285,53 @@ pmd_mtr_create(struct rte_eth_dev *dev,
return 0;
 }
 
+/* MTR object destroy */
+static int
+pmd_mtr_destroy(struct rte_eth_dev *dev,
+   uint32_t mtr_id,
+   struct rte_mtr_error *error)
+{
+   struct pmd_internals *p = dev->data->dev_private;
+   struct softnic_mtr_list *ml = &p->mtr.mtrs;
+   struct softnic_mtr_meter_profile *mp;
+   struct softnic_mtr *m;
+
+   /* MTR object must exist */
+   m = softnic_mtr_find(p, mtr_id);
+   if (m == NULL)
+   return -rte_mtr_error_set(error,
+   EEXIST,
+   RTE_MTR_ERROR_TYPE_MTR_ID,
+   NULL,
+   "MTR object id not valid");
+
+   /* MTR object must not have any owner */
+   if (m->flow != NULL)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_UNSPECIFIED,
+   NULL,
+   "MTR object is being used");
+
+   /* Get meter profile */
+   mp = softnic_mtr_meter_profile_find(p, m->params.meter_profile_id);
+   if (mp == NULL)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_METER_PROFILE_ID,
+   NULL,
+   "MTR object meter profile invalid");
+
+   /* Update dependencies */
+   mp->n_users--;
+
+   /* Remove from list */
+   TAILQ_REMOVE(ml, m, node);
+   free(m);
+
+   return 0;
+}
+
 const struct rte_mtr_ops pmd_mtr_ops = {
.capabilities_get = NULL,
 
@@ -292,7 +339,7 @@ const struct rte_mtr_ops pmd_mtr_ops = {
.meter_profile_delete = pmd_mtr_meter_profile_delete,
 
.create = pmd_mtr_create,
-   .destroy = NULL,
+   .destroy = pmd_mtr_destroy,
.meter_enable = NULL,
.meter_disable = NULL,
 
-- 
2.9.3

[dpdk-dev] [PATCH v2 06/10] net/softnic: update meter profile

[Jasvinder Singh]

Implement meter profile update function

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/rte_eth_softnic_internals.h |  14 
 drivers/net/softnic/rte_eth_softnic_meter.c | 104 +++-
 drivers/net/softnic/rte_eth_softnic_pipeline.c  |  12 +++
 3 files changed, 129 insertions(+), 1 deletion(-)

diff --git a/drivers/net/softnic/rte_eth_softnic_internals.h 
b/drivers/net/softnic/rte_eth_softnic_internals.h
index 50b7295..784035f 100644
--- a/drivers/net/softnic/rte_eth_softnic_internals.h
+++ b/drivers/net/softnic/rte_eth_softnic_internals.h
@@ -320,6 +320,15 @@ struct softnic_table_action_profile {
 
 TAILQ_HEAD(softnic_table_action_profile_list, softnic_table_action_profile);
 
+struct softnic_table_action_meter_profile {
+   TAILQ_ENTRY(softnic_table_action_meter_profile) node;
+   uint32_t meter_profile_id;
+   struct rte_table_action_meter_profile profile;
+};
+
+TAILQ_HEAD(softnic_table_action_meter_profile_list,
+   softnic_table_action_meter_profile);
+
 /**
  * Pipeline
  */
@@ -455,6 +464,7 @@ struct softnic_table {
struct softnic_table_action_profile *ap;
struct rte_table_action *a;
struct flow_list flows;
+   struct softnic_table_action_meter_profile_list meter_profiles;
 };
 
 struct pipeline {
@@ -620,6 +630,10 @@ struct softnic_mtr_meter_profile *
 softnic_mtr_meter_profile_find(struct pmd_internals *p,
uint32_t meter_profile_id);
 
+struct softnic_mtr_meter_profile *
+softnic_table_meter_profile_find(struct softnic_table *table,
+   uint32_t meter_profile_id);
+
 extern const struct rte_mtr_ops pmd_mtr_ops;
 
 /**
diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c 
b/drivers/net/softnic/rte_eth_softnic_meter.c
index 5103bda..e5c8f09 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -332,6 +332,108 @@ pmd_mtr_destroy(struct rte_eth_dev *dev,
return 0;
 }
 
+/* MTR object meter profile update */
+static int
+pmd_mtr_meter_profile_update(struct rte_eth_dev *dev,
+   uint32_t mtr_id,
+   uint32_t meter_profile_id,
+   struct rte_mtr_error *error)
+{
+   struct pmd_internals *p = dev->data->dev_private;
+   struct rte_table_action_meter_profile profile;
+   struct softnic_table_rule_action action;
+   struct softnic_mtr_meter_profile *mp_in, *mp_out;
+   struct softnic_mtr *m;
+   int status;
+
+   /* MTR object id must be valid */
+   m = softnic_mtr_find(p, mtr_id);
+   if (m == NULL)
+   return -rte_mtr_error_set(error,
+   EEXIST,
+   RTE_MTR_ERROR_TYPE_MTR_ID,
+   NULL,
+   "MTR object id not valid");
+
+   /* Meter profile id must be valid */
+   mp_in = softnic_mtr_meter_profile_find(p, meter_profile_id);
+   if (mp_in == NULL)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_METER_PROFILE_ID,
+   NULL,
+   "Meter profile not valid");
+
+   /* MTR object current meter profile */
+   mp_out = softnic_mtr_meter_profile_find(p, m->params.meter_profile_id);
+   if (mp_out == NULL)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_METER_PROFILE_ID,
+   NULL,
+   "MTR object current meter profile invalid");
+
+   /* MTR object already set to meter profile id */
+   if (m->params.meter_profile_id == meter_profile_id)
+   return 0;
+
+   /*  MTR object owner table update */
+   if (m->flow) {
+   memset(&profile, 0, sizeof(profile));
+
+   profile.alg = RTE_TABLE_ACTION_METER_TRTCM;
+   profile.trtcm.cir = mp_in->params.trtcm_rfc2698.cir;
+   profile.trtcm.pir = mp_in->params.trtcm_rfc2698.pir;
+   profile.trtcm.cbs = mp_in->params.trtcm_rfc2698.cbs;
+   profile.trtcm.pbs = mp_in->params.trtcm_rfc2698.pbs;
+
+   /* Add meter profile to pipeline table */
+   status = softnic_pipeline_table_mtr_profile_add(p,
+   m->flow->pipeline->name,
+   m->flow->table_id,
+   meter_profile_id,
+   &profile);
+   if (status)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_UNSPECIFIED,
+   NULL,
+   "Table meter profile add failed");
+
+   /* Set meter action */
+   memset(&action, 0, sizeof(action));
+   memcpy(&action, &m->flow->action, sizeof(action));
+
+   action.mtr.mtr[0].meter_profile_id = meter_profile_id;
+
+

[dpdk-dev] [PATCH v2 10/10] net/softnic: enable flow rule with meter action

[Jasvinder Singh]

Implement flow rules with meter action.

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/rte_eth_softnic_flow.c | 153 +
 1 file changed, 153 insertions(+)

diff --git a/drivers/net/softnic/rte_eth_softnic_flow.c 
b/drivers/net/softnic/rte_eth_softnic_flow.c
index fc7a0b0..f0eeff2 100644
--- a/drivers/net/softnic/rte_eth_softnic_flow.c
+++ b/drivers/net/softnic/rte_eth_softnic_flow.c
@@ -1474,6 +1474,101 @@ flow_rule_action_get(struct pmd_internals *softnic,
break;
} /* RTE_FLOW_ACTION_TYPE_COUNT */
 
+   case RTE_FLOW_ACTION_TYPE_METER:
+   {
+   struct rte_table_action_mtr_tc_params mtr_tc_params;
+   const struct rte_flow_action_meter *conf = action->conf;
+   struct rte_table_action_meter_profile profile;
+   struct softnic_mtr_meter_profile *mp;
+   struct softnic_mtr *m;
+   uint32_t i, meter_profile_id, table_id = UINT32_MAX;
+   int status;
+
+   if (conf == NULL)
+   return rte_flow_error_set(error,
+   EINVAL,
+   RTE_FLOW_ERROR_TYPE_ACTION,
+   action,
+   "METER: Null configuration");
+
+   if ((params->action_mask & (1LLU << 
RTE_TABLE_ACTION_MTR)) == 0)
+   return rte_flow_error_set(error,
+   EINVAL,
+   RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+   NULL,
+   "METER: table action not supported");
+
+   m = softnic_mtr_find(softnic, conf->mtr_id);
+   if (m == NULL)
+   return -rte_flow_error_set(error,
+   EINVAL,
+   RTE_FLOW_ERROR_TYPE_ACTION_CONF,
+   NULL,
+   "METER: invalid meter id");
+
+   if (m->flow)
+   return -rte_flow_error_set(error,
+   EINVAL,
+   RTE_FLOW_ERROR_TYPE_ACTION_CONF,
+   NULL,
+   "METER: meter already attached to 
flow");
+
+   if (params->mtr.n_tc != 1)
+   return -rte_flow_error_set(error,
+   EINVAL,
+   RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+   NULL,
+   "METER: multiple TCs not supported");
+
+   meter_profile_id = m->params.meter_profile_id;
+   mp = softnic_mtr_meter_profile_find(softnic, 
meter_profile_id);
+
+   memset(&profile, 0, sizeof(profile));
+   profile.alg = RTE_TABLE_ACTION_METER_TRTCM;
+   profile.trtcm.cir = mp->params.trtcm_rfc2698.cir;
+   profile.trtcm.pir = mp->params.trtcm_rfc2698.pir;
+   profile.trtcm.cbs = mp->params.trtcm_rfc2698.cbs;
+   profile.trtcm.pbs = mp->params.trtcm_rfc2698.pbs;
+
+   /* Identify the pipeline table to add this flow to. */
+   for (i = 0; i < pipeline->n_tables; i++) {
+   if (table == &pipeline->table[i]) {
+   table_id = i;
+   break;
+   }
+   }
+
+   /* Add meter profile to pipeline table */
+   status = softnic_pipeline_table_mtr_profile_add(softnic,
+   pipeline->name,
+   table_id,
+   meter_profile_id,
+   &profile);
+   if (status) {
+   rte_flow_error_set(error,
+   EINVAL,
+   RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+   NULL,
+   "Table meter profile add failed");
+   return -1;
+   }
+
+   /* RTE_TABLE_ACTION_METER */
+   mtr_tc_params.meter_profile_id = meter_profile_id;
+   mtr_tc_params.policer[e_RTE_METER_GREEN] =
+   (enum 
rte_table_action_policer)m->params.action[RTE_MTR

[dpdk-dev] [PATCH v2 07/10] net/softnic: update dscp table

[Jasvinder Singh]

Implement meter object dscp table update.

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/rte_eth_softnic_internals.h |  1 +
 drivers/net/softnic/rte_eth_softnic_meter.c | 54 -
 drivers/net/softnic/rte_eth_softnic_pipeline.c  |  1 +
 3 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/net/softnic/rte_eth_softnic_internals.h 
b/drivers/net/softnic/rte_eth_softnic_internals.h
index 784035f..ac05eba 100644
--- a/drivers/net/softnic/rte_eth_softnic_internals.h
+++ b/drivers/net/softnic/rte_eth_softnic_internals.h
@@ -464,6 +464,7 @@ struct softnic_table {
struct softnic_table_action_profile *ap;
struct rte_table_action *a;
struct flow_list flows;
+   struct rte_table_action_dscp_table dscp_table;
struct softnic_table_action_meter_profile_list meter_profiles;
 };
 
diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c 
b/drivers/net/softnic/rte_eth_softnic_meter.c
index e5c8f09..6135f21 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -434,6 +434,58 @@ pmd_mtr_meter_profile_update(struct rte_eth_dev *dev,
return 0;
 }
 
+/* MTR object meter DSCP table update */
+static int
+pmd_mtr_meter_dscp_table_update(struct rte_eth_dev *dev,
+   uint32_t mtr_id,
+   enum rte_mtr_color *dscp_table,
+   struct rte_mtr_error *error)
+{
+   struct pmd_internals *p = dev->data->dev_private;
+   struct rte_table_action_dscp_table dt;
+   struct pipeline *pipeline;
+   struct softnic_table *table;
+   struct softnic_mtr *m;
+   uint32_t i;
+   int status;
+
+   /* MTR object id must be valid */
+   m = softnic_mtr_find(p, mtr_id);
+   if (m == NULL)
+   return -rte_mtr_error_set(error,
+   EEXIST,
+   RTE_MTR_ERROR_TYPE_MTR_ID,
+   NULL,
+   "MTR object id not valid");
+
+   /* MTR object owner valid? */
+   if (m->flow == NULL)
+   return 0;
+
+   /* Update data plane table */
+   pipeline = m->flow->pipeline;
+   table = &pipeline->table[m->flow->table_id];
+
+   memcpy(&dt, &table->dscp_table, sizeof(dt));
+   for (i = 0; i < RTE_DIM(dt.entry); i++)
+   dt.entry[i].color = (enum rte_meter_color)dscp_table[i];
+
+   status = rte_table_action_dscp_table_update(table->a,
+   UINT64_MAX,
+   &dt);
+   if (status)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_UNSPECIFIED,
+   NULL,
+   "Table action dscp table update failed");
+
+   /* Update table */
+   memcpy(&table->dscp_table, &dt, sizeof(table->dscp_table));
+
+   return 0;
+}
+
 const struct rte_mtr_ops pmd_mtr_ops = {
.capabilities_get = NULL,
 
@@ -446,7 +498,7 @@ const struct rte_mtr_ops pmd_mtr_ops = {
.meter_disable = NULL,
 
.meter_profile_update = pmd_mtr_meter_profile_update,
-   .meter_dscp_table_update = NULL,
+   .meter_dscp_table_update = pmd_mtr_meter_dscp_table_update,
.policer_actions_update = NULL,
.stats_update = NULL,
 
diff --git a/drivers/net/softnic/rte_eth_softnic_pipeline.c 
b/drivers/net/softnic/rte_eth_softnic_pipeline.c
index 26d10a1..5deb93c 100644
--- a/drivers/net/softnic/rte_eth_softnic_pipeline.c
+++ b/drivers/net/softnic/rte_eth_softnic_pipeline.c
@@ -1000,6 +1000,7 @@ softnic_pipeline_table_create(struct pmd_internals 
*softnic,
table->a = action;
TAILQ_INIT(&table->flows);
TAILQ_INIT(&table->meter_profiles);
+   memset(&table->dscp_table, 0, sizeof(table->dscp_table));
pipeline->n_tables++;
 
return 0;
-- 
2.9.3

[dpdk-dev] [PATCH v2 09/10] net/softnic: meter stats read

[Jasvinder Singh]

Implement meter object stats read function.

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/rte_eth_softnic_meter.c | 115 +++-
 1 file changed, 114 insertions(+), 1 deletion(-)

diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c 
b/drivers/net/softnic/rte_eth_softnic_meter.c
index bc1f2ea..369f670 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -580,6 +580,119 @@ pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
return 0;
 }
 
+/* MTR object stats read */
+static int
+pmd_mtr_stats_read(struct rte_eth_dev *dev,
+   uint32_t mtr_id,
+   struct rte_mtr_stats *stats,
+   uint64_t *stats_mask,
+   int clear,
+   struct rte_mtr_error *error)
+{
+   struct pmd_internals *p = dev->data->dev_private;
+   struct rte_table_action_mtr_counters counters;
+   struct rte_table_action_mtr_counters_tc *c;
+   struct rte_mtr_stats s;
+   struct softnic_table *table;
+   struct pipeline *pipeline;
+   struct softnic_mtr *m;
+   uint64_t mask = 0;
+   uint32_t i, tc_mask = 1 << 0;
+   int status;
+
+   /* MTR object id must be valid */
+   m = softnic_mtr_find(p, mtr_id);
+   if (m == NULL)
+   return -rte_mtr_error_set(error,
+   EEXIST,
+   RTE_MTR_ERROR_TYPE_MTR_ID,
+   NULL,
+   "MTR object id not valid");
+
+   /* MTR meter object owner valid? */
+   if (m->flow == NULL)
+   return 0;
+
+   /* Meter stats */
+   pipeline = m->flow->pipeline;
+   table = &pipeline->table[m->flow->table_id];
+
+   status = rte_table_action_meter_read(table->a,
+   m->flow->data,
+   tc_mask,
+   &counters,
+   clear);
+   if (status)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_UNSPECIFIED,
+   NULL,
+   "Meter stats read failed");
+
+   c = &counters.stats[0];
+   memset(&s, 0, sizeof(s));
+
+   if (c->n_packets_valid) {
+   for (i = 0; i < RTE_MTR_COLORS; i++) {
+   if (m->params.action[i] == 
MTR_POLICER_ACTION_COLOR_GREEN)
+   s.n_pkts[RTE_MTR_GREEN] += c->n_packets[i];
+
+   if (m->params.action[i] == 
MTR_POLICER_ACTION_COLOR_YELLOW)
+   s.n_pkts[RTE_MTR_YELLOW] += c->n_packets[i];
+
+   if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_RED)
+   s.n_pkts[RTE_MTR_RED] += c->n_packets[i];
+
+   if (m->params.action[i] == MTR_POLICER_ACTION_DROP)
+   s.n_pkts_dropped += c->n_packets[i];
+   }
+
+   mask = RTE_MTR_STATS_N_PKTS_GREEN |
+   RTE_MTR_STATS_N_PKTS_YELLOW |
+   RTE_MTR_STATS_N_PKTS_RED |
+   RTE_MTR_STATS_N_PKTS_DROPPED;
+   }
+
+   if (c->n_bytes_valid) {
+   for (i = 0; i < RTE_MTR_COLORS; i++) {
+   if (m->params.action[i] == 
MTR_POLICER_ACTION_COLOR_GREEN)
+   s.n_bytes[RTE_MTR_GREEN] += c->n_bytes[i];
+
+   if (m->params.action[i] == 
MTR_POLICER_ACTION_COLOR_YELLOW)
+   s.n_bytes[RTE_MTR_YELLOW] += c->n_bytes[i];
+
+   if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_RED)
+   s.n_bytes[RTE_MTR_RED] += c->n_bytes[i];
+
+   if (m->params.action[i] == MTR_POLICER_ACTION_DROP)
+   s.n_bytes_dropped += c->n_bytes[i];
+   }
+
+   mask |= RTE_MTR_STATS_N_BYTES_GREEN |
+   RTE_MTR_STATS_N_BYTES_YELLOW |
+   RTE_MTR_STATS_N_BYTES_RED |
+   RTE_MTR_STATS_N_BYTES_DROPPED;
+   }
+
+   /* Read */
+   if (stats) {
+   memset(stats, 0, sizeof(*stats));
+   memcpy(stats, &s, sizeof(*stats));
+   }
+
+   if (stats_mask) {
+   if (mask)
+   *stats_mask = mask;
+   else
+   *stats_mask = RTE_MTR_STATS_N_PKTS_GREEN |
+   RTE_MTR_STATS_N_PKTS_YELLOW |
+   RTE_MTR_STATS_N_PKTS_RED |
+   RTE_MTR_STATS_N_PKTS_DROPPED;
+   }
+
+   return 0;
+}
+
 const struct rte_mtr_ops pmd_mtr_ops = {
.capabilities_get = NULL,
 
@@ -596,5 +709,5 @@ const struct rte_mtr_ops pmd_mtr_ops = {
.policer_actions_update = pmd_mtr_policer_actions_update,
.stats_update = NULL,
 
-   .stats_read = NULL,
+   .stats_read = pmd_mtr_stats_read,
 };
-- 
2.9.3

[dpdk-dev] [PATCH v2 08/10] net/softnic: update policer actions

[Jasvinder Singh]

Implement meter object policer actions function.

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/rte_eth_softnic_meter.c | 96 -
 1 file changed, 95 insertions(+), 1 deletion(-)

diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c 
b/drivers/net/softnic/rte_eth_softnic_meter.c
index 6135f21..bc1f2ea 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -486,6 +486,100 @@ pmd_mtr_meter_dscp_table_update(struct rte_eth_dev *dev,
return 0;
 }
 
+/* MTR object policer action update */
+static int
+pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
+   uint32_t mtr_id,
+   uint32_t action_mask,
+   enum rte_mtr_policer_action *actions,
+   struct rte_mtr_error *error)
+{
+   struct pmd_internals *p = dev->data->dev_private;
+   struct softnic_table_rule_action action;
+   struct softnic_table *table;
+   struct pipeline *pipeline;
+   struct softnic_mtr *m;
+   uint32_t i, tc_mask = 1 << 0;
+   int status;
+
+   /* MTR object id must be valid */
+   m = softnic_mtr_find(p, mtr_id);
+   if (m == NULL)
+   return -rte_mtr_error_set(error,
+   EEXIST,
+   RTE_MTR_ERROR_TYPE_MTR_ID,
+   NULL,
+   "MTR object id not valid");
+
+   /* Valid policer actions */
+   if (actions == NULL)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_UNSPECIFIED,
+   NULL,
+   "Invalid actions");
+
+   for (i = 0; i < RTE_MTR_COLORS; i++) {
+   if ((action_mask >> i) & 1) {
+   if (actions[i] != MTR_POLICER_ACTION_COLOR_GREEN  &&
+   actions[i] != MTR_POLICER_ACTION_COLOR_YELLOW &&
+   actions[i] != MTR_POLICER_ACTION_COLOR_RED &&
+   actions[i] != MTR_POLICER_ACTION_DROP) {
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_UNSPECIFIED,
+   NULL,
+   " Invalid action value");
+   }
+   }
+   }
+
+   /* MTR object owner valid? */
+   if (m->flow) {
+   memset(&action, 0, sizeof(action));
+   memcpy(&action, &m->flow->action, sizeof(action));
+   pipeline = m->flow->pipeline;
+
+   /* Set action */
+   for (i = 0; i < RTE_MTR_COLORS; i++) {
+   if ((action_mask >> i) & 1)
+   action.mtr.mtr[0].policer[i] =
+   (enum 
rte_table_action_policer)actions[i];
+   }
+
+   /* Re-add the rule */
+   status = softnic_pipeline_table_rule_add(p,
+   pipeline->name,
+   m->flow->table_id,
+   &m->flow->match,
+   &action,
+   &m->flow->data);
+   if (status)
+   return -rte_mtr_error_set(error,
+   EINVAL,
+   RTE_MTR_ERROR_TYPE_UNSPECIFIED,
+   NULL,
+   "Pipeline table rule re-add failed");
+
+   /* Update flow action */
+   memcpy(&m->flow->action, &action, sizeof(m->flow->action));
+
+   /* Reset the meter stats */
+   table = &pipeline->table[m->flow->table_id];
+
+   rte_table_action_meter_read(table->a, m->flow->data,
+   tc_mask, NULL, 1);
+   }
+
+   /* Update MTR object policer actions */
+   for (i = 0; i < RTE_MTR_COLORS; i++) {
+   if ((action_mask >> i) & 1)
+   m->params.action[i] = actions[i];
+   }
+
+   return 0;
+}
+
 const struct rte_mtr_ops pmd_mtr_ops = {
.capabilities_get = NULL,
 
@@ -499,7 +593,7 @@ const struct rte_mtr_ops pmd_mtr_ops = {
 
.meter_profile_update = pmd_mtr_meter_profile_update,
.meter_dscp_table_update = pmd_mtr_meter_dscp_table_update,
-   .policer_actions_update = NULL,
+   .policer_actions_update = pmd_mtr_policer_actions_update,
.stats_update = NULL,
 
.stats_read = NULL,
-- 
2.9.3

Re: [dpdk-dev] [PATCH v2] ethdev: fix missing names in Tx offload name array

[Ferruh Yigit]

On 9/12/2018 9:33 AM, Andrew Rybchenko wrote:
> On 09/12/2018 11:28 AM, Dekel Peled wrote:
>> Patch 5355f443 added two definitions of DEV_TX_OFFLOAD_xxx.
>> If new Tx offload capabilities are defined, they also must be mentioned
>> in rte_tx_offload_names in rte_ethdev.c file.
>>
>> This patch adds the required lines in array rte_tx_offload_names.
>>
>> Fixes: 5355f4439e2e ("ethdev: introduce generic IP/UDP tunnel checksum and 
>> TSO")
>>
>> Cc: xuemi...@mellanox.com
>>
>> Signed-off-by: Dekel Peled 
> 
> Acked-by: Andrew Rybchenko 

 Cc: sta...@dpdk.org

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

[dpdk-dev] [PATCH] build: create relative symlinks for PMDs in libdir

[Luca Boccassi]

Add -r option to ln, otherwise the link will be absolute and contain
the build path and break packaging among other things:

lrwxrwxrwx 1 bluca bluca 99 Sep 11 22:17 librte_mempool_dpaa.so.1.1
  -> /home/bluca/git/dpdk/testt4//usr/local/lib/x86_64-linux-gnu/dpdk/
 drivers/librte_mempool_dpaa.so.1.1

With -r:

lrwxrwxrwx 1 bluca bluca 35 Sep 12 18:13 librte_pmd_zlib.so.1.1
  -> dpdk/drivers/librte_pmd_zlib.so.1.1

Fixes: ed4d43d73e2b ("build: symlink drivers to library directory")
Cc: sta...@dpdk.org

Signed-off-by: Luca Boccassi 
---
 buildtools/symlink-drivers-solibs.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/buildtools/symlink-drivers-solibs.sh 
b/buildtools/symlink-drivers-solibs.sh
index 803dfec491..9826c6ae37 100644
--- a/buildtools/symlink-drivers-solibs.sh
+++ b/buildtools/symlink-drivers-solibs.sh
@@ -9,4 +9,4 @@
 # parameters to script are paths relative to install prefix:
 # 1. directory containing driver files e.g. lib64/dpdk/drivers
 # 2. directory for installed regular libs e.g. lib64
-ln -sf ${DESTDIR}/${MESON_INSTALL_PREFIX}/$1/* 
${DESTDIR}/${MESON_INSTALL_PREFIX}/$2
+ln -rsf ${DESTDIR}/${MESON_INSTALL_PREFIX}/$1/* 
${DESTDIR}/${MESON_INSTALL_PREFIX}/$2
-- 
2.18.0

Re: [dpdk-dev] [PATCH] build: create relative symlinks for PMDs in libdir

[Timothy Redaelli]

On Wed, 12 Sep 2018 18:21:34 +0100
Luca Boccassi  wrote:

> Add -r option to ln, otherwise the link will be absolute and contain
> the build path and break packaging among other things:
> 
> lrwxrwxrwx 1 bluca bluca 99 Sep 11 22:17
> librte_mempool_dpaa.so.1.1
> -> /home/bluca/git/dpdk/testt4//usr/local/lib/x86_64-linux-gnu/dpdk/
> drivers/librte_mempool_dpaa.so.1.1
> 
> With -r:
> 
> lrwxrwxrwx 1 bluca bluca 35 Sep 12 18:13 librte_pmd_zlib.so.1.1
>   -> dpdk/drivers/librte_pmd_zlib.so.1.1  
> 
> Fixes: ed4d43d73e2b ("build: symlink drivers to library directory")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Luca Boccassi 

Tested on Fedora 28 by building dpdk using meson from a spec file

Tested-by: Timothy Redaelli 

Re: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing

[Ananyev, Konstantin]

Hi Anoob,

> 
> Hi Konstantin,
> Please see inline.
> 
> 
> This RFC introduces a new library within DPDK: librte_ipsec.
> The aim is to provide DPDK native high performance library for IPsec
> data-path processing.
> The library is supposed to utilize existing DPDK crypto-dev and
> security API to provide application with transparent IPsec processing API.
> The library is concentrated on data-path protocols processing (ESP and AH),
> IKE protocol(s) implementation is out of scope for that library.
> Though hook/callback mechanisms will be defined to allow integrate it
> with existing IKE implementations.
> Due to quite complex nature of IPsec protocol suite and variety of user
> requirements and usage scenarios a few API levels will be provided:
> 1) Security Association (SA-level) API
>  Operates at SA level, provides functions to:
>  - initialize/teardown SA object
>  - process inbound/outbound ESP/AH packets associated with the given SA
>(decrypt/encrypt, authenticate, check integrity,
> add/remove ESP/AH related headers and data, etc.).
> 2) Security Association Database (SAD) API
>  API to create/manage/destroy IPsec SAD.
>  While DPDK IPsec library plans to have its own implementation,
>  the intention is to keep it as independent from the other parts
>  of IPsec library as possible.
>  That is supposed to give users the ability to provide their own
>  implementation of the SAD compatible with the other parts of the
>  IPsec library.
> 3) IPsec Context (CTX) API
>  This is supposed to be a high-level API, where each IPsec CTX is an
>  abstraction of 'independent copy of the IPsec stack'.
>  CTX owns set of SAs, SADs and assigned to it crypto-dev queues, etc.
>  and provides:
>  - de-multiplexing stream of inbound packets to particular SAs and
>further IPsec related processing.
>  - IPsec related processing for the outbound packets.
>  - SA add/delete/update functionality
> [Anoob]: Security Policy is an important aspect of IPsec. An IPsec
> library without Security Policy API would be incomplete. For inline
> protocol offload, the final SP-SA check(selector check) is the only
> IPsec part being done by ipsec-secgw now. Would make sense to add that
> also in the library.
> 
> You mean here, that we need some sort of SPD implementation, correct?
> [Anoob] Yes.

Ok, I see.
Our thought was that just something based on librte_acl would be enough here...
But if you think that a special defined SPD API (and implementation) is needed -
we can probably discuss it along with SAD API (#2 above).
Though if you'd like to start to work on RFC for it right-away - please feel 
free to do so :)

> 
> 
> 
> Current RFC concentrates on SA-level API only (1),
> detailed discussion for 2) and 3) will be subjects for separate RFC(s).
> 
> SA (low) level API
> ==
> 
> API described below operates on SA level.
> It provides functionality that allows user for given SA to process
> inbound and outbound IPsec packets.
> To be more specific:
> - for inbound ESP/AH packets perform decryption, authentication,
>integrity checking, remove ESP/AH related headers
> [Anoob] Anti-replay check would also be required.
> 
> Yep, anti-replay and ESN support is implied as part of "integrity checking".
> Probably I have to be more specific here.
> [Anoob] This is fine.
> 
> 
> 
> - for outbound packets perform payload encryption, attach ICV,
>update/add IP headers, add ESP/AH headers/trailers,
>setup related mbuf felids (ol_flags, tx_offloads, etc.).
> [Anoob] Do we have any plans to handle ESN expiry? Some means to
> initiate an IKE renegotiation? I'm assuming application won't be aware
> of the sequence numbers, in this case.
> [Anoob] What is your plan with events like ESN expiry? IPsec spec talks about 
> byte and time expiry as well.

At current moment, for SA level: 
rte_ipsec_crypto_prepare()/rte_ipsec_inline_process() will set rte_errno
to special value (EOVERFLOW) to signal upper layer that limit is reached.
Upper layer can decide to start re-negotiation, or just destroy an SA.
 
Future plans for IPsec Context (CTX) API (#3 above):
Introduce a special function, something like:
rte_ipsec_get_expired(rte_ipsec_ctx *ctx, rte_ipsec_sa *expired_sa[], uint32_t 
num);
It would return up-to *num* of SAs for given ipsec context, that are 
expired/limit reached.
Then upper layer again might decide for each SA should renegotiation be started,
or just wipe given SA.
It would be upper layer responsibility to call this function periodically.
 
> 
> 
> - initialize/un-initialize given SA based on user provided parameters.
> 
> Processed inbound/outbound packets could be grouped by user provided
> flow id (opaque 64-bit number associated by user with given SA).
> 
> SA-level API is based on top of crypto-dev/security API and relies on them
> to perform actual cipher and integrity checking.
> Due to the nature of crypto-dev API (e

Re: [dpdk-dev] [PATCH] test/bpf: use hton instead of __builtin_bswap

[Malvika Gupta]

Hi Konstantin,

I installed the clang version 4.0.1 to check for the issue you were facing with 
-O2 compilation. I was able to compile with -O2 and -O0 optimization without 
any errors. Please see the exact command I used and the following output for 
your reference:

$ clang -O2 -target bpf -I /usr/include/aarch64-linux-gnu/ -c t1.c 
$ clang -O0 -target bpf -I /usr/include/aarch64-linux-gnu/ -c t1.c
$ clang -v
clang version 4.0.1-10 (tags/RELEASE_401/final)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/8.0.1
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/8.0.1
Selected GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/7.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

I hope this was helpful to you.
Best Regards,
Malvika Gupta


-Original Message-
From: Malvika Gupta 
Sent: Wednesday, September 5, 2018 4:43 PM
To: Ananyev, Konstantin 
Cc: dev@dpdk.org; Gavin Hu (Arm Technology China) ; Honnappa 
Nagarahalli ; Brian Brooks 
; nd 
Subject: RE: [PATCH] test/bpf: use hton instead of __builtin_bswap

Hi Ananyev,

I used clang version 6.0.0. Please see the following output for your reference. 

$ clang -v
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/8.0.1
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/6 Found 
candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/7 Found 
candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/8 Found 
candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/8.0.1
Selected GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/7.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

Also, the code compiles with both -O2 and -O0 for me. 

I hope this was helpful
Best,
Malvika

-Original Message-
From: Ananyev, Konstantin 
Sent: Tuesday, September 4, 2018 8:56 AM
To: Malvika Gupta 
Cc: dev@dpdk.org; Gavin Hu (Arm Technology China) ; Honnappa 
Nagarahalli ; Brian Brooks 
; nd 
Subject: RE: [PATCH] test/bpf: use hton instead of __builtin_bswap

Hi,

> 
> Convert host machine endianness to networking endianness for 
> comparison of incoming packets with BPF filter
> 
> 
> Signed-off-by: Malvika Gupta 
> Reviewed-by: Gavin Hu 
> Reviewed-by: Brian Brooks 
> Suggested-by: Brian Brooks 
> ---
>  test/bpf/t1.c | 7 ---
>  test/bpf/t3.c | 3 ++-
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/test/bpf/t1.c b/test/bpf/t1.c index 60f9434ab..7943fcf34
> 100644
> --- a/test/bpf/t1.c
> +++ b/test/bpf/t1.c
> @@ -28,24 +28,25 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  uint64_t
>  entry(void *pkt)
>  {
>   struct ether_header *ether_header = (void *)pkt;
> 
> - if (ether_header->ether_type != __builtin_bswap16(0x0800))
> + if (ether_header->ether_type != htons(0x0800))

Which version of clang do you use?
With my one I get:
$ clang -O2 -target bpf -c t1.c
t1.c:37:34: error: couldn't allocate output register for constraint 'r'
if (ether_header->ether_type != ntohs(0x0800))
^
/usr/include/netinet/in.h:402:21: note: expanded from macro 'ntohs'
#   define ntohs(x) __bswap_16 (x)
^
/usr/include/bits/byteswap-16.h:31:14: note: expanded from macro '__bswap_16'
   __asm__ ("rorw $8, %w0"  

With '-O0' it compiles ok.

$ clang -v
clang version 4.0.1 (tags/RELEASE_401/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-l

Re: [dpdk-dev] [PATCH v3] hash table: add an iterator over conflicting entries

[Honnappa Nagarahalli]

Hi Michel,
I applied your patch and tweaked the code to run few performance tests 
on Arm (Cortex-A72, 1.3GHz) and x86 (Intel Xeon CPU E5-2660 v4 @ 2.00GHz). The 
perf code looks as follows:

count_b = rte_rdtsc_precise();
int k = 0;
rte_hash_iterator_init(tbl_rw_test_param.h, &state);

while (rte_hash_iterate(&state, &next_key, &next_data) >= 0) {
/* Search for the key in the list of keys added .*/
i = *(const uint32_t *)next_key;
tbl_rw_test_param.found[i]++;
k++;
}

count_a = rte_rdtsc_precise() - count_b;
printf("*Cycles2 per iterate call: %lu\n", count_a/k);

Further, I changed the rte_hash_iterate as follows and ran the same test.
int32_t rte_hash_iterate(const struct rte_hash *h, struct 
rte_hash_iterator_state *state, const void **key, void **data)

Finally, I used memset in the place of rte_hash_iterator_init with the required 
changes to rte_hash_iterate.

All these tests show little variation in 'cycles per iterate call' for both 
architectures.


-Original Message-
From: Michel Machado  
Sent: Thursday, September 6, 2018 9:29 AM
To: Honnappa Nagarahalli ; Qiaobin Fu 
; bruce.richard...@intel.com; pablo.de.lara.gua...@intel.com
Cc: dev@dpdk.org; douce...@bu.edu; keith.wi...@intel.com; 
sameh.gobr...@intel.com; charlie@intel.com; step...@networkplumber.org; nd 
; yipeng1.w...@intel.com
Subject: Re: [PATCH v3] hash table: add an iterator over conflicting entries

On 09/05/2018 06:13 PM, Honnappa Nagarahalli wrote:
>> +uint32_t  next;
>> +uint32_t  total_entries;
>> +};
>> This structure can be moved to rte_cuckoo_hash.h file.
> 
>  What's the purpose of moving this struct to a header file since it's 
> only used in the C file rte_cuckoo_hash.c?
> 
> This is to maintain consistency. For ex: 'struct queue_node', which is 
> an internal structure, is kept in rte_cuckoo_hash.h

Okay. We'll move it there.

>> +int32_t
>> +rte_hash_iterator_init(const struct rte_hash *h,
>> +struct rte_hash_iterator_state *state) {
>> +struct rte_hash_iterator_istate *__state;
>> '__state' can be replaced by 's'.
>>
>> +
>> +RETURN_IF_TRUE(((h == NULL) || (state == NULL)), -EINVAL);
>> +
>> +__state = (struct rte_hash_iterator_istate *)state;
>> +__state->h = h;
>> +__state->next = 0;
>> +__state->total_entries = h->num_buckets * RTE_HASH_BUCKET_ENTRIES;
>> +
>> +return 0;
>> +}
>> IMO, creating this API can be avoided if the initialization is handled in 
>> 'rte_hash_iterate' function. The cost of doing this is very trivial (one 
>> extra 'if' statement) in 'rte_hash_iterate' function. It will help keep the 
>> number of APIs to minimal.
> 
>  Applications would have to initialize struct rte_hash_iterator_state 
> *state before calling rte_hash_iterate() anyway. Why not initializing the 
> fields of a state only once?
> 
> My concern is about creating another API for every iterator API. You have a 
> valid point on saving cycles as this API applies for data plane. Have you 
> done any performance benchmarking with and without this API? May be we can 
> guide our decision based on that.

It's not just about creating one init function for each iterator because an 
iterator may have a couple of init functions. For example, someone may 
eventually find useful to add another init function for the conflicting-entry 
iterator that we are advocating in this patch. A possibility would be for this 
new init function to use the key of the new entry instead of its signature to 
initialize the state. Similar to what is already done in rte_hash_lookup*() 
functions. In spite of possibly having multiple init functions, there will be a 
single iterator function.

About the performance benchmarking, the current API only requites 
applications to initialize a single 32-bit integer. But with the adoption of a 
struct for the state, the initialization will grow to 64 bytes.

As my tests showed, I do not see any impact of this.

>>int32_t
>> -rte_hash_iterate(const struct rte_hash *h, const void **key, void 
>> **data, uint32_t *next)
>> +rte_hash_iterate(
>> +struct rte_hash_iterator_state *state, const void **key, void
>> +**data)
>>
>> IMO, as suggested above, do not store 'struct rte_hash *h' in 'struct 
>> rte_hash_iterator_state'. Instead, change the API definition as follows:
>> rte_hash_iterate(const struct rte_hash *h, const void **key, void 
>> **data, struct rte_hash_iterator_state *state)
>>
>> This will help keep the API signature consistent with existing APIs.
>>
>> This is an ABI change. Please take a look at 
>> https://doc.dpdk.org/guides/contributing/versioning.html.
> 
>  The ABI will change in a way or another, so why not going for a single 
> state instead of requiring parameters that are already needed for the 
> initialization of the state?
> 
> Are there any cost savings we can ac

[dpdk-dev] rte_memcpy() moves data incorrectly on Ubuntu 18.04 on Intel Skylake.

[Yongseok Koh]

Hi, Christian

We've recently encountered a weird issue with Ubuntu 18.04 on the Skylake
server. I can always reproduce this crash and I could narrowed it down. I guess
it could be a GCC issue.


[1] How to reproduce
- ConnectX-4Lx/ConnectX-5 with mlx5 PMD in DPDK 18.02.1
- Ubuntu 18.04 on Intel Skylake server
- gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
- Testpmd crashes when it starts to forward traffic. Easy to reproduce.
- Only happens on the Skylake server.
- DPDK 18.05 and later don't have such issue. git-bisect gives no clue.


[2] Failure point

The attached patch gives an insight of why it crashes. The following is the
result of the patch and the GDB commands.

In summary, rte_memcpy() doesn't work as expected. In __mempool_generic_put(),
there's rte_memcpy() to move the array of objects to the lcore cache. If I run
memcmp() right after rte_memcpy(dst, src, n), data in dst differs from data in
src. And it looks like some of data got shifted by a few bytes as you can see
below.

[GDB command]
$dst = 0x74e09ea8
$src = 0x7fffce3fb970
$n = 256
x/32gx 0x74e09ea8
x/32gx 0x7fffce3fb970
testpmd: /home/mlnxtest/dpdk/build/include/rte_mempool.h:1140: 
__mempool_generic_put: Assertion `0' failed.

Thread 4 "lcore-slave-1" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffce3ff700 (LWP 69913)]
(gdb) x/32gx 0x74e09ea8
0x74e09ea8: 0x7fffaac38ec0  0x7fffaac38500
0x74e09eb8: 0x7fffaac37b40  0x7fffaac37180
0x74e09ec8: 0x85007fffaac3  0x7b407fffaac3
0x74e09ed8: 0x7fffaac35440  0x7fffaac34a80
0x74e09ee8: 0xaac385007fff  0xaac37b407fff
0x74e09ef8: 0x7fffaac32d40  0x7fffaac32380
0x74e09f08: 0x7fffaac38500  0x7fffaac37b40
0x74e09f18: 0x7fffaac30640  0x7fffaac2fc80
0x74e09f28: 0x7fffaac2f2c0  0x7fffaac2e900
0x74e09f38: 0x7fffaac2df40  0x7fffaac2d580
0x74e09f48: 0x7fffaac2cbc0  0x7fffaac2c200
0x74e09f58: 0x7fffaac2b840  0x7fffaac2ae80
0x74e09f68: 0x7fffaac2a4c0  0x7fffaac29b00
0x74e09f78: 0x7fffaac29140  0x7fffaac28780
0x74e09f88: 0x7fffaac27dc0  0x7fffaac27400
0x74e09f98: 0x7fffaac26a40  0x7fffaac26080
(gdb) x/32gx 0x7fffce3fb970
0x7fffce3fb970: 0x7fffaac38ec0  0x7fffaac38500
0x7fffce3fb980: 0x7fffaac37b40  0x7fffaac37180
0x7fffce3fb990: 0x7fffaac367c0  0x7fffaac35e00
0x7fffce3fb9a0: 0x7fffaac35440  0x7fffaac34a80
0x7fffce3fb9b0: 0x7fffaac340c0  0x7fffaac33700
0x7fffce3fb9c0: 0x7fffaac32d40  0x7fffaac32380
0x7fffce3fb9d0: 0x7fffaac319c0  0x7fffaac31000
0x7fffce3fb9e0: 0x7fffaac30640  0x7fffaac2fc80
0x7fffce3fb9f0: 0x7fffaac2f2c0  0x7fffaac2e900
0x7fffce3fba00: 0x7fffaac2df40  0x7fffaac2d580
0x7fffce3fba10: 0x7fffaac2cbc0  0x7fffaac2c200
0x7fffce3fba20: 0x7fffaac2b840  0x7fffaac2ae80
0x7fffce3fba30: 0x7fffaac2a4c0  0x7fffaac29b00
0x7fffce3fba40: 0x7fffaac29140  0x7fffaac28780
0x7fffce3fba50: 0x7fffaac27dc0  0x7fffaac27400
0x7fffce3fba60: 0x7fffaac26a40  0x7fffaac26080


AFAIK, AVX512F support is disabled by default in DPDK as it is still
experimental (CONFIG_RTE_ENABLE_AVX512=n). But with gcc optimization, AVX2
version of rte_memcpy() seems to be optimized with 512b instructions. If I
disable it by adding EXTRA_CFLAGS="-mno-avx512f", then it works fine and doesn't
crash.

Do you have any idea regarding this issue or are you already aware of it?


Thanks,
Yongseok


$ git diff
diff --git a/config/common_base b/config/common_base
index ad03cf433..f512b5a88 100644
--- a/config/common_base
+++ b/config/common_base
@@ -275,8 +275,8 @@ CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
 #
 # Compile burst-oriented Mellanox ConnectX-4 & ConnectX-5 (MLX5) PMD
 #
-CONFIG_RTE_LIBRTE_MLX5_PMD=n
-CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
+CONFIG_RTE_LIBRTE_MLX5_PMD=y
+CONFIG_RTE_LIBRTE_MLX5_DEBUG=y
 CONFIG_RTE_LIBRTE_MLX5_DLOPEN_DEPS=n
 CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8

@@ -597,7 +597,7 @@ CONFIG_RTE_RING_USE_C11_MEM_MODEL=n
 #
 CONFIG_RTE_LIBRTE_MEMPOOL=y
 CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE=512
-CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=n
+CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=y

 #
 # Compile Mempool drivers
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 8b1b7f7ed..9f48028d9 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #incl

Re: [dpdk-dev] [RFC] eal: allow hotplug to skip an already probed device

[Ophir Munk]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Saturday, September 08, 2018 12:10 AM
> To: dev@dpdk.org
> Cc: gaetan.ri...@6wind.com
> Subject: [dpdk-dev] [RFC] eal: allow hotplug to skip an already probed 
> device
> 
> In the devargs syntax for device representors, it is possible to add 
> several devices at once: -w dbdf,representor=[0-3] It will become a 
> more frequent case when introducing wildcards and ranges in the new devargs 
> syntax.
> 
> If a devargs string is provided for probing, and updated with a bigger 
> range for a new probing, then we do not want it to fail because part 
> of this range was already probed previously.
> 

When having devargs with representors ("dbdf,representor=") there is 
actually just one PCI device to probe (whose address is "dbdf", the master) 
while the representors themselves are net devices all using the same PCI "dbdf" 
address. 
The way to see it: when running "lspci": only the "dpdf" PCI device appears 
while when executing "ifconfig" - all representors are shown as net devices.
When calling rte_eal_hotplug_add() for the first time there is a flow which 
eventually calls the PMD probe callback (e.g. mlx5_pci_probe() in case of mlx5 
PMD). 
When calling rte_eal_hotplug_add() for several times we should skip failures 
till we reach the PMD probe callback.

Skipping failures can done as follows:
1. In file ./lib/librte_eal/common/eal_common_dev.c, function: 
rte_eal_hotplug_add(), remove the following code:

if (dev->driver != NULL) {
RTE_LOG(ERR, EAL, "Device is already plugged\n");
return -EEXIST}

2. In file ./drivers/bus/pci/pci_common.cm function: pci_probe_all_drivers(), 
remove the following code:

/* Check if a driver is already loaded */
if (dev->driver != NULL)
return -1;


However the substantial major changes are in each individual PMD probe callback 
when it is called several times with different devargs. For example it should 
not fail an already probed PCI device and just create new eth devices for new 
representors.

> On the opposite, we could require rte_eal_hotplug_add() to try to add
> all matching devices, and fail if one is already probed.
> 
> That's why a new parameter is added to specify if the function must 
> fail or not when trying to add an already probed device.
> 

Please note this new parameter ("fail_existing") will have to be propagated to 
all PMD probe callbacks.
Otherwise, in case (fail_existing == false) the second call to 
rte_eal_hotplug_add() will call the PMD probe callback, which may fail unless 
it is aware of "fail_existing" parameter.
Alternatively "fail_existing" may be better named "enable_multi_probe".
Anyway - if the PMD probe() callback has to be updated to return a 
success/failure value (for more than one probe) - maybe we do not need a new 
parameter and can rely on the PMD probe() callback the take the decision by 
returning success/failure value.

The counter part of rte_eal_hotplug_add() is rte_eal_hotplug_remove() which 
must be updated as well. For example when representors 1 and 2 exist - then 
removing just representor 1 will have to make sure that the PCI device used for 
both representors is not unplugged since representor 2 is not removed and it 
uses the same PCI device as representor 1. 

> Signed-off-by: Thomas Monjalon 
> ---
> This patch contains only the change in the function itself as RFC.
> 
> This idea was presented at Dublin during the "hotplug talk".
> ---
>  lib/librte_eal/common/eal_common_dev.c  | 4 +++- 
> lib/librte_eal/common/include/rte_dev.h | 5 -
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eal/common/eal_common_dev.c
> b/lib/librte_eal/common/eal_common_dev.c
> index 678dbcac7..17d7e9089 100644
> --- a/lib/librte_eal/common/eal_common_dev.c
> +++ b/lib/librte_eal/common/eal_common_dev.c
> @@ -128,7 +128,7 @@ int rte_eal_dev_detach(struct rte_device *dev)  }
> 
>  int __rte_experimental rte_eal_hotplug_add(const char *busname, const 
> char *devname,
> - const char *devargs)
> + const char *devargs, bool fail_existing)
>  {
>   struct rte_bus *bus;
>   struct rte_device *dev;
> @@ -173,6 +173,8 @@ int __rte_experimental rte_eal_hotplug_add(const 
> char *busname, const char *devn
>   }
> 
>   if (dev->driver != NULL) {
> + if (!fail_existing)
> + return 0;
>   RTE_LOG(ERR, EAL, "Device is already plugged\n");
>   return -EEXIST;
>   }
> diff --git a/lib/librte_eal/common/include/rte_dev.h
> b/lib/librte_eal/common/include/rte_dev.h
> index b80a80598..10a1cd2b4 100644
> --- a/lib/librte_eal/common/include/rte_dev.h
> +++ b/lib/librte_eal/common/include/rte_dev.h
> @@ -201,11 +201,14 @@ int rte_eal_dev_detach(struct rte_device *dev);
>   *   capable of handling it and pass it to the driver probing function.
>   * @param devargs
>   *   Devic

Re: [dpdk-dev] rte_memcpy() moves data incorrectly on Ubuntu 18.04 on Intel Skylake.

[Yongseok Koh]

> On Sep 12, 2018, at 1:56 PM, Yongseok Koh  wrote:
> 
> Hi, Christian
> 
> We've recently encountered a weird issue with Ubuntu 18.04 on the Skylake
> server. I can always reproduce this crash and I could narrowed it down. I 
> guess
> it could be a GCC issue.
> 
> 
> [1] How to reproduce
> - ConnectX-4Lx/ConnectX-5 with mlx5 PMD in DPDK 18.02.1
> - Ubuntu 18.04 on Intel Skylake server
> - gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
> - Testpmd crashes when it starts to forward traffic. Easy to reproduce.
> - Only happens on the Skylake server.
> - DPDK 18.05 and later don't have such issue. git-bisect gives no clue.

This is because I enabled MEMPOOL_DEBUG and MLX5_DEBUG. As mempool/rte_memcpy is
inlined function, it should be affected. Now I can see the crash regardlessly -
18.02, 18.05 and 18.08.

Thanks,
Yongseok.

> 
> 
> [2] Failure point
> 
> The attached patch gives an insight of why it crashes. The following is the
> result of the patch and the GDB commands.
> 
> In summary, rte_memcpy() doesn't work as expected. In __mempool_generic_put(),
> there's rte_memcpy() to move the array of objects to the lcore cache. If I run
> memcmp() right after rte_memcpy(dst, src, n), data in dst differs from data in
> src. And it looks like some of data got shifted by a few bytes as you can see
> below.
> 
>   [GDB command]
>   $dst = 0x74e09ea8
>   $src = 0x7fffce3fb970
>   $n = 256
>   x/32gx 0x74e09ea8
>   x/32gx 0x7fffce3fb970
>   testpmd: /home/mlnxtest/dpdk/build/include/rte_mempool.h:1140: 
> __mempool_generic_put: Assertion `0' failed.
> 
>   Thread 4 "lcore-slave-1" received signal SIGABRT, Aborted.
>   [Switching to Thread 0x7fffce3ff700 (LWP 69913)]
>   (gdb) x/32gx 0x74e09ea8
>   0x74e09ea8: 0x7fffaac38ec0  0x7fffaac38500
>   0x74e09eb8: 0x7fffaac37b40  0x7fffaac37180
>   0x74e09ec8: 0x85007fffaac3  0x7b407fffaac3
>   0x74e09ed8: 0x7fffaac35440  0x7fffaac34a80
>   0x74e09ee8: 0xaac385007fff  0xaac37b407fff
>   0x74e09ef8: 0x7fffaac32d40  0x7fffaac32380
>   0x74e09f08: 0x7fffaac38500  0x7fffaac37b40
>   0x74e09f18: 0x7fffaac30640  0x7fffaac2fc80
>   0x74e09f28: 0x7fffaac2f2c0  0x7fffaac2e900
>   0x74e09f38: 0x7fffaac2df40  0x7fffaac2d580
>   0x74e09f48: 0x7fffaac2cbc0  0x7fffaac2c200
>   0x74e09f58: 0x7fffaac2b840  0x7fffaac2ae80
>   0x74e09f68: 0x7fffaac2a4c0  0x7fffaac29b00
>   0x74e09f78: 0x7fffaac29140  0x7fffaac28780
>   0x74e09f88: 0x7fffaac27dc0  0x7fffaac27400
>   0x74e09f98: 0x7fffaac26a40  0x7fffaac26080
>   (gdb) x/32gx 0x7fffce3fb970
>   0x7fffce3fb970: 0x7fffaac38ec0  0x7fffaac38500
>   0x7fffce3fb980: 0x7fffaac37b40  0x7fffaac37180
>   0x7fffce3fb990: 0x7fffaac367c0  0x7fffaac35e00
>   0x7fffce3fb9a0: 0x7fffaac35440  0x7fffaac34a80
>   0x7fffce3fb9b0: 0x7fffaac340c0  0x7fffaac33700
>   0x7fffce3fb9c0: 0x7fffaac32d40  0x7fffaac32380
>   0x7fffce3fb9d0: 0x7fffaac319c0  0x7fffaac31000
>   0x7fffce3fb9e0: 0x7fffaac30640  0x7fffaac2fc80
>   0x7fffce3fb9f0: 0x7fffaac2f2c0  0x7fffaac2e900
>   0x7fffce3fba00: 0x7fffaac2df40  0x7fffaac2d580
>   0x7fffce3fba10: 0x7fffaac2cbc0  0x7fffaac2c200
>   0x7fffce3fba20: 0x7fffaac2b840  0x7fffaac2ae80
>   0x7fffce3fba30: 0x7fffaac2a4c0  0x7fffaac29b00
>   0x7fffce3fba40: 0x7fffaac29140  0x7fffaac28780
>   0x7fffce3fba50: 0x7fffaac27dc0  0x7fffaac27400
>   0x7fffce3fba60: 0x7fffaac26a40  0x7fffaac26080
> 
> 
> AFAIK, AVX512F support is disabled by default in DPDK as it is still
> experimental (CONFIG_RTE_ENABLE_AVX512=n). But with gcc optimization, AVX2
> version of rte_memcpy() seems to be optimized with 512b instructions. If I
> disable it by adding EXTRA_CFLAGS="-mno-avx512f", then it works fine and 
> doesn't
> crash.
> 
> Do you have any idea regarding this issue or are you already aware of it?
> 
> 
> Thanks,
> Yongseok
> 
> 
> $ git diff
> diff --git a/config/common_base b/config/common_base
> index ad03cf433..f512b5a88 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -275,8 +275,8 @@ CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
> #
> # Compile burst-oriented Mellanox ConnectX-4 & ConnectX-5 (MLX5) PMD
> #
> -CONFIG_RTE_LIBRTE_MLX5_PMD=n
> -CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
> +CONFIG_RTE_LIBRTE_MLX5_PMD=y
> +CONFIG_RTE_LIBRTE_MLX5_DEBUG=y
> CONFIG_RTE_LIBRTE_MLX5_DLOPEN_DEPS=n
> CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
> 
> @@ -597,7 +597,7 @@ CONFIG_RTE_RING_USE_C11_MEM_MODEL=n
> #
> CONFIG_RTE_LIBRTE_MEMPOOL=y
> CONFIG_RTE_MEMPOOL_CACHE_

Re: [dpdk-dev] [PATCH v5] net/i40e: add interface to choose latest vector path

[Zhang, Qi Z]

> -Original Message-
> From: Li, Xiaoyun
> Sent: Wednesday, September 12, 2018 6:12 PM
> To: Xing, Beilei ; Zhang, Qi Z 
> Cc: dev@dpdk.org; Yang, Zhiyong ; Li, Xiaoyun
> 
> Subject: [PATCH v5] net/i40e: add interface to choose latest vector path
> 
> Right now, vector path is limited to only use on later platform.
> This patch adds a devarg use-latest-vec to allow the users to use the latest
> vector path that the platform supported. Namely, using AVX2 vector path on
> broadwell is possible.
> 
> Signed-off-by: Xiaoyun Li 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Regards
Qi

Re: [dpdk-dev] [PATCH 0/8] update ixgbe base code

[Zhang, Qi Z]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Xiaoyun Li
> Sent: Tuesday, September 11, 2018 12:38 AM
> To: Lu, Wenzhuo ; dev@dpdk.org
> Cc: Li, Xiaoyun 
> Subject: [dpdk-dev] [PATCH 0/8] update ixgbe base code
> 
> Update the ixgbe base code to version cid-ixgbe.2018.08.28.tar.gz.
> 
> Xiaoyun Li (8):
>   net/ixgbe/base: update the license
>   net/ixgbe/base: cleanup codes
>   net/ixgbe/base: add FW recovery mode check
>   net/ixgbe/base: relpace an operation in X550 setup
>   net/ixgbe/base: update X550 SFP identification
>   net/ixgbe/base: add support for DCB registers dump
>   net/ixgbe: remove Light Spring code
>   net/ixgbe/base: update README file
> 
>  drivers/net/ixgbe/base/README|  4 +-
>  drivers/net/ixgbe/base/ixgbe_82598.c | 35 ++
>  drivers/net/ixgbe/base/ixgbe_82598.h | 35 ++
>  drivers/net/ixgbe/base/ixgbe_82599.c | 45 ++
>  drivers/net/ixgbe/base/ixgbe_82599.h | 35 ++
>  drivers/net/ixgbe/base/ixgbe_api.c   | 50 ++--
>  drivers/net/ixgbe/base/ixgbe_api.h   | 36 ++-
>  drivers/net/ixgbe/base/ixgbe_common.c| 41 ++--
>  drivers/net/ixgbe/base/ixgbe_common.h| 35 ++
>  drivers/net/ixgbe/base/ixgbe_dcb.c   | 35 ++
>  drivers/net/ixgbe/base/ixgbe_dcb.h   | 35 ++
>  drivers/net/ixgbe/base/ixgbe_dcb_82598.c | 35 ++
> drivers/net/ixgbe/base/ixgbe_dcb_82598.h | 35 ++
> drivers/net/ixgbe/base/ixgbe_dcb_82599.c | 35 ++
> drivers/net/ixgbe/base/ixgbe_dcb_82599.h | 35 ++
>  drivers/net/ixgbe/base/ixgbe_hv_vf.c | 35 ++
>  drivers/net/ixgbe/base/ixgbe_hv_vf.h | 35 ++
>  drivers/net/ixgbe/base/ixgbe_mbx.c   | 35 ++
>  drivers/net/ixgbe/base/ixgbe_mbx.h   | 35 ++
>  drivers/net/ixgbe/base/ixgbe_osdep.h | 36 ++-
>  drivers/net/ixgbe/base/ixgbe_phy.c   | 36 ++-
>  drivers/net/ixgbe/base/ixgbe_phy.h   | 35 ++
>  drivers/net/ixgbe/base/ixgbe_type.h  | 53 ++---
>  drivers/net/ixgbe/base/ixgbe_vf.c| 35 ++
>  drivers/net/ixgbe/base/ixgbe_vf.h| 35 ++
>  drivers/net/ixgbe/base/ixgbe_x540.c  | 35 ++
>  drivers/net/ixgbe/base/ixgbe_x540.h  | 35 ++
>  drivers/net/ixgbe/base/ixgbe_x550.c  | 59 +---
>  drivers/net/ixgbe/base/ixgbe_x550.h  | 36 ++-
>  drivers/net/ixgbe/ixgbe_ethdev.c |  1 -
>  30 files changed, 131 insertions(+), 931 deletions(-)
> 
> --
> 2.17.1

Regression test shows no issue.

Acked-by: Qi Zhang 

Applied-to dpdk-next-net-intel.

Regards
Qi

Re: [dpdk-dev] [PATCH] net/ixgbe: firmware status check

[Zhang, Qi Z]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Xiaoyun Li
> Sent: Friday, September 7, 2018 11:01 PM
> To: Lu, Wenzhuo ; dev@dpdk.org; Zhang, Helin
> ; Wu, Jingjing 
> Cc: Li, Xiaoyun 
> Subject: [dpdk-dev] [PATCH] net/ixgbe: firmware status check
> 
> Check the firmware status at init time. If the firmware is in recovery mode,
> alert the user to check it.
> 
> Signed-off-by: Xiaoyun Li 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [dpdk-dev] [PATCH] net/ifc: do not notify before HW ready

[Ye Xiaolong]

Hi, Xiao

On 09/10, Xiao Wang wrote:
>Fixes: a3f8150eac6d ("net/ifcvf: add ifcvf vDPA driver")

Could you help describe what problem is without this fix in commit log?

Thanks,
Xiaolong
>
>Signed-off-by: Xiao Wang 
>---
> drivers/net/ifc/ifcvf_vdpa.c | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/net/ifc/ifcvf_vdpa.c b/drivers/net/ifc/ifcvf_vdpa.c
>index 3c5430dc0..7d3085d8d 100644
>--- a/drivers/net/ifc/ifcvf_vdpa.c
>+++ b/drivers/net/ifc/ifcvf_vdpa.c
>@@ -503,11 +503,11 @@ update_datapath(struct ifcvf_internal *internal)
>   if (ret)
>   goto err;
> 
>-  ret = setup_notify_relay(internal);
>+  ret = vdpa_ifcvf_start(internal);
>   if (ret)
>   goto err;
> 
>-  ret = vdpa_ifcvf_start(internal);
>+  ret = setup_notify_relay(internal);
>   if (ret)
>   goto err;
> 
>@@ -515,12 +515,12 @@ update_datapath(struct ifcvf_internal *internal)
>   } else if (rte_atomic32_read(&internal->running) &&
>  (!rte_atomic32_read(&internal->started) ||
>   !rte_atomic32_read(&internal->dev_attached))) {
>-  vdpa_ifcvf_stop(internal);
>-
>   ret = unset_notify_relay(internal);
>   if (ret)
>   goto err;
> 
>+  vdpa_ifcvf_stop(internal);
>+
>   ret = vdpa_disable_vfio_intr(internal);
>   if (ret)
>   goto err;
>-- 
>2.15.1
>

[dpdk-dev] [PATCH 00/10] Introducing the NXP CAAM job ring driver

[Gagandeep Singh]

The caam_jr PMD provides poll mode crypto driver
support for NXP SEC 4.x+ (CAAM) hardware accelerator.

This patch has dependancy on below patches:
http://patchwork.dpdk.org/patch/43986/
http://patchwork.dpdk.org/patch/43964/

Hemant Agrawal (10):
  doc: add caam jr cryptodev details
  crypto/caam_jr: introduce basic driver
  crypto/caam_jr: add HW config for job rings
  crypto/caam_jr: add device configuration routines
  crypto/caam_jr: add queue config functions
  crypto/caam_jr: add basic session config routines
  crypto/caam_jr: add enqueue and dequeue routines
  crypto/caam_jr: add auth cipher and aead session support
  crypto/caam_jr: add stats support
  crypto/caam_jr: add security offload support

 config/common_base|8 +
 config/common_linuxapp|1 +
 config/defconfig_arm64-dpaa-linuxapp-gcc  |4 +
 doc/guides/cryptodevs/caam_jr.rst |  159 ++
 doc/guides/cryptodevs/index.rst   |1 +
 drivers/crypto/Makefile   |1 +
 drivers/crypto/caam_jr/Makefile   |   46 +
 drivers/crypto/caam_jr/caam_jr.c  | 2485 +
 drivers/crypto/caam_jr/caam_jr.h  |  257 ++
 drivers/crypto/caam_jr/caam_jr_config.h   |  207 ++
 drivers/crypto/caam_jr/caam_jr_desc.h |  289 ++
 drivers/crypto/caam_jr/caam_jr_hw.c   |  365 +++
 drivers/crypto/caam_jr/caam_jr_hw_specific.h  |  503 
 drivers/crypto/caam_jr/caam_jr_log.h  |   42 +
 drivers/crypto/caam_jr/caam_jr_pvt.h  |  288 ++
 drivers/crypto/caam_jr/caam_jr_uio.c  |  491 
 drivers/crypto/caam_jr/meson.build|   14 +
 .../caam_jr/rte_pmd_caam_jr_version.map   |4 +
 drivers/crypto/meson.build|2 +-
 19 files changed, 5166 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/cryptodevs/caam_jr.rst
 create mode 100644 drivers/crypto/caam_jr/Makefile
 create mode 100644 drivers/crypto/caam_jr/caam_jr.c
 create mode 100644 drivers/crypto/caam_jr/caam_jr.h
 create mode 100644 drivers/crypto/caam_jr/caam_jr_config.h
 create mode 100644 drivers/crypto/caam_jr/caam_jr_desc.h
 create mode 100644 drivers/crypto/caam_jr/caam_jr_hw.c
 create mode 100644 drivers/crypto/caam_jr/caam_jr_hw_specific.h
 create mode 100644 drivers/crypto/caam_jr/caam_jr_log.h
 create mode 100644 drivers/crypto/caam_jr/caam_jr_pvt.h
 create mode 100644 drivers/crypto/caam_jr/caam_jr_uio.c
 create mode 100644 drivers/crypto/caam_jr/meson.build
 create mode 100644 drivers/crypto/caam_jr/rte_pmd_caam_jr_version.map

-- 
2.17.1

[dpdk-dev] [PATCH 01/10] doc: add caam jr cryptodev details

[Gagandeep Singh]

From: Hemant Agrawal 

Signed-off-by: Hemant Agrawal 
---
 doc/guides/cryptodevs/caam_jr.rst | 159 ++
 doc/guides/cryptodevs/index.rst   |   1 +
 2 files changed, 160 insertions(+)
 create mode 100644 doc/guides/cryptodevs/caam_jr.rst

diff --git a/doc/guides/cryptodevs/caam_jr.rst 
b/doc/guides/cryptodevs/caam_jr.rst
new file mode 100644
index 0..0ee501506
--- /dev/null
+++ b/doc/guides/cryptodevs/caam_jr.rst
@@ -0,0 +1,159 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright 2017 NXP
+
+
+NXP CAAM JOB RING (caam_jr)
+===
+
+The caam_jr PMD provides poll mode crypto driver support for NXP SEC 4.x+ 
(CAAM)
+hardware accelerator. More information is available at:
+
+`NXP Cryptographic Acceleration Technology  
`_.
+
+Architecture
+
+
+SEC is the SOC's security engine, which serves as NXP's latest cryptographic
+acceleration and offloading hardware. It combines functions previously
+implemented in separate modules to create a modular and scalable acceleration
+and assurance engine. It also implements block encryption algorithms, stream
+cipher algorithms, hashing algorithms, public key algorithms, run-time
+integrity checking, and a hardware random number generator. SEC performs
+higher-level cryptographic operations than previous NXP cryptographic
+accelerators. This provides significant improvement to system level 
performance.
+
+SEC HW accelerator above 4.x+ version are also known as CAAM.
+
+caam_jr PMD is one of DPAA drivers which uses uio interface to interact with
+Linux kernel for configure and destroy the device instance (ring).
+
+
+Implementation
+--
+
+SEC provides platform assurance by working with SecMon, which is a companion
+logic block that tracks the security state of the SOC. SEC is programmed by
+means of descriptors (not to be confused with frame descriptors (FDs)) that
+indicate the operations to be performed and link to the message and
+associated data. SEC incorporates two DMA engines to fetch the descriptors,
+read the message data, and write the results of the operations. The DMA
+engine provides a scatter/gather capability so that SEC can read and write
+data scattered in memory. SEC may be configured by means of software for
+dynamic changes in byte ordering. The default configuration for this version
+of SEC is little-endian mode.
+
+Note that one physical Job Ring represent one caam_jr device.
+
+Features
+
+
+The CAAM_JR PMD has support for:
+
+Cipher algorithms:
+
+* ``RTE_CRYPTO_CIPHER_3DES_CBC``
+* ``RTE_CRYPTO_CIPHER_AES128_CBC``
+* ``RTE_CRYPTO_CIPHER_AES192_CBC``
+* ``RTE_CRYPTO_CIPHER_AES256_CBC``
+* ``RTE_CRYPTO_CIPHER_AES128_CTR``
+* ``RTE_CRYPTO_CIPHER_AES192_CTR``
+* ``RTE_CRYPTO_CIPHER_AES256_CTR``
+
+Hash algorithms:
+
+* ``RTE_CRYPTO_AUTH_SHA1_HMAC``
+* ``RTE_CRYPTO_AUTH_SHA224_HMAC``
+* ``RTE_CRYPTO_AUTH_SHA256_HMAC``
+* ``RTE_CRYPTO_AUTH_SHA384_HMAC``
+* ``RTE_CRYPTO_AUTH_SHA512_HMAC``
+* ``RTE_CRYPTO_AUTH_MD5_HMAC``
+
+AEAD algorithms:
+
+* ``RTE_CRYPTO_AEAD_AES_GCM``
+
+Supported DPAA SoCs
+
+
+* LS1046A/LS1026A
+* LS1043A/LS1023A
+* LS1028A
+* LS1012A
+
+Limitations
+---
+
+* Hash followed by Cipher mode is not supported
+* Only supports the session-oriented API implementation (session-less APIs are 
not supported).
+
+Prerequisites
+-
+
+caam_jr driver has following dependencies are not part of DPDK and must be 
installed separately:
+
+* **NXP Linux SDK**
+
+  NXP Linux software development kit (SDK) includes support for the family
+  of QorIQ® ARM-Architecture-based system on chip (SoC) processors
+  and corresponding boards.
+
+  It includes the Linux board support packages (BSPs) for NXP SoCs,
+  a fully operational tool chain, kernel and board specific modules.
+
+  SDK and related information can be obtained from:  `NXP QorIQ SDK  
`_.
+
+Currently supported by DPDK:
+
+* NXP SDK **18.09+**.
+* Supported architectures:  **arm64 LE**.
+
+* Follow the DPDK :ref:`Getting Started Guide for Linux ` to setup 
the basic DPDK environment.
+
+Pre-Installation Configuration
+--
+
+Config File Options
+~~~
+
+The following options can be modified in the ``config`` file
+to enable caam_jr PMD.
+
+Please note that enabling debugging options may affect system performance.
+
+* ``CONFIG_RTE_LIBRTE_PMD_CAAM_JR`` (default ``n``)
+  By default it is only enabled in common_armv8a_linuxapp config.
+  Toggle compilation of the ``librte_pmd_caam_jr`` driver.
+
+* ``CONFIG_RTE_LIBRTE_PMD_CAAM_JR_BE`` (default ``n``)
+  By default it is disabled.
+  It can be used when the underlying hardware supports the CAAM in BE

[dpdk-dev] [PATCH 02/10] crypto/caam_jr: introduce basic driver

[Gagandeep Singh]

From: Hemant Agrawal 

This patch introduces basic support for caam_jr crypto driver.

Signed-off-by: Gagandeep Singh 
Signed-off-by: Hemant Agrawal 
---
 config/common_base|   8 +
 config/common_linuxapp|   1 +
 config/defconfig_arm64-dpaa-linuxapp-gcc  |   4 +
 drivers/crypto/Makefile   |   1 +
 drivers/crypto/caam_jr/Makefile   |  40 +
 drivers/crypto/caam_jr/caam_jr.c  | 157 ++
 drivers/crypto/caam_jr/caam_jr_log.h  |  42 +
 drivers/crypto/caam_jr/meson.build|  11 ++
 .../caam_jr/rte_pmd_caam_jr_version.map   |   4 +
 drivers/crypto/meson.build|   2 +-
 10 files changed, 269 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/caam_jr/Makefile
 create mode 100644 drivers/crypto/caam_jr/caam_jr.c
 create mode 100644 drivers/crypto/caam_jr/caam_jr_log.h
 create mode 100644 drivers/crypto/caam_jr/meson.build
 create mode 100644 drivers/crypto/caam_jr/rte_pmd_caam_jr_version.map

diff --git a/config/common_base b/config/common_base
index 4bcbaf923..a73f063d1 100644
--- a/config/common_base
+++ b/config/common_base
@@ -479,6 +479,14 @@ CONFIG_RTE_CRYPTO_MAX_DEVS=64
 CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO=n
 CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO_DEBUG=n
 
+#
+# Compile NXP CAAM JR crypto Driver
+#
+CONFIG_RTE_LIBRTE_PMD_CAAM_JR=n
+CONFIG_RTE_LIBRTE_PMD_CAAM_JR_BE=n
+CONFIG_RTE_LIBRTE_PMD_CAAM_JR_DEBUG=n
+CONFIG_RTE_CAAM_JR_PMD_MAX_NB_SESSIONS=2048
+
 #
 # Compile NXP DPAA2 crypto sec driver for CAAM HW
 #
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 9c5ea9d89..c1c7c4287 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -35,6 +35,7 @@ CONFIG_RTE_LIBRTE_DPAA_MEMPOOL=y
 CONFIG_RTE_LIBRTE_DPAA_PMD=y
 CONFIG_RTE_LIBRTE_PMD_DPAA_EVENTDEV=y
 CONFIG_RTE_LIBRTE_PMD_DPAA_SEC=y
+CONFIG_RTE_LIBRTE_PMD_CAAM_JR=y
 
 # NXP FSLMC BUS and DPAA2 drivers
 CONFIG_RTE_LIBRTE_FSLMC_BUS=y
diff --git a/config/defconfig_arm64-dpaa-linuxapp-gcc 
b/config/defconfig_arm64-dpaa-linuxapp-gcc
index c47aec0a6..e5343f7a9 100644
--- a/config/defconfig_arm64-dpaa-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa-linuxapp-gcc
@@ -21,3 +21,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=128
 # NXP DPAA Bus
 CONFIG_RTE_LIBRTE_DPAA_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_DPAA_HWDEBUG=n
+
+# NXP CAAM_JR driver
+CONFIG_RTE_LIBRTE_PMD_CAAM_JR=y
+CONFIG_RTE_LIBRTE_PMD_CAAM_JR_BE=y
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c480cbd37..e3711d703 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -6,6 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_GCM) += aesni_gcm
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += aesni_mb
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO) += armv8
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_CAAM_JR) += caam_jr
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_CCP) += ccp
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_OPENSSL) += openssl
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_CRYPTO_SCHEDULER) += scheduler
diff --git a/drivers/crypto/caam_jr/Makefile b/drivers/crypto/caam_jr/Makefile
new file mode 100644
index 0..46d752af7
--- /dev/null
+++ b/drivers/crypto/caam_jr/Makefile
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2017 NXP
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_caam_jr.a
+
+# build flags
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+CFLAGS += -D _GNU_SOURCE
+ifeq ($(CONFIG_RTE_LIBRTE_CAAM_JR_DEBUG),y)
+CFLAGS += -O0 -g
+CFLAGS += "-Wno-error"
+else
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+endif
+
+CFLAGS += -I$(RTE_SDK)/drivers/crypto/caam_jr
+CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common/include
+CFLAGS += -I$(RTE_SDK)/lib/librte_eal/linuxapp/eal
+
+# versioning export map
+EXPORT_MAP := rte_pmd_caam_jr_version.map
+
+# library version
+LIBABIVER := 1
+
+# library source files
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_CAAM_JR) += caam_jr.c
+# library dependencies
+
+LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
+LDLIBS += -lrte_cryptodev
+LDLIBS += -lrte_bus_vdev
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
new file mode 100644
index 0..68779cba5
--- /dev/null
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -0,0 +1,157 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2017-2018 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define CRYPTODEV_NAME_CAAM_JR_PMD crypto_caam_jr
+static uint8_t cryptodev_driver_id;
+int caam_jr_logtype;
+
+
+/*
+ * @brief Release the resources used by the SEC user space driver.
+ *
+ * Reset and release SEC's job rings indicated by the User Application at
+ * init_job_ring() and free any memory allocated internally.
+ * Call once during application tear down.
+ *
+ * @note In case there are any descriptors in-flight (descriptors r

[dpdk-dev] [PATCH 03/10] crypto/caam_jr: add HW config for job rings

[Gagandeep Singh]

From: Hemant Agrawal 

Signed-off-by: Gagandeep Singh 
Signed-off-by: Hemant Agrawal 
---
 drivers/crypto/caam_jr/Makefile  |   6 +
 drivers/crypto/caam_jr/caam_jr.c | 329 +++-
 drivers/crypto/caam_jr/caam_jr_config.h  | 207 
 drivers/crypto/caam_jr/caam_jr_hw.c  | 365 ++
 drivers/crypto/caam_jr/caam_jr_hw_specific.h | 503 +++
 drivers/crypto/caam_jr/caam_jr_pvt.h | 285 +++
 drivers/crypto/caam_jr/caam_jr_uio.c | 491 ++
 drivers/crypto/caam_jr/meson.build   |   5 +-
 8 files changed, 2188 insertions(+), 3 deletions(-)
 create mode 100644 drivers/crypto/caam_jr/caam_jr_config.h
 create mode 100644 drivers/crypto/caam_jr/caam_jr_hw.c
 create mode 100644 drivers/crypto/caam_jr/caam_jr_hw_specific.h
 create mode 100644 drivers/crypto/caam_jr/caam_jr_pvt.h
 create mode 100644 drivers/crypto/caam_jr/caam_jr_uio.c

diff --git a/drivers/crypto/caam_jr/Makefile b/drivers/crypto/caam_jr/Makefile
index 46d752af7..8b863b4af 100644
--- a/drivers/crypto/caam_jr/Makefile
+++ b/drivers/crypto/caam_jr/Makefile
@@ -19,7 +19,10 @@ CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS)
 endif
 
+CFLAGS += -I$(RTE_SDK)/drivers/bus/dpaa/include
 CFLAGS += -I$(RTE_SDK)/drivers/crypto/caam_jr
+#sharing the hw flib headers from dpaa2_sec pmd
+CFLAGS += -I$(RTE_SDK)/drivers/crypto/dpaa2_sec/
 CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common/include
 CFLAGS += -I$(RTE_SDK)/lib/librte_eal/linuxapp/eal
 
@@ -30,11 +33,14 @@ EXPORT_MAP := rte_pmd_caam_jr_version.map
 LIBABIVER := 1
 
 # library source files
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_CAAM_JR) += caam_jr_hw.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_CAAM_JR) += caam_jr_uio.c
 SRCS-$(CONFIG_RTE_LIBRTE_PMD_CAAM_JR) += caam_jr.c
 # library dependencies
 
 LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
 LDLIBS += -lrte_cryptodev
+LDLIBS += -lrte_bus_dpaa
 LDLIBS += -lrte_bus_vdev
 
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index 68779cba5..9d5f5b79b 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -16,13 +16,146 @@
 #include 
 #include 
 #include 
+#include 
 
+/* RTA header files */
+#include 
+#include 
+#include 
+#include 
 #include 
 
 #define CRYPTODEV_NAME_CAAM_JR_PMD crypto_caam_jr
 static uint8_t cryptodev_driver_id;
 int caam_jr_logtype;
 
+enum rta_sec_era rta_sec_era;
+
+/* Lists the states possible for the SEC user space driver. */
+enum sec_driver_state_e {
+   SEC_DRIVER_STATE_IDLE,  /* Driver not initialized */
+   SEC_DRIVER_STATE_STARTED,   /* Driver initialized and can be used*/
+   SEC_DRIVER_STATE_RELEASE,   /* Driver release is in progress */
+};
+
+/* Job rings used for communication with SEC HW */
+static struct sec_job_ring_t g_job_rings[MAX_SEC_JOB_RINGS];
+
+/* The current state of SEC user space driver */
+static enum sec_driver_state_e g_driver_state = SEC_DRIVER_STATE_IDLE;
+
+/* The number of job rings used by SEC user space driver */
+static int g_job_rings_no;
+static int g_job_rings_max;
+
+/* @brief Poll the HW for already processed jobs in the JR
+ * and silently discard the available jobs or notify them to UA
+ * with indicated error code.
+ *
+ * @param [in,out]  job_ringThe job ring to poll.
+ * @param [in]  do_notify   Can be #TRUE or #FALSE. Indicates if
+ * descriptors are to be discarded
+ *  or notified to UA with given error_code.
+ * @param [out] notified_descsNumber of notified descriptors. Can be NULL
+ * if do_notify is #FALSE
+ */
+static void hw_flush_job_ring(struct sec_job_ring_t *job_ring,
+ uint32_t do_notify,
+ uint32_t *notified_descs)
+{
+   int32_t jobs_no_to_discard = 0;
+   int32_t discarded_descs_no = 0;
+
+   CAAM_JR_DEBUG("Jr[%p] pi[%d] ci[%d].Flushing jr notify desc=[%d]",
+   job_ring, job_ring->pidx, job_ring->cidx, do_notify);
+
+   jobs_no_to_discard = hw_get_no_finished_jobs(job_ring);
+
+   /* Discard all jobs */
+   CAAM_JR_DEBUG("Jr[%p] pi[%d] ci[%d].Discarding %d descs",
+ job_ring, job_ring->pidx, job_ring->cidx,
+ jobs_no_to_discard);
+
+   while (jobs_no_to_discard > discarded_descs_no) {
+   /* Get completed descriptor */
+#if 0
+   /*TODO if we want to do something with desc*/
+   /* Since the memory is contigous, then P2V translation is a
+* mere addition to the base descriptor physical address
+*/
+   current_desc = job_ring->output_ring[job_ring->cidx].desc;
+#endif
+
+   discarded_descs_no++;
+   /* Now increment the consumer index for the current job ring,
+* AFTER saving job in temporary location

[dpdk-dev] [PATCH 04/10] crypto/caam_jr: add device configuration routines

[Gagandeep Singh]

From: Hemant Agrawal 

Signed-off-by: Gagandeep Singh 
Signed-off-by: Hemant Agrawal 
---
 drivers/crypto/caam_jr/caam_jr.c | 100 +++-
 drivers/crypto/caam_jr/caam_jr.h | 257 +++
 2 files changed, 356 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/caam_jr/caam_jr.h

diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index 9d5f5b79b..43fe5233b 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -104,6 +105,90 @@ static void hw_flush_job_ring(struct sec_job_ring_t 
*job_ring,
 }
 
 
+static int
+caam_jr_dev_configure(struct rte_cryptodev *dev,
+  struct rte_cryptodev_config *config __rte_unused)
+{
+   char str[20];
+   struct sec_job_ring_t *internals;
+
+   PMD_INIT_FUNC_TRACE();
+
+   internals = dev->data->dev_private;
+   sprintf(str, "ctx_pool_%d", dev->data->dev_id);
+   if (!internals->ctx_pool) {
+   internals->ctx_pool = rte_mempool_create((const char *)str,
+   CTX_POOL_NUM_BUFS,
+   sizeof(struct caam_jr_op_ctx),
+   CTX_POOL_CACHE_SIZE, 0,
+   NULL, NULL, NULL, NULL,
+   SOCKET_ID_ANY, 0);
+   if (!internals->ctx_pool) {
+   CAAM_JR_ERR("%s create failed\n", str);
+   return -ENOMEM;
+   }
+   } else
+   CAAM_JR_INFO("mempool already created for dev_id : %d",
+   dev->data->dev_id);
+
+   return 0;
+}
+
+static int
+caam_jr_dev_start(struct rte_cryptodev *dev __rte_unused)
+{
+   PMD_INIT_FUNC_TRACE();
+   return 0;
+}
+
+static void
+caam_jr_dev_stop(struct rte_cryptodev *dev __rte_unused)
+{
+   PMD_INIT_FUNC_TRACE();
+}
+
+static int
+caam_jr_dev_close(struct rte_cryptodev *dev)
+{
+   struct sec_job_ring_t *internals;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (dev == NULL)
+   return -ENOMEM;
+
+   internals = dev->data->dev_private;
+   rte_mempool_free(internals->ctx_pool);
+   internals->ctx_pool = NULL;
+
+   return 0;
+}
+
+static void
+caam_jr_dev_infos_get(struct rte_cryptodev *dev,
+  struct rte_cryptodev_info *info)
+{
+   struct sec_job_ring_t *internals = dev->data->dev_private;
+
+   PMD_INIT_FUNC_TRACE();
+   if (info != NULL) {
+   info->max_nb_queue_pairs = internals->max_nb_queue_pairs;
+   info->feature_flags = dev->feature_flags;
+   info->capabilities = caam_jr_capabilities;
+   info->sym.max_nb_sessions = internals->max_nb_sessions;
+   info->driver_id = cryptodev_driver_id;
+   }
+}
+
+static struct rte_cryptodev_ops caam_jr_ops = {
+   .dev_configure= caam_jr_dev_configure,
+   .dev_start= caam_jr_dev_start,
+   .dev_stop = caam_jr_dev_stop,
+   .dev_close= caam_jr_dev_close,
+   .dev_infos_get= caam_jr_dev_infos_get,
+};
+
+
 /* @brief Flush job rings of any processed descs.
  * The processed descs are silently dropped,
  * WITHOUT being notified to UA.
@@ -366,7 +451,20 @@ caam_jr_dev_init(const char *name,
}
 
dev->driver_id = cryptodev_driver_id;
-   dev->dev_ops = NULL;
+   dev->dev_ops = &caam_jr_ops;
+
+   /* register rx/tx burst functions for data path */
+   dev->dequeue_burst = NULL;
+   dev->enqueue_burst = NULL;
+   dev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
+   RTE_CRYPTODEV_FF_HW_ACCELERATED |
+   RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
+   RTE_CRYPTODEV_FF_SECURITY |
+   RTE_CRYPTODEV_FF_IN_PLACE_SGL |
+   RTE_CRYPTODEV_FF_OOP_SGL_IN_SGL_OUT |
+   RTE_CRYPTODEV_FF_OOP_SGL_IN_LB_OUT |
+   RTE_CRYPTODEV_FF_OOP_LB_IN_SGL_OUT |
+   RTE_CRYPTODEV_FF_OOP_LB_IN_LB_OUT;
 
/* For secondary processes, we don't initialise any further as primary
 * has already done this work. Only check we don't need a different
diff --git a/drivers/crypto/caam_jr/caam_jr.h b/drivers/crypto/caam_jr/caam_jr.h
new file mode 100644
index 0..d7c36ca9d
--- /dev/null
+++ b/drivers/crypto/caam_jr/caam_jr.h
@@ -0,0 +1,257 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2017-2018 NXP
+ */
+
+#ifndef CAAM_JR_H
+#define CAAM_JR_H
+
+static const struct rte_cryptodev_capabilities caam_jr_capabilities[] = {
+   {   /* MD5 HMAC */
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   {.sym = {
+   .xform_type = RTE_C

[dpdk-dev] [PATCH 06/10] crypto/caam_jr: add basic session config routines

[Gagandeep Singh]

From: Hemant Agrawal 

The current support is limited to crypto only.

Signed-off-by: Gagandeep Singh 
Signed-off-by: Hemant Agrawal 
---
 drivers/crypto/caam_jr/caam_jr.c | 124 +++
 1 file changed, 124 insertions(+)

diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index f05e966b0..a0eee3b85 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -20,6 +20,7 @@
 
 /* RTA header files */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -166,6 +167,126 @@ caam_jr_queue_pair_count(struct rte_cryptodev *dev)
return dev->data->nb_queue_pairs;
 }
 
+/* Returns the size of the aesni gcm session structure */
+static unsigned int
+caam_jr_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
+{
+   PMD_INIT_FUNC_TRACE();
+
+   return sizeof(struct caam_jr_session);
+}
+
+static int
+caam_jr_cipher_init(struct rte_cryptodev *dev __rte_unused,
+struct rte_crypto_sym_xform *xform,
+struct caam_jr_session *session)
+{
+   session->cipher_alg = xform->cipher.algo;
+   session->iv.length = xform->cipher.iv.length;
+   session->iv.offset = xform->cipher.iv.offset;
+   session->cipher_key.data = rte_zmalloc(NULL, xform->cipher.key.length,
+  RTE_CACHE_LINE_SIZE);
+   if (session->cipher_key.data == NULL && xform->cipher.key.length > 0) {
+   CAAM_JR_ERR("No Memory for cipher key\n");
+   return -ENOMEM;
+   }
+   session->cipher_key.length = xform->cipher.key.length;
+
+   memcpy(session->cipher_key.data, xform->cipher.key.data,
+  xform->cipher.key.length);
+   session->dir = (xform->cipher.op == RTE_CRYPTO_CIPHER_OP_ENCRYPT) ?
+   DIR_ENC : DIR_DEC;
+
+   return 0;
+}
+
+
+static int
+caam_jr_set_session_parameters(struct rte_cryptodev *dev,
+   struct rte_crypto_sym_xform *xform, void *sess)
+{
+   struct sec_job_ring_t *internals = dev->data->dev_private;
+   struct caam_jr_session *session = sess;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (unlikely(sess == NULL)) {
+   CAAM_JR_ERR("invalid session struct");
+   return -EINVAL;
+   }
+
+   /* Default IV length = 0 */
+   session->iv.length = 0;
+
+   /* Cipher Only */
+   if (xform->type == RTE_CRYPTO_SYM_XFORM_CIPHER && xform->next == NULL) {
+   session->auth_alg = RTE_CRYPTO_AUTH_NULL;
+   caam_jr_cipher_init(dev, xform, session);
+
+   } else {
+   CAAM_JR_ERR("Invalid crypto type");
+   return -EINVAL;
+   }
+   session->ctx_pool = internals->ctx_pool;
+
+   return 0;
+}
+
+static int
+caam_jr_sym_session_configure(struct rte_cryptodev *dev,
+   struct rte_crypto_sym_xform *xform,
+   struct rte_cryptodev_sym_session *sess,
+   struct rte_mempool *mempool)
+{
+   void *sess_private_data;
+   int ret;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (rte_mempool_get(mempool, &sess_private_data)) {
+   CAAM_JR_ERR("Couldn't get object from session mempool");
+   return -ENOMEM;
+   }
+
+   memset(sess_private_data, 0, sizeof(struct caam_jr_session));
+
+   ret = caam_jr_set_session_parameters(dev, xform, sess_private_data);
+   if (ret != 0) {
+   CAAM_JR_ERR("failed to configure session parameters");
+
+   /* Return session to mempool */
+   rte_mempool_put(mempool, sess_private_data);
+   return ret;
+   }
+
+   set_sym_session_private_data(sess, dev->driver_id, sess_private_data);
+
+
+   return 0;
+}
+
+/* Clear the memory of session so it doesn't leave key material behind */
+static void
+caam_jr_sym_session_clear(struct rte_cryptodev *dev,
+   struct rte_cryptodev_sym_session *sess)
+{
+   uint8_t index = dev->driver_id;
+   void *sess_priv = get_sym_session_private_data(sess, index);
+   struct caam_jr_session *s = (struct caam_jr_session *)sess_priv;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (sess_priv) {
+   struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
+
+   rte_free(s->cipher_key.data);
+   rte_free(s->auth_key.data);
+   memset(s, 0, sizeof(struct caam_jr_session));
+   set_sym_session_private_data(sess, index, NULL);
+   rte_mempool_put(sess_mp, sess_priv);
+   }
+}
+
 static int
 caam_jr_dev_configure(struct rte_cryptodev *dev,
   struct rte_cryptodev_config *config __rte_unused)
@@ -250,6 +371,9 @@ static struct rte_cryptodev_ops caam_jr_ops = {
.queue_pair_setup = caam_jr_queue_pair_setup,
.queue_pair_release   = caam_jr_queue_pair_release,
.queue_pair_count = caam_jr_queue_pair_count,
+   .sym_ses

[dpdk-dev] [PATCH 09/10] crypto/caam_jr: add stats support

[Gagandeep Singh]

From: Hemant Agrawal 

Signed-off-by: Gagandeep Singh 
Signed-off-by: Hemant Agrawal 
---
 drivers/crypto/caam_jr/caam_jr.c | 55 
 1 file changed, 55 insertions(+)

diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index d582b2fcb..f51ff1093 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -99,6 +99,59 @@ caam_jr_alloc_ctx(struct caam_jr_session *ses)
 
return ctx;
 }
+
+static
+void caam_jr_stats_get(struct rte_cryptodev *dev,
+   struct rte_cryptodev_stats *stats)
+{
+   struct caam_jr_qp **qp = (struct caam_jr_qp **)
+   dev->data->queue_pairs;
+   int i;
+
+   PMD_INIT_FUNC_TRACE();
+   if (stats == NULL) {
+   CAAM_JR_ERR("Invalid stats ptr NULL");
+   return;
+   }
+   for (i = 0; i < dev->data->nb_queue_pairs; i++) {
+   if (qp[i] == NULL) {
+   CAAM_JR_WARN("Uninitialised queue pair");
+   continue;
+   }
+
+   stats->enqueued_count += qp[i]->tx_pkts;
+   stats->dequeued_count += qp[i]->rx_pkts;
+   stats->enqueue_err_count += qp[i]->tx_errs;
+   stats->dequeue_err_count += qp[i]->rx_errs;
+   CAAM_JR_INFO("extra stats:\n\tRX Poll ERR = %" PRIu64
+"\n\tTX Ring Full = %" PRIu64,
+qp[i]->rx_poll_err,
+qp[i]->tx_ring_full);
+   }
+}
+
+static
+void caam_jr_stats_reset(struct rte_cryptodev *dev)
+{
+   int i;
+   struct caam_jr_qp **qp = (struct caam_jr_qp **)
+  (dev->data->queue_pairs);
+
+   PMD_INIT_FUNC_TRACE();
+   for (i = 0; i < dev->data->nb_queue_pairs; i++) {
+   if (qp[i] == NULL) {
+   CAAM_JR_WARN("Uninitialised queue pair");
+   continue;
+   }
+   qp[i]->rx_pkts = 0;
+   qp[i]->rx_errs = 0;
+   qp[i]->rx_poll_err = 0;
+   qp[i]->tx_pkts = 0;
+   qp[i]->tx_errs = 0;
+   qp[i]->tx_ring_full = 0;
+   }
+}
+
 static inline int is_cipher_only(struct caam_jr_session *ses)
 {
return ((ses->cipher_alg != RTE_CRYPTO_CIPHER_NULL) &&
@@ -1689,6 +1742,8 @@ static struct rte_cryptodev_ops caam_jr_ops = {
.dev_stop = caam_jr_dev_stop,
.dev_close= caam_jr_dev_close,
.dev_infos_get= caam_jr_dev_infos_get,
+   .stats_get= caam_jr_stats_get,
+   .stats_reset  = caam_jr_stats_reset,
.queue_pair_setup = caam_jr_queue_pair_setup,
.queue_pair_release   = caam_jr_queue_pair_release,
.queue_pair_count = caam_jr_queue_pair_count,
-- 
2.17.1

[dpdk-dev] [PATCH 05/10] crypto/caam_jr: add queue config functions

[Gagandeep Singh]

From: Hemant Agrawal 

Signed-off-by: Gagandeep Singh 
Signed-off-by: Hemant Agrawal 
---
 drivers/crypto/caam_jr/caam_jr.c | 64 
 1 file changed, 64 insertions(+)

diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index 43fe5233b..f05e966b0 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -104,6 +104,67 @@ static void hw_flush_job_ring(struct sec_job_ring_t 
*job_ring,
}
 }
 
+/* Release queue pair */
+static int
+caam_jr_queue_pair_release(struct rte_cryptodev *dev,
+   uint16_t qp_id)
+{
+   struct sec_job_ring_t *internals;
+   struct caam_jr_qp *qp = NULL;
+
+   PMD_INIT_FUNC_TRACE();
+
+   CAAM_JR_DEBUG("dev =%p, queue =%d", dev, qp_id);
+
+   internals = dev->data->dev_private;
+   if (qp_id >= internals->max_nb_queue_pairs) {
+   CAAM_JR_ERR("Max supported qpid %d",
+internals->max_nb_queue_pairs);
+   return -EINVAL;
+   }
+
+   qp = &internals->qps[qp_id];
+   qp->ring = NULL;
+   dev->data->queue_pairs[qp_id] = NULL;
+
+   return 0;
+}
+
+/* Setup a queue pair */
+static int
+caam_jr_queue_pair_setup(
+   struct rte_cryptodev *dev, uint16_t qp_id,
+   __rte_unused const struct rte_cryptodev_qp_conf *qp_conf,
+   __rte_unused int socket_id,
+   __rte_unused struct rte_mempool *session_pool)
+{
+   struct sec_job_ring_t *internals;
+   struct caam_jr_qp *qp = NULL;
+
+   CAAM_JR_DEBUG("dev =%p, queue =%d, conf =%p", dev, qp_id, qp_conf);
+
+   internals = dev->data->dev_private;
+   if (qp_id >= internals->max_nb_queue_pairs) {
+   CAAM_JR_ERR("Max supported qpid %d",
+internals->max_nb_queue_pairs);
+   return -EINVAL;
+   }
+
+   qp = &internals->qps[qp_id];
+   qp->ring = internals;
+   dev->data->queue_pairs[qp_id] = qp;
+
+   return 0;
+}
+
+/* Return the number of allocated queue pairs */
+static uint32_t
+caam_jr_queue_pair_count(struct rte_cryptodev *dev)
+{
+   PMD_INIT_FUNC_TRACE();
+
+   return dev->data->nb_queue_pairs;
+}
 
 static int
 caam_jr_dev_configure(struct rte_cryptodev *dev,
@@ -186,6 +247,9 @@ static struct rte_cryptodev_ops caam_jr_ops = {
.dev_stop = caam_jr_dev_stop,
.dev_close= caam_jr_dev_close,
.dev_infos_get= caam_jr_dev_infos_get,
+   .queue_pair_setup = caam_jr_queue_pair_setup,
+   .queue_pair_release   = caam_jr_queue_pair_release,
+   .queue_pair_count = caam_jr_queue_pair_count,
 };
 
 
-- 
2.17.1

[dpdk-dev] [PATCH 08/10] crypto/caam_jr: add auth cipher and aead session support

[Gagandeep Singh]

From: Hemant Agrawal 

Signed-off-by: Gagandeep Singh 
Signed-off-by: Hemant Agrawal 
---
 drivers/crypto/caam_jr/caam_jr.c | 710 ++-
 1 file changed, 707 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index 6d30c4f4d..d582b2fcb 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -21,7 +21,9 @@
 /* RTA header files */
 #include 
 #include 
+#include 
 #include 
+
 #include 
 #include 
 #include 
@@ -103,6 +105,71 @@ static inline int is_cipher_only(struct caam_jr_session 
*ses)
(ses->auth_alg == RTE_CRYPTO_AUTH_NULL));
 }
 
+static inline int is_auth_only(struct caam_jr_session *ses)
+{
+   return ((ses->cipher_alg == RTE_CRYPTO_CIPHER_NULL) &&
+   (ses->auth_alg != RTE_CRYPTO_AUTH_NULL));
+}
+
+static inline int is_aead(struct caam_jr_session *ses)
+{
+   return ((ses->cipher_alg == 0) &&
+   (ses->auth_alg == 0) &&
+   (ses->aead_alg != 0));
+}
+
+static inline int is_auth_cipher(struct caam_jr_session *ses)
+{
+   return ((ses->cipher_alg != RTE_CRYPTO_CIPHER_NULL) &&
+   (ses->auth_alg != RTE_CRYPTO_AUTH_NULL));
+}
+
+static inline int is_encode(struct caam_jr_session *ses)
+{
+   return ses->dir == DIR_ENC;
+}
+
+static inline int is_decode(struct caam_jr_session *ses)
+{
+   return ses->dir == DIR_DEC;
+}
+
+static inline void
+caam_auth_alg(struct caam_jr_session *ses, struct alginfo *alginfo_a)
+{
+   switch (ses->auth_alg) {
+   case RTE_CRYPTO_AUTH_NULL:
+   ses->digest_length = 0;
+   break;
+   case RTE_CRYPTO_AUTH_MD5_HMAC:
+   alginfo_a->algtype = OP_ALG_ALGSEL_MD5;
+   alginfo_a->algmode = OP_ALG_AAI_HMAC;
+   break;
+   case RTE_CRYPTO_AUTH_SHA1_HMAC:
+   alginfo_a->algtype = OP_ALG_ALGSEL_SHA1;
+   alginfo_a->algmode = OP_ALG_AAI_HMAC;
+   break;
+   case RTE_CRYPTO_AUTH_SHA224_HMAC:
+   alginfo_a->algtype = OP_ALG_ALGSEL_SHA224;
+   alginfo_a->algmode = OP_ALG_AAI_HMAC;
+   break;
+   case RTE_CRYPTO_AUTH_SHA256_HMAC:
+   alginfo_a->algtype = OP_ALG_ALGSEL_SHA256;
+   alginfo_a->algmode = OP_ALG_AAI_HMAC;
+   break;
+   case RTE_CRYPTO_AUTH_SHA384_HMAC:
+   alginfo_a->algtype = OP_ALG_ALGSEL_SHA384;
+   alginfo_a->algmode = OP_ALG_AAI_HMAC;
+   break;
+   case RTE_CRYPTO_AUTH_SHA512_HMAC:
+   alginfo_a->algtype = OP_ALG_ALGSEL_SHA512;
+   alginfo_a->algmode = OP_ALG_AAI_HMAC;
+   break;
+   default:
+   CAAM_JR_DEBUG("unsupported auth alg %u", ses->auth_alg);
+   }
+}
+
 static inline void
 caam_cipher_alg(struct caam_jr_session *ses, struct alginfo *alginfo_c)
 {
@@ -126,13 +193,27 @@ caam_cipher_alg(struct caam_jr_session *ses, struct 
alginfo *alginfo_c)
}
 }
 
+static inline void
+caam_aead_alg(struct caam_jr_session *ses, struct alginfo *alginfo)
+{
+   switch (ses->aead_alg) {
+   case RTE_CRYPTO_AEAD_AES_GCM:
+   alginfo->algtype = OP_ALG_ALGSEL_AES;
+   alginfo->algmode = OP_ALG_AAI_GCM;
+   break;
+   default:
+   CAAM_JR_DEBUG("unsupported AEAD alg %d", ses->aead_alg);
+   }
+}
+
 /* prepare command block of the session */
 static int
 caam_jr_prep_cdb(struct caam_jr_session *ses)
 {
-   struct alginfo alginfo_c = {0};
+   struct alginfo alginfo_c = {0}, alginfo_a = {0}, alginfo = {0};
int32_t shared_desc_len = 0;
struct sec_cdb *cdb;
+   int err;
 #if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
int swap = false;
 #else
@@ -171,6 +252,108 @@ caam_jr_prep_cdb(struct caam_jr_session *ses)
NULL,
ses->iv.length,
ses->dir);
+   } else if (is_auth_only(ses)) {
+   caam_auth_alg(ses, &alginfo_a);
+   if (alginfo_a.algtype == (unsigned int)CAAM_JR_ALG_UNSUPPORT) {
+   CAAM_JR_ERR("not supported auth alg");
+   rte_free(cdb);
+   return -ENOTSUP;
+   }
+
+   alginfo_a.key = (size_t)ses->auth_key.data;
+   alginfo_a.keylen = ses->auth_key.length;
+   alginfo_a.key_enc_flags = 0;
+   alginfo_a.key_type = RTA_DATA_IMM;
+
+   shared_desc_len = cnstr_shdsc_hmac(cdb->sh_desc, true,
+  swap, &alginfo_a,
+  !ses->dir,
+  ses->digest_length);
+   } else if (is_aead(ses)) {
+   caam_aead_alg(ses, &alginfo);
+   if (alginfo.algtype == (unsig

[dpdk-dev] [PATCH 10/10] crypto/caam_jr: add security offload support

[Gagandeep Singh]

From: Hemant Agrawal 

Signed-off-by: Hemant Agrawal 
---
 drivers/crypto/caam_jr/caam_jr.c | 361 ++-
 drivers/crypto/caam_jr/caam_jr_pvt.h |   3 +
 2 files changed, 354 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index f51ff1093..c4689078a 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -174,7 +174,13 @@ static inline int is_aead(struct caam_jr_session *ses)
 static inline int is_auth_cipher(struct caam_jr_session *ses)
 {
return ((ses->cipher_alg != RTE_CRYPTO_CIPHER_NULL) &&
-   (ses->auth_alg != RTE_CRYPTO_AUTH_NULL));
+   (ses->auth_alg != RTE_CRYPTO_AUTH_NULL) &&
+   (ses->proto_alg != RTE_SECURITY_PROTOCOL_IPSEC));
+}
+
+static inline int is_proto_ipsec(struct caam_jr_session *ses)
+{
+   return (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC);
 }
 
 static inline int is_encode(struct caam_jr_session *ses)
@@ -195,27 +201,39 @@ caam_auth_alg(struct caam_jr_session *ses, struct alginfo 
*alginfo_a)
ses->digest_length = 0;
break;
case RTE_CRYPTO_AUTH_MD5_HMAC:
-   alginfo_a->algtype = OP_ALG_ALGSEL_MD5;
+   alginfo_a->algtype =
+   (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+   OP_PCL_IPSEC_HMAC_MD5_96 : OP_ALG_ALGSEL_MD5;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
case RTE_CRYPTO_AUTH_SHA1_HMAC:
-   alginfo_a->algtype = OP_ALG_ALGSEL_SHA1;
+   alginfo_a->algtype =
+   (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+   OP_PCL_IPSEC_HMAC_SHA1_96 : OP_ALG_ALGSEL_SHA1;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
case RTE_CRYPTO_AUTH_SHA224_HMAC:
-   alginfo_a->algtype = OP_ALG_ALGSEL_SHA224;
+   alginfo_a->algtype =
+   (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+   OP_PCL_IPSEC_HMAC_SHA1_160 : OP_ALG_ALGSEL_SHA224;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
case RTE_CRYPTO_AUTH_SHA256_HMAC:
-   alginfo_a->algtype = OP_ALG_ALGSEL_SHA256;
+   alginfo_a->algtype =
+   (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+   OP_PCL_IPSEC_HMAC_SHA2_256_128 : OP_ALG_ALGSEL_SHA256;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
case RTE_CRYPTO_AUTH_SHA384_HMAC:
-   alginfo_a->algtype = OP_ALG_ALGSEL_SHA384;
+   alginfo_a->algtype =
+   (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+   OP_PCL_IPSEC_HMAC_SHA2_384_192 : OP_ALG_ALGSEL_SHA384;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
case RTE_CRYPTO_AUTH_SHA512_HMAC:
-   alginfo_a->algtype = OP_ALG_ALGSEL_SHA512;
+   alginfo_a->algtype =
+   (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+   OP_PCL_IPSEC_HMAC_SHA2_512_256 : OP_ALG_ALGSEL_SHA512;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
default:
@@ -230,15 +248,21 @@ caam_cipher_alg(struct caam_jr_session *ses, struct 
alginfo *alginfo_c)
case RTE_CRYPTO_CIPHER_NULL:
break;
case RTE_CRYPTO_CIPHER_AES_CBC:
-   alginfo_c->algtype = OP_ALG_ALGSEL_AES;
+   alginfo_c->algtype =
+   (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+   OP_PCL_IPSEC_AES_CBC : OP_ALG_ALGSEL_AES;
alginfo_c->algmode = OP_ALG_AAI_CBC;
break;
case RTE_CRYPTO_CIPHER_3DES_CBC:
-   alginfo_c->algtype = OP_ALG_ALGSEL_3DES;
+   alginfo_c->algtype =
+   (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+   OP_PCL_IPSEC_3DES : OP_ALG_ALGSEL_3DES;
alginfo_c->algmode = OP_ALG_AAI_CBC;
break;
case RTE_CRYPTO_CIPHER_AES_CTR:
-   alginfo_c->algtype = OP_ALG_ALGSEL_AES;
+   alginfo_c->algtype =
+   (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+   OP_PCL_IPSEC_AES_CTR : OP_ALG_ALGSEL_AES;
alginfo_c->algmode = OP_ALG_AAI_CTR;
break;
default:
@@ -400,6 +424,22 @@ caam_jr_prep_cdb(struct caam_jr_session *ses)
cdb->sh_desc[0] = 0;
cdb->sh_desc[1] = 0;
cdb->sh_desc[2] = 0;
+   if (is_proto_ipsec(ses)) {
+   if (ses->dir == DIR_ENC) {
+   shared_desc_len = cnstr_shdsc_ipsec_new_encap(
+   cdb->sh_desc,
+  

[dpdk-dev] [PATCH 07/10] crypto/caam_jr: add enqueue and dequeue routines

[Gagandeep Singh]

From: Hemant Agrawal 

Signed-off-by: Gagandeep Singh 
Signed-off-by: Hemant Agrawal 
---
 drivers/crypto/caam_jr/caam_jr.c  | 621 +-
 drivers/crypto/caam_jr/caam_jr_desc.h | 289 
 2 files changed, 908 insertions(+), 2 deletions(-)
 create mode 100644 drivers/crypto/caam_jr/caam_jr_desc.h

diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index a0eee3b85..6d30c4f4d 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define CRYPTODEV_NAME_CAAM_JR_PMD crypto_caam_jr
@@ -50,6 +51,142 @@ static enum sec_driver_state_e g_driver_state = 
SEC_DRIVER_STATE_IDLE;
 static int g_job_rings_no;
 static int g_job_rings_max;
 
+struct sec_outring_entry {
+   phys_addr_t desc;   /* Pointer to completed descriptor */
+   uint32_t status;/* Status for completed descriptor */
+} __rte_packed;
+
+/* virtual address conversin when mempool support is available for ctx */
+static inline phys_addr_t
+caam_jr_vtop_ctx(struct caam_jr_op_ctx *ctx, void *vaddr)
+{
+   return (size_t)vaddr - ctx->vtop_offset;
+}
+
+static inline void
+caam_jr_op_ending(struct caam_jr_op_ctx *ctx)
+{
+   /* report op status to sym->op and then free the ctx memeory  */
+   rte_mempool_put(ctx->ctx_pool, (void *)ctx);
+}
+
+static inline struct caam_jr_op_ctx *
+caam_jr_alloc_ctx(struct caam_jr_session *ses)
+{
+   struct caam_jr_op_ctx *ctx;
+   int ret;
+
+   ret = rte_mempool_get(ses->ctx_pool, (void **)(&ctx));
+   if (!ctx || ret) {
+   CAAM_JR_DP_WARN("Alloc sec descriptor failed!");
+   return NULL;
+   }
+   /*
+* Clear SG memory. There are 16 SG entries of 16 Bytes each.
+* one call to dcbz_64() clear 64 bytes, hence calling it 4 times
+* to clear all the SG entries. caam_jr_alloc_ctx() is called for
+* each packet, memset is costlier than dcbz_64().
+*/
+   dcbz_64(&ctx->sg[SG_CACHELINE_0]);
+   dcbz_64(&ctx->sg[SG_CACHELINE_1]);
+   dcbz_64(&ctx->sg[SG_CACHELINE_2]);
+   dcbz_64(&ctx->sg[SG_CACHELINE_3]);
+
+   ctx->ctx_pool = ses->ctx_pool;
+   ctx->vtop_offset = (size_t) ctx - rte_mempool_virt2iova(ctx);
+
+   return ctx;
+}
+static inline int is_cipher_only(struct caam_jr_session *ses)
+{
+   return ((ses->cipher_alg != RTE_CRYPTO_CIPHER_NULL) &&
+   (ses->auth_alg == RTE_CRYPTO_AUTH_NULL));
+}
+
+static inline void
+caam_cipher_alg(struct caam_jr_session *ses, struct alginfo *alginfo_c)
+{
+   switch (ses->cipher_alg) {
+   case RTE_CRYPTO_CIPHER_NULL:
+   break;
+   case RTE_CRYPTO_CIPHER_AES_CBC:
+   alginfo_c->algtype = OP_ALG_ALGSEL_AES;
+   alginfo_c->algmode = OP_ALG_AAI_CBC;
+   break;
+   case RTE_CRYPTO_CIPHER_3DES_CBC:
+   alginfo_c->algtype = OP_ALG_ALGSEL_3DES;
+   alginfo_c->algmode = OP_ALG_AAI_CBC;
+   break;
+   case RTE_CRYPTO_CIPHER_AES_CTR:
+   alginfo_c->algtype = OP_ALG_ALGSEL_AES;
+   alginfo_c->algmode = OP_ALG_AAI_CTR;
+   break;
+   default:
+   CAAM_JR_DEBUG("unsupported cipher alg %d", ses->cipher_alg);
+   }
+}
+
+/* prepare command block of the session */
+static int
+caam_jr_prep_cdb(struct caam_jr_session *ses)
+{
+   struct alginfo alginfo_c = {0};
+   int32_t shared_desc_len = 0;
+   struct sec_cdb *cdb;
+#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+   int swap = false;
+#else
+   int swap = true;
+#endif
+
+   if (ses->cdb)
+   caam_jr_dma_free(ses->cdb);
+
+   cdb = caam_jr_dma_mem_alloc(L1_CACHE_BYTES, sizeof(struct sec_cdb));
+   if (!cdb) {
+   CAAM_JR_ERR("failed to allocate memory for cdb\n");
+   return -1;
+   }
+
+   ses->cdb = cdb;
+
+   memset(cdb, 0, sizeof(struct sec_cdb));
+
+   if (is_cipher_only(ses)) {
+   caam_cipher_alg(ses, &alginfo_c);
+   if (alginfo_c.algtype == (unsigned int)CAAM_JR_ALG_UNSUPPORT) {
+   CAAM_JR_ERR("not supported cipher alg");
+   rte_free(cdb);
+   return -ENOTSUP;
+   }
+
+   alginfo_c.key = (size_t)ses->cipher_key.data;
+   alginfo_c.keylen = ses->cipher_key.length;
+   alginfo_c.key_enc_flags = 0;
+   alginfo_c.key_type = RTA_DATA_IMM;
+
+   shared_desc_len = cnstr_shdsc_blkcipher(
+   cdb->sh_desc, true,
+   swap, &alginfo_c,
+   NULL,
+   ses->iv.length,
+   ses->dir);
+   }
+
+   if (shared_desc_len < 0) {
+

Re: [dpdk-dev] [RFC] eal: allow hotplug to skip an already probed device

[Ophir Munk]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Saturday, September 08, 2018 2:10 AM
> To: dev@dpdk.org
> Cc: gaetan.ri...@6wind.com
> Subject: [dpdk-dev] [RFC] eal: allow hotplug to skip an already probed device
> 
> In the devargs syntax for device representors, it is possible to add several
> devices at once: -w dbdf,representor=[0-3] It will become a more frequent
> case when introducing wildcards and ranges in the new devargs syntax.
> 
> If a devargs string is provided for probing, and updated with a bigger range
> for a new probing, then we do not want it to fail because part of this range
> was already probed previously.
> 

When having devargs with representors ("dbdf,representor=") there is 
actually just one PCI device to probe (whose address is "dbdf", the master) 
while the representors themselves are net devices all using the same PCI "dbdf" 
address. 
The way to see it: when running "lspci": only the "dpdf" PCI device appears 
while when executing "ifconfig" - all representors are shown as net devices.
When calling rte_eal_hotplug_add() for the first time there is a flow which 
eventually calls the PMD probe callback (e.g. mlx5_pci_probe() in case of mlx5 
PMD). 
When calling rte_eal_hotplug_add() for several times we should skip failures 
till we reach the PMD probe callback.

Skipping failures can be done as follows:
1. In file ./lib/librte_eal/common/eal_common_dev.c, function: 
rte_eal_hotplug_add(), remove the following code:

if (dev->driver != NULL) {
RTE_LOG(ERR, EAL, "Device is already plugged\n");
return -EEXIST}

2. In file ./drivers/bus/pci/pci_common.cm function: pci_probe_all_drivers(), 
remove the following code:

/* Check if a driver is already loaded */ if (dev->driver != NULL)
return -1;


However the substantial major changes are in each individual PMD probe callback 
when it is called several times with different devargs. For example it should 
not fail an already probed PCI device and just create new eth devices for new 
representors.


> On the opposite, we could require rte_eal_hotplug_add() to try to add all
> matching devices, and fail if one is already probed.
> 
> That's why a new parameter is added to specify if the function must fail or
> not when trying to add an already probed device.
> 

Please note this new parameter ("fail_existing") will have to be propagated to 
all PMD probe callbacks.
Otherwise, in case (fail_existing == false) a second call to 
rte_eal_hotplug_add() will call the PMD probe callback, which may fail unless 
it is aware of "fail_existing" parameter.
Alternatively "fail_existing" may be better named "enable_multi_probes".
Anyway - if the PMD probe() callback has to be updated to return a 
success/failure value (for more than one probe) - maybe we do not need a new 
parameter and can rely on the PMD probe() callback the take the decision by 
returning success/failure value.

The counter part of rte_eal_hotplug_add() is rte_eal_hotplug_remove() which 
must be updated as well. For example when representors 1 and 2 exist - then 
removing just representor 1 will have to make sure that the PCI device used for 
both representors is not unplugged since representor 2 is not removed and it 
uses the same PCI device as representor 1.

> Signed-off-by: Thomas Monjalon 
> ---
> This patch contains only the change in the function itself as RFC.
> 
> This idea was presented at Dublin during the "hotplug talk".
> ---
>  lib/librte_eal/common/eal_common_dev.c  | 4 +++-
> lib/librte_eal/common/include/rte_dev.h | 5 -
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eal/common/eal_common_dev.c
> b/lib/librte_eal/common/eal_common_dev.c
> index 678dbcac7..17d7e9089 100644
> --- a/lib/librte_eal/common/eal_common_dev.c
> +++ b/lib/librte_eal/common/eal_common_dev.c
> @@ -128,7 +128,7 @@ int rte_eal_dev_detach(struct rte_device *dev)  }
> 
>  int __rte_experimental rte_eal_hotplug_add(const char *busname, const
> char *devname,
> - const char *devargs)
> + const char *devargs, bool fail_existing)
>  {
>   struct rte_bus *bus;
>   struct rte_device *dev;
> @@ -173,6 +173,8 @@ int __rte_experimental rte_eal_hotplug_add(const
> char *busname, const char *devn
>   }
> 
>   if (dev->driver != NULL) {
> + if (!fail_existing)
> + return 0;
>   RTE_LOG(ERR, EAL, "Device is already plugged\n");
>   return -EEXIST;
>   }
> diff --git a/lib/librte_eal/common/include/rte_dev.h
> b/lib/librte_eal/common/include/rte_dev.h
> index b80a80598..10a1cd2b4 100644
> --- a/lib/librte_eal/common/include/rte_dev.h
> +++ b/lib/librte_eal/common/include/rte_dev.h
> @@ -201,11 +201,14 @@ int rte_eal_dev_detach(struct rte_device *dev);
>   *   capable of handling it and pass it to the driver probing function.
>   * @param devargs
>   *   Device arguments 

Re: [dpdk-dev] [PATCH 1/3] mbuf: add sanity checks on segment metadata

[David Marchand]

Hello Yongseok,

On Tue, Sep 11, 2018 at 8:16 PM, Yongseok Koh  wrote:
>
>> On Sep 9, 2018, at 10:45 PM, David Marchand  wrote:
>>
>> Add some basic checks on the segments offset and length metadata:
>> always funny to have a < 0 tailroom cast to uint16_t ;-).
>>
>> Signed-off-by: David Marchand 
>> ---
>> lib/librte_mbuf/rte_mbuf.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
>> index e714c5a59..137a320ed 100644
>> --- a/lib/librte_mbuf/rte_mbuf.c
>> +++ b/lib/librte_mbuf/rte_mbuf.c
>> @@ -200,6 +200,11 @@ rte_mbuf_sanity_check(const struct rte_mbuf *m, int 
>> is_header)
>>   pkt_len = m->pkt_len;
>>
>>   do {
>> + if (m->data_off > m->buf_len)
>> + rte_panic("data offset too big in mbuf segment\n");
>> + if ((uint32_t)m->data_off + (uint32_t)m->data_len >
>> + (uint32_t)m->buf_len)
>
> Casting to uint32_t is needed? All of the three fields are uint16_t and it 
> would
> anyway happen because of the integer promotion rule. Right?

Indeed, this is unnecessary.
Will send a v2 without this.


-- 
David Marchand