[dpdk-dev] [PATCH 4/4] szedata2: add 100G link speed

[Thomas Monjalon]

2016-03-15 14:50, Matej Vido:
> 
> D?a 15.03.2016 o 14:41 Thomas Monjalon nap?sal(a):
> > Thanks for the series completing the ethdev rework with the same splitting.
> >
> > 2016-03-15 14:12, Matej Vido:
> >> Temporary 10G constant is replaced with 100G constant.
> >> Item speed_capa from struct rte_eth_dev_info is set with 100G flag.
> > [...]
> >> @@ -1161,7 +1162,7 @@ eth_link_update(struct rte_eth_dev *dev,
> >> * will be changed to support 100Gbps speed change
> >> * this value to 100G.
> >> */
> >> -  link.link_speed = ETH_SPEED_NUM_10G;
> >> +  link.link_speed = ETH_SPEED_NUM_100G;
> > Shouldn't we remove the above comment?
> Yes, I forgot. Should I remove the comment and send again or could you 
> do it when merging with original series?

I'll do it, thanks.

[dpdk-dev] [PATCH v2] l3fwd: Fix compilation & enable exact match mode on ARM.

[Thomas Monjalon]

Hi Maciej,

2016-03-15 21:05, Maciej.Czekaj at caviumnetworks.com:
> v2:
>  * Fixed compilation issue with HASH_MULTI_LOOKUP

2 comments:
- your patch v1 is already applied, so now we need a standalone fix
- you do not need to send a cover letter for an unique patch

Thanks

[dpdk-dev] [PATCH v6] enic: receive path performance improvements

[Thomas Monjalon]

2016-03-04 13:09, John Daley:
> +#ifdef RTE_NEXT_ABI
> +   pkt_err_flags |= PKT_RX_MAC_ERR;
> +#else
> +   pkt_err_flags |= PKT_EXT_RX_PKT_ERROR;
> +#endif
> +   }
> +
> +   /* Check for bad FCS. MAC error isn't quite, but no other choice */
> +   if (!enic_cq_rx_desc_fcs_ok(cqrd)) {
> +#ifdef RTE_NEXT_ABI
> +   pkt_err_flags |= PKT_RX_MAC_ERR;
> +#else
> +   pkt_err_flags |= PKT_EXT_RX_BAD_FCS;
> +#endif

It seems to be a mistake, leading to build failure when NEXT_ABI is disabled.
Will be fixed when rebased on master branch.

[dpdk-dev] [PATCH v4 5/6] vmxnet3: add TSO support

[Thomas Monjalon]

2016-01-12 18:08, Yong Wang:
> +   /* Drop non-TSO packet that is excessively fragmented */
> +   if (unlikely(!tso && count > VMXNET3_MAX_TXD_PER_PKT)) {
> +   PMD_TX_LOG(ERROR, "Non-TSO packet cannot occupy more 
> than %d tx "
> +  "descriptors. Packet dropped.", 
> VMXNET3_MAX_TXD_PER_PKT);
> 

It cannot compile because rte_log.h defines RTE_LOG_ERR not RTE_LOG_ERROR.
Will be fixed when rebased on master branch.

[dpdk-dev] [PATCH v2] l3fwd: Fix compilation & enable exact match mode on ARM.

[maciej.cze...@caviumnetworks.com]

From: Maciej Czekaj 

Enable NEON support in exact match mode.
l3fwd example did not compile on ARM due to SSE2 instrincics used
in generic part.
Some instrinsins were used to initialize data structures and those were
replaced by ordinary structure initalization.
All SSE2 intrinsics used in forwarding, i.e. masking the IP/TCP header
are moved to single inline function and made arch-specific.

Signed-off-by: Maciej Czekaj 
---
 examples/l3fwd/l3fwd.h|  4 ++-
 examples/l3fwd/l3fwd_em.c | 72 ---
 examples/l3fwd/l3fwd_em_hlm_sse.h | 32 -
 examples/l3fwd/main.c |  2 +-
 4 files changed, 64 insertions(+), 46 deletions(-)

diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index da6d369..7dcc7e5 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -34,6 +34,8 @@
 #ifndef __L3_FWD_H__
 #define __L3_FWD_H__

+#include 
+
 #define DO_RFC_1812_CHECKS

 #define RTE_LOGTYPE_L3FWD RTE_LOGTYPE_USER1
@@ -103,7 +105,7 @@ extern uint32_t enabled_port_mask;
 extern int ipv6; /**< ipv6 is false by default. */
 extern uint32_t hash_entry_number;

-extern __m128i val_eth[RTE_MAX_ETHPORTS];
+extern xmm_t val_eth[RTE_MAX_ETHPORTS];

 extern struct lcore_conf lcore_conf[RTE_MAX_LCORE];

diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index f6a65d8..0adf8f4 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -85,7 +85,7 @@ union ipv4_5tuple_host {
uint16_t port_src;
uint16_t port_dst;
};
-   __m128i xmm;
+   xmm_t xmm;
 };

 #define XMM_NUM_IN_IPV6_5TUPLE 3
@@ -109,9 +109,11 @@ union ipv6_5tuple_host {
uint16_t port_dst;
uint64_t reserve;
};
-   __m128i xmm[XMM_NUM_IN_IPV6_5TUPLE];
+   xmm_t xmm[XMM_NUM_IN_IPV6_5TUPLE];
 };

+
+
 struct ipv4_l3fwd_em_route {
struct ipv4_5tuple key;
uint8_t if_out;
@@ -236,9 +238,27 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t 
data_len,
 static uint8_t ipv4_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
 static uint8_t ipv6_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;

-static __m128i mask0;
-static __m128i mask1;
-static __m128i mask2;
+static rte_xmm_t mask0;
+static rte_xmm_t mask1;
+static rte_xmm_t mask2;
+
+#if defined(__SSE2__)
+static inline xmm_t
+em_mask_key(void *key, xmm_t mask)
+{
+   __m128i data = _mm_loadu_si128((__m128i *)(key));
+
+   return _mm_and_si128(data, mask);
+}
+#elif defined(__ARM_NEON)
+static inline xmm_t
+em_mask_key(void *key, xmm_t mask)
+{
+   int32x4_t data = vld1q_s32((int32_t *)key);
+
+   return vandq_s32(data, mask);
+}
+#endif

 static inline uint8_t
 em_get_ipv4_dst_port(void *ipv4_hdr, uint8_t portid, void *lookup_struct)
@@ -249,13 +269,12 @@ em_get_ipv4_dst_port(void *ipv4_hdr, uint8_t portid, void 
*lookup_struct)
(struct rte_hash *)lookup_struct;

ipv4_hdr = (uint8_t *)ipv4_hdr + offsetof(struct ipv4_hdr, 
time_to_live);
-   __m128i data = _mm_loadu_si128((__m128i *)(ipv4_hdr));

/*
 * Get 5 tuple: dst port, src port, dst IP address,
 * src IP address and protocol.
 */
-   key.xmm = _mm_and_si128(data, mask0);
+   key.xmm = em_mask_key(ipv4_hdr, mask0.x);

/* Find destination port */
ret = rte_hash_lookup(ipv4_l3fwd_lookup_struct, (const void *));
@@ -271,35 +290,31 @@ em_get_ipv6_dst_port(void *ipv6_hdr,  uint8_t portid, 
void *lookup_struct)
(struct rte_hash *)lookup_struct;

ipv6_hdr = (uint8_t *)ipv6_hdr + offsetof(struct ipv6_hdr, payload_len);
-   __m128i data0 =
-   _mm_loadu_si128((__m128i *)(ipv6_hdr));
-   __m128i data1 =
-   _mm_loadu_si128((__m128i *)(((uint8_t *)ipv6_hdr)+
-   sizeof(__m128i)));
-   __m128i data2 =
-   _mm_loadu_si128((__m128i *)(((uint8_t *)ipv6_hdr)+
-   sizeof(__m128i)+sizeof(__m128i)));
+   void *data0 = ipv6_hdr;
+   void *data1 = ((uint8_t *)ipv6_hdr) + sizeof(xmm_t);
+   void *data2 = ((uint8_t *)ipv6_hdr) + sizeof(xmm_t) + sizeof(xmm_t);

/* Get part of 5 tuple: src IP address lower 96 bits and protocol */
-   key.xmm[0] = _mm_and_si128(data0, mask1);
+   key.xmm[0] = em_mask_key(data0, mask1.x);

/*
 * Get part of 5 tuple: dst IP address lower 96 bits
 * and src IP address higher 32 bits.
 */
-   key.xmm[1] = data1;
+   key.xmm[1] = *(xmm_t *)data1;

/*
 * Get part of 5 tuple: dst port and src port
 * and dst IP address higher 32 bits.
 */
-   key.xmm[2] = _mm_and_si128(data2, mask2);
+   key.xmm[2] = em_mask_key(data2, mask2.x);

/* Find destination port */
ret = rte_hash_lookup(ipv6_l3fwd_lookup_struct, (const void *));

[dpdk-dev] [PATCH v2] l3fwd: Fix compilation & enable exact match mode on ARM.

[maciej.cze...@caviumnetworks.com]

From: Maciej Czekaj 

v2:
 * Fixed compilation issue with HASH_MULTI_LOOKUP

Maciej Czekaj (1):
  l3fwd: Fix compilation & enable exact match mode on ARM.

 examples/l3fwd/l3fwd.h|  4 ++-
 examples/l3fwd/l3fwd_em.c | 72 ---
 examples/l3fwd/l3fwd_em_hlm_sse.h | 32 -
 examples/l3fwd/main.c |  2 +-
 4 files changed, 64 insertions(+), 46 deletions(-)

-- 
1.9.1

[dpdk-dev] Odp.: [PATCH v3] examples/l3fwd: em path performance fix

[Czekaj, Maciej]

Od: Kulasek, TomaszX 
Wys?ane: 15 marca 2016 17:06
Do: Thomas Monjalon; Czekaj, Maciej
DW: dev at dpdk.org
Temat: RE: [dpdk-dev] [PATCH v3] examples/l3fwd: em path performance fix

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, March 15, 2016 15:50
> To: Kulasek, TomaszX ; Maciej Czekaj
> 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] examples/l3fwd: em path performance fix
>
> 2016-03-15 14:31, Kulasek, TomaszX:
> > From: Kulasek, TomaszX
> > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > > There is an error:
> > > > examples/l3fwd/l3fwd_em_hlm_sse.h:72:38: error:
> > > > incompatible type for argument 2 of ?_mm_and_si128?
> > >
> > > It's caused by
> > >
> > > commit 64d3955de1de4d7879a0930a6d2f501369d3445a
> > > Author: Maciej Czekaj 
> > > Date:   Thu Mar 10 17:06:22 2016 +0100
> > >
> > > examples/l3fwd: fix ARM build
> > >
> > > Enable NEON support in exact match mode.
> > > l3fwd example did not compile on ARM due to SSE2 instrincics used
> > > in generic part.
> > > Some instrinsins were used to initialize data structures and
> > > those were
> > > replaced by ordinary structure initalization.
> > > All SSE2 intrinsics used in forwarding, i.e. masking the IP/TCP
> header
> > > are moved to single inline function and made arch-specific.
> > >
> > > Signed-off-by: Maciej Czekaj 
> > >
> > > Which doesn't include rework of l3fwd_em_hlm_sse.h file.
> > >
> > > When you compile it now with global "#define HASH_MULTI_LOOKUP 1"
> > > and alternative classification is used, and compilation will also fail
> now.
> > >
> > > I need a little bit more time to investigate it, because I'm not an
> > > expert in ARM. It will be nice if Maciej will help me in that.
> > >
> > > Tomasz
> >
> > Will be that ok for you to disable this path for arm?
>
> Please, what do you mean?
> Maciej, have you looked at this issue?

This fix uses platform specific part of code which wasn't reworked in previous 
patch for ARM. It causes compilation error.
What I mean, is to leave current classification path for ARM and turn on 
alternative only for Intel platform.

Like that:

60 +#if defined(NO_HASH_MULTI_LOOKUP) || defined(__ARM_NEON)
61  #include "l3fwd_em_sse.h"
62  #else
63  #include "l3fwd_em_hlm_sse.h"

Thanks guys for pointing this out. The issue is that after my patch mask0, 
mask1 and mask2 are now defined as:

static rte_xmm_t mask0;
static rte_xmm_t mask1;
static rte_xmm_t mask2;

rte_xmm_t is a union with xmm_t field inside.

Apparently, I overlooked the HASH_MULTI_LOOKUP define

I can provide a quick fix for that, I need to rename all maskN references to 
maskN.x, to point out to xmm_t variable. E.g. the following diff is fixing the 
compilation.

diff --git a/examples/l3fwd/l3fwd_em_hlm_sse.h 
b/examples/l3fwd/l3fwd_em_hlm_sse.h
index d3388da..eb23163 100644
--- a/examples/l3fwd/l3fwd_em_hlm_sse.h
+++ b/examples/l3fwd/l3fwd_em_hlm_sse.h
@@ -77,14 +77,14 @@ em_get_dst_port_ipv4x8(struct lcore_conf *qconf, struct 
rte_mbuf *m[8],
sizeof(struct ether_hdr) +
offsetof(struct ipv4_hdr, time_to_live)));

-   key[0].xmm = _mm_and_si128(data[0], mask0);
-   key[1].xmm = _mm_and_si128(data[1], mask0);
-   key[2].xmm = _mm_and_si128(data[2], mask0);
-   key[3].xmm = _mm_and_si128(data[3], mask0);
-   key[4].xmm = _mm_and_si128(data[4], mask0);
-   key[5].xmm = _mm_and_si128(data[5], mask0);
-   key[6].xmm = _mm_and_si128(data[6], mask0);
-   key[7].xmm = _mm_and_si128(data[7], mask0);
+   key[0].xmm = _mm_and_si128(data[0], mask0.x);
+   key[1].xmm = _mm_and_si128(data[1], mask0.x);
+   key[2].xmm = _mm_and_si128(data[2], mask0.x);
+   key[3].xmm = _mm_and_si128(data[3], mask0.x);
+   key[4].xmm = _mm_and_si128(data[4], mask0.x);
+   key[5].xmm = _mm_and_si128(data[5], mask0.x);
+   key[6].xmm = _mm_and_si128(data[6], mask0.x);
+   key[7].xmm = _mm_and_si128(data[7], mask0.x);

const void *key_array[8] = {[0], [1], [2], [3],
[4], [5], [6], [7]};
@@ -175,14 +175,14 @@ em_get_dst_port_ipv6x8(struct lcore_conf *qconf, struct 
rte_mbuf *m[8],
int32_t ret[8];
union ipv6_5tuple_host key[8];

-   get_ipv6_5tuple(m[0], mask1, mask2, [0]);
-   get_ipv6_5tuple(m[1], mask1, mask2, [1]);
-   get_ipv6_5tuple(m[2], mask1, mask2, [2]);
-   get_ipv6_5tuple(m[3], mask1, mask2, [3]);
-   get_ipv6_5tuple(m[4], mask1, mask2, [4]);
-   get_ipv6_5tuple(m[5], mask1, mask2, [5]);
-   get_ipv6_5tuple(m[6], mask1, mask2, [6]);
-   get_ipv6_5tuple(m[7], mask1, mask2, [7]);
+   get_ipv6_5tuple(m[0], mask1.x, mask2.x, [0]);
+   get_ipv6_5tuple(m[1], mask1.x, mask2.x, [1]);
+   get_ipv6_5tuple(m[2], mask1.x, mask2.x, [2]);
+   get_ipv6_5tuple(m[3], 

[dpdk-dev] [PATCH] ring: assert on zero objects dequeue/enqueue

[Lazaros Koromilas]

Issuing a zero objects dequeue with a single consumer has no effect.
Doing so with multiple consumers, can get more than one thread to succeed
the compare-and-set operation and observe starvation or even deadlock in
the while loop that checks for preceding dequeues.  The problematic piece
of code when n = 0:

cons_next = cons_head + n;
success = rte_atomic32_cmpset(>cons.head, cons_head, cons_next);

The same is possible on the enqueue path.

Signed-off-by: Lazaros Koromilas 
---
 lib/librte_ring/rte_ring.h | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 943c97c..2bf9ce3 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -100,6 +100,7 @@ extern "C" {
 #include 
 #include 
 #include 
+#include 

 #define RTE_TAILQ_RING_NAME "RTE_RING"

@@ -211,6 +212,19 @@ struct rte_ring {
 #endif

 /**
+ * @internal Assert macro.
+ * @param exp
+ *   The expression to evaluate.
+ */
+#define RTE_RING_ASSERT(exp) do { \
+   if (!(exp)) { \
+   rte_panic("line%d\t"  \
+ "assert \"" #exp "\" failed\n", \
+ __LINE__);  \
+   } \
+   } while (0)
+
+/**
  * Calculate the memory size needed for a ring
  *
  * This function returns the number of bytes needed for a ring, given
@@ -406,6 +420,7 @@ void rte_ring_dump(FILE *f, const struct rte_ring *r);
  *   A pointer to a table of void * pointers (objects).
  * @param n
  *   The number of objects to add in the ring from the obj_table.
+ *   Must be greater than zero.
  * @param behavior
  *   RTE_RING_QUEUE_FIXED:Enqueue a fixed number of items from a ring
  *   RTE_RING_QUEUE_VARIABLE: Enqueue as many items a possible from ring
@@ -431,6 +446,8 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const 
*obj_table,
uint32_t mask = r->prod.mask;
int ret;

+   RTE_RING_ASSERT(n > 0);
+
/* move prod.head atomically */
do {
/* Reset n to the initial burst count */
@@ -510,6 +527,7 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const 
*obj_table,
  *   A pointer to a table of void * pointers (objects).
  * @param n
  *   The number of objects to add in the ring from the obj_table.
+ *   Must be greater than zero.
  * @param behavior
  *   RTE_RING_QUEUE_FIXED:Enqueue a fixed number of items from a ring
  *   RTE_RING_QUEUE_VARIABLE: Enqueue as many items a possible from ring
@@ -533,6 +551,8 @@ __rte_ring_sp_do_enqueue(struct rte_ring *r, void * const 
*obj_table,
uint32_t mask = r->prod.mask;
int ret;

+   RTE_RING_ASSERT(n > 0);
+
prod_head = r->prod.head;
cons_tail = r->cons.tail;
/* The subtraction is done between two unsigned 32bits value
@@ -594,6 +614,7 @@ __rte_ring_sp_do_enqueue(struct rte_ring *r, void * const 
*obj_table,
  *   A pointer to a table of void * pointers (objects) that will be filled.
  * @param n
  *   The number of objects to dequeue from the ring to the obj_table.
+ *   Must be greater than zero.
  * @param behavior
  *   RTE_RING_QUEUE_FIXED:Dequeue a fixed number of items from a ring
  *   RTE_RING_QUEUE_VARIABLE: Dequeue as many items a possible from ring
@@ -618,6 +639,8 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void 
**obj_table,
unsigned i, rep = 0;
uint32_t mask = r->prod.mask;

+   RTE_RING_ASSERT(n > 0);
+
/* move cons.head atomically */
do {
/* Restore n as it may change every loop */
@@ -689,6 +712,7 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void 
**obj_table,
  *   A pointer to a table of void * pointers (objects) that will be filled.
  * @param n
  *   The number of objects to dequeue from the ring to the obj_table.
+ *   Must be greater than zero.
  * @param behavior
  *   RTE_RING_QUEUE_FIXED:Dequeue a fixed number of items from a ring
  *   RTE_RING_QUEUE_VARIABLE: Dequeue as many items a possible from ring
@@ -710,6 +734,8 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void 
**obj_table,
unsigned i;
uint32_t mask = r->prod.mask;

+   RTE_RING_ASSERT(n > 0);
+
cons_head = r->cons.head;
prod_tail = r->prod.tail;
/* The subtraction is done between two unsigned 32bits value
-- 
1.9.1

[dpdk-dev] [PATCH v12 2/2] vhost: Add VHOST PMD

[Tetsuya Mukawa]

The patch introduces a new PMD. This PMD is implemented as thin wrapper
of librte_vhost. It means librte_vhost is also needed to compile the PMD.
The vhost messages will be handled only when a port is started. So start
a port first, then invoke QEMU.

The PMD has 2 parameters.
 - iface:  The parameter is used to specify a path to connect to a
   virtio-net device.
 - queues: The parameter is used to specify the number of the queues
   virtio-net device has.
   (Default: 1)

Here is an example.
$ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i

To connect above testpmd, here is qemu command example.

$ qemu-system-x86_64 \

-chardev socket,id=chr0,path=/tmp/sock0 \
-netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \
-device virtio-net-pci,netdev=net0,mq=on

Signed-off-by: Tetsuya Mukawa 
Acked-by: Ferruh Yigit 
Acked-by: Yuanhan Liu 
Acked-by: Rich Lane 
Tested-by: Rich Lane 
---
 MAINTAINERS |   5 +
 config/common_base  |   6 +
 config/common_linuxapp  |   1 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/nics/vhost.rst   | 110 
 doc/guides/rel_notes/release_16_04.rst  |   5 +
 drivers/net/Makefile|   4 +
 drivers/net/vhost/Makefile  |  62 ++
 drivers/net/vhost/rte_eth_vhost.c   | 916 
 drivers/net/vhost/rte_eth_vhost.h   | 109 
 drivers/net/vhost/rte_pmd_vhost_version.map |  10 +
 mk/rte.app.mk   |   6 +
 12 files changed, 1235 insertions(+)
 create mode 100644 doc/guides/nics/vhost.rst
 create mode 100644 drivers/net/vhost/Makefile
 create mode 100644 drivers/net/vhost/rte_eth_vhost.c
 create mode 100644 drivers/net/vhost/rte_eth_vhost.h
 create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index f10b26a..8ec1972 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -351,6 +351,11 @@ Null PMD
 M: Tetsuya Mukawa 
 F: drivers/net/null/

+Vhost PMD
+M: Tetsuya Mukawa 
+M: Yuanhan Liu 
+F: drivers/net/vhost/
+
 Intel AES-NI GCM PMD
 M: Declan Doherty 
 F: drivers/crypto/aesni_gcm/
diff --git a/config/common_base b/config/common_base
index 52bd34f..3d753e1 100644
--- a/config/common_base
+++ b/config/common_base
@@ -505,6 +505,12 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n
 CONFIG_RTE_LIBRTE_VHOST_DEBUG=n

 #
+# Compile vhost PMD
+# To compile, CONFIG_RTE_LIBRTE_VHOST should be enabled.
+#
+CONFIG_RTE_LIBRTE_PMD_VHOST=n
+
+#
 #Compile Xen domain0 support
 #
 CONFIG_RTE_LIBRTE_XEN_DOM0=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index ffbe260..7e698e2 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -40,5 +40,6 @@ CONFIG_RTE_EAL_VFIO=y
 CONFIG_RTE_KNI_KMOD=y
 CONFIG_RTE_LIBRTE_KNI=y
 CONFIG_RTE_LIBRTE_VHOST=y
+CONFIG_RTE_LIBRTE_PMD_VHOST=y
 CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
 CONFIG_RTE_LIBRTE_POWER=y
diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst
index 0b353a8..d53b0c7 100644
--- a/doc/guides/nics/index.rst
+++ b/doc/guides/nics/index.rst
@@ -49,6 +49,7 @@ Network Interface Controller Drivers
 nfp
 szedata2
 virtio
+vhost
 vmxnet3
 pcap_ring

diff --git a/doc/guides/nics/vhost.rst b/doc/guides/nics/vhost.rst
new file mode 100644
index 000..50e8a3a
--- /dev/null
+++ b/doc/guides/nics/vhost.rst
@@ -0,0 +1,110 @@
+..  BSD LICENSE
+Copyright(c) 2016 IGEL Co., Ltd.. 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 IGEL Co., Ltd. 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
+

[dpdk-dev] [PATCH v12 1/2] ethdev: Add a new event type to notify a queue state changed event

[Tetsuya Mukawa]

This patch adds a below event type.
 - RTE_ETH_EVENT_QUEUE_STATE_CHANGE
This event is used for notifying a queue state changed event.

Signed-off-by: Tetsuya Mukawa 
Acked-by: Ferruh Yigit 
Acked-by: Yuanhan Liu 
Acked-by: Rich Lane 
Tested-by: Rich Lane 
---
 lib/librte_ether/rte_ethdev.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index d867976..0680a71 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2915,6 +2915,8 @@ rte_eth_tx_buffer_count_callback(struct rte_mbuf **pkts, 
uint16_t unsent,
 enum rte_eth_event_type {
RTE_ETH_EVENT_UNKNOWN,  /**< unknown event type */
RTE_ETH_EVENT_INTR_LSC, /**< lsc interrupt event */
+   RTE_ETH_EVENT_QUEUE_STATE_CHANGE,
+   /**< queue state changed interrupt */
RTE_ETH_EVENT_MAX   /**< max value of this enum */
 };

-- 
2.1.4

[dpdk-dev] [PATCH v12 0/2] Add VHOST PMD

[Tetsuya Mukawa]

The patch introduces a new PMD. This PMD is implemented as thin wrapper
of librte_vhost.

PATCH v12 changes:
 - Rebase on latest master.
 - Add a missing documentation.

PATCH v11 changes:
 - Rebase on latest master.
 - Fix MAINTAINERS file.
 - Fix Acked-by and Tested-by signatures of commit log.

PATCH v10 changes:
 - Rebase on latest master.
 - Fix DPDK version number(2.3 to 16.04)
 - Set port id to mbuf while receiving packets.

PATCH v9 changes:
 - Fix a null pointer access issue implemented in v8 patch.

PATCH v8 changes:
 - Manage ether devices list instead of internal structures list.
 - Remove needless NULL checking.
 - Replace "pthread_exit" to "return NULL".
 - Replace rte_panic to RTE_LOG, also add error handling.
 - Remove duplicated lines.
 - Remove needless casting.
 - Follow coding style.
 - Remove needless parenthesis.

PATCH v7 changes:
 - Remove needless parenthesis.
 - Add release note.
 - Remove needless line wraps.
 - Add null pointer check in vring_state_changed().
 - Free queue memory in eth_queue_release().
 - Fix wrong variable name.
 - Fix error handling code of eth_dev_vhost_create() and
   rte_pmd_vhost_devuninit().
 - Remove needless null checking from rte_pmd_vhost_devinit/devuninit().
 - Use port id to create mac address.
 - Add doxygen style comments in "rte_eth_vhost.h".
 - Fix wrong comment in "mk/rte.app.mk".

PATCH v6 changes:
 - Remove rte_vhost_driver_pmd_callback_registe().
 - Support link status interrupt.
 - Support queue state changed interrupt.
 - Add rte_eth_vhost_get_queue_event().
 - Support numa node detection when new device is connected.

PATCH v5 changes:
 - Rebase on latest master.
 - Fix RX/TX routine to count RX/TX bytes.
 - Fix RX/TX routine not to count as error packets if enqueue/dequeue
   cannot send all packets.
 - Fix if-condition checking for multiqueues.
 - Add "static" to pthread variable.
 - Fix format.
 - Change default behavior not to receive queueing event from driver.
 - Split the patch to separate rte_eth_vhost_portid2vdev().

PATCH v4 changes:
 - Rebase on latest DPDK tree.
 - Fix cording style.
 - Fix code not to invoke multiple messaging handling threads.
 - Fix code to handle vdev parameters correctly.
 - Remove needless cast.
 - Remove needless if-condition before rt_free().

PATCH v3 changes:
 - Rebase on latest matser
 - Specify correct queue_id in RX/TX function.

PATCH v2 changes:
 - Remove a below patch that fixes vhost library.
   The patch was applied as a separate patch.
   - vhost: fix crash with multiqueue enabled
 - Fix typos.
   (Thanks to Thomas, Monjalon)
 - Rebase on latest tree with above bernard's patches.

PATCH v1 changes:
 - Support vhost multiple queues.
 - Rebase on "remove pci driver from vdevs".
 - Optimize RX/TX functions.
 - Fix resource leaks.
 - Fix compile issue.
 - Add patch to fix vhost library.

RFC PATCH v3 changes:
 - Optimize performance.
   In RX/TX functions, change code to access only per core data.
 - Add below API to allow user to use vhost library APIs for a port managed
   by vhost PMD. There are a few limitations. See "rte_eth_vhost.h".
- rte_eth_vhost_portid2vdev()
   To support this functionality, vhost library is also changed.
   Anyway, if users doesn't use vhost PMD, can fully use vhost library APIs.
 - Add code to support vhost multiple queues.
   Actually, multiple queues functionality is not enabled so far.

RFC PATCH v2 changes:
 - Fix issues reported by checkpatch.pl
   (Thanks to Stephen Hemminger)


Tetsuya Mukawa (2):
  ethdev: Add a new event type to notify a queue state changed event
  vhost: Add VHOST PMD

 MAINTAINERS |   5 +
 config/common_base  |   6 +
 config/common_linuxapp  |   1 +
 doc/guides/nics/index.rst   |   1 +
 doc/guides/nics/vhost.rst   | 110 
 doc/guides/rel_notes/release_16_04.rst  |   5 +
 drivers/net/Makefile|   4 +
 drivers/net/vhost/Makefile  |  62 ++
 drivers/net/vhost/rte_eth_vhost.c   | 916 
 drivers/net/vhost/rte_eth_vhost.h   | 109 
 drivers/net/vhost/rte_pmd_vhost_version.map |  10 +
 lib/librte_ether/rte_ethdev.h   |   2 +
 mk/rte.app.mk   |   6 +
 13 files changed, 1237 insertions(+)
 create mode 100644 doc/guides/nics/vhost.rst
 create mode 100644 drivers/net/vhost/Makefile
 create mode 100644 drivers/net/vhost/rte_eth_vhost.c
 create mode 100644 drivers/net/vhost/rte_eth_vhost.h
 create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map

-- 
2.1.4

[dpdk-dev] [PATCH v3] examples/l3fwd: em path performance fix

[Kulasek, TomaszX]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, March 15, 2016 15:50
> To: Kulasek, TomaszX ; Maciej Czekaj
> 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] examples/l3fwd: em path performance fix
> 
> 2016-03-15 14:31, Kulasek, TomaszX:
> > From: Kulasek, TomaszX
> > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > > There is an error:
> > > > examples/l3fwd/l3fwd_em_hlm_sse.h:72:38: error:
> > > > incompatible type for argument 2 of ?_mm_and_si128?
> > >
> > > It's caused by
> > >
> > > commit 64d3955de1de4d7879a0930a6d2f501369d3445a
> > > Author: Maciej Czekaj 
> > > Date:   Thu Mar 10 17:06:22 2016 +0100
> > >
> > > examples/l3fwd: fix ARM build
> > >
> > > Enable NEON support in exact match mode.
> > > l3fwd example did not compile on ARM due to SSE2 instrincics used
> > > in generic part.
> > > Some instrinsins were used to initialize data structures and
> > > those were
> > > replaced by ordinary structure initalization.
> > > All SSE2 intrinsics used in forwarding, i.e. masking the IP/TCP
> header
> > > are moved to single inline function and made arch-specific.
> > >
> > > Signed-off-by: Maciej Czekaj 
> > >
> > > Which doesn't include rework of l3fwd_em_hlm_sse.h file.
> > >
> > > When you compile it now with global "#define HASH_MULTI_LOOKUP 1"
> > > and alternative classification is used, and compilation will also fail
> now.
> > >
> > > I need a little bit more time to investigate it, because I'm not an
> > > expert in ARM. It will be nice if Maciej will help me in that.
> > >
> > > Tomasz
> >
> > Will be that ok for you to disable this path for arm?
> 
> Please, what do you mean?
> Maciej, have you looked at this issue?

This fix uses platform specific part of code which wasn't reworked in previous 
patch for ARM. It causes compilation error.
What I mean, is to leave current classification path for ARM and turn on 
alternative only for Intel platform.

Like that:

60 +#if defined(NO_HASH_MULTI_LOOKUP) || defined(__ARM_NEON)
61  #include "l3fwd_em_sse.h"
62  #else
63  #include "l3fwd_em_hlm_sse.h"

[dpdk-dev] [PATCH v3] examples/l3fwd: em path performance fix

[Thomas Monjalon]

2016-03-15 14:31, Kulasek, TomaszX:
> From: Kulasek, TomaszX
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > There is an error:
> > > examples/l3fwd/l3fwd_em_hlm_sse.h:72:38: error:
> > >   incompatible type for argument 2 of ?_mm_and_si128?
> > 
> > It's caused by
> > 
> > commit 64d3955de1de4d7879a0930a6d2f501369d3445a
> > Author: Maciej Czekaj 
> > Date:   Thu Mar 10 17:06:22 2016 +0100
> > 
> > examples/l3fwd: fix ARM build
> > 
> > Enable NEON support in exact match mode.
> > l3fwd example did not compile on ARM due to SSE2 instrincics used
> > in generic part.
> > Some instrinsins were used to initialize data structures and those
> > were
> > replaced by ordinary structure initalization.
> > All SSE2 intrinsics used in forwarding, i.e. masking the IP/TCP header
> > are moved to single inline function and made arch-specific.
> > 
> > Signed-off-by: Maciej Czekaj 
> > 
> > Which doesn't include rework of l3fwd_em_hlm_sse.h file.
> > 
> > When you compile it now with global "#define HASH_MULTI_LOOKUP 1" and
> > alternative classification is used, and compilation will also fail now.
> > 
> > I need a little bit more time to investigate it, because I'm not an expert
> > in ARM. It will be nice if Maciej will help me in that.
> > 
> > Tomasz
> 
> Will be that ok for you to disable this path for arm?

Please, what do you mean?
Maciej, have you looked at this issue?

[dpdk-dev] [PATCH v7 4/4] ena: DPDK polling-mode driver for Amazon Elastic Network Adapters (ENA)

[Jan Medala]

This is a PMD for the Amazon ethernet ENA family.
The driver operates variety of ENA adapters through feature negotiation
with the adapter and upgradable commands set.
ENA driver handles PCI Physical and Virtual ENA functions.

Signed-off-by: Evgeny Schemeilin 
Signed-off-by: Jan Medala 
Signed-off-by: Jakub Palider 
---
 config/common_base  |   11 +
 drivers/net/Makefile|1 +
 drivers/net/ena/Makefile|   61 ++
 drivers/net/ena/ena_ethdev.c| 1445 +++
 drivers/net/ena/ena_ethdev.h|  160 
 drivers/net/ena/ena_logs.h  |   74 ++
 drivers/net/ena/ena_platform.h  |   59 ++
 drivers/net/ena/rte_pmd_ena_version.map |4 +
 mk/rte.app.mk   |1 +
 9 files changed, 1816 insertions(+)
 create mode 100644 drivers/net/ena/Makefile
 create mode 100644 drivers/net/ena/ena_ethdev.c
 create mode 100644 drivers/net/ena/ena_ethdev.h
 create mode 100644 drivers/net/ena/ena_logs.h
 create mode 100644 drivers/net/ena/ena_platform.h
 create mode 100644 drivers/net/ena/rte_pmd_ena_version.map

diff --git a/config/common_base b/config/common_base
index 52bd34f..472a9e9 100644
--- a/config/common_base
+++ b/config/common_base
@@ -135,6 +135,17 @@ CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
 CONFIG_RTE_NIC_BYPASS=n

 #
+# Compile burst-oriented Amazon ENA PMD driver
+#
+CONFIG_RTE_LIBRTE_ENA_PMD=y
+CONFIG_RTE_LIBRTE_ENA_DEBUG_INIT=y
+CONFIG_RTE_LIBRTE_ENA_DEBUG_RX=n
+CONFIG_RTE_LIBRTE_ENA_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_ENA_DEBUG_TX_FREE=n
+CONFIG_RTE_LIBRTE_ENA_DEBUG_DRIVER=n
+CONFIG_RTE_LIBRTE_ENA_COM_DEBUG=n
+
+#
 # Compile burst-oriented IGB & EM PMD drivers
 #
 CONFIG_RTE_LIBRTE_EM_PMD=y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 0c3393f..612e85e 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -36,6 +36,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += bonding
 DIRS-$(CONFIG_RTE_LIBRTE_CXGBE_PMD) += cxgbe
 DIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += e1000
+DIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena
 DIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic
 DIRS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += fm10k
 DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e
diff --git a/drivers/net/ena/Makefile b/drivers/net/ena/Makefile
new file mode 100644
index 000..ac2b55d
--- /dev/null
+++ b/drivers/net/ena/Makefile
@@ -0,0 +1,61 @@
+#
+# BSD LICENSE
+#
+# Copyright (c) 2015-2016 Amazon.com, Inc. or its affiliates.
+# 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 copyright holder nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_ena.a
+CFLAGS += $(WERROR_FLAGS) -O2
+INCLUDES :=-I$(SRCDIR) -I$(SRCDIR)/base/ena_defs -I$(SRCDIR)/base
+
+EXPORT_MAP := rte_pmd_ena_version.map
+LIBABIVER := 1
+
+VPATH += $(SRCDIR)/base
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena_ethdev.c
+SRCS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena_com.c
+SRCS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena_eth_com.c
+
+# this lib depends upon:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += lib/librte_eal lib/librte_ether
+DEPDIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += lib/librte_mempool lib/librte_mbuf
+DEPDIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += lib/librte_net lib/librte_malloc
+
+CFLAGS += $(INCLUDES)
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
new file mode 100644
index 000..325c513
--- /dev/null
+++ b/drivers/net/ena/ena_ethdev.c
@@ -0,0 +1,1445 @@

[dpdk-dev] [PATCH v7 3/4] ena: Amazon ENA communication layer for DPDK platform

[Jan Medala]

Implementation of platform specific code for ENA communication layer.

Signed-off-by: Evgeny Schemeilin 
Signed-off-by: Jan Medala 
Signed-off-by: Jakub Palider 
---
 drivers/net/ena/base/ena_plat_dpdk.h | 217 +++
 1 file changed, 217 insertions(+)
 create mode 100644 drivers/net/ena/base/ena_plat_dpdk.h

diff --git a/drivers/net/ena/base/ena_plat_dpdk.h 
b/drivers/net/ena/base/ena_plat_dpdk.h
new file mode 100644
index 000..3ddc5c2
--- /dev/null
+++ b/drivers/net/ena/base/ena_plat_dpdk.h
@@ -0,0 +1,217 @@
+/*-
+* BSD LICENSE
+*
+* Copyright (c) 2015-2016 Amazon.com, Inc. or its affiliates.
+* 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 copyright holder 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 DPDK_ENA_COM_ENA_PLAT_DPDK_H_
+#define DPDK_ENA_COM_ENA_PLAT_DPDK_H_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+typedef uint64_t u64;
+typedef uint32_t u32;
+typedef uint16_t u16;
+typedef uint8_t u8;
+
+typedef uint64_t dma_addr_t;
+
+#define ena_atomic32_t rte_atomic32_t
+#define ena_mem_handle_t void *
+
+#define SZ_256 (256)
+#define SZ_4K (4096)
+
+#define ENA_COM_OK 0
+#define ENA_COM_NO_MEM -ENOMEM
+#define ENA_COM_INVAL  -EINVAL
+#define ENA_COM_NO_SPACE   -ENOSPC
+#define ENA_COM_NO_DEVICE  -ENODEV
+#define ENA_COM_PERMISSION -EPERM
+#define ENA_COM_TIMER_EXPIRED  -ETIME
+#define ENA_COM_FAULT  -EFAULT
+
+#define cacheline_aligned __rte_cache_aligned
+
+#define ENA_ABORT() abort()
+
+#define ENA_MSLEEP(x) rte_delay_ms(x)
+#define ENA_UDELAY(x) rte_delay_us(x)
+
+#define memcpy_toio memcpy
+#define wmb rte_wmb
+#define rmb rte_wmb
+#define mb rte_mb
+#define __iomem
+
+#define US_PER_S 100
+#define ENA_GET_SYSTEM_USECS() \
+   (rte_get_timer_cycles() * US_PER_S / rte_get_timer_hz())
+
+#define ENA_ASSERT(cond, format, arg...)   \
+   do {\
+   if (unlikely(!(cond))) {\
+   printf("Assertion failed on %s:%s:%d: " format, \
+   __FILE__, __func__, __LINE__, ##arg);   \
+   rte_exit(EXIT_FAILURE, "ASSERTION FAILED\n");   \
+   }   \
+   } while (0)
+
+#define ENA_MAX32(x, y) RTE_MAX((x), (y))
+#define ENA_MAX16(x, y) RTE_MAX((x), (y))
+#define ENA_MAX8(x, y) RTE_MAX((x), (y))
+#define ENA_MIN32(x, y) RTE_MIN((x), (y))
+#define ENA_MIN16(x, y) RTE_MIN((x), (y))
+#define ENA_MIN8(x, y) RTE_MIN((x), (y))
+
+#define U64_C(x) x ## ULL
+#define BIT(nr) (1UL << (nr))
+#define BITS_PER_LONG  (__SIZEOF_LONG__ * 8)
+#define GENMASK(h, l)  (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
+#define GENMASK_ULL(h, l) (((U64_C(1) << ((h) - (l) + 1)) - 1) << (l))
+
+#ifdef RTE_LIBRTE_ENA_COM_DEBUG
+#define ena_trc_dbg(format, arg...)\
+   RTE_LOG(DEBUG, PMD, "[ENA_COM: %s] " format, __func__, ##arg)
+#define ena_trc_info(format, arg...)   \
+   RTE_LOG(INFO, PMD, "[ENA_COM: %s] " format, __func__, ##arg)
+#define ena_trc_warn(format, arg...)   \
+   RTE_LOG(ERR, PMD, "[ENA_COM: %s] " format, __func__, ##arg)
+#define ena_trc_err(format, arg...)\
+   RTE_LOG(ERR, PMD, 

[dpdk-dev] [PATCH v7 2/4] ena: Amazon ENA communication layer

[Jan Medala]

Low level common abstraction for ENA device communication.

Signed-off-by: Netanel Belgazal 
Signed-off-by: Jan Medala 
Signed-off-by: Jakub Palider 
---
 drivers/net/ena/base/ena_com.c  | 2809 +++
 drivers/net/ena/base/ena_com.h  | 1052 +
 drivers/net/ena/base/ena_defs/ena_admin_defs.h  | 1979 
 drivers/net/ena/base/ena_defs/ena_common_defs.h |   54 +
 drivers/net/ena/base/ena_defs/ena_eth_io_defs.h | 1488 
 drivers/net/ena/base/ena_defs/ena_gen_info.h|   35 +
 drivers/net/ena/base/ena_defs/ena_includes.h|   39 +
 drivers/net/ena/base/ena_defs/ena_regs_defs.h   |  135 ++
 drivers/net/ena/base/ena_eth_com.c  |  508 
 drivers/net/ena/base/ena_eth_com.h  |  153 ++
 drivers/net/ena/base/ena_plat.h |   51 +
 11 files changed, 8303 insertions(+)
 create mode 100644 drivers/net/ena/base/ena_com.c
 create mode 100644 drivers/net/ena/base/ena_com.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_admin_defs.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_common_defs.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_eth_io_defs.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_gen_info.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_includes.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_regs_defs.h
 create mode 100644 drivers/net/ena/base/ena_eth_com.c
 create mode 100644 drivers/net/ena/base/ena_eth_com.h
 create mode 100644 drivers/net/ena/base/ena_plat.h

diff --git a/drivers/net/ena/base/ena_com.c b/drivers/net/ena/base/ena_com.c
new file mode 100644
index 000..c7355eb
--- /dev/null
+++ b/drivers/net/ena/base/ena_com.c
@@ -0,0 +1,2809 @@
+/*-
+* BSD LICENSE
+*
+* Copyright (c) 2015-2016 Amazon.com, Inc. or its affiliates.
+* 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 copyright holder nor the names of its
+* contributors may be used to endorse or promote products derived
+* from this software without specific prior written permission.
+*
+* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#include "ena_com.h"
+
+/*/
+/*/
+
+/* Timeout in micro-sec */
+#define ADMIN_CMD_TIMEOUT_US (100)
+
+#define ENA_ASYNC_QUEUE_DEPTH 4
+#define ENA_ADMIN_QUEUE_DEPTH 32
+
+#define ENA_EXTENDED_STAT_GET_FUNCT(_funct_queue) (_funct_queue & 0x)
+#define ENA_EXTENDED_STAT_GET_QUEUE(_funct_queue) (_funct_queue >> 16)
+
+#define MIN_ENA_VER (((ENA_COMMON_SPEC_VERSION_MAJOR) << \
+   ENA_REGS_VERSION_MAJOR_VERSION_SHIFT) \
+   | (ENA_COMMON_SPEC_VERSION_MINOR))
+
+#define ENA_CTRL_MAJOR 0
+#define ENA_CTRL_MINOR 0
+#define ENA_CTRL_SUB_MINOR 1
+
+#define MIN_ENA_CTRL_VER \
+   (((ENA_CTRL_MAJOR) << \
+   (ENA_REGS_CONTROLLER_VERSION_MAJOR_VERSION_SHIFT)) | \
+   ((ENA_CTRL_MINOR) << \
+   (ENA_REGS_CONTROLLER_VERSION_MINOR_VERSION_SHIFT)) | \
+   (ENA_CTRL_SUB_MINOR))
+
+#define ENA_DMA_ADDR_TO_UINT32_LOW(x)  ((u32)((u64)(x)))
+#define ENA_DMA_ADDR_TO_UINT32_HIGH(x) ((u32)(((u64)(x)) >> 32))
+
+#define ENA_MMIO_READ_TIMEOUT 0x
+
+static int ena_alloc_cnt;
+
+/*/
+/*/
+/*/
+
+enum ena_cmd_status {
+   ENA_CMD_SUBMITTED,
+   ENA_CMD_COMPLETED,
+   /* Abort - canceled by the driver */
+   ENA_CMD_ABORTED,
+};
+
+struct ena_comp_ctx {
+   ena_wait_event_t 

[dpdk-dev] [PATCH v7 1/4] ena: Amazon ENA documentation

[Jan Medala]

Signed-off-by: Alexander Matushevsky 
Signed-off-by: Jan Medala 
Signed-off-by: Jakub Palider 
---
 MAINTAINERS  |   8 ++
 doc/guides/nics/ena.rst  | 251 +++
 doc/guides/nics/index.rst|   1 +
 doc/guides/nics/overview.rst | 116 ++--
 4 files changed, 318 insertions(+), 58 deletions(-)
 create mode 100644 doc/guides/nics/ena.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index f10b26a..d37aad6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -260,6 +260,14 @@ Linux AF_PACKET
 M: John W. Linville 
 F: drivers/net/af_packet/

+Amazon ena
+M: Jan Medala 
+M: Jakub Palider 
+M: Netanel Belgazal 
+M: Evgeny Schemeilin 
+F: drivers/net/ena/
+F: doc/guides/nics/ena.rst
+
 Chelsio cxgbe
 M: Rahul Lakkireddy 
 F: drivers/net/cxgbe/
diff --git a/doc/guides/nics/ena.rst b/doc/guides/nics/ena.rst
new file mode 100644
index 000..9f93848
--- /dev/null
+++ b/doc/guides/nics/ena.rst
@@ -0,0 +1,251 @@
+.. BSD LICENSE
+
+Copyright (c) 2015-2016 Amazon.com, Inc. or its affiliates.
+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 Amazon.com, Inc. nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+ENA Poll Mode Driver
+
+
+The ENA PMD is a DPDK poll-mode driver for the Amazon Elastic
+Network Adapter (ENA) family.
+
+Overview
+
+
+The ENA driver exposes a lightweight management interface with a
+minimal set of memory mapped registers and an extendable command set
+through an Admin Queue.
+
+The driver supports a wide range of ENA adapters, is link-speed
+independent (i.e., the same driver is used for 10GbE, 25GbE, 40GbE,
+etc.), and it negotiates and supports an extendable feature set.
+
+ENA adapters allow high speed and low overhead Ethernet traffic
+processing by providing a dedicated Tx/Rx queue pair per CPU core.
+
+The ENA driver supports industry standard TCP/IP offload features such
+as checksum offload and TCP transmit segmentation offload (TSO).
+
+Receive-side scaling (RSS) is supported for multi-core scaling.
+
+Some of the ENA devices support a working mode called Low-latency
+Queue (LLQ), which saves several more microseconds.
+
+Management Interface
+
+
+ENA management interface is exposed by means of:
+
+* Device Registers
+* Admin Queue (AQ) and Admin Completion Queue (ACQ)
+
+ENA device memory-mapped PCIe space for registers (MMIO registers)
+are accessed only during driver initialization and are not involved
+in further normal device operation.
+
+AQ is used for submitting management commands, and the
+results/responses are reported asynchronously through ACQ.
+
+ENA introduces a very small set of management commands with room for
+vendor-specific extensions. Most of the management operations are
+framed in a generic Get/Set feature command.
+
+The following admin queue commands are supported:
+
+* Create I/O submission queue
+* Create I/O completion queue
+* Destroy I/O submission queue
+* Destroy I/O completion queue
+* Get feature
+* Set feature
+* Get statistics
+
+Refer to ``ena_admin_defs.h`` for the list of supported Get/Set Feature
+properties.
+
+Data Path Interface
+---
+
+I/O operations are based on Tx and Rx Submission Queues (Tx SQ and Rx
+SQ correspondingly). Each SQ has a completion queue (CQ) associated
+with it.
+
+The SQs and CQs are implemented as descriptor rings in contiguous
+physical memory.
+
+Refer to ``ena_eth_io_defs.h`` for the detailed structure of the descriptor
+
+The driver supports multi-queue for both Tx and 

[dpdk-dev] [PATCH v7 0/4] DPDK polling-mode driver for Amazon Elastic Network Adapters (ENA)

[Jan Medala]

v3:
Additional features for Amazon ENA:
* Low Latenycy Queue (LLQ) for Tx
* RSS
v4:
* Improved doc
* Improved style according to checkpatch script
* Fixed build problems on: i686, clang, +shared, +debug
v5:
* Removed 'cvos' environment code from ena Makefile
* Driver symbol version fixed to DPDK_16.04
* Max MTU is read from device attributes
v6:
* Updated ENA communication layer
* Added check if DPDK queue size is supported by device
* Checkpatch results: 6 warns >80, 0 warns >90, no whitespace issues
* defined likely/unlikely (can compile with ARM toolchain)
* Updated doc/guides/nics/overview.rst w/ ENA
* Removed metioned #pragma for "-Wcast-qual"
v7:
* Resolved Thomas's comments:
  - included  instead of own definition of
  likely/unlikely
  - used RTE_MIN/RTE_MAX macros

Jan Medala (4):
  ena: Amazon ENA documentation
  ena: Amazon ENA communication layer
  ena: Amazon ENA communication layer for DPDK platform
  ena: DPDK polling-mode driver for Amazon Elastic Network Adapters
(ENA)

 MAINTAINERS |8 +
 config/common_base  |   11 +
 doc/guides/nics/ena.rst |  251 ++
 doc/guides/nics/index.rst   |1 +
 doc/guides/nics/overview.rst|  116 +-
 drivers/net/Makefile|1 +
 drivers/net/ena/Makefile|   61 +
 drivers/net/ena/base/ena_com.c  | 2809 +++
 drivers/net/ena/base/ena_com.h  | 1052 +
 drivers/net/ena/base/ena_defs/ena_admin_defs.h  | 1979 
 drivers/net/ena/base/ena_defs/ena_common_defs.h |   54 +
 drivers/net/ena/base/ena_defs/ena_eth_io_defs.h | 1488 
 drivers/net/ena/base/ena_defs/ena_gen_info.h|   35 +
 drivers/net/ena/base/ena_defs/ena_includes.h|   39 +
 drivers/net/ena/base/ena_defs/ena_regs_defs.h   |  135 ++
 drivers/net/ena/base/ena_eth_com.c  |  508 
 drivers/net/ena/base/ena_eth_com.h  |  153 ++
 drivers/net/ena/base/ena_plat.h |   51 +
 drivers/net/ena/base/ena_plat_dpdk.h|  217 ++
 drivers/net/ena/ena_ethdev.c| 1445 
 drivers/net/ena/ena_ethdev.h|  160 ++
 drivers/net/ena/ena_logs.h  |   74 +
 drivers/net/ena/ena_platform.h  |   59 +
 drivers/net/ena/rte_pmd_ena_version.map |4 +
 mk/rte.app.mk   |1 +
 25 files changed, 10654 insertions(+), 58 deletions(-)
 create mode 100644 doc/guides/nics/ena.rst
 create mode 100644 drivers/net/ena/Makefile
 create mode 100644 drivers/net/ena/base/ena_com.c
 create mode 100644 drivers/net/ena/base/ena_com.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_admin_defs.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_common_defs.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_eth_io_defs.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_gen_info.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_includes.h
 create mode 100644 drivers/net/ena/base/ena_defs/ena_regs_defs.h
 create mode 100644 drivers/net/ena/base/ena_eth_com.c
 create mode 100644 drivers/net/ena/base/ena_eth_com.h
 create mode 100644 drivers/net/ena/base/ena_plat.h
 create mode 100644 drivers/net/ena/base/ena_plat_dpdk.h
 create mode 100644 drivers/net/ena/ena_ethdev.c
 create mode 100644 drivers/net/ena/ena_ethdev.h
 create mode 100644 drivers/net/ena/ena_logs.h
 create mode 100644 drivers/net/ena/ena_platform.h
 create mode 100644 drivers/net/ena/rte_pmd_ena_version.map

-- 
1.9.1

[dpdk-dev] [PATCH 4/4] szedata2: add 100G link speed

[Matej Vido]

D?a 15.03.2016 o 14:41 Thomas Monjalon nap?sal(a):
> Thanks for the series completing the ethdev rework with the same splitting.
>
> 2016-03-15 14:12, Matej Vido:
>> Temporary 10G constant is replaced with 100G constant.
>> Item speed_capa from struct rte_eth_dev_info is set with 100G flag.
> [...]
>> @@ -1161,7 +1162,7 @@ eth_link_update(struct rte_eth_dev *dev,
>>   * will be changed to support 100Gbps speed change
>>   * this value to 100G.
>>   */
>> -link.link_speed = ETH_SPEED_NUM_10G;
>> +link.link_speed = ETH_SPEED_NUM_100G;
> Shouldn't we remove the above comment?
Yes, I forgot. Should I remove the comment and send again or could you 
do it when merging with original series?

Matej

[dpdk-dev] [PATCH 4/4] szedata2: add 100G link speed

[Matej Vido]

D?a 15.03.2016 o 14:41 Thomas Monjalon nap?sal(a):
> Thanks for the series completing the ethdev rework with the same splitting.
>
> 2016-03-15 14:12, Matej Vido:
>> Temporary 10G constant is replaced with 100G constant.
>> Item speed_capa from struct rte_eth_dev_info is set with 100G flag.
> [...]
>> @@ -1161,7 +1162,7 @@ eth_link_update(struct rte_eth_dev *dev,
>>   * will be changed to support 100Gbps speed change
>>   * this value to 100G.
>>   */
>> -link.link_speed = ETH_SPEED_NUM_10G;
>> +link.link_speed = ETH_SPEED_NUM_100G;
> Shouldn't we remove the above comment?
Yes, I forgot

[dpdk-dev] [PATCH 4/4] szedata2: add 100G link speed

[Thomas Monjalon]

Thanks for the series completing the ethdev rework with the same splitting.

2016-03-15 14:12, Matej Vido:
> Temporary 10G constant is replaced with 100G constant.
> Item speed_capa from struct rte_eth_dev_info is set with 100G flag.
[...]
> @@ -1161,7 +1162,7 @@ eth_link_update(struct rte_eth_dev *dev,
>* will be changed to support 100Gbps speed change
>* this value to 100G.
>*/
> - link.link_speed = ETH_SPEED_NUM_10G;
> + link.link_speed = ETH_SPEED_NUM_100G;

Shouldn't we remove the above comment?

[dpdk-dev] [PATCH v11 2/2] vhost: Add VHOST PMD

[Tetsuya Mukawa]

On 2016/03/14 21:02, Bruce Richardson wrote:
> On Mon, Mar 07, 2016 at 11:07:14AM +0900, Tetsuya Mukawa wrote:
>> The patch introduces a new PMD. This PMD is implemented as thin wrapper
>> of librte_vhost. It means librte_vhost is also needed to compile the PMD.
>> The vhost messages will be handled only when a port is started. So start
>> a port first, then invoke QEMU.
>>
>> The PMD has 2 parameters.
>>  - iface:  The parameter is used to specify a path to connect to a
>>virtio-net device.
>>  - queues: The parameter is used to specify the number of the queues
>>virtio-net device has.
>>(Default: 1)
>>
>> Here is an example.
>> $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i
>>
>> To connect above testpmd, here is qemu command example.
>>
>> $ qemu-system-x86_64 \
>> 
>> -chardev socket,id=chr0,path=/tmp/sock0 \
>> -netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \
>> -device virtio-net-pci,netdev=net0,mq=on
>>
>> Signed-off-by: Tetsuya Mukawa 
>> Acked-by: Ferruh Yigit 
>> Acked-by: Yuanhan Liu 
>> Acked-by: Rich Lane 
>> Tested-by: Rich Lane 
>> ---
>>  MAINTAINERS |   5 +
>>  config/common_base  |   6 +
>>  config/common_linuxapp  |   1 +
>>  doc/guides/nics/index.rst   |   1 +
> This adds a new entry for vhost PMD into the index, but there is no vhost.rst
> file present in this patchset. Did you forget to add it?

Yes, it seems so. The file is only on my environment.
I will add it.

Thanks,
Tetsuya

>
>>  doc/guides/rel_notes/release_16_04.rst  |   4 +
>>  drivers/net/Makefile|   4 +
>>  drivers/net/vhost/Makefile  |  62 ++
>>  drivers/net/vhost/rte_eth_vhost.c   | 916 
>> 
>>  drivers/net/vhost/rte_eth_vhost.h   | 109 
>>  drivers/net/vhost/rte_pmd_vhost_version.map |  10 +
>>  mk/rte.app.mk   |   6 +
>>  11 files changed, 1124 insertions(+)
>>  create mode 100644 drivers/net/vhost/Makefile
>>  create mode 100644 drivers/net/vhost/rte_eth_vhost.c
>>  create mode 100644 drivers/net/vhost/rte_eth_vhost.h
>>  create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map
> 
>
> /Bruce
>

[dpdk-dev] [PATCH v3] examples/l3fwd: em path performance fix

[Kulasek, TomaszX]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Kulasek, TomaszX
> Sent: Friday, March 11, 2016 18:49
> To: Thomas Monjalon ; Maciej Czekaj
> 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] examples/l3fwd: em path performance fix
> 
> 
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Friday, March 11, 2016 17:23
> > To: Kulasek, TomaszX 
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3] examples/l3fwd: em path performance
> fix
> >
> > There is an error:
> > examples/l3fwd/l3fwd_em_hlm_sse.h:72:38: error:
> > incompatible type for argument 2 of ?_mm_and_si128?
> 
> It's caused by
> 
> commit 64d3955de1de4d7879a0930a6d2f501369d3445a
> Author: Maciej Czekaj 
> Date:   Thu Mar 10 17:06:22 2016 +0100
> 
> examples/l3fwd: fix ARM build
> 
> Enable NEON support in exact match mode.
> l3fwd example did not compile on ARM due to SSE2 instrincics used
> in generic part.
> Some instrinsins were used to initialize data structures and those
> were
> replaced by ordinary structure initalization.
> All SSE2 intrinsics used in forwarding, i.e. masking the IP/TCP header
> are moved to single inline function and made arch-specific.
> 
> Signed-off-by: Maciej Czekaj 
> 
> Which doesn't include rework of l3fwd_em_hlm_sse.h file.
> 
> When you compile it now with global "#define HASH_MULTI_LOOKUP 1" and
> alternative classification is used, and compilation will also fail now.
> 
> I need a little bit more time to investigate it, because I'm not an expert
> in ARM. It will be nice if Maciej will help me in that.
> 
> Tomasz

Will be that ok for you to disable this path for arm?

[dpdk-dev] Reg: promiscuous mode on VF

[bharath paulraj]

Hi Team,

We are facing an issue when we are trying to implement Layer 2 bridging
functionality over the Virtual function.

*Requirement:*
We need to create four VMs and each VM should run in promiscuous mode
for a specific VLAN, so that it can receive packets for that VLAN and all
the unicast MAC address irrespective of its (VF) mac address. In other
words, the packet classification should be based on VLAN only. Each VM has
to use SRIOV enabled with VF interface (NIC Controller used here is Intel
82599)

*Problem Description:*
Facing issues while enabling promiscuous mode in virtual function. We
have seen many mail threads about promiscuous mode not working on VF.

*Questions:*
1) Is it possible to enable promiscuous mode on virtual function?
2) Is the above supported for 82599 controller? If it is supported in
the NIC, please provide the steps to enable.
3) If it is enabled, then VLAN should be the only classifier to
determine the packets fate to reach the VM. Is it possible to do the
classification based on the VLAN alone?

Thanks,
Bharath Paulraj

[dpdk-dev] [PATCH 4/4] szedata2: add 100G link speed

[Matej Vido]

Temporary 10G constant is replaced with 100G constant.
Item speed_capa from struct rte_eth_dev_info is set with 100G flag.

Signed-off-by: Matej Vido 
---
 drivers/net/szedata2/rte_eth_szedata2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/szedata2/rte_eth_szedata2.c 
b/drivers/net/szedata2/rte_eth_szedata2.c
index 0708e4a..f1855a5 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1036,6 +1036,7 @@ eth_dev_info(struct rte_eth_dev *dev,
dev_info->max_rx_queues = internals->max_rx_queues;
dev_info->max_tx_queues = internals->max_tx_queues;
dev_info->min_rx_bufsize = 0;
+   dev_info->speed_capa = ETH_LINK_SPEED_100G;
 }

 static void
@@ -1161,7 +1162,7 @@ eth_link_update(struct rte_eth_dev *dev,
 * will be changed to support 100Gbps speed change
 * this value to 100G.
 */
-   link.link_speed = ETH_SPEED_NUM_10G;
+   link.link_speed = ETH_SPEED_NUM_100G;
break;
default:
link.link_speed = ETH_SPEED_NUM_10G;
-- 
1.9.1

[dpdk-dev] [PATCH 3/4] szedata2: redesign link speed config

[Matej Vido]

This patch sets value of flag link_autoneg in struct rte_eth_link
to ETH_LINK_SPEED_FIXED.

Signed-off-by: Matej Vido 
---
 drivers/net/szedata2/rte_eth_szedata2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/szedata2/rte_eth_szedata2.c 
b/drivers/net/szedata2/rte_eth_szedata2.c
index 854cb5c..0708e4a 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1174,6 +1174,8 @@ eth_link_update(struct rte_eth_dev *dev,
link.link_status = (cgmii_ibuf_is_enabled(ibuf) &&
cgmii_ibuf_is_link_up(ibuf)) ? ETH_LINK_UP : 
ETH_LINK_DOWN;

+   link.link_autoneg = ETH_LINK_SPEED_FIXED;
+
rte_atomic64_cmpset((uint64_t *)dev_link, *(uint64_t *)dev_link,
*(uint64_t *)link_ptr);

-- 
1.9.1

[dpdk-dev] [PATCH 2/4] szedata2: rename link speed constants

[Matej Vido]

The speed numbers ETH_LINK_SPEED_ are renamed ETH_SPEED_NUM_.

Signed-off-by: Matej Vido 
---
 drivers/net/szedata2/rte_eth_szedata2.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/szedata2/rte_eth_szedata2.c 
b/drivers/net/szedata2/rte_eth_szedata2.c
index c65067e..854cb5c 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1149,10 +1149,10 @@ eth_link_update(struct rte_eth_dev *dev,

switch (cgmii_link_speed(ibuf)) {
case SZEDATA2_LINK_SPEED_10G:
-   link.link_speed = ETH_LINK_SPEED_10G;
+   link.link_speed = ETH_SPEED_NUM_10G;
break;
case SZEDATA2_LINK_SPEED_40G:
-   link.link_speed = ETH_LINK_SPEED_40G;
+   link.link_speed = ETH_SPEED_NUM_40G;
break;
case SZEDATA2_LINK_SPEED_100G:
/*
@@ -1161,10 +1161,10 @@ eth_link_update(struct rte_eth_dev *dev,
 * will be changed to support 100Gbps speed change
 * this value to 100G.
 */
-   link.link_speed = ETH_LINK_SPEED_10G;
+   link.link_speed = ETH_SPEED_NUM_10G;
break;
default:
-   link.link_speed = ETH_LINK_SPEED_10G;
+   link.link_speed = ETH_SPEED_NUM_10G;
break;
}

-- 
1.9.1

[dpdk-dev] [PATCH 1/4] szedata2: use constants for link state

[Matej Vido]

Use ETH_LINK_UP and ETH_LINK_DOWN constants.

Signed-off-by: Matej Vido 
---
 drivers/net/szedata2/rte_eth_szedata2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/szedata2/rte_eth_szedata2.c 
b/drivers/net/szedata2/rte_eth_szedata2.c
index 81c806e..c65067e 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1172,7 +1172,7 @@ eth_link_update(struct rte_eth_dev *dev,
link.link_duplex = ETH_LINK_FULL_DUPLEX;

link.link_status = (cgmii_ibuf_is_enabled(ibuf) &&
-   cgmii_ibuf_is_link_up(ibuf)) ? 1 : 0;
+   cgmii_ibuf_is_link_up(ibuf)) ? ETH_LINK_UP : 
ETH_LINK_DOWN;

rte_atomic64_cmpset((uint64_t *)dev_link, *(uint64_t *)dev_link,
*(uint64_t *)link_ptr);
-- 
1.9.1

[dpdk-dev] [PATCH 0/4] szedata2: 100G and link speed API refactoring

[Matej Vido]

This patch series adds link speed API changes to szedata2 driver
based on current dpdk-next-net/rel_16_04 tree.
Changes are split into commits as in v10 of patch series:
http://dpdk.org/ml/archives/dev/2016-March/035731.html


Matej Vido (4):
  szedata2: use constants for link state
  szedata2: rename link speed constants
  szedata2: redesign link speed config
  szedata2: add 100G link speed

 drivers/net/szedata2/rte_eth_szedata2.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

-- 
1.9.1

[dpdk-dev] [PATCH] lpm: fix memory leak

[Olivier Matz]

Internal lpm structures are not properly freed. Seen with the
lpm6 autotest.

Signed-off-by: Olivier Matz 
---
 lib/librte_lpm/rte_lpm.c  | 3 +++
 lib/librte_lpm/rte_lpm6.c | 1 +
 2 files changed, 4 insertions(+)

diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index dd62f9b..d28e954 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -318,6 +318,7 @@ rte_lpm_create_v1604(const char *name, int socket_id,

if (lpm->tbl8 == NULL) {
RTE_LOG(ERR, LPM, "LPM memory allocation failed\n");
+   rte_free(lpm->rules_tbl);
rte_free(lpm);
rte_free(te);
goto exit;
@@ -406,6 +407,8 @@ rte_lpm_free_v1604(struct rte_lpm *lpm)

rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);

+   rte_free(lpm->tbl8);
+   rte_free(lpm->rules_tbl);
rte_free(lpm);
rte_free(te);
 }
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 4e9f2d0..faf7684 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -288,6 +288,7 @@ rte_lpm6_free(struct rte_lpm6 *lpm)

rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);

+   rte_free(lpm->rules_tbl);
rte_free(lpm);
rte_free(te);
 }
-- 
2.1.4

[dpdk-dev] [RFC] hash/lpm: return NULL if the object exists

[Olivier Matz]

Seen by trying to fix the func_reentrancy autotest. The test
was doing the following on several cores in parallel:

  name = "common_name";
  do several times {
  obj = allocate_an_object(name)   // obj = ring, mempool, hash, lpm, ...
  if (obj == NULL && lookup(name) == NULL)
  return TEST_FAIL;
  }

Issues:

1/ rings, mempools, hashs API are not coherent
   rings and mempool return NULL if the object does not exist
   hash and lpm return an object that was allocated allocated if
   it already was allocated

2/ The hash/lpm API looks dangerous: when an object is returned,
   the user does not know if it should be freed or not (no refcnt)

3/ There are some possible race conditions in cuckoo_hash as the
   lock is not held in rte_hash_create(). We could find some cases
   where NULL is returned when the object already exists (ex: when
   rte_ring_create() fails).

This patch tries to rationalize the APIs of lpm and hash.

Signed-off-by: Olivier Matz 
---
 app/test/test_func_reentrancy.c   | 31 +--
 app/test/test_lpm6.c  |  2 +-
 lib/librte_hash/rte_cuckoo_hash.c |  2 +-
 lib/librte_hash/rte_fbk_hash.c|  4 +++-
 lib/librte_lpm/rte_lpm.c  |  8 ++--
 lib/librte_lpm/rte_lpm6.c |  4 +++-
 6 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/app/test/test_func_reentrancy.c b/app/test/test_func_reentrancy.c
index 5d09296..300a3bc 100644
--- a/app/test/test_func_reentrancy.c
+++ b/app/test/test_func_reentrancy.c
@@ -83,6 +83,7 @@ typedef void (*case_clean_t)(unsigned lcore_id);

 #define MAX_LCORES RTE_MAX_MEMZONE / (MAX_ITER_TIMES * 4U)

+static rte_atomic32_t obj_count = RTE_ATOMIC32_INIT(0);
 static rte_atomic32_t synchro = RTE_ATOMIC32_INIT(0);

 #define WAIT_SYNCHRO_FOR_SLAVES()   do{ \
@@ -100,6 +101,7 @@ test_eal_init_once(__attribute__((unused)) void *arg)

WAIT_SYNCHRO_FOR_SLAVES();

+   rte_atomic32_set(_count, 1); /* silent the check in the caller */
if (rte_eal_init(0, NULL) != -1)
return -1;

@@ -122,8 +124,8 @@ ring_create_lookup(__attribute__((unused)) void *arg)
/* create the same ring simultaneously on all threads */
for (i = 0; i < MAX_ITER_TIMES; i++) {
rp = rte_ring_create("fr_test_once", 4096, SOCKET_ID_ANY, 0);
-   if ((NULL == rp) && (rte_ring_lookup("fr_test_once") == NULL))
-   return -1;
+   if (rp != NULL)
+   rte_atomic32_inc(_count);
}

/* create/lookup new ring several times */
@@ -172,8 +174,8 @@ mempool_create_lookup(__attribute__((unused)) void *arg)
NULL, NULL,
my_obj_init, NULL,
SOCKET_ID_ANY, 0);
-   if ((NULL == mp) && (rte_mempool_lookup("fr_test_once") == 
NULL))
-   return -1;
+   if (mp != NULL)
+   rte_atomic32_inc(_count);
}

/* create/lookup new ring several times */
@@ -238,8 +240,8 @@ hash_create_free(__attribute__((unused)) void *arg)
hash_params.name = "fr_test_once";
for (i = 0; i < MAX_ITER_TIMES; i++) {
handle = rte_hash_create(_params);
-   if ((NULL == handle) && (rte_hash_find_existing("fr_test_once") 
== NULL))
-   return -1;
+   if (handle != NULL)
+   rte_atomic32_inc(_count);
}

/* create mutiple times simultaneously */
@@ -306,8 +308,8 @@ fbk_create_free(__attribute__((unused)) void *arg)
fbk_params.name = "fr_test_once";
for (i = 0; i < MAX_ITER_TIMES; i++) {
handle = rte_fbk_hash_create(_params);
-   if ((NULL == handle) && 
(rte_fbk_hash_find_existing("fr_test_once") == NULL))
-   return -1;
+   if (handle != NULL)
+   rte_atomic32_inc(_count);
}

/* create mutiple fbk tables simultaneously */
@@ -372,8 +374,8 @@ lpm_create_free(__attribute__((unused)) void *arg)
/* create the same lpm simultaneously on all threads */
for (i = 0; i < MAX_ITER_TIMES; i++) {
lpm = rte_lpm_create("fr_test_once",  SOCKET_ID_ANY, );
-   if ((NULL == lpm) && (rte_lpm_find_existing("fr_test_once") == 
NULL))
-   return -1;
+   if (lpm != NULL)
+   rte_atomic32_inc(_count);
}

/* create mutiple fbk tables simultaneously */
@@ -432,10 +434,12 @@ launch_test(struct test_case *pt_case)
unsigned lcore_id;
unsigned cores_save = rte_lcore_count();
unsigned cores = RTE_MIN(cores_save, MAX_LCORES);
+   unsigned count;

if (pt_case->func == NULL)
return -1;

+   rte_atomic32_set(_count, 0);
rte_atomic32_set(, 0);

RTE_LCORE_FOREACH_SLAVE(lcore_id) {

[dpdk-dev] [PATCH] autotests: fix pmd ring

[Olivier Matz]

This test expects that a vdev is instanciated on the command
line. If it's not the case, just skip this part.

Signed-off-by: Olivier Matz 
---
 app/test/test_pmd_ring.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/app/test/test_pmd_ring.c b/app/test/test_pmd_ring.c
index 5568759..34fea09 100644
--- a/app/test/test_pmd_ring.c
+++ b/app/test/test_pmd_ring.c
@@ -425,7 +425,7 @@ static int
 test_pmd_ring(void)
 {
struct rte_ring *rxtx[NUM_RINGS];
-   int cmdl_port0 = 0;
+   int port, cmdl_port0 = -1;
uint8_t nb_ports;

nb_ports = rte_eth_dev_count();
@@ -501,8 +501,18 @@ test_pmd_ring(void)
if (test_pmd_ring_pair_create_attach(rxtx_portd, rxtx_porte) < 0)
return -1;

-   if (nb_ports > 0) {
-   /* test port 0 created with the --vdev=eth_ring0 command line 
option */
+   /* find a port created with the --vdev=eth_ring0 command line option */
+   for (port = 0; port < nb_ports; port++) {
+   struct rte_eth_dev_info dev_info;
+
+   rte_eth_dev_info_get(port, _info);
+   if (!strcmp(dev_info.driver_name, "Rings PMD")) {
+   printf("found a command line ring port=%d\n", port);
+   cmdl_port0 = port;
+   break;
+   }
+   }
+   if (cmdl_port0 != -1) {
if (test_ethdev_configure_port(cmdl_port0) < 0)
return -1;
if (test_send_basic_packets_port(cmdl_port0) < 0)
-- 
2.1.4

[dpdk-dev] [PATCH] autotests: display command line when starting

[Olivier Matz]

It's useful for debug purposes to see the command line used by
autotest.py.

Signed-off-by: Olivier Matz 
---
 app/test/autotest_runner.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/app/test/autotest_runner.py b/app/test/autotest_runner.py
index eadfb7f..291a821 100644
--- a/app/test/autotest_runner.py
+++ b/app/test/autotest_runner.py
@@ -72,6 +72,7 @@ def run_test_group(cmdline, test_group):
startuplog = StringIO.StringIO()

print >>startuplog, "\n%s %s\n" % ("="*20, test_group["Prefix"])
+   print >>startuplog, "\ncmdline=%s" % cmdline

child = pexpect.spawn(cmdline, logfile=startuplog)

-- 
2.1.4

[dpdk-dev] Client Server Application using DPDK API

[Vivek Gupta]

Hi

Thanks for your prompt reply.

As per my understanding rte_mbuf structure contains information of many header 
and their corresponding values.
Like Ethernet, IP and UDP Headers.
I would like to know what are the other headers information is available and 
how to extract those information from packet.

Thanks & Regards
Vivek Gupta


-Original Message-
From: Bruce Richardson [mailto:bruce.richard...@intel.com] 
Sent: Tuesday, March 15, 2016 4:12 PM
To: Vivek Gupta
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Client Server Application using DPDK API

On Tue, Mar 15, 2016 at 09:06:12AM +, Vivek Gupta wrote:
> Hi
> 
> I am developing a network program using DPDK API. I want to extract the data 
> which is there is rte_mbuf structure.
> 
> Referred to rte_mbuf structure manual but confused with fields
> 
> uint16_t buf_len; /**< Length of segment buffer. */
> uint16_t data_len;/**< Amount of data in segment buffer. */
> 
> 
> Can someone help me to understand how to extract data from buffer?

The first value is the size of the buffer, the second is the amount of data in 
the buffer. When working with a packet in an mbuf, the data_len is the value 
you want.

/Bruce

> 
> Thanks & regards
> Vivek Gupta
> 
> -Original Message-
> From: Remy Horton [mailto:remy.horton at intel.com]
> Sent: Wednesday, March 09, 2016 10:14 PM
> To: Vivek Gupta
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Client Server Application using DPDK API
> 
> 'noon,
> 
> On 09/03/2016 08:45, Vivek Gupta wrote:
> > Hi
> >
> > I want to write a Client Server application using DPDK API on a 
> > single machine. What are the basic building block for that. How can 
> > we write such application?
> 
> examples/l2fwd/main.c and examples/ethtool/ethtool-app/main.c are probably 
> the easier examples to follow. In terms of function calls, it is pretty much:
> 
> rte_eal_init(..);
> for (each port) {
>   rte_pktmbuf_pool_create(..);
>   rte_eth_dev_configure(..);
>   rte_eth_dev_rx_queue_setup(..);
>   rte_eth_dev_tx_queue_setup(..);
>   rte_eth_dev_start(..);
> }
> while(1) {
>   rte_eth_rx_burst(..); /* incoming frames */
>   rte_eth_tx_burst(..); /* outgoing frames */ }
> 
> Bear in mind that DPDK deals with MAC frames rather than higher level IP 
> packets, which may be an issue if you intend to use TCP/IP based application 
> protocols.
> 
> 
> > ::DISCLAIMER::
> 
> Avoid using confidentality disclaimers on mailing list emails. It 
> tends to "annoy" people.. :)
> 
> Regards,
> 
> ..Remy
> 
> 
> ::DISCLAIMER::
> --
> --
> 
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as 
> information could be intercepted, corrupted, lost, destroyed, arrive 
> late or incomplete, or may contain viruses in transmission. The e mail and 
> its contents (with or without referred errors) shall therefore not attach any 
> liability on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of 
> the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, 
> copying, disclosure, modification, distribution and / or publication of this 
> message without the prior written consent of authorized representative of HCL 
> is strictly prohibited. If you have received this email in error please 
> delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses 
> and other defects.
> 
> --
> --
> 
> 

[dpdk-dev] Client Server Application using DPDK API

[Bruce Richardson]

On Tue, Mar 15, 2016 at 09:06:12AM +, Vivek Gupta wrote:
> Hi
> 
> I am developing a network program using DPDK API. I want to extract the data 
> which is there is rte_mbuf structure.
> 
> Referred to rte_mbuf structure manual but confused with fields 
> 
> uint16_t buf_len; /**< Length of segment buffer. */
> uint16_t data_len;/**< Amount of data in segment buffer. */
> 
> 
> Can someone help me to understand how to extract data from buffer?

The first value is the size of the buffer, the second is the amount of data
in the buffer. When working with a packet in an mbuf, the data_len is the value
you want.

/Bruce

> 
> Thanks & regards
> Vivek Gupta
> 
> -Original Message-
> From: Remy Horton [mailto:remy.horton at intel.com] 
> Sent: Wednesday, March 09, 2016 10:14 PM
> To: Vivek Gupta
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Client Server Application using DPDK API
> 
> 'noon,
> 
> On 09/03/2016 08:45, Vivek Gupta wrote:
> > Hi
> >
> > I want to write a Client Server application using DPDK API on a single 
> > machine. What are the basic building block for that. How can we write 
> > such application?
> 
> examples/l2fwd/main.c and examples/ethtool/ethtool-app/main.c are probably 
> the easier examples to follow. In terms of function calls, it is pretty much:
> 
> rte_eal_init(..);
> for (each port) {
>   rte_pktmbuf_pool_create(..);
>   rte_eth_dev_configure(..);
>   rte_eth_dev_rx_queue_setup(..);
>   rte_eth_dev_tx_queue_setup(..);
>   rte_eth_dev_start(..);
> }
> while(1) {
>   rte_eth_rx_burst(..); /* incoming frames */
>   rte_eth_tx_burst(..); /* outgoing frames */ }
> 
> Bear in mind that DPDK deals with MAC frames rather than higher level IP 
> packets, which may be an issue if you intend to use TCP/IP based application 
> protocols.
> 
> 
> > ::DISCLAIMER::
> 
> Avoid using confidentality disclaimers on mailing list emails. It tends to 
> "annoy" people.. :)
> 
> Regards,
> 
> ..Remy
> 
> 
> ::DISCLAIMER::
> 
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as 
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in 
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability on 
> the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the 
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction, 
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written 
> consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error please 
> delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses 
> and other defects.
> 
> 
> 

[dpdk-dev] [PATCH v6 2/2] i40evf: support to report pf reset event

[Jingjing Wu]

When Linux PF and DPDK VF are used for i40e PMD, In case of PF reset,
interrupt will go via adminq event, VF need be informed the event,
a callback mechanism is introduced by VF. This will allow VF to
invoke callback when reset happens.
Users can register a callback for this interrupt event like:
  rte_eth_dev_callback_register(portid,
RTE_ETH_EVENT_INTR_RESET,
reset_event_callback,
arg);

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 doc/guides/rel_notes/release_16_04.rst |   3 +
 drivers/net/i40e/i40e_ethdev_vf.c  | 275 +
 lib/librte_ether/rte_ethdev.h  |   1 +
 3 files changed, 249 insertions(+), 30 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 5f9eb3e..c1a8456 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -139,6 +139,9 @@ This section should contain new features added in this 
release. Sample format:
   Added support for linking multi-segment buffers together to
   handle Jumbo packets.

+* **Added pf reset event reporting in i40e vf PMD driver.**
+
+
 Resolved Issues
 ---

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 7944ccc..1ce174c 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -74,8 +74,6 @@
 #define I40EVF_BUSY_WAIT_DELAY 10
 #define I40EVF_BUSY_WAIT_COUNT 50
 #define MAX_RESET_WAIT_CNT 20
-/*ITR index for NOITR*/
-#define I40E_QINT_RQCTL_MSIX_INDX_NOITR 3

 struct i40evf_arq_msg_info {
enum i40e_virtchnl_ops ops;
@@ -156,6 +154,9 @@ static int
 i40evf_dev_rx_queue_intr_enable(struct rte_eth_dev *dev, uint16_t queue_id);
 static int
 i40evf_dev_rx_queue_intr_disable(struct rte_eth_dev *dev, uint16_t queue_id);
+static void i40evf_handle_pf_event(__rte_unused struct rte_eth_dev *dev,
+  uint8_t *msg,
+  uint16_t msglen);

 /* Default hash key buffer for RSS */
 static uint32_t rss_key_default[I40E_VFQF_HKEY_MAX_INDEX + 1];
@@ -342,19 +343,40 @@ i40evf_execute_vf_cmd(struct rte_eth_dev *dev, struct 
vf_cmd_info *args)
return err;
}

-   do {
-   ret = i40evf_read_pfmsg(dev, );
-   if (ret == I40EVF_MSG_CMD) {
-   err = 0;
-   break;
-   } else if (ret == I40EVF_MSG_ERR) {
-   err = -1;
-   break;
-   }
-   rte_delay_ms(ASQ_DELAY_MS);
-   /* If don't read msg or read sys event, continue */
-   } while (i++ < MAX_TRY_TIMES);
-   _clear_cmd(vf);
+   switch (args->ops) {
+   case I40E_VIRTCHNL_OP_RESET_VF:
+   /*no need to process in this function */
+   break;
+   case I40E_VIRTCHNL_OP_VERSION:
+   case I40E_VIRTCHNL_OP_GET_VF_RESOURCES:
+   /* for init adminq commands, need to poll the response */
+   do {
+   ret = i40evf_read_pfmsg(dev, );
+   if (ret == I40EVF_MSG_CMD) {
+   err = 0;
+   break;
+   } else if (ret == I40EVF_MSG_ERR) {
+   err = -1;
+   break;
+   }
+   rte_delay_ms(ASQ_DELAY_MS);
+   /* If don't read msg or read sys event, continue */
+   } while (i++ < MAX_TRY_TIMES);
+   _clear_cmd(vf);
+   break;
+
+   default:
+   /* for other adminq in running time, waiting the cmd done flag 
*/
+   do {
+   if (vf->pend_cmd == I40E_VIRTCHNL_OP_UNKNOWN) {
+   err = 0;
+   break;
+   }
+   rte_delay_ms(ASQ_DELAY_MS);
+   /* If don't read msg or read sys event, continue */
+   } while (i++ < MAX_TRY_TIMES);
+   break;
+   }

return err | vf->cmd_retval;
 }
@@ -703,7 +725,7 @@ i40evf_config_irq_map(struct rte_eth_dev *dev)

map_info = (struct i40e_virtchnl_irq_map_info *)cmd_buffer;
map_info->num_vectors = 1;
-   map_info->vecmap[0].rxitr_idx = I40E_QINT_RQCTL_MSIX_INDX_NOITR;
+   map_info->vecmap[0].rxitr_idx = I40E_ITR_INDEX_DEFAULT;
map_info->vecmap[0].vsi_id = vf->vsi_res->vsi_id;
/* Alway use default dynamic MSIX interrupt */
map_info->vecmap[0].vector_id = vector_id;
@@ -1083,6 +1105,38 @@ i40evf_dev_atomic_write_link_status(struct rte_eth_dev 
*dev,
return 0;
 }

+/* Disable IRQ0 */
+static inline void
+i40evf_disable_irq0(struct i40e_hw *hw)
+{
+   /* Disable all interrupt types */
+   I40E_WRITE_REG(hw, 

[dpdk-dev] [PATCH v6 1/2] i40evf: allocate virtchnl cmd buffer for each vf

[Jingjing Wu]

Currently, i40evf PMD uses a global static buffer to send virtchnl
command to host driver. It is shared by multi VFs.
This patch changed to allocate virtchnl cmd buffer for each VF.

Signed-off-by: Jingjing Wu 
Acked-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev.h|   2 +
 drivers/net/i40e/i40e_ethdev_vf.c | 180 +++---
 2 files changed, 72 insertions(+), 110 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 1c75672..b641882 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -500,7 +500,9 @@ struct i40e_vf {
bool link_up;
bool vf_reset;
volatile uint32_t pend_cmd; /* pending command not finished yet */
+   uint32_t cmd_retval; /* return value of the cmd response from PF */
u16 pend_msg; /* flags indicates events from pf not handled yet */
+   uint8_t *aq_resp; /* buffer to store the adminq response from PF */

/* VSI info */
struct i40e_virtchnl_vf_resource *vf_res; /* All VSIs */
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 6b7b350..7944ccc 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -103,9 +103,6 @@ enum i40evf_aq_result {
I40EVF_MSG_CMD,  /* Read async command result */
 };

-/* A share buffer to store the command result from PF driver */
-static uint8_t cmd_result_buffer[I40E_AQ_BUF_SZ];
-
 static int i40evf_dev_configure(struct rte_eth_dev *dev);
 static int i40evf_dev_start(struct rte_eth_dev *dev);
 static void i40evf_dev_stop(struct rte_eth_dev *dev);
@@ -224,31 +221,37 @@ static const struct eth_dev_ops i40evf_eth_dev_ops = {
 };

 /*
- * Parse admin queue message.
- *
- * return value:
- *  < 0: meet error
- *  0: read sys msg
- *  > 0: read cmd result
+ * Read data in admin queue to get msg from pf driver
  */
 static enum i40evf_aq_result
-i40evf_parse_pfmsg(struct i40e_vf *vf,
-  struct i40e_arq_event_info *event,
-  struct i40evf_arq_msg_info *data)
+i40evf_read_pfmsg(struct rte_eth_dev *dev, struct i40evf_arq_msg_info *data)
 {
-   enum i40e_virtchnl_ops opcode = (enum i40e_virtchnl_ops)\
-   rte_le_to_cpu_32(event->desc.cookie_high);
-   enum i40e_status_code retval = (enum i40e_status_code)\
-   rte_le_to_cpu_32(event->desc.cookie_low);
-   enum i40evf_aq_result ret = I40EVF_MSG_CMD;
+   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
+   struct i40e_arq_event_info event;
+   enum i40e_virtchnl_ops opcode;
+   enum i40e_status_code retval;
+   int ret;
+   enum i40evf_aq_result result = I40EVF_MSG_NON;
+
+   event.buf_len = data->buf_len;
+   event.msg_buf = data->msg;
+   ret = i40e_clean_arq_element(hw, , NULL);
+   /* Can't read any msg from adminQ */
+   if (ret) {
+   if (ret != I40E_ERR_ADMIN_QUEUE_NO_WORK)
+   result = I40EVF_MSG_ERR;
+   return result;
+   }

+   opcode = (enum 
i40e_virtchnl_ops)rte_le_to_cpu_32(event.desc.cookie_high);
+   retval = (enum i40e_status_code)rte_le_to_cpu_32(event.desc.cookie_low);
/* pf sys event */
if (opcode == I40E_VIRTCHNL_OP_EVENT) {
struct i40e_virtchnl_pf_event *vpe =
-   (struct i40e_virtchnl_pf_event *)event->msg_buf;
+   (struct i40e_virtchnl_pf_event *)event.msg_buf;

-   /* Initialize ret to sys event */
-   ret = I40EVF_MSG_SYS;
+   result = I40EVF_MSG_SYS;
switch (vpe->event) {
case I40E_VIRTCHNL_EVENT_LINK_CHANGE:
vf->link_up =
@@ -273,74 +276,17 @@ i40evf_parse_pfmsg(struct i40e_vf *vf,
}
} else {
/* async reply msg on command issued by vf previously */
-   ret = I40EVF_MSG_CMD;
+   result = I40EVF_MSG_CMD;
/* Actual data length read from PF */
-   data->msg_len = event->msg_len;
+   data->msg_len = event.msg_len;
}
-   /* fill the ops and result to notify VF */
+
data->result = retval;
data->ops = opcode;

-   return ret;
-}
-
-/*
- * Read data in admin queue to get msg from pf driver
- */
-static enum i40evf_aq_result
-i40evf_read_pfmsg(struct rte_eth_dev *dev, struct i40evf_arq_msg_info *data)
-{
-   struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-   struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
-   struct i40e_arq_event_info event;
-   int ret;
-   enum i40evf_aq_result result = I40EVF_MSG_NON;
-
-   event.buf_len = data->buf_len;
-   event.msg_buf = data->msg;
-   ret = i40e_clean_arq_element(hw, , NULL);

[dpdk-dev] [PATCH v6 0/2] i40evf: pf reset event report

[Jingjing Wu]

v6 changes:
 - rebase on latest dpdk-next-net/rel_16_04 branch (commit 94d8f4bf963a)
 - fix complie issue

v5 changes:
 - doc rewording and format fixing.

v4 changes:
 - rebase on latest dpdk-next-net/rel_16_04 branch (commit 0f9564a0e4f2)

v3 changes:
 - commit log doc rewording.
 - rebase on latest dpdk-next-net/rel_16_04 branch.
 - remove few useless line.
 - adjust interval and increase times for waiting pf msg

v2 changes:
 - remove the change on vf reset status checking
 - add pf event report support in release note

When Linux PF and DPDK VF are used for i40e PMD, In case of PF
reset, interrupt request will go via adminq event, VF need be
informed, a callback mechanism is introduced by VF. This will
allow VF to invoke callback when reset happens.
Users can register a callback for this interrupt event like:
rte_eth_dev_callback_register(portid,
 RTE_ETH_EVENT_INTR_RESET,
 reset_event_callback,
 arg);


Jingjing Wu (2):
  i40evf: allocate virtchnl cmd buffer for each vf
  i40evf: support to report pf reset event

 doc/guides/rel_notes/release_16_04.rst |   3 +
 drivers/net/i40e/i40e_ethdev.h |   2 +
 drivers/net/i40e/i40e_ethdev_vf.c  | 425 +++--
 lib/librte_ether/rte_ethdev.h  |   1 +
 4 files changed, 306 insertions(+), 125 deletions(-)

-- 
2.4.0

[dpdk-dev] [PATCH v8 01/11] ethdev: add API to query supported packet types

[Tan, Jianfeng]

Hi,

On 3/15/2016 1:14 AM, Ferruh Yigit wrote:
> On 3/14/2016 7:42 AM, Jianfeng Tan wrote:
>> Add a new API rte_eth_dev_get_supported_ptypes to query what packet types
>> can be filled by given already started device (or its pmd rx burst function
>> has already been decided).
>>
>> Signed-off-by: Jianfeng Tan 
>> Acked-by: Konstantin Ananyev 
>> Acked-by: Adrien Mazarguil 
>> ---
> <...>
>
>> +DPDK_16.04 {
>> +rte_eth_dev_get_supported_ptypes;
> Other script files tends to put a blank line before function names.

Thank you for reminding.

>
>> +
>> +local: *;
> This line is not required.

Yes, actually, this leads to compiling error when 
CONFIG_RTE_BUILD_SHARED_LIB=y.

Bruce, do you mind fix these two issues when applying the code (if 
there's no other issue)? Thanks.

Jianfeng

>
>> +} DPDK_2.2;
>>

[dpdk-dev] [PATCH v10 0/8] ethdev: 100G and link speed API refactoring

[Nélio Laranjeiro]

On Mon, Mar 14, 2016 at 10:55:38PM +0100, Thomas Monjalon wrote:
> Re-spin of the Marc's patchset.
> The first version was sent 10 months ago!
> There are still too few tests and reviews but it is now time to move
> forward with this rework.
> Some issues were remaining in v9 and were difficult to see because it
> was mainly one big patch. That's why I've split it in several steps
> and fixed/reworked some pieces.
> There will be an exception to integrate this feature in 16.04-rc2.
> Please test and review shortly, thanks!
>[...] 

Tested-by: Nelio Laranjeiro 

 1. On Mellanox ConnectX-3, Connexct-4 100G, ConnectX-4 Lx, speed is
correctly displayed according to the negotiated link speed.

 2. Configuring speed tested, not working as expected.

-- 
N?lio Laranjeiro
6WIND

[dpdk-dev] Client Server Application using DPDK API

[Vivek Gupta]

Hi

I am developing a network program using DPDK API. I want to extract the data 
which is there is rte_mbuf structure.

Referred to rte_mbuf structure manual but confused with fields 

uint16_t buf_len; /**< Length of segment buffer. */
uint16_t data_len;/**< Amount of data in segment buffer. */


Can someone help me to understand how to extract data from buffer?

Thanks & regards
Vivek Gupta

-Original Message-
From: Remy Horton [mailto:remy.hor...@intel.com] 
Sent: Wednesday, March 09, 2016 10:14 PM
To: Vivek Gupta
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Client Server Application using DPDK API

'noon,

On 09/03/2016 08:45, Vivek Gupta wrote:
> Hi
>
> I want to write a Client Server application using DPDK API on a single 
> machine. What are the basic building block for that. How can we write 
> such application?

examples/l2fwd/main.c and examples/ethtool/ethtool-app/main.c are probably the 
easier examples to follow. In terms of function calls, it is pretty much:

rte_eal_init(..);
for (each port) {
rte_pktmbuf_pool_create(..);
rte_eth_dev_configure(..);
rte_eth_dev_rx_queue_setup(..);
rte_eth_dev_tx_queue_setup(..);
rte_eth_dev_start(..);
}
while(1) {
rte_eth_rx_burst(..); /* incoming frames */
rte_eth_tx_burst(..); /* outgoing frames */ }

Bear in mind that DPDK deals with MAC frames rather than higher level IP 
packets, which may be an issue if you intend to use TCP/IP based application 
protocols.


> ::DISCLAIMER::

Avoid using confidentality disclaimers on mailing list emails. It tends to 
"annoy" people.. :)

Regards,

..Remy


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.

[dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-process environment

[张伟]

Thanks so much for your patch! Your patch exactly solves my bug. :)


At 2016-03-15 08:57:29, "Dhananjaya Eadala"  wrote:
Hi

I looked at your info from gdb and source code.

[dpdk-dev] dpdk hash lookup function crashed (segment fault)

[张伟]

Thanks for your reply! I used one patch solve my problem someone posted  last 
night in the mailing list.


At 2016-03-14 21:02:13, "Kyle Larose"  wrote:
>Hello,
>
>On Sun, Mar 13, 2016 at 10:38 AM, ??  wrote:
>> Hi all,
>> When I use the dpdk lookup function, I met the segment fault problem. Can  
>> anybody help to look at why this happens. I will put the aim what I want to 
>> do and the related piece of code, and my debug message,
>>
>>
>> This problem is that in dpdk multi process - client and server example, 
>> dpdk-2.2.0/examples/multi_process/client_server_mp
>> My aim is that server create a hash table, then share it to client. Client 
>> will write the hash  table, server will read the hash table.  I am using 
>> dpdk hash table.  What I did is that server create a hash table (table and 
>> array entries), return the table address.  I use memzone pass the table 
>> address to client.  In client, the second lookup gets segment fault. The 
>> system gets crashed.  I will put some related code here.
>> create hash table function:
>>
>
>Let me see if I understand correctly. You're allocating a hash table
>on huge-page backed memory.
>You pass a pointer to that table over a shared memory structure.
>
>Is that correct?
>
>I don't think something being in a huge-page necessarily means it is
>shared. That is, allocating your hash table using rte_calloc in the
>primary isn't sufficient to make it available in the secondary.
>
>Further, even if it was, I do not think that it would work, because
>there are a bunch of pointers involved (i.e. ft->data). As far as I'm
>aware, each  process has its own "view" of the shared memory. It maps
>it into its own local address space, and gives it an address according
>to what is currently available there.
>
>Most of my IPC with DPDK has involved passing packets around; I'm not
>sure what the strategy is for hash tables. Synchronization issues
>aside, I think you will need to put the hash table in its entirety in
>shared memory, and avoid global pointers: either offset into the
>shared memory, or have a structure with no pointers at all. From that,
>you can probably build up local pointers.
>
>Maybe somebody else can correct me or come up with a better idea.
>
>Hope that helps,
>
>Kyle
>
>
>> struct onvm_ft*
>>
>> onvm_ft_create(int cnt, int entry_size) {
>>
>> struct rte_hash* hash;
>>
>> struct onvm_ft* ft;
>>
>> struct rte_hash_parameters ipv4_hash_params = {
>>
>> .name = NULL,
>>
>> .entries = cnt,
>>
>> .key_len = sizeof(struct onvm_ft_ipv4_5tuple),
>>
>> .hash_func = NULL,
>>
>> .hash_func_init_val = 0,
>>
>> };
>>
>>
>>
>>
>> char s[64];
>>
>> /* create ipv4 hash table. use core number and cycle counter to get 
>> a unique name. */
>>
>> ipv4_hash_params.name = s;
>>
>> ipv4_hash_params.socket_id = rte_socket_id();
>>
>> snprintf(s, sizeof(s), "onvm_ft_%d-%"PRIu64, rte_lcore_id(), 
>> rte_get_tsc_cycles());
>>
>> hash = rte_hash_create(_hash_params);
>>
>> if (hash == NULL) {
>>
>> return NULL;
>>
>> }
>>
>> ft = (struct onvm_ft*)rte_calloc("table", 1, sizeof(struct onvm_ft), 
>> 0);
>>
>> if (ft == NULL) {
>>
>> rte_hash_free(hash);
>>
>> return NULL;
>>
>> }
>>
>> ft->hash = hash;
>>
>> ft->cnt = cnt;
>>
>> ft->entry_size = entry_size;
>>
>> /* Create data array for storing values */
>>
>> ft->data = rte_calloc("entry", cnt, entry_size, 0);
>>
>> if (ft->data == NULL) {
>>
>> rte_hash_free(hash);
>>
>> rte_free(ft);
>>
>> return NULL;
>>
>> }
>>
>> return ft;
>>
>> }
>>
>>
>>
>>
>> related structure:
>>
>> struct onvm_ft {
>>
>> struct rte_hash* hash;
>>
>> char* data;
>>
>> int cnt;
>>
>> int entry_size;
>>
>> };
>>
>>
>>
>>
>> in server side, I will call the create function, use memzone share it to 
>> client. The following is what I do:
>>
>> related variables:
>>
>> struct onvm_ft *sdn_ft;
>>
>> struct onvm_ft **sdn_ft_p;
>>
>> const struct rte_memzone *mz_ftp;
>>
>>
>>
>>
>> sdn_ft = onvm_ft_create(1024, sizeof(struct onvm_flow_entry));
>>
>> if(sdn_ft == NULL) {
>>
>> rte_exit(EXIT_FAILURE, "Unable to create flow table\n");
>>
>> }
>>
>> mz_ftp = rte_memzone_reserve(MZ_FTP_INFO, sizeof(struct onvm_ft *),
>>
>>   rte_socket_id(), NO_FLAGS);
>>
>> if (mz_ftp == NULL) {
>>
>> rte_exit(EXIT_FAILURE, "Canot reserve memory zone for flow 
>> table pointer\n");
>>
>> }
>>
>> memset(mz_ftp->addr, 0, sizeof(struct onvm_ft *));
>>
>> sdn_ft_p = mz_ftp->addr;
>>
>> *sdn_ft_p = sdn_ft;
>>
>>
>>
>>
>> In client side:
>>
>> struct onvm_ft *sdn_ft;
>>
>> static void
>>

[dpdk-dev] [PATCH v10 0/8] ethdev: 100G and link speed API refactoring

[Matej Vido]

D?a 15.03.2016 o 08:12 Thomas Monjalon nap?sal(a):
> 2016-03-15 01:04, Matej Vido:
>> Hi,
>>
>> patch http://dpdk.org/dev/patchwork/patch/10202/
>> which was applied to dpdk-next-net/rel_16_04 tree changes filling
>> of items in rte_eth_link structure for szedata2 driver. These changes
>> for szedata2 driver are not compliant with changes in this patch series.
>> I'm not sure how it should be addressed.
> The branch dpdk-next-net/rel_16_04 is going to be rebased for RC1 integration.
> This series targets RC2.
> Please prepare a patch to replace the szedata2 changes of this patch, and
> it will be merged in the series for a v11.
> Thanks
Ok, I'll do.

Regards,
Matej

[dpdk-dev] [PATCH v3 1/3] mk: clear up libm and librt linkage confusion

[Panu Matilainen]

On 03/14/2016 06:44 PM, Ferruh Yigit wrote:
> On 3/10/2016 1:15 PM, Panu Matilainen wrote:
>> There are two places that need -lm (test app and librte_sched) and
>> exactly one that needs -lrt (librte_sched). Add the relevant
>> DT_NEEDED entries to both, and eliminate the bogus discrepancy
>> between Linux and BSD EXECENV_LDLIBS wrt these libs.
>>
>> Signed-off-by: Panu Matilainen 
>> ---
>>   app/test/Makefile| 2 ++
>>   lib/librte_sched/Makefile| 3 +++
>>   mk/exec-env/linuxapp/rte.vars.mk | 2 +-
>>   mk/rte.app.mk| 6 ++
>>   4 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/app/test/Makefile b/app/test/Makefile
>> index ec33e1a..00e4df2 100644
>> --- a/app/test/Makefile
>> +++ b/app/test/Makefile
>> @@ -160,6 +160,8 @@ CFLAGS += $(WERROR_FLAGS)
>>
>>   CFLAGS += -D_GNU_SOURCE
>>
>> +LDLIBS += -lm
>> +
>>   # Disable VTA for memcpy test
>>   ifeq ($(CC), gcc)
>>   ifeq ($(shell test $(GCC_VERSION) -ge 44 && echo 1), 1)
>> diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
>> index b1cb285..4d631f6 100644
>> --- a/lib/librte_sched/Makefile
>> +++ b/lib/librte_sched/Makefile
>> @@ -41,6 +41,9 @@ CFLAGS += $(WERROR_FLAGS)
>>
>>   CFLAGS_rte_red.o := -D_GNU_SOURCE
>>
>> +LDLIBS += -lm
>> +LDLIBS += -lrt
>> +
>>   EXPORT_MAP := rte_sched_version.map
>>
>>   LIBABIVER := 1
>> diff --git a/mk/exec-env/linuxapp/rte.vars.mk 
>> b/mk/exec-env/linuxapp/rte.vars.mk
>> index 5fd7d85..d51bd17 100644
>> --- a/mk/exec-env/linuxapp/rte.vars.mk
>> +++ b/mk/exec-env/linuxapp/rte.vars.mk
>> @@ -48,7 +48,7 @@ endif
>>   # Workaround lack of DT_NEEDED entry
>>   EXECENV_LDFLAGS = --no-as-needed
>>
>> -EXECENV_LDLIBS  = -lrt -lm
>> +EXECENV_LDLIBS  =
>>   EXECENV_ASFLAGS =
>>
>>   ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
>> index daac09f..cadc7ab 100644
>> --- a/mk/rte.app.mk
>> +++ b/mk/rte.app.mk
>> @@ -77,11 +77,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_LPM)+= -lrte_lpm
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_POWER)  += -lrte_power
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_METER)  += -lrte_meter
>> -
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED)  += -lrte_sched
>> -_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED)  += -lm
>> -_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED)  += -lrt
>> -
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST)  += -lrte_vhost
>>
>>   ifeq ($(CONFIG_RTE_LIBRTE_VHOST_NUMA),y)
>> @@ -104,6 +100,8 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT)+= -lxenstore
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD)  += -lgxio
>>   # QAT PMD has a dependency on libcrypto (from openssl) for calculating 
>> HMAC precomputes
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lcrypto
>> +_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED)  += -lm
>> +_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED)  += -lrt
>>   endif # !CONFIG_RTE_BUILD_SHARED_LIBS
>>
>>   _LDLIBS-y += --start-group
>>
> This is causing a shared library compilation error with gcc:
>
> "
> == Build app/test-acl
>LD testacl
> /root/dpdk/build/lib/librte_meter.so: error: undefined reference to 'ceil'
> collect2: error: ld returned 1 exit status
> "
>
> There is an indirect libm dependency from test-acl. Adding -lm fixes the
> issue.
>
> But this issue not seen by everybody, not sure why I am getting this but
> not others.
>
> Also clang compiles fine, only fails with gcc.
> I am using Fedora 23, gcc version:
> gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
>
> I will dig some more.

Right, librte_meter indeed has a dependency on libm that I've missed.
The curious thing is why is it not failing everywhere - I cannot 
reproduce that at all on Fedora 23. Poking around in math.h leads to 
bits/mathlinline.h where the answer probably lies: ceil() is typically 
provided by inline code, but for one reason or another that is not 
available in your setup.

Anyway, I'll send a patch to add the missing dependency, thanks for 
spotting and reporting!

- Panu -

> Regards,
> ferruh
>
>
>
>

[dpdk-dev] [PATCH v10 0/8] ethdev: 100G and link speed API refactoring

[Thomas Monjalon]

2016-03-15 01:04, Matej Vido:
> Hi,
> 
> patch http://dpdk.org/dev/patchwork/patch/10202/
> which was applied to dpdk-next-net/rel_16_04 tree changes filling
> of items in rte_eth_link structure for szedata2 driver. These changes
> for szedata2 driver are not compliant with changes in this patch series.
> I'm not sure how it should be addressed.

The branch dpdk-next-net/rel_16_04 is going to be rebased for RC1 integration.
This series targets RC2.
Please prepare a patch to replace the szedata2 changes of this patch, and
it will be merged in the series for a v11.
Thanks

[dpdk-dev] [PATCH v2 0/2] cryptodev API changes

[Cao, Min]

Tested-by: Min Cao 

- Tested Commit: e45ef10c34540c3f543689d833db8bb7296d9e85
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 24 cases, 24 passed, 0 failed

- test case 1: QAT Unit test 
Total 13 cases, 13 passed, 0 failed

- test case 2: AES_NI Unit test 
Total 10 cases, 10 passed, 0 failed

- test case 3: l2fwd-crypto 
Total 1 cases, 1 passed, 0 failed

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Declan Doherty
Sent: Friday, February 19, 2016 7:01 PM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v2 0/2] cryptodev API changes

This patch set separates the symmetric crypto operations from generic 
operations and then modifies the cryptodev burst API to accept bursts of 
rte_crypto_op rather than rte_mbufs.

This patch set is dependent on the following bug fixes patches:

aesni_mb: strict-aliasing rule compilation fix
(http://dpdk.org/ml/archives/dev/2016-February/033193.html)

qat:fix build on 32-bit systems
(http://dpdk.org/ml/archives/dev/2016-February/033442.html)

aesni_mb: fix wrong return value
(http://dpdk.org/ml/archives/dev/2016-February/033193.html)

Various fixes for L2fwd-crypto

Declan Doherty (1):
  cryptodev: change burst API to be crypto op oriented

Fiona Trahe (1):
  cryptodev: API tidy and changes to support future extensions

 MAINTAINERS|   4 -
 app/test/test_cryptodev.c  | 890 +++--
 app/test/test_cryptodev.h  |   9 +-
 app/test/test_cryptodev_perf.c | 270 ---
 config/common_bsdapp   |   7 -
 config/common_linuxapp |  11 +-
 doc/api/doxy-api-index.md  |   1 -
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 199 ++---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  18 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   6 +-
 drivers/crypto/qat/qat_crypto.c| 154 ++--
 drivers/crypto/qat/qat_crypto.h|  14 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   8 +-
 examples/l2fwd-crypto/main.c   | 281 ---
 lib/Makefile   |   1 -
 lib/librte_cryptodev/Makefile  |   1 +
 lib/librte_cryptodev/rte_crypto.h  | 802 +++
 lib/librte_cryptodev/rte_crypto_sym.h  | 642 +++
 lib/librte_cryptodev/rte_cryptodev.c   | 113 ++-
 lib/librte_cryptodev/rte_cryptodev.h   | 183 ++---
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  32 +-
 lib/librte_cryptodev/rte_cryptodev_version.map |   1 +
 lib/librte_mbuf/rte_mbuf.h |   6 -
 lib/librte_mbuf_offload/Makefile   |  52 --
 lib/librte_mbuf_offload/rte_mbuf_offload.c | 100 ---
 lib/librte_mbuf_offload/rte_mbuf_offload.h | 307 ---
 .../rte_mbuf_offload_version.map   |   7 -
 27 files changed, 2114 insertions(+), 2005 deletions(-)  create mode 100644 
lib/librte_cryptodev/rte_crypto_sym.h
 delete mode 100644 lib/librte_mbuf_offload/Makefile  delete mode 100644 
lib/librte_mbuf_offload/rte_mbuf_offload.c
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.h
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload_version.map

--
2.5.0

[dpdk-dev] [PATCH 4/4] pci: fix ioport support for uio_pci_generic on x86

[David Marchand]

uio_pci_generic does not offer the same sysfs helpers as igb_uio.
In this case, ioport number can only be retrieved by parsing /proc/ioports.

Fixes: 756ce64b1ecd ("eal: introduce PCI ioport API")

Reported-by: Mauricio V?squez 
Signed-off-by: David Marchand 
---
 lib/librte_eal/linuxapp/eal/eal_pci.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 74c6919..dbf12a8 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -620,7 +620,11 @@ rte_eal_pci_ioport_map(struct rte_pci_device *dev, int bar,
ret = pci_uio_ioport_map(dev, bar, p);
break;
case RTE_KDRV_UIO_GENERIC:
+#if defined(RTE_ARCH_X86)
+   ret = pci_ioport_map(dev, bar, p);
+#else
ret = pci_uio_ioport_map(dev, bar, p);
+#endif
break;
case RTE_KDRV_NONE:
 #if defined(RTE_ARCH_X86)
@@ -705,7 +709,11 @@ rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
ret = pci_uio_ioport_unmap(p);
break;
case RTE_KDRV_UIO_GENERIC:
+#if defined(RTE_ARCH_X86)
+   ret = 0;
+#else
ret = pci_uio_ioport_unmap(p);
+#endif
break;
case RTE_KDRV_NONE:
 #if defined(RTE_ARCH_X86)
-- 
1.9.1

[dpdk-dev] [PATCH 3/4] pci: align ioport special case for x86 in read/write/unmap

[David Marchand]

Commit b8eb345378bd ("pci: ignore devices already managed in Linux when
mapping x86 ioport") did not update other parts of the ioport api.

The application is not supposed to call these read/write/unmap ioport
functions if map call failed but I prefer aligning the code for the sake
of consistency.

Signed-off-by: David Marchand 
---
 lib/librte_eal/linuxapp/eal/eal_pci.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 7707292..74c6919 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -653,12 +653,13 @@ rte_eal_pci_ioport_read(struct rte_pci_ioport *p,
case RTE_KDRV_UIO_GENERIC:
pci_uio_ioport_read(p, data, len, offset);
break;
-   default:
+   case RTE_KDRV_NONE:
 #if defined(RTE_ARCH_X86)
-   /* special case for x86 ... */
pci_uio_ioport_read(p, data, len, offset);
 #endif
break;
+   default:
+   break;
}
 }

@@ -678,12 +679,13 @@ rte_eal_pci_ioport_write(struct rte_pci_ioport *p,
case RTE_KDRV_UIO_GENERIC:
pci_uio_ioport_write(p, data, len, offset);
break;
-   default:
+   case RTE_KDRV_NONE:
 #if defined(RTE_ARCH_X86)
-   /* special case for x86 ... */
pci_uio_ioport_write(p, data, len, offset);
 #endif
break;
+   default:
+   break;
}
 }

@@ -705,12 +707,13 @@ rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
case RTE_KDRV_UIO_GENERIC:
ret = pci_uio_ioport_unmap(p);
break;
-   default:
+   case RTE_KDRV_NONE:
 #if defined(RTE_ARCH_X86)
-   /* special case for x86 ... nothing to do */
ret = 0;
 #endif
break;
+   default:
+   break;
}

return ret;
-- 
1.9.1

[dpdk-dev] [PATCH 2/4] pci: align ioport unmap error handling to ioport map

[David Marchand]

Same idea as commit bd80d4730aca ("pci: rework ioport map error handling").

Signed-off-by: David Marchand 
---
 lib/librte_eal/linuxapp/eal/eal_pci.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index e2af371..7707292 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -690,12 +690,11 @@ rte_eal_pci_ioport_write(struct rte_pci_ioport *p,
 int
 rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
 {
-   int ret;
+   int ret = -1;

switch (p->dev->kdrv) {
 #ifdef VFIO_PRESENT
case RTE_KDRV_VFIO:
-   ret = -1;
if (pci_vfio_is_enabled())
ret = pci_vfio_ioport_unmap(p);
break;
@@ -710,8 +709,6 @@ rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
 #if defined(RTE_ARCH_X86)
/* special case for x86 ... nothing to do */
ret = 0;
-#else
-   ret = -1;
 #endif
break;
}
-- 
1.9.1

[dpdk-dev] [PATCH 1/4] pci: explicitly call ioport handlers for uio_pci_generic

[David Marchand]

Prepare for fixes on x86 by separating igb_uio and uio_pci_generic cases.

Signed-off-by: David Marchand 
---
 lib/librte_eal/linuxapp/eal/eal_pci.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c 
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 9f75252..e2af371 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -617,6 +617,8 @@ rte_eal_pci_ioport_map(struct rte_pci_device *dev, int bar,
break;
 #endif
case RTE_KDRV_IGB_UIO:
+   ret = pci_uio_ioport_map(dev, bar, p);
+   break;
case RTE_KDRV_UIO_GENERIC:
ret = pci_uio_ioport_map(dev, bar, p);
break;
@@ -646,6 +648,8 @@ rte_eal_pci_ioport_read(struct rte_pci_ioport *p,
break;
 #endif
case RTE_KDRV_IGB_UIO:
+   pci_uio_ioport_read(p, data, len, offset);
+   break;
case RTE_KDRV_UIO_GENERIC:
pci_uio_ioport_read(p, data, len, offset);
break;
@@ -669,6 +673,8 @@ rte_eal_pci_ioport_write(struct rte_pci_ioport *p,
break;
 #endif
case RTE_KDRV_IGB_UIO:
+   pci_uio_ioport_write(p, data, len, offset);
+   break;
case RTE_KDRV_UIO_GENERIC:
pci_uio_ioport_write(p, data, len, offset);
break;
@@ -695,6 +701,8 @@ rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
break;
 #endif
case RTE_KDRV_IGB_UIO:
+   ret = pci_uio_ioport_unmap(p);
+   break;
case RTE_KDRV_UIO_GENERIC:
ret = pci_uio_ioport_unmap(p);
break;
-- 
1.9.1

[dpdk-dev] [PATCH 0/4] x86 ioport fixes

[David Marchand]

Here is a patchset for little cleanups and a fix on newly introduced pci
ioport api.
The last patch fixes a regression reported by Mauricio V. [1].


[1]: http://dpdk.org/ml/archives/dev/2016-February/033922.html

-- 
David Marchand

David Marchand (4):
  pci: explicitly call ioport handlers for uio_pci_generic
  pci: align ioport unmap error handling to ioport map
  pci: align ioport special case for x86 in read/write/unmap
  pci: fix ioport support for uio_pci_generic on x86

 lib/librte_eal/linuxapp/eal/eal_pci.c | 36 +--
 1 file changed, 26 insertions(+), 10 deletions(-)

-- 
1.9.1

[dpdk-dev] [PATCH v3 0/2] cryptodev API changes

[Cao, Min]

Tested-by: Min Cao 

- Tested Commit: e45ef10c34540c3f543689d833db8bb7296d9e85
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 24 cases, 24 passed, 0 failed

- test case 1: QAT Unit test 
Total 13 cases, 13 passed, 0 failed

- test case 2: AES_NI Unit test 
Total 10 cases, 10 passed, 0 failed

- test case 3: l2fwd-crypto 
Total 1 cases, 1 passed, 0 failed

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Declan Doherty
Sent: Saturday, February 27, 2016 1:30 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v3 0/2] cryptodev API changes

This patch set separates the symmetric crypto operations from generic 
operations and then modifies the cryptodev burst API to accept bursts of 
rte_crypto_op rather than rte_mbufs.

V3:
 - Addresses V2 comments
 - Rebased for head

Declan Doherty (1):
  cryptodev: change burst API to be crypto op oriented

Fiona Trahe (1):
  cryptodev: API tidy and changes to support future extensions

 MAINTAINERS|   6 +-
 app/test/test_cryptodev.c  | 894 +++--
 app/test/test_cryptodev.h  |   9 +-
 app/test/test_cryptodev_perf.c | 270 ---
 config/common_bsdapp   |   8 -
 config/common_linuxapp |   8 -
 doc/api/doxy-api-index.md  |   1 -
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 199 ++---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  18 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   6 +-
 drivers/crypto/qat/qat_crypto.c| 150 ++--
 drivers/crypto/qat/qat_crypto.h|  14 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   8 +-
 examples/l2fwd-crypto/main.c   | 300 ---
 lib/Makefile   |   1 -
 lib/librte_cryptodev/Makefile  |   1 +
 lib/librte_cryptodev/rte_crypto.h  | 822 ---
 lib/librte_cryptodev/rte_crypto_sym.h  | 642 +++
 lib/librte_cryptodev/rte_cryptodev.c   | 115 ++-
 lib/librte_cryptodev/rte_cryptodev.h   | 185 ++---
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  32 +-
 lib/librte_cryptodev/rte_cryptodev_version.map |   3 +-
 lib/librte_mbuf/rte_mbuf.h |   6 -
 lib/librte_mbuf_offload/Makefile   |  52 --
 lib/librte_mbuf_offload/rte_mbuf_offload.c | 100 ---
 lib/librte_mbuf_offload/rte_mbuf_offload.h | 310 ---
 .../rte_mbuf_offload_version.map   |   7 -
 27 files changed, 2146 insertions(+), 2021 deletions(-)  create mode 100644 
lib/librte_cryptodev/rte_crypto_sym.h
 delete mode 100644 lib/librte_mbuf_offload/Makefile  delete mode 100644 
lib/librte_mbuf_offload/rte_mbuf_offload.c
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.h
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload_version.map

--
2.5.0

[dpdk-dev] [PATCH v4 0/2] cryptodev API changes

[Cao, Min]

Tested-by: Min Cao 

- Tested Commit: e45ef10c34540c3f543689d833db8bb7296d9e85
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 24 cases, 24 passed, 0 failed

- test case 1: QAT Unit test 
Total 13 cases, 13 passed, 0 failed

- test case 2: AES_NI Unit test 
Total 10 cases, 10 passed, 0 failed

- test case 3: l2fwd-crypto 
Total 1 cases, 1 passed, 0 failed

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Declan Doherty
Sent: Tuesday, March 01, 2016 12:52 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v4 0/2] cryptodev API changes

This patch set separates the symmetric crypto operations from generic 
operations and then modifies the cryptodev burst API to accept bursts of 
rte_crypto_op rather than rte_mbufs.

V4:
- Fixes for issues introduced in __rte_crypto_op_raw_bulk_alloc in V3 patcheset.
- Typo fix in cached attribute on rte_crypto_op structure.

V3:
 - Addresses V2 comments
 - Rebased for head


Declan Doherty (1):
  cryptodev: change burst API to be crypto op oriented

Fiona Trahe (1):
  cryptodev: API tidy and changes to support future extensions

 MAINTAINERS|   6 +-
 app/test/test_cryptodev.c  | 894 +++--
 app/test/test_cryptodev.h  |   9 +-
 app/test/test_cryptodev_perf.c | 270 ---
 config/common_bsdapp   |   8 -
 config/common_linuxapp |   8 -
 doc/api/doxy-api-index.md  |   1 -
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 199 ++---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  18 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   6 +-
 drivers/crypto/qat/qat_crypto.c| 150 ++--
 drivers/crypto/qat/qat_crypto.h|  14 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   8 +-
 examples/l2fwd-crypto/main.c   | 300 ---
 lib/Makefile   |   1 -
 lib/librte_cryptodev/Makefile  |   1 +
 lib/librte_cryptodev/rte_crypto.h  | 819 +++
 lib/librte_cryptodev/rte_crypto_sym.h  | 642 +++
 lib/librte_cryptodev/rte_cryptodev.c   | 115 ++-
 lib/librte_cryptodev/rte_cryptodev.h   | 185 ++---
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  32 +-
 lib/librte_cryptodev/rte_cryptodev_version.map |   3 +-
 lib/librte_mbuf/rte_mbuf.h |   6 -
 lib/librte_mbuf_offload/Makefile   |  52 --
 lib/librte_mbuf_offload/rte_mbuf_offload.c | 100 ---
 lib/librte_mbuf_offload/rte_mbuf_offload.h | 310 ---
 .../rte_mbuf_offload_version.map   |   7 -
 27 files changed, 2143 insertions(+), 2021 deletions(-)  create mode 100644 
lib/librte_cryptodev/rte_crypto_sym.h
 delete mode 100644 lib/librte_mbuf_offload/Makefile  delete mode 100644 
lib/librte_mbuf_offload/rte_mbuf_offload.c
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.h
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload_version.map

--
2.5.0

[dpdk-dev] [PATCH v5 0/2] cryptodev API changes

[Cao, Min]

Tested-by: Min Cao 

- Tested Commit: e45ef10c34540c3f543689d833db8bb7296d9e85
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 23 cases, 23 passed, 0 failed

- test case 1: QAT Unit test 
Total 13 cases, 13 passed, 0 failed

- test case 2: AES_NI Unit test 
Total 10 cases, 10 passed, 0 failed

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fiona Trahe
Sent: Saturday, March 05, 2016 1:18 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v5 0/2] cryptodev API changes

This patch set separates the symmetric crypto operations from generic 
operations and then modifies the cryptodev burst API to accept bursts of 
rte_crypto_op rather than rte_mbufs.

V5:
- updates .map file
- removes EXPERIMENTAL label from rte_cryptodev.h

V4:
- Fixes for issues introduced in __rte_crypto_op_raw_bulk_alloc in V3 patcheset.
- Typo fix in cached attribute on rte_crypto_op structure.

V3:
 - Addresses V2 comments
 - Rebased for head


Declan Doherty (1):
  cryptodev: change burst API to be crypto op oriented

Fiona Trahe (1):
  cryptodev: API tidy and changes to support future extensions


 MAINTAINERS|   6 +-
 app/test/test_cryptodev.c  | 894 +++--
 app/test/test_cryptodev.h  |   9 +-
 app/test/test_cryptodev_perf.c | 270 ---
 config/common_bsdapp   |   8 -
 config/common_linuxapp |   8 -
 doc/api/doxy-api-index.md  |   1 -
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 199 ++---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  18 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   6 +-
 drivers/crypto/qat/qat_crypto.c| 150 ++--
 drivers/crypto/qat/qat_crypto.h|  14 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   8 +-
 examples/l2fwd-crypto/main.c   | 300 ---
 lib/Makefile   |   1 -
 lib/librte_cryptodev/Makefile  |   1 +
 lib/librte_cryptodev/rte_crypto.h  | 819 +++
 lib/librte_cryptodev/rte_crypto_sym.h  | 642 +++
 lib/librte_cryptodev/rte_cryptodev.c   | 115 ++-
 lib/librte_cryptodev/rte_cryptodev.h   | 189 ++---
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  32 +-
 lib/librte_cryptodev/rte_cryptodev_version.map |   7 +-
 lib/librte_mbuf/rte_mbuf.h |   6 -
 lib/librte_mbuf_offload/Makefile   |  52 --
 lib/librte_mbuf_offload/rte_mbuf_offload.c | 100 ---
 lib/librte_mbuf_offload/rte_mbuf_offload.h | 310 ---
 .../rte_mbuf_offload_version.map   |   7 -
 27 files changed, 2145 insertions(+), 2027 deletions(-)  create mode 100644 
lib/librte_cryptodev/rte_crypto_sym.h
 delete mode 100644 lib/librte_mbuf_offload/Makefile  delete mode 100644 
lib/librte_mbuf_offload/rte_mbuf_offload.c
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.h
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload_version.map

--
2.1.0

[dpdk-dev] [PATCH v6 0/2] cryptodev API changes

[Cao, Min]

Tested-by: Min Cao 

- Tested Commit: e45ef10c34540c3f543689d833db8bb7296d9e85
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 24 cases, 24 passed, 0 failed

- test case 1: QAT Unit test 
Total 13 cases, 13 passed, 0 failed

- test case 2: AES_NI Unit test 
Total 10 cases, 10 passed, 0 failed

- test case 3: l2fwd-crypto 
Total 1 cases, 1 passed, 0 failed

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fiona Trahe
Sent: Saturday, March 05, 2016 2:30 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v6 0/2] cryptodev API changes

This patch set separates the symmetric crypto operations from generic 
operations and then modifies the cryptodev burst API to accept bursts of 
rte_crypto_op rather than rte_mbufs.

v6:
- restore EXPERIMENTAL label to cryptodev. Will handle removal in separate 
thread.
(email subject was incorrect in v5, so v5 hasn't arrived in patchwork, 
therefore v6 is in-reply-to v4 message id)

V5: 
- updates .map file
- removes EXPERIMENTAL label from rte_cryptodev.h

V4:
- Fixes for issues introduced in __rte_crypto_op_raw_bulk_alloc in V3 patcheset.
- Typo fix in cached attribute on rte_crypto_op structure.

V3:
 - Addresses V2 comments
 - Rebased for head


Declan Doherty (1):
  cryptodev: change burst API to be crypto op oriented

Fiona Trahe (1):
  cryptodev: API tidy and changes to support future extensions


 MAINTAINERS|   4 -
 app/test/test_cryptodev.c  | 894 +++--
 app/test/test_cryptodev.h  |   9 +-
 app/test/test_cryptodev_perf.c | 270 ---
 config/common_bsdapp   |   9 +-
 config/common_linuxapp |   9 +-
 doc/api/doxy-api-index.md  |   1 -
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 199 ++---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  18 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   6 +-
 drivers/crypto/qat/qat_crypto.c| 150 ++--
 drivers/crypto/qat/qat_crypto.h|  14 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   8 +-
 examples/l2fwd-crypto/main.c   | 300 ---
 lib/Makefile   |   1 -
 lib/librte_cryptodev/Makefile  |   1 +
 lib/librte_cryptodev/rte_crypto.h  | 819 +++
 lib/librte_cryptodev/rte_crypto_sym.h  | 642 +++
 lib/librte_cryptodev/rte_cryptodev.c   | 115 ++-
 lib/librte_cryptodev/rte_cryptodev.h   | 191 ++---
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  32 +-
 lib/librte_cryptodev/rte_cryptodev_version.map |   7 +-
 lib/librte_mbuf/rte_mbuf.h |   6 -
 lib/librte_mbuf_offload/Makefile   |  52 --
 lib/librte_mbuf_offload/rte_mbuf_offload.c | 100 ---
 lib/librte_mbuf_offload/rte_mbuf_offload.h | 310 ---
 .../rte_mbuf_offload_version.map   |   7 -
 27 files changed, 2148 insertions(+), 2026 deletions(-)  create mode 100644 
lib/librte_cryptodev/rte_crypto_sym.h
 delete mode 100644 lib/librte_mbuf_offload/Makefile  delete mode 100644 
lib/librte_mbuf_offload/rte_mbuf_offload.c
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.h
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload_version.map

--
2.1.0

[dpdk-dev] [PATCH v7 0/2] cryptodev API changes

[Cao, Min]

Tested-by: Min Cao 

- Tested Commit: e702183bab5a13f6e7d77be0d414914319469020
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 24 cases, 24 passed, 0 failed

- test case 1: QAT Unit test 
Total 13 cases, 13 passed, 0 failed

- test case 2: AES_NI Unit test 
Total 10 cases, 10 passed, 0 failed

- test case 3: l2fwd-crypto 
Total 1 cases, 1 passed, 0 failed

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fiona Trahe
Sent: Monday, March 07, 2016 7:50 PM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v7 0/2] cryptodev API changes


This patch set separates the symmetric crypto operations from generic 
operations and then modifies the cryptodev burst API to accept bursts of 
rte_crypto_op rather than rte_mbufs.

v7:
- remove trailing spaces introduced in v6
- rebase against recent config file changes

v6:
- restore EXPERIMENTAL label to cryptodev. Will handle removal in separate 
thread.
(email subject was incorrect in v5, so v5 hasn't arrived in patchwork, 
therefore v6 is in-reply-to v4 message id)

V5: 
- updates .map file
- removes EXPERIMENTAL label from rte_cryptodev.h

V4:
- Fixes for issues introduced in __rte_crypto_op_raw_bulk_alloc in V3 patcheset.
- Typo fix in cached attribute on rte_crypto_op structure.

V3:
 - Addresses V2 comments
 - Rebased for head


Declan Doherty (1):
  cryptodev: change burst API to be crypto op oriented

Fiona Trahe (2):
  cryptodev: API tidy and changes to support future extensions
  cryptodev: change burst API to be crypto op oriented

 MAINTAINERS|   4 -
 app/test/test_cryptodev.c  | 894 +++--
 app/test/test_cryptodev.h  |   9 +-
 app/test/test_cryptodev_perf.c | 270 ---
 config/common_base |   7 -
 doc/api/doxy-api-index.md  |   1 -
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 199 ++---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  18 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   6 +-
 drivers/crypto/qat/qat_crypto.c| 150 ++--
 drivers/crypto/qat/qat_crypto.h|  14 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   8 +-
 examples/l2fwd-crypto/main.c   | 300 ---
 lib/Makefile   |   1 -
 lib/librte_cryptodev/Makefile  |   1 +
 lib/librte_cryptodev/rte_crypto.h  | 819 +++
 lib/librte_cryptodev/rte_crypto_sym.h  | 642 +++
 lib/librte_cryptodev/rte_cryptodev.c   | 115 ++-
 lib/librte_cryptodev/rte_cryptodev.h   | 189 ++---
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  32 +-
 lib/librte_cryptodev/rte_cryptodev_version.map |   7 +-
 lib/librte_mbuf/rte_mbuf.h |   6 -
 lib/librte_mbuf_offload/Makefile   |  52 --
 lib/librte_mbuf_offload/rte_mbuf_offload.c | 100 ---
 lib/librte_mbuf_offload/rte_mbuf_offload.h | 310 ---
 .../rte_mbuf_offload_version.map   |   7 -
 26 files changed, 2145 insertions(+), 2016 deletions(-)  create mode 100644 
lib/librte_cryptodev/rte_crypto_sym.h
 delete mode 100644 lib/librte_mbuf_offload/Makefile  delete mode 100644 
lib/librte_mbuf_offload/rte_mbuf_offload.c
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.h
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload_version.map

--
2.1.0

[dpdk-dev] [PATCH v9 01/11] ethdev: add API to query supported packet types

[Jianfeng Tan]

Add a new API rte_eth_dev_get_supported_ptypes to query what packet types
can be filled by given already started device (or its pmd rx burst function
has already been decided).

Signed-off-by: Jianfeng Tan 
Acked-by: Konstantin Ananyev 
Acked-by: Adrien Mazarguil 
---
v9:
 - Fix rte_ether_version.map as Ferruh Yigit sugguests.
 lib/librte_ether/rte_ethdev.c  | 27 +++
 lib/librte_ether/rte_ethdev.h  | 27 +++
 lib/librte_ether/rte_ether_version.map |  7 +++
 3 files changed, 61 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a6e83c1..52fb62c 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1616,6 +1616,33 @@ rte_eth_dev_info_get(uint8_t port_id, struct 
rte_eth_dev_info *dev_info)
dev_info->driver_name = dev->data->drv_name;
 }

+int
+rte_eth_dev_get_supported_ptypes(uint8_t port_id, uint32_t ptype_mask,
+uint32_t *ptypes, int num)
+{
+   int i, j;
+   struct rte_eth_dev *dev;
+   const uint32_t *all_ptypes;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+   dev = _eth_devices[port_id];
+   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_supported_ptypes_get,
+   -ENOTSUP);
+   all_ptypes = (*dev->dev_ops->dev_supported_ptypes_get)(dev);
+
+   if (!all_ptypes)
+   return 0;
+
+   for (i = 0, j = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
+   if (all_ptypes[i] & ptype_mask) {
+   if (j < num)
+   ptypes[j] = all_ptypes[i];
+   j++;
+   }
+
+   return j;
+}
+
 void
 rte_eth_macaddr_get(uint8_t port_id, struct ether_addr *mac_addr)
 {
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index e2893ba..7770f24 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1021,6 +1021,9 @@ typedef void (*eth_dev_infos_get_t)(struct rte_eth_dev 
*dev,
struct rte_eth_dev_info *dev_info);
 /**< @internal Get specific informations of an Ethernet device. */

+typedef const uint32_t *(*eth_dev_supported_ptypes_get_t)(struct rte_eth_dev 
*dev);
+/**< @internal Get supported ptypes of an Ethernet device. */
+
 typedef int (*eth_queue_start_t)(struct rte_eth_dev *dev,
uint16_t queue_id);
 /**< @internal Start rx and tx of a queue of an Ethernet device. */
@@ -1347,6 +1350,7 @@ struct eth_dev_ops {
eth_queue_stats_mapping_set_t queue_stats_mapping_set;
/**< Configure per queue stat counter mapping. */
eth_dev_infos_get_tdev_infos_get; /**< Get device info. */
+   eth_dev_supported_ptypes_get_t dev_supported_ptypes_get; /** Get 
supported ptypes */
mtu_set_t  mtu_set; /**< Set MTU. */
vlan_filter_set_t  vlan_filter_set;  /**< Filter VLAN Setup. */
vlan_tpid_set_tvlan_tpid_set;  /**< Outer VLAN TPID 
Setup. */
@@ -2270,6 +2274,29 @@ void rte_eth_macaddr_get(uint8_t port_id, struct 
ether_addr *mac_addr);
 void rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info);

 /**
+ * Retrieve the supported packet types of an Ethernet device.
+ *
+ * @note
+ *   Better to invoke this API after the device is already started or rx burst
+ *   function is decided, to obtain correct supported ptypes.
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param ptype_mask
+ *   A hint of what kind of packet type which the caller is interested in.
+ * @param ptypes
+ *   An array pointer to store adequent packet types, allocated by caller.
+ * @param num
+ *  Size of the array pointed by param ptypes.
+ * @return
+ *   - (>0) Number of supported ptypes. If it exceeds param num, exceeding
+ *  packet types will not be filled in the given array.
+ *   - (0 or -ENOTSUP) if PMD does not fill the specified ptype.
+ *   - (-ENODEV) if *port_id* invalid.
+ */
+int rte_eth_dev_get_supported_ptypes(uint8_t port_id, uint32_t ptype_mask,
+uint32_t *ptypes, int num);
+
+/**
  * Retrieve the MTU of an Ethernet device.
  *
  * @param port_id
diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index d8db24d..c242e71 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -117,3 +117,10 @@ DPDK_2.2 {

local: *;
 };
+
+DPDK_16.04 {
+   global:
+
+   rte_eth_dev_get_supported_ptypes;
+
+} DPDK_2.2;
-- 
2.1.4

[dpdk-dev] [PATCH v10 1/8] ethdev: use constants for link state

[Zhang, Helin]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, March 15, 2016 5:56 AM
> To: marcdevel at gmail.com; Richardson, Bruce ;
> Doherty, Declan ; Ananyev, Konstantin
> ; Lu, Wenzhuo ;
> Zhang, Helin ; Chen, Jing D  intel.com>;
> harish.patil at qlogic.com; rahul.lakkireddy at chelsio.com; johndale at 
> cisco.com;
> vido at cesnet.cz; adrien.mazarguil at 6wind.com;
> alejandro.lucero at netronome.com
> Cc: dev at dpdk.org
> Subject: [PATCH v10 1/8] ethdev: use constants for link state
> 
> Define and use ETH_LINK_UP and ETH_LINK_DOWN where appropriate.
> 
> Signed-off-by: Marc Sune 
> Signed-off-by: Thomas Monjalon 
> ---




> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h 
> index
> d867976..6704a82 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -247,7 +247,7 @@ struct rte_eth_stats {  struct rte_eth_link {
>   uint16_t link_speed;  /**< ETH_LINK_SPEED_[10, 100, 1000, 1] */
>   uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX, FULL_DUPLEX]
> */
> - uint8_t  link_status : 1; /**< 1 -> link up, 0 -> link down */
> + uint8_t  link_status : 1; /**< ETH_LINK_[DOWN/UP] */
>  }__attribute__((aligned(8))); /**< aligned for atomic64 read/write */
> 
>  #define ETH_LINK_SPEED_AUTONEG  0   /**< Auto-negotiate link
> speed. */
> @@ -259,9 +259,12 @@ struct rte_eth_link {
>  #define ETH_LINK_SPEED_20G  2   /**< 20 gigabits/second. */
>  #define ETH_LINK_SPEED_40G  4   /**< 40 gigabits/second. */
> 
> +/* Utility constants */
>  #define ETH_LINK_AUTONEG_DUPLEX 0   /**< Auto-negotiate duplex.
> */
>  #define ETH_LINK_HALF_DUPLEX1   /**< Half-duplex connection. */
>  #define ETH_LINK_FULL_DUPLEX2   /**< Full-duplex connection. */
> +#define ETH_LINK_DOWN   0 /**< Link is down. */
> +#define ETH_LINK_UP 1 /**< Link is up. */
I was thinking if there is a link state of ETH_LINK_UNKOWN is needed?
Sometimes, it cannot get the real link status from hardware.
Any comments about this from others?

/Helin

> 
>  /**
>   * A structure used to configure the ring threshold registers of an RX/TX
> --
> 2.7.0

[dpdk-dev] [PATCH v10 0/8] ethdev: 100G and link speed API refactoring

[Matej Vido]

Hi,

patch http://dpdk.org/dev/patchwork/patch/10202/
which was applied to dpdk-next-net/rel_16_04 tree changes filling
of items in rte_eth_link structure for szedata2 driver. These changes
for szedata2 driver are not compliant with changes in this patch series.
I'm not sure how it should be addressed.

Regards,
Matej


D?a 14.03.2016 o 22:55 Thomas Monjalon nap?sal(a):
> Re-spin of the Marc's patchset.
> The first version was sent 10 months ago!
> There are still too few tests and reviews but it is now time to move
> forward with this rework.
> Some issues were remaining in v9 and were difficult to see because it
> was mainly one big patch. That's why I've split it in several steps
> and fixed/reworked some pieces.
> There will be an exception to integrate this feature in 16.04-rc2.
> Please test and review shortly, thanks!
>
> 
>
> This series of patches adds the following capabilities:
>
> * speed_capa bitmap in rte_eth_dev_info, which is filled by the PMDs
>according to the physical device capabilities.
> * refactors link API in ethdev to allow the definition of the advertised
>link speeds, fix speed (no auto-negociation) or advertise all supported
>speeds (default).
>
> WARNING: this patch series, specifically the patch 6/8, is NOT tested for
> most of the drivers.
> Reviewing and testing are required by PMD maintainers.
>
> 
>
> Marc Sune (6):
>ethdev: use constants for link duplex
>app/testpmd: move speed and duplex parsing in a function
>ethdev: rename link speed constants
>ethdev: add speed capabilities
>ethdev: redesign link speed config
>ethdev: convert speed number to bitmap flag
>
> Thomas Monjalon (2):
>ethdev: use constants for link state
>ethdev: add 100G link speed
>
> v10:
>  - rebase
>  - rework release notes
>  - rearrange patch splitting
>  - fix doxygen comments
>  - fix typos
>  - removed log format of link.link_speed as %d (keep %u)
>  - complete ETH_LINK_[DOWN/UP] replacement from 0/1
>  - change ETH_LINK_SPEED_AUTONEG to 1
>  - replace ETH_LINK_SPEED_NEG by ETH_LINK_SPEED_AUTONEG (1)
>  - replace ETH_LINK_SPEED_NO_AUTONEG by ETH_LINK_SPEED_FIXED (0)
>  - rework rte_eth_speed_to_bm_flag to rte_eth_speed_bitflag
>  - complete 100G support in testpmd
>
> v9: rebased to current HEAD. Reverted numeric speed to 32 bit in struct
>  rte_eth_link (no atomic link get > 64bit). Fixed mlx5 driver compilation
>  and link speeds. Moved documentation to release_16_04.rst and fixed 
> several
>  issues. Upgrade NIC notes with speed capabilities.
>
> v8: Rebased to current HEAD. Modified em driver impl. to not touch base files.
>  Merged patch 5 into 3 (map file). Changed numeric speed to a 64 bit 
> value.
>  Filled-in speed capabilities for drivers bnx2x, cxgbe, mlx5 and nfp in
>  addition to the ones of previous patch sets.
>
> v7: Rebased to current HEAD. Moved documentation to v2.3. Still needs testing
>  from PMD maintainers.
>
> v6: Move link_duplex to be part of bitfield. Fixed i40 autoneg flag link
>  update code. Added rte_eth_speed_to_bm_flag() to .map file. Fixed other
>  spelling issues. Rebased to current HEAD.
>
> v5: revert to v2 speed capabilities patch. Fixed MLX4 speed capabilities
>  (thanks N. Laranjeiro). Refactored link speed API to allow setting
>  advertised speeds (3/4). Added NO_AUTONEG option to explicitely disable
>  auto-negociation. Updated 2.2 rel. notes (4/4). Rebased to current HEAD.
>
> v4: fixed errata in the documentation of field speeds of rte_eth_conf, and
>  commit 1/2 message. rebased to v2.1.0. v3 was incorrectly based on
>  ~2.1.0-rc1.
>
> v3: rebase to v2.1. unified ETH_LINK_SPEED and ETH_SPEED_CAP into ETH_SPEED.
>  Converted field speed in struct rte_eth_conf to speed, to allow a bitmap
>  for defining the announced speeds, as suggested M. Brorup. Fixed spelling
>  issues.
>
> v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment
>  (checkpatch).
>
>
>   app/test-pipeline/init.c   |   2 +-
>   app/test-pmd/cmdline.c | 125 
> ++---
>   app/test-pmd/testpmd.c |   2 +-
>   app/test/test_pmd_perf.c   |   2 +-
>   app/test/virtual_pmd.c |   8 +-
>   doc/guides/nics/overview.rst   |   1 +
>   doc/guides/rel_notes/release_16_04.rst |  22 
>   doc/guides/testpmd_app_ug/testpmd_funcs.rst|   2 +-
>   drivers/net/af_packet/rte_eth_af_packet.c  |   9 +-
>   drivers/net/bnx2x/bnx2x_ethdev.c   |   7 +-
>   drivers/net/bnx2x/elink.c  |   2 +-
>   drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 +--
>   drivers/net/bonding/rte_eth_bond_api.c |   4 +-
>   drivers/net/bonding/rte_eth_bond_pmd.c |  12 +-
>   

[dpdk-dev] [PATCH v5 1/2] i40evf: allocate virtchnl cmd buffer for each vf

[Wu, Jingjing]

Hi, Bruce

That is because another patch was applied before this one. I will rework it, 
and send it soon.

Thanks
Jingjing

> -Original Message-
> From: Richardson, Bruce
> Sent: Monday, March 14, 2016 8:22 PM
> To: Wu, Jingjing
> Cc: dev at dpdk.org; Zhang, Helin; Tao, Zhe
> Subject: Re: [PATCH v5 1/2] i40evf: allocate virtchnl cmd buffer for each vf
> 
> On Thu, Mar 10, 2016 at 11:41:10AM +0800, Jingjing Wu wrote:
> > Currently, i40evf PMD uses a global static buffer to send virtchnl
> > command to host driver. It is shared by multi VFs.
> > This patch changed to allocate virtchnl cmd buffer for each VF.
> >
> > Signed-off-by: Jingjing Wu 
> > Acked-by: Helin Zhang 
> > ---
> >  drivers/net/i40e/i40e_ethdev.h|   2 +
> >  drivers/net/i40e/i40e_ethdev_vf.c | 178
> > +++---
> >  2 files changed, 71 insertions(+), 109 deletions(-)
> >
> Hi Jingjing,
> 
> I get some compilation errors when I apply this to dpdk-next-net.
> 
> /home/bruce/next-net/dpdk-next-net/drivers/net/i40e/i40e_ethdev_vf.c:
> In function ?i40evf_add_del_all_mac_addr?:
> /home/bruce/next-net/dpdk-next-
> net/drivers/net/i40e/i40e_ethdev_vf.c:1801:21: error: ?cmd_result_buffer?
> undeclared (first use in this function)
>args.out_buffer = cmd_result_buffer;
> ^
> 
> This is with Fedora 23 with gcc 5.3.1
> 
> /Bruce

[dpdk-dev] [PATCH v3] vhost: Fix default value of kickfd and callfd

[Thomas Monjalon]

2016-03-14 17:12, Yuanhan Liu:
> On Mon, Mar 14, 2016 at 05:53:32PM +0900, Tetsuya Mukawa wrote:
> > Currently, default values of kickfd and callfd are -1.
> > If the values are -1, current code guesses kickfd and callfd haven't
> > been initialized yet. Then vhost library will guess the virtqueue isn't
> > ready for processing.
> > But callfd and kickfd will be set as -1 when "--enable-kvm"
> > isn't specified in QEMU command line. It means we cannot treat -1 as
> > uninitialized state.
> > The patch defines -1 and -2 as VIRTIO_INVALID_EVENTFD and
> > VIRTIO_UNINITIALIZED_EVENTFD, and uses VIRTIO_UNINITIALIZED_EVENTFD for
> > the default values of kickfd and callfd.
> 
> Don't be mean to put an empty line between paragraphs :)
> 
> > Signed-off-by: Tetsuya Mukawa 
> 
> Acked-by: Yuanhan Liu 

Applied, thanks

[dpdk-dev] [PATCH] vhost: remove lockless enqueue to the virtio ring

[Thomas Monjalon]

2016-01-05 07:16, Xie, Huawei:
> On 1/5/2016 2:42 PM, Xie, Huawei wrote:
> > This patch removes the internal lockless enqueue implmentation.
> > DPDK doesn't support receiving/transmitting packets from/to the same
> > queue. Vhost PMD wraps vhost device as normal DPDK port. DPDK
> > applications normally have their own lock implmentation when enqueue
> > packets to the same queue of a port.
> >
> > The atomic cmpset is a costly operation. This patch should help
> > performance a bit.
> >
> > Signed-off-by: Huawei Xie 
> This patch modifies the API's behavior, which is also a trivial ABI
> change. In my opinion, application shouldn't rely on previous behavior.
> Anyway, i am checking how to declare the ABI change.

I guess this patch is now obsolete?

[dpdk-dev] [PATCH v3 0/8] vhost rxtx refactor and fixes

[Thomas Monjalon]

2016-03-10 12:32, Yuanhan Liu:
> v3: - quite few minor changes, including using likely/unlikely
>   when possible.
> 
> - Added a new patch 8 to avoid desc dead loop chain
> 
> The first 3 patches refactor 3 major functions at vhost_rxtx.c.
> It simplifies the code logic, making it more readable. OTOH, it
> reduces binary code size, due to a lot of duplicate code are
> removed, as well as some huge inline functions are diminished.
> 
> Patch 4 gets rid of the rte_memcpy for virtio_hdr copy, which
> nearly saves 12K bytes of binary code size!
> 
> Patch 5 removes "unlikely" for VIRTIO_NET_F_MRG_RXBUF detection.
> 
> Patch 6, 7 and 8 do some sanity check for two desc fields, to make
> vhost robust and be protected from malicious guest or abnormal use
> cases.
> 
> ---
> Yuanhan Liu (8):
>   vhost: refactor rte_vhost_dequeue_burst
>   vhost: refactor virtio_dev_rx
>   vhost: refactor virtio_dev_merge_rx
>   vhost: do not use rte_memcpy for virtio_hdr copy
>   vhost: don't use unlikely for VIRTIO_NET_F_MRG_RXBUF detection
>   vhost: do sanity check for desc->len
>   vhost: do sanity check for desc->next against with vq->size
>   vhost: avoid dead loop chain.

Applied with 3/8 v4, thanks.

[dpdk-dev] [PATCH v5 0/4] Use common Linux tools to control DPDK ports

[Ferruh Yigit]

On 3/14/2016 5:40 PM, Jay Rolette wrote:
> Is there some technical reason or is it just the push-back you are
> getting from some of the maintainers?
> 
The majority of the discussion on the list was based on not having
kernel modules, which cloud the desired technical discussion.

As a result of the opposition, we will give a try to upstreaming and I
will be able to use some of my time to work on this.

If KCP can be upstreamed, this is good for everybody, if not I hope we
can discuss again in community the future of the feature.

And during this process, userspace counterpart in DPDK will be missing,
and kernel part will be in a form of patch for head of latest kernel, so
not sure how community will be able to test this.

> I chimed in on one of the other threads already, but I'm extremely
> disappointed that usability and serviceability improvements to existing
> DPDK capabilities (KNI) are getting blocked like this.
> 
> For companies building network appliances based on DPDK, having a kernel
> module that isn't in the tree just isn't that big of a deal. Long term
> goals for getting this upstream are great, but why not take advantage of
> incremental improvements in the meantime?
> 
> Jay 
> 
> On Mon, Mar 14, 2016 at 10:31 AM, Ferruh Yigit  > wrote:
> 
> On 3/9/2016 11:41 AM, Ferruh Yigit wrote:
> > This patch sent to keep record of latest status of the work.
> >
> >
> > This work is to make DPDK ports more visible and to enable using common
> > Linux tools to configure DPDK ports.
> >
> > Patch is based on KNI but contains only control functionality of it,
> > also this patch does not include any Linux kernel network driver as
> > part of it.
> >
> > Basically with the help of a kernel module (KCP), virtual Linux network
> > interfaces named as "dpdk$" are created per DPDK port, control messages
> > sent to these virtual interfaces are forwarded to DPDK, and response
> > sent back to Linux application.
> >
> > Virtual interfaces created when DPDK application started and destroyed
> > automatically when DPDK application terminated.
> >
> > Communication between kernel-space and DPDK done using netlink socket.
> >
> > In long term this patch intends to replace the KNI and KNI will be
> > depreciated.
> >
> 
> Self-NACK: Will work on netdev to upstream this.
> 
> 

[dpdk-dev] [PATCH] virtio: fix wrong features returned for legacy virtio

[Thomas Monjalon]

2016-03-10 08:43, David Marchand:
> On Thu, Mar 10, 2016 at 8:01 AM, Yuanhan Liu
>  wrote:
> > Declare dst as type uint32_t instead of uint64_t, otherwise, we will get
> > a random upper 32 bit feature bits, as the following io port read reads
> > lower 32 bit only. It could lead a feature bits that include 
> > VIRTIO_F_VERSION_1
> > (the 32th bit) for legacy virtio, which is obviously wrong.
> >
> > Fixes: b8f04520ad71 ("virtio: use PCI ioport API")
> >
> > Cc: David Marchand 
> > Signed-off-by: Yuanhan Liu 
> 
> Argh, good catch.
> Relooked at my patch, this should be the only bug (of this kind ;-)).
> 
> Reviewed-by: David Marchand 

Applied, thanks

[dpdk-dev] [PATCH] cryptodev: fix RTE_PMD_DEBUG_TRACE redefinition

[Marc]

On 10 March 2016 at 19:23, Thomas Monjalon 
wrote:

> 2016-03-03 00:34, Marc Sune:
> > RTE_PMD_DEBUG_TRACE used RTE_FUNC_PTR_OR_ERR_RET was redefined
> > in rte_cryptodev_pmd.h which produced MACRO redefinition warnings
> > when including both rte_cryptodev_pmd.h and rte_ethdev.h.
> >
> > This commit moves MACRO definition to rte_cryptodev.c to prevent
> > this warning.
>
> It is not the right fix.
>

This MACRO is only used in that .c file, so it actually makes sense not to
be defined in the header file.


>
> This macro should probably be renamed with a crypto prefix or defined
> only once (same thing for ethdev).
> The function rte_pmd_debug_trace() and the macros
> RTE_PROC_PRIMARY_OR_ERR_RET,
> RTE_PROC_PRIMARY_OR_RET,
> RTE_FUNC_PTR_OR_ERR_RET,
> RTE_FUNC_PTR_OR_RET
> should not be in lib/librte_eal/common/include/rte_dev.h.
> The macros call RTE_PMD_DEBUG_TRACE which is defined elsewhere.
> The rte_log.h is probably a better place.
> But why these macros have no PMD prefix?
>

While I agree, this patch is only trying to solve the compilation error,
which I think it is a step forward from what we have now. I am working on
C++ linking automated test and I could not include both files in the test.

Marc