[dpdk-dev] [PATCH v2] virtio: use zeroed memory for simple TX header
For simple TX the virtio-net header must be zeroed, but it was using memory that had been initialized with indirect descriptor tables. This resulted in "unsupported gso type" errors from librte_vhost. We can use the same memory for every descriptor to save cachelines in the vswitch. Fixes: 6dc5de3a (virtio: use indirect ring elements) Signed-off-by: Rich Lane --- v1-v2: - Use offsetof to get address of tx_hdr drivers/net/virtio/virtio_rxtx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c index 2b88efd..ef21d8e 100644 --- a/drivers/net/virtio/virtio_rxtx.c +++ b/drivers/net/virtio/virtio_rxtx.c @@ -377,7 +377,7 @@ virtio_dev_vring_start(struct virtqueue *vq, int queue_type) vq->vq_ring.desc[i + mid_idx].next = i; vq->vq_ring.desc[i + mid_idx].addr = vq->virtio_net_hdr_mem + - i * vq->hw->vtnet_hdr_size; + offsetof(struct virtio_tx_region, tx_hdr); vq->vq_ring.desc[i + mid_idx].len = vq->hw->vtnet_hdr_size; vq->vq_ring.desc[i + mid_idx].flags = -- 1.9.1
[dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz Kulasek
> Sent: Monday, April 04, 2016 3:45 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
>
> It seems that with gcc >5.x and -O2/-O3 optimization breaks packet grouping
> algorithm.
>
> When last packet pointer "lp" and "pnum->u64" buffer points the same
> memory buffer, high optimization can cause unpredictable results. It seems
> that assignment of precalculated group sizes may interfere with
> initialization of new group size when lp points value inside current group
> and didn't should be changed.
>
> With gcc >5.x and optimization we cannot be sure which assignment will be
> done first, so the group size can be counted incorrectly.
>
> This patch eliminates intersection of assignment of initial group size
> (lp[0] = 1) and precalculated group sizes when gptbl[v].idx < 4.
>
> Fixes: 94c54b4158d5 ("examples/l3fwd: rework exact-match")
>
> Signed-off-by: Tomasz Kulasek
> ---
> examples/l3fwd/l3fwd_sse.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/examples/l3fwd/l3fwd_sse.h b/examples/l3fwd/l3fwd_sse.h
> index f9cf50a..1afa1f0 100644
> --- a/examples/l3fwd/l3fwd_sse.h
> +++ b/examples/l3fwd/l3fwd_sse.h
> @@ -283,9 +283,9 @@ port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t *lp,
> __m128i dp1, __m128i dp2)
>
> /* if dest port value has changed. */
> if (v != GRPMSK) {
> - lp = pnum->u16 + gptbl[v].idx;
> - lp[0] = 1;
> pnum->u64 = gptbl[v].pnum;
> + pnum->u16[FWDSTEP] = 1;
> + lp = pnum->u16 + gptbl[v].idx;
> }
>
> return lp;
> --
Acked-by: Konstantin Ananyev
> 1.7.9.5
[dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
> -Original Message-
> From: Kulasek, TomaszX
> Sent: Monday, April 04, 2016 5:20 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
>
> Hi Konstantin,
>
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Monday, April 4, 2016 17:35
> > To: Kulasek, TomaszX
> > Cc: dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
> >
> > Hi Tomasz,
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz Kulasek
> > > Sent: Monday, April 04, 2016 3:45 PM
> > > To: dev at dpdk.org
> > > Subject: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
> > >
> > > It seems that with gcc >5.x and -O2/-O3 optimization breaks packet
> > > grouping algorithm.
> > >
> > > When last packet pointer "lp" and "pnum->u64" buffer points the same
> > > memory buffer, high optimization can cause unpredictable results. It
> > > seems that assignment of precalculated group sizes may interfere with
> > > initialization of new group size when lp points value inside current
> > > group and didn't should be changed.
> > >
> > > With gcc >5.x and optimization we cannot be sure which assignment will
> > > be done first, so the group size can be counted incorrectly.
> > >
> > > This patch eliminates intersection of assignment of initial group size
> > > (lp[0] = 1) and precalculated group sizes when gptbl[v].idx < 4.
> > >
> > > Fixes: 94c54b4158d5 ("examples/l3fwd: rework exact-match")
> > >
> > > Signed-off-by: Tomasz Kulasek
> > > ---
> > > examples/l3fwd/l3fwd_sse.h |4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/examples/l3fwd/l3fwd_sse.h b/examples/l3fwd/l3fwd_sse.h
> > > index f9cf50a..1afa1f0 100644
> > > --- a/examples/l3fwd/l3fwd_sse.h
> > > +++ b/examples/l3fwd/l3fwd_sse.h
> > > @@ -283,9 +283,9 @@ port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t
> > > *lp, __m128i dp1, __m128i dp2)
> > >
> > > /* if dest port value has changed. */
> > > if (v != GRPMSK) {
> > > - lp = pnum->u16 + gptbl[v].idx;
> > > - lp[0] = 1;
> > > pnum->u64 = gptbl[v].pnum;
> > > + pnum->u16[FWDSTEP] = 1;
> >
> > Hmm, but FWDSTEP and gptbl[v].idx are not always equal.
> > Actually could you explain a bit more - what exactly is reordered by gcc
> > 5.x, and how to reproduce it?
> > i.e what sequence of input packets will trigger an error?
> > Konstantin
> >
> > > + lp = pnum->u16 + gptbl[v].idx;
> > > }
> > >
> > > return lp;
> > > --
> > > 1.7.9.5
>
>
> Eg. For this case, when group is changed:
>
> {
> /* 0xb: a == b, b == c, c != d, d == e */
> .pnum = UINT64_C(0x0002000100020003),
> .idx = 3,
> .lpv = 2,
> },
>
> We expect:
>
> pnum->u16 = { 3, 2, 1, 2, x }
> lp = pnum->u16 + 3;
> // should be lp[0] == 2
>
> but for gcc 5.2
>
> lp = pnum->u16 + gptbl[v].idx;
> lp[0] = 1;
> pnum->u64 = gptbl[v].pnum;
>
> gives, for some reason lp[0] == 1, even if pnum->u16[3] == 2.
>
> It causes, that group is shorter and fails trying to send next group with
> messy length.
>
> We should set lp[0] = 1 only when needed (gptbl[v].idx == 4), so this is why
> I set pnum->u16[4] = 1. I set it up always to prevent
> condition. For idx < 4 we don't need to set lp[0].
>
> The problem is that both pointers operates on the same memory buffer and, it
> seems like gcc optimization will produce (it is wrong):
>
> lp = pnum->u16 + gptbl[v].idx;
> pnum->u64 = gptbl[v].pnum;
> lp[0] = 1;
>
> except:
>
> lp = pnum->u16 + gptbl[v].idx;
> lp[0] = 1;
> pnum->u64 = gptbl[v].pnum;
>
> This issue is with gcc 5.x and application seems to fail for the patterns
> where gptbl[v].idx < 4.
Thanks for explanation Tomasz.
So it reordered:
lp[0] = 1;
pnum->u64 = gptbl[v].pnum;
correct?
My first thought was to insert a rte_complier_barrier() between these two lines,
but actually your approach looks cleaner.
Konstantin
[dpdk-dev] [PATCH] ixgbe: cleanup whitespace and formatting issues
On Tue, 5 Apr 2016 00:57:16 + "Lu, Wenzhuo" wrote: > Hi Stephen, > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger > > Sent: Tuesday, April 5, 2016 12:14 AM > > To: Zhang, Helin; Ananyev, Konstantin > > Cc: dev at dpdk.org; Stephen Hemminger > > Subject: [dpdk-dev] [PATCH] ixgbe: cleanup whitespace and formatting issues > > > > This driver was one of the originals and has lots of little whitespace > > issues. > > > > PS: I know Intel doesn't like whitespace changes, there is never a good time > > to do this, but no resuliting binary changes and it is unlikely that more > > changes to this driver will occur this late in release cycle. > > > > Signed-off-by: Stephen Hemminger > Thanks for this patch. I think it's good to make the format better :) > But there's some checkpatch error and warnings, like this, > ERROR: "foo* bar" should be "foo *bar" > #508: FILE: drivers/net/ixgbe/ixgbe_ethdev.c:4256: > +ixgbe_uc_hash_table_set(struct rte_eth_dev *dev, struct ether_addr* mac_addr, > I didn't fix all the checkpatch errors, just the easy ones.
[dpdk-dev] [PATCH v2 2/2] mempool: use bit flags instead of is_mp and is_mc
Pass the same flags as in rte_mempool_create().
Signed-off-by: Lazaros Koromilas
---
app/test/test_mempool.c | 18 +--
app/test/test_mempool_perf.c | 4 +--
lib/librte_mempool/rte_mempool.h | 66 +---
3 files changed, 45 insertions(+), 43 deletions(-)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 2dc0cf2..445f450 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -121,7 +121,7 @@ test_mempool_basic(void)
rte_mempool_dump(stdout, mp);
printf("get an object\n");
- if (rte_mempool_generic_get(mp, , 1, cache, 1) < 0)
+ if (rte_mempool_generic_get(mp, , 1, cache, 0) < 0)
return -1;
rte_mempool_dump(stdout, mp);
@@ -149,21 +149,21 @@ test_mempool_basic(void)
return -1;
printf("put the object back\n");
- rte_mempool_generic_put(mp, , 1, cache, 1);
+ rte_mempool_generic_put(mp, , 1, cache, 0);
rte_mempool_dump(stdout, mp);
printf("get 2 objects\n");
- if (rte_mempool_generic_get(mp, , 1, cache, 1) < 0)
+ if (rte_mempool_generic_get(mp, , 1, cache, 0) < 0)
return -1;
- if (rte_mempool_generic_get(mp, , 1, cache, 1) < 0) {
- rte_mempool_generic_put(mp, , 1, cache, 1);
+ if (rte_mempool_generic_get(mp, , 1, cache, 0) < 0) {
+ rte_mempool_generic_put(mp, , 1, cache, 0);
return -1;
}
rte_mempool_dump(stdout, mp);
printf("put the objects back\n");
- rte_mempool_generic_put(mp, , 1, cache, 1);
- rte_mempool_generic_put(mp, , 1, cache, 1);
+ rte_mempool_generic_put(mp, , 1, cache, 0);
+ rte_mempool_generic_put(mp, , 1, cache, 0);
rte_mempool_dump(stdout, mp);
/*
@@ -176,7 +176,7 @@ test_mempool_basic(void)
}
for (i=0; iring);
@@ -187,7 +187,7 @@ per_lcore_mempool_test(__attribute__((unused)) void *arg)
while (idx < n_keep) {
rte_mempool_generic_put(mp, _table[idx],
n_put_bulk,
- cache, 1);
+ cache, 0);
idx += n_put_bulk;
}
}
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 21d43e2..fe4fed9 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -812,12 +812,13 @@ rte_mempool_default_cache(struct rte_mempool *mp,
unsigned lcore_id)
* positive.
* @param cache
* A pointer to a mempool cache structure. May be NULL if not needed.
- * @param is_mp
- * Mono-producer (0) or multi-producers (1).
+ * @param flags
+ * The flags used for the mempool creation.
+ * Single-producer (MEMPOOL_F_SP_PUT flag) or multi-producers.
*/
static inline void __attribute__((always_inline))
__mempool_generic_put(struct rte_mempool *mp, void * const *obj_table,
- unsigned n, struct rte_mempool_cache *cache, int is_mp)
+ unsigned n, struct rte_mempool_cache *cache, int flags)
{
uint32_t index;
void **cache_objs;
@@ -826,7 +827,8 @@ __mempool_generic_put(struct rte_mempool *mp, void * const
*obj_table,
__MEMPOOL_STAT_ADD(mp, put, n);
/* No cache provided or cache is not enabled or single producer */
- if (unlikely(cache == NULL || cache->size == 0 || is_mp == 0))
+ if (unlikely(cache == NULL || cache->size == 0 ||
+flags & MEMPOOL_F_SP_PUT))
[dpdk-dev] [PATCH v2 1/2] mempool: allow for user-owned mempool caches
The mempool cache is only available to EAL threads as a per-lcore
resource. Change this so that the user can create and provide their own
cache on mempool get and put operations. This works with non-EAL threads
too. This commit introduces the new API calls:
rte_mempool_cache_create(size, socket_id)
rte_mempool_cache_flush(cache, mp)
rte_mempool_cache_free(cache)
rte_mempool_default_cache(mp, lcore_id)
rte_mempool_generic_put(mp, obj_table, n, cache, is_mp)
rte_mempool_generic_get(mp, obj_table, n, cache, is_mc)
Removes the API calls:
rte_mempool_sp_put_bulk(mp, obj_table, n)
rte_mempool_sc_get_bulk(mp, obj_table, n)
rte_mempool_sp_put(mp, obj)
rte_mempool_sc_get(mp, obj)
And the remaining API calls use the per-lcore default local cache:
rte_mempool_put_bulk(mp, obj_table, n)
rte_mempool_get_bulk(mp, obj_table, n)
rte_mempool_put(mp, obj)
rte_mempool_get(mp, obj)
Signed-off-by: Lazaros Koromilas
---
app/test/test_mempool.c| 58 +--
app/test/test_mempool_perf.c | 46 +-
lib/librte_eal/common/eal_common_log.c | 8 +-
lib/librte_mempool/rte_mempool.c | 76 -
lib/librte_mempool/rte_mempool.h | 291 +
5 files changed, 275 insertions(+), 204 deletions(-)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 10e1fa4..2dc0cf2 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -79,6 +79,7 @@
static struct rte_mempool *mp;
static struct rte_mempool *mp_cache, *mp_nocache;
+static int use_external_cache;
static rte_atomic32_t synchro;
@@ -107,19 +108,33 @@ test_mempool_basic(void)
char *obj_data;
int ret = 0;
unsigned i, j;
+ struct rte_mempool_cache *cache;
+
+ if (use_external_cache)
+ /* Create a user-owned mempool cache. */
+ cache = rte_mempool_cache_create(RTE_MEMPOOL_CACHE_MAX_SIZE,
+SOCKET_ID_ANY);
+ else
+ cache = rte_mempool_default_cache(mp, rte_lcore_id());
/* dump the mempool status */
rte_mempool_dump(stdout, mp);
printf("get an object\n");
- if (rte_mempool_get(mp, ) < 0)
+ if (rte_mempool_generic_get(mp, , 1, cache, 1) < 0)
return -1;
rte_mempool_dump(stdout, mp);
/* tests that improve coverage */
printf("get object count\n");
- if (rte_mempool_count(mp) != MEMPOOL_SIZE - 1)
- return -1;
+ if (use_external_cache) {
+ /* We have to count the extra caches, one in this case. */
+ if (rte_mempool_count(mp) + cache->len != MEMPOOL_SIZE - 1)
+ return -1;
+ } else {
+ if (rte_mempool_count(mp) != MEMPOOL_SIZE - 1)
+ return -1;
+ }
printf("get private data\n");
if (rte_mempool_get_priv(mp) != (char *)mp +
@@ -134,21 +149,21 @@ test_mempool_basic(void)
return -1;
printf("put the object back\n");
- rte_mempool_put(mp, obj);
+ rte_mempool_generic_put(mp, , 1, cache, 1);
rte_mempool_dump(stdout, mp);
printf("get 2 objects\n");
- if (rte_mempool_get(mp, ) < 0)
+ if (rte_mempool_generic_get(mp, , 1, cache, 1) < 0)
return -1;
- if (rte_mempool_get(mp, ) < 0) {
- rte_mempool_put(mp, obj);
+ if (rte_mempool_generic_get(mp, , 1, cache, 1) < 0) {
+ rte_mempool_generic_put(mp, , 1, cache, 1);
return -1;
}
rte_mempool_dump(stdout, mp);
printf("put the objects back\n");
- rte_mempool_put(mp, obj);
- rte_mempool_put(mp, obj2);
+ rte_mempool_generic_put(mp, , 1, cache, 1);
+ rte_mempool_generic_put(mp, , 1, cache, 1);
rte_mempool_dump(stdout, mp);
/*
@@ -161,7 +176,7 @@ test_mempool_basic(void)
}
for (i=0; i
[dpdk-dev] [PATCH] autotests: fix eal flags test
Since commit a88ba49e51, values larger than 4 are allowed,
the autotests need to be updated accordingly.
Fixes: a88ba49e51 ("config: fix CPU and memory parameters on IBM POWER8")
Signed-off-by: Olivier Matz
---
app/test/test_eal_flags.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index d9c0d93..93ae6e7 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -698,8 +698,8 @@ test_invalid_n_flag(void)
const char *argv1[] = { prgname, prefix, no_huge, no_shconf, "-c", "1",
"-n"};
/* bad numeric value */
const char *argv2[] = { prgname, prefix, no_huge, no_shconf, "-c", "1",
"-n", "e" };
- /* out-of-range value */
- const char *argv3[] = { prgname, prefix, no_huge, no_shconf, "-c", "1",
"-n", "9" };
+ /* zero is invalid */
+ const char *argv3[] = { prgname, prefix, no_huge, no_shconf, "-c", "1",
"-n", "0" };
/* sanity test - check with good value */
const char *argv4[] = { prgname, prefix, no_huge, no_shconf, "-c", "1",
"-n", "2" };
/* sanity test - check with no -n flag */
--
2.1.4
[dpdk-dev] [PATCH] cryptodev: renaming 2 elements for clarity
renamed rte_cryptodev_sym_session.type -> dev_type
(as it's not a session type, but a device type)
renamed rte_crypto_sym_op.type -> sess_type
(as it's not an op type, but a session type)
Signed-off-by: Fiona Trahe
---
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 7 ---
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 6 +++---
drivers/crypto/null/null_crypto_pmd.c | 4 ++--
drivers/crypto/qat/qat_crypto.c| 4 ++--
drivers/crypto/snow3g/rte_snow3g_pmd.c | 6 +++---
lib/librte_cryptodev/rte_crypto_sym.h | 6 +++---
lib/librte_cryptodev/rte_cryptodev.c | 4 ++--
lib/librte_cryptodev/rte_cryptodev.h | 2 +-
8 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 35577bc..2987ef6 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -180,8 +180,9 @@ aesni_gcm_get_session(struct aesni_gcm_qp *qp, struct
rte_crypto_sym_op *op)
{
struct aesni_gcm_session *sess = NULL;
- if (op->type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
- if (unlikely(op->session->type != RTE_CRYPTODEV_AESNI_GCM_PMD))
+ if (op->sess_type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
+ if (unlikely(op->session->dev_type
+ != RTE_CRYPTODEV_AESNI_GCM_PMD))
return sess;
sess = (struct aesni_gcm_session *)op->session->_private;
@@ -339,7 +340,7 @@ handle_completed_gcm_crypto_op(struct aesni_gcm_qp *qp,
post_process_gcm_crypto_op(op);
/* Free session if a session-less crypto op */
- if (op->sym->type == RTE_CRYPTO_SYM_OP_SESSIONLESS) {
+ if (op->sym->sess_type == RTE_CRYPTO_SYM_OP_SESSIONLESS) {
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index a4b8807..3415ac1 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -299,8 +299,8 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op
*op)
{
struct aesni_mb_session *sess = NULL;
- if (op->sym->type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
- if (unlikely(op->sym->session->type !=
+ if (op->sym->sess_type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
+ if (unlikely(op->sym->session->dev_type !=
RTE_CRYPTODEV_AESNI_MB_PMD))
return NULL;
@@ -475,7 +475,7 @@ post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC
*job)
}
/* Free session if a session-less crypto op */
- if (op->sym->type == RTE_CRYPTO_SYM_OP_SESSIONLESS) {
+ if (op->sym->sess_type == RTE_CRYPTO_SYM_OP_SESSIONLESS) {
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/null/null_crypto_pmd.c
b/drivers/crypto/null/null_crypto_pmd.c
index 82b990c..bdaf13c 100644
--- a/drivers/crypto/null/null_crypto_pmd.c
+++ b/drivers/crypto/null/null_crypto_pmd.c
@@ -114,9 +114,9 @@ get_session(struct null_crypto_qp *qp, struct
rte_crypto_sym_op *op)
{
struct null_crypto_session *sess;
- if (op->type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
+ if (op->sess_type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
if (unlikely(op->session == NULL ||
- op->session->type != RTE_CRYPTODEV_NULL_PMD))
+op->session->dev_type != RTE_CRYPTODEV_NULL_PMD))
return NULL;
sess = (struct null_crypto_session *)op->session->_private;
diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index 45bb8b3..495ea1c 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -676,13 +676,13 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t
*out_msg)
return -EINVAL;
}
#endif
- if (unlikely(op->sym->type == RTE_CRYPTO_SYM_OP_SESSIONLESS)) {
+ if (unlikely(op->sym->sess_type == RTE_CRYPTO_SYM_OP_SESSIONLESS)) {
PMD_DRV_LOG(ERR, "QAT PMD only supports session oriented"
" requests, op (%p) is sessionless.", op);
return -EINVAL;
}
- if (unlikely(op->sym->session->type != RTE_CRYPTODEV_QAT_SYM_PMD)) {
+ if (unlikely(op->sym->session->dev_type != RTE_CRYPTODEV_QAT_SYM_PMD)) {
PMD_DRV_LOG(ERR, "Session was not created for this device");
return -EINVAL;
}
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c
b/drivers/crypto/snow3g/rte_snow3g_pmd.c
index 97c7fb5..f3e0e66 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
@@ -162,8 +162,8 @@
[dpdk-dev] [PATCH v1 1/1] cmdline: add any multi string mode to token string
Hi Piotr, On 04/04/2016 04:11 PM, Azarewicz, PiotrX T wrote: >> Using token_len + 1 as the buffer size in the snprintf looks a bit >> dangerous, as >> it won't protect from overflows. >> >> See the following example: > > > That's why snprintf() should still use STR_TOKEN_SIZE. >> > Okay, I see it. > But this is a problem that we may need longer string than STR_TOKEN_SIZE in > multi token case. > So what you think about adding new typedef cmdline_multi_string_t for this > case? > For example: > #define STR_MULTI_TOKEN_SIZE 1024 > typedef char cmdline_multi_string_t[STR_MULTI_TOKEN_SIZE]; It should do the job, indeed. By the way, it would be nice to have an example of use. Regards, Olivier
[dpdk-dev] [PATCH] xstats: fix behavior when a null array is provided
Coverity reports an issue in ethdev:
*** CID 124562: Null pointer dereferences (FORWARD_NULL)
/lib/librte_ether/rte_ethdev.c: 1518 in rte_eth_xstats_get()
1512
1513 /* global stats */
1514 for (i = 0; i < RTE_NB_STATS; i++) {
1515 stats_ptr = RTE_PTR_ADD(_stats,
1516
rte_stats_strings[i].offset);
1517 val = *stats_ptr;
>>> CID 124562: Null pointer dereferences (FORWARD_NULL)
>>> Dereferencing null pointer "xstats".
1518 snprintf(xstats[count].name,
sizeof(xstats[count].name),
1519 "%s", rte_stats_strings[i].name);
1520xstats[count++].value = val;
1521}
1522
1523 /* per-rxq stats */
If a user calls rte_eth_xstats_get(portid, NULL, n) with n != 0,
it may result in a crash. Although the API documentation says that
n is the size of the table and xstats can be NULL if n == 0, we
can add an additional check here to make Coverity happy.
In that case, the return value is the same than when n == 0 is
passed, it returns the number of statistics.
Fixes: ce757f5c9a ("ethdev: new method to retrieve extended statistics")
Signed-off-by: Olivier Matz
---
lib/librte_ether/rte_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 76a30fd..60d2573 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1503,7 +1503,7 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstats
*xstats,
return xcount;
}
- if (n < count + xcount)
+ if (n < count + xcount || xstats == NULL)
return count + xcount;
/* now fill the xstats structure */
--
2.1.4
[dpdk-dev] [PATCH] doc: add mempool mgr ABI deprication notice
> >> > Announce the ABI breakage due to addition of external mempool > >> > manager functionality which requires changes to rte_mempool > >> > structure. > >> > > >> > Signed-off-by: David Hunt > >> > >> Acked-by: Olivier Matz > >> > >Acked-by: Bruce Richardson > > Acked-by: John McNamara > Asked-by: Keith Wiles Assumed it is an ack. Applied, thanks
[dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
It seems that with gcc >5.x and -O2/-O3 optimization breaks packet grouping
algorithm.
When last packet pointer "lp" and "pnum->u64" buffer points the same
memory buffer, high optimization can cause unpredictable results. It seems
that assignment of precalculated group sizes may interfere with
initialization of new group size when lp points value inside current group
and didn't should be changed.
With gcc >5.x and optimization we cannot be sure which assignment will be
done first, so the group size can be counted incorrectly.
This patch eliminates intersection of assignment of initial group size
(lp[0] = 1) and precalculated group sizes when gptbl[v].idx < 4.
Fixes: 94c54b4158d5 ("examples/l3fwd: rework exact-match")
Signed-off-by: Tomasz Kulasek
---
examples/l3fwd/l3fwd_sse.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/l3fwd/l3fwd_sse.h b/examples/l3fwd/l3fwd_sse.h
index f9cf50a..1afa1f0 100644
--- a/examples/l3fwd/l3fwd_sse.h
+++ b/examples/l3fwd/l3fwd_sse.h
@@ -283,9 +283,9 @@ port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t *lp,
__m128i dp1, __m128i dp2)
/* if dest port value has changed. */
if (v != GRPMSK) {
- lp = pnum->u16 + gptbl[v].idx;
- lp[0] = 1;
pnum->u64 = gptbl[v].pnum;
+ pnum->u16[FWDSTEP] = 1;
+ lp = pnum->u16 + gptbl[v].idx;
}
return lp;
--
1.7.9.5
[dpdk-dev] [PATCH] doc: mempool ABI deprecation notice for 16.07
2016-03-17 10:05, Olivier Matz: > Add a deprecation notice for coming changes in mempool for 16.07. [...] > +* librte_mempool: new fixes and features will be added in 16.07: > + allocation of large mempool in several virtual memory chunks, new API > + to populate a mempool, new API to free a mempool, allocation in > + anonymous mapping, drop of specific dom0 code. These changes will > + induce a modification of the rte_mempool structure, plus a > + modification of the API of rte_mempool_obj_iter(), implying a breakage > + of the ABI. Acked-by: Thomas Monjalon Other people involved in the discussion wanting to bring their support?
[dpdk-dev] [PATCH] doc: deprecation notice in 16.04 for rte_mempool changes
> >> Deprecation notice for 16.04 for changes to occur in > >> release 16.07 for rte_mempool memory reduction. > >> > >> Signed-off-by: Keith Wiles > > Acked-by: Olivier Matz > Acked-by: David Hunt > Acked-by: John McNamara Applied, thanks.
[dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
Hi Konstantin,
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Monday, April 4, 2016 17:35
> To: Kulasek, TomaszX
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
>
> Hi Tomasz,
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz Kulasek
> > Sent: Monday, April 04, 2016 3:45 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
> >
> > It seems that with gcc >5.x and -O2/-O3 optimization breaks packet
> > grouping algorithm.
> >
> > When last packet pointer "lp" and "pnum->u64" buffer points the same
> > memory buffer, high optimization can cause unpredictable results. It
> > seems that assignment of precalculated group sizes may interfere with
> > initialization of new group size when lp points value inside current
> > group and didn't should be changed.
> >
> > With gcc >5.x and optimization we cannot be sure which assignment will
> > be done first, so the group size can be counted incorrectly.
> >
> > This patch eliminates intersection of assignment of initial group size
> > (lp[0] = 1) and precalculated group sizes when gptbl[v].idx < 4.
> >
> > Fixes: 94c54b4158d5 ("examples/l3fwd: rework exact-match")
> >
> > Signed-off-by: Tomasz Kulasek
> > ---
> > examples/l3fwd/l3fwd_sse.h |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/examples/l3fwd/l3fwd_sse.h b/examples/l3fwd/l3fwd_sse.h
> > index f9cf50a..1afa1f0 100644
> > --- a/examples/l3fwd/l3fwd_sse.h
> > +++ b/examples/l3fwd/l3fwd_sse.h
> > @@ -283,9 +283,9 @@ port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t
> > *lp, __m128i dp1, __m128i dp2)
> >
> > /* if dest port value has changed. */
> > if (v != GRPMSK) {
> > - lp = pnum->u16 + gptbl[v].idx;
> > - lp[0] = 1;
> > pnum->u64 = gptbl[v].pnum;
> > + pnum->u16[FWDSTEP] = 1;
>
> Hmm, but FWDSTEP and gptbl[v].idx are not always equal.
> Actually could you explain a bit more - what exactly is reordered by gcc
> 5.x, and how to reproduce it?
> i.e what sequence of input packets will trigger an error?
> Konstantin
>
> > + lp = pnum->u16 + gptbl[v].idx;
> > }
> >
> > return lp;
> > --
> > 1.7.9.5
Eg. For this case, when group is changed:
{
/* 0xb: a == b, b == c, c != d, d == e */
.pnum = UINT64_C(0x0002000100020003),
.idx = 3,
.lpv = 2,
},
We expect:
pnum->u16 = { 3, 2, 1, 2, x }
lp = pnum->u16 + 3;
// should be lp[0] == 2
but for gcc 5.2
lp = pnum->u16 + gptbl[v].idx;
lp[0] = 1;
pnum->u64 = gptbl[v].pnum;
gives, for some reason lp[0] == 1, even if pnum->u16[3] == 2.
It causes, that group is shorter and fails trying to send next group with messy
length.
We should set lp[0] = 1 only when needed (gptbl[v].idx == 4), so this is why I
set pnum->u16[4] = 1. I set it up always to prevent condition. For idx < 4 we
don't need to set lp[0].
The problem is that both pointers operates on the same memory buffer and, it
seems like gcc optimization will produce (it is wrong):
lp = pnum->u16 + gptbl[v].idx;
pnum->u64 = gptbl[v].pnum;
lp[0] = 1;
except:
lp = pnum->u16 + gptbl[v].idx;
lp[0] = 1;
pnum->u64 = gptbl[v].pnum;
This issue is with gcc 5.x and application seems to fail for the patterns where
gptbl[v].idx < 4.
Tomasz
[dpdk-dev] [PATCH] gcc compiler option -Og warnings fix
2016-04-01 14:20, Keith Wiles:
> The new compiler option -Og causes a few warning on variables
> being used before being set warnings.
Sometimes the compiler is wrong. It seems this option makes it
even wronger. Why not use -Wno-error with -Og?
More details below:
> lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 2 +-
> lib/librte_lpm/rte_lpm6.c | 1 +
> lib/librte_vhost/vhost_rxtx.c | 4 ++--
There are also some warnings in mlx drivers, solved with patch below:
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5415,7 +5415,7 @@ mlx4_pci_devinit(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
int err = 0;
struct ibv_context *attr_ctx = NULL;
struct ibv_device_attr device_attr;
- unsigned int vf;
+ unsigned int vf = 0;
int idx;
int i;
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -260,8 +260,8 @@ mlx5_pci_devinit(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
int err = 0;
struct ibv_context *attr_ctx = NULL;
struct ibv_device_attr device_attr;
- unsigned int vf;
- unsigned int mps;
+ unsigned int vf = 0;
+ unsigned int mps = 0;
int idx;
int i;
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> @@ -152,7 +152,7 @@ pci_get_uio_dev(struct rte_pci_device *dev, char *dstbuf,
> unsigned int buflen, int create)
> {
> struct rte_pci_addr *loc = >addr;
> - unsigned int uio_num;
> + unsigned int uio_num = 0;
This one is OK to fix.
> --- a/lib/librte_lpm/rte_lpm6.c
> +++ b/lib/librte_lpm/rte_lpm6.c
> @@ -381,6 +381,7 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry
> *tbl,
> int8_t bitshift;
> uint8_t bits_covered;
>
> + *tbl_next = NULL;
> /*
>* Calculate index to the table based on the number and position
>* of the bytes being inspected in this step.
It would be more logical to set this variable in the right condition branch:
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -429,6 +429,7 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry
*tbl,
}
}
+ *tbl_next = NULL;
return 0;
}
> --- a/lib/librte_vhost/vhost_rxtx.c
> +++ b/lib/librte_vhost/vhost_rxtx.c
> @@ -295,7 +295,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
> for (i = 0; i < count; i++) {
> uint16_t desc_idx = desc_indexes[i];
> uint16_t used_idx = (res_start_idx + i) & (vq->size - 1);
> - uint32_t copied;
> + uint32_t copied = 0;
This variable is not used if copy_mbuf_to_desc fails, so it is always
initialised before being used.
We can workaround the silly compiler while avoiding a performance hit
by resetting the variable only in the error case of copy_mbuf_to_desc:
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -147,8 +147,10 @@ copy_mbuf_to_desc(struct virtio_net *dev, struct
vhost_virtqueue *vq,
struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0};
desc = >desc[desc_idx];
- if (unlikely(desc->len < vq->vhost_hlen))
+ if (unlikely(desc->len < vq->vhost_hlen)) {
+ *copied = 0;
return -1;
+ }
> err = copy_mbuf_to_desc(dev, vq, pkts[i], desc_idx, );
> @@ -531,7 +531,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t
> queue_id,
> {
> struct vhost_virtqueue *vq;
> uint32_t pkt_idx = 0, nr_used = 0;
> - uint16_t start, end;
> + uint16_t start = 0, end = 0;
I don't understand this one because the variables are not used if
reserve_avail_buf_mergeable fails.
I don't see any smart workaround.
Huawei, Yuanhan, can we expect a little slowdown with this change?
[dpdk-dev] [PATCH] virtio: use zeroed memory for simple TX header
On Mon, Apr 4, 2016 at 1:05 PM, Yuanhan Liu wrote: > On Mon, Apr 04, 2016 at 03:13:37PM +0200, Thomas Monjalon wrote: > > Huawei, Yuanhan, any comment? > > > > 2016-03-31 13:01, Rich Lane: > > > vq->vq_ring.desc[i + mid_idx].next = i; > > > vq->vq_ring.desc[i + mid_idx].addr = > > > - vq->virtio_net_hdr_mem + > > > - i * vq->hw->vtnet_hdr_size; > > > + vq->virtio_net_hdr_mem; > > I could be wrong, but this looks like a special case when i == 0, > which is by no way that zeroed memory is guaranteed? Huawei, do > you have time to check this patch? This bug exists because the type of the objects pointed to by virtio_net_hdr_mem changed in 6dc5de3a (virtio: use indirect ring elements), but because it isn't a C pointer the compiler didn't catch the type mismatch. We could also fix it with: vq->virtio_net_hdr_mem + i * sizeof(struct virtio_tx_region) + offsetof(struct virtio_tx_region, tx_hdr) Given that tx_hdr is the first member in struct virtio_tx_region, and using a single header optimizes cache use, that simplifies to the code in my patch. The virtio-net header is never written to by simple TX so it remains zeroed. I can respin the patch using offsetof if that's preferred. Note that right now virtio simple TX is broken with DPDK vhost due to the flood of error messages.
[dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev,
> Konstantin
> Sent: Monday, April 04, 2016 4:35 PM
> To: Kulasek, TomaszX
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
>
> Hi Tomasz,
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz Kulasek
> > Sent: Monday, April 04, 2016 3:45 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
> >
> > It seems that with gcc >5.x and -O2/-O3 optimization breaks packet
> grouping
> > algorithm.
> >
> > When last packet pointer "lp" and "pnum->u64" buffer points the same
> > memory buffer, high optimization can cause unpredictable results. It seems
> > that assignment of precalculated group sizes may interfere with
> > initialization of new group size when lp points value inside current group
> > and didn't should be changed.
> >
> > With gcc >5.x and optimization we cannot be sure which assignment will be
> > done first, so the group size can be counted incorrectly.
> >
> > This patch eliminates intersection of assignment of initial group size
> > (lp[0] = 1) and precalculated group sizes when gptbl[v].idx < 4.
> >
> > Fixes: 94c54b4158d5 ("examples/l3fwd: rework exact-match")
> >
> > Signed-off-by: Tomasz Kulasek
> > ---
> > examples/l3fwd/l3fwd_sse.h |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/examples/l3fwd/l3fwd_sse.h b/examples/l3fwd/l3fwd_sse.h
> > index f9cf50a..1afa1f0 100644
> > --- a/examples/l3fwd/l3fwd_sse.h
> > +++ b/examples/l3fwd/l3fwd_sse.h
> > @@ -283,9 +283,9 @@ port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t
> *lp, __m128i dp1, __m128i dp2)
> >
> > /* if dest port value has changed. */
> > if (v != GRPMSK) {
> > - lp = pnum->u16 + gptbl[v].idx;
> > - lp[0] = 1;
> > pnum->u64 = gptbl[v].pnum;
> > + pnum->u16[FWDSTEP] = 1;
>
> Hmm, but FWDSTEP and gptbl[v].idx are not always equal.
> Actually could you explain a bit more - what exactly is reordered by gcc 5.x,
> and how to reproduce it?
> i.e what sequence of input packets will trigger an error?
Hi Konstantin,
I could see the issue when having two flows in one port, one going to port 0
and the other to port 1 (using Exact Match).
There is no issue when there is just one flow per port, using an older gcc
version (< 5.0) or using O0/O1 (and of course, using LPM).
Pablo
> Konstantin
>
> > + lp = pnum->u16 + gptbl[v].idx;
> > }
> >
> > return lp;
> > --
> > 1.7.9.5
[dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
Hi Tomasz,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz Kulasek
> Sent: Monday, April 04, 2016 3:45 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
>
> It seems that with gcc >5.x and -O2/-O3 optimization breaks packet grouping
> algorithm.
>
> When last packet pointer "lp" and "pnum->u64" buffer points the same
> memory buffer, high optimization can cause unpredictable results. It seems
> that assignment of precalculated group sizes may interfere with
> initialization of new group size when lp points value inside current group
> and didn't should be changed.
>
> With gcc >5.x and optimization we cannot be sure which assignment will be
> done first, so the group size can be counted incorrectly.
>
> This patch eliminates intersection of assignment of initial group size
> (lp[0] = 1) and precalculated group sizes when gptbl[v].idx < 4.
>
> Fixes: 94c54b4158d5 ("examples/l3fwd: rework exact-match")
>
> Signed-off-by: Tomasz Kulasek
> ---
> examples/l3fwd/l3fwd_sse.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/examples/l3fwd/l3fwd_sse.h b/examples/l3fwd/l3fwd_sse.h
> index f9cf50a..1afa1f0 100644
> --- a/examples/l3fwd/l3fwd_sse.h
> +++ b/examples/l3fwd/l3fwd_sse.h
> @@ -283,9 +283,9 @@ port_groupx4(uint16_t pn[FWDSTEP + 1], uint16_t *lp,
> __m128i dp1, __m128i dp2)
>
> /* if dest port value has changed. */
> if (v != GRPMSK) {
> - lp = pnum->u16 + gptbl[v].idx;
> - lp[0] = 1;
> pnum->u64 = gptbl[v].pnum;
> + pnum->u16[FWDSTEP] = 1;
Hmm, but FWDSTEP and gptbl[v].idx are not always equal.
Actually could you explain a bit more - what exactly is reordered by gcc 5.x,
and how to reproduce it?
i.e what sequence of input packets will trigger an error?
Konstantin
> + lp = pnum->u16 + gptbl[v].idx;
> }
>
> return lp;
> --
> 1.7.9.5
[dpdk-dev] [PATCH] virtio: use zeroed memory for simple TX header
Huawei, Yuanhan, any comment? 2016-03-31 13:01, Rich Lane: > vq->vq_ring.desc[i + mid_idx].next = i; > vq->vq_ring.desc[i + mid_idx].addr = > - vq->virtio_net_hdr_mem + > - i * vq->hw->vtnet_hdr_size; > + vq->virtio_net_hdr_mem; > vq->vq_ring.desc[i + mid_idx].len = > vq->hw->vtnet_hdr_size;
[dpdk-dev] [PATCH 0/2] fixes for icc build errors
2016-04-04 10:46, Daniel Mrzyglod: > This series of patches is to solve errors for Intel C Compiler > > Daniel Mrzyglod (2): > examples/l2fwd-crypto: fix for icc > examples: fix build errors for icc Applied with precision about icc 15.0.1, thanks
[dpdk-dev] [PATCH] doc: update the snow3g library information
On 01/04/16 12:23, Pablo de Lara wrote: > A new process to request the libsso library required by the SNOW3G PMD > has been put in place, through a website, replacing the previous email method. > This commit updates the SNOW3G documentation, to reflect this change. > > Since the library does not support newer gcc versions, the documentation > also contains a patch to make the library work with gcc > 5.0. > > Signed-off-by: Pablo de Lara > --- . > Acked-by: Declan Doherty
[dpdk-dev] [PATCH 1/3] doc: fix typo in Crypto NULL PMD title
Fixes: 94b0ad8e0aa5 ("null_crypto: add driver for null crypto operations")
Signed-off-by: Pablo de Lara
---
doc/guides/cryptodevs/null.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/cryptodevs/null.rst b/doc/guides/cryptodevs/null.rst
index 3ea4d21..6408391 100644
--- a/doc/guides/cryptodevs/null.rst
+++ b/doc/guides/cryptodevs/null.rst
@@ -27,7 +27,7 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-Null Crytpo Poll Mode Driver
+Null Crypto Poll Mode Driver
The Null Crypto PMD (**librte_pmd_null_crypto**) provides a crypto poll mode
--
2.5.5
[dpdk-dev] [PATCH 0/3] Fixes/extra documentation for Crypto PMDs
This patchset fixes some minor typos in the Crypto PMD documentation and add an extra section to help user to initialize the devices. The patchset depends on: "doc: update the snow3g library information" (http://dpdk.org/dev/patchwork/patch/11889/) Pablo de Lara (3): doc: fix typo in Crypto NULL PMD title doc: remove unnecessary underline characters in AES GCM PMD doc: add initialization section for virtual crypto PMDs doc/guides/cryptodevs/aesni_gcm.rst | 40 +++-- doc/guides/cryptodevs/aesni_mb.rst | 36 + doc/guides/cryptodevs/null.rst | 26 +++- doc/guides/cryptodevs/snow3g.rst| 35 +--- 4 files changed, 123 insertions(+), 14 deletions(-) -- 2.5.5
[dpdk-dev] [PATCH v1 1/1] cmdline: add any multi string mode to token string
Hi Olivier, > -Original Message- > From: Olivier Matz [mailto:olivier.matz at 6wind.com] > Sent: Monday, April 4, 2016 10:01 AM > To: Azarewicz, PiotrX T > Cc: dev at dpdk.org > Subject: Re: [PATCH v1 1/1] cmdline: add any multi string mode to token > string > > Hi Piotr, > > This is globally ok for me. Please see a comment below. > Good to know it, thanks. > Using token_len + 1 as the buffer size in the snprintf looks a bit dangerous, > as > it won't protect from overflows. > > See the following example: > That's why snprintf() should still use STR_TOKEN_SIZE. > Okay, I see it. But this is a problem that we may need longer string than STR_TOKEN_SIZE in multi token case. So what you think about adding new typedef cmdline_multi_string_t for this case? For example: #define STR_MULTI_TOKEN_SIZE 1024 typedef char cmdline_multi_string_t[STR_MULTI_TOKEN_SIZE]; > > Regards, > Olivier
[dpdk-dev] [PATCH v2] examples: fix build errors for icc
error: loops in this subroutine are not good vectorization candidates
(try compiling with O3 and/or IPO).
this error occurs in icc 15.0.1
Solution to disable this diagnostic message
https://software.intel.com/en-us/forums/intel-c-compiler/topic/537688
Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")
Fixes: 8cc72f2814dd ("examples/vmdq_dcb: support X710")
Signed-off-by: Daniel Mrzyglod
---
examples/ipsec-secgw/Makefile | 4
examples/vmdq_dcb/Makefile| 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/examples/ipsec-secgw/Makefile b/examples/ipsec-secgw/Makefile
index da39e49..f9b59c2 100644
--- a/examples/ipsec-secgw/Makefile
+++ b/examples/ipsec-secgw/Makefile
@@ -42,6 +42,10 @@ APP = ipsec-secgw
CFLAGS += -O3 -gdwarf-2
CFLAGS += $(WERROR_FLAGS)
+ifeq ($(CONFIG_RTE_TOOLCHAIN_ICC),y)
+CFLAGS_sa.o += -diag-disable=vec
+endif
+
VPATH += $(SRCDIR)/librte_ipsec
diff --git a/examples/vmdq_dcb/Makefile b/examples/vmdq_dcb/Makefile
index 10a9a9a..8c51131 100644
--- a/examples/vmdq_dcb/Makefile
+++ b/examples/vmdq_dcb/Makefile
@@ -51,7 +51,9 @@ CFLAGS += $(WERROR_FLAGS)
ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
CFLAGS_main.o += -Wno-return-type
endif
-
+ifeq ($(CONFIG_RTE_TOOLCHAIN_ICC),y)
+CFLAGS_main.o += -diag-disable=vec
+endif
EXTRA_CFLAGS += -O3 -g
include $(RTE_SDK)/mk/rte.extapp.mk
--
2.5.5
[dpdk-dev] [PATCH] scripts: build with libsso
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, April 01, 2016 8:43 PM > To: De Lara Guarch, Pablo > Cc: dev at dpdk.org > Subject: [PATCH] scripts: build with libsso > > Signed-off-by: Thomas Monjalon Acked-by: Pablo de Lara
[dpdk-dev] Regarding VF RSS support on fortville XL710 NIC
Hello experts, We are currently running the latest DPDK driver on a Linux VM on KVM host. We are using Intel XL710 NIC (40G mode) in SRIOV mode on the VM. The PF side is the standard i40e Linux Kernel driver. What is the maximum number of HW RSS queues that can be allocated for the i40e poll mode VF driver? As per the link: http://dpdk.org/doc/guides/nics/intel_vf.html , upto 16 RSS queues can be supported per VF. *Question* Could you please confirm the same number holds good with the latest i40e kernel PF driver? Thanks in advance! Regards, Nirmal
[dpdk-dev] [PATCH 2/2] examples: fix build errors for icc
error: loops in this subroutine are not good vectorization candidates
(try compiling with O3 and/or IPO).
Solution to disable this diagnostic message
https://software.intel.com/en-us/forums/intel-c-compiler/topic/537688
Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")
Fixes: 8cc72f2814dd ("examples/vmdq_dcb: support X710")
Signed-off-by: Daniel Mrzyglod
---
examples/ipsec-secgw/Makefile | 4
examples/vmdq_dcb/Makefile| 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/examples/ipsec-secgw/Makefile b/examples/ipsec-secgw/Makefile
index da39e49..f9b59c2 100644
--- a/examples/ipsec-secgw/Makefile
+++ b/examples/ipsec-secgw/Makefile
@@ -42,6 +42,10 @@ APP = ipsec-secgw
CFLAGS += -O3 -gdwarf-2
CFLAGS += $(WERROR_FLAGS)
+ifeq ($(CONFIG_RTE_TOOLCHAIN_ICC),y)
+CFLAGS_sa.o += -diag-disable=vec
+endif
+
VPATH += $(SRCDIR)/librte_ipsec
diff --git a/examples/vmdq_dcb/Makefile b/examples/vmdq_dcb/Makefile
index 10a9a9a..8c51131 100644
--- a/examples/vmdq_dcb/Makefile
+++ b/examples/vmdq_dcb/Makefile
@@ -51,7 +51,9 @@ CFLAGS += $(WERROR_FLAGS)
ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
CFLAGS_main.o += -Wno-return-type
endif
-
+ifeq ($(CONFIG_RTE_TOOLCHAIN_ICC),y)
+CFLAGS_main.o += -diag-disable=vec
+endif
EXTRA_CFLAGS += -O3 -g
include $(RTE_SDK)/mk/rte.extapp.mk
--
2.5.5
[dpdk-dev] [PATCH 0/2] fixes for icc build errors
This series of patches is to solve errors for Intel C Compiler Daniel Mrzyglod (2): examples/l2fwd-crypto: fix for icc examples: fix build errors for icc examples/ipsec-secgw/Makefile | 4 examples/l2fwd-crypto/main.c | 4 ++-- examples/vmdq_dcb/Makefile| 4 +++- 3 files changed, 9 insertions(+), 3 deletions(-) -- 2.5.5
[dpdk-dev] [PATCH 2/2] examples: fix build errors for icc
> -Original Message-
> From: Mrzyglod, DanielX T
> Sent: Monday, April 04, 2016 10:38 AM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Cc: Wu, Jingjing
> Subject: RE: [PATCH 2/2] examples: fix build errors for icc
>
> >From: De Lara Guarch, Pablo
> >Sent: Monday, April 04, 2016 11:34 AM
> >To: Mrzyglod, DanielX T ; dev at dpdk.org
> >Cc: Wu, Jingjing
> >Subject: RE: [PATCH 2/2] examples: fix build errors for icc
> >
> >Hi Daniel,
> >
> >> -Original Message-
> >> From: Mrzyglod, DanielX T
> >> Sent: Monday, April 04, 2016 9:47 AM
> >> To: dev at dpdk.org
> >> Cc: Wu, Jingjing; De Lara Guarch, Pablo
> >> Subject: [PATCH 2/2] examples: fix build errors for icc
> >>
> >> error: loops in this subroutine are not good vectorization candidates
> >> (try compiling with O3 and/or IPO).
> >>
> >> Solution to disable this diagnostic message
> >> https://software.intel.com/en-us/forums/intel-c-compiler/topic/537688
> >>
> >> Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample
> application")
> >> Fixes: 8cc72f2814dd ("examples/vmdq_dcb: support X710")
> >>
> >> Signed-off-by: Daniel Mrzyglod
> >
> >Which ICC version are you using? I don't see any errors with ICC 15.0, so is
> >it
> with
> >16.0?
OK, I see that the problem is only in 15.0.1, but was fixed in 15.0.2 (my
version).
Could you specify in the commit message the icc version that this patch is
targeting?
Thanks,
Pablo
>
> icc (ICC) 15.0.1 20141023
> Copyright (C) 1985-2014 Intel Corporation. All rights reserved.
>
> When I did: make examples T=x86_64-native-linuxapp-icc
> /mnt/shared/dtmrzglx/hubabuba/examples/vmdq_dcb/main.c(521): (col. 1)
> error: loops in this subroutine are not good vectorization candidates (try
> compiling with O3 and/or IPO).
> compilation aborted for
> /mnt/shared/dtmrzglx/hubabuba/examples/vmdq_dcb/main.c (code 1)
> /mnt/shared/dtmrzglx/hubabuba/mk/internal/rte.compile-pre.mk:126:
> recipe for target 'main.o' failed
> make[4]: *** [main.o] Error 1
> /mnt/shared/dtmrzglx/hubabuba/mk/rte.extapp.mk:42: recipe for target
> 'all' failed
> make[3]: *** [all] Error 2
> /mnt/shared/dtmrzglx/hubabuba/mk/rte.extsubdir.mk:46: recipe for target
> 'vmdq_dcb' failed
> make[2]: *** [vmdq_dcb] Error 2
> make[2]: *** Waiting for unfinished jobs
>
>
> /mnt/shared/dtmrzglx/hubabuba/examples/ipsec-secgw/sa.c(348): (col. 1)
> error: loops in this subroutine are not good vectorization candidates (try
> compiling with O3 and/or IPO).
> compilation aborted for /mnt/shared/dtmrzglx/hubabuba/examples/ipsec-
> secgw/sa.c (code 1)
> /mnt/shared/dtmrzglx/hubabuba/mk/internal/rte.compile-pre.mk:126:
> recipe for target 'sa.o' failed
> make[4]: *** [sa.o] Error 1
[dpdk-dev] [PATCH v1 1/1] cmdline: add any multi string mode to token string
Hi Piotr,
This is globally ok for me. Please see a comment below.
On 04/01/2016 01:36 PM, Piotr Azarewicz wrote:
> @@ -162,12 +174,15 @@ cmdline_parse_string(cmdline_parse_token_hdr_t *tk,
> const char *buf, void *res,
> }
>
> if (res) {
> - /* we are sure that token_len is < STR_TOKEN_SIZE-1 */
> - snprintf(res, STR_TOKEN_SIZE, "%s", buf);
> - *((char *)res + token_len) = 0;
> + if ((sd->str != NULL) && (strcmp(sd->str, TOKEN_STRING_MULTI)
> == 0))
> + snprintf(res, token_len + 1, "%s", buf);
> + else {
> + /* we are sure that token_len is < STR_TOKEN_SIZE-1 */
> + snprintf(res, STR_TOKEN_SIZE, "%s", buf);
> + *((char *)res + token_len) = 0;
> + }
> }
>
Using token_len + 1 as the buffer size in the snprintf looks a
bit dangerous, as it won't protect from overflows.
See the following example:
struct cmd_foo_result {
cmdline_fixed_string_t args;
cmdline_fixed_string_t foo;
};
static void
cmd_foo_parsed(void *parsed_result,
__rte_unused struct cmdline *cl,
__rte_unused void *data)
{
struct cmd_foo_result *res = parsed_result;
printf("foo=%s, args=%s\n", res->foo, res->args);
}
cmdline_parse_token_string_t cmd_foo_foo =
TOKEN_STRING_INITIALIZER(struct cmd_foo_result, foo,
"foo");
cmdline_parse_token_string_t cmd_foo_args =
TOKEN_STRING_INITIALIZER(struct cmd_foo_result, args,
TOKEN_STRING_MULTI);
cmdline_parse_inst_t cmd_foo = {
.f = cmd_foo_parsed, /* function to call */
.data = NULL, /* 2nd arg of func */
.help_str = "test",
.tokens = {/* token list, NULL terminated */
(void *)_foo_foo,
(void *)_foo_args,
NULL,
},
};
The result will be:
# ok
RTE>>foo xxx
foo=foo, args=xxx
# not ok, args overflows in foo
RTE>>foo
xxx
foo=xxx,
args=xxx
That's why snprintf() should still use STR_TOKEN_SIZE.
Regards,
Olivier
[dpdk-dev] [PATCH 2/2] examples: fix build errors for icc
>From: De Lara Guarch, Pablo
>Sent: Monday, April 04, 2016 11:34 AM
>To: Mrzyglod, DanielX T ; dev at dpdk.org
>Cc: Wu, Jingjing
>Subject: RE: [PATCH 2/2] examples: fix build errors for icc
>
>Hi Daniel,
>
>> -Original Message-
>> From: Mrzyglod, DanielX T
>> Sent: Monday, April 04, 2016 9:47 AM
>> To: dev at dpdk.org
>> Cc: Wu, Jingjing; De Lara Guarch, Pablo
>> Subject: [PATCH 2/2] examples: fix build errors for icc
>>
>> error: loops in this subroutine are not good vectorization candidates
>> (try compiling with O3 and/or IPO).
>>
>> Solution to disable this diagnostic message
>> https://software.intel.com/en-us/forums/intel-c-compiler/topic/537688
>>
>> Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")
>> Fixes: 8cc72f2814dd ("examples/vmdq_dcb: support X710")
>>
>> Signed-off-by: Daniel Mrzyglod
>
>Which ICC version are you using? I don't see any errors with ICC 15.0, so is
>it with
>16.0?
icc (ICC) 15.0.1 20141023
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.
When I did: make examples T=x86_64-native-linuxapp-icc
/mnt/shared/dtmrzglx/hubabuba/examples/vmdq_dcb/main.c(521): (col. 1) error:
loops in this subroutine are not good vectorization candidates (try compiling
with O3 and/or IPO).
compilation aborted for /mnt/shared/dtmrzglx/hubabuba/examples/vmdq_dcb/main.c
(code 1)
/mnt/shared/dtmrzglx/hubabuba/mk/internal/rte.compile-pre.mk:126: recipe for
target 'main.o' failed
make[4]: *** [main.o] Error 1
/mnt/shared/dtmrzglx/hubabuba/mk/rte.extapp.mk:42: recipe for target 'all'
failed
make[3]: *** [all] Error 2
/mnt/shared/dtmrzglx/hubabuba/mk/rte.extsubdir.mk:46: recipe for target
'vmdq_dcb' failed
make[2]: *** [vmdq_dcb] Error 2
make[2]: *** Waiting for unfinished jobs
/mnt/shared/dtmrzglx/hubabuba/examples/ipsec-secgw/sa.c(348): (col. 1) error:
loops in this subroutine are not good vectorization candidates (try compiling
with O3 and/or IPO).
compilation aborted for /mnt/shared/dtmrzglx/hubabuba/examples/ipsec-secgw/sa.c
(code 1)
/mnt/shared/dtmrzglx/hubabuba/mk/internal/rte.compile-pre.mk:126: recipe for
target 'sa.o' failed
make[4]: *** [sa.o] Error 1
[dpdk-dev] [PATCH 1/2] examples/l2fwd-crypto: fix for icc
> -Original Message-
> From: Mrzyglod, DanielX T
> Sent: Monday, April 04, 2016 9:47 AM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; De Lara Guarch, Pablo
> Subject: [PATCH 1/2] examples/l2fwd-crypto: fix for icc
>
> Fix for compilation errors for icc:
> error #188: enumerated type mixed with another type
>
> Fixes: 00c58901f1b3 ("examples/l2fwd-crypto: use key-value list of
> supported algorithms")
>
> Signed-off-by: Daniel Mrzyglod
Acked-by: Pablo de Lara
[dpdk-dev] [PATCH 2/2] examples: fix build errors for icc
Hi Daniel,
> -Original Message-
> From: Mrzyglod, DanielX T
> Sent: Monday, April 04, 2016 9:47 AM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; De Lara Guarch, Pablo
> Subject: [PATCH 2/2] examples: fix build errors for icc
>
> error: loops in this subroutine are not good vectorization candidates
> (try compiling with O3 and/or IPO).
>
> Solution to disable this diagnostic message
> https://software.intel.com/en-us/forums/intel-c-compiler/topic/537688
>
> Fixes: d299106e8e31 ("examples/ipsec-secgw: add IPsec sample application")
> Fixes: 8cc72f2814dd ("examples/vmdq_dcb: support X710")
>
> Signed-off-by: Daniel Mrzyglod
Which ICC version are you using? I don't see any errors with ICC 15.0, so is it
with 16.0?
Thanks,
Pablo
[dpdk-dev] [PATCH] ixgbe: cleanup whitespace and formatting issues
This driver was one of the originals and has lots of little
whitespace issues.
PS: I know Intel doesn't like whitespace changes, there is never a
good time to do this, but no resuliting binary changes and it is
unlikely that more changes to this driver will occur this late in
release cycle.
Signed-off-by: Stephen Hemminger
---
drivers/net/ixgbe/ixgbe_82599_bypass.c | 4 +-
drivers/net/ixgbe/ixgbe_bypass.c | 6 +-
drivers/net/ixgbe/ixgbe_bypass.h | 8 +-
drivers/net/ixgbe/ixgbe_bypass_defines.h | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 156 +++
drivers/net/ixgbe/ixgbe_fdir.c | 10 +-
drivers/net/ixgbe/ixgbe_pf.c | 29 +++---
drivers/net/ixgbe/ixgbe_rxtx.c | 80
8 files changed, 145 insertions(+), 150 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_82599_bypass.c
b/drivers/net/ixgbe/ixgbe_82599_bypass.c
index 21c42ea..db05d8e 100644
--- a/drivers/net/ixgbe/ixgbe_82599_bypass.c
+++ b/drivers/net/ixgbe/ixgbe_82599_bypass.c
@@ -306,8 +306,8 @@ ixgbe_bypass_init_hw(struct ixgbe_hw *hw)
hw->mac.ops.get_media_type = _bypass_get_media_type;
hw->mac.ops.disable_tx_laser = NULL;
-hw->mac.ops.enable_tx_laser = NULL;
-hw->mac.ops.flap_tx_laser = NULL;
+ hw->mac.ops.enable_tx_laser = NULL;
+ hw->mac.ops.flap_tx_laser = NULL;
}
return rc;
diff --git a/drivers/net/ixgbe/ixgbe_bypass.c b/drivers/net/ixgbe/ixgbe_bypass.c
index 73f608b..7006928 100644
--- a/drivers/net/ixgbe/ixgbe_bypass.c
+++ b/drivers/net/ixgbe/ixgbe_bypass.c
@@ -82,7 +82,7 @@ ixgbe_bypass_set_time(struct ixgbe_adapter *adapter)
BYPASS_CTL1_VALID_M |
BYPASS_CTL1_OFFTRST_M;
value = (sec & BYPASS_CTL1_TIME_M) |
- BYPASS_CTL1_VALID |
+ BYPASS_CTL1_VALID |
BYPASS_CTL1_OFFTRST;
FUNC_PTR_OR_RET(adapter->bps.ops.bypass_set);
@@ -275,8 +275,8 @@ s32
ixgbe_bypass_wd_timeout_store(struct rte_eth_dev *dev, u32 timeout)
{
struct ixgbe_hw *hw;
-u32 status;
-u32 mask;
+ u32 status;
+ u32 mask;
s32 ret_val;
struct ixgbe_adapter *adapter = IXGBE_DEV_TO_ADPATER(dev);
diff --git a/drivers/net/ixgbe/ixgbe_bypass.h b/drivers/net/ixgbe/ixgbe_bypass.h
index fcd9774..5f5c63e 100644
--- a/drivers/net/ixgbe/ixgbe_bypass.h
+++ b/drivers/net/ixgbe/ixgbe_bypass.h
@@ -37,10 +37,10 @@
#ifdef RTE_NIC_BYPASS
struct ixgbe_bypass_mac_ops {
- s32 (*bypass_rw) (struct ixgbe_hw *hw, u32 cmd, u32 *status);
- bool (*bypass_valid_rd) (u32 in_reg, u32 out_reg);
- s32 (*bypass_set) (struct ixgbe_hw *hw, u32 cmd, u32 event, u32 action);
- s32 (*bypass_rd_eep) (struct ixgbe_hw *hw, u32 addr, u8 *value);
+ s32 (*bypass_rw)(struct ixgbe_hw *hw, u32 cmd, u32 *status);
+ bool (*bypass_valid_rd)(u32 in_reg, u32 out_reg);
+ s32 (*bypass_set)(struct ixgbe_hw *hw, u32 cmd, u32 event, u32 action);
+ s32 (*bypass_rd_eep)(struct ixgbe_hw *hw, u32 addr, u8 *value);
};
struct ixgbe_bypass_info {
diff --git a/drivers/net/ixgbe/ixgbe_bypass_defines.h
b/drivers/net/ixgbe/ixgbe_bypass_defines.h
index 22570ac..cafcb27 100644
--- a/drivers/net/ixgbe/ixgbe_bypass_defines.h
+++ b/drivers/net/ixgbe/ixgbe_bypass_defines.h
@@ -136,7 +136,7 @@ enum ixgbe_state_t {
#define BYPASS_LOG_EVENT_SHIFT 28
#define BYPASS_LOG_CLEAR_SHIFT 24 /* bit offset */
#define IXGBE_DEV_TO_ADPATER(dev) \
- ((struct ixgbe_adapter*)(dev->data->dev_private))
+ ((struct ixgbe_adapter *)(dev->data->dev_private))
/* extractions from ixgbe_phy.h */
#defineIXGBE_I2C_EEPROM_DEV_ADDR2 0xA2
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3f1ebc1..1be0009 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -232,7 +232,7 @@ static void ixgbe_add_rar(struct rte_eth_dev *dev, struct
ether_addr *mac_addr,
static void ixgbe_remove_rar(struct rte_eth_dev *dev, uint32_t index);
static void ixgbe_set_default_mac_addr(struct rte_eth_dev *dev,
struct ether_addr *mac_addr);
-static void ixgbe_dcb_init(struct ixgbe_hw *hw,struct ixgbe_dcb_config
*dcb_config);
+static void ixgbe_dcb_init(struct ixgbe_hw *hw, struct ixgbe_dcb_config
*dcb_config);
/* For Virtual Function support */
static int eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev);
@@ -264,14 +264,14 @@ static void ixgbevf_dev_allmulticast_disable(struct
rte_eth_dev *dev);
/* For Eth VMDQ APIs support */
static int ixgbe_uc_hash_table_set(struct rte_eth_dev *dev, struct
- ether_addr* mac_addr,uint8_t on);
-static int ixgbe_uc_all_hash_table_set(struct rte_eth_dev *dev,uint8_t on);
+ ether_addr * mac_addr, uint8_t on);
+static int ixgbe_uc_all_hash_table_set(struct rte_eth_dev *dev, uint8_t on);
