date:20170602

Re: [dpdk-dev] [PATCH v2 01/11] net/e1000: store and restore TCP SYN filter

2017-06-02 Thread Lu, Wenzhuo

Hi,

> -Original Message-
> From: Zhao1, Wei
> Sent: Friday, June 2, 2017 2:36 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo; Zhao1, Wei
> Subject: [PATCH v2 01/11] net/e1000: store and restore TCP SYN filter
> 
> Add support for storing and restoring TCP SYN filter in SW.
> 
> Signed-off-by: Wei Zhao 
Acked-by: Wenzhuo Lu

Re: [dpdk-dev] [PATCH v2 02/11] net/e1000: restore n-tuple filter

2017-06-02 Thread Lu, Wenzhuo

Hi Wei,

> -Original Message-
> From: Zhao1, Wei
> Sent: Friday, June 2, 2017 2:36 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo; Zhao1, Wei
> Subject: [PATCH v2 02/11] net/e1000: restore n-tuple filter
> 
> Add support for restoring n-tuple
> filter in SW.
> 
> Signed-off-by: Wei Zhao 
> ---
>  drivers/net/e1000/igb_ethdev.c | 262 +
> 
>  1 file changed, 159 insertions(+), 103 deletions(-)
> 
> diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
> index 1077870..1e321d6 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -757,6 +757,35 @@ igb_reset_swfw_lock(struct e1000_hw *hw)
>   return E1000_SUCCESS;
>  }
> 
> +/* Remove all ntuple filters of the device */ static int
> +igb_ntuple_filter_uninit(struct rte_eth_dev *eth_dev) {
> + struct e1000_filter_info *filter_info =
> + E1000_DEV_PRIVATE_TO_FILTER_INFO(eth_dev->data-
> >dev_private);
> +
> + struct e1000_5tuple_filter *p_5tuple, *p_5tuple_next;
> + struct e1000_2tuple_filter *p_2tuple, *p_2tuple_next;
> +
> + for (p_5tuple = TAILQ_FIRST(&filter_info->fivetuple_list);
> +  p_5tuple != NULL; p_5tuple = p_5tuple_next) {
> + p_5tuple_next = TAILQ_NEXT(p_5tuple, entries);
> + TAILQ_REMOVE(&filter_info->fivetuple_list,
> +  p_5tuple, entries);
> + rte_free(p_5tuple);
> + }
I know you don't change this code. It's moved here. But this implementation is 
complex and not friendly. Would you like to change it to,
while ((p_5tuple = TAILQ_FIRST(&filter_info->fivetuple_list))) {
TAILQ_REMOVE(&filter_info->fivetuple_list,
 p_5tuple, entries);
rte_free(p_5tuple);
}
The same below.

> + filter_info->fivetuple_mask = 0;
> + for (p_2tuple = TAILQ_FIRST(&filter_info->twotuple_list);
> +  p_2tuple != NULL; p_2tuple = p_2tuple_next) {
> + p_2tuple_next = TAILQ_NEXT(p_2tuple, entries);
> + TAILQ_REMOVE(&filter_info->twotuple_list,
> +  p_2tuple, entries);
> + rte_free(p_2tuple);
> + }
> + filter_info->twotuple_mask = 0;
> +
> + return 0;
> +}

Re: [dpdk-dev] [PATCH v2 02/11] net/e1000: restore n-tuple filter

2017-06-02 Thread Zhao1, Wei

Hi, wenzhuo

> -Original Message-
> From: Lu, Wenzhuo
> Sent: Friday, June 2, 2017 3:57 PM
> To: Zhao1, Wei ; dev@dpdk.org
> Subject: RE: [PATCH v2 02/11] net/e1000: restore n-tuple filter
> 
> Hi Wei,
> 
> > -Original Message-
> > From: Zhao1, Wei
> > Sent: Friday, June 2, 2017 2:36 PM
> > To: dev@dpdk.org
> > Cc: Lu, Wenzhuo; Zhao1, Wei
> > Subject: [PATCH v2 02/11] net/e1000: restore n-tuple filter
> >
> > Add support for restoring n-tuple
> > filter in SW.
> >
> > Signed-off-by: Wei Zhao 
> > ---
> >  drivers/net/e1000/igb_ethdev.c | 262
> > +
> > 
> >  1 file changed, 159 insertions(+), 103 deletions(-)
> >
> > diff --git a/drivers/net/e1000/igb_ethdev.c
> > b/drivers/net/e1000/igb_ethdev.c index 1077870..1e321d6 100644
> > --- a/drivers/net/e1000/igb_ethdev.c
> > +++ b/drivers/net/e1000/igb_ethdev.c
> > @@ -757,6 +757,35 @@ igb_reset_swfw_lock(struct e1000_hw *hw)
> > return E1000_SUCCESS;
> >  }
> >
> > +/* Remove all ntuple filters of the device */ static int
> > +igb_ntuple_filter_uninit(struct rte_eth_dev *eth_dev) {
> > +   struct e1000_filter_info *filter_info =
> > +   E1000_DEV_PRIVATE_TO_FILTER_INFO(eth_dev->data-
> > >dev_private);
> > +
> > +   struct e1000_5tuple_filter *p_5tuple, *p_5tuple_next;
> > +   struct e1000_2tuple_filter *p_2tuple, *p_2tuple_next;
> > +
> > +   for (p_5tuple = TAILQ_FIRST(&filter_info->fivetuple_list);
> > +p_5tuple != NULL; p_5tuple = p_5tuple_next) {
> > +   p_5tuple_next = TAILQ_NEXT(p_5tuple, entries);
> > +   TAILQ_REMOVE(&filter_info->fivetuple_list,
> > +p_5tuple, entries);
> > +   rte_free(p_5tuple);
> > +   }
> I know you don't change this code. It's moved here. But this implementation
> is complex and not friendly. Would you like to change it to,
>   while ((p_5tuple = TAILQ_FIRST(&filter_info->fivetuple_list))) {
>   TAILQ_REMOVE(&filter_info->fivetuple_list,
>p_5tuple, entries);
>   rte_free(p_5tuple);
>   }
> The same below.

Ok, I will change as your suggestion in v3 later.

> 
> > +   filter_info->fivetuple_mask = 0;
> > +   for (p_2tuple = TAILQ_FIRST(&filter_info->twotuple_list);
> > +p_2tuple != NULL; p_2tuple = p_2tuple_next) {
> > +   p_2tuple_next = TAILQ_NEXT(p_2tuple, entries);
> > +   TAILQ_REMOVE(&filter_info->twotuple_list,
> > +p_2tuple, entries);
> > +   rte_free(p_2tuple);
> > +   }
> > +   filter_info->twotuple_mask = 0;
> > +
> > +   return 0;
> > +}

Re: [dpdk-dev] [PATCH v2 03/11] net/e1000: restore ether type filter

2017-06-02 Thread Lu, Wenzhuo

Hi,

> -Original Message-
> From: Zhao1, Wei
> Sent: Friday, June 2, 2017 2:36 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo; Zhao1, Wei
> Subject: [PATCH v2 03/11] net/e1000: restore ether type filter
> 
> Add support for restoring ether type filter in SW.
> 
> Signed-off-by: Wei Zhao 
Acked-by: Wenzhuo Lu

Re: [dpdk-dev] [PATCH v2 04/11] net/e1000: restore flex type filter

2017-06-02 Thread Lu, Wenzhuo

Hi,

> -Original Message-
> From: Zhao1, Wei
> Sent: Friday, June 2, 2017 2:36 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo; Zhao1, Wei
> Subject: [PATCH v2 04/11] net/e1000: restore flex type filter
> 
> Add support for restoring flex type filter in SW.
> 
> Signed-off-by: Wei Zhao 
Acked-by: Wenzhuo Lu

Re: [dpdk-dev] [PATCH] vhost: fix crash on NUMA

2017-06-02 Thread Jens Freimann

On Fri, Jun 02, 2017 at 08:14:46AM +0800, Yuanhan Liu wrote:
> The queue allocation was changed, from allocating one queue-pair at a
> time to one queue at a time. Most of the changes have been done, but
> just with one being missed: the size of coping the old queue is still

s/coping/copying/ ?

> based on queue-pair at numa_realloc(), which leads to overwritten issue.
> As a result, crash may happen.
> 
> Fix it by specifying the right copy size. Also, the net queue macros
> are not used any more. Remove them.
> 
> Fixes: ab4d7b9f1afc ("vhost: turn queue pair to vring")
> 
> Cc: sta...@dpdk.org
> Reported-by: Ciara Loftus 
> Signed-off-by: Yuanhan Liu 
> ---
>  lib/librte_vhost/vhost_user.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 

Reviewed-by: Jens Freimann

[dpdk-dev] [PATCH] event/octeontx: add driver name in info get

2017-06-02 Thread Jerin Jacob

Signed-off-by: Jerin Jacob 
---
 drivers/event/octeontx/ssovf_evdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/event/octeontx/ssovf_evdev.c 
b/drivers/event/octeontx/ssovf_evdev.c
index c80a44379..f1b7eee3d 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -170,6 +170,7 @@ ssovf_info_get(struct rte_eventdev *dev, struct 
rte_event_dev_info *dev_info)
 {
struct ssovf_evdev *edev = ssovf_pmd_priv(dev);
 
+   dev_info->driver_name = RTE_STR(EVENTDEV_NAME_OCTEONTX_PMD);
dev_info->min_dequeue_timeout_ns = edev->min_deq_timeout_ns;
dev_info->max_dequeue_timeout_ns = edev->max_deq_timeout_ns;
dev_info->max_event_queues = edev->max_event_queues;
-- 
2.13.0

Re: [dpdk-dev] [RFC] eal/memory: introducing an option to set iova as va

2017-06-02 Thread Bruce Richardson

On Fri, Jun 02, 2017 at 09:54:46AM +0530, santosh wrote:
> Ping?
> 
> On Wednesday 24 May 2017 09:41 PM, Santosh Shukla wrote:
> 
> > Some NPU hardware like OCTEONTX follows push model to get
> > the packet from the pktio device. Where packet allocation
> > and freeing done by the HW. Since HW can operate only on
> > IOVA with help of SMMU/IOMMU, When packet receives from the
> > Ethernet device, It is the IOVA address(which is PA in existing scheme).
> >
> > Mapping IOVA as PA is expensive on those HW, where every
> > packet needs to be converted to VA from PA/IOVA.
> >
> > This patch proposes the scheme where the user can set IOVA
> > as VA by using an eal command line argument. That helps to
> > avoid costly lookup for VA in SW by leveraging the SMMU
> > translation feature.
> >
> > Signed-off-by: Santosh Shukla 
> > ---
Hi,

I agree this is a problem that needs to be solved, but this doesn't look
like a particularly future-proofed solution. Given that we should
use the IOMMU on as many platforms as possible for protection, we
probably need to find an automatic way for DPDK to use IO addresses
correctly. Is this therefore better done as part of the VFIO and
UIO-specific code in EAL - as that is the part that knows how the memory
mapping is done, and in the VFIO case, what address ranges were
programmed in. The mempool driver was something else I considered but it
is probably too high a level to implement this.

So, in short, I don't particularly like this solution, but I could live
with it as a short-term option. Longer term though, I think we need a
better way to support using IO addresses rather than physical addresses
- I just don't know what that would look like or where it would sit/live.

/Bruce

[dpdk-dev] [dpdk-announce] DPDK 17.02.1 released

2017-06-02 Thread Yuanhan Liu

Hi all,

I'm going to announce the 17.02.1 stable release:
http://fast.dpdk.org/rel/dpdk-17.02.1.tar.xz

The git tree is at:
http://dpdk.org/browse/dpdk-stable/

Thanks.

--yliu

---
 app/test-crypto-perf/cperf_test_throughput.c   |  13 +
 app/test-crypto-perf/cperf_test_vectors.c  |   2 +-
 app/test-crypto-perf/data/aes_cbc_128_sha.data | 439 ++---
 app/test-pmd/cmdline_flow.c|  11 +-
 app/test-pmd/csumonly.c|  11 +-
 app/test-pmd/testpmd.c |  22 +-
 app/test/test_cmdline_num.c|   1 +
 app/test/test_mempool.c|   5 +-
 .../howto/virtio_user_as_exceptional_path.rst  |   2 +-
 doc/guides/nics/bnx2x.rst  |   6 +-
 doc/guides/rel_notes/release_17_02.rst | 164 
 drivers/crypto/openssl/rte_openssl_pmd_ops.c   |  10 +-
 drivers/crypto/qat/qat_crypto.c|  39 +-
 drivers/crypto/scheduler/rte_cryptodev_scheduler.c |   4 +-
 drivers/crypto/scheduler/rte_cryptodev_scheduler.h |   2 +-
 drivers/crypto/scheduler/scheduler_pmd.c   |   2 +-
 drivers/crypto/scheduler/scheduler_pmd_private.h   |   2 +-
 drivers/net/bnx2x/bnx2x_rxtx.c |   2 +
 drivers/net/bnx2x/bnx2x_rxtx.h |   2 +-
 drivers/net/bonding/rte_eth_bond_pmd.c |   9 +-
 drivers/net/cxgbe/base/t4_hw.c |   3 +
 drivers/net/e1000/base/e1000_vf.c  |   3 +-
 drivers/net/e1000/igb_ethdev.c |  12 +-
 drivers/net/e1000/igb_pf.c |   4 +
 drivers/net/ena/base/ena_com.c |   2 +-
 drivers/net/ena/ena_ethdev.c   |  16 +-
 drivers/net/fm10k/fm10k_ethdev.c   |  37 +-
 drivers/net/fm10k/fm10k_rxtx_vec.c |  16 +-
 drivers/net/i40e/i40e_ethdev.c | 157 ++--
 drivers/net/i40e/i40e_ethdev.h |   1 +
 drivers/net/i40e/i40e_ethdev_vf.c  |   7 +
 drivers/net/i40e/i40e_flow.c   |   6 +-
 drivers/net/i40e/i40e_pf.c |  29 +-
 drivers/net/i40e/i40e_rxtx.c   |   8 +-
 drivers/net/i40e/i40e_rxtx.h   |   2 +-
 drivers/net/i40e/i40e_rxtx_vec_common.h|   4 +
 drivers/net/i40e/i40e_rxtx_vec_neon.c  |   2 +-
 drivers/net/i40e/i40e_rxtx_vec_sse.c   |  16 +-
 drivers/net/ixgbe/base/ixgbe_phy.c |  29 +-
 drivers/net/ixgbe/ixgbe_ethdev.c   |  24 +-
 drivers/net/ixgbe/ixgbe_fdir.c |   6 +-
 drivers/net/ixgbe/ixgbe_flow.c |  91 ++---
 drivers/net/ixgbe/ixgbe_pf.c   |  14 +-
 drivers/net/ixgbe/ixgbe_rxtx.c |  57 ++-
 drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c |  16 +-
 drivers/net/mlx4/mlx4.c|  19 +-
 drivers/net/mlx5/mlx5.c|  14 +-
 drivers/net/mlx5/mlx5_ethdev.c |   8 +-
 drivers/net/mlx5/mlx5_flow.c   |   9 +-
 drivers/net/mlx5/mlx5_rxq.c|  13 +
 drivers/net/mlx5/mlx5_rxtx.c   |  34 +-
 drivers/net/mlx5/mlx5_trigger.c|  22 +-
 drivers/net/mlx5/mlx5_txq.c|  13 +
 drivers/net/nfp/nfp_net.c  |  39 +-
 drivers/net/pcap/rte_eth_pcap.c|   2 +-
 drivers/net/qede/qede_ethdev.c | 107 +++--
 drivers/net/qede/qede_ethdev.h |   2 +-
 drivers/net/qede/qede_main.c   |   9 +-
 drivers/net/qede/qede_rxtx.c   |  22 +-
 drivers/net/qede/qede_rxtx.h   |   4 +
 drivers/net/sfc/sfc_ev.c   |  13 +-
 drivers/net/sfc/sfc_intr.c |   2 +
 drivers/net/sfc/sfc_rx.c   |   7 +-
 drivers/net/sfc/sfc_tx.c   |   2 +
 drivers/net/tap/rte_eth_tap.c  |   4 +-
 drivers/net/thunderx/base/nicvf_bsvf.c |  12 +-
 drivers/net/thunderx/base/nicvf_bsvf.h |   2 +-
 drivers/net/thunderx/base/nicvf_hw_defs.h  |  58 ++-
 drivers/net/thunderx/base/nicvf_mbox.c |   2 +-
 drivers/net/thunderx/base/nicvf_plat.h |   4 +
 drivers/net/thunderx/nicvf_ethdev.c|   9 +-
 drivers/net/thunderx/nicvf_rxtx.c  |  18 +-
 drivers/net/thunderx/nicvf_struct.h|  12 +-
 drivers/net/virtio/virtio_ethdev.c |  20 +-
 drivers/net/virtio/virtio_pci.c|  27 +-
 drivers/net/virtio/virtio_pci.h|   6 +-
 drivers/net/virtio/virtio_user/vhost_kernel.c  |   2 +-
 drivers/net/virtio/virtio_user/virtio_user_dev.c   |   2 +-
 drivers/net/virt

Re: [dpdk-dev] [PATCH v2] lpm: fix build error on g++ with -O0 option

2017-06-02 Thread Bruce Richardson

On Fri, Jun 02, 2017 at 05:07:46AM +, Sangjin Han wrote:
> When rte_lpm.h is used on x86, -O0 option (no optimization at all)
> given to gcc causes a compile error like this:
> 
> error: the last argument must be an 8-bit immediate
>i24 = _mm_srli_si128(i24, sizeof(uint64_t));
> 
> -O0 option is useful for debugging and code coverage measurement, but
> this error prevents DPDK programs from building. This patch replaces
> "sizeof(uint64_t)" with a constant literal "8" to work around the issue.
> The issue occurs on gcc/g++ versions from 4.8 to 5.
> 
> Signed-off-by: Sangjin Han 
Acked-by: Bruce Richardson

Re: [dpdk-dev] [RFC PATCH v2 1/3] cryptodev: added asymmetric algorithms

2017-06-02 Thread Umesh Kartha

Hi Fiona,

On Mon, May 29, 2017 at 02:51:11PM +, Trahe, Fiona wrote:
> Hi Umesh,
> 
> > -Original Message-
> > From: Umesh Kartha [mailto:umesh.kar...@caviumnetworks.com]
> > Sent: Friday, May 26, 2017 8:18 AM
> > To: Trahe, Fiona 
> > Cc: dev@dpdk.org; Jerin Jacob ; 
> > Balasubramanian Manoharan
> > ; Ram Kumar ; 
> > Murthy
> > Nidadavolu ; Doherty, Declan 
> > ; De Lara
> > Guarch, Pablo 
> > Subject: Re: [RFC PATCH v2 1/3] cryptodev: added asymmetric algorithms
> > 
> > Hi Fiona,
> > 
> > 
> > On Thu, May 25, 2017 at 04:00:42PM +, Trahe, Fiona wrote:
> > > Hi Umesh,
> > >
> > >
> > > > -Original Message-
> > > > From: Umesh Kartha [mailto:umesh.kar...@caviumnetworks.com]
> > > > Sent: Thursday, May 11, 2017 1:36 PM
> > > > To: dev@dpdk.org
> > > > Cc: Jerin Jacob ; Balasubramanian 
> > > > Manoharan
> > > > ; Ram Kumar 
> > > > ; Murthy
> > > > Nidadavolu ; Doherty, Declan 
> > > > ; De
> > Lara
> > > > Guarch, Pablo ; Trahe, Fiona 
> > > > 
> > > > Subject: [RFC PATCH v2 1/3] cryptodev: added asymmetric algorithms
> > > >
> > > > Added asymmetric xform structures, operation definitions, operation
> > > > parameters. Added asymmetric algorithms RSA, DH, ECDH, DSA, ECDSA,
> > > > MODEXP, FECC, MOD-INVERSE. Added curves (all curves supported by
> > > > libcrypto as of now).
> > > >
> > > > Signed-off-by: Umesh Kartha 
> > > > ---
> > > >  lib/librte_cryptodev/rte_crypto_asym.h | 1124 
> > > > 
> > > >  1 file changed, 1124 insertions(+)
> > > >  create mode 100644 lib/librte_cryptodev/rte_crypto_asym.h
> > > >
> > > > diff --git lib/librte_cryptodev/rte_crypto_asym.h 
> > > > lib/librte_cryptodev/rte_crypto_asym.h
> > > > new file mode 100644
> > > > index 000..36a8b4f
> > > > --- /dev/null
> > > > +++ lib/librte_cryptodev/rte_crypto_asym.h
> > > > @@ -0,0 +1,1124 @@
> > > > +/*
> > > > + *   BSD LICENSE
> > > > + *
> > > > + *   Copyright (C) Cavium networks Ltd. 2017.
> > > > + *
> > > > + *   Redistribution and use in source and binary forms, with or without
> > > > + *   modification, are permitted provided that the following conditions
> > > > + *   are met:
> > > > + *
> > > > + * * Redistributions of source code must retain the above copyright
> > > > + *   notice, this list of conditions and the following disclaimer.
> > > > + * * Redistributions in binary form must reproduce the above 
> > > > copyright
> > > > + *   notice, this list of conditions and the following disclaimer 
> > > > in
> > > > + *   the documentation and/or other materials provided with the
> > > > + *   distribution.
> > > > + * * Neither the name of Cavium Networks nor the names of its
> > > > + *   contributors may be used to endorse or promote products 
> > > > derived
> > > > + *   from this software without specific prior written permission.
> > > > + *
> > > > + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
> > > > CONTRIBUTORS
> > > > + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> > > > + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 
> > > > FOR
> > > > + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE 
> > > > COPYRIGHT
> > > > + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 
> > > > INCIDENTAL,
> > > > + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> > > > + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF 
> > > > USE,
> > > > + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 
> > > > ANY
> > > > + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR 
> > > > TORT
> > > > + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
> > > > USE
> > > > + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
> > > > DAMAGE.
> > > > + */
> > > > +
> > > > +#ifndef _RTE_CRYPTO_ASYM_H_
> > > > +#define _RTE_CRYPTO_ASYM_H_
> > > > +
> > > > +/**
> > > > + * @file rte_crypto_asym.h
> > > > + *
> > > > + * RTE Definitions for Asymmetric Cryptography
> > > > + *
> > > > + * Defines asymmetric algorithms and modes, as well as supported
> > > > + * asymmetric crypto operations.
> > > > + */
> > > > +
> > > > +#ifdef __cplusplus
> > > > +extern "C" {
> > > > +#endif
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include "rte_crypto_sym.h"
> > > > +
> > > > +typedef struct rte_crypto_xform_param_t {
> > > > +   uint8_t *data;
> > > > +   size_t length;
> > > > +} rte_crypto_xform_param;
> > > > +
> > > > +typedef struct rte_crypto_op_param_t {
> > > > +   uint8_t *data;
> > > > +   phys_addr_t phys_addr;
> > > > +   size_t length;
> > > > +} rte_crypto_op_param;
> > > [Fiona] Are both above lengths in bytes ?
> > >
> > >
> > [Umesh] Yes, they are in bytes. Will add note for this to avoid any
> > confusion.
> [Fiona] Thanks.
> Re y

[dpdk-dev] [PATCH 1/4] examples/l3fwd: add switch fall-through comments

2017-06-02 Thread Jerin Jacob

This fixes compiler warnings with GCC 7.1.1

Fixes: 26b5b020 ("examples/l3fwd: modularize")
Fixes: 94c54b4158d5 ("examples/l3fwd: rework exact-match")
Signed-off-by: Jerin Jacob 
---
 examples/l3fwd/l3fwd_lpm_sse.h | 2 ++
 examples/l3fwd/l3fwd_sse.h | 8 
 2 files changed, 10 insertions(+)

diff --git a/examples/l3fwd/l3fwd_lpm_sse.h b/examples/l3fwd/l3fwd_lpm_sse.h
index aa06b6d34..e92814b10 100644
--- a/examples/l3fwd/l3fwd_lpm_sse.h
+++ b/examples/l3fwd/l3fwd_lpm_sse.h
@@ -199,9 +199,11 @@ l3fwd_lpm_send_packets(int nb_rx, struct rte_mbuf 
**pkts_burst,
case 3:
dst_port[j] = lpm_get_dst_port(qconf, pkts_burst[j], portid);
j++;
+   /* fall-through */
case 2:
dst_port[j] = lpm_get_dst_port(qconf, pkts_burst[j], portid);
j++;
+   /* fall-through */
case 1:
dst_port[j] = lpm_get_dst_port(qconf, pkts_burst[j], portid);
j++;
diff --git a/examples/l3fwd/l3fwd_sse.h b/examples/l3fwd/l3fwd_sse.h
index 1afa1f006..fa9c4829d 100644
--- a/examples/l3fwd/l3fwd_sse.h
+++ b/examples/l3fwd/l3fwd_sse.h
@@ -349,12 +349,15 @@ send_packetsx4(struct lcore_conf *qconf, uint8_t port, 
struct rte_mbuf *m[],
case 0:
qconf->tx_mbufs[port].m_table[len + j] = m[j];
j++;
+   /* fall-through */
case 3:
qconf->tx_mbufs[port].m_table[len + j] = m[j];
j++;
+   /* fall-through */
case 2:
qconf->tx_mbufs[port].m_table[len + j] = m[j];
j++;
+   /* fall-through */
case 1:
qconf->tx_mbufs[port].m_table[len + j] = m[j];
j++;
@@ -376,12 +379,15 @@ send_packetsx4(struct lcore_conf *qconf, uint8_t port, 
struct rte_mbuf *m[],
case 0:
qconf->tx_mbufs[port].m_table[j] = m[n + j];
j++;
+   /* fall-through */
case 3:
qconf->tx_mbufs[port].m_table[j] = m[n + j];
j++;
+   /* fall-through */
case 2:
qconf->tx_mbufs[port].m_table[j] = m[n + j];
j++;
+   /* fall-through */
case 1:
qconf->tx_mbufs[port].m_table[j] = m[n + j];
j++;
@@ -464,10 +470,12 @@ send_packets_multi(struct lcore_conf *qconf, struct 
rte_mbuf **pkts_burst,
process_packet(pkts_burst[j], dst_port + j);
GROUP_PORT_STEP(dlp, dst_port, lp, pnum, j);
j++;
+   /* fall-through */
case 2:
process_packet(pkts_burst[j], dst_port + j);
GROUP_PORT_STEP(dlp, dst_port, lp, pnum, j);
j++;
+   /* fall-through */
case 1:
process_packet(pkts_burst[j], dst_port + j);
GROUP_PORT_STEP(dlp, dst_port, lp, pnum, j);
-- 
2.13.0

[dpdk-dev] [PATCH 2/4] examples/performance-thread: add fall-through comments

2017-06-02 Thread Jerin Jacob

This fixes compiler warnings with GCC 7.1.1

Fixes: d48415e1fee3 ("examples/performance-thread: add l3fwd-thread app")
Signed-off-by: Jerin Jacob 
---
 examples/performance-thread/l3fwd-thread/main.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/examples/performance-thread/l3fwd-thread/main.c 
b/examples/performance-thread/l3fwd-thread/main.c
index 2d98473eb..ac85a369f 100644
--- a/examples/performance-thread/l3fwd-thread/main.c
+++ b/examples/performance-thread/l3fwd-thread/main.c
@@ -761,12 +761,15 @@ send_packetsx4(uint8_t port,
case 0:
qconf->tx_mbufs[port].m_table[len + j] = m[j];
j++;
+   /* fall-through */
case 3:
qconf->tx_mbufs[port].m_table[len + j] = m[j];
j++;
+   /* fall-through */
case 2:
qconf->tx_mbufs[port].m_table[len + j] = m[j];
j++;
+   /* fall-through */
case 1:
qconf->tx_mbufs[port].m_table[len + j] = m[j];
j++;
@@ -788,12 +791,15 @@ send_packetsx4(uint8_t port,
case 0:
qconf->tx_mbufs[port].m_table[j] = m[n + j];
j++;
+   /* fall-through */
case 3:
qconf->tx_mbufs[port].m_table[j] = m[n + j];
j++;
+   /* fall-through */
case 2:
qconf->tx_mbufs[port].m_table[j] = m[n + j];
j++;
+   /* fall-through */
case 1:
qconf->tx_mbufs[port].m_table[j] = m[n + j];
j++;
@@ -1860,10 +1866,12 @@ process_burst(struct rte_mbuf 
*pkts_burst[MAX_PKT_BURST], int nb_rx,
process_packet(pkts_burst[j], dst_port + j, portid);
GROUP_PORT_STEP(dlp, dst_port, lp, pnum, j);
j++;
+   /* fall-through */
case 2:
process_packet(pkts_burst[j], dst_port + j, portid);
GROUP_PORT_STEP(dlp, dst_port, lp, pnum, j);
j++;
+   /* fall-through */
case 1:
process_packet(pkts_burst[j], dst_port + j, portid);
GROUP_PORT_STEP(dlp, dst_port, lp, pnum, j);
-- 
2.13.0

[dpdk-dev] [PATCH 4/4] examples/vhost: fix uninitialized desc indexes

2017-06-02 Thread Jerin Jacob

Fixing the below error by returning from the function early
when count == 0.

Issue flagged by GCC 7.1.1

examples/vhost/virtio_net.c:370:38: error: ‘desc_indexes[0]’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
  rte_prefetch0(&vr->desc[desc_indexes[0]]);

Fixes: ca059fa5e290 ("examples/vhost: demonstrate the new generic APIs")

Cc: sta...@dpdk.org
Signed-off-by: Jerin Jacob 
---
 examples/vhost/virtio_net.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/examples/vhost/virtio_net.c b/examples/vhost/virtio_net.c
index cc2c3d882..5e1ed44a5 100644
--- a/examples/vhost/virtio_net.c
+++ b/examples/vhost/virtio_net.c
@@ -350,6 +350,9 @@ vs_dequeue_pkts(struct vhost_dev *dev, uint16_t queue_id,
count = RTE_MIN(count, MAX_PKT_BURST);
count = RTE_MIN(count, free_entries);
 
+   if (unlikely(count == 0))
+   return 0;
+
/*
 * Retrieve all of the head indexes first and pre-update used entries
 * to avoid caching issues.
@@ -385,8 +388,6 @@ vs_dequeue_pkts(struct vhost_dev *dev, uint16_t queue_id,
}
 
}
-   if (!i)
-   return 0;
 
queue->last_avail_idx += i;
queue->last_used_idx += i;
-- 
2.13.0

[dpdk-dev] [PATCH 3/4] examples/qos_sched: suppress GCC 7.1.1 warnings

2017-06-02 Thread Jerin Jacob

This one is more of a compiler issue as application
checks the app_parse_opt_vals() return value.

Since this code is in slow path, adding a memset
to fix following "maybe-uninitialized" warning.

qos_sched/args.c: In function ‘app_parse_args’:
examples/qos_sched/args.c:254:32: error: ‘vals[0]’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
pconf->rx_port = (uint8_t)vals[0];
^~~
Signed-off-by: Jerin Jacob 
---
 examples/qos_sched/args.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c
index 476a0ee1c..2350d64f4 100644
--- a/examples/qos_sched/args.c
+++ b/examples/qos_sched/args.c
@@ -245,6 +245,7 @@ app_parse_flow_conf(const char *conf_str)
struct flow_conf *pconf;
uint64_t mask;
 
+   memset(vals, 0, sizeof(vals));
ret = app_parse_opt_vals(conf_str, ',', 6, vals);
if (ret < 4 || ret > 5)
return ret;
-- 
2.13.0

Re: [dpdk-dev] [PATCH 31/33] doc/testeventdev: add "perf queue" test details

2017-06-02 Thread Jerin Jacob

-Original Message-
> Date: Thu, 1 Jun 2017 21:11:29 +
> From: "Eads, Gage" 
> To: Jerin Jacob , "dev@dpdk.org"
>  
> CC: "Richardson, Bruce" , "Van Haaren, Harry"
>  , "hemant.agra...@nxp.com"
>  , "nipun.gu...@nxp.com" ,
>  "Vangati, Narender" , "Rao, Nikhil"
>  , "gprathyu...@caviumnetworks.com"
>  , "Mcnamara, John"
>  
> Subject: RE: [dpdk-dev] [PATCH 31/33] doc/testeventdev: add "perf queue"
>  test details
> 
> 
> 
> >  diff --git a/doc/guides/tools/testeventdev.rst
> >  b/doc/guides/tools/testeventdev.rst
> >  index 02b7a8a57..b895b2d2b 100644
> >  --- a/doc/guides/tools/testeventdev.rst
> >  +++ b/doc/guides/tools/testeventdev.rst
> >  @@ -297,4 +297,90 @@ Example command to run order ``all types queue``
> >  test:
> >  sudo build/app/dpdk-test-eventdev --vdev=event_octeontx -- --
> >  test=order_atq --plcore 1 --wlcores 2,3
> >  
> >  
> >  +PERF_QUEUE Test
> >  +~~~
> >  +
> >  +This is a performance test case that aims at testing the following:
> >  +
> >  +#. Measure the number of events can be processed in a second.
> >  +#. Measure the latency to forward an event.
> >  +
> >  +.. _table_eventdev_perf_queue_test:
> >  +
> >  +.. table:: Perf queue test eventdev configuration.
> >  +
> >  +   
> > +---+--++-+
> >  +   | # | Items| Value  | Comments 
> >|
> >  +   |   |  ||  
> >|
> >  +
> >  +===+==++===
> >  ==+
> >  +   | 1 | nb_queues| nb_producers * | Queues will be configured based 
> > on
> >  the  |
> >  +   |   |  | nb_stages  | user requested sched type 
> > list(--stlist)|
> >  +   
> > +---+--++-+
> >  +   | 2 | nb_producers | >= 1   | Selected through --plcores 
> > command line |
> >  +   |   |  || argument.
> >|
> >  +   
> > +---+--++-+
> >  +   | 3 | nb_workers   | >= 1   | Selected through --wlcores 
> > command line |
> >  +   |   |  || argument 
> >|
> >  +   
> > +---+--++-+
> >  +   | 4 | nb_ports | nb_workers +   | Workers use port 0 to port w.
> >|
> >  +   |   |  | nb_producers   | Producers use port w to port p   
> >|
> >  +   
> > +---+--++-+
> 
> Just a suggestion: consider changing 'w' (i.e. "Workers use port 0 to port 
> w") to'n', or vice versa, so the text matches the diagram. Applies to 
> perf_atq as well.

Sure.

Re: [dpdk-dev] [PATCH 25/33] app/testeventdev: perf queue: add worker functions

2017-06-02 Thread Jerin Jacob

-Original Message-
> Date: Thu, 1 Jun 2017 21:04:15 +
> From: "Eads, Gage" 
> To: Jerin Jacob , "dev@dpdk.org"
>  
> CC: "Richardson, Bruce" , "Van Haaren, Harry"
>  , "hemant.agra...@nxp.com"
>  , "nipun.gu...@nxp.com" ,
>  "Vangati, Narender" , "Rao, Nikhil"
>  , "gprathyu...@caviumnetworks.com"
>  
> Subject: RE: [dpdk-dev] [PATCH 25/33] app/testeventdev: perf queue: add
>  worker functions
> 
> 
> 
> >  -Original Message-
> >  From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> >  Sent: Sunday, May 28, 2017 2:59 PM
> >  To: dev@dpdk.org
> >  Cc: Richardson, Bruce ; Van Haaren, Harry
> >  ; hemant.agra...@nxp.com; Eads, Gage
> >  ; nipun.gu...@nxp.com; Vangati, Narender
> >  ; Rao, Nikhil ;
> >  gprathyu...@caviumnetworks.com; Jerin Jacob
> >  
> >  Subject: [dpdk-dev] [PATCH 25/33] app/testeventdev: perf queue: add worker
> >  functions
> >  
> >  Signed-off-by: Jerin Jacob 
> >  ---
> >   app/test-eventdev/test_perf_common.h |  60 +++  app/test-
> >  eventdev/test_perf_queue.c  | 137 +++
> >   2 files changed, 197 insertions(+)
> >  
> >  diff --git a/app/test-eventdev/test_perf_common.h b/app/test-
> >  eventdev/test_perf_common.h
> >  index f8246953a..9888e5078 100644
> >  --- a/app/test-eventdev/test_perf_common.h
> >  +++ b/app/test-eventdev/test_perf_common.h
> >  @@ -86,6 +86,66 @@ struct perf_elt {
> > uint64_t timestamp;
> >   } __rte_cache_aligned;
> >  
> >  +#define BURST_SIZE 16
> >  +
> >  +#define PERF_WORKER_INIT\
> >  +  struct worker_data *w  = arg;\
> >  +  struct test_perf *t = w->t;\
> >  +  struct evt_options *opt = t->opt;\
> >  +  const uint8_t dev = w->dev_id;\
> >  +  const uint8_t port = w->port_id;\
> >  +  uint8_t *const sched_type_list = &t->sched_type_list[0];\
> >  +  struct rte_mempool *const pool = t->pool;\
> >  +  const uint8_t nb_stages = t->opt->nb_stages;\
> >  +  const uint8_t laststage = nb_stages - 1;\
> >  +  uint8_t cnt = 0;\
> >  +  void *bufs[16] __rte_cache_aligned;\
> >  +  int const sz = RTE_DIM(bufs);\
> >  +  if (opt->verbose_level > 1)\
> >  +  printf("%s(): lcore %d dev_id %d port=%d\n", __func__,\
> >  +  rte_lcore_id(), dev, port)
> >  +
> >  +static inline __attribute__((always_inline)) int
> >  +perf_process_last_stage(struct rte_mempool *const pool,
> >  +  struct rte_event *const ev, struct worker_data *const w,
> >  +  void *bufs[], int const buf_sz, uint8_t count) {
> >  +  bufs[count++] = ev->event_ptr;
> >  +  w->processed_pkts++;
> >  +  rte_smp_wmb();
> >  +
> >  +  if (unlikely(count == buf_sz)) {
> >  +  count = 0;
> >  +  rte_mempool_put_bulk(pool, bufs, buf_sz);
> >  +  }
> >  +  return count;
> >  +}
> >  +
> >  +static inline __attribute__((always_inline)) uint8_t
> >  +perf_process_last_stage_latency(struct rte_mempool *const pool,
> >  +  struct rte_event *const ev, struct worker_data *const w,
> >  +  void *bufs[], int const buf_sz, uint8_t count) {
> >  +  uint64_t latency;
> >  +  struct perf_elt *const m = ev->event_ptr;
> >  +
> >  +  bufs[count++] = ev->event_ptr;
> >  +  w->processed_pkts++;
> >  +
> >  +  if (unlikely(count == buf_sz)) {
> >  +  count = 0;
> >  +  latency = rte_get_timer_cycles() - m->timestamp;
> >  +  rte_mempool_put_bulk(pool, bufs, buf_sz);
> >  +  } else {
> >  +  latency = rte_get_timer_cycles() - m->timestamp;
> >  +  }
> >  +
> >  +  w->latency += latency;
> >  +  rte_smp_wmb();
> >  +  return count;
> >  +}
> 
> What purpose does the store barrier serve in these two functions?

The master core(!worker core) reads w->latency and
w->processed_pkts periodically from all workers.

[dpdk-dev] [PATCH] maintainers: update email address

2017-06-02 Thread Yuanhan Liu

Signed-off-by: Yuanhan Liu 
---

- I left Intel today.

---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index afb4cab..f6095ef 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -424,7 +424,7 @@ F: doc/guides/nics/vmxnet3.rst
 F: doc/guides/nics/features/vmxnet3.ini
 
 Vhost-user
-M: Yuanhan Liu 
+M: Yuanhan Liu 
 M: Maxime Coquelin 
 T: git://dpdk.org/next/dpdk-next-virtio
 F: lib/librte_vhost/
@@ -434,14 +434,14 @@ F: doc/guides/sample_app_ug/vhost.rst
 
 Vhost PMD
 M: Tetsuya Mukawa 
-M: Yuanhan Liu 
+M: Yuanhan Liu 
 M: Maxime Coquelin 
 T: git://dpdk.org/next/dpdk-next-virtio
 F: drivers/net/vhost/
 F: doc/guides/nics/features/vhost.ini
 
 Virtio PMD
-M: Yuanhan Liu 
+M: Yuanhan Liu 
 M: Maxime Coquelin 
 T: git://dpdk.org/next/dpdk-next-virtio
 F: drivers/net/virtio/
-- 
2.7.4

[dpdk-dev] [PATCH v1] ring: fix return value for sc and mc dequeue

2017-06-02 Thread Anand B Jyoti

The error return code for rte_ring_sc_dequeue_bulk() and
rte_ring_mc_dequeue_bulk() function should be -ENOENT rather
than -ENOBUFS as described in the function description.

Signed-off-by: Anand B Jyoti 
---
 lib/librte_ring/rte_ring.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 97f025a..3400ed8 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -801,7 +801,7 @@ rte_ring_dequeue_bulk(struct rte_ring *r, void **obj_table, 
unsigned int n,
 static inline int __attribute__((always_inline))
 rte_ring_mc_dequeue(struct rte_ring *r, void **obj_p)
 {
-   return rte_ring_mc_dequeue_bulk(r, obj_p, 1, NULL)  ? 0 : -ENOBUFS;
+   return rte_ring_mc_dequeue_bulk(r, obj_p, 1, NULL)  ? 0 : -ENOENT;
 }
 
 /**
@@ -819,7 +819,7 @@ rte_ring_mc_dequeue(struct rte_ring *r, void **obj_p)
 static inline int __attribute__((always_inline))
 rte_ring_sc_dequeue(struct rte_ring *r, void **obj_p)
 {
-   return rte_ring_sc_dequeue_bulk(r, obj_p, 1, NULL) ? 0 : -ENOBUFS;
+   return rte_ring_sc_dequeue_bulk(r, obj_p, 1, NULL) ? 0 : -ENOENT;
 }
 
 /**
-- 
2.7.4

Re: [dpdk-dev] [PATCH] vhost: fix crash on NUMA

2017-06-02 Thread Loftus, Ciara

> The queue allocation was changed, from allocating one queue-pair at a
> time to one queue at a time. Most of the changes have been done, but
> just with one being missed: the size of coping the old queue is still
> based on queue-pair at numa_realloc(), which leads to overwritten issue.
> As a result, crash may happen.
> 
> Fix it by specifying the right copy size. Also, the net queue macros
> are not used any more. Remove them.
> 
> Fixes: ab4d7b9f1afc ("vhost: turn queue pair to vring")
> 
> Cc: sta...@dpdk.org
> Reported-by: Ciara Loftus 
> Signed-off-by: Yuanhan Liu 

Tested-by: Ciara Loftus 

> ---
>  lib/librte_vhost/vhost_user.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> index 5c8058b..e486b78 100644
> --- a/lib/librte_vhost/vhost_user.c
> +++ b/lib/librte_vhost/vhost_user.c
> @@ -238,8 +238,6 @@ numa_realloc(struct virtio_net *dev, int index)
>   struct vhost_virtqueue *old_vq, *vq;
>   int ret;
> 
> - enum {VIRTIO_RXQ, VIRTIO_TXQ, VIRTIO_QNUM};
> -
>   old_dev = dev;
>   vq = old_vq = dev->virtqueue[index];
> 
> @@ -261,7 +259,7 @@ numa_realloc(struct virtio_net *dev, int index)
>   if (!vq)
>   return dev;
> 
> - memcpy(vq, old_vq, sizeof(*vq) * VIRTIO_QNUM);
> + memcpy(vq, old_vq, sizeof(*vq));
>   rte_free(old_vq);
>   }
> 
> --
> 2.8.1

Re: [dpdk-dev] [PATCH] eventdev: define the default value for dequeue timeout

2017-06-02 Thread Jerin Jacob

-Original Message-
> Date: Thu, 18 May 2017 19:45:44 +0530
> From: Hemant Agrawal 
> To: Jerin Jacob , dev@dpdk.org
> CC: bruce.richard...@intel.com, harry.van.haa...@intel.com,
>  gage.e...@intel.com, nipun.gu...@nxp.com, narender.vang...@intel.com
> Subject: Re: [PATCH] eventdev: define the default value for dequeue timeout
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
>  Thunderbird/45.8.0
> 
> On 5/18/2017 2:18 PM, Jerin Jacob wrote:
> > Defining the value 0 as default value for dequeue timeout
> > will help the application reduce the configuration setup
> > if the application is interested only in default
> > timeout value.
> > 
> > Signed-off-by: Jerin Jacob 
> > ---
> > This patch will fix following error found in the event_pipeline RFC 
> > application
> > http://dpdk.org/dev/patchwork/patch/23799/ with event_octeontx HW driver.
> > 
> > EVENTDEV: rte_event_dev_configure() line 379: dev0 invalid
> > dequeue_timeout_ns=0 min_dequeue_timeout_ns=853 
> > max_dequeue_timeout_ns=873813
> > ---
> >  drivers/event/octeontx/ssovf_evdev.c | 2 ++
> >  lib/librte_eventdev/rte_eventdev.c   | 5 +++--
> >  lib/librte_eventdev/rte_eventdev.h   | 1 +
> >  3 files changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/event/octeontx/ssovf_evdev.c 
> > b/drivers/event/octeontx/ssovf_evdev.c
> > index c80a44379..5499b1bf7 100644
> > --- a/drivers/event/octeontx/ssovf_evdev.c
> > +++ b/drivers/event/octeontx/ssovf_evdev.c
> > @@ -194,6 +194,8 @@ ssovf_configure(const struct rte_eventdev *dev)
> > 
> > ssovf_func_trace();
> > deq_tmo_ns = conf->dequeue_timeout_ns;
> > +   if (deq_tmo_ns == 0)
> > +   deq_tmo_ns = edev->min_deq_timeout_ns;
> 
> '0' should mean don't wait?

Yes. I think, we can leave that to the driver for the minimum supported
dequeue timeout for the given platform(PMD). OCTEONTX PMD needs
different treatment for "no-wait" case, hence setting the minimum value
that PMD supports.

Any other comments on API change?


> 
> > 
> > if (conf->event_dev_cfg & RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT) {
> > edev->is_timeout_deq = 1;
> > diff --git a/lib/librte_eventdev/rte_eventdev.c 
> > b/lib/librte_eventdev/rte_eventdev.c
> > index 20afc3f0e..8cafffe03 100644
> > --- a/lib/librte_eventdev/rte_eventdev.c
> > +++ b/lib/librte_eventdev/rte_eventdev.c
> > @@ -369,9 +369,10 @@ rte_event_dev_configure(uint8_t dev_id,
> > 
> > /* Check dequeue_timeout_ns value is in limit */
> > if (!(dev_conf->event_dev_cfg & RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT)) 
> > {
> > -   if (dev_conf->dequeue_timeout_ns < info.min_dequeue_timeout_ns
> > +   if (dev_conf->dequeue_timeout_ns &&
> > +   (dev_conf->dequeue_timeout_ns < info.min_dequeue_timeout_ns
> > || dev_conf->dequeue_timeout_ns >
> > -info.max_dequeue_timeout_ns) {
> > +info.max_dequeue_timeout_ns)) {
> > RTE_EDEV_LOG_ERR("dev%d invalid dequeue_timeout_ns=%d"
> > " min_dequeue_timeout_ns=%d max_dequeue_timeout_ns=%d",
> > dev_id, dev_conf->dequeue_timeout_ns,
> > diff --git a/lib/librte_eventdev/rte_eventdev.h 
> > b/lib/librte_eventdev/rte_eventdev.h
> > index 94284337d..f39fbc6b9 100644
> > --- a/lib/librte_eventdev/rte_eventdev.h
> > +++ b/lib/librte_eventdev/rte_eventdev.h
> > @@ -409,6 +409,7 @@ struct rte_event_dev_config {
> >  * This value should be in the range of *min_dequeue_timeout_ns* and
> >  * *max_dequeue_timeout_ns* which previously provided in
> >  * rte_event_dev_info_get()
> > +* The value 0 is allowed, in which case, default dequeue timeout used.
> >  * @see RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT
> >  */
> > int32_t nb_events_limit;
> > 
> 
>

Re: [dpdk-dev] [PATCH] maintainers: update email address

2017-06-02 Thread Thomas Monjalon

02/06/2017 15:34, Yuanhan Liu:
> Signed-off-by: Yuanhan Liu 
> ---
> 
> - I left Intel today.
> 
> ---
>  MAINTAINERS | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Applied, thanks and good luck in your new job :)

Re: [dpdk-dev] [RFC] proposal of allowing personal/project repos on DPDK.org

2017-06-02 Thread Thomas Monjalon

01/06/2017 07:07, Tiwei Bie:
> Hello everyone,
> 
> We'd like to make a proposal of making DPDK.org allow hosting
> some personal/project repos, which could be very useful when
> someone wants to try some experimental projects in DPDK. Many
> formal/mature opensource communities allow this. Such as:
[...]

So you are asking for a forge.
It requires some maintenance effort.

> But currently on DPDK.org, for the repos of DPDK, besides the main
> repo, there are just one repo for stable release, few old repos
> which are obsoleted, and some "-next" repos which are mainly used
> as the preparation of pull requests for different subsystems of DPDK.

Yes they are the official DPDK repos.

> Some “-next” repos may be developed individually for a short time
> when they are created, but will always be merged to the main repo
> after few releases. We think they are too formal/limited to try
> new ideas.

Why? Do you need to host a repo on dpdk.org to try a new idea?

> What we want to proposal is to make DPDK.org allow hosting some
> DPDK based repos which may be very experimental, which even not
> be planned to be merged back to the main repo directly, and may
> be deleted directly if it proves that no one really cares about
> it. Just like what other opensource communities did, allow some
> core developers/vendors create their own repos and try ideas on
> DPDK.org without too many restrictions. We think it can provide
> people a very convenient way to try ideas in DPDK community and
> eventually help DPDK grow.
> 
> Allowing it won't have any negative impact on the existing repos
> of DPDK, instead, it can help to keep them tidy and clean when
> someone wants/needs to try some very experimental and big ideas
> publicly in DPDK as he/she can start it in an experimental repo.
> An experimental repo can be merged back to the main repo when it
> proves to be mature and useful, or could just be deleted when no
> one really cares about it any more.
> 
> Please share your thoughts on this. Many thanks! :-)

I am against adding some user repos in this list:
http://dpdk.org/browse/
I think the list of official repos must be kept light for good visibility.

But we can imagine a forge for users at a different location like
http://dpdk.org/users/
However why not using another public forge for this need?

[dpdk-dev] [RFCv2] service core concept

2017-06-02 Thread Van Haaren, Harry

> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Van Haaren, Harry
> Sent: Thursday, May 25, 2017 2:28 PM
> Subject: Re: [dpdk-dev] [RFC] service core concept header implementation
> 
> Thanks everybody for the input on the RFC - appreciated! From an application 
> point-of-view, I
> see merit in Konstantin's suggestions for the API, over the RFC I sent 
> previously. I will re-
> work the API taking inspiration from both APIs and send an RFCv2, you'll be 
> on CC :)


Hi All,

This email is the v2 RFC for Service Cores, in response to the v1 sent 
previously[1].
The service-cores API has been updated, and various concepts have changed.

The API has been redesigned, with Konstantin's API suggestions as a base, and 
the
other comments taken into account. In my opinion this v2 API is more 
application-centric,
and enables the common application tasks much better. Such tasks are for 
example start/stop
of a service, and add/remove of a service core.

In particular this version of the API enables applications that are not aware 
of services to
benefit from the services concept, as EAL args can be used to setup services 
and service cores.
With this design, switching to/from SW/HW PMD is transparent to the 
application. An example
use-case is the Eventdev HW PMD to Eventdev SW PMD that requires a service 
core. 

I have noted the implementation comments that were raised on the v1. For v2, I 
think our time
is better spent looking at the API design, and I will handle implementation 
feedback in the
follow-up patchset to v2 RFC.

Below a summary of what we are trying to achieve, and the current API design.
Have a good weekend! Cheers, -Harry


Summary of goals (summarized from a previous email)
1. Allowing libraries and drivers to register the fact that they require 
background processing
2. Providing support for easily multiplexing these independent functions from 
different libs onto a different core
3. Providing support for the application to configure the running of these 
background services on specific cores
4. Once configured, hiding these services and the cores they run on from the 
rest of the application,
   so that the rest of the app logic does not need to change depending on 
whether service cores are in use or not


=== RFC v2 API ===

There are 3 parts to the API; they separate the concerns of each "user" of the 
API:
- Service Registration
- Service Config
- ServiceCore Config

Service Registration: 
A service requires a core. It only knows about its NUMA node, and that it 
requires CPU time.
Registration of a service requires only that information.

Service Config:
An application may configure what service runs where using the Service Config 
APIs.
EAL is capable of performing this during rte_eal_init() if requested by passing 
a
--service-cores argument. The application (mostly) calls these functions at 
initialization
time, with start() and stop() being available to dynamically switch on/off a 
service if required.

ServiceCore Config
An application can start/stop or add/remove service-lcores using the 
ServiceCore Config, allowing
dynamically scaling the number of used lcores by services. Lcores used as 
service-cores are removed
from the application coremask, and are not available to remote_launch() as they 
are already in use.


Service Registration:
int32_t rte_service_register(const struct rte_service_spec *spec);
int32_t rte_service_unregister(struct rte_service_spec *service);

Service Configuration:
uint32_t rte_service_get_count(void);
struct rte_service_spec *rte_service_get_by_id(uint32_t id);
const char *rte_service_get_name(const struct rte_service_spec *service);
int32_t rte_service_set_coremask(struct rte_service_spec *service, const 
rte_cpuset_t *coremask);
int32_t rte_service_start(struct rte_service_spec *service); /* runtime 
function */
int32_t rte_service_stop(struct rte_service_spec *service);  /* runtime 
function */

ServiceCore Configuration:
int32_t rte_service_cores_start(void);
int32_t rte_service_cores_stop(void);
int32_t rte_service_cores_add(const rte_cpuset_t *coremask);
int32_t rte_service_cores_del(const rte_cpuset_t *coremask);


I am working on a patchset - but for now I would appreciate general design 
feedback,
particularly if a specific use-case is not handled.

Re: [dpdk-dev] 2nd try: problem with ixgbe_dev_link_update() for multi-speed fiber [was] Re: [PATCH v4] net/ixgbe: ensure link status is updated

2017-06-02 Thread Roger B. Melton


Hi Wei,

Have you had a chance to look at the debug output yet?  Is there any 
additional data you need?


Regards,
Roger


On 5/24/17 2:38 PM, Roger B. Melton wrote:

Hi Wei,

I am using ixgbe:

00:02.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit 
SFI/SFP+ Network Connection (rev 01)


The debug output you requested is below showing the results for both 
far end link up and far end link down.  In the case of far end link 
up, the elapse time is too small for the granularity of my logging 
system.  In the case when the far end link is down, the elapsed time 
for rte_eth_link_get_nowait() is ~1.4 seconds.  You can really see 
those 40 and 100msec delays add up when the link is down.


Let me know if you require more information.

Regards,
Roger


Far end link up:

2017/05/24 18:15:14.353 [ulord-dp]: [3706]:  UUID: 0, ra: 0 (debug): 
rmeltonDBG Start rte_eth_link_get_nowait()


2017/05/24 18:15:14.353 [ulord-dp]: [3706]:  UUID: 0, ra: 0 (debug): 
PMD: ixgbe_check_mac_link_generic(): ixgbe_check_mac_link_generic


2017/05/24 18:15:14.353 [ulord-dp]: [3706]:  UUID: 0, ra: 0 (debug): 
rmeltonDBG :End rte_eth_link_get_nowait()



Far end link down:


2017/05/24 18:15:38.502 (debug): rmeltonDBG: Start 
rte_eth_link_get_nowait()


2017/05/24 18:15:38.502 (debug): PMD: ixgbe_get_media_type_82599(): 
ixgbe_get_media_type_82599
2017/05/24 18:15:38.502 (debug): PMD: 
ixgbe_setup_mac_link_multispeed_fiber(): 
ixgbe_setup_mac_link_multispeed_fiber
2017/05/24 18:15:38.502 (debug): PMD: 
ixgbe_get_link_capabilities_82599(): ixgbe_get_link_capabilities_82599
2017/05/24 18:15:38.542 (debug): PMD: ixgbe_setup_mac_link_82599(): 
ixgbe_setup_mac_link_82599
2017/05/24 18:15:38.542 (debug): PMD: 
ixgbe_get_link_capabilities_82599(): ixgbe_get_link_capabilities_82599
2017/05/24 18:15:38.542 (debug): PMD: 
ixgbe_flap_tx_laser_multispeed_fiber(): 
ixgbe_flap_tx_laser_multispeed_fiber
2017/05/24 18:15:38.542 (debug): PMD: ixgbe_check_reset_blocked(): 
ixgbe_check_reset_blocked
2017/05/24 18:15:38.643 (debug): PMD: ixgbe_check_mac_link_generic(): 
ixgbe_check_mac_link_generic
2017/05/24 18:15:38.743 (debug): PMD: ixgbe_check_mac_link_generic(): 
ixgbe_check_mac_link_generic
2017/05/24 18:15:38.843 (debug): PMD: ixgbe_check_mac_link_generic(): 
ixgbe_check_mac_link_generic
2017/05/24 18:15:38.943 (debug): PMD: ixgbe_check_mac_link_generic(): 
ixgbe_check_mac_link_generic
2017/05/24 18:15:39.043 (debug): PMD: ixgbe_check_mac_link_generic(): 
ixgbe_check_mac_link_generic
2017/05/24 18:15:39.083 (debug): PMD: ixgbe_setup_mac_link_82599(): 
ixgbe_setup_mac_link_82599
2017/05/24 18:15:39.083 (debug): PMD: 
ixgbe_get_link_capabilities_82599(): ixgbe_get_link_capabilities_82599
2017/05/24 18:15:39.083 (debug): PMD: ixgbe_check_reset_blocked(): 
ixgbe_check_reset_blocked
2017/05/24 18:15:39.083 (debug): PMD: 
ixgbe_verify_lesm_fw_enabled_82599(): ixgbe_verify_lesm_fw_enabled_82599
2017/05/24 18:15:39.083 (debug): PMD: ixgbe_read_eeprom_82599(): 
ixgbe_read_eeprom_82599
2017/05/24 18:15:39.083 (debug): PMD: 
ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic
2017/05/24 18:15:39.083 (debug): PMD: 
ixgbe_init_eeprom_params_generic(): ixgbe_init_eeprom_params_generic
2017/05/24 18:15:39.083 (debug): PMD: ixgbe_poll_eerd_eewr_done(): 
ixgbe_poll_eerd_eewr_done
2017/05/24 18:15:39.083 (debug): PMD: ixgbe_read_eeprom_82599(): 
ixgbe_read_eeprom_82599
2017/05/24 18:15:39.083 (debug): PMD: 
ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic
2017/05/24 18:15:39.083 (debug): PMD: 
ixgbe_init_eeprom_params_generic(): ixgbe_init_eeprom_params_generic
2017/05/24 18:15:39.083 (debug): PMD: ixgbe_poll_eerd_eewr_done(): 
ixgbe_poll_eerd_eewr_done
2017/05/24 18:15:39.165 (debug): PMD: 
ixgbe_flap_tx_laser_multispeed_fiber(): 
ixgbe_flap_tx_laser_multispeed_fiber
2017/05/24 18:15:39.165 (debug): PMD: ixgbe_check_reset_blocked(): 
ixgbe_check_reset_blocked
2017/05/24 18:15:39.265 (debug): PMD: ixgbe_check_mac_link_generic(): 
ixgbe_check_mac_link_generic
2017/05/24 18:15:39.265 (debug): PMD: 
ixgbe_setup_mac_link_multispeed_fiber(): 
ixgbe_setup_mac_link_multispeed_fiber
2017/05/24 18:15:39.265 (debug): PMD: 
ixgbe_get_link_capabilities_82599(): ixgbe_get_link_capabilities_82599
2017/05/24 18:15:39.305 (debug): PMD: ixgbe_setup_mac_link_82599(): 
ixgbe_setup_mac_link_82599
2017/05/24 18:15:39.305 (debug): PMD: 
ixgbe_get_link_capabilities_82599(): ixgbe_get_link_capabilities_82599
2017/05/24 18:15:39.305 (debug): PMD: ixgbe_check_reset_blocked(): 
ixgbe_check_reset_blocked
2017/05/24 18:15:39.305 (debug): PMD: 
ixgbe_verify_lesm_fw_enabled_82599(): ixgbe_verify_lesm_fw_enabled_82599
2017/05/24 18:15:39.305 (debug): PMD: ixgbe_read_eeprom_82599(): 
ixgbe_read_eeprom_82599
2017/05/24 18:15:39.305 (debug): PMD: 
ixgbe_read_eerd_buffer_generic(): ixgbe_read_eerd_buffer_generic
2017/05/24 18:15:39.305 (debug): PMD: 
ixgbe_init_eeprom_params_generic(): ixgbe_init_eeprom_params_generic
2017/05/24 18:15:39.305 (debug): PMD: ixg

[dpdk-dev] [PATCH] eal: fix secondary process segfault on multipe virtio devices

2017-06-02 Thread Jianfeng Tan

Suppose we have 2 virtio devices for a VM, with only the first one,
virtio0, binding to igb_uio. Start a primary DPDK process, driving
only virtio0. Then start a secondary DPDK process, it encounters
segfault at eth_virtio_dev_init() because hw is NULL, when trying
to initialize the 2nd virtio devices.
1539if (!hw->virtio_user_dev) {

We could add a precheck to return error when hw is NULL. But the
root cause is that virtio devices which are not driven by the primary
process are not exluded by secondary eal probe function.

To support legacy virtio devices bound to none kernel driver, we
removed RTE_PCI_DRV_NEED_MAPPING in
commit 962cf902e6eb ("pci: export device mapping functions").
At the boot of primary process, ether dev is allocated in rte_eth_devices
array, rte_eth_dev_data is also allocated in rte_eth_dev_data array; then
probe function fails; and ether dev is released. However, the entry in
rte_eth_dev_data array is not cleared. Then we start secondary process,
and try to attach the virtio device that not used in primary process,
the field, dev_private (or hw), in rte_eth_dev_data, is NULL.

To fail the dev attach, we need to clear the field, name, when we
release any ether devices in primary, so that below loop in
rte_eth_dev_attach_secondary() will not find any matched names.
for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
if (strcmp(rte_eth_dev_data[i].name, name) == 0)
break;
}

Fixes: 6d890f8ab512 ("Fixes: net/virtio: fix multiple process support")

Reported-by: Reshma Pattan 
Signed-off-by: Jianfeng Tan 
---
 lib/librte_ether/rte_ethdev_pci.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev_pci.h 
b/lib/librte_ether/rte_ethdev_pci.h
index d3bc03c..025700d 100644
--- a/lib/librte_ether/rte_ethdev_pci.h
+++ b/lib/librte_ether/rte_ethdev_pci.h
@@ -134,6 +134,11 @@ rte_eth_dev_pci_release(struct rte_eth_dev *eth_dev)
 
eth_dev->data->dev_private = NULL;
 
+   /* Secondary process will use this field, name, for secondary attach,
+* clear this field to avoid attaching any released ports in primary.
+*/
+   memset(eth_dev->data->name, 0, RTE_ETH_NAME_MAX_LEN);
+
eth_dev->device = NULL;
eth_dev->intr_handle = NULL;
 }
-- 
2.7.4

[dpdk-dev] [PATCH] mk: disable new gcc truncation flag

2017-06-02 Thread Nirmoy Das

disable truncation check to ignore below warning
dpdk/x86_64-native-linuxapp-gcc-default/build/lib/librte_eal/linuxapp/kni/igb_main.c:2476:30:
 error: '%d' directive output may be truncated writing between 1 and 5 bytes 
into a region of size between 0 and 11 [-Werror=format-truncation=]

Signed-off-by: Nirmoy Das 
---
 lib/librte_eal/linuxapp/kni/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/librte_eal/linuxapp/kni/Makefile 
b/lib/librte_eal/linuxapp/kni/Makefile
index 154c528db..79bb498dd 100644
--- a/lib/librte_eal/linuxapp/kni/Makefile
+++ b/lib/librte_eal/linuxapp/kni/Makefile
@@ -43,6 +43,9 @@ MODULE_CFLAGS += -I$(SRCDIR) --param 
max-inline-insns-single=50
 MODULE_CFLAGS += -I$(RTE_OUTPUT)/include -I$(SRCDIR)/ethtool/ixgbe 
-I$(SRCDIR)/ethtool/igb
 MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h
 MODULE_CFLAGS += -Wall -Werror
+ifeq ($(shell test $(GCC_VERSION) -ge 70 && echo 1), 1)
+MODULE_CFLAGS += -Wno-format-truncation
+endif
 
 -include /etc/lsb-release
 
-- 
2.12.2

Re: [dpdk-dev] [PATCH] mk: disable new gcc truncation flag

2017-06-02 Thread Markos Chandras

On 06/02/2017 05:31 PM, Nirmoy Das wrote:
> disable truncation check to ignore below warning
> dpdk/x86_64-native-linuxapp-gcc-default/build/lib/librte_eal/linuxapp/kni/igb_main.c:2476:30:
>  error: '%d' directive output may be truncated writing between 1 and 5 bytes 
> into a region of size between 0 and 11 [-Werror=format-truncation=]
> 
> Signed-off-by: Nirmoy Das 
> ---

I haven't check the code but is this a bogus warning or a real one? If
it's bogus then could you explain why in the commit message so we do not
bring it back in the future? If it's a real problem, then perhaps worth
fixing it instead of masking it?

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

Re: [dpdk-dev] [PATCH 3/4] examples/qos_sched: suppress GCC 7.1.1 warnings

2017-06-02 Thread Dumitrescu, Cristian



> -Original Message-
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Friday, June 2, 2017 12:21 PM
> To: dev@dpdk.org
> Cc: Richardson, Bruce ;
> tho...@monjalon.net; Dumitrescu, Cristian
> ; yuanhan@linux.intel.com;
> maxime.coque...@redhat.com; Jerin Jacob
> 
> Subject: [dpdk-dev] [PATCH 3/4] examples/qos_sched: suppress GCC 7.1.1
> warnings
> 
> This one is more of a compiler issue as application
> checks the app_parse_opt_vals() return value.
> 
> Since this code is in slow path, adding a memset
> to fix following "maybe-uninitialized" warning.
> 
> qos_sched/args.c: In function ‘app_parse_args’:
> examples/qos_sched/args.c:254:32: error: ‘vals[0]’ may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
> pconf->rx_port = (uint8_t)vals[0];
> ^~~
> Signed-off-by: Jerin Jacob 
> ---

Acked-by: cristian.dumitre...@intel.com

Re: [dpdk-dev] [RFC] proposal of allowing personal/project repos on DPDK.org

2017-06-02 Thread Dumitrescu, Cristian

> Why? Do you need to host a repo on dpdk.org to try a new idea?
> 

Prototyping new DPDK-related ideas and sharing them with DPDK community, with 
some of them likely to eventually make their way into DPDK once accepted and 
mature enough.


> I am against adding some user repos in this list:
>   http://dpdk.org/browse/
> I think the list of official repos must be kept light for good visibility.

We could have a single project called sandbox mentioned in this list; whoever 
interested, needs to drill down into this one?

> 
> But we can imagine a forge for users at a different location like
>   http://dpdk.org/users/
> However why not using another public forge for this need?

Easier to share DPDK related ideas on dpdk.org rather than other places.

[dpdk-dev] [PATCH] ring: use aligned memzone allocation

2017-06-02 Thread Daniel Verkamp

rte_memzone_reserve() provides cache line alignment, but
struct rte_ring may require more than cache line alignment: on x86-64,
it needs 128-byte alignment due to PROD_ALIGN and CONS_ALIGN, which are
128 bytes, but cache line size is 64 bytes.

Fixes runtime warnings with UBSan enabled.

Fixes: d9f0d3a1ffd4 ("ring: remove split cacheline build setting")

Signed-off-by: Daniel Verkamp 
---
 lib/librte_ring/rte_ring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
index 5f98c33..ee42343 100644
--- a/lib/librte_ring/rte_ring.c
+++ b/lib/librte_ring/rte_ring.c
@@ -189,7 +189,7 @@ rte_ring_create(const char *name, unsigned count, int 
socket_id,
/* reserve a memory zone for this ring. If we can't get rte_config or
 * we are secondary process, the memzone_reserve function will set
 * rte_errno for us appropriately - hence no check in this this 
function */
-   mz = rte_memzone_reserve(mz_name, ring_size, socket_id, mz_flags);
+   mz = rte_memzone_reserve_aligned(mz_name, ring_size, socket_id, 
mz_flags, __alignof__(*r));
if (mz != NULL) {
r = mz->addr;
/* no need to check return value here, we already checked the
-- 
2.9.4

[dpdk-dev] [PATCH v2] ring: use aligned memzone allocation

2017-06-02 Thread Daniel Verkamp

rte_memzone_reserve() provides cache line alignment, but
struct rte_ring may require more than cache line alignment: on x86-64,
it needs 128-byte alignment due to PROD_ALIGN and CONS_ALIGN, which are
128 bytes, but cache line size is 64 bytes.

Fixes runtime warnings with UBSan enabled.

Fixes: d9f0d3a1ffd4 ("ring: remove split cacheline build setting")

Signed-off-by: Daniel Verkamp 
---

v2: fixed checkpatch warnings

 lib/librte_ring/rte_ring.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
index 5f98c33..6f58faf 100644
--- a/lib/librte_ring/rte_ring.c
+++ b/lib/librte_ring/rte_ring.c
@@ -189,7 +189,8 @@ rte_ring_create(const char *name, unsigned count, int 
socket_id,
/* reserve a memory zone for this ring. If we can't get rte_config or
 * we are secondary process, the memzone_reserve function will set
 * rte_errno for us appropriately - hence no check in this this 
function */
-   mz = rte_memzone_reserve(mz_name, ring_size, socket_id, mz_flags);
+   mz = rte_memzone_reserve_aligned(mz_name, ring_size, socket_id,
+mz_flags, __alignof__(*r));
if (mz != NULL) {
r = mz->addr;
/* no need to check return value here, we already checked the
-- 
2.9.4

Re: [dpdk-dev] [RFC] proposal of allowing personal/project repos on DPDK.org

2017-06-02 Thread Stephen Hemminger

On Fri, 2 Jun 2017 18:37:40 +
"Dumitrescu, Cristian"  wrote:

> > Why? Do you need to host a repo on dpdk.org to try a new idea?
> >   
> 
> Prototyping new DPDK-related ideas and sharing them with DPDK community, with 
> some of them likely to eventually make their way into DPDK once accepted and 
> mature enough.
> 
> 
> > I am against adding some user repos in this list:
> > http://dpdk.org/browse/
> > I think the list of official repos must be kept light for good visibility.  
> 
> We could have a single project called sandbox mentioned in this list; whoever 
> interested, needs to drill down into this one?
> 
> > 
> > But we can imagine a forge for users at a different location like
> > http://dpdk.org/users/
> > However why not using another public forge for this need?  
> 
> Easier to share DPDK related ideas on dpdk.org rather than other places.
> 

Let's not distract Thomas and others with lots of effort to run servers.
Having dpdk.org be the server for development and stable should be more than 
enough.

Running a secure server for user repositories is hard. If you want an example,
look follow some of the two factor auth stuff being done at kernel.org.

Another option would be to have an official clone of dpdk.org on github
and let users do what they need to there. This keeps project out of the forge
business.

Re: [dpdk-dev] [RFC] Add Membership Library

2017-06-02 Thread Stephen Hemminger

On Thu, 1 Jun 2017 01:03:36 +
"Wang, Yipeng1"  wrote:

> Hi Vincent,
> 
> Thanks for the comments and some quick responses below:
> 
> - DPDK Bloom Filter is derived from the libbloom (as shown by the included 
> BSD license), but optimized for performance with various DPDK goodness such 
> as rte_zmalloc, rte_bitmap, rte_jhash, etc. It doesn't seem appropriate to
> bring those DPDK specific features into libbloom, which is designed for more 
> generic environments.
> - DPDK Bloom Filter is just one very basic mode among other more 
> sophisticated ones in the DPDK Membership Library, which supports a different 
> set of APIs (e.g., bulk lookup, multi-match, etc.) than those supported in 
> libbloom.
> - It may make sense to bring some generic (i.e., non DPDK specific) 
> improvements back to libbloom once identified.
> 
> Thanks
> Yipeng
> 
> > -Original Message-
> > From: Vincent Jardin [mailto:vincent.jar...@6wind.com]
> > Sent: Saturday, May 27, 2017 2:42 AM
> > To: Wang, Yipeng1 
> > Cc: dev@dpdk.org; Gobriel, Sameh ; Wang, Ren
> > ; Tai, Charlie 
> > Subject: Re: [dpdk-dev] [RFC] Add Membership Library
> > 
> > Why duplicating Jyri's libbloom - https://github.com/jvirkki/libbloom - for 
> > this
> > DPDK capability? Why not showing that you can contribute to libbloom and
> > make it linkable with the DPDK?
> > 
> > There are so many duplicated code...
> > 
> > Thank you,
> >   Vincent
> >   
> 

Note: rte_zmalloc is really no faster in my experience than regular malloc. And 
under
memory pressure rte_malloc is worse than malloc.

Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation

2017-06-02 Thread Ananyev, Konstantin



> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Daniel Verkamp
> Sent: Friday, June 2, 2017 9:12 PM
> To: dev@dpdk.org
> Cc: Verkamp, Daniel 
> Subject: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation
> 
> rte_memzone_reserve() provides cache line alignment, but
> struct rte_ring may require more than cache line alignment: on x86-64,
> it needs 128-byte alignment due to PROD_ALIGN and CONS_ALIGN, which are
> 128 bytes, but cache line size is 64 bytes.

Hmm but what for?
I understand we need our rte_ring cche-line aligned,
but why do you want it 2 cache-line aligned?
Konstantin 

> 
> Fixes runtime warnings with UBSan enabled.
> 
> Fixes: d9f0d3a1ffd4 ("ring: remove split cacheline build setting")
> 
> Signed-off-by: Daniel Verkamp 
> ---
> 
> v2: fixed checkpatch warnings
> 
>  lib/librte_ring/rte_ring.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
> index 5f98c33..6f58faf 100644
> --- a/lib/librte_ring/rte_ring.c
> +++ b/lib/librte_ring/rte_ring.c
> @@ -189,7 +189,8 @@ rte_ring_create(const char *name, unsigned count, int 
> socket_id,
>   /* reserve a memory zone for this ring. If we can't get rte_config or
>* we are secondary process, the memzone_reserve function will set
>* rte_errno for us appropriately - hence no check in this this 
> function */
> - mz = rte_memzone_reserve(mz_name, ring_size, socket_id, mz_flags);
> + mz = rte_memzone_reserve_aligned(mz_name, ring_size, socket_id,
> +  mz_flags, __alignof__(*r));
>   if (mz != NULL) {
>   r = mz->addr;
>   /* no need to check return value here, we already checked the
> --
> 2.9.4

Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation

2017-06-02 Thread Verkamp, Daniel

The PROD/CONS_ALIGN values on x86-64 are set to 2 cache lines, so members of 
struct rte_ring are 128 byte aligned, and therefore the whole struct needs 
128-byte alignment according to the ABI so that the 128-byte alignment of the 
fields can be guaranteed.

If the allocation is only 64-byte aligned, the beginning of the prod and cons 
fields may not actually be 128-byte aligned (but we've told the compiler that 
they are using the __rte_aligned macro).  Accessing these fields when they are 
misaligned will work in practice on x86 (as long as the compiler doesn't use 
e.g. aligned SSE instructions), but it is undefined behavior according to the C 
standard, and UBSan (-fsanitize=undefined) checks for this.

Thanks,
-- Daniel Verkamp

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Friday, June 2, 2017 1:52 PM
> To: Verkamp, Daniel ; dev@dpdk.org
> Cc: Verkamp, Daniel 
> Subject: RE: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Daniel Verkamp
> > Sent: Friday, June 2, 2017 9:12 PM
> > To: dev@dpdk.org
> > Cc: Verkamp, Daniel 
> > Subject: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation
> >
> > rte_memzone_reserve() provides cache line alignment, but
> > struct rte_ring may require more than cache line alignment: on x86-64,
> > it needs 128-byte alignment due to PROD_ALIGN and CONS_ALIGN, which are
> > 128 bytes, but cache line size is 64 bytes.
> 
> Hmm but what for?
> I understand we need our rte_ring cche-line aligned,
> but why do you want it 2 cache-line aligned?
> Konstantin
> 
> >
> > Fixes runtime warnings with UBSan enabled.
> >
> > Fixes: d9f0d3a1ffd4 ("ring: remove split cacheline build setting")
> >
> > Signed-off-by: Daniel Verkamp 
> > ---
> >
> > v2: fixed checkpatch warnings
> >
> >  lib/librte_ring/rte_ring.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
> > index 5f98c33..6f58faf 100644
> > --- a/lib/librte_ring/rte_ring.c
> > +++ b/lib/librte_ring/rte_ring.c
> > @@ -189,7 +189,8 @@ rte_ring_create(const char *name, unsigned count, int
> socket_id,
> > /* reserve a memory zone for this ring. If we can't get rte_config or
> >  * we are secondary process, the memzone_reserve function will set
> >  * rte_errno for us appropriately - hence no check in this this 
> > function */
> > -   mz = rte_memzone_reserve(mz_name, ring_size, socket_id, mz_flags);
> > +   mz = rte_memzone_reserve_aligned(mz_name, ring_size, socket_id,
> > +mz_flags, __alignof__(*r));
> > if (mz != NULL) {
> > r = mz->addr;
> > /* no need to check return value here, we already checked the
> > --
> > 2.9.4

[dpdk-dev] [PATCH] pci/uio: enable prefetchable resources mapping

2017-06-02 Thread Changpeng Liu

For PCI prefetchable resources, Linux will create a
write combined file as well, the library will try
to map resourceX_wc file first, if the file does
not exist, then it will map resourceX as usual.

Signed-off-by: Changpeng Liu 
---
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c 
b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
index fa10329..d9fc20a 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
@@ -321,7 +321,7 @@
 
/* update devname for mmap  */
snprintf(devname, sizeof(devname),
-   "%s/" PCI_PRI_FMT "/resource%d",
+   "%s/" PCI_PRI_FMT "/resource%d_wc",
pci_get_sysfs_path(),
loc->domain, loc->bus, loc->devid,
loc->function, res_idx);
@@ -335,13 +335,22 @@
}
 
/*
-* open resource file, to mmap it
+* open prefetchable resource file first, try to mmap it
 */
fd = open(devname, O_RDWR);
if (fd < 0) {
-   RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
-   devname, strerror(errno));
-   goto error;
+   snprintf(devname, sizeof(devname),
+   "%s/" PCI_PRI_FMT "/resource%d",
+   pci_get_sysfs_path(),
+   loc->domain, loc->bus, loc->devid,
+   loc->function, res_idx);
+   /* then try to map resource file */
+   fd = open(devname, O_RDWR);
+   if (fd < 0) {
+   RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
+   devname, strerror(errno));
+   goto error;
+   }
}
 
/* try mapping somewhere close to the end of hugepages */
-- 
1.9.3

Re: [dpdk-dev] [RFC] proposal of allowing personal/project repos on DPDK.org

2017-06-02 Thread Tiwei Bie

On Fri, Jun 02, 2017 at 05:29:48PM +0200, Thomas Monjalon wrote:
> 01/06/2017 07:07, Tiwei Bie:
> > Hello everyone,
> > 
> > We'd like to make a proposal of making DPDK.org allow hosting
> > some personal/project repos, which could be very useful when
> > someone wants to try some experimental projects in DPDK. Many
> > formal/mature opensource communities allow this. Such as:
> [...]
> 
> So you are asking for a forge.
> It requires some maintenance effort.
> 
> > But currently on DPDK.org, for the repos of DPDK, besides the main
> > repo, there are just one repo for stable release, few old repos
> > which are obsoleted, and some "-next" repos which are mainly used
> > as the preparation of pull requests for different subsystems of DPDK.
> 
> Yes they are the official DPDK repos.
> 
> > Some “-next” repos may be developed individually for a short time
> > when they are created, but will always be merged to the main repo
> > after few releases. We think they are too formal/limited to try
> > new ideas.
> 
> Why? Do you need to host a repo on dpdk.org to try a new idea?
> 

Yeah. We have some new ideas to try in DPDK, and we are longing to
host some repos on dpdk.org to show them to the community. Such as
some virtio 1.1 prototyping. DPDK is one of the best places to practice
those new ideas. We want to show it in a formal way to promote the
development of virtio in DPDK. Currently, it's done in a temporary
branch of Yuanhan's next-virtio tree:

http://dpdk.org/browse/next/dpdk-next-virtio/commit/?h=for-testing

It's very inconvenient, and just like what you said, it is an official
DPDK repo, and actually we are misusing it. :-(

> > What we want to proposal is to make DPDK.org allow hosting some
> > DPDK based repos which may be very experimental, which even not
> > be planned to be merged back to the main repo directly, and may
> > be deleted directly if it proves that no one really cares about
> > it. Just like what other opensource communities did, allow some
> > core developers/vendors create their own repos and try ideas on
> > DPDK.org without too many restrictions. We think it can provide
> > people a very convenient way to try ideas in DPDK community and
> > eventually help DPDK grow.
> > 
> > Allowing it won't have any negative impact on the existing repos
> > of DPDK, instead, it can help to keep them tidy and clean when
> > someone wants/needs to try some very experimental and big ideas
> > publicly in DPDK as he/she can start it in an experimental repo.
> > An experimental repo can be merged back to the main repo when it
> > proves to be mature and useful, or could just be deleted when no
> > one really cares about it any more.
> > 
> > Please share your thoughts on this. Many thanks! :-)
> 
> I am against adding some user repos in this list:
>   http://dpdk.org/browse/
> I think the list of official repos must be kept light for good visibility.
> 

Yeah, I totally agree with you. The list of official repos should
definitely be kept as light as possible.

> But we can imagine a forge for users at a different location like
>   http://dpdk.org/users/
> However why not using another public forge for this need?
> 

It's definitely OK to show those repos at http://dpdk.org/users/ or
any other similar locations. Technically, we can use any public forge
for this need. But it would seems less connected with DPDK community
and be harder for other people to figure it out quickly. And we really
don't want such things hinder the development of the new ideas.

Anyway, DPDK is not a small community any more. We should learn from
other mature open source communities such as FreeBSD/Linux. If we have
some concerns on the maintenance effort, we should think about how to
fix it, rather than letting it kill this proposal.

Thank you very much for sharing your thoughts! :-)

Best regards,
Tiwei Bie

38 matches

Mail list logo