Re: [dpdk-dev] compilation error in softnic PMD

[Singh, Jasvinder]

> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Wednesday, November 8, 2017 2:05 AM
> To: Singh, Jasvinder 
> Cc: dev@dpdk.org
> Subject: compilation error in softnic PMD
> 
> Hi,
> 
> There is an error when compiling on SUSE11SP2:
> 
> drivers/net/softnic/rte_eth_softnic_tm.c:588:3: error:
>   unknown field ‘nonleaf’ specified in initializer
> 
> It is probably the same cause as in this recent ixgbe fix:
>   http://dpdk.org/commit/a8c839a675b

Thank you. I will send fix.

Re: [dpdk-dev] [PATCH 2/3] ring: guarantee load ordering of cons/prod when doing enqueue/dequeue

[Ananyev, Konstantin]

> +
> +#define UNUSED_PARAMETER(x) ((void)(x))
> +static __rte_always_inline void
> +update_tail(struct rte_ring_headtail *ht, uint32_t old_val, uint32_t new_val,
> + uint32_t single, uint32_t enqueue)
> +{
> + UNUSED_PARAMETER(enqueue);

As a nit you can use __rte_unused parameter attribute or
RTE_SET_USED() macro here.

Konstantin

[dpdk-dev] [PATCH] doc: postpone devargs clean-up

[Gaetan Rivet]

These changes were planned for 17.11 but were proposed too late.
Postpone those to v18.02 instead.

Signed-off-by: Gaetan Rivet 
---

The related series:

[PATCH v2 00/18] devargs cleanup
http://dpdk.org/ml/archives/dev/2017-October/078761.html

 doc/guides/rel_notes/deprecation.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 7fcebf1..a89a394 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -8,14 +8,14 @@ API and ABI deprecation notices are to be posted here.
 Deprecation Notices
 ---
 
-* eal: several API and ABI changes are planned for ``rte_devargs`` in v17.11.
+* eal: several API and ABI changes are planned for ``rte_devargs`` in v18.02.
   The format of device command line parameters will change. The bus will need
   to be explicitly stated in the device declaration. The enum ``rte_devtype``
   was used to identify a bus and will disappear.
   The structure ``rte_devargs`` will change.
   The ``rte_devargs_list`` will be made private.
   The following functions are deprecated starting from 17.08 and will either be
-  modified or removed in 17.11:
+  modified or removed in 18.02:
 
   - ``rte_eal_devargs_add``
   - ``rte_eal_devargs_type_count``
-- 
2.1.4

[dpdk-dev] [PATCH v4 3/4] ring: introduce new header file to include common functions

[Jia He]

move the common part of rte_ring.h into rte_ring_generic.h
move the memory barrier part into update_tail()
no functional changes here

Signed-off-by: Jia He 
Suggested-by: Jerin Jacob 
Suggested-by: Ananyev, Konstantin 
---
 lib/librte_eventdev/rte_event_ring.h |   6 +-
 lib/librte_ring/Makefile |   3 +-
 lib/librte_ring/rte_ring.h   | 159 +---
 lib/librte_ring/rte_ring_generic.h   | 194 +++
 4 files changed, 202 insertions(+), 160 deletions(-)
 create mode 100644 lib/librte_ring/rte_ring_generic.h

diff --git a/lib/librte_eventdev/rte_event_ring.h 
b/lib/librte_eventdev/rte_event_ring.h
index ea9b688..3e49458 100644
--- a/lib/librte_eventdev/rte_event_ring.h
+++ b/lib/librte_eventdev/rte_event_ring.h
@@ -126,9 +126,8 @@ rte_event_ring_enqueue_burst(struct rte_event_ring *r,
goto end;
 
ENQUEUE_PTRS(&r->r, &r[1], prod_head, events, n, struct rte_event);
-   rte_smp_wmb();
 
-   update_tail(&r->r.prod, prod_head, prod_next, 1);
+   update_tail(&r->r.prod, prod_head, prod_next, 1, 1);
 end:
if (free_space != NULL)
*free_space = free_entries - n;
@@ -168,9 +167,8 @@ rte_event_ring_dequeue_burst(struct rte_event_ring *r,
goto end;
 
DEQUEUE_PTRS(&r->r, &r[1], cons_head, events, n, struct rte_event);
-   rte_smp_rmb();
 
-   update_tail(&r->r.cons, cons_head, cons_next, 1);
+   update_tail(&r->r.cons, cons_head, cons_next, 1, 0);
 
 end:
if (available != NULL)
diff --git a/lib/librte_ring/Makefile b/lib/librte_ring/Makefile
index e34d9d9..c959945 100644
--- a/lib/librte_ring/Makefile
+++ b/lib/librte_ring/Makefile
@@ -45,6 +45,7 @@ LIBABIVER := 1
 SRCS-$(CONFIG_RTE_LIBRTE_RING) := rte_ring.c
 
 # install includes
-SYMLINK-$(CONFIG_RTE_LIBRTE_RING)-include := rte_ring.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_RING)-include := rte_ring.h \
+   rte_ring_generic.h
 
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 3e8085a..519614c 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -356,90 +356,8 @@ void rte_ring_dump(FILE *f, const struct rte_ring *r);
} \
 } while (0)
 
-static __rte_always_inline void
-update_tail(struct rte_ring_headtail *ht, uint32_t old_val, uint32_t new_val,
-   uint32_t single)
-{
-   /*
-* If there are other enqueues/dequeues in progress that preceded us,
-* we need to wait for them to complete
-*/
-   if (!single)
-   while (unlikely(ht->tail != old_val))
-   rte_pause();
-
-   ht->tail = new_val;
-}
-
-/**
- * @internal This function updates the producer head for enqueue
- *
- * @param r
- *   A pointer to the ring structure
- * @param is_sp
- *   Indicates whether multi-producer path is needed or not
- * @param n
- *   The number of elements we will want to enqueue, i.e. how far should the
- *   head be moved
- * @param behavior
- *   RTE_RING_QUEUE_FIXED:Enqueue a fixed number of items from a ring
- *   RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
- * @param old_head
- *   Returns head value as it was before the move, i.e. where enqueue starts
- * @param new_head
- *   Returns the current/new head value i.e. where enqueue finishes
- * @param free_entries
- *   Returns the amount of free space in the ring BEFORE head was moved
- * @return
- *   Actual number of objects enqueued.
- *   If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
- */
-static __rte_always_inline unsigned int
-__rte_ring_move_prod_head(struct rte_ring *r, int is_sp,
-   unsigned int n, enum rte_ring_queue_behavior behavior,
-   uint32_t *old_head, uint32_t *new_head,
-   uint32_t *free_entries)
-{
-   const uint32_t capacity = r->capacity;
-   unsigned int max = n;
-   int success;
-
-   do {
-   /* Reset n to the initial burst count */
-   n = max;
-
-   *old_head = r->prod.head;
-
-   /* add rmb barrier to avoid load/load reorder in weak
-* memory model. It is noop on x86 */
-   rte_smp_rmb();
-
-   const uint32_t cons_tail = r->cons.tail;
-   /*
-*  The subtraction is done between two unsigned 32bits value
-* (the result is always modulo 32 bits even if we have
-* *old_head > cons_tail). So 'free_entries' is always between 0
-* and capacity (which is < size).
-*/
-   *free_entries = (capacity + cons_tail - *old_head);
-
-   /* check that we have enough room in ring */
-   if (unlikely(n > *free_entries))
-   n = (behavior == RTE_RING_QUEUE_FIXED) ?
-   0 : *free_entries;
-
-

[dpdk-dev] [PATCH v4 0/4] fix race condition in enqueue/dequeue because of cpu reorder

[Jia He]

We watched a rte panic of mbuf_autotest in our qualcomm arm64 server due
to a possible race condition.

To fix this race, there are 2 options as suggested by Jerin:
1. use rte_smp_rmb
2. use load_acquire/store_release(refer to [2]).
CONFIG_RTE_RING_USE_C11_MEM_MODEL is provided, and by default it is "y"
only on arm64 so far.

The reason why providing 2 options is due to the performance benchmark
difference in different arm machines.

Already fuctionally tested on the machines as follows:
- on X86
- on arm64 with CONFIG_RTE_RING_USE_C11_MEM_MODEL=y
- on arm64 with CONFIG_RTE_RING_USE_C11_MEM_MODEL=n

---
Changelog:
V4: split into small patches
V3: arch specific implementation for enqueue/dequeue barrier
V2: let users choose whether using load_acquire/store_release
V1: rte_smp_rmb() between 2 loads

Jia He (4):
  eal/arm64: remove the braces {} for dmb() and dsb()
  ring: guarantee load/load order in enqueue and dequeue
  ring: introduce new header file to include common functions
  ring: introduce new header file to support C11 memory model

 config/common_armv8a_linuxapp  |   2 +
 .../common/include/arch/arm/rte_atomic_64.h|   4 +-
 lib/librte_eventdev/rte_event_ring.h   |   6 +-
 lib/librte_ring/Makefile   |   4 +-
 lib/librte_ring/rte_ring.h | 161 ++---
 lib/librte_ring/rte_ring_c11_mem.h | 185 
 lib/librte_ring/rte_ring_generic.h | 194 +
 7 files changed, 404 insertions(+), 152 deletions(-)
 create mode 100644 lib/librte_ring/rte_ring_c11_mem.h
 create mode 100644 lib/librte_ring/rte_ring_generic.h

-- 
2.7.4

[dpdk-dev] [PATCH] net/softnic: fix build error on gcc4.5.1

[Jasvinder Singh]

Fix the build error due to improper handling of unions on SUSE11(gcc 4.5.1).

Fixes: 299a89de916a ("net/softnic: add TM capabilities ops")

DPDK/drivers/net/softnic/rte_eth_softnic_tm.c:588:3
error: unknown field 'nonleaf' specified in initializer compilation
terminated due to -Wfatal-errors.

Signed-off-by: Jasvinder Singh 
---
 drivers/net/softnic/rte_eth_softnic_tm.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c 
b/drivers/net/softnic/rte_eth_softnic_tm.c
index dbb2514..a459900 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -585,7 +585,7 @@ static const struct rte_tm_level_capabilities 
tm_level_cap[] = {
.non_leaf_nodes_identical = 1,
.leaf_nodes_identical = 0,
 
-   .nonleaf = {
+   {.nonleaf = {
.shaper_private_supported = 1,
.shaper_private_dual_rate_supported = 0,
.shaper_private_rate_min = 1,
@@ -599,7 +599,7 @@ static const struct rte_tm_level_capabilities 
tm_level_cap[] = {
.sched_wfq_weight_max = 1,
 
.stats_mask = STATS_MASK_DEFAULT,
-   },
+   } },
},
 
[TM_NODE_LEVEL_SUBPORT] = {
@@ -609,7 +609,7 @@ static const struct rte_tm_level_capabilities 
tm_level_cap[] = {
.non_leaf_nodes_identical = 1,
.leaf_nodes_identical = 0,
 
-   .nonleaf = {
+   {.nonleaf = {
.shaper_private_supported = 1,
.shaper_private_dual_rate_supported = 0,
.shaper_private_rate_min = 1,
@@ -626,7 +626,7 @@ static const struct rte_tm_level_capabilities 
tm_level_cap[] = {
.sched_wfq_weight_max = 1,
 #endif
.stats_mask = STATS_MASK_DEFAULT,
-   },
+   } },
},
 
[TM_NODE_LEVEL_PIPE] = {
@@ -636,7 +636,7 @@ static const struct rte_tm_level_capabilities 
tm_level_cap[] = {
.non_leaf_nodes_identical = 1,
.leaf_nodes_identical = 0,
 
-   .nonleaf = {
+   {.nonleaf = {
.shaper_private_supported = 1,
.shaper_private_dual_rate_supported = 0,
.shaper_private_rate_min = 1,
@@ -652,7 +652,7 @@ static const struct rte_tm_level_capabilities 
tm_level_cap[] = {
.sched_wfq_weight_max = 1,
 
.stats_mask = STATS_MASK_DEFAULT,
-   },
+   } },
},
 
[TM_NODE_LEVEL_TC] = {
@@ -662,7 +662,7 @@ static const struct rte_tm_level_capabilities 
tm_level_cap[] = {
.non_leaf_nodes_identical = 1,
.leaf_nodes_identical = 0,
 
-   .nonleaf = {
+   {.nonleaf = {
.shaper_private_supported = 1,
.shaper_private_dual_rate_supported = 0,
.shaper_private_rate_min = 1,
@@ -678,7 +678,7 @@ static const struct rte_tm_level_capabilities 
tm_level_cap[] = {
.sched_wfq_weight_max = UINT32_MAX,
 
.stats_mask = STATS_MASK_DEFAULT,
-   },
+   } },
},
 
[TM_NODE_LEVEL_QUEUE] = {
@@ -688,7 +688,7 @@ static const struct rte_tm_level_capabilities 
tm_level_cap[] = {
.non_leaf_nodes_identical = 0,
.leaf_nodes_identical = 1,
 
-   .leaf = {
+   {.leaf = {
.shaper_private_supported = 0,
.shaper_private_dual_rate_supported = 0,
.shaper_private_rate_min = 0,
@@ -700,7 +700,7 @@ static const struct rte_tm_level_capabilities 
tm_level_cap[] = {
.cman_wred_context_shared_n_max = 0,
 
.stats_mask = STATS_MASK_QUEUE,
-   },
+   } },
},
 };
 
@@ -778,13 +778,13 @@ static const struct rte_tm_node_capabilities 
tm_node_cap[] = {
.shaper_private_rate_max = UINT32_MAX,
.shaper_shared_n_max = 0,
 
-   .nonleaf = {
+   {.nonleaf = {
.sched_n_children_max = UINT32_MAX,
.sched_sp_n_priorities_max = 1,
.sched_wfq_n_children_per_group_max = UINT32_MAX,
.sched_wfq_n_groups_max = 1,
.sched_wfq_weight_max = 1,
-   },
+   } },
 
.stats_mask = STATS_MASK_DEFAULT,
},
@@ -796,13 +796,13 @@ static const struct rte_tm_node_capabilities 
tm_node_cap[] = {
.shaper_private_rate_max = UINT32_MAX,
.shaper_shared_n_max = 0,
 
-   .nonleaf = {

Re: [dpdk-dev] [PATCH 1/3] eal/arm64: remove the braces {} for dmb(), dsb()

[Bruce Richardson]

On Wed, Nov 08, 2017 at 06:17:10AM +, Jia He wrote:
> for the code as follows:
> if (condition)
>   rte_smp_rmb();
> else
>   rte_smp_wmb();
> Without this patch, compiler will report this error:
> error: 'else' without a previous 'if'
> 
> Signed-off-by: Jia He 
> Signed-off-by: jia...@hxt-semitech.com
> ---
>  lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h 
> b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> index 0b70d62..38c3393 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> @@ -43,8 +43,8 @@ extern "C" {
>  
>  #include "generic/rte_atomic.h"
>  
> -#define dsb(opt)  { asm volatile("dsb " #opt : : : "memory"); }
> -#define dmb(opt)  { asm volatile("dmb " #opt : : : "memory"); }
> +#define dsb(opt) asm volatile("dsb " #opt : : : "memory");
> +#define dmb(opt) asm volatile("dmb " #opt : : : "memory");
>  

Need to remove the trailing ";" I too I think.
Alternatively, to keep the braces, the standard practice is to use
do { ... } while(0)

Regards,
/Bruce

[dpdk-dev] [PATCH v4 2/4] ring: guarantee load/load order in enqueue and dequeue

[Jia He]

We watched a rte panic of mbuf_autotest in our qualcomm arm64 server.
In __rte_ring_move_cons_head()
...
do {
/* Restore n as it may change every loop */
n = max;

*old_head = r->cons.head;//1st load
const uint32_t prod_tail = r->prod.tail; //2nd load

In weak memory order architectures(powerpc,arm), the 2nd load might be
reodered before the 1st load, that makes *entries is bigger than we wanted.
This nasty reording messed enque/deque up.

cpu1(producer)  cpu2(consumer)  cpu3(consumer)
load r->prod.tail
in enqueue:
load r->cons.tail
load r->prod.head

store r->prod.tail

load r->cons.head
load r->prod.tail
...
store r->cons.{head,tail}
load r->cons.head

Then, r->cons.head will be bigger than prod_tail, then make *entries very
big and the consumer will go forward incorrectly.

After this patch, the old cons.head will be recaculated after failure of
rte_atomic32_cmpset

There is no such issue on X86, because X86 is strong memory order model.

Signed-off-by: Jia He 
Signed-off-by: jie2@hxt-semitech.com
Signed-off-by: bing.z...@hxt-semitech.com
---
 lib/librte_ring/rte_ring.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 5e9b3b7..3e8085a 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -409,6 +409,11 @@ __rte_ring_move_prod_head(struct rte_ring *r, int is_sp,
n = max;
 
*old_head = r->prod.head;
+
+   /* add rmb barrier to avoid load/load reorder in weak
+* memory model. It is noop on x86 */
+   rte_smp_rmb();
+
const uint32_t cons_tail = r->cons.tail;
/*
 *  The subtraction is done between two unsigned 32bits value
@@ -517,6 +522,11 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
n = max;
 
*old_head = r->cons.head;
+
+   /* add rmb barrier to avoid load/load reorder in weak
+* memory model. It is noop on x86 */
+   rte_smp_rmb();
+
const uint32_t prod_tail = r->prod.tail;
/* The subtraction is done between two unsigned 32bits value
 * (the result is always modulo 32 bits even if we have
-- 
2.7.4

[dpdk-dev] [PATCH v4 4/4] ring: introduce new header file to support C11 memory model

[Jia He]

To fix the cpu reorder race condition in enque/deque, there are 2 options
suggested by Jerin:
1. use rte_smp_rmb
2. use load_acquire/store_release(refer to [1]).
for the 2nd option, CONFIG_RTE_RING_USE_C11_MEM_MODEL is provided, and by
default it is "y" only on arm64.

The reason why providing 2 options is due to the performance benchmark
difference in different arm machines, refer to [2].

We haven't tested on ppc64. If anyone verifies it, he can add
CONFIG_RTE_RING_USE_C11_MEM_MODEL=y to ppc64 config files.

[1] https://github.com/freebsd/freebsd/blob/master/sys/sys/buf_ring.h#L170
[2] http://dpdk.org/ml/archives/dev/2017-October/080861.html

Signed-off-by: Jia He 
Suggested-by: Jerin Jacob 
---
 config/common_armv8a_linuxapp  |   2 +
 lib/librte_ring/Makefile   |   3 +-
 lib/librte_ring/rte_ring.h |  14 ++-
 lib/librte_ring/rte_ring_c11_mem.h | 185 +
 4 files changed, 202 insertions(+), 2 deletions(-)
 create mode 100644 lib/librte_ring/rte_ring_c11_mem.h

diff --git a/config/common_armv8a_linuxapp b/config/common_armv8a_linuxapp
index 6732d1e..5b7b2eb 100644
--- a/config/common_armv8a_linuxapp
+++ b/config/common_armv8a_linuxapp
@@ -49,3 +49,5 @@ CONFIG_RTE_LIBRTE_SFC_EFX_PMD=n
 CONFIG_RTE_LIBRTE_AVP_PMD=n
 
 CONFIG_RTE_SCHED_VECTOR=n
+
+CONFIG_RTE_RING_USE_C11_MEM_MODEL=y
diff --git a/lib/librte_ring/Makefile b/lib/librte_ring/Makefile
index c959945..a2682e7 100644
--- a/lib/librte_ring/Makefile
+++ b/lib/librte_ring/Makefile
@@ -46,6 +46,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_RING) := rte_ring.c
 
 # install includes
 SYMLINK-$(CONFIG_RTE_LIBRTE_RING)-include := rte_ring.h \
-   rte_ring_generic.h
+   rte_ring_generic.h \
+   rte_ring_c11_mem.h
 
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 519614c..3343eba 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -356,8 +356,20 @@ void rte_ring_dump(FILE *f, const struct rte_ring *r);
} \
 } while (0)
 
-/* Move common functions to generic file */
+/* Between load and load. there might be cpu reorder in weak model
+ * (powerpc/arm).
+ * There are 2 choices for the users
+ * 1.use rmb() memory barrier
+ * 2.use one-direcion load_acquire/store_release barrier,defined by
+ * CONFIG_RTE_RING_USE_C11_MEM_MODEL=y
+ * It depends on performance test results.
+ * By default, move common functions to rte_ring_generic.h
+ */
+#ifdef RTE_RING_USE_C11_MEM_MODEL
+#include "rte_ring_c11_mem.h"
+#else
 #include "rte_ring_generic.h"
+#endif
 
 /**
  * @internal Enqueue several objects on the ring
diff --git a/lib/librte_ring/rte_ring_c11_mem.h 
b/lib/librte_ring/rte_ring_c11_mem.h
new file mode 100644
index 000..c167b46
--- /dev/null
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -0,0 +1,185 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2017 hxt-semitech. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of hxt-semitech 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_RING_C11_MEM_H_
+#define _RTE_RING_C11_MEM_H_
+
+static __rte_always_inline void
+update_tail(struct rte_ring_headtail *ht, uint32_t old_val, uint32_t new_val,
+   uint32_t single, uint32_t enqueue)
+{
+   RTE_SET_USED(enqueue);
+
+   /*
+* If there are other enqueues/dequeues in progress that preceded us,
+* we need to wait for them

[dpdk-dev] [PATCH v4 1/4] eal/arm64: remove the braces {} for dmb() and dsb()

[Jia He]

for the code as follows:
if (condition)
rte_smp_rmb();
else
rte_smp_wmb();
Without this patch, compiler will report this error:
error: 'else' without a previous 'if'

Fixes: 84733fd0d75e ("eal/arm64: fix memory barrier definition")
Signed-off-by: Jia He 
---
 lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h 
b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
index 0b70d62..71da29c 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
@@ -43,8 +43,8 @@ extern "C" {
 
 #include "generic/rte_atomic.h"
 
-#define dsb(opt)  { asm volatile("dsb " #opt : : : "memory"); }
-#define dmb(opt)  { asm volatile("dmb " #opt : : : "memory"); }
+#define dsb(opt) asm volatile("dsb " #opt : : : "memory")
+#define dmb(opt) asm volatile("dmb " #opt : : : "memory")
 
 #define rte_mb() dsb(sy)
 
-- 
2.7.4

[dpdk-dev] [PATCH v2] net/virtio: fix rxq intr config fails using vfio-pci

[Zhiyong Yang]

When running l3fwd-power to test virtio rxq interrupt using vfio
pci noiommu mode, startup fails. In the function virtio_read_caps,
the code if (flags & PCI_MSIX_ENABLE) intends to double check
if vfio msix is enabled or not. However, it is not enable at that
stage. So use_msix is assigned to "0", not "1", which causes the
failure of configuring rxq intr in l3fwd-power.
This patch adds the function vtpci_msix_detect to detect the status
of msix when interrupt changes happen.
In the meanwhile, virtio_intr_enable/disable are introduced to wrap
rte_intr_enable/disable to enhance the ability to detect msix. Only
support and enable msix can assign "1" to use_msix.

Fixes: cb482cb3a305 ("net/virtio: fix MAC address read")
Signed-off-by: Zhiyong Yang 
---
 drivers/net/virtio/virtio_ethdev.c | 64 +-
 drivers/net/virtio/virtio_pci.c| 42 +
 drivers/net/virtio/virtio_pci.h|  5 +++
 3 files changed, 104 insertions(+), 7 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index d2576d5e0..525cfa06c 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -97,6 +97,9 @@ static void virtio_mac_addr_remove(struct rte_eth_dev *dev, 
uint32_t index);
 static void virtio_mac_addr_set(struct rte_eth_dev *dev,
struct ether_addr *mac_addr);
 
+static int virtio_intr_enable(struct rte_eth_dev *dev);
+static int virtio_intr_disable(struct rte_eth_dev *dev);
+
 static int virtio_dev_queue_stats_mapping_set(
struct rte_eth_dev *eth_dev,
uint16_t queue_id,
@@ -618,7 +621,7 @@ virtio_dev_close(struct rte_eth_dev *dev)
virtio_queues_unbind_intr(dev);
 
if (intr_conf->lsc || intr_conf->rxq) {
-   rte_intr_disable(dev->intr_handle);
+   virtio_intr_disable(dev);
rte_intr_efd_disable(dev->intr_handle);
rte_free(dev->intr_handle->intr_vec);
dev->intr_handle->intr_vec = NULL;
@@ -1160,6 +1163,44 @@ virtio_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
vlan_id, int on)
 }
 
 static int
+virtio_intr_enable(struct rte_eth_dev *dev)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   int msix_detect;
+
+   if (rte_intr_enable(dev->intr_handle) < 0)
+   return -1;
+
+   msix_detect = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
+   if (msix_detect < 0)
+   return -1;
+   else if (msix_detect == SUPPORT_MSIX_STATUS_ENABLED)
+   hw->use_msix = 1;
+   else
+   hw->use_msix = 0;
+   return 0;
+}
+
+static int
+virtio_intr_disable(struct rte_eth_dev *dev)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   int msix_detect;
+
+   if (rte_intr_disable(dev->intr_handle) < 0)
+   return -1;
+
+   msix_detect = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
+   if (msix_detect < 0)
+   return -1;
+   else if (msix_detect == SUPPORT_MSIX_STATUS_ENABLED)
+   hw->use_msix = 1;
+   else
+   hw->use_msix = 0;
+   return 0;
+}
+
+static int
 virtio_negotiate_features(struct virtio_hw *hw, uint64_t req_features)
 {
uint64_t host_features;
@@ -1228,7 +1269,7 @@ virtio_interrupt_handler(void *param)
isr = vtpci_isr(hw);
PMD_DRV_LOG(INFO, "interrupt status = %#x", isr);
 
-   if (rte_intr_enable(dev->intr_handle) < 0)
+   if (virtio_intr_enable(dev) < 0)
PMD_DRV_LOG(ERR, "interrupt enable failed");
 
if (isr & VIRTIO_PCI_ISR_CONFIG) {
@@ -1348,7 +1389,7 @@ virtio_configure_intr(struct rte_eth_dev *dev)
 * to change the config size from 20 to 24, or VIRTIO_MSI_QUEUE_VECTOR
 * (22) will be ignored.
 */
-   if (rte_intr_enable(dev->intr_handle) < 0) {
+   if (virtio_intr_enable(dev) < 0) {
PMD_DRV_LOG(ERR, "interrupt enable failed");
return -1;
}
@@ -1370,7 +1411,15 @@ virtio_init_device(struct rte_eth_dev *eth_dev, uint64_t 
req_features)
struct virtio_net_config local_config;
struct rte_pci_device *pci_dev = NULL;
int ret;
+   int msix_detect;
 
+   msix_detect = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(eth_dev));
+   if (msix_detect < 0)
+   return -1;
+   else if (msix_detect == SUPPORT_MSIX_STATUS_ENABLED)
+   hw->use_msix = 1;
+   else
+   hw->use_msix = 0;
/* Reset the device although not necessary at startup */
vtpci_reset(hw);
 
@@ -1388,7 +1437,8 @@ virtio_init_device(struct rte_eth_dev *eth_dev, uint64_t 
req_features)
}
 
/* If host does not support both status and MSI-X then disable LSC */
-   if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS) && hw->use_msix)
+   if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS) &&
+   (msix_detect >= SUPPORT_MSIX_STATU

Re: [dpdk-dev] [PATCH] net/softnic: fix build error on gcc4.5.1

[Dumitrescu, Cristian]

> -Original Message-
> From: Singh, Jasvinder
> Sent: Wednesday, November 8, 2017 10:25 AM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; Dumitrescu, Cristian
> 
> Subject: [PATCH] net/softnic: fix build error on gcc4.5.1
> 
> Fix the build error due to improper handling of unions on SUSE11(gcc 4.5.1).
> 
> Fixes: 299a89de916a ("net/softnic: add TM capabilities ops")
> 
> DPDK/drivers/net/softnic/rte_eth_softnic_tm.c:588:3
> error: unknown field 'nonleaf' specified in initializer compilation
> terminated due to -Wfatal-errors.
> 
> Signed-off-by: Jasvinder Singh 
> ---
>  drivers/net/softnic/rte_eth_softnic_tm.c | 40 ---
> -
>  1 file changed, 20 insertions(+), 20 deletions(-)
> 

Acked-by: Cristian Dumitrescu 

Re: [dpdk-dev] [PATCH] doc: update deprecation of ethdev offload API

[Andrew Rybchenko]

On 10/17/2017 05:24 PM, Shahaf Shuler wrote:

Update deprecation notice for the new ethdev offloads API.
Deprecation of the old offloads API is set to 18.05.

Signed-off-by: Shahaf Shuler 
---
  doc/guides/rel_notes/deprecation.rst | 14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 52058f580..deb546a67 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -41,12 +41,14 @@ Deprecation Notices
PKT_RX_QINQ_STRIPPED, that are better described. The old flags and
their behavior will be kept until 17.08 and will be removed in 17.11.
  
-* ethdev: Tx offloads will no longer be enabled by default in 17.11.

-  Instead, the ``rte_eth_txmode`` structure will be extended with
-  bit field to enable each Tx offload.
-  Besides of making the Rx/Tx configuration API more consistent for the
-  application, PMDs will be able to provide a better out of the box 
performance.
-  As part of the work, ``ETH_TXQ_FLAGS_NO*`` will be superseded as well.
+* ethdev: a new Tx and Rx offload API was introduced on 17.11.
+  In the new API, offloads are divided into per-port and per-queue offloads.
+  Offloads are disabled by default and enabled per application request.
+  The old offloads API is target to be deprecated on 18.05. This includes:
+
+  - removal of ``ETH_TXQ_FLAGS_NO*`` flags.
+  - removal of ``txq_flags`` field from ``rte_eth_txconf`` struct.
+  - removal of the offloads bit-field from ``rte_eth_rxmode`` struct.
  
  * ethdev: the legacy filter API, including

``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well


Acked-by: Andrew Rybchenko 

Re: [dpdk-dev] [PATCH] mem: warn if address hint is not respected

[Jonas Pfefferle1]

"Burakov, Anatoly"  wrote on 11/07/2017 02:54:24
PM:

> From: "Burakov, Anatoly" 
> To: Thomas Monjalon 
> Cc: dev@dpdk.org, Jonas Pfefferle ,
jianfeng@intel.com
> Date: 11/07/2017 02:54 PM
> Subject: Re: [dpdk-dev] [PATCH] mem: warn if address hint is not
respected
>
> On 06-Nov-17 8:26 PM, Thomas Monjalon wrote:
> > 31/10/2017 10:08, Jonas Pfefferle:
> >> Print a warning if the --base-virtaddr hint is not respected
> >> since this might lead to problems when mapping memory in
> >> the secondary process.
> >>
> >> Signed-off-by: Jonas Pfefferle 
> >
> > Anatoly, please review this patch.
> > It does not seem to fix something, so it is candidate for 18.02.
> >
>
> For some reason my Thunderbird ate the original email, so i'll reply to
> this one.
>
> One nitpick would be that we're calling get_virtual_area many times and
> it would probably be a good idea to make pagesize static and call
> sysconf only once. Otherwise,

We should address this in a separate patch and introduce a pagesize
function
for everyone to use. sysconf is used like this all over the place.

>
> Acked-by: Anatoly Burakov 
>
> --
> Thanks,
> Anatoly
>

[dpdk-dev] [PATCH] net/nfp: initialize stats struct

[Alejandro Lucero]

Not all struct fields will be written and random data could
confuse readers.

Fixes: 92aa491b881e ("nfp: add statistics")
Coverity: 140755

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfp_net.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 83dec06..0501156 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1038,6 +1038,8 @@ enum nfp_qcp_ptr {
 
/* RTE_ETHDEV_QUEUE_STAT_CNTRS default value is 16 */
 
+   memset(&nfp_dev_stats, 0, sizeof(nfp_dev_stats));
+
/* reading per RX ring stats */
for (i = 0; i < dev->data->nb_rx_queues; i++) {
if (i == RTE_ETHDEV_QUEUE_STAT_CNTRS)
-- 
1.9.1

Re: [dpdk-dev] [dpdk-stable] [PATCH v2] igb_uio: prevent reset for a list of devices

[Chas Williams]

On Tue, Nov 7, 2017 at 5:26 PM, Ferruh Yigit  wrote:

> On 11/7/2017 12:47 PM, Chas Williams wrote:
> > I will confess I haven't looked into the issue too hard since I have a
> > workaround.  My first guess is that there is something going on with the
> IOMMU
> > and quiescing a PCI pass-through device/function from the guest (since I
> don't
> > think the IOMMU is "visible" to the guest) seems iffy.
> >
> > Most devices have some sort of reset to put the device into a known
> state for
> > setup/configuration (or enable/disable for the DMA engines).  If this is
> done at
> > .dev_close(), shouldn't that be as sufficient as resetting the function?
>
> This is for the cases DPDK app terminated unexpectedly, proper exit path
> already
> does cleanup.
>

Call a usermode helper from igb_uio that does an open/close on the device
about to be released?


>
> >
> > On Tue, Nov 7, 2017 at 1:49 PM, Ferruh Yigit  > > wrote:
> >
> > On 11/7/2017 10:12 AM, Chas Williams wrote:
> > > Environment: Dell PowerEdge R730, Intel Corporation 82599ES
> 10-Gigabit
> > SFI/SFP+
> > > Network Connection shared via PCI pass-through
> > > Host: Debian 8
> > > Guest: Custom Debian 8 with DPDK application based on 17.11
> > >
> > > When we shutdown the guest, the kernel panics with:
> > >
> > > [  279.021818] Do you have a strange power saving mode enabled?
> > > [  279.021819] Dazed and confused, but trying to continue
> > > [  279.021847] {1}[Hardware Error]: Hardware error from APEI
> Generic Hardware
> > > Error Source: 3
> > > [  279.021849] {1}[Hardware Error]: event severity: fatal
> > > [  279.021850] {1}[Hardware Error]:  Error 0, type: fatal
> > > [  279.021851] {1}[Hardware Error]:   section_type: PCIe error
> > > [  279.021852] {1}[Hardware Error]:   port_type: 0, PCIe end point
> > > [  279.021853] {1}[Hardware Error]:   version: 1.16
> > > [  279.021854] {1}[Hardware Error]:   command: 0x0507, status:
> 0x4010
> > > [  279.021855] {1}[Hardware Error]:   device_id: :03:00.0
> > > [  279.021855] {1}[Hardware Error]:   slot: 0
> > > [  279.021856] {1}[Hardware Error]:   secondary_bus: 0x00
> > > [  279.021857] {1}[Hardware Error]:   vendor_id: 0x8086,
> device_id: 0x10fb
> > > [  279.021858] {1}[Hardware Error]:   class_code: 02
> > > [  279.021859] Kernel panic - not syncing: Fatal hardware error!
> > > [  279.021977] sched: Unexpected reschedule of offline CPU#1!
> > > [  279.021984] [ cut here ]
> > > [  279.021992] WARNING: CPU: 43 PID: 2807 at
> > > /build/linux-fHlJSJ/linux-4.12.6/arch/x86/kernel/smp.c:128
> > > native_smp_send_reschedule+0x34/0x40
> > > [  279.021993] Modules linked in: vfio_pci vfio_virqfd
> vfio_iommu_type1 vfio
> > > openvswitch nf_conntrack_ipv6 nf_nat_ipv6 nf_conntrack_ipv4
> nf_defrag_ipv4
> > > nf_nat_ipv4 nf_defrag_ipv6 nf_nat nf_conntrack libcrc32c
> crc32c_generic nfsd
> > > nfs_aclr
> > > pcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace
> sunrpc
> > fscache tun
> > > intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp
> > kvm_intel kvm
> > > irqbypass mgag200 ttm drm_kms_helper drm joydev crct10dif_pclmul
> crc32_pclmu
> > > l ghash_clmulni_intel i2c_algo_bit ipmi_si ipmi_devintf iTCO_wdt
> intel_cstate
> > > iTCO_vendor_support evdev intel_uncore mxm_wmi lpc_ich
> ipmi_msghandler
> > mfd_core
> > > ioatdma intel_rapl_perf dcdbas pcspkr shpchp mei_me button wmi mei
> > acpi_power_m
> > > eter tpm_crb autofs4 ext4 crc16 jbd2 fscrypto mbcache sr_mod cdrom
> sg
> > > hid_generic usbhid hid sd_mod
> > > [  279.022044]  crc32c_intel aesni_intel aes_x86_64 crypto_simd
> cryptd
> > > glue_helper ahci ehci_pci libahci ehci_hcd ixgbe libata
> megaraid_sas
> > usbcore dca
> > > i40e usb_common ptp pps_core scsi_mod mdio
> > > [  279.022060] CPU: 43 PID: 2807 Comm: revalidator85 Not tainted
> > 4.12.0-1-amd64
> > > #1 Debian 4.12.6-1
> > > [  279.022061] Hardware name: Dell Inc. PowerEdge R730/0WCJNT,
> BIOS 2.3.4
> > 11/08/2016
> > > [  279.022062] task: 91d0473f7100 task.stack: afef8f4a4000
> > > [  279.022066] RIP: 0010:native_smp_send_reschedule+0x34/0x40
> > > [  279.022067] RSP: 0018:afef8f4a7c98 EFLAGS: 00010082
> > > [  279.022069] RAX: 002e RBX: 91d059d24080 RCX:
> > 0001
> > > [  279.022070] RDX:  RSI: 0002 RDI:
> > 0046
> > > [  279.022071] RBP: 91d04691d100 R08:  R09:
> > 002e
> > > [  279.022072] R10: afef8f4a7c90 R11: 001cbb78 R12:
> > 91d85d21ae80
> > > [  279.022073] R13: 91d059d24000 R14: 0002 R15:
> > 0008
> > > [  279.022075] FS:  7f726affd700()
> GS:91d85d7

[dpdk-dev] [PATCH v1] net/mlx4: improve Rx packet type offloads report

[Moti Haimovsky]

This patch improves Rx packet type offload report in case the device is
a virtual function device. L2 tunnel indications are not reported by
those devices and therefore should not be checked by the PMD.

Fixes: aee4a03fee4f ("net/mlx4: enhance Rx packet type offloads")

Signed-off-by: Moti Haimovsky 
---
 drivers/net/mlx4/mlx4.c  | 2 ++
 drivers/net/mlx4/mlx4.h  | 1 +
 drivers/net/mlx4/mlx4_rxq.c  | 1 +
 drivers/net/mlx4/mlx4_rxtx.c | 9 ++---
 drivers/net/mlx4/mlx4_rxtx.h | 1 +
 5 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index f9e4f9d..efff65d 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -573,6 +573,8 @@ struct mlx4_conf {
 PCI_DEVICE_ID_MELLANOX_CONNECTX3PRO);
DEBUG("L2 tunnel checksum offloads are %ssupported",
  (priv->hw_csum_l2tun ? "" : "not "));
+   /* VFs are not configured to offload L2 tunnels */
+   priv->hw_l2tun_offload = !vf;
/* Configure the first MAC address by default. */
if (mlx4_get_mac(priv, &mac.addr_bytes)) {
ERROR("cannot get MAC address, is mlx4_en loaded?"
diff --git a/drivers/net/mlx4/mlx4.h b/drivers/net/mlx4/mlx4.h
index 3aeef87..cbb8628 100644
--- a/drivers/net/mlx4/mlx4.h
+++ b/drivers/net/mlx4/mlx4.h
@@ -128,6 +128,7 @@ struct priv {
uint32_t isolated:1; /**< Toggle isolated mode. */
uint32_t hw_csum:1; /* Checksum offload is supported. */
uint32_t hw_csum_l2tun:1; /* Checksum support for L2 tunnels. */
+   uint32_t hw_l2tun_offload:1; /**< L2 tunnel offload is configured. */
struct rte_intr_handle intr_handle; /**< Port interrupt handle. */
struct mlx4_drop *drop; /**< Shared resources for drop flow rules. */
LIST_HEAD(, mlx4_rss) rss; /**< Shared targets for Rx flow rules. */
diff --git a/drivers/net/mlx4/mlx4_rxq.c b/drivers/net/mlx4/mlx4_rxq.c
index 8b97a89..802be84 100644
--- a/drivers/net/mlx4/mlx4_rxq.c
+++ b/drivers/net/mlx4/mlx4_rxq.c
@@ -750,6 +750,7 @@ struct mlx4_rss *
 dev->data->dev_conf.rxmode.hw_ip_checksum),
.csum_l2tun = (priv->hw_csum_l2tun &&
   dev->data->dev_conf.rxmode.hw_ip_checksum),
+   .l2tun_offload = priv->hw_l2tun_offload,
.stats = {
.idx = idx,
},
diff --git a/drivers/net/mlx4/mlx4_rxtx.c b/drivers/net/mlx4/mlx4_rxtx.c
index 3985e06..1131d56 100644
--- a/drivers/net/mlx4/mlx4_rxtx.c
+++ b/drivers/net/mlx4/mlx4_rxtx.c
@@ -37,6 +37,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -751,7 +752,8 @@ struct pv {
  *   Packet type for struct rte_mbuf.
  */
 static inline uint32_t
-rxq_cq_to_pkt_type(volatile struct mlx4_cqe *cqe)
+rxq_cq_to_pkt_type(volatile struct mlx4_cqe *cqe,
+  uint32_t l2tun_offload)
 {
uint8_t idx = 0;
uint32_t pinfo = rte_be_to_cpu_32(cqe->vlan_my_qpn);
@@ -762,7 +764,7 @@ struct pv {
 *  bit[7] - MLX4_CQE_L2_TUNNEL
 *  bit[6] - MLX4_CQE_L2_TUNNEL_IPV4
 */
-   if (!(pinfo & MLX4_CQE_L2_VLAN_MASK) && (pinfo & MLX4_CQE_L2_TUNNEL))
+   if (l2tun_offload && (pinfo & MLX4_CQE_L2_TUNNEL))
idx |= ((pinfo & MLX4_CQE_L2_TUNNEL) >> 20) |
   ((pinfo & MLX4_CQE_L2_TUNNEL_IPV4) >> 19);
/*
@@ -960,7 +962,8 @@ struct pv {
}
pkt = seg;
/* Update packet information. */
-   pkt->packet_type = rxq_cq_to_pkt_type(cqe);
+   pkt->packet_type =
+   rxq_cq_to_pkt_type(cqe, rxq->l2tun_offload);
pkt->ol_flags = 0;
pkt->pkt_len = len;
if (rxq->csum | rxq->csum_l2tun) {
diff --git a/drivers/net/mlx4/mlx4_rxtx.h b/drivers/net/mlx4/mlx4_rxtx.h
index 4acad80..463df2b 100644
--- a/drivers/net/mlx4/mlx4_rxtx.h
+++ b/drivers/net/mlx4/mlx4_rxtx.h
@@ -80,6 +80,7 @@ struct rxq {
volatile uint32_t *rq_db; /**< RQ doorbell record. */
uint32_t csum:1; /**< Enable checksum offloading. */
uint32_t csum_l2tun:1; /**< Same for L2 tunnels. */
+   uint32_t l2tun_offload:1; /**< L2 tunnel offload is enabled. */
struct mlx4_cq mcq;  /**< Info for directly manipulating the CQ. */
struct mlx4_rxq_stats stats; /**< Rx queue counters. */
unsigned int socket; /**< CPU socket ID for allocations. */
-- 
1.8.3.1

[dpdk-dev] [PATCH] net/liquidio: add support for device reset in driver

[Shijith Thotton]

Reset device during init and close if bound to igb_uio.

Fixes: 369db3ae8e91 ("igb_uio: remove device reset in release")
Cc: sta...@dpdk.org

Signed-off-by: Shijith Thotton 
---
Hi Thomas/Ferruh,

Please consider this patch for 17.11 as removing reset from igb_uio breaks
LiquidIO PMD[1]. Here I have added support for reset within driver if the kernel
driver in use is igb_uio.

1. http://dpdk.org/ml/archives/dev/2017-October/079483.html

Thanks,
Shijith
---
 drivers/net/liquidio/base/lio_23xx_vf.c | 19 +++
 drivers/net/liquidio/base/lio_23xx_vf.h |  2 ++
 drivers/net/liquidio/base/lio_hw_defs.h |  3 +++
 drivers/net/liquidio/base/lio_mbox.h|  1 +
 drivers/net/liquidio/lio_ethdev.c   | 12 
 5 files changed, 37 insertions(+)

diff --git a/drivers/net/liquidio/base/lio_23xx_vf.c 
b/drivers/net/liquidio/base/lio_23xx_vf.c
index 9978017..e30c20d 100644
--- a/drivers/net/liquidio/base/lio_23xx_vf.c
+++ b/drivers/net/liquidio/base/lio_23xx_vf.c
@@ -379,6 +379,25 @@
cn23xx_vf_reset_io_queues(lio_dev, num_queues);
 }
 
+void
+cn23xx_vf_ask_pf_to_do_flr(struct lio_device *lio_dev)
+{
+   struct lio_mbox_cmd mbox_cmd;
+
+   memset(&mbox_cmd, 0, sizeof(struct lio_mbox_cmd));
+   mbox_cmd.msg.s.type = LIO_MBOX_REQUEST;
+   mbox_cmd.msg.s.resp_needed = 0;
+   mbox_cmd.msg.s.cmd = LIO_VF_FLR_REQUEST;
+   mbox_cmd.msg.s.len = 1;
+   mbox_cmd.q_no = 0;
+   mbox_cmd.recv_len = 0;
+   mbox_cmd.recv_status = 0;
+   mbox_cmd.fn = NULL;
+   mbox_cmd.fn_arg = 0;
+
+   lio_mbox_write(lio_dev, &mbox_cmd);
+}
+
 static void
 cn23xx_pfvf_hs_callback(struct lio_device *lio_dev,
struct lio_mbox_cmd *cmd, void *arg)
diff --git a/drivers/net/liquidio/base/lio_23xx_vf.h 
b/drivers/net/liquidio/base/lio_23xx_vf.h
index 83dc053..ad8db0d 100644
--- a/drivers/net/liquidio/base/lio_23xx_vf.h
+++ b/drivers/net/liquidio/base/lio_23xx_vf.h
@@ -87,6 +87,8 @@
 
 #define CN23XX_VF_BUSY_READING_REG_LOOP_COUNT  10
 
+void cn23xx_vf_ask_pf_to_do_flr(struct lio_device *lio_dev);
+
 int cn23xx_pfvf_handshake(struct lio_device *lio_dev);
 
 int cn23xx_vf_setup_device(struct lio_device  *lio_dev);
diff --git a/drivers/net/liquidio/base/lio_hw_defs.h 
b/drivers/net/liquidio/base/lio_hw_defs.h
index d4cd23c..fe5c3bb 100644
--- a/drivers/net/liquidio/base/lio_hw_defs.h
+++ b/drivers/net/liquidio/base/lio_hw_defs.h
@@ -80,6 +80,9 @@
 /* Max IOQs per LIO Link */
 #define LIO_MAX_IOQS_PER_IF64
 
+/* Wait time in milliseconds for FLR */
+#define LIO_PCI_FLR_WAIT   100
+
 enum lio_card_type {
LIO_23XX /* 23xx */
 };
diff --git a/drivers/net/liquidio/base/lio_mbox.h 
b/drivers/net/liquidio/base/lio_mbox.h
index f1c5b8e..b0875d6 100644
--- a/drivers/net/liquidio/base/lio_mbox.h
+++ b/drivers/net/liquidio/base/lio_mbox.h
@@ -43,6 +43,7 @@
 #define LIO_MBOX_DATA_MAX  32
 
 #define LIO_VF_ACTIVE  0x1
+#define LIO_VF_FLR_REQUEST 0x2
 #define LIO_CORES_CRASHED  0x3
 
 /* Macro for Read acknowledgment */
diff --git a/drivers/net/liquidio/lio_ethdev.c 
b/drivers/net/liquidio/lio_ethdev.c
index 4b18966..84b8a32 100644
--- a/drivers/net/liquidio/lio_ethdev.c
+++ b/drivers/net/liquidio/lio_ethdev.c
@@ -1636,6 +1636,11 @@ struct rte_lio_xstats_name_off {
rte_write32(pkt_count, droq->pkts_sent_reg);
}
 
+   if (lio_dev->pci_dev->kdrv == RTE_KDRV_IGB_UIO) {
+   cn23xx_vf_ask_pf_to_do_flr(lio_dev);
+   rte_delay_ms(LIO_PCI_FLR_WAIT);
+   }
+
/* lio_free_mbox */
lio_dev->fn_list.free_mbox(lio_dev);
 
@@ -2009,6 +2014,13 @@ static int lio_dev_configure(struct rte_eth_dev *eth_dev)
if (cn23xx_pfvf_handshake(lio_dev))
goto error;
 
+   /* Request and wait for device reset. */
+   if (pdev->kdrv == RTE_KDRV_IGB_UIO) {
+   cn23xx_vf_ask_pf_to_do_flr(lio_dev);
+   /* FLR wait time doubled as a precaution. */
+   rte_delay_ms(LIO_PCI_FLR_WAIT * 2);
+   }
+
if (cn23xx_vf_set_io_queues_off(lio_dev)) {
lio_dev_err(lio_dev, "Setting io queues off failed\n");
goto error;
-- 
1.8.3.1

[dpdk-dev] [PATCH] net/nfp: fix memory allocation

[Alejandro Lucero]

If the function actually returns a null value, a null pointer
dereference will occur.

Fixes: dd63df2bfff3 ("net/nfp: add NSP symbol resolution command")
Coverity: 195013

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfp_nspu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/nfp/nfp_nspu.c b/drivers/net/nfp/nfp_nspu.c
index 6ba940c..a2819a1 100644
--- a/drivers/net/nfp/nfp_nspu.c
+++ b/drivers/net/nfp/nfp_nspu.c
@@ -411,6 +411,9 @@
int ret = 0;
 
sym_buf = malloc(desc->buf_size);
+   if (!sym_buf)
+   return -ENOMEM;
+
strncpy(sym_buf, symbl, strlen(symbl));
ret = nspu_command(desc, NSP_CMD_GET_SYMBOL, 1, 1, sym_buf,
   NFP_SYM_DESC_LEN, strlen(symbl));
-- 
1.9.1

[dpdk-dev] [PATCH] net/nfp: fix resource leak

[Alejandro Lucero]

File descriptor is not released in any potential exit path
inside the function.

Fixes: f37d8a4b67b2 ("net/nfp: add NSP FW upload command")
Coverity: 195018

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfp_nspu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/nfp/nfp_nspu.c b/drivers/net/nfp/nfp_nspu.c
index a2819a1..3c8cdad 100644
--- a/drivers/net/nfp/nfp_nspu.c
+++ b/drivers/net/nfp/nfp_nspu.c
@@ -351,12 +351,14 @@
RTE_LOG(INFO, PMD, "fw file too big: %" PRIu64
   " bytes (%" PRIu64 " max)",
  (uint64_t)fsize, (uint64_t)size);
+   close(fw_f);
return -EINVAL;
}
 
fw_buf = malloc((size_t)size);
if (!fw_buf) {
RTE_LOG(INFO, PMD, "malloc failed for fw buffer");
+   close(fw_f);
return -ENOMEM;
}
memset(fw_buf, 0, size);
@@ -367,12 +369,14 @@
   "Just %" PRIu64 " of %" PRIu64 " bytes 
read.",
   (uint64_t)bytes, (uint64_t)fsize);
free(fw_buf);
+   close(fw_f);
return -EIO;
}
 
ret = nspu_command(nspu_desc, NSP_CMD_FW_LOAD, 0, 1, fw_buf, 0, bytes);
 
free(fw_buf);
+   close(fw_f);
 
return ret;
 }
-- 
1.9.1

Re: [dpdk-dev] [PATCH v4 0/4] fix race condition in enqueue/dequeue because of cpu reorder

[Bruce Richardson]

On Wed, Nov 08, 2017 at 09:54:37AM +, Jia He wrote:
> We watched a rte panic of mbuf_autotest in our qualcomm arm64 server
> due to a possible race condition.
> 
> To fix this race, there are 2 options as suggested by Jerin: 1. use
> rte_smp_rmb 2. use load_acquire/store_release(refer to [2]).
> CONFIG_RTE_RING_USE_C11_MEM_MODEL is provided, and by default it is
> "y" only on arm64 so far.
> 
> The reason why providing 2 options is due to the performance benchmark
> difference in different arm machines.
> 
> Already fuctionally tested on the machines as follows: - on X86 - on
> arm64 with CONFIG_RTE_RING_USE_C11_MEM_MODEL=y - on arm64 with
> CONFIG_RTE_RING_USE_C11_MEM_MODEL=n
> 
> --- Changelog: V4: split into small patches V3: arch specific
> implementation for enqueue/dequeue barrier V2: let users choose
> whether using load_acquire/store_release V1: rte_smp_rmb() between 2
> loads
> 
> Jia He (4): eal/arm64: remove the braces {} for dmb() and dsb() ring:
> guarantee load/load order in enqueue and dequeue ring: introduce new
> header file to include common functions ring: introduce new header
> file to support C11 memory model
> 
I'm wondering what the merge plans are for this set, given we are now
past RC3 in 17.11? As the rings are broken on ARM machines we need to
merge in some fix, but I'm a little concerned about the scope of the
changes from the 3rd and 4th patches. Would it be acceptable to just
merge in patches 1 & 2 in 17.11 and leave the rework and C11 memory
model additions in patches 3 & 4 to 18.02 release?

Regards,
/Bruce

[dpdk-dev] [PATCH] net/nfp: check function return value

[Alejandro Lucero]

The fstat function could return a value that indicates an error condition.
If this is not checked, the error condition may not be handled correctly.

Fixes: f37d8a4b67b2 ("net/nfp: add NSP FW upload command")
Coverity: 195019

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfp_nspu.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/nfp/nfp_nspu.c b/drivers/net/nfp/nfp_nspu.c
index 3c8cdad..39d14e6 100644
--- a/drivers/net/nfp/nfp_nspu.c
+++ b/drivers/net/nfp/nfp_nspu.c
@@ -341,7 +341,12 @@
return -ENOENT;
}
 
-   fstat(fw_f, &file_stat);
+   if (fstat(fw_f, &file_stat) < 0) {
+   RTE_LOG(INFO, PMD, "Firmware file %s/%s size is unknown",
+   DEFAULT_FW_PATH, DEFAULT_FW_FILENAME);
+   close(fw_f);
+   return -ENOENT;
+   }
 
fsize = file_stat.st_size;
RTE_LOG(DEBUG, PMD, "Firmware file with size: %" PRIu64 "\n",
-- 
1.9.1

[dpdk-dev] [PATCH] net/nfp: check BAR size is above a safe size

[Alejandro Lucero]

We do not know how big can the BAR be, but we know anything less
than 1MB is an error. This BAR needs to be big enough for accessing
most of NFP internals.

Fixes: d12206e00590 ("net/nfp: add NSP user space interface")
Coverity: 195024

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfp_nfpu.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/nfp/nfp_nfpu.c b/drivers/net/nfp/nfp_nfpu.c
index 5775d8d..f11afef 100644
--- a/drivers/net/nfp/nfp_nfpu.c
+++ b/drivers/net/nfp/nfp_nfpu.c
@@ -75,8 +75,13 @@
/* barsz in log2 */
while (barsz >>= 1)
i++;
+
barsz = i;
 
+   /* Sanity check: we can assume any bar size less than 1MB an error */
+   if (barsz < 20)
+   return -1;
+
/* Getting address for NFP expansion BAR registers */
cfg_base = pci_dev->mem_resource[0].addr;
cfg_base = (uint8_t *)cfg_base + NFP_CFG_EXP_BAR_CFG_BASE;
-- 
1.9.1

[dpdk-dev] [PATCH] test/memzone: fixing memory leak in memzone autotest

[Radoslaw Biernacki]

This patch fixes the memory leaks in memzone_autotest. Those memory leaks
lead to failures in tests from the same testing group due to out of memory
problems.  With introduction of rte_memzone_free() it is now possible to
free the memzone.  Fix uses this API call to make a clean after each test
case.

Fixes: ff909fe21f0a ("mem: introduce memzone freeing")

Signed-off-by: Radoslaw Biernacki 
---
 test/test/test_memzone.c | 135 ++-
 1 file changed, 134 insertions(+), 1 deletion(-)

diff --git a/test/test/test_memzone.c b/test/test/test_memzone.c
index c9394c4..1cf235a 100644
--- a/test/test/test_memzone.c
+++ b/test/test/test_memzone.c
@@ -176,6 +176,10 @@ test_memzone_reserve_flags(void)
printf("hugepage_sz not equal 2M\n");
return -1;
}
+   if (rte_memzone_free(mz)) {
+   printf("Fail memzone free\n");
+   return -1;
+   }
 
mz = rte_memzone_reserve("flag_zone_2M_HINT", size, 
SOCKET_ID_ANY,
RTE_MEMZONE_2MB|RTE_MEMZONE_SIZE_HINT_ONLY);
@@ -187,6 +191,10 @@ test_memzone_reserve_flags(void)
printf("hugepage_sz not equal 2M\n");
return -1;
}
+   if (rte_memzone_free(mz)) {
+   printf("Fail memzone free\n");
+   return -1;
+   }
 
/* Check if 1GB huge pages are unavailable, that function fails 
unless
 * HINT flag is indicated
@@ -202,6 +210,10 @@ test_memzone_reserve_flags(void)
printf("hugepage_sz not equal 2M\n");
return -1;
}
+   if (rte_memzone_free(mz)) {
+   printf("Fail memzone free\n");
+   return -1;
+   }
 
mz = rte_memzone_reserve("flag_zone_1G", size, 
SOCKET_ID_ANY,
RTE_MEMZONE_1GB);
@@ -224,6 +236,10 @@ test_memzone_reserve_flags(void)
printf("hugepage_sz not equal 1G\n");
return -1;
}
+   if (rte_memzone_free(mz)) {
+   printf("Fail memzone free\n");
+   return -1;
+   }
 
mz = rte_memzone_reserve("flag_zone_1G_HINT", size, 
SOCKET_ID_ANY,
RTE_MEMZONE_1GB|RTE_MEMZONE_SIZE_HINT_ONLY);
@@ -235,6 +251,10 @@ test_memzone_reserve_flags(void)
printf("hugepage_sz not equal 1G\n");
return -1;
}
+   if (rte_memzone_free(mz)) {
+   printf("Fail memzone free\n");
+   return -1;
+   }
 
/* Check if 1GB huge pages are unavailable, that function fails 
unless
 * HINT flag is indicated
@@ -250,12 +270,20 @@ test_memzone_reserve_flags(void)
printf("hugepage_sz not equal 1G\n");
return -1;
}
+   if (rte_memzone_free(mz)) {
+   printf("Fail memzone free\n");
+   return -1;
+   }
mz = rte_memzone_reserve("flag_zone_2M", size, 
SOCKET_ID_ANY,
RTE_MEMZONE_2MB);
if (mz != NULL) {
printf("MEMZONE FLAG 2MB\n");
return -1;
}
+   if (rte_memzone_free(mz)) {
+   printf("Fail memzone free\n");
+   return -1;
+   }
}
 
if (hugepage_2MB_avail && hugepage_1GB_avail) {
@@ -285,6 +313,10 @@ test_memzone_reserve_flags(void)
printf("hugepage_sz not equal 16M\n");
return -1;
}
+   if (rte_memzone_free(mz)) {
+   printf("Fail memzone free\n");
+   return -1;
+   }
 
mz = rte_memzone_reserve("flag_zone_16M_HINT", size,
SOCKET_ID_ANY, RTE_MEMZONE_16MB|RTE_MEMZONE_SIZE_HINT_ONLY);
@@ -296,6 +328,10 @@ test_memzone_reserve_flags(void)
printf("hugepage_sz not equal 16M\n");
return -1;
}
+   if (rte_memzone_free(mz)) {
+   printf("Fail memzone free\n");
+   return -1;
+   }
 
/* Check if 1GB huge pages are unavailable, that function fails
 * unless HINT flag is indicated
@@ -312,6 +348,10 @@ test_me

[dpdk-dev] [PATCH] doc: added inline crypto feature

[Radu Nicolau]

Signed-off-by: Radu Nicolau 
---
 doc/guides/nics/features.rst  | 17 +
 doc/guides/nics/features/default.ini  |  1 +
 doc/guides/nics/features/ixgbe.ini|  2 ++
 doc/guides/nics/features/ixgbe_vec.ini|  2 ++
 doc/guides/nics/features/ixgbe_vf.ini |  2 ++
 doc/guides/nics/features/ixgbe_vf_vec.ini |  2 ++
 6 files changed, 26 insertions(+)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index bfeae80..1170da8 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -900,6 +900,23 @@ Documentation describes performance values.
 See ``dpdk.org/doc/perf/*``.
 
 
+.. _nic_features_inline_crypto_doc:
+
+Inline crypto
+-
+
+Supports inline crypto processing (eg. inline IPsec). See Security library for 
more details.
+
+* **[uses]   rte_eth_rxconf,rte_eth_rxmode**: 
``offloads:DEV_RX_OFFLOAD_SECURITY``,
+* **[uses]   rte_eth_txconf,rte_eth_txmode**: 
``offloads:DEV_TX_OFFLOAD_SECURITY``.
+* **[implements] rte_security_ops**: ``session_create``, ``session_update``,
+  ``session_stats_get``, ``session_destroy``, ``set_pkt_metadata``, 
``capabilities_get``.
+* **[provides] rte_eth_dev_info**: 
``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_SECURITY``,
+  ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_SECURITY``.
+* **[provides]   mbuf**: ``mbuf.ol_flags:PKT_RX_SEC_OFFLOAD``,
+  ``mbuf.ol_flags:PKT_TX_SEC_OFFLOAD``, 
``mbuf.ol_flags:PKT_RX_SEC_OFFLOAD_FAILED``.
+
+
 
 .. _nic_features_other:
 
diff --git a/doc/guides/nics/features/default.ini 
b/doc/guides/nics/features/default.ini
index dc527dd..9ef6a2a 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -77,3 +77,4 @@ Usage doc=
 Design doc   =
 Perf doc =
 Mbuf fast free   =
+Inline crypto=
diff --git a/doc/guides/nics/features/ixgbe.ini 
b/doc/guides/nics/features/ixgbe.ini
index 9ff5d8f..900840f 100644
--- a/doc/guides/nics/features/ixgbe.ini
+++ b/doc/guides/nics/features/ixgbe.ini
@@ -58,3 +58,5 @@ Linux VFIO   = Y
 ARMv8= Y
 x86-32   = Y
 x86-64   = Y
+Inline crypto= Y
+
diff --git a/doc/guides/nics/features/ixgbe_vec.ini 
b/doc/guides/nics/features/ixgbe_vec.ini
index 4d56df4..5e32c08 100644
--- a/doc/guides/nics/features/ixgbe_vec.ini
+++ b/doc/guides/nics/features/ixgbe_vec.ini
@@ -47,3 +47,5 @@ Linux VFIO   = Y
 ARMv8= Y
 x86-32   = Y
 x86-64   = Y
+Inline crypto= Y
+
diff --git a/doc/guides/nics/features/ixgbe_vf.ini 
b/doc/guides/nics/features/ixgbe_vf.ini
index b63e32c..f217b09 100644
--- a/doc/guides/nics/features/ixgbe_vf.ini
+++ b/doc/guides/nics/features/ixgbe_vf.ini
@@ -37,3 +37,5 @@ Linux VFIO   = Y
 ARMv8= Y
 x86-32   = Y
 x86-64   = Y
+Inline crypto= Y
+
diff --git a/doc/guides/nics/features/ixgbe_vf_vec.ini 
b/doc/guides/nics/features/ixgbe_vf_vec.ini
index c994857..9549aab 100644
--- a/doc/guides/nics/features/ixgbe_vf_vec.ini
+++ b/doc/guides/nics/features/ixgbe_vf_vec.ini
@@ -29,3 +29,5 @@ Linux VFIO   = Y
 ARMv8= Y
 x86-32   = Y
 x86-64   = Y
+Inline crypto= Y
+
-- 
2.7.5

Re: [dpdk-dev] [PATCH v2] net/virtio: fix rxq intr config fails using vfio-pci

[Tan, Jianfeng]

Hi Zhiyong,


On 11/8/2017 7:03 PM, Zhiyong Yang wrote:

When running l3fwd-power to test virtio rxq interrupt using vfio
pci noiommu mode, startup fails. In the function virtio_read_caps,
the code if (flags & PCI_MSIX_ENABLE) intends to double check
if vfio msix is enabled or not. However, it is not enable at that
stage. So use_msix is assigned to "0", not "1", which causes the
failure of configuring rxq intr in l3fwd-power.
This patch adds the function vtpci_msix_detect to detect the status
of msix when interrupt changes happen.
In the meanwhile, virtio_intr_enable/disable are introduced to wrap
rte_intr_enable/disable to enhance the ability to detect msix. Only
support and enable msix can assign "1" to use_msix.


Should be "2". Better to use macro here.



Fixes: cb482cb3a305 ("net/virtio: fix MAC address read")
Signed-off-by: Zhiyong Yang 
---
  drivers/net/virtio/virtio_ethdev.c | 64 +-
  drivers/net/virtio/virtio_pci.c| 42 +
  drivers/net/virtio/virtio_pci.h|  5 +++
  3 files changed, 104 insertions(+), 7 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index d2576d5e0..525cfa06c 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -97,6 +97,9 @@ static void virtio_mac_addr_remove(struct rte_eth_dev *dev, 
uint32_t index);
  static void virtio_mac_addr_set(struct rte_eth_dev *dev,
struct ether_addr *mac_addr);
  
+static int virtio_intr_enable(struct rte_eth_dev *dev);

+static int virtio_intr_disable(struct rte_eth_dev *dev);
+
  static int virtio_dev_queue_stats_mapping_set(
struct rte_eth_dev *eth_dev,
uint16_t queue_id,
@@ -618,7 +621,7 @@ virtio_dev_close(struct rte_eth_dev *dev)
virtio_queues_unbind_intr(dev);
  
  	if (intr_conf->lsc || intr_conf->rxq) {

-   rte_intr_disable(dev->intr_handle);
+   virtio_intr_disable(dev);
rte_intr_efd_disable(dev->intr_handle);
rte_free(dev->intr_handle->intr_vec);
dev->intr_handle->intr_vec = NULL;
@@ -1160,6 +1163,44 @@ virtio_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
vlan_id, int on)
  }
  
  static int

+virtio_intr_enable(struct rte_eth_dev *dev)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   int msix_detect;


As I don't think we need to return a value except 0, 1, 2 as my comment 
at the end, so I suppose we just:


hw->use_msix = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));


+
+   if (rte_intr_enable(dev->intr_handle) < 0)
+   return -1;
+
+   msix_detect = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));


This breaks virtio_user. Need to add a check before this line.


+   if (msix_detect < 0)
+   return -1;
+   else if (msix_detect == SUPPORT_MSIX_STATUS_ENABLED)
+   hw->use_msix = 1;
+   else
+   hw->use_msix = 0;
+   return 0;
+}
+
+static int
+virtio_intr_disable(struct rte_eth_dev *dev)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+   int msix_detect;
+
+   if (rte_intr_disable(dev->intr_handle) < 0)
+   return -1;
+
+   msix_detect = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));


Ditto.


+   if (msix_detect < 0)
+   return -1;
+   else if (msix_detect == SUPPORT_MSIX_STATUS_ENABLED)
+   hw->use_msix = 1;
+   else
+   hw->use_msix = 0;
+   return 0;
+}
+
+static int
  virtio_negotiate_features(struct virtio_hw *hw, uint64_t req_features)
  {
uint64_t host_features;
@@ -1228,7 +1269,7 @@ virtio_interrupt_handler(void *param)
isr = vtpci_isr(hw);
PMD_DRV_LOG(INFO, "interrupt status = %#x", isr);
  
-	if (rte_intr_enable(dev->intr_handle) < 0)

+   if (virtio_intr_enable(dev) < 0)
PMD_DRV_LOG(ERR, "interrupt enable failed");
  
  	if (isr & VIRTIO_PCI_ISR_CONFIG) {

@@ -1348,7 +1389,7 @@ virtio_configure_intr(struct rte_eth_dev *dev)
 * to change the config size from 20 to 24, or VIRTIO_MSI_QUEUE_VECTOR
 * (22) will be ignored.
 */
-   if (rte_intr_enable(dev->intr_handle) < 0) {
+   if (virtio_intr_enable(dev) < 0) {
PMD_DRV_LOG(ERR, "interrupt enable failed");
return -1;
}
@@ -1370,7 +1411,15 @@ virtio_init_device(struct rte_eth_dev *eth_dev, uint64_t 
req_features)
struct virtio_net_config local_config;
struct rte_pci_device *pci_dev = NULL;
int ret;
+   int msix_detect;
  
+	msix_detect = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(eth_dev));

+   if (msix_detect < 0)
+   return -1;
+   else if (msix_detect == SUPPORT_MSIX_STATUS_ENABLED)
+   hw->use_msix = 1;
+   else
+   hw->use_msix = 0;


Ditto, we directly assign return value to hw->use_msix.


/* Reset the device although

Re: [dpdk-dev] [PATCH] doc: added inline crypto feature

[Thomas Monjalon]

Hi,

08/11/2017 14:26, Radu Nicolau:
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -900,6 +900,23 @@ Documentation describes performance values.
>  See ``dpdk.org/doc/perf/*``.
>  
>  
> +.. _nic_features_inline_crypto_doc:

This anchor seems useless.

> +
> +Inline crypto
> +-
> +
> +Supports inline crypto processing (eg. inline IPsec). See Security library 
> for more details.

As there are several types of inline crypto, don't you think it deserves
several separate features?

Re: [dpdk-dev] [PATCH] doc: added inline crypto feature

[Radu Nicolau]

On 11/8/2017 2:22 PM, Thomas Monjalon wrote:

Hi,

08/11/2017 14:26, Radu Nicolau:

--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -900,6 +900,23 @@ Documentation describes performance values.
  See ``dpdk.org/doc/perf/*``.
  
  
+.. _nic_features_inline_crypto_doc:

This anchor seems useless.

It is, I will remove it.



+
+Inline crypto
+-
+
+Supports inline crypto processing (eg. inline IPsec). See Security library for 
more details.

As there are several types of inline crypto, don't you think it deserves
several separate features?
We don't differentiate in the offload, net, mbuf APIs; it's all 
"security offload".
rte_security is the one that deals with different kinds of inline 
crypto, but in the NIC section it's all the same.

[dpdk-dev] [PATCH] net/nfp: fix null pointer check

[Alejandro Lucero]

First, the received pointer was not checked before. Then the pointer
from malloc was not the one used in the existing check.

Fixes: ad60bca34899 ("net/nfp: read PF port MAC addr using NSP")
Coverity: 195027

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfp_nspu.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/nfp/nfp_nspu.c b/drivers/net/nfp/nfp_nspu.c
index 39d14e6..0b415fc 100644
--- a/drivers/net/nfp/nfp_nspu.c
+++ b/drivers/net/nfp/nfp_nspu.c
@@ -618,10 +618,14 @@
 {
int ret;
 
+   if (!table)
+   return -EINVAL;
+
RTE_LOG(INFO, PMD, "Reading hw ethernet table...\n");
+
/* port 0 allocates the eth table and read it using NSPU */
*table = malloc(NSP_ETH_TABLE_SIZE);
-   if (!table)
+   if (!*table)
return -ENOMEM;
 
ret = nspu_command(desc, NSP_CMD_READ_ETH_TABLE, 1, 0, *table,
-- 
1.9.1

[dpdk-dev] [PATCH] net/nfp: release memory before exit

[Alejandro Lucero]

Memory allocated was not being released in any exit path.

Fixes: 48e2255f1b63 ("net/nfp: add NSP support for HW link configuration")
Coverity: 195030

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfp_nspu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/nfp/nfp_nspu.c b/drivers/net/nfp/nfp_nspu.c
index 0b415fc..f908983 100644
--- a/drivers/net/nfp/nfp_nspu.c
+++ b/drivers/net/nfp/nfp_nspu.c
@@ -566,6 +566,7 @@
   NSP_ETH_TABLE_SIZE, 0);
if (ret) {
rte_spinlock_unlock(&desc->nsp_lock);
+   free(entries);
return ret;
}
 
@@ -586,6 +587,7 @@
 
if (i == NSP_ETH_MAX_COUNT) {
rte_spinlock_unlock(&desc->nsp_lock);
+   free(entries);
return -EINVAL;
}
 
@@ -610,6 +612,7 @@
"Hw ethernet port %d configure failed\n", port);
}
rte_spinlock_unlock(&desc->nsp_lock);
+   free(entries);
return ret;
 }
 
-- 
1.9.1

Re: [dpdk-dev] [PATCH v1] net/mlx4: improve Rx packet type offloads report

[Adrien Mazarguil]

Hi Moti,

On Wed, Nov 08, 2017 at 02:02:45PM +0200, Moti Haimovsky wrote:
> This patch improves Rx packet type offload report in case the device is
> a virtual function device. L2 tunnel indications are not reported by
> those devices and therefore should not be checked by the PMD.
> 
> Fixes: aee4a03fee4f ("net/mlx4: enhance Rx packet type offloads")
> 
> Signed-off-by: Moti Haimovsky 

Does "not reporting them" cause any issue? Is this patch adding anything on
top of checking they can't be reported before not reporting them either?

Otherwise this additional unnecessary check may cause a minor performance
regression for no good reason.

I think this patch should really update mlx4_dev_supported_ptypes_get()
(control path) instead of rxq_cq_to_pkt_type() (data path). What's your
opinion?

A few other suggestions, see below.

> ---
>  drivers/net/mlx4/mlx4.c  | 2 ++
>  drivers/net/mlx4/mlx4.h  | 1 +
>  drivers/net/mlx4/mlx4_rxq.c  | 1 +
>  drivers/net/mlx4/mlx4_rxtx.c | 9 ++---
>  drivers/net/mlx4/mlx4_rxtx.h | 1 +
>  5 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index f9e4f9d..efff65d 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -573,6 +573,8 @@ struct mlx4_conf {
>PCI_DEVICE_ID_MELLANOX_CONNECTX3PRO);
>   DEBUG("L2 tunnel checksum offloads are %ssupported",
> (priv->hw_csum_l2tun ? "" : "not "));
> + /* VFs are not configured to offload L2 tunnels */
> + priv->hw_l2tun_offload = !vf;

Seeing how you're adding a new bit to this field, is hw_l2tun_offload really
different from hw_csum_l2tun? 

Can you get inner VXLAN checksums if the packet can't be recognized as VXLAN
in the first place? I don't think so.

Perhaps hw_csum_l2tun should be renamed, however in my opinion you could
simply update the hw_csum_l2tun assignment with a vf check and use that.

>   /* Configure the first MAC address by default. */
>   if (mlx4_get_mac(priv, &mac.addr_bytes)) {
>   ERROR("cannot get MAC address, is mlx4_en loaded?"
> diff --git a/drivers/net/mlx4/mlx4.h b/drivers/net/mlx4/mlx4.h
> index 3aeef87..cbb8628 100644
> --- a/drivers/net/mlx4/mlx4.h
> +++ b/drivers/net/mlx4/mlx4.h
> @@ -128,6 +128,7 @@ struct priv {
>   uint32_t isolated:1; /**< Toggle isolated mode. */
>   uint32_t hw_csum:1; /* Checksum offload is supported. */
>   uint32_t hw_csum_l2tun:1; /* Checksum support for L2 tunnels. */
> + uint32_t hw_l2tun_offload:1; /**< L2 tunnel offload is configured. */

This change would become unnecessary.

>   struct rte_intr_handle intr_handle; /**< Port interrupt handle. */
>   struct mlx4_drop *drop; /**< Shared resources for drop flow rules. */
>   LIST_HEAD(, mlx4_rss) rss; /**< Shared targets for Rx flow rules. */
> diff --git a/drivers/net/mlx4/mlx4_rxq.c b/drivers/net/mlx4/mlx4_rxq.c
> index 8b97a89..802be84 100644
> --- a/drivers/net/mlx4/mlx4_rxq.c
> +++ b/drivers/net/mlx4/mlx4_rxq.c
> @@ -750,6 +750,7 @@ struct mlx4_rss *
>dev->data->dev_conf.rxmode.hw_ip_checksum),
>   .csum_l2tun = (priv->hw_csum_l2tun &&
>  dev->data->dev_conf.rxmode.hw_ip_checksum),
> + .l2tun_offload = priv->hw_l2tun_offload,

Assuming a data path change is really needed, this one could likely stay
since it doesn't depend on the user enabling checksums.

>   .stats = {
>   .idx = idx,
>   },
> diff --git a/drivers/net/mlx4/mlx4_rxtx.c b/drivers/net/mlx4/mlx4_rxtx.c
> index 3985e06..1131d56 100644
> --- a/drivers/net/mlx4/mlx4_rxtx.c
> +++ b/drivers/net/mlx4/mlx4_rxtx.c
> @@ -37,6 +37,7 @@
>   */
>  
>  #include 
> +#include 

What for?

>  #include 
>  #include 
>  
> @@ -751,7 +752,8 @@ struct pv {
>   *   Packet type for struct rte_mbuf.
>   */
>  static inline uint32_t
> -rxq_cq_to_pkt_type(volatile struct mlx4_cqe *cqe)
> +rxq_cq_to_pkt_type(volatile struct mlx4_cqe *cqe,
> +uint32_t l2tun_offload)
>  {
>   uint8_t idx = 0;
>   uint32_t pinfo = rte_be_to_cpu_32(cqe->vlan_my_qpn);
> @@ -762,7 +764,7 @@ struct pv {
>*  bit[7] - MLX4_CQE_L2_TUNNEL
>*  bit[6] - MLX4_CQE_L2_TUNNEL_IPV4
>*/
> - if (!(pinfo & MLX4_CQE_L2_VLAN_MASK) && (pinfo & MLX4_CQE_L2_TUNNEL))
> + if (l2tun_offload && (pinfo & MLX4_CQE_L2_TUNNEL))
>   idx |= ((pinfo & MLX4_CQE_L2_TUNNEL) >> 20) |
>  ((pinfo & MLX4_CQE_L2_TUNNEL_IPV4) >> 19);
>   /*
> @@ -960,7 +962,8 @@ struct pv {
>   }
>   pkt = seg;
>   /* Update packet information. */
> - pkt->packet_type = rxq_cq_to_pkt_type(cqe);
> + pkt->packet_type =
> + rxq_cq_to_pkt_type(cqe, rxq->l2tun_offload);
> 

Re: [dpdk-dev] [PATCH v4 0/4] fix race condition in enqueue/dequeue because of cpu reorder

[Jia He]

Hi Bruce


On 11/8/2017 8:15 PM, Bruce Richardson Wrote:

On Wed, Nov 08, 2017 at 09:54:37AM +, Jia He wrote:

We watched a rte panic of mbuf_autotest in our qualcomm arm64 server
due to a possible race condition.

To fix this race, there are 2 options as suggested by Jerin: 1. use
rte_smp_rmb 2. use load_acquire/store_release(refer to [2]).
CONFIG_RTE_RING_USE_C11_MEM_MODEL is provided, and by default it is
"y" only on arm64 so far.

The reason why providing 2 options is due to the performance benchmark
difference in different arm machines.

Already fuctionally tested on the machines as follows: - on X86 - on
arm64 with CONFIG_RTE_RING_USE_C11_MEM_MODEL=y - on arm64 with
CONFIG_RTE_RING_USE_C11_MEM_MODEL=n

--- Changelog: V4: split into small patches V3: arch specific
implementation for enqueue/dequeue barrier V2: let users choose
whether using load_acquire/store_release V1: rte_smp_rmb() between 2
loads

Jia He (4): eal/arm64: remove the braces {} for dmb() and dsb() ring:
guarantee load/load order in enqueue and dequeue ring: introduce new
header file to include common functions ring: introduce new header
file to support C11 memory model


I'm wondering what the merge plans are for this set, given we are now
past RC3 in 17.11? As the rings are broken on ARM machines we need to
merge in some fix, but I'm a little concerned about the scope of the
changes from the 3rd and 4th patches. Would it be acceptable to just
merge in patches 1 & 2 in 17.11 and leave the rework and C11 memory
model additions in patches 3 & 4 to 18.02 release?

As far as I'm concerned, it is ok.

Cheers,
Jia

Re: [dpdk-dev] [PATCH] doc: added inline crypto feature

[Thomas Monjalon]

08/11/2017 15:31, Radu Nicolau:
> On 11/8/2017 2:22 PM, Thomas Monjalon wrote:
> > 08/11/2017 14:26, Radu Nicolau:
> >> +
> >> +Inline crypto
> >> +-
> >> +
> >> +Supports inline crypto processing (eg. inline IPsec). See Security 
> >> library for more details.
> > 
> > As there are several types of inline crypto, don't you think it deserves
> > several separate features?
> 
> We don't differentiate in the offload, net, mbuf APIs; it's all 
> "security offload".
> rte_security is the one that deals with different kinds of inline 
> crypto, but in the NIC section it's all the same.

OK
How can we document which kind of inline crypto is supported with which device?

Re: [dpdk-dev] [PATCH v1] net/mlx4: improve Rx packet type offloads report

[Mordechay Haimovsky]

Inline

> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Wednesday, November 8, 2017 4:58 PM
> To: Mordechay Haimovsky 
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v1] net/mlx4: improve Rx packet type offloads report
> 
> Hi Moti,
> 
> On Wed, Nov 08, 2017 at 02:02:45PM +0200, Moti Haimovsky wrote:
> > This patch improves Rx packet type offload report in case the device
> > is a virtual function device. L2 tunnel indications are not reported
> > by those devices and therefore should not be checked by the PMD.
> >
> > Fixes: aee4a03fee4f ("net/mlx4: enhance Rx packet type offloads")
> >
> > Signed-off-by: Moti Haimovsky 
> 
> Does "not reporting them" cause any issue? Is this patch adding anything on
> top of checking they can't be reported before not reporting them either?
> 
> Otherwise this additional unnecessary check may cause a minor performance
> regression for no good reason.
> 
In VFs (sriov VF devices) we see that the L2 tunnel flag is set which causes a 
complete misinterpretation of the packet type being received.
This happens since the tunnel_mode is not set to 0x7 by the driver and 
therefore has meaningless value in such case and should be ignored.
And yes, performance-wise there is probably an impact.
Another approach which will not affect performance can be to init the 
mlx4_ptype_table according to the device at hand (i.e. per-device table).
This however will require some effort :)

> I think this patch should really update mlx4_dev_supported_ptypes_get()
> (control path) instead of rxq_cq_to_pkt_type() (data path). What's your
> opinion?
> 
> A few other suggestions, see below.
> 
> > ---
> >  drivers/net/mlx4/mlx4.c  | 2 ++
> >  drivers/net/mlx4/mlx4.h  | 1 +
> >  drivers/net/mlx4/mlx4_rxq.c  | 1 +
> >  drivers/net/mlx4/mlx4_rxtx.c | 9 ++---
> > drivers/net/mlx4/mlx4_rxtx.h | 1 +
> >  5 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c index
> > f9e4f9d..efff65d 100644
> > --- a/drivers/net/mlx4/mlx4.c
> > +++ b/drivers/net/mlx4/mlx4.c
> > @@ -573,6 +573,8 @@ struct mlx4_conf {
> >  PCI_DEVICE_ID_MELLANOX_CONNECTX3PRO);
> > DEBUG("L2 tunnel checksum offloads are %ssupported",
> >   (priv->hw_csum_l2tun ? "" : "not "));
> > +   /* VFs are not configured to offload L2 tunnels */
> > +   priv->hw_l2tun_offload = !vf;
> 
> Seeing how you're adding a new bit to this field, is hw_l2tun_offload really
> different from hw_csum_l2tun?
> 
> Can you get inner VXLAN checksums if the packet can't be recognized as
> VXLAN in the first place? I don't think so.
> 
> Perhaps hw_csum_l2tun should be renamed, however in my opinion you
> could simply update the hw_csum_l2tun assignment with a vf check and use
> that.
> 
> > /* Configure the first MAC address by default. */
> > if (mlx4_get_mac(priv, &mac.addr_bytes)) {
> > ERROR("cannot get MAC address, is mlx4_en
> loaded?"
> > diff --git a/drivers/net/mlx4/mlx4.h b/drivers/net/mlx4/mlx4.h index
> > 3aeef87..cbb8628 100644
> > --- a/drivers/net/mlx4/mlx4.h
> > +++ b/drivers/net/mlx4/mlx4.h
> > @@ -128,6 +128,7 @@ struct priv {
> > uint32_t isolated:1; /**< Toggle isolated mode. */
> > uint32_t hw_csum:1; /* Checksum offload is supported. */
> > uint32_t hw_csum_l2tun:1; /* Checksum support for L2 tunnels. */
> > +   uint32_t hw_l2tun_offload:1; /**< L2 tunnel offload is configured.
> > +*/
> 
> This change would become unnecessary.
> 
> > struct rte_intr_handle intr_handle; /**< Port interrupt handle. */
> > struct mlx4_drop *drop; /**< Shared resources for drop flow rules.
> */
> > LIST_HEAD(, mlx4_rss) rss; /**< Shared targets for Rx flow rules. */
> > diff --git a/drivers/net/mlx4/mlx4_rxq.c b/drivers/net/mlx4/mlx4_rxq.c
> > index 8b97a89..802be84 100644
> > --- a/drivers/net/mlx4/mlx4_rxq.c
> > +++ b/drivers/net/mlx4/mlx4_rxq.c
> > @@ -750,6 +750,7 @@ struct mlx4_rss *
> >  dev->data->dev_conf.rxmode.hw_ip_checksum),
> > .csum_l2tun = (priv->hw_csum_l2tun &&
> >dev->data-
> >dev_conf.rxmode.hw_ip_checksum),
> > +   .l2tun_offload = priv->hw_l2tun_offload,
> 
> Assuming a data path change is really needed, this one could likely stay since
> it doesn't depend on the user enabling checksums.
> 
> > .stats = {
> > .idx = idx,
> > },
> > diff --git a/drivers/net/mlx4/mlx4_rxtx.c
> > b/drivers/net/mlx4/mlx4_rxtx.c index 3985e06..1131d56 100644
> > --- a/drivers/net/mlx4/mlx4_rxtx.c
> > +++ b/drivers/net/mlx4/mlx4_rxtx.c
> > @@ -37,6 +37,7 @@
> >   */
> >
> >  #include 
> > +#include 
> 
> What for?
> 
> >  #include 
> >  #include 
> >
> > @@ -751,7 +752,8 @@ struct pv {
> >   *   Packet type for struct rte_mbuf.
> >   */
> >  static inline uint32_t
> > -rxq_cq_to_pkt_type(volatile struct mlx4_c

Re: [dpdk-dev] [PATCH] doc: added inline crypto feature

[Radu Nicolau]

On 11/8/2017 3:13 PM, Thomas Monjalon wrote:

08/11/2017 15:31, Radu Nicolau:

On 11/8/2017 2:22 PM, Thomas Monjalon wrote:

08/11/2017 14:26, Radu Nicolau:

+
+Inline crypto
+-
+
+Supports inline crypto processing (eg. inline IPsec). See Security library for 
more details.

As there are several types of inline crypto, don't you think it deserves
several separate features?

We don't differentiate in the offload, net, mbuf APIs; it's all
"security offload".
rte_security is the one that deals with different kinds of inline
crypto, but in the NIC section it's all the same.

OK
How can we document which kind of inline crypto is supported with which device?
I propose to change "See Security library for more details" to "See 
Security library and PMD documentation for more details" and update 
ixgbe.rst with an "inline crypto" section.

Re: [dpdk-dev] [PATCH v1] net/mlx4: improve Rx packet type offloads report

[Adrien Mazarguil]

On Wed, Nov 08, 2017 at 03:33:57PM +, Mordechay Haimovsky wrote:
> Inline
> 
> > -Original Message-
> > From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> > Sent: Wednesday, November 8, 2017 4:58 PM
> > To: Mordechay Haimovsky 
> > Cc: dev@dpdk.org
> > Subject: Re: [PATCH v1] net/mlx4: improve Rx packet type offloads report
> > 
> > Hi Moti,
> > 
> > On Wed, Nov 08, 2017 at 02:02:45PM +0200, Moti Haimovsky wrote:
> > > This patch improves Rx packet type offload report in case the device
> > > is a virtual function device. L2 tunnel indications are not reported
> > > by those devices and therefore should not be checked by the PMD.
> > >
> > > Fixes: aee4a03fee4f ("net/mlx4: enhance Rx packet type offloads")
> > >
> > > Signed-off-by: Moti Haimovsky 
> > 
> > Does "not reporting them" cause any issue? Is this patch adding anything on
> > top of checking they can't be reported before not reporting them either?
> > 
> > Otherwise this additional unnecessary check may cause a minor performance
> > regression for no good reason.
> > 
> In VFs (sriov VF devices) we see that the L2 tunnel flag is set which causes 
> a complete misinterpretation of the packet type being received.
> This happens since the tunnel_mode is not set to 0x7 by the driver and 
> therefore has meaningless value in such case and should be ignored.

OK, please mention this in the commit log then, otherwise it doesn't look
like this patch addresses anything.

> And yes, performance-wise there is probably an impact.
> Another approach which will not affect performance can be to init the 
> mlx4_ptype_table according to the device at hand (i.e. per-device table).
> This however will require some effort :)

My remaining comments still stand, particularly the need to update
mlx4_dev_supported_ptypes_get() as well.

> 
> > I think this patch should really update mlx4_dev_supported_ptypes_get()
> > (control path) instead of rxq_cq_to_pkt_type() (data path). What's your
> > opinion?
> > 
> > A few other suggestions, see below.
> > 
> > > ---
> > >  drivers/net/mlx4/mlx4.c  | 2 ++
> > >  drivers/net/mlx4/mlx4.h  | 1 +
> > >  drivers/net/mlx4/mlx4_rxq.c  | 1 +
> > >  drivers/net/mlx4/mlx4_rxtx.c | 9 ++---
> > > drivers/net/mlx4/mlx4_rxtx.h | 1 +
> > >  5 files changed, 11 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c index
> > > f9e4f9d..efff65d 100644
> > > --- a/drivers/net/mlx4/mlx4.c
> > > +++ b/drivers/net/mlx4/mlx4.c
> > > @@ -573,6 +573,8 @@ struct mlx4_conf {
> > >PCI_DEVICE_ID_MELLANOX_CONNECTX3PRO);
> > >   DEBUG("L2 tunnel checksum offloads are %ssupported",
> > > (priv->hw_csum_l2tun ? "" : "not "));
> > > + /* VFs are not configured to offload L2 tunnels */
> > > + priv->hw_l2tun_offload = !vf;
> > 
> > Seeing how you're adding a new bit to this field, is hw_l2tun_offload really
> > different from hw_csum_l2tun?
> > 
> > Can you get inner VXLAN checksums if the packet can't be recognized as
> > VXLAN in the first place? I don't think so.
> > 
> > Perhaps hw_csum_l2tun should be renamed, however in my opinion you
> > could simply update the hw_csum_l2tun assignment with a vf check and use
> > that.
> > 
> > >   /* Configure the first MAC address by default. */
> > >   if (mlx4_get_mac(priv, &mac.addr_bytes)) {
> > >   ERROR("cannot get MAC address, is mlx4_en
> > loaded?"
> > > diff --git a/drivers/net/mlx4/mlx4.h b/drivers/net/mlx4/mlx4.h index
> > > 3aeef87..cbb8628 100644
> > > --- a/drivers/net/mlx4/mlx4.h
> > > +++ b/drivers/net/mlx4/mlx4.h
> > > @@ -128,6 +128,7 @@ struct priv {
> > >   uint32_t isolated:1; /**< Toggle isolated mode. */
> > >   uint32_t hw_csum:1; /* Checksum offload is supported. */
> > >   uint32_t hw_csum_l2tun:1; /* Checksum support for L2 tunnels. */
> > > + uint32_t hw_l2tun_offload:1; /**< L2 tunnel offload is configured.
> > > +*/
> > 
> > This change would become unnecessary.
> > 
> > >   struct rte_intr_handle intr_handle; /**< Port interrupt handle. */
> > >   struct mlx4_drop *drop; /**< Shared resources for drop flow rules.
> > */
> > >   LIST_HEAD(, mlx4_rss) rss; /**< Shared targets for Rx flow rules. */
> > > diff --git a/drivers/net/mlx4/mlx4_rxq.c b/drivers/net/mlx4/mlx4_rxq.c
> > > index 8b97a89..802be84 100644
> > > --- a/drivers/net/mlx4/mlx4_rxq.c
> > > +++ b/drivers/net/mlx4/mlx4_rxq.c
> > > @@ -750,6 +750,7 @@ struct mlx4_rss *
> > >dev->data->dev_conf.rxmode.hw_ip_checksum),
> > >   .csum_l2tun = (priv->hw_csum_l2tun &&
> > >  dev->data-
> > >dev_conf.rxmode.hw_ip_checksum),
> > > + .l2tun_offload = priv->hw_l2tun_offload,
> > 
> > Assuming a data path change is really needed, this one could likely stay 
> > since
> > it doesn't depend on the user enabling checksums.
> > 
> > >   .stats = {
> > >   .idx = idx,
> > >   },

Re: [dpdk-dev] [PATCH v4 0/4] fix race condition in enqueue/dequeue because of cpu reorder

[Jerin Jacob]

-Original Message-
> Date: Wed, 8 Nov 2017 23:11:32 +0800
> From: Jia He 
> To: Bruce Richardson 
> Cc: jerin.ja...@caviumnetworks.com, dev@dpdk.org, olivier.m...@6wind.com,
>  konstantin.anan...@intel.com, jianbo@arm.com, hemant.agra...@nxp.com
> Subject: Re: [PATCH v4 0/4] fix race condition in enqueue/dequeue because
>  of cpu reorder
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>  Thunderbird/52.4.0
> 
> Hi Bruce
> 
> 
> On 11/8/2017 8:15 PM, Bruce Richardson Wrote:
> > On Wed, Nov 08, 2017 at 09:54:37AM +, Jia He wrote:
> > > We watched a rte panic of mbuf_autotest in our qualcomm arm64 server
> > > due to a possible race condition.
> > > 
> > > To fix this race, there are 2 options as suggested by Jerin: 1. use
> > > rte_smp_rmb 2. use load_acquire/store_release(refer to [2]).
> > > CONFIG_RTE_RING_USE_C11_MEM_MODEL is provided, and by default it is
> > > "y" only on arm64 so far.
> > > 
> > > The reason why providing 2 options is due to the performance benchmark
> > > difference in different arm machines.
> > > 
> > > Already fuctionally tested on the machines as follows: - on X86 - on
> > > arm64 with CONFIG_RTE_RING_USE_C11_MEM_MODEL=y - on arm64 with
> > > CONFIG_RTE_RING_USE_C11_MEM_MODEL=n
> > > 
> > > --- Changelog: V4: split into small patches V3: arch specific
> > > implementation for enqueue/dequeue barrier V2: let users choose
> > > whether using load_acquire/store_release V1: rte_smp_rmb() between 2
> > > loads
> > > 
> > > Jia He (4): eal/arm64: remove the braces {} for dmb() and dsb() ring:
> > > guarantee load/load order in enqueue and dequeue ring: introduce new
> > > header file to include common functions ring: introduce new header
> > > file to support C11 memory model
> > > 
> > I'm wondering what the merge plans are for this set, given we are now
> > past RC3 in 17.11? As the rings are broken on ARM machines we need to
> > merge in some fix, but I'm a little concerned about the scope of the
> > changes from the 3rd and 4th patches. Would it be acceptable to just
> > merge in patches 1 & 2 in 17.11 and leave the rework and C11 memory
> > model additions in patches 3 & 4 to 18.02 release?
> As far as I'm concerned, it is ok.

It is OK to me as well. May be Jia can send 0-1 and 2-3 as separate
series with exiting comments.


> 
> Cheers,
> Jia
> 

[dpdk-dev] [RFC PATCH 0/2] RAW Device Support

[Hemant Agrawal]

Rawdevice Support in DPDK
-

This RFC describes support for rawdevices or generic device support in DPDK.
It is supported by following writeup accompanied by skeleton header file with
declarations.

Motivation
==

In terms of device flavor (type) support, DPDK currently has ethernet
(lib_ether), cryptodev (libcryptodev), eventdev (libeventdev) and vdev
(virtual device) support.

For a new type of device, for example an accelerator, there are not many
options except either:
1. create another lib/librte_MySpecialDev, driver/MySpecialDrv and use it
through Bus/PMD model.
2. Or, create a vdev and implement necessary custom APIs which are directly
exposed from driver layer. However this may still require changes in bus code
in DPDK.

Either method is unclean (touching lib for specific context) and possibly
non-upstreamable (custom APIs). Applications and customers prefers uniform
device view and programming model.


Scope
=

The rawdevice implementation is targetted towards various accelerator use cases
which cannot be generalized within existing device models. Aim is to provided a
generalized structure at the cost of portability guarantee. Specific PMDs may
also expose any specific config APIs. Applications built over such devices are
special use-cases involving IP blocks.

The rawdevice  may also connect to other standard devices using adapter or other
methods e.g. eventdev – single place to get all events.

Proposed Solution
=

Defining a very generic super-set of device type and its device operations that
can be exposed such that any new/upcoming/experimental device can be layered
over it. This RFC names it 'rawdevice' to signify that the device doesn't have
any flavor/type associated with it which is advertised (like net, crypto etc).

A *rte_rawdevice* is a raw/generic device without any standard configuration
or input/output method assumption.

Thus, driver for a new accelerator block, which requires operations for
start/stop/enqueue/dequeue, can be quickly strapped over this rawdevice layer.
Thereafter, any appropriate bus can scan for it (assuming device is discoverable
over the Linux interfaces like sysfs) and match it against registered drivers.

Similarly, for a new accelerator or a wireless device, which doesn't fit the eth
type, a driver can be registered with a bus (on which its device would be
scannable) and use this layer for configuring the device.

It can also serve as a staging area for new type of devices till they
find some commonality and can be standardized.

The outline of this proposed library is same as existing ether/crypto devices.

 +---+
 | Application(s)|
 +--.+
|
|
 +--'+
 |   DPDK Framework (APIs)   |
 +--||-|-+
   /  \ \
(crypto ops)  (eth ops)  (rawdev ops)++
/   \ \  |DrvA|
 +-'---++`++---'-+   ++
 | crypto  || ethdev  || raw |
 +--/--++---/-++/+   ++
   /\__/\  /   ..|DrvB|
  /  \  /\/ ../\ ++
  ++ ++++ +++==/=+  ```Bus Probe 
  |DevA| |DevB||DevC| |DevD||DevF|
  ++ ++++ ++++
|  ||  | |
  ``|``||``|`|Bus Scan
   (PCI)   |   (PCI)  (PCI)(PCI)
 (BusA)

 * It is assumed above that DrvB is a PCI type driver which registers itself
   with PCI Bus
 * Thereafter, when the PCI scan is done, during probe DrvB would match the
   rawdev DevF ID and take control of device
 * Applications can then continue using the device through rawdev API interfaces


Proposed Interfaces
===

Following broad API categories are exposed by the rawdevice:

1) Device State Operations (start/stop/reset)
2) Communication Channel setup/teardown (queue)
3) Stat Operations (xstats)
4) Enqueue/Dequeue Operations
5) Firmware Operations (Load/unload)

Notes:
For (1), other than standard start/stop, reset has been added extra. This is for
cases where device power cycle has various definitions. Semantics of what
stop->start and what reset would mean are still open-ended.

For (2), though currently `queue` has been used a semantic, it would be possible
in implementation to use this with other methods like internally hosted 
rte_ring.

For (3), Reason for choosin

[dpdk-dev] [RFC PATCH 1/2] lib: introduce raw device library

[Hemant Agrawal]

Raw device is a generalized interface for expanding non-generic devices
into DPDK framework. This library provides primitive interfaces which
enable creation of raw devices.

Signed-off-by: Hemant Agrawal 
---
 lib/librte_rawdev/Makefile   |  53 +++
 lib/librte_rawdev/rte_rawdev.c   | 626 +++
 lib/librte_rawdev/rte_rawdev.h   | 524 ++
 lib/librte_rawdev/rte_rawdev_pmd.h   | 540 ++
 lib/librte_rawdev/rte_rawdev_version.map |  28 ++
 5 files changed, 1771 insertions(+)
 create mode 100644 lib/librte_rawdev/Makefile
 create mode 100644 lib/librte_rawdev/rte_rawdev.c
 create mode 100644 lib/librte_rawdev/rte_rawdev.h
 create mode 100644 lib/librte_rawdev/rte_rawdev_pmd.h
 create mode 100644 lib/librte_rawdev/rte_rawdev_version.map

diff --git a/lib/librte_rawdev/Makefile b/lib/librte_rawdev/Makefile
new file mode 100644
index 000..a2b22a1
--- /dev/null
+++ b/lib/librte_rawdev/Makefile
@@ -0,0 +1,53 @@
+#   BSD LICENSE
+#
+#   Copyright 2017 NXP
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of NXPnor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# library name
+LIB = librte_rawdev.a
+
+# library version
+LIBABIVER := 1
+
+# build flags
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrte_eal -lrte_mempool -lrte_ring -lrte_mbuf
+
+# library source files
+SRCS-y += rte_rawdev.c
+
+# export include files
+SYMLINK-y-include += rte_rawdev.h
+
+# versioning export map
+EXPORT_MAP := rte_rawdev_version.map
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_rawdev/rte_rawdev.c b/lib/librte_rawdev/rte_rawdev.c
new file mode 100644
index 000..1269193
--- /dev/null
+++ b/lib/librte_rawdev/rte_rawdev.c
@@ -0,0 +1,626 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright 2017 NXP
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of NXPnor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#in

[dpdk-dev] [RFC PATCH 2/2] config: enable compilation of raw device library

[Hemant Agrawal]

Signed-off-by: Hemant Agrawal 
---
 config/common_base | 7 +++
 lib/Makefile   | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/config/common_base b/config/common_base
index 34f04a9..30ab741 100644
--- a/config/common_base
+++ b/config/common_base
@@ -793,6 +793,13 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n
 CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
 
 #
+# Compile raw device support
+# EXPERIMENTAL: API may change without prior notice
+#
+CONFIG_RTE_LIBRTE_RAWDEV=y
+CONFIG_RTE_LIBRTE_RAWDEV_DEBUG=n
+
+#
 # Compile vhost PMD
 # To compile, CONFIG_RTE_LIBRTE_VHOST should be enabled.
 #
diff --git a/lib/Makefile b/lib/Makefile
index dc4e8df..4c60f30 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -126,4 +126,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
 endif
 DEPDIRS-librte_kni := librte_eal librte_mempool librte_mbuf librte_ether
 
+DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev
+DEPDIRS-librte_rawdev := librte_eal librte_mbuf librte_ether librte_cryptodev
+
 include $(RTE_SDK)/mk/rte.subdir.mk
-- 
2.7.4

Re: [dpdk-dev] [PATCH v4 0/4] fix race condition in enqueue/dequeue because of cpu reorder

[Ananyev, Konstantin]

> -Original Message-
> From: Jia He [mailto:hejia...@gmail.com]
> Sent: Wednesday, November 8, 2017 3:12 PM
> To: Richardson, Bruce 
> Cc: jerin.ja...@caviumnetworks.com; dev@dpdk.org; olivier.m...@6wind.com; 
> Ananyev, Konstantin ;
> jianbo@arm.com; hemant.agra...@nxp.com
> Subject: Re: [PATCH v4 0/4] fix race condition in enqueue/dequeue because of 
> cpu reorder
> 
> Hi Bruce
> 
> 
> On 11/8/2017 8:15 PM, Bruce Richardson Wrote:
> > On Wed, Nov 08, 2017 at 09:54:37AM +, Jia He wrote:
> >> We watched a rte panic of mbuf_autotest in our qualcomm arm64 server
> >> due to a possible race condition.
> >>
> >> To fix this race, there are 2 options as suggested by Jerin: 1. use
> >> rte_smp_rmb 2. use load_acquire/store_release(refer to [2]).
> >> CONFIG_RTE_RING_USE_C11_MEM_MODEL is provided, and by default it is
> >> "y" only on arm64 so far.
> >>
> >> The reason why providing 2 options is due to the performance benchmark
> >> difference in different arm machines.
> >>
> >> Already fuctionally tested on the machines as follows: - on X86 - on
> >> arm64 with CONFIG_RTE_RING_USE_C11_MEM_MODEL=y - on arm64 with
> >> CONFIG_RTE_RING_USE_C11_MEM_MODEL=n
> >>
> >> --- Changelog: V4: split into small patches V3: arch specific
> >> implementation for enqueue/dequeue barrier V2: let users choose
> >> whether using load_acquire/store_release V1: rte_smp_rmb() between 2
> >> loads
> >>
> >> Jia He (4): eal/arm64: remove the braces {} for dmb() and dsb() ring:
> >> guarantee load/load order in enqueue and dequeue ring: introduce new
> >> header file to include common functions ring: introduce new header
> >> file to support C11 memory model
> >>
> > I'm wondering what the merge plans are for this set, given we are now
> > past RC3 in 17.11? As the rings are broken on ARM machines we need to
> > merge in some fix, but I'm a little concerned about the scope of the
> > changes from the 3rd and 4th patches. Would it be acceptable to just
> > merge in patches 1 & 2 in 17.11 and leave the rework and C11 memory
> > model additions in patches 3 & 4 to 18.02 release?
> As far as I'm concerned, it is ok.

Sounds good to me too.
Konstantin 

[dpdk-dev] [PATCH v2] net/mlx4: improve Rx packet type offloads report

[Moti Haimovsky]

This patch improves Rx packet type offload report in case the device is
a virtual function device.
In these devices we observed that the L2 tunnel flag is set also for
non-tunneled packets, this leads to a complete misinterpretation of the
packet type being received.
This issue occurs since the tunnel_mode is not set to 0x7 by the driver
for virtual devices and therefore the value in the L2 tunnel flag is
meaningless and should be ignored.

Fixes: aee4a03fee4f ("net/mlx4: enhance Rx packet type offloads")

Signed-off-by: Moti Haimovsky 
---
V2:
Modification according to inputs from Adrien Mazarguil
* Modified the commit message to explain the issue.
* Removed redundant l2 tunnel offload bit.
* Modified mlx4_dev_supported_ptypes_get to report the supported
  packet types according to the device in hand.
---
 drivers/net/mlx4/mlx4_ethdev.c | 19 +--
 drivers/net/mlx4/mlx4_rxq.c|  1 +
 drivers/net/mlx4/mlx4_rxtx.c   |  8 +---
 drivers/net/mlx4/mlx4_rxtx.h   |  1 +
 4 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx4/mlx4_ethdev.c b/drivers/net/mlx4/mlx4_ethdev.c
index c2ea4db..2f69e7d 100644
--- a/drivers/net/mlx4/mlx4_ethdev.c
+++ b/drivers/net/mlx4/mlx4_ethdev.c
@@ -1036,12 +1036,27 @@ enum rxmode_toggle {
RTE_PTYPE_L4_FRAG,
RTE_PTYPE_L4_TCP,
RTE_PTYPE_L4_UDP,
+   RTE_PTYPE_UNKNOWN
+   };
+   static const uint32_t ptypes_l2tun[] = {
+   /* refers to rxq_cq_to_pkt_type() */
+   RTE_PTYPE_L2_ETHER,
+   RTE_PTYPE_L3_IPV4_EXT_UNKNOWN,
+   RTE_PTYPE_L3_IPV6_EXT_UNKNOWN,
+   RTE_PTYPE_L4_FRAG,
+   RTE_PTYPE_L4_TCP,
+   RTE_PTYPE_L4_UDP,
RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN,
RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN,
RTE_PTYPE_UNKNOWN
};
+   struct priv *priv = dev->data->dev_private;
 
-   if (dev->rx_pkt_burst == mlx4_rx_burst)
-   return ptypes;
+   if (dev->rx_pkt_burst == mlx4_rx_burst) {
+   if (priv->hw_csum_l2tun)
+   return ptypes_l2tun;
+   else
+   return ptypes;
+   }
return NULL;
 }
diff --git a/drivers/net/mlx4/mlx4_rxq.c b/drivers/net/mlx4/mlx4_rxq.c
index 8b97a89..53313c5 100644
--- a/drivers/net/mlx4/mlx4_rxq.c
+++ b/drivers/net/mlx4/mlx4_rxq.c
@@ -750,6 +750,7 @@ struct mlx4_rss *
 dev->data->dev_conf.rxmode.hw_ip_checksum),
.csum_l2tun = (priv->hw_csum_l2tun &&
   dev->data->dev_conf.rxmode.hw_ip_checksum),
+   .l2tun_offload = priv->hw_csum_l2tun,
.stats = {
.idx = idx,
},
diff --git a/drivers/net/mlx4/mlx4_rxtx.c b/drivers/net/mlx4/mlx4_rxtx.c
index 3985e06..06f57cc 100644
--- a/drivers/net/mlx4/mlx4_rxtx.c
+++ b/drivers/net/mlx4/mlx4_rxtx.c
@@ -751,7 +751,8 @@ struct pv {
  *   Packet type for struct rte_mbuf.
  */
 static inline uint32_t
-rxq_cq_to_pkt_type(volatile struct mlx4_cqe *cqe)
+rxq_cq_to_pkt_type(volatile struct mlx4_cqe *cqe,
+  uint32_t l2tun_offload)
 {
uint8_t idx = 0;
uint32_t pinfo = rte_be_to_cpu_32(cqe->vlan_my_qpn);
@@ -762,7 +763,7 @@ struct pv {
 *  bit[7] - MLX4_CQE_L2_TUNNEL
 *  bit[6] - MLX4_CQE_L2_TUNNEL_IPV4
 */
-   if (!(pinfo & MLX4_CQE_L2_VLAN_MASK) && (pinfo & MLX4_CQE_L2_TUNNEL))
+   if (l2tun_offload && (pinfo & MLX4_CQE_L2_TUNNEL))
idx |= ((pinfo & MLX4_CQE_L2_TUNNEL) >> 20) |
   ((pinfo & MLX4_CQE_L2_TUNNEL_IPV4) >> 19);
/*
@@ -960,7 +961,8 @@ struct pv {
}
pkt = seg;
/* Update packet information. */
-   pkt->packet_type = rxq_cq_to_pkt_type(cqe);
+   pkt->packet_type =
+   rxq_cq_to_pkt_type(cqe, rxq->l2tun_offload);
pkt->ol_flags = 0;
pkt->pkt_len = len;
if (rxq->csum | rxq->csum_l2tun) {
diff --git a/drivers/net/mlx4/mlx4_rxtx.h b/drivers/net/mlx4/mlx4_rxtx.h
index 4acad80..463df2b 100644
--- a/drivers/net/mlx4/mlx4_rxtx.h
+++ b/drivers/net/mlx4/mlx4_rxtx.h
@@ -80,6 +80,7 @@ struct rxq {
volatile uint32_t *rq_db; /**< RQ doorbell record. */
uint32_t csum:1; /**< Enable checksum offloading. */
uint32_t csum_l2tun:1; /**< Same for L2 tunnels. */
+   uint32_t l2tun_offload:1; /**< L2 tunnel offload is enabled. */
struct mlx4_cq mcq;  /**< Info for directly manipulating the CQ. */
struct mlx4_rxq_stats stats; /**< Rx queue counters. */
unsigned int socket; /**< CPU socket ID for allocations. */
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH] doc: update ABI/API policy

[Kevin Traynor]

On 11/06/2017 11:28 AM, Bruce Richardson wrote:
> Following agreement at the DPDK Technical Board meeting of 2017-10-13 [1],
> update the documentation with the ABI/API policy changes.
> 
> [1] http://dpdk.org/ml/archives/dev/2017-October/079961.html
> 
> Signed-off-by: Bruce Richardson 

Acked-by: Kevin Traynor 

[dpdk-dev] rte_eth_bond 8023ad dedicated queues with i40e with vectorized rx does not work

[Kyle Larose]

Hello,

I've been doing some testing using the 8023ad link bonding driver on a system 
with 4 10G i40e interfaces in the link bond. It's working fine, except that 
when any of the links are overloaded, it starts dropping the LACPDUs, which is 
rather unfortunate for many reasons.

While thinking about that problem, I noticed that the driver provides the 
ability to allocate dedicated queues for rx and tx of LACPDUs. This is great! 
Solves my problem (sort of - I'll send another email about that later)... Or so 
I thought. After enabling the dedicated queues, I noticed  a few things:
1. The link bond never started distributing
2. The slave interfaces started dropping frames on their dedicated 
control queues after some time
3. The connected interfaces reported both sending and receiving LACP 
PDUs. 

After digging in to this, I found out that the call to rte_eth_rx_burst was 
returning 0 packets, despite their being many in the queue. It turns out that 
the i40e was using one of the vectorized rx_burst functions, which require that 
the user poll for more than 1 packet at a time. bond_mode_8023ad_periodic_cb 
was polling for exactly one.

I changed the code to read up to 16 at a time, and everything started working. 
I'm not sure this is the right fix, though, since the normal behaviour of 
processing one packet at a time maintains some hold offs/etc that may be nice, 
and I don't want to discard any packets past the first one.

Does anyone have some thoughts/comments on this? I can submit a patch with my 
current workaround, if desired.

Thanks,

Kyle 

[dpdk-dev] rte_eth_bond 8023ad behaviour under congestion

[Kyle Larose]

Hello,

I've been doing some testing using the 8023ad link bonding driver on a system 
with 4 10G i40e interfaces in the link bond. One thing I've noticed is that if 
any of the links are overloaded when I don't have dedicated control queues 
enabled, it starts dropping LACPDUs on transmit. I quickly realized that it's 
because of the following code in bond_ethdev_tx_burst_8023ad:



num_tx_slave = rte_eth_tx_burst(slaves[i], bd_tx_q->queue_id,
slave_bufs[i], slave_nb_pkts[i]);

/* If tx burst fails drop slow packets */
for ( ; num_tx_slave < slave_slow_nb_pkts[i]; num_tx_slave++)
rte_pktmbuf_free(slave_bufs[i][num_tx_slave]);

This chunk of code basically treats the LACPPDUs at a very low priority, since 
they are generated infrequently. I'd like to ensure that LACPPDUs are 
transmitted when there's congestion in the case where dedicated queues are not 
supported.

I can think of a few options to resolve this:
 1) Store the LACPDUS for later sending in a per-slave buffer if tx fails, and 
make sure these are always at the front of the send buffer, so that when 
there's room, they're sent (I'm not quite sure what the best way to do this is).
 2) Allow enabling the dedicated tx queue without enabling the dedicated rx 
queue.

I think both 1 & 2 are good solutions on their own, and should probably both be 
implemented. #2 is ideal, but doesn't cover all cases (like if there are 
insufficient tx queues to dedicate one to this).

How do people feel about these proposals?

Note: I understand that this is not ideal at all, since the lack of a dedicated 
rx queue means that lacpdus could drop on rx. But, in my use-case that's less 
likely than link congestion, so I'd like to at least be resilient here.

Thanks,

Kyle
 

Re: [dpdk-dev] [PATCH] net/softnic: fix build error on gcc4.5.1

[Thomas Monjalon]

> > Fix the build error due to improper handling of unions on SUSE11(gcc 4.5.1).
> > 
> > Fixes: 299a89de916a ("net/softnic: add TM capabilities ops")
> > 
> > DPDK/drivers/net/softnic/rte_eth_softnic_tm.c:588:3
> > error: unknown field 'nonleaf' specified in initializer compilation
> > terminated due to -Wfatal-errors.
> > 
> > Signed-off-by: Jasvinder Singh 
> > ---
> >  drivers/net/softnic/rte_eth_softnic_tm.c | 40 ---
> > -
> >  1 file changed, 20 insertions(+), 20 deletions(-)
> 
> Acked-by: Cristian Dumitrescu 

Applied, thanks

Re: [dpdk-dev] [PATCH v2] net/mlx4: improve Rx packet type offloads report

[Thomas Monjalon]

08/11/2017 19:47, Moti Haimovsky:
> This patch improves Rx packet type offload report in case the device is
> a virtual function device.
> In these devices we observed that the L2 tunnel flag is set also for
> non-tunneled packets, this leads to a complete misinterpretation of the
> packet type being received.
> This issue occurs since the tunnel_mode is not set to 0x7 by the driver
> for virtual devices and therefore the value in the L2 tunnel flag is
> meaningless and should be ignored.
> 
> Fixes: aee4a03fee4f ("net/mlx4: enhance Rx packet type offloads")
> 
> Signed-off-by: Moti Haimovsky 
> ---
> V2:
> Modification according to inputs from Adrien Mazarguil
> * Modified the commit message to explain the issue.
> * Removed redundant l2 tunnel offload bit.
> * Modified mlx4_dev_supported_ptypes_get to report the supported
>   packet types according to the device in hand.
> ---

As it is a v2, it should be threaded with v1.
Please remind to use --in-reply-to.

Just looking at the title, we should not take it for RC3.
But reading the commit message, especially "this leads to a
complete misinterpretation of the packet type being received",
it appears fixing a real bug. In this case, the title should be
"net/mlx4: fix Rx packet type offloads"

Re: [dpdk-dev] [PATCH] net/liquidio: add support for device reset in driver

[Thomas Monjalon]

08/11/2017 13:04, Shijith Thotton:
> Reset device during init and close if bound to igb_uio.
> 
> Fixes: 369db3ae8e91 ("igb_uio: remove device reset in release")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Shijith Thotton 
> ---
> Hi Thomas/Ferruh,
> 
> Please consider this patch for 17.11 as removing reset from igb_uio breaks
> LiquidIO PMD[1]. Here I have added support for reset within driver if the 
> kernel
> driver in use is igb_uio.
> 
> 1. http://dpdk.org/ml/archives/dev/2017-October/079483.html

Applied, thanks

[dpdk-dev] [PATCH] doc: move fast mbuf free feature in net guide

[Thomas Monjalon]

The feature was added at the end of the table.
And the description was between the anchor _nic_features_timesync
and its title.
It is moved near related features with a new anchor.

It is also renamed from "mbuf fast free" to "fast mbuf free".

Fixes: d6f90afd3070 ("ethdev: add mbuf fast free Tx offload")

Signed-off-by: Thomas Monjalon 
---
 doc/guides/nics/features.rst | 21 -
 doc/guides/nics/features/default.ini |  2 +-
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index bfeae80ef..d9917d4f5 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -136,6 +136,18 @@ invoke rte_eth_tx_burst() concurrently on the same Tx 
queue without SW lock.
 * **[related]  API**: ``rte_eth_tx_burst()``.
 
 
+.. _nic_features_fast_mbuf_free:
+
+Fast mbuf free
+--
+
+Supports optimization for fast release of mbufs following successful Tx.
+Requires that per queue, all mbufs come from the same mempool and has refcnt = 
1.
+
+* **[uses]   rte_eth_txconf,rte_eth_txmode**: 
``offloads:DEV_TX_OFFLOAD_MBUF_FAST_FREE``.
+* **[provides]   rte_eth_dev_info**: 
``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_MBUF_FAST_FREE``.
+
+
 .. _nic_features_free_tx_mbuf_on_demand:
 
 Free Tx mbuf on demand
@@ -640,15 +652,6 @@ Supports packet type parsing and returns a list of 
supported types.
 
 .. _nic_features_timesync:
 
-Mbuf fast free
---
-
-Supports optimization for fast release of mbufs following successful Tx.
-Requires that per queue, all mbufs come from the same mempool and has refcnt = 
1.
-
-* **[uses]   rte_eth_txconf,rte_eth_txmode**: 
``offloads:DEV_TX_OFFLOAD_MBUF_FAST_FREE``.
-* **[provides]   rte_eth_dev_info**: 
``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_MBUF_FAST_FREE``.
-
 Timesync
 
 
diff --git a/doc/guides/nics/features/default.ini 
b/doc/guides/nics/features/default.ini
index dc527ddf9..95c569869 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -14,6 +14,7 @@ Removal event=
 Queue status event   =
 Rx interrupt =
 Lock-free Tx queue   =
+Fast mbuf free   =
 Free Tx mbuf on demand =
 Queue start/stop =
 MTU update   =
@@ -76,4 +77,3 @@ x86-64   =
 Usage doc=
 Design doc   =
 Perf doc =
-Mbuf fast free   =
-- 
2.14.2

Re: [dpdk-dev] [PATCH] doc: move fast mbuf free feature in net guide

[Ferruh Yigit]

On 11/8/2017 12:51 PM, Thomas Monjalon wrote:
> The feature was added at the end of the table.
> And the description was between the anchor _nic_features_timesync
> and its title.
> It is moved near related features with a new anchor.
> 
> It is also renamed from "mbuf fast free" to "fast mbuf free".
> 
> Fixes: d6f90afd3070 ("ethdev: add mbuf fast free Tx offload")
> 
> Signed-off-by: Thomas Monjalon 

Acked-by: Ferruh Yigit 

Re: [dpdk-dev] [PATCH 1/3] eal/arm64: remove the braces {} for dmb(), dsb()

[Jia He]

Hi Bruce


On 11/8/2017 6:28 PM, Bruce Richardson Wrote:

On Wed, Nov 08, 2017 at 06:17:10AM +, Jia He wrote:

for the code as follows:
if (condition)
rte_smp_rmb();
else
rte_smp_wmb();
Without this patch, compiler will report this error:
error: 'else' without a previous 'if'

Signed-off-by: Jia He 
Signed-off-by: jia...@hxt-semitech.com
---
  lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h 
b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
index 0b70d62..38c3393 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
@@ -43,8 +43,8 @@ extern "C" {
  
  #include "generic/rte_atomic.h"
  
-#define dsb(opt)  { asm volatile("dsb " #opt : : : "memory"); }

-#define dmb(opt)  { asm volatile("dmb " #opt : : : "memory"); }
+#define dsb(opt) asm volatile("dsb " #opt : : : "memory");
+#define dmb(opt) asm volatile("dmb " #opt : : : "memory");
  

Need to remove the trailing ";" I too I think.
Alternatively, to keep the braces, the standard practice is to use
do { ... } while(0)

If trailing ";" is not removed
the code:
if (condition)
    rte_smp_rmb();
else
    anything();

will be like below after precompiling:
if (condition)
    asm volatile("dsb " "ld" : : : "memory");;
else
    anything();
Then, the same error - error: 'else' without a previous 'if'

If you choose do/while(0), yes, no errors from compiler.
But the checkpatch will report

WARNING: Single statement macros should not use a do {} while (0) loop
#11: FILE: lib/librte_eal/common/include/arch/arm/rte_atomic_64.h:46:
+#define dsb(opt) do { asm volatile("dsb " #opt : : : "memory"); } while (0)

I searched the kernel codes, the marco dsb() didn't use the do/while(0).
Which one do you think is better for dpdk?

Cheers,
Jia

Re: [dpdk-dev] [PATCH v2] net/virtio: fix rxq intr config fails using vfio-pci

[Yang, Zhiyong]

Hi Jianfeng,

Thanks for detailed reviews and comments. Next version will come soon according 
to your suggestions.

Thanks
Zhiyong

> -Original Message-
> From: Tan, Jianfeng
> Sent: Wednesday, November 8, 2017 9:53 PM
> To: Yang, Zhiyong ; dev@dpdk.org
> Cc: y...@fridaylinux.org; maxime.coque...@redhat.com
> Subject: Re: [PATCH v2] net/virtio: fix rxq intr config fails using vfio-pci
> 
> 
> Hi Zhiyong,
> 
> 
> On 11/8/2017 7:03 PM, Zhiyong Yang wrote:
> > When running l3fwd-power to test virtio rxq interrupt using vfio pci
> > noiommu mode, startup fails. In the function virtio_read_caps, the
> > code if (flags & PCI_MSIX_ENABLE) intends to double check if vfio msix
> > is enabled or not. However, it is not enable at that stage. So
> > use_msix is assigned to "0", not "1", which causes the failure of
> > configuring rxq intr in l3fwd-power.
> > This patch adds the function vtpci_msix_detect to detect the status of
> > msix when interrupt changes happen.
> > In the meanwhile, virtio_intr_enable/disable are introduced to wrap
> > rte_intr_enable/disable to enhance the ability to detect msix. Only
> > support and enable msix can assign "1" to use_msix.
> 
> Should be "2". Better to use macro here.
> 
> >
> > Fixes: cb482cb3a305 ("net/virtio: fix MAC address read")
> > Signed-off-by: Zhiyong Yang 
> > ---

Re: [dpdk-dev] [PATCH v2] net/virtio: fix rxq intr config fails using vfio-pci

[Yang, Zhiyong]

Hi Jianfeng,

> -Original Message-
> From: Tan, Jianfeng
> Sent: Wednesday, November 8, 2017 9:53 PM
> To: Yang, Zhiyong ; dev@dpdk.org
> Cc: y...@fridaylinux.org; maxime.coque...@redhat.com
> Subject: Re: [PATCH v2] net/virtio: fix rxq intr config fails using vfio-pci
> 
> 
> Hi Zhiyong,
> 
> 
> On 11/8/2017 7:03 PM, Zhiyong Yang wrote:
> > When running l3fwd-power to test virtio rxq interrupt using vfio pci
> > noiommu mode, startup fails. In the function virtio_read_caps, the
> > code if (flags & PCI_MSIX_ENABLE) intends to double check if vfio msix
> > is enabled or not. However, it is not enable at that stage. So
> > use_msix is assigned to "0", not "1", which causes the failure of
> > configuring rxq intr in l3fwd-power.
> > This patch adds the function vtpci_msix_detect to detect the status of
> > msix when interrupt changes happen.
> > In the meanwhile, virtio_intr_enable/disable are introduced to wrap
> > rte_intr_enable/disable to enhance the ability to detect msix. Only
> > support and enable msix can assign "1" to use_msix.
> 
> Should be "2". Better to use macro here.
> 
> >
> > Fixes: cb482cb3a305 ("net/virtio: fix MAC address read")
> > Signed-off-by: Zhiyong Yang 
> > ---
> > @@ -1370,7 +1411,15 @@ virtio_init_device(struct rte_eth_dev *eth_dev,
> uint64_t req_features)
> > struct virtio_net_config local_config;
> > struct rte_pci_device *pci_dev = NULL;
> > int ret;
> > +   int msix_detect;
> >
> > +   msix_detect = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(eth_dev));
> > +   if (msix_detect < 0)
> > +   return -1;
> > +   else if (msix_detect == SUPPORT_MSIX_STATUS_ENABLED)
> > +   hw->use_msix = 1;
> > +   else
> > +   hw->use_msix = 0;
> 
> Ditto, we directly assign return value to hw->use_msix.
> 
The function call can be removed if use_misx  can use 0, 1, 2 directly
We can implement the same logic  in  virtio_read_caps instead.

Thanks
Zhiyong

Re: [dpdk-dev] Huge mapping secondary process linux

[Chao Zhu]

 

 

From: Jonas Pfefferle1 [mailto:j...@zurich.ibm.com] 
Sent: 2017年11月7日 18:16
To: Chao Zhu 
Cc: 'Burakov, Anatoly' ; bruce.richard...@intel.com; 
dev@dpdk.org
Subject: RE: [dpdk-dev] Huge mapping secondary process linux

 

"Chao Zhu" mailto:chao...@linux.vnet.ibm.com> > 
wrote on 11/07/2017 09:25:26 AM:

> From: "Chao Zhu"   >
> To: "'Jonas Pfefferle1'" mailto:j...@zurich.ibm.com> >, 
> "'Burakov, Anatoly'" 
> mailto:anatoly.bura...@intel.com> >
> Cc: mailto:bruce.richard...@intel.com> >, 
> mailto:dev@dpdk.org> >
> Date: 11/07/2017 11:00 AM
> Subject: RE: [dpdk-dev] Huge mapping secondary process linux
> 
>  
>  
> From: Jonas Pfefferle1 [mailto:j...@zurich.ibm.com] 
> Sent: 2017年10月28日 3:23
> To: Burakov, Anatoly   >
> Cc: bruce.richard...@intel.com  ; 
> chao...@linux.vnet.ibm.com  ; dev@dpdk.org 
>  
> Subject: Re: [dpdk-dev] Huge mapping secondary process linux
>  
> "Burakov, Anatoly"   > wrote on 27/10/2017 18:00:27:
> 
> > From: "Burakov, Anatoly"  >  >
> > To: Jonas Pfefferle1 mailto:j...@zurich.ibm.com> >
> > Cc: bruce.richard...@intel.com  , 
> > chao...@linux.vnet.ibm.com  , 
> > dev@dpdk.org  
> > Date: 27/10/2017 18:00
> > Subject: Re: [dpdk-dev] Huge mapping secondary process linux
> > 
> > On 27-Oct-17 4:16 PM, Jonas Pfefferle1 wrote:
> > > "dev" mailto:dev-boun...@dpdk.org> > wrote on 
> > > 10/27/2017 04:58:01 PM:
> > > 
> > >  > From: "Jonas Pfefferle1"  > >  >
> > >  > To: "Burakov, Anatoly"  > >  >
> > >  > Cc: bruce.richard...@intel.com  , 
> > > chao...@linux.vnet.ibm.com  , 
> dev@dpdk.org  
> > >  > Date: 10/27/2017 04:58 PM
> > >  > Subject: Re: [dpdk-dev] Huge mapping secondary process linux
> > >  > Sent by: "dev" mailto:dev-boun...@dpdk.org> >
> > >  >
> > >  >
> > >  > "Burakov, Anatoly"  > >  > wrote on 10/27/2017 
> > > 04:44:52
> > >  > PM:
> > >  >
> > >  > > From: "Burakov, Anatoly"  > >  >
> > >  > > To: Jonas Pfefferle1  > >  >
> > >  > > Cc: bruce.richard...@intel.com  , 
> > > chao...@linux.vnet.ibm.com  , 
> > > dev@dpdk.org  
> > >  > > Date: 10/27/2017 04:45 PM
> > >  > > Subject: Re: [dpdk-dev] Huge mapping secondary process linux
> > >  > >
> > >  > > On 27-Oct-17 3:28 PM, Jonas Pfefferle1 wrote:
> > >  > > > "Burakov, Anatoly"  > >  > wrote on 10/27/2017
> > >  > > > 04:06:44 PM:
> > >  > > >
> > >  > > > Â > From: "Burakov, Anatoly"  > >  >
> > >  > > > Â > To: Jonas Pfefferle1  > >  >, dev@dpdk.org  
> > >  > > > Â > Cc: chao...@linux.vnet.ibm.com 
> > >  , bruce.richard...@intel.com 
> > >  
> > >  > > > Â > Date: 10/27/2017 04:06 PM
> > >  > > > Â > Subject: Re: [dpdk-dev] Huge mapping secondary process linux
> > >  > > > Â >
> > >  > > > Â > On 27-Oct-17 1:43 PM, Jonas Pfefferle1 wrote:
> > >  > > > Â > >
> > >  > > > Â > >
> > >  > > > Â > > Hi @all,
> > >  > > > Â > >
> > >  > > > Â > > I'm trying to make sense of the hugepage memory mappings in
> > >  > > > Â > > librte_eal/linuxapp/eal/eal_memory.c:
> > >  > > > Â > > * In rte_eal_hugepage_attach (line 1347) when we try to do a
> > >  > private
> > >  > > > Â > > mapping on /dev/zero (line 1393) why do we not use MAP_FIXED 
> > > if we
> > >  >
> > >  > > > need the
> > >  > > > Â > > addresses to be identical with the primary process?
> > >  > > > Â > > * On POWER we have this weird business going on where we use
> > >  > > > MAP_HUGETLB
> > >  > > > Â > > because according to this commit:
> > >  > > > Â > >
> > >  > > > Â > > commit 284ae3e9ff9a92575c28c858efd2c85c8de6d440
> > >  > > > Â > > Author: Chao Zhu  > >  >
> > >  > > > Â > > Date: Â  Thu Apr 6 15:36:09 2017 +0530
> > >  > > > Â > >
> > >  > > > Â > > Â  Â  Â eal/ppc: fix mmap for memory initialization
> > >  > > > Â > >
> > >  > > > Â > > Â  Â  Â On IBM POWER platform, when mapping /dev/zero file to
> > >  > hugepage
> > >  > > > memory
> > >  > > > Â > > Â  Â  Â space, mmap will not respect the requested address 
> > > hint.This
> > >  > will
> > >  > > > Â > > cause
> > >  > > > Â > > Â  Â  Â the memory initialization for the second 
> > process fails. 
> > > This
> > >  > > > patch adds
> > >  > > > Â > > Â  Â  Â the required mmap flags to make it work. 
> > Beside this

Re: [dpdk-dev] [PATCH 1/3] eal/arm64: remove the braces {} for dmb(), dsb()

[Jia He]

On 11/9/2017 9:22 AM, Jia He Wrote:

Hi Bruce


On 11/8/2017 6:28 PM, Bruce Richardson Wrote:

On Wed, Nov 08, 2017 at 06:17:10AM +, Jia He wrote:

for the code as follows:
if (condition)
rte_smp_rmb();
else
rte_smp_wmb();
Without this patch, compiler will report this error:
error: 'else' without a previous 'if'

Signed-off-by: Jia He 
Signed-off-by: jia...@hxt-semitech.com
---
  lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h 
b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h

index 0b70d62..38c3393 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
@@ -43,8 +43,8 @@ extern "C" {
    #include "generic/rte_atomic.h"
  -#define dsb(opt)  { asm volatile("dsb " #opt : : : "memory"); }
-#define dmb(opt)  { asm volatile("dmb " #opt : : : "memory"); }
+#define dsb(opt) asm volatile("dsb " #opt : : : "memory");
+#define dmb(opt) asm volatile("dmb " #opt : : : "memory");

Need to remove the trailing ";" I too I think.
Alternatively, to keep the braces, the standard practice is to use
do { ... } while(0)

If trailing ";" is not removed
the code:
if (condition)
    rte_smp_rmb();
else
    anything();

will be like below after precompiling:
if (condition)
    asm volatile("dsb " "ld" : : : "memory");;
else
    anything();
Then, the same error - error: 'else' without a previous 'if'


Ignore my words above，thanks
sorry for the inconvenience.
And I've sent out v4 in this mail thread. The ";" has been removed.
If no more comments, I will send out v5 (2 patch sets for 17 and 18)

--
Cheers,
Jia


--
Cheers,
Jia

[dpdk-dev] [PATCH v3] net/virtio: fix rxq intr config fails using vfio-pci

[Zhiyong Yang]

When running l3fwd-power to test virtio rxq interrupt using vfio
pci noiommu mode, startup fails. In the function virtio_read_caps,
the code if (flags & PCI_MSIX_ENABLE) intends to double check
if vfio msix is enabled or not. However, it is not enable at that
time. So use_msix is assigned to "0", not "1", which causes the
failure of configuring rxq intr in l3fwd-power.
This patch adds the function "vtpci_msix_detect" to detect the status
of msix when interrupt changes happen.
In the meanwhile, virtio_intr_enable/disable are introduced to wrap
rte_intr_enable/disable to enhance the ability to detect msix. Only
supporting and enabling msix can assign "VIRTIO_MSIX_ENABLED(2)" to
use_msix.

Fixes: cb482cb3a305 ("net/virtio: fix MAC address read")
Signed-off-by: Zhiyong Yang 
---

Changes in v3:
Simply the code according to jianfeng's comments.

Changes in v2:
Add the capability to detect msix if virtio intr changes.

 drivers/net/virtio/virtio_ethdev.c | 46 ++--
 drivers/net/virtio/virtio_pci.c| 48 --
 drivers/net/virtio/virtio_pci.h|  6 +
 3 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index d2576d5e0..87ac2bee6 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -97,6 +97,9 @@ static void virtio_mac_addr_remove(struct rte_eth_dev *dev, 
uint32_t index);
 static void virtio_mac_addr_set(struct rte_eth_dev *dev,
struct ether_addr *mac_addr);
 
+static int virtio_intr_enable(struct rte_eth_dev *dev);
+static int virtio_intr_disable(struct rte_eth_dev *dev);
+
 static int virtio_dev_queue_stats_mapping_set(
struct rte_eth_dev *eth_dev,
uint16_t queue_id,
@@ -618,7 +621,7 @@ virtio_dev_close(struct rte_eth_dev *dev)
virtio_queues_unbind_intr(dev);
 
if (intr_conf->lsc || intr_conf->rxq) {
-   rte_intr_disable(dev->intr_handle);
+   virtio_intr_disable(dev);
rte_intr_efd_disable(dev->intr_handle);
rte_free(dev->intr_handle->intr_vec);
dev->intr_handle->intr_vec = NULL;
@@ -1160,6 +1163,34 @@ virtio_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
vlan_id, int on)
 }
 
 static int
+virtio_intr_enable(struct rte_eth_dev *dev)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+
+   if (rte_intr_enable(dev->intr_handle) < 0)
+   return -1;
+
+   if (!hw->virtio_user_dev)
+   hw->use_msix = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
+
+   return 0;
+}
+
+static int
+virtio_intr_disable(struct rte_eth_dev *dev)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+
+   if (rte_intr_disable(dev->intr_handle) < 0)
+   return -1;
+
+   if (!hw->virtio_user_dev)
+   hw->use_msix = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
+
+   return 0;
+}
+
+static int
 virtio_negotiate_features(struct virtio_hw *hw, uint64_t req_features)
 {
uint64_t host_features;
@@ -1228,7 +1259,7 @@ virtio_interrupt_handler(void *param)
isr = vtpci_isr(hw);
PMD_DRV_LOG(INFO, "interrupt status = %#x", isr);
 
-   if (rte_intr_enable(dev->intr_handle) < 0)
+   if (virtio_intr_enable(dev) < 0)
PMD_DRV_LOG(ERR, "interrupt enable failed");
 
if (isr & VIRTIO_PCI_ISR_CONFIG) {
@@ -1348,7 +1379,7 @@ virtio_configure_intr(struct rte_eth_dev *dev)
 * to change the config size from 20 to 24, or VIRTIO_MSI_QUEUE_VECTOR
 * (22) will be ignored.
 */
-   if (rte_intr_enable(dev->intr_handle) < 0) {
+   if (virtio_intr_enable(dev) < 0) {
PMD_DRV_LOG(ERR, "interrupt enable failed");
return -1;
}
@@ -1388,7 +1419,8 @@ virtio_init_device(struct rte_eth_dev *eth_dev, uint64_t 
req_features)
}
 
/* If host does not support both status and MSI-X then disable LSC */
-   if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS) && hw->use_msix)
+   if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS) &&
+   hw->use_msix != VIRTIO_MSIX_NONE)
eth_dev->data->dev_flags |= RTE_ETH_DEV_INTR_LSC;
else
eth_dev->data->dev_flags &= ~RTE_ETH_DEV_INTR_LSC;
@@ -1801,9 +1833,9 @@ virtio_dev_start(struct rte_eth_dev *dev)
 */
if (dev->data->dev_conf.intr_conf.lsc ||
dev->data->dev_conf.intr_conf.rxq) {
-   rte_intr_disable(dev->intr_handle);
+   virtio_intr_disable(dev);
 
-   if (rte_intr_enable(dev->intr_handle) < 0) {
+   if (virtio_intr_enable(dev) < 0) {
PMD_DRV_LOG(ERR, "interrupt enable failed");
return -EIO;
}
@@ -1912,7 +1944,7 @@ virtio_dev_stop(struct rte_eth_dev *dev)
PMD_INIT_LOG(DEBUG, "stop");
 
if (int

Re: [dpdk-dev] [PATCH 1/3] eal/arm64: remove the braces {} for dmb(), dsb()

[Jianbo Liu]

The 11/09/2017 11:14, Jia He wrote:
>
>
> On 11/9/2017 9:22 AM, Jia He Wrote:
> >Hi Bruce
> >
> >
> >On 11/8/2017 6:28 PM, Bruce Richardson Wrote:
> >>On Wed, Nov 08, 2017 at 06:17:10AM +, Jia He wrote:
> >>>for the code as follows:
> >>>if (condition)
> >>>rte_smp_rmb();
> >>>else
> >>>rte_smp_wmb();
> >>>Without this patch, compiler will report this error:
> >>>error: 'else' without a previous 'if'
> >>>
> >>>Signed-off-by: Jia He 
> >>>Signed-off-by: jia...@hxt-semitech.com
> >>>---
> >>>  lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git
> >>>a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> >>>b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> >>>index 0b70d62..38c3393 100644
> >>>--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> >>>+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> >>>@@ -43,8 +43,8 @@ extern "C" {
> >>>    #include "generic/rte_atomic.h"
> >>>  -#define dsb(opt)  { asm volatile("dsb " #opt : : : "memory"); }
> >>>-#define dmb(opt)  { asm volatile("dmb " #opt : : : "memory"); }
> >>>+#define dsb(opt) asm volatile("dsb " #opt : : : "memory");
> >>>+#define dmb(opt) asm volatile("dmb " #opt : : : "memory");
> >>Need to remove the trailing ";" I too I think.
> >>Alternatively, to keep the braces, the standard practice is to use
> >>do { ... } while(0)
> >If trailing ";" is not removed
> >the code:
> >if (condition)
> >    rte_smp_rmb();
> >else
> >    anything();
> >

Sorry, why not use two different functions as your conditions passed in
are fixed in the calling functions.

> >will be like below after precompiling:
> >if (condition)
> >    asm volatile("dsb " "ld" : : : "memory");;
> >else
> >    anything();
> >Then, the same error - error: 'else' without a previous 'if'
> >
> Ignore my words above，thanks
> sorry for the inconvenience.
> And I've sent out v4 in this mail thread. The ";" has been removed.
> If no more comments, I will send out v5 (2 patch sets for 17 and 18)
>
> --
> Cheers,
> Jia
>
>
> --
> Cheers,
> Jia
>

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

[dpdk-dev] The virtio device mac is empty in vhostuser type.

[? ?]

Hi,

When I attached a virtio device to ovs bridge in vhostuser type, the virtual 
port does not have the mac address.
After checked the dpdk code, I found the 'mac' which is the member of struct 
'virtio_net' is empty.
It only been assigned in case VHOST_USER_SEND_RARP of function 
'vhost_user_msg_handler'.
But the comments said VHOST_USER_SEND_RARP would be handled during VM migration.

Therefore I would like to ask when I launch the dpdk vhost-user program, how 
could I get the virtio NIC MAC address?

Thanks

Best Regards,
Hering
heringli...@outlook.com

Re: [dpdk-dev] [PATCH v2] net/virtio: fix rxq intr config fails using vfio-pci

[Tan, Jianfeng]

On 11/9/2017 10:11 AM, Yang, Zhiyong wrote:

Hi Jianfeng,


-Original Message-
From: Tan, Jianfeng
Sent: Wednesday, November 8, 2017 9:53 PM
To: Yang, Zhiyong ; dev@dpdk.org
Cc: y...@fridaylinux.org; maxime.coque...@redhat.com
Subject: Re: [PATCH v2] net/virtio: fix rxq intr config fails using vfio-pci


Hi Zhiyong,


On 11/8/2017 7:03 PM, Zhiyong Yang wrote:

When running l3fwd-power to test virtio rxq interrupt using vfio pci
noiommu mode, startup fails. In the function virtio_read_caps, the
code if (flags & PCI_MSIX_ENABLE) intends to double check if vfio msix
is enabled or not. However, it is not enable at that stage. So
use_msix is assigned to "0", not "1", which causes the failure of
configuring rxq intr in l3fwd-power.
This patch adds the function vtpci_msix_detect to detect the status of
msix when interrupt changes happen.
In the meanwhile, virtio_intr_enable/disable are introduced to wrap
rte_intr_enable/disable to enhance the ability to detect msix. Only
support and enable msix can assign "1" to use_msix.

Should be "2". Better to use macro here.


Fixes: cb482cb3a305 ("net/virtio: fix MAC address read")
Signed-off-by: Zhiyong Yang 
---
@@ -1370,7 +1411,15 @@ virtio_init_device(struct rte_eth_dev *eth_dev,

uint64_t req_features)

struct virtio_net_config local_config;
struct rte_pci_device *pci_dev = NULL;
int ret;
+   int msix_detect;

+   msix_detect = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(eth_dev));
+   if (msix_detect < 0)
+   return -1;
+   else if (msix_detect == SUPPORT_MSIX_STATUS_ENABLED)
+   hw->use_msix = 1;
+   else
+   hw->use_msix = 0;

Ditto, we directly assign return value to hw->use_msix.


The function call can be removed if use_misx  can use 0, 1, 2 directly
We can implement the same logic  in  virtio_read_caps instead.


Actually, I prefer not hide such an assignment in this function name 
"*_detect".




Thanks
Zhiyong

Re: [dpdk-dev] [PATCH v3] net/virtio: fix rxq intr config fails using vfio-pci

[Tan, Jianfeng]

On 11/9/2017 11:18 AM, Zhiyong Yang wrote:

When running l3fwd-power to test virtio rxq interrupt using vfio
pci noiommu mode, startup fails. In the function virtio_read_caps,
the code if (flags & PCI_MSIX_ENABLE) intends to double check
if vfio msix is enabled or not. However, it is not enable at that
time. So use_msix is assigned to "0", not "1", which causes the
failure of configuring rxq intr in l3fwd-power.
This patch adds the function "vtpci_msix_detect" to detect the status
of msix when interrupt changes happen.
In the meanwhile, virtio_intr_enable/disable are introduced to wrap
rte_intr_enable/disable to enhance the ability to detect msix. Only
supporting and enabling msix can assign "VIRTIO_MSIX_ENABLED(2)" to
use_msix.


Above sentence seems not correct. As we can assign VIRTIO_MSIX_NONE, 
VIRTIO_MSIX_DISABLED, VIRTIO_MSIX_ENABLED to use_msix to indicate three 
different msix status.





Fixes: cb482cb3a305 ("net/virtio: fix MAC address read")
Signed-off-by: Zhiyong Yang 
---

Changes in v3:
Simply the code according to jianfeng's comments.

Changes in v2:
Add the capability to detect msix if virtio intr changes.

  drivers/net/virtio/virtio_ethdev.c | 46 ++--
  drivers/net/virtio/virtio_pci.c| 48 --
  drivers/net/virtio/virtio_pci.h|  6 +
  3 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index d2576d5e0..87ac2bee6 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -97,6 +97,9 @@ static void virtio_mac_addr_remove(struct rte_eth_dev *dev, 
uint32_t index);
  static void virtio_mac_addr_set(struct rte_eth_dev *dev,
struct ether_addr *mac_addr);
  
+static int virtio_intr_enable(struct rte_eth_dev *dev);

+static int virtio_intr_disable(struct rte_eth_dev *dev);
+
  static int virtio_dev_queue_stats_mapping_set(
struct rte_eth_dev *eth_dev,
uint16_t queue_id,
@@ -618,7 +621,7 @@ virtio_dev_close(struct rte_eth_dev *dev)
virtio_queues_unbind_intr(dev);
  
  	if (intr_conf->lsc || intr_conf->rxq) {

-   rte_intr_disable(dev->intr_handle);
+   virtio_intr_disable(dev);
rte_intr_efd_disable(dev->intr_handle);
rte_free(dev->intr_handle->intr_vec);
dev->intr_handle->intr_vec = NULL;
@@ -1160,6 +1163,34 @@ virtio_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
vlan_id, int on)
  }
  
  static int

+virtio_intr_enable(struct rte_eth_dev *dev)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+
+   if (rte_intr_enable(dev->intr_handle) < 0)
+   return -1;
+
+   if (!hw->virtio_user_dev)
+   hw->use_msix = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));


Maybe we can check hw->use_msix as an additional check; if it does not 
equal VIRTIO_MSIX_ENABLE, returns -1.



+
+   return 0;
+}
+
+static int
+virtio_intr_disable(struct rte_eth_dev *dev)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+
+   if (rte_intr_disable(dev->intr_handle) < 0)
+   return -1;
+
+   if (!hw->virtio_user_dev)
+   hw->use_msix = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
+
+   return 0;
+}
+
+static int
  virtio_negotiate_features(struct virtio_hw *hw, uint64_t req_features)
  {
uint64_t host_features;
@@ -1228,7 +1259,7 @@ virtio_interrupt_handler(void *param)
isr = vtpci_isr(hw);
PMD_DRV_LOG(INFO, "interrupt status = %#x", isr);
  
-	if (rte_intr_enable(dev->intr_handle) < 0)

+   if (virtio_intr_enable(dev) < 0)
PMD_DRV_LOG(ERR, "interrupt enable failed");
  
  	if (isr & VIRTIO_PCI_ISR_CONFIG) {

@@ -1348,7 +1379,7 @@ virtio_configure_intr(struct rte_eth_dev *dev)
 * to change the config size from 20 to 24, or VIRTIO_MSI_QUEUE_VECTOR
 * (22) will be ignored.
 */
-   if (rte_intr_enable(dev->intr_handle) < 0) {
+   if (virtio_intr_enable(dev) < 0) {
PMD_DRV_LOG(ERR, "interrupt enable failed");
return -1;
}
@@ -1388,7 +1419,8 @@ virtio_init_device(struct rte_eth_dev *eth_dev, uint64_t 
req_features)
}
  
  	/* If host does not support both status and MSI-X then disable LSC */

-   if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS) && hw->use_msix)
+   if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS) &&
+   hw->use_msix != VIRTIO_MSIX_NONE)
eth_dev->data->dev_flags |= RTE_ETH_DEV_INTR_LSC;
else
eth_dev->data->dev_flags &= ~RTE_ETH_DEV_INTR_LSC;
@@ -1801,9 +1833,9 @@ virtio_dev_start(struct rte_eth_dev *dev)
 */
if (dev->data->dev_conf.intr_conf.lsc ||
dev->data->dev_conf.intr_conf.rxq) {
-   rte_intr_disable(dev->intr_handle);
+   virtio_intr_disable(dev);
  
-		if (rte_intr_e

Re: [dpdk-dev] [PATCH v3] net/virtio: fix rxq intr config fails using vfio-pci

[Yang, Zhiyong]

> -Original Message-
> From: Tan, Jianfeng
> Sent: Thursday, November 9, 2017 11:47 AM
> To: Yang, Zhiyong ; dev@dpdk.org
> Cc: y...@fridaylinux.org
> Subject: Re: [PATCH v3] net/virtio: fix rxq intr config fails using vfio-pci
> 
> 
> 
> On 11/9/2017 11:18 AM, Zhiyong Yang wrote:
> > When running l3fwd-power to test virtio rxq interrupt using vfio pci
> > noiommu mode, startup fails. In the function virtio_read_caps, the
> > code if (flags & PCI_MSIX_ENABLE) intends to double check if vfio msix
> > is enabled or not. However, it is not enable at that time. So use_msix
> > is assigned to "0", not "1", which causes the failure of configuring
> > rxq intr in l3fwd-power.
> > This patch adds the function "vtpci_msix_detect" to detect the status
> > of msix when interrupt changes happen.
> > In the meanwhile, virtio_intr_enable/disable are introduced to wrap
> > rte_intr_enable/disable to enhance the ability to detect msix. Only
> > supporting and enabling msix can assign "VIRTIO_MSIX_ENABLED(2)" to
> > use_msix.
> 
> Above sentence seems not correct. As we can assign VIRTIO_MSIX_NONE,
> VIRTIO_MSIX_DISABLED, VIRTIO_MSIX_ENABLED to use_msix to indicate three
> different msix status.
> 

Right, I just want to say, supporting and enabling msix are true, use_misx can 
be assigned to 2.

> 
> >
> > Fixes: cb482cb3a305 ("net/virtio: fix MAC address read")
> > Signed-off-by: Zhiyong Yang 
> > ---
> >
> > Changes in v3:
> > Simply the code according to jianfeng's comments.
> >
> > Changes in v2:
> > Add the capability to detect msix if virtio intr changes.
> >
> >   drivers/net/virtio/virtio_ethdev.c | 46 ++--
> 
> >   drivers/net/virtio/virtio_pci.c| 48
> --
> >   drivers/net/virtio/virtio_pci.h|  6 +
> >   3 files changed, 91 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/virtio/virtio_ethdev.c
> > b/drivers/net/virtio/virtio_ethdev.c
> > index d2576d5e0..87ac2bee6 100644
> > --- a/drivers/net/virtio/virtio_ethdev.c
> > +++ b/drivers/net/virtio/virtio_ethdev.c
> > @@ -97,6 +97,9 @@ static void virtio_mac_addr_remove(struct rte_eth_dev
> *dev, uint32_t index);
> >   static void virtio_mac_addr_set(struct rte_eth_dev *dev,
> > struct ether_addr *mac_addr);
> >
> > +static int virtio_intr_enable(struct rte_eth_dev *dev); static int
> > +virtio_intr_disable(struct rte_eth_dev *dev);
> > +
> >   static int virtio_dev_queue_stats_mapping_set(
> > struct rte_eth_dev *eth_dev,
> > uint16_t queue_id,
> > @@ -618,7 +621,7 @@ virtio_dev_close(struct rte_eth_dev *dev)
> > virtio_queues_unbind_intr(dev);
> >
> > if (intr_conf->lsc || intr_conf->rxq) {
> > -   rte_intr_disable(dev->intr_handle);
> > +   virtio_intr_disable(dev);
> > rte_intr_efd_disable(dev->intr_handle);
> > rte_free(dev->intr_handle->intr_vec);
> > dev->intr_handle->intr_vec = NULL; @@ -1160,6 +1163,34 @@
> > virtio_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
> >   }
> >
> >   static int
> > +virtio_intr_enable(struct rte_eth_dev *dev) {
> > +   struct virtio_hw *hw = dev->data->dev_private;
> > +
> > +   if (rte_intr_enable(dev->intr_handle) < 0)
> > +   return -1;
> > +
> > +   if (!hw->virtio_user_dev)
> > +   hw->use_msix = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
> 
> Maybe we can check hw->use_msix as an additional check; if it does not equal
> VIRTIO_MSIX_ENABLE, returns -1.
>  
>From my understanding, it is unnecessary. 
Functionality of virtio_intr_enable  should be generic.
Igb_uio or other can use it. it should be no harm to others.
 we add msix detect here in order to just get use_msix status. 

Thanks
Zhiyong 

Re: [dpdk-dev] [PATCH v3] net/virtio: fix rxq intr config fails using vfio-pci

[Tan, Jianfeng]

On 11/9/2017 12:01 PM, Yang, Zhiyong wrote:


   static int
+virtio_intr_enable(struct rte_eth_dev *dev) {
+   struct virtio_hw *hw = dev->data->dev_private;
+
+   if (rte_intr_enable(dev->intr_handle) < 0)
+   return -1;
+
+   if (!hw->virtio_user_dev)
+   hw->use_msix = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));

Maybe we can check hw->use_msix as an additional check; if it does not equal
VIRTIO_MSIX_ENABLE, returns -1.
  

 From my understanding, it is unnecessary.
Functionality of virtio_intr_enable  should be generic.
Igb_uio or other can use it. it should be no harm to others.
  we add msix detect here in order to just get use_msix status.


Fair enough.



Thanks
Zhiyong

Re: [dpdk-dev] [PATCH 1/3] eal/arm64: remove the braces {} for dmb(), dsb()

[Jia He]

Hi Jianbo


On 11/9/2017 11:21 AM, Jianbo Liu Wrote:

The 11/09/2017 11:14, Jia He wrote:


On 11/9/2017 9:22 AM, Jia He Wrote:

Hi Bruce


On 11/8/2017 6:28 PM, Bruce Richardson Wrote:

On Wed, Nov 08, 2017 at 06:17:10AM +, Jia He wrote:

for the code as follows:
if (condition)
 rte_smp_rmb();
else
 rte_smp_wmb();
Without this patch, compiler will report this error:
error: 'else' without a previous 'if'

Signed-off-by: Jia He 
Signed-off-by: jia...@hxt-semitech.com
---
   lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git
a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
index 0b70d62..38c3393 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
@@ -43,8 +43,8 @@ extern "C" {
     #include "generic/rte_atomic.h"
   -#define dsb(opt)  { asm volatile("dsb " #opt : : : "memory"); }
-#define dmb(opt)  { asm volatile("dmb " #opt : : : "memory"); }
+#define dsb(opt) asm volatile("dsb " #opt : : : "memory");
+#define dmb(opt) asm volatile("dmb " #opt : : : "memory");

Need to remove the trailing ";" I too I think.
Alternatively, to keep the braces, the standard practice is to use
do { ... } while(0)

If trailing ";" is not removed
the code:
if (condition)
     rte_smp_rmb();
else
     anything();


Sorry, why not use two different functions as your conditions passed in
are fixed in the calling functions.
Do you mean to split update_tail() into update_tail_enqueue() and 
update_tail_dequeue()?

Cheers,
Jia

[dpdk-dev] [PATCH v4] net/virtio: fix rxq intr config fails using vfio-pci

[Zhiyong Yang]

When running l3fwd-power to test virtio rxq interrupt using vfio
pci noiommu mode, startup fails. In the function virtio_read_caps,
the code if (flags & PCI_MSIX_ENABLE) intends to double check
if vfio msix is enabled or not. However, it is not enable at that
time. So use_msix is assigned to "0", not "1", which causes the
failure of configuring rxq intr in l3fwd-power.
This patch adds the function "vtpci_msix_detect" to detect the status
of msix when interrupt changes happen.
In the meanwhile, virtio_intr_enable/disable are introduced to wrap
rte_intr_enable/disable to enhance the ability to detect msix.
use_msix can indicate three different msix status by:
VIRTIO_MSIX_NONE (0)
VIRTIO_MSIX_DISABLED (1)
VIRTIO_MSIX_ENABLED (2)

CC: sta...@dpdk.org
CC: jianfeng@intel.com
CC: y...@fridaylinux.org
CC: maxime.coque...@redhat.com

Fixes: cb482cb3a305 ("net/virtio: fix MAC address read")
Signed-off-by: Zhiyong Yang 
---

Changes in v4:
Enhance the commit log description.

Changes in v3:
Simply the code according to jianfeng's comments.

Changes in v2:
Add the capability to detect msix if virtio intr changes.

 drivers/net/virtio/virtio_ethdev.c | 46 ++--
 drivers/net/virtio/virtio_pci.c| 48 --
 drivers/net/virtio/virtio_pci.h|  6 +
 3 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index d2576d5e0..87ac2bee6 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -97,6 +97,9 @@ static void virtio_mac_addr_remove(struct rte_eth_dev *dev, 
uint32_t index);
 static void virtio_mac_addr_set(struct rte_eth_dev *dev,
struct ether_addr *mac_addr);
 
+static int virtio_intr_enable(struct rte_eth_dev *dev);
+static int virtio_intr_disable(struct rte_eth_dev *dev);
+
 static int virtio_dev_queue_stats_mapping_set(
struct rte_eth_dev *eth_dev,
uint16_t queue_id,
@@ -618,7 +621,7 @@ virtio_dev_close(struct rte_eth_dev *dev)
virtio_queues_unbind_intr(dev);
 
if (intr_conf->lsc || intr_conf->rxq) {
-   rte_intr_disable(dev->intr_handle);
+   virtio_intr_disable(dev);
rte_intr_efd_disable(dev->intr_handle);
rte_free(dev->intr_handle->intr_vec);
dev->intr_handle->intr_vec = NULL;
@@ -1160,6 +1163,34 @@ virtio_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
vlan_id, int on)
 }
 
 static int
+virtio_intr_enable(struct rte_eth_dev *dev)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+
+   if (rte_intr_enable(dev->intr_handle) < 0)
+   return -1;
+
+   if (!hw->virtio_user_dev)
+   hw->use_msix = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
+
+   return 0;
+}
+
+static int
+virtio_intr_disable(struct rte_eth_dev *dev)
+{
+   struct virtio_hw *hw = dev->data->dev_private;
+
+   if (rte_intr_disable(dev->intr_handle) < 0)
+   return -1;
+
+   if (!hw->virtio_user_dev)
+   hw->use_msix = vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
+
+   return 0;
+}
+
+static int
 virtio_negotiate_features(struct virtio_hw *hw, uint64_t req_features)
 {
uint64_t host_features;
@@ -1228,7 +1259,7 @@ virtio_interrupt_handler(void *param)
isr = vtpci_isr(hw);
PMD_DRV_LOG(INFO, "interrupt status = %#x", isr);
 
-   if (rte_intr_enable(dev->intr_handle) < 0)
+   if (virtio_intr_enable(dev) < 0)
PMD_DRV_LOG(ERR, "interrupt enable failed");
 
if (isr & VIRTIO_PCI_ISR_CONFIG) {
@@ -1348,7 +1379,7 @@ virtio_configure_intr(struct rte_eth_dev *dev)
 * to change the config size from 20 to 24, or VIRTIO_MSI_QUEUE_VECTOR
 * (22) will be ignored.
 */
-   if (rte_intr_enable(dev->intr_handle) < 0) {
+   if (virtio_intr_enable(dev) < 0) {
PMD_DRV_LOG(ERR, "interrupt enable failed");
return -1;
}
@@ -1388,7 +1419,8 @@ virtio_init_device(struct rte_eth_dev *eth_dev, uint64_t 
req_features)
}
 
/* If host does not support both status and MSI-X then disable LSC */
-   if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS) && hw->use_msix)
+   if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS) &&
+   hw->use_msix != VIRTIO_MSIX_NONE)
eth_dev->data->dev_flags |= RTE_ETH_DEV_INTR_LSC;
else
eth_dev->data->dev_flags &= ~RTE_ETH_DEV_INTR_LSC;
@@ -1801,9 +1833,9 @@ virtio_dev_start(struct rte_eth_dev *dev)
 */
if (dev->data->dev_conf.intr_conf.lsc ||
dev->data->dev_conf.intr_conf.rxq) {
-   rte_intr_disable(dev->intr_handle);
+   virtio_intr_disable(dev);
 
-   if (rte_intr_enable(dev->intr_handle) < 0) {
+   if (virtio_intr_enable(dev) < 0) {
PMD_DRV_LOG(ERR, "in

Re: [dpdk-dev] [PATCH 1/3] eal/arm64: remove the braces {} for dmb(), dsb()

[Jianbo Liu]

The 11/09/2017 12:43, Jia He wrote:
> Hi Jianbo
>
>
> On 11/9/2017 11:21 AM, Jianbo Liu Wrote:
> >The 11/09/2017 11:14, Jia He wrote:
> >>
> >>On 11/9/2017 9:22 AM, Jia He Wrote:
> >>>Hi Bruce
> >>>
> >>>
> >>>On 11/8/2017 6:28 PM, Bruce Richardson Wrote:
> On Wed, Nov 08, 2017 at 06:17:10AM +, Jia He wrote:
> >for the code as follows:
> >if (condition)
> > rte_smp_rmb();
> >else
> > rte_smp_wmb();
> >Without this patch, compiler will report this error:
> >error: 'else' without a previous 'if'
> >
> >Signed-off-by: Jia He 
> >Signed-off-by: jia...@hxt-semitech.com
> >---
> >   lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git
> >a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> >b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> >index 0b70d62..38c3393 100644
> >--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> >+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> >@@ -43,8 +43,8 @@ extern "C" {
> > #include "generic/rte_atomic.h"
> >   -#define dsb(opt)  { asm volatile("dsb " #opt : : : "memory"); }
> >-#define dmb(opt)  { asm volatile("dmb " #opt : : : "memory"); }
> >+#define dsb(opt) asm volatile("dsb " #opt : : : "memory");
> >+#define dmb(opt) asm volatile("dmb " #opt : : : "memory");
> Need to remove the trailing ";" I too I think.
> Alternatively, to keep the braces, the standard practice is to use
> do { ... } while(0)
> >>>If trailing ";" is not removed
> >>>the code:
> >>>if (condition)
> >>> rte_smp_rmb();
> >>>else
> >>> anything();
> >>>
> >Sorry, why not use two different functions as your conditions passed in
> >are fixed in the calling functions.
> Do you mean to split update_tail() into update_tail_enqueue() and
> update_tail_dequeue()?

Yes. So it's not need to change dsb/dmb.

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

[dpdk-dev] [PATCH] net/i40e: fix VF cannot forward packets issue

[Xiaoyun Li]

When Rx interrupt is not enabled, there is no need to check if interrupt
allow others. It will cause VF cannot forwarding packets issue. This patch
fixes this issue.

Fixes: 96a9fd03c25f ("net/i40e: fix Rx queue interrupt mapping in VF")
Cc: sta...@dpdk.org

Signed-off-by: Xiaoyun Li 
---
 drivers/net/i40e/i40e_ethdev_vf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 02d9e57..91b5bb0 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -650,7 +650,8 @@ i40evf_config_irq_map(struct rte_eth_dev *dev)
uint32_t vector_id;
int i, err;
 
-   if (rte_intr_allow_others(intr_handle))
+   if (dev->data->dev_conf.intr_conf.rxq != 0 &&
+   rte_intr_allow_others(intr_handle))
vector_id = I40E_RX_VEC_START;
else
vector_id = I40E_MISC_VEC_ID;
-- 
2.7.4

Re: [dpdk-dev] [PATCH v4] net/virtio: fix rxq intr config fails using vfio-pci

[Tan, Jianfeng]

> -Original Message-
> From: Yang, Zhiyong
> Sent: Thursday, November 9, 2017 12:46 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Tan, Jianfeng; y...@fridaylinux.org;
> maxime.coque...@redhat.com; Yang, Zhiyong
> Subject: [PATCH v4] net/virtio: fix rxq intr config fails using vfio-pci
> 
> When running l3fwd-power to test virtio rxq interrupt using vfio
> pci noiommu mode, startup fails. In the function virtio_read_caps,
> the code if (flags & PCI_MSIX_ENABLE) intends to double check
> if vfio msix is enabled or not. However, it is not enable at that
> time. So use_msix is assigned to "0", not "1", which causes the
> failure of configuring rxq intr in l3fwd-power.
> This patch adds the function "vtpci_msix_detect" to detect the status
> of msix when interrupt changes happen.
> In the meanwhile, virtio_intr_enable/disable are introduced to wrap
> rte_intr_enable/disable to enhance the ability to detect msix.
> use_msix can indicate three different msix status by:
> VIRTIO_MSIX_NONE (0)
> VIRTIO_MSIX_DISABLED (1)
> VIRTIO_MSIX_ENABLED (2)
> 
> CC: sta...@dpdk.org
> CC: jianfeng@intel.com
> CC: y...@fridaylinux.org
> CC: maxime.coque...@redhat.com
> 
> Fixes: cb482cb3a305 ("net/virtio: fix MAC address read")
> Signed-off-by: Zhiyong Yang 

Except a small nit, looks good to me:

Acked-by: Jianfeng Tan 

> ---
> 
> Changes in v4:
> Enhance the commit log description.
> 
> Changes in v3:
> Simply the code according to jianfeng's comments.
> 
> Changes in v2:
> Add the capability to detect msix if virtio intr changes.
> 
>  drivers/net/virtio/virtio_ethdev.c | 46
> ++--
>  drivers/net/virtio/virtio_pci.c| 48
> --
>  drivers/net/virtio/virtio_pci.h|  6 +
>  3 files changed, 91 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index d2576d5e0..87ac2bee6 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -97,6 +97,9 @@ static void virtio_mac_addr_remove(struct rte_eth_dev
> *dev, uint32_t index);
>  static void virtio_mac_addr_set(struct rte_eth_dev *dev,
>   struct ether_addr *mac_addr);
> 
> +static int virtio_intr_enable(struct rte_eth_dev *dev);
> +static int virtio_intr_disable(struct rte_eth_dev *dev);
> +
>  static int virtio_dev_queue_stats_mapping_set(
>   struct rte_eth_dev *eth_dev,
>   uint16_t queue_id,
> @@ -618,7 +621,7 @@ virtio_dev_close(struct rte_eth_dev *dev)
>   virtio_queues_unbind_intr(dev);
> 
>   if (intr_conf->lsc || intr_conf->rxq) {
> - rte_intr_disable(dev->intr_handle);
> + virtio_intr_disable(dev);
>   rte_intr_efd_disable(dev->intr_handle);
>   rte_free(dev->intr_handle->intr_vec);
>   dev->intr_handle->intr_vec = NULL;
> @@ -1160,6 +1163,34 @@ virtio_vlan_filter_set(struct rte_eth_dev *dev,
> uint16_t vlan_id, int on)
>  }
> 
>  static int
> +virtio_intr_enable(struct rte_eth_dev *dev)
> +{
> + struct virtio_hw *hw = dev->data->dev_private;
> +
> + if (rte_intr_enable(dev->intr_handle) < 0)
> + return -1;
> +
> + if (!hw->virtio_user_dev)
> + hw->use_msix =
> vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
> +
> + return 0;
> +}
> +
> +static int
> +virtio_intr_disable(struct rte_eth_dev *dev)
> +{
> + struct virtio_hw *hw = dev->data->dev_private;
> +
> + if (rte_intr_disable(dev->intr_handle) < 0)
> + return -1;
> +
> + if (!hw->virtio_user_dev)
> + hw->use_msix =
> vtpci_msix_detect(RTE_ETH_DEV_TO_PCI(dev));
> +
> + return 0;
> +}
> +
> +static int
>  virtio_negotiate_features(struct virtio_hw *hw, uint64_t req_features)
>  {
>   uint64_t host_features;
> @@ -1228,7 +1259,7 @@ virtio_interrupt_handler(void *param)
>   isr = vtpci_isr(hw);
>   PMD_DRV_LOG(INFO, "interrupt status = %#x", isr);
> 
> - if (rte_intr_enable(dev->intr_handle) < 0)
> + if (virtio_intr_enable(dev) < 0)
>   PMD_DRV_LOG(ERR, "interrupt enable failed");
> 
>   if (isr & VIRTIO_PCI_ISR_CONFIG) {
> @@ -1348,7 +1379,7 @@ virtio_configure_intr(struct rte_eth_dev *dev)
>* to change the config size from 20 to 24, or
> VIRTIO_MSI_QUEUE_VECTOR
>* (22) will be ignored.
>*/
> - if (rte_intr_enable(dev->intr_handle) < 0) {
> + if (virtio_intr_enable(dev) < 0) {
>   PMD_DRV_LOG(ERR, "interrupt enable failed");
>   return -1;
>   }
> @@ -1388,7 +1419,8 @@ virtio_init_device(struct rte_eth_dev *eth_dev,
> uint64_t req_features)
>   }
> 
>   /* If host does not support both status and MSI-X then disable LSC */
> - if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS) && hw-
> >use_msix)
> + if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS) &&
> + hw->use_msix != VIRTIO_MSIX_NONE)
>   eth_dev->data->dev_flags

[dpdk-dev] [PATCH 1/2] doc: update QEDE pmd nic guide

[Rasesh Mody]

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

diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
index 09a10be..84becc9 100644
--- a/doc/guides/nics/qede.rst
+++ b/doc/guides/nics/qede.rst
@@ -1,5 +1,6 @@
 ..  BSD LICENSE
 Copyright (c) 2016 QLogic Corporation
+Copyright (c) 2017 Cavium Inc.
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
@@ -32,8 +33,7 @@ QEDE Poll Mode Driver
 ==
 
 The QEDE poll mode driver library (**librte_pmd_qede**) implements support
-for **QLogic FastLinQ QL4 10G/25G/40G/50G/100G CNA** family of adapters as 
well
-as their virtual functions (VF) in SR-IOV context. It is supported on
+for **QLogic FastLinQ QL4 10G/25G/40G/50G/100G Intelligent Ethernet 
Adapters (IEA) and Converged Network Adapters (CNA)** family of adapters as 
well as SR-IOV virtual functions (VF). It is supported on
 several standard Linux distros like RHEL7.x, SLES12.x and Ubuntu.
 It is compile-tested under FreeBSD OS.
 
@@ -48,21 +48,22 @@ Supported Features
 - Allmulti mode
 - Port hardware statistics
 - Jumbo frames
-- VLAN offload - Filtering and stripping
-- Stateless checksum offloads (IPv4/TCP/UDP)
-- Multiple Rx/Tx queues
-- RSS (with RETA/hash table/key)
-- TSS
 - Multiple MAC address
-- Default pause flow control
-- SR-IOV VF
 - MTU change
+- Default pause flow control
 - Multiprocess aware
 - Scatter-Gather
-- VXLAN tunneling offload
-- N-tuple filter and flow director (limited support)
+- Multiple Rx/Tx queues
+- RSS (with RETA/hash table/key)
+- TSS
+- Stateless checksum offloads (IPv4/IPv6/TCP/UDP)
 - LRO/TSO
+- VLAN offload - Filtering and stripping
+- N-tuple filter and flow director (limited support)
 - NPAR (NIC Partitioning)
+- SR-IOV VF
+- VXLAN tunneling offload
+- MPLSoUDP Tx tunnel offload
 
 Non-supported Features
 --
@@ -73,18 +74,30 @@ Non-supported Features
 Supported QLogic Adapters
 -
 
-- QLogic FastLinQ QL4 10G/25G/40G/50G/100G CNAs.
+- QLogic FastLinQ QL4 10G/25G/40G/50G/100G Intelligent Ethernet Adapters 
(IEA) and Converged Network Adapters (CNA)
 
 Prerequisites
 -
 
-- Requires firmware version **8.18.x.** and management firmware
-  version **8.18.x or higher**. Firmware may be available
+- Requires storm firmware version **8.30.12.0**. Firmware may be available
   inbox in certain newer Linux distros under the standard directory
-  ``E.g. /lib/firmware/qed/qed_init_values-8.18.9.0.bin``
+  ``E.g. /lib/firmware/qed/qed_init_values-8.30.12.0.bin``
+  If the required firmware files are not available then download it from
+  `QLogic Driver Download Center 
`_.
+  For downloading firmware file, select adapter category, model and DPDK Poll 
Mode Driver.
+
+- Requires management firmware (MFW) version **8.30.x.x** or higher to be
+  flashed on to the adapter. If the required management firmware is not
+  available then download from
+  `QLogic Driver Download Center 
`_.
+  For downloading firmware upgrade utility, select adapter category, model and 
Linux distro.
+  To flash the management firmware refer to the instructions in the QLogic 
Firmware Upgrade Utility Readme document.
+
+- SR-IOV requires Linux PF driver version **8.20.x.x** or higher.
+  If the required PF driver is not available then download it from
+  `QLogic Driver Download Center 
`_.
+  For downloading PF driver, select adapter category, model and Linux distro.
 
-- If the required firmware files are not available then visit
-  `QLogic Driver Download Center `_.
 
 Performance note
 
@@ -117,12 +130,18 @@ enabling debugging options may affect system performance.
 
   Toggle display of receive fast path run-time messages.
 
+- ``CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH`` (default **"y"**)
+
+  A knob to control per-VF Tx switching feature.
+
 - ``CONFIG_RTE_LIBRTE_QEDE_FW`` (default **""**)
 
   Gives absolute path of firmware file.
-  ``Eg: "/lib/firmware/qed/qed_init_values_zipped-8.18.9.0.bin"``
+  ``Eg: "/lib/firmware/qed/qed_init_values-8.30.12.0.bin"``
   Empty string indicates driver will pick up the firmware file
-  from the default location.
+  from the default location /lib/firmware/qed.
+  CAUTION this option is more for custom firmware, it is not
+  recommended for use under normal condition.
 
 Driver compilation and testing
 --
@@ -135,7 +154,7 @@ SR-IOV: Prerequisites and Sample Application Notes
 
 This section provides instructions to configure SR-IOV with Linux OS.
 
-**Note**: librte_pmd_qede will be u

[dpdk-dev] [RFC] eventdev: add caps API and PMD callback for crypto adapter

[Abhinandan Gujjar]

Signed-off-by: Abhinandan Gujjar 
Signed-off-by: Nikhil Rao 
---
 lib/librte_eventdev/rte_eventdev.c | 25 +++
 lib/librte_eventdev/rte_eventdev.h | 44 ++
 lib/librte_eventdev/rte_eventdev_pmd.h | 32 +
 3 files changed, 101 insertions(+)

diff --git a/lib/librte_eventdev/rte_eventdev.c 
b/lib/librte_eventdev/rte_eventdev.c
index ce6a5dc..3f9475e 100644
--- a/lib/librte_eventdev/rte_eventdev.c
+++ b/lib/librte_eventdev/rte_eventdev.c
@@ -57,6 +57,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "rte_eventdev.h"
 #include "rte_eventdev_pmd.h"
@@ -151,6 +153,29 @@
: 0;
 }
 
+int
+rte_event_crypto_adapter_caps_get(uint8_t dev_id, uint8_t cdev_id,
+uint32_t *caps)
+{
+   struct rte_eventdev *dev;
+   struct rte_cryptodev *cdev;
+
+   RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+   if (!rte_cryptodev_pmd_is_valid_dev(cdev_id))
+   return -EINVAL;
+
+   dev = &rte_eventdevs[dev_id];
+   cdev = rte_cryptodev_pmd_get_dev(cdev_id);
+
+   if (caps == NULL)
+   return -EINVAL;
+   *caps = 0;
+
+   return dev->dev_ops->crypto_adapter_caps_get ?
+   (*dev->dev_ops->crypto_adapter_caps_get)
+   (dev, cdev, caps) : 0;
+}
+
 static inline int
 rte_event_dev_queue_config(struct rte_eventdev *dev, uint8_t nb_queues)
 {
diff --git a/lib/librte_eventdev/rte_eventdev.h 
b/lib/librte_eventdev/rte_eventdev.h
index f1949ff..65a9edd 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -1048,6 +1048,50 @@ struct rte_event {
 rte_event_eth_rx_adapter_caps_get(uint8_t dev_id, uint8_t eth_port_id,
uint32_t *caps);
 
+
+/* Crypto Rx adapter capability bitmap flags */
+#define RTE_EVENT_CYRPTO_ADAPTER_CAP_INTERNAL_PORT 0x1
+/**< Flag indicates HW is capable of generating events.
+ * Cryptodev can send packets to the event device using internal event port.
+ */
+#define RTE_EVENT_CRYPTO_ADAPTER_CAP_MULTI_EVENTQ  0x2
+/**< Flag indicates adapter supports multiple event queues per cryptodev.
+ * Each cryptodev queue pair can be connected to a unique event queue.
+ */
+#define RTE_EVENT_CRYPTO_ADAPTER_CAP_MBUF_MULTI_EVENTQ 0x3
+/**< Flag indicates adapter supports event queue enqueue based on mbuf 
metadata.
+ * Mbuf metadata will be used enqueue to unique event queue.
+ * Event information will be stored in metadata of each mbuf
+ * @see struct rte_event_crypto_adapter_mbuf_metadata
+ */
+
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Retrieve the event device's crypto Rx adapter capabilities for the
+ * specified cryptodev device
+ *
+ * @param dev_id
+ *   The identifier of the device.
+ *
+ * @param qp_id
+ *   The queue pair id of the cryptodev device.
+ *
+ * @param[out] caps
+ *   A pointer to memory filled with Rx event adapter capabilities.
+ *
+ * @return
+ *   - 0: Success, driver provides Rx event adapter capabilities for the
+ * cryptodev device.
+ *   - <0: Error code returned by the driver function.
+ *
+ */
+int
+rte_event_crypto_adapter_caps_get(uint8_t dev_id, uint8_t eth_port_id,
+uint32_t *caps);
+
 struct rte_eventdev_driver;
 struct rte_eventdev_ops;
 struct rte_eventdev;
diff --git a/lib/librte_eventdev/rte_eventdev_pmd.h 
b/lib/librte_eventdev/rte_eventdev_pmd.h
index 7a206c5..77886e0 100644
--- a/lib/librte_eventdev/rte_eventdev_pmd.h
+++ b/lib/librte_eventdev/rte_eventdev_pmd.h
@@ -596,6 +596,35 @@ typedef int (*eventdev_eth_rx_adapter_stats_reset)
(const struct rte_eventdev *dev,
const struct rte_eth_dev *eth_dev);
 
+
+struct rte_cryptodev;
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Retrieve the event device's crypto Rx adapter capabilities for the
+ * specified cryptodev
+ *
+ * @param dev
+ *   Event device pointer
+ *
+ * @param crypto_dev
+ *   cryptodev pointer
+ *
+ * @param[out] caps
+ *   A pointer to memory filled with Rx event adapter capabilities.
+ *
+ * @return
+ *   - 0: Success, driver provides Rx event adapter capabilities for the
+ * cryptodev.
+ *   - <0: Error code returned by the driver function.
+ *
+ */
+typedef int (*eventdev_crypto_adapter_caps_get_t)
+   (const struct rte_eventdev *dev,
+   const struct rte_cryptodev *cdev,
+   uint32_t *caps);
+
 /** Event device operations function pointer table */
 struct rte_eventdev_ops {
eventdev_info_get_t dev_infos_get;  /**< Get device info. */
@@ -650,6 +679,9 @@ struct rte_eventdev_ops {
/**< Get ethernet Rx stats */
eventdev_eth_rx_adapter_stats_reset eth_rx_adapter_stats_reset;
/**< Reset

[dpdk-dev] [PATCH 2/2] net/qede: fix default config option

[Rasesh Mody]

From: Harish Patil 

Restore the default configuration as in previous releases and
add a debug msg.

Fixes: f07aa795c92a ("net/qede: disable per-VF Tx switching feature")

Signed-off-by: Harish Patil 
Signed-off-by: Rasesh Mody 
---
 config/common_base |2 +-
 drivers/net/qede/qede_ethdev.c |5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/config/common_base b/config/common_base
index 34f04a9..e74febe 100644
--- a/config/common_base
+++ b/config/common_base
@@ -415,7 +415,7 @@ CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
 CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
-CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH=n
+CONFIG_RTE_LIBRTE_QEDE_VF_TX_SWITCH=y
 #Provides abs path/name of the firmware file.
 #Empty string denotes driver will use default firmware
 CONFIG_RTE_LIBRTE_QEDE_FW=""
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 8832145..6f5ba2a 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -457,6 +457,7 @@ int qede_activate_vport(struct rte_eth_dev *eth_dev, bool 
flg)
if (IS_VF(edev)) {
params.update_tx_switching_flg = 1;
params.tx_switching_flg = !flg;
+   DP_INFO(edev, "VF tx-switching is disabled\n");
}
 #endif
for_each_hwfn(edev, i) {
@@ -469,8 +470,8 @@ int qede_activate_vport(struct rte_eth_dev *eth_dev, bool 
flg)
break;
}
}
-   DP_INFO(edev, "vport %s VF tx-switch %s\n", flg ? "activated" : 
"deactivated",
-   params.tx_switching_flg ? "enabled" : "disabled");
+   DP_INFO(edev, "vport is %s\n", flg ? "activated" : "deactivated");
+
return rc;
 }
 
-- 
1.7.10.3

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

[Abhinandan Gujjar]

Signed-off-by: Abhinandan Gujjar 
Signed-off-by: Nikhil Rao 
Signed-off-by: Gage Eads 
---
 lib/librte_eventdev/Makefile   |   1 +
 lib/librte_eventdev/rte_event_crypto_adapter.h | 474 +
 2 files changed, 475 insertions(+)
 create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h

diff --git a/lib/librte_eventdev/Makefile b/lib/librte_eventdev/Makefile
index 5ac22cd..9cbe1a6 100644
--- a/lib/librte_eventdev/Makefile
+++ b/lib/librte_eventdev/Makefile
@@ -53,6 +53,7 @@ SYMLINK-y-include += rte_eventdev_pmd_pci.h
 SYMLINK-y-include += rte_eventdev_pmd_vdev.h
 SYMLINK-y-include += rte_event_ring.h
 SYMLINK-y-include += rte_event_eth_rx_adapter.h
+SYMLINK-y-include += rte_event_crypto_adapter.h
 
 # versioning export map
 EXPORT_MAP := rte_eventdev_version.map
diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h 
b/lib/librte_eventdev/rte_event_crypto_adapter.h
new file mode 100644
index 000..080c3ed
--- /dev/null
+++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
@@ -0,0 +1,474 @@
+/*
+ *   Copyright(c) 2017 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_EVENT_CRYPTO_ADAPTER_
+#define _RTE_EVENT_CRYPTO_ADAPTER_
+
+/**
+ * This adapter adds support to enqueue crypto completion to event device.
+ * The packet flow from cryptodev to the event device can be accomplished
+ * using either HW or SW mechanisms.
+ * The adapter uses a EAL service core function for SW based packet transfer
+ * and uses the eventdev PMD functions to configure HW based packet transfer
+ * between the cryptodev and the event device.
+ *
+ * The event crypto adapter provides common APIs to configure the packet flow
+ * from the cryptodev to event devices on both HW and SW.
+ * The crypto event adapter's functions are:
+ *  - rte_event_crypto_adapter_create_ext()
+ *  - rte_event_crypto_adapter_create()
+ *  - rte_event_crypto_adapter_free()
+ *  - rte_event_crypto_adapter_queue_pair_add()
+ *  - rte_event_crypto_adapter_queue_pair_del()
+ *  - rte_event_crypto_adapter_start()
+ *  - rte_event_crypto_adapter_stop()
+ *  - rte_event_crypto_adapter_stats_get()
+ *  - rte_event_crypto_adapter_stats_reset()
+
+ * The applicaton creates an instance using rte_event_crypto_adapter_create()
+ * or rte_event_crypto_adapter_create_ext().
+ *
+ * Cryptodev queue pair addition/deletion is done
+ * using rte_event_crypto_adapter_queue_pair_xxx() API.
+ *
+ * Adapter uses rte_event_crypto_queue_pair_conf to decide whether the event
+ * enqueue is based on RTE_EVENT_CRYPTO_ENQ_MULTI_EVENTQ or
+ * RTE_EVENT_CRYPTO_ENQ_MBUF_MULTI_EVENTQ.
+ * In case of RTE_EVENT_CRYPTO_ENQ_MULTI_EVENTQ,
+ * rte_event_crypto_queue_pair_conf::ev will be used for event enqueue.
+ * In case of RTE_EVENT_CRYPTO_ENQ_MBUF_MULTI_EVENTQ,
+ * members of rte_event_crypto_metadata will be used for event enqueue.
+ *
+ * The metadata offset is used to configure the location of the
+ * rte_event_crypto_metadata structure within the mbuf's private metadata area.
+ *
+ * When the application sends crypto operations to the adapter,
+ * the crypto queue pair identifier needs to be specified, similarly eventdev
+ * parameters such as the flow id, scheduling type etc are needed by the
+ * adapter when it enqueues mbufs from completed crypto operations to eventdev.
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+