[dpdk-dev] [PATCH v2] app/testpmd: configure event display
Add two parameters to testpmd:
--print-event
--mask-event
To enable or disable to printing of events. This display is configured
on a per-event basis. By default, all except VF_MBOX are displayed.
Fixes: 76ad4a2d82d4 ("app/testpmd: add generic event handler")
Cc: "Lu, Wenzhuo"
Signed-off-by: Gaetan Rivet
---
Additionally, I'm thinking about runtime commands for events, in the form
event show
event print
event mask
where show could display the state of the masking for this event as well
as statistics for the event. print and mask would do the same as the two
parameters introduced by this patch.
But this is a little heavier and I wanted to propose this fix as soon as
possible.
v1 -> v2:
* Rebased on top of master
* Fixed typos in doc
---
app/test-pmd/parameters.c | 46 +++
app/test-pmd/testpmd.c| 13 +-
app/test-pmd/testpmd.h| 2 ++
doc/guides/testpmd_app_ug/run_app.rst | 8 ++
4 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 787e143..5a07dea 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -206,6 +206,10 @@ usage(char* progname)
printf(" --no-rmv-interrupt: disable device removal interrupt.\n");
printf(" --bitrate-stats=N: set the logical core N to perform "
"bit-rate calculation.\n");
+ printf(" --print-event
: "
+ "enable print of designated event");
+ printf(" --mask-event
: "
+ "disable print of designated event");
}
#ifdef RTE_LIBRTE_CMDLINE
@@ -503,6 +507,36 @@ parse_ringnuma_config(const char *q_arg)
return 0;
}
+static int
+parse_event_printing_config(const char *optarg, int enable)
+{
+ uint32_t mask = 0;
+
+ if (!strcmp(optarg, "unknown"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_UNKNOWN;
+ else if (!strcmp(optarg, "intr_lsc"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_INTR_LSC;
+ else if (!strcmp(optarg, "queue_state"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_QUEUE_STATE;
+ else if (!strcmp(optarg, "intr_reset"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_INTR_RESET;
+ else if (!strcmp(optarg, "vf_mbox"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_VF_MBOX;
+ else if (!strcmp(optarg, "macsec"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_MACSEC;
+ else if (!strcmp(optarg, "intr_rmv"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_INTR_RMV;
+ else {
+ fprintf(stderr, "Invalid event: %s\n", optarg);
+ return -1;
+ }
+ if (enable)
+ event_print_mask |= mask;
+ else
+ event_print_mask &= ~mask;
+ return 0;
+}
+
void
launch_args_parse(int argc, char** argv)
{
@@ -581,6 +615,8 @@ launch_args_parse(int argc, char** argv)
{ "disable-link-check", 0, 0, 0 },
{ "no-lsc-interrupt", 0, 0, 0 },
{ "no-rmv-interrupt", 0, 0, 0 },
+ { "print-event",1, 0, 0 },
+ { "mask-event", 1, 0, 0 },
{ 0, 0, 0, 0 },
};
@@ -1036,6 +1072,16 @@ launch_args_parse(int argc, char** argv)
lsc_interrupt = 0;
if (!strcmp(lgopts[opt_idx].name, "no-rmv-interrupt"))
rmv_interrupt = 0;
+ if (!strcmp(lgopts[opt_idx].name, "print-event"))
+ if (parse_event_printing_config(optarg, 1)) {
+ rte_exit(EXIT_FAILURE,
+"invalid print-event
argument\n");
+ }
+ if (!strcmp(lgopts[opt_idx].name, "mask-event"))
+ if (parse_event_printing_config(optarg, 0)) {
+ rte_exit(EXIT_FAILURE,
+"invalid mask-event
argument\n");
+ }
break;
case 'h':
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index dfe6442..b9c385e 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -282,6 +282,17 @@ uint8_t lsc_interrupt = 1; /* enabled by default */
uint8_t rmv_interrupt = 1; /* enabled by default */
/*
+ * Display or mask ether events
+ * Default to all events except VF_MBOX
+ */
+uint32_t event_print_mask = (UINT32_C(1) << RTE_ETH_EVENT_UNKNOWN) |
+ (UINT32_C(1) << RTE_ETH_EVENT_INTR_LSC) |
+ (UINT32_C(1) << RTE_ETH_EVENT_QUEUE_STATE) |
+ (UINT32_C(1) << RTE_ETH_EVENT_INTR_RESET) |
+ (UINT32_C(1) << RTE_ETH_EVENT_MACSEC) |
+
[dpdk-dev] [PATCH 1/5] examples/l3fwd: extract arch independent code from multi hash lookup
Extract common code from l3fwd_em_hlm_sse.h, and add to the new file
l3fwd_em_hlm.h.
Signed-off-by: Jianbo Liu
---
examples/l3fwd/l3fwd_em.c | 2 +-
examples/l3fwd/l3fwd_em_hlm.h | 302 ++
examples/l3fwd/l3fwd_em_hlm_sse.h | 280 +--
3 files changed, 309 insertions(+), 275 deletions(-)
create mode 100644 examples/l3fwd/l3fwd_em_hlm.h
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 9cc4460..939a16d 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -332,7 +332,7 @@ struct ipv6_l3fwd_em_route {
#if defined(NO_HASH_MULTI_LOOKUP)
#include "l3fwd_em_sse.h"
#else
-#include "l3fwd_em_hlm_sse.h"
+#include "l3fwd_em_hlm.h"
#endif
#else
#include "l3fwd_em.h"
diff --git a/examples/l3fwd/l3fwd_em_hlm.h b/examples/l3fwd/l3fwd_em_hlm.h
new file mode 100644
index 000..636dea4
--- /dev/null
+++ b/examples/l3fwd/l3fwd_em_hlm.h
@@ -0,0 +1,302 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * Copyright(c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef __L3FWD_EM_HLM_H__
+#define __L3FWD_EM_HLM_H__
+
+#include "l3fwd_sse.h"
+#include "l3fwd_em_hlm_sse.h"
+
+static inline __attribute__((always_inline)) void
+em_get_dst_port_ipv4x8(struct lcore_conf *qconf, struct rte_mbuf *m[8],
+ uint8_t portid, uint16_t dst_port[8])
+{
+ int32_t ret[8];
+ union ipv4_5tuple_host key[8];
+
+ get_ipv4_5tuple(m[0], mask0.x, &key[0]);
+ get_ipv4_5tuple(m[1], mask0.x, &key[1]);
+ get_ipv4_5tuple(m[2], mask0.x, &key[2]);
+ get_ipv4_5tuple(m[3], mask0.x, &key[3]);
+ get_ipv4_5tuple(m[4], mask0.x, &key[4]);
+ get_ipv4_5tuple(m[5], mask0.x, &key[5]);
+ get_ipv4_5tuple(m[6], mask0.x, &key[6]);
+ get_ipv4_5tuple(m[7], mask0.x, &key[7]);
+
+ const void *key_array[8] = {&key[0], &key[1], &key[2], &key[3],
+ &key[4], &key[5], &key[6], &key[7]};
+
+ rte_hash_lookup_bulk(qconf->ipv4_lookup_struct, &key_array[0], 8, ret);
+
+ dst_port[0] = (uint8_t) ((ret[0] < 0) ?
+ portid : ipv4_l3fwd_out_if[ret[0]]);
+ dst_port[1] = (uint8_t) ((ret[1] < 0) ?
+ portid : ipv4_l3fwd_out_if[ret[1]]);
+ dst_port[2] = (uint8_t) ((ret[2] < 0) ?
+ portid : ipv4_l3fwd_out_if[ret[2]]);
+ dst_port[3] = (uint8_t) ((ret[3] < 0) ?
+ portid : ipv4_l3fwd_out_if[ret[3]]);
+ dst_port[4] = (uint8_t) ((ret[4] < 0) ?
+ portid : ipv4_l3fwd_out_if[ret[4]]);
+ dst_port[5] = (uint8_t) ((ret[5] < 0) ?
+ portid : ipv4_l3fwd_out_if[ret[5]]);
+ dst_port[6] = (uint8_t) ((ret[6] < 0) ?
+ portid : ipv4_l3fwd_out_if[ret[6]]);
+ dst_port[7] = (uint8_t) ((ret[7] < 0) ?
+ portid : ipv4_l3fwd_out_if[ret[7]]);
+
+ if (dst_port[0] >= RTE_MAX_ETHPORTS ||
+ (enabled_port_mask & 1 << dst_port[0]) == 0)
+ dst_port[0] = portid;
+
+ if (dst_port[1] >= RTE_MAX_ETHPORTS ||
+ (enabled_port_mask & 1 << dst_port[1]) == 0)
+ dst_port[1] = portid;
+
+ if (dst_port[2] >= RTE_MAX_ETHPORTS ||
+ (enabled_port_m
[dpdk-dev] [PATCH 2/5] examples/l3fwd: rename l3fwd_em_sse.h to l3fwd_em_single.h
The l3fwd_em_sse.h is enabled by NO_HASH_LOOKUP_MULTI.
Renaming it because it's only for single hash lookup,
and doesn't include any x86 SSE instructions.
Signed-off-by: Jianbo Liu
---
examples/l3fwd/l3fwd_em.c| 2 +-
examples/l3fwd/{l3fwd_em_sse.h => l3fwd_em_single.h} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename examples/l3fwd/{l3fwd_em_sse.h => l3fwd_em_single.h} (100%)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 939a16d..cccf797 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -330,7 +330,7 @@ struct ipv6_l3fwd_em_route {
#if defined(__SSE4_1__)
#if defined(NO_HASH_MULTI_LOOKUP)
-#include "l3fwd_em_sse.h"
+#include "l3fwd_em_single.h"
#else
#include "l3fwd_em_hlm.h"
#endif
diff --git a/examples/l3fwd/l3fwd_em_sse.h b/examples/l3fwd/l3fwd_em_single.h
similarity index 100%
rename from examples/l3fwd/l3fwd_em_sse.h
rename to examples/l3fwd/l3fwd_em_single.h
--
1.8.3.1
[dpdk-dev] [PATCH 4/5] examples/l3fwd: rearrange the code for lpm_l3fwd
Signed-off-by: Jianbo Liu
Some common code can be used by other ARCHs, move to l3fwd_lpm.c
---
examples/l3fwd/l3fwd_lpm.c | 83 ++
examples/l3fwd/l3fwd_lpm.h | 26 +
examples/l3fwd/l3fwd_lpm_sse.h | 66 -
3 files changed, 84 insertions(+), 91 deletions(-)
diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
index f621269..fc554fc 100644
--- a/examples/l3fwd/l3fwd_lpm.c
+++ b/examples/l3fwd/l3fwd_lpm.c
@@ -104,6 +104,89 @@ struct ipv6_l3fwd_lpm_route {
struct rte_lpm *ipv4_l3fwd_lpm_lookup_struct[NB_SOCKETS];
struct rte_lpm6 *ipv6_l3fwd_lpm_lookup_struct[NB_SOCKETS];
+static inline uint16_t
+lpm_get_ipv4_dst_port(void *ipv4_hdr, uint8_t portid, void *lookup_struct)
+{
+ uint32_t next_hop;
+ struct rte_lpm *ipv4_l3fwd_lookup_struct =
+ (struct rte_lpm *)lookup_struct;
+
+ return (uint16_t) ((rte_lpm_lookup(ipv4_l3fwd_lookup_struct,
+ rte_be_to_cpu_32(((struct ipv4_hdr *)ipv4_hdr)->dst_addr),
+ &next_hop) == 0) ? next_hop : portid);
+}
+
+static inline uint16_t
+lpm_get_ipv6_dst_port(void *ipv6_hdr, uint8_t portid, void *lookup_struct)
+{
+ uint32_t next_hop;
+ struct rte_lpm6 *ipv6_l3fwd_lookup_struct =
+ (struct rte_lpm6 *)lookup_struct;
+
+ return (uint16_t) ((rte_lpm6_lookup(ipv6_l3fwd_lookup_struct,
+ ((struct ipv6_hdr *)ipv6_hdr)->dst_addr,
+ &next_hop) == 0) ? next_hop : portid);
+}
+
+static inline __attribute__((always_inline)) uint16_t
+lpm_get_dst_port(const struct lcore_conf *qconf, struct rte_mbuf *pkt,
+ uint8_t portid)
+{
+ struct ipv6_hdr *ipv6_hdr;
+ struct ipv4_hdr *ipv4_hdr;
+ struct ether_hdr *eth_hdr;
+
+ if (RTE_ETH_IS_IPV4_HDR(pkt->packet_type)) {
+
+ eth_hdr = rte_pktmbuf_mtod(pkt, struct ether_hdr *);
+ ipv4_hdr = (struct ipv4_hdr *)(eth_hdr + 1);
+
+ return lpm_get_ipv4_dst_port(ipv4_hdr, portid,
+qconf->ipv4_lookup_struct);
+ } else if (RTE_ETH_IS_IPV6_HDR(pkt->packet_type)) {
+
+ eth_hdr = rte_pktmbuf_mtod(pkt, struct ether_hdr *);
+ ipv6_hdr = (struct ipv6_hdr *)(eth_hdr + 1);
+
+ return lpm_get_ipv6_dst_port(ipv6_hdr, portid,
+qconf->ipv6_lookup_struct);
+ }
+
+ return portid;
+}
+
+/*
+ * lpm_get_dst_port optimized routine for packets where dst_ipv4 is already
+ * precalculated. If packet is ipv6 dst_addr is taken directly from packet
+ * header and dst_ipv4 value is not used.
+ */
+static inline __attribute__((always_inline)) uint16_t
+lpm_get_dst_port_with_ipv4(const struct lcore_conf *qconf, struct rte_mbuf
*pkt,
+ uint32_t dst_ipv4, uint8_t portid)
+{
+ uint32_t next_hop;
+ struct ipv6_hdr *ipv6_hdr;
+ struct ether_hdr *eth_hdr;
+
+ if (RTE_ETH_IS_IPV4_HDR(pkt->packet_type)) {
+ return (uint16_t) ((rte_lpm_lookup(qconf->ipv4_lookup_struct,
+ dst_ipv4, &next_hop) == 0)
+ ? next_hop : portid);
+
+ } else if (RTE_ETH_IS_IPV6_HDR(pkt->packet_type)) {
+
+ eth_hdr = rte_pktmbuf_mtod(pkt, struct ether_hdr *);
+ ipv6_hdr = (struct ipv6_hdr *)(eth_hdr + 1);
+
+ return (uint16_t) ((rte_lpm6_lookup(qconf->ipv6_lookup_struct,
+ ipv6_hdr->dst_addr, &next_hop) == 0)
+ ? next_hop : portid);
+
+ }
+
+ return portid;
+}
+
#if defined(__SSE4_1__)
#include "l3fwd_lpm_sse.h"
#else
diff --git a/examples/l3fwd/l3fwd_lpm.h b/examples/l3fwd/l3fwd_lpm.h
index 258a82f..4865d90 100644
--- a/examples/l3fwd/l3fwd_lpm.h
+++ b/examples/l3fwd/l3fwd_lpm.h
@@ -34,37 +34,13 @@
#ifndef __L3FWD_LPM_H__
#define __L3FWD_LPM_H__
-static inline uint8_t
-lpm_get_ipv4_dst_port(void *ipv4_hdr, uint8_t portid, void *lookup_struct)
-{
- uint32_t next_hop;
- struct rte_lpm *ipv4_l3fwd_lookup_struct =
- (struct rte_lpm *)lookup_struct;
-
- return (uint8_t) ((rte_lpm_lookup(ipv4_l3fwd_lookup_struct,
- rte_be_to_cpu_32(((struct ipv4_hdr *)ipv4_hdr)->dst_addr),
- &next_hop) == 0) ? next_hop : portid);
-}
-
-static inline uint8_t
-lpm_get_ipv6_dst_port(void *ipv6_hdr, uint8_t portid, void *lookup_struct)
-{
- uint32_t next_hop;
- struct rte_lpm6 *ipv6_l3fwd_lookup_struct =
- (struct rte_lpm6 *)lookup_struct;
-
- return (uint8_t) ((rte_lpm6_lookup(ipv6_l3fwd_lookup_struct,
- ((struct ipv6_hdr *)ipv6_hdr)->dst_addr,
- &next_hop) == 0) ? next_hop : portid);
-}
-
static inline __attribute__((always_inline)) void
l3fwd_lpm_simple_forward(struct rte_mbuf *m, uint8_t port
[dpdk-dev] [PATCH 5/5] examples/l3fwd: add neon support for l3fwd
Use ARM NEON intrinsics to accelerate l3 fowarding.
Signed-off-by: Jianbo Liu
---
examples/l3fwd/l3fwd.h | 4 -
examples/l3fwd/l3fwd_em.c | 4 +-
examples/l3fwd/l3fwd_em_hlm.h | 5 +
examples/l3fwd/l3fwd_em_hlm_neon.h | 74 +++
examples/l3fwd/l3fwd_em_single.h | 4 +
examples/l3fwd/l3fwd_lpm.c | 4 +-
examples/l3fwd/l3fwd_lpm_neon.h| 157 ++
examples/l3fwd/l3fwd_neon.h| 259 +
8 files changed, 504 insertions(+), 7 deletions(-)
create mode 100644 examples/l3fwd/l3fwd_em_hlm_neon.h
create mode 100644 examples/l3fwd/l3fwd_lpm_neon.h
create mode 100644 examples/l3fwd/l3fwd_neon.h
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 011ba14..c45589a 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -40,10 +40,6 @@
#define RTE_LOGTYPE_L3FWD RTE_LOGTYPE_USER1
-#if !defined(NO_HASH_MULTI_LOOKUP) && defined(RTE_MACHINE_CPUFLAG_NEON)
-#define NO_HASH_MULTI_LOOKUP 1
-#endif
-
#define MAX_PKT_BURST 32
#define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index cccf797..ac1e2e0 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -328,7 +328,7 @@ struct ipv6_l3fwd_em_route {
return (uint8_t)((ret < 0) ? portid : ipv6_l3fwd_out_if[ret]);
}
-#if defined(__SSE4_1__)
+#if defined(__SSE4_1__) || defined(RTE_MACHINE_CPUFLAG_NEON)
#if defined(NO_HASH_MULTI_LOOKUP)
#include "l3fwd_em_single.h"
#else
@@ -709,7 +709,7 @@ struct ipv6_l3fwd_em_route {
if (nb_rx == 0)
continue;
-#if defined(__SSE4_1__)
+#if defined(__SSE4_1__) || defined(RTE_MACHINE_CPUFLAG_NEON)
l3fwd_em_send_packets(nb_rx, pkts_burst,
portid, qconf);
#else
diff --git a/examples/l3fwd/l3fwd_em_hlm.h b/examples/l3fwd/l3fwd_em_hlm.h
index 636dea4..3329c1a 100644
--- a/examples/l3fwd/l3fwd_em_hlm.h
+++ b/examples/l3fwd/l3fwd_em_hlm.h
@@ -35,8 +35,13 @@
#ifndef __L3FWD_EM_HLM_H__
#define __L3FWD_EM_HLM_H__
+#if defined(__SSE4_1__)
#include "l3fwd_sse.h"
#include "l3fwd_em_hlm_sse.h"
+#elif defined(RTE_MACHINE_CPUFLAG_NEON)
+#include "l3fwd_neon.h"
+#include "l3fwd_em_hlm_neon.h"
+#endif
static inline __attribute__((always_inline)) void
em_get_dst_port_ipv4x8(struct lcore_conf *qconf, struct rte_mbuf *m[8],
diff --git a/examples/l3fwd/l3fwd_em_hlm_neon.h
b/examples/l3fwd/l3fwd_em_hlm_neon.h
new file mode 100644
index 000..dae1acf
--- /dev/null
+++ b/examples/l3fwd/l3fwd_em_hlm_neon.h
@@ -0,0 +1,74 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * Copyright(c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef __L3FWD_EM_HLM_NEON_H__
+#define __L3FWD_EM_HLM_NEON_H__
+
+#include
+
+static inline void
+get_ipv4_5tuple(struct rte_mbuf *m0, int32x4_t mask0,
+ union ipv4_5tuple_host *key)
+{
+ int32x4_t tmpdata0 = vld1q_s32(rte_pktmbuf_mtod_offset(m0, int32_t *,
+ sizeof(struct ether_hdr) +
+ offsetof(struct ipv4_hdr, time_to_live)));
+
+ key->xmm = vandq_s32(tmpdata0, mask0);
+}
+
+static inline void
+get_ipv6_5tuple(struct rte_mbuf *
[dpdk-dev] [PATCH 3/5] examples/l3fwd: extract common code from multi packet send
Keep x86 related code in l3fwd_sse.h, and move common code to
l3fwd_common.h, which will be used by other Archs.
Signed-off-by: Jianbo Liu
---
examples/l3fwd/l3fwd_common.h | 293 ++
examples/l3fwd/l3fwd_sse.h| 255 +---
2 files changed, 297 insertions(+), 251 deletions(-)
create mode 100644 examples/l3fwd/l3fwd_common.h
diff --git a/examples/l3fwd/l3fwd_common.h b/examples/l3fwd/l3fwd_common.h
new file mode 100644
index 000..d7a1fdf
--- /dev/null
+++ b/examples/l3fwd/l3fwd_common.h
@@ -0,0 +1,293 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation. All rights reserved.
+ * Copyright(c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+
+#ifndef _L3FWD_COMMON_H_
+#define _L3FWD_COMMON_H_
+
+#ifdef DO_RFC_1812_CHECKS
+
+#defineIPV4_MIN_VER_IHL0x45
+#defineIPV4_MAX_VER_IHL0x4f
+#defineIPV4_MAX_VER_IHL_DIFF (IPV4_MAX_VER_IHL - IPV4_MIN_VER_IHL)
+
+/* Minimum value of IPV4 total length (20B) in network byte order. */
+#defineIPV4_MIN_LEN_BE (sizeof(struct ipv4_hdr) << 8)
+
+/*
+ * From http://www.rfc-editor.org/rfc/rfc1812.txt section 5.2.2:
+ * - The IP version number must be 4.
+ * - The IP header length field must be large enough to hold the
+ *minimum length legal IP datagram (20 bytes = 5 words).
+ * - The IP total length field must be large enough to hold the IP
+ * datagram header, whose length is specified in the IP header length
+ * field.
+ * If we encounter invalid IPV4 packet, then set destination port for it
+ * to BAD_PORT value.
+ */
+static inline __attribute__((always_inline)) void
+rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint16_t *dp, uint32_t ptype)
+{
+ uint8_t ihl;
+
+ if (RTE_ETH_IS_IPV4_HDR(ptype)) {
+ ihl = ipv4_hdr->version_ihl - IPV4_MIN_VER_IHL;
+
+ ipv4_hdr->time_to_live--;
+ ipv4_hdr->hdr_checksum++;
+
+ if (ihl > IPV4_MAX_VER_IHL_DIFF ||
+ ((uint8_t)ipv4_hdr->total_length == 0 &&
+ ipv4_hdr->total_length < IPV4_MIN_LEN_BE))
+ dp[0] = BAD_PORT;
+
+ }
+}
+
+#else
+#definerfc1812_process(mb, dp, ptype) do { } while (0)
+#endif /* DO_RFC_1812_CHECKS */
+
+/*
+ * We group consecutive packets with the same destionation port into one burst.
+ * To avoid extra latency this is done together with some other packet
+ * processing, but after we made a final decision about packet's destination.
+ * To do this we maintain:
+ * pnum - array of number of consecutive packets with the same dest port for
+ * each packet in the input burst.
+ * lp - pointer to the last updated element in the pnum.
+ * dlp - dest port value lp corresponds to.
+ */
+
+#defineGRPSZ (1 << FWDSTEP)
+#defineGRPMSK (GRPSZ - 1)
+
+#define GROUP_PORT_STEP(dlp, dcp, lp, pn, idx) do { \
+ if (likely((dlp) == (dcp)[(idx)])) { \
+ (lp)[0]++; \
+ } else { \
+ (dlp) = (dcp)[idx]; \
+ (lp) = (pn) + (idx); \
+ (lp)[0] = 1; \
+ }\
+}
Re: [dpdk-dev] [PATCH] test/test: improve dequeue logic for crypto operation
Hi Akhil, > -Original Message- > From: Akhil Goyal [mailto:akhil.go...@nxp.com] > Sent: Wednesday, April 26, 2017 12:02 PM > To: De Lara Guarch, Pablo; dev@dpdk.org > Cc: Doherty, Declan; hemant.agra...@nxp.com > Subject: Re: [PATCH] test/test: improve dequeue logic for crypto operation > > On 4/26/2017 4:12 PM, De Lara Guarch, Pablo wrote: > > > > > >> -Original Message- > >> From: Akhil Goyal [mailto:akhil.go...@nxp.com] > >> Sent: Wednesday, April 26, 2017 10:53 AM > >> To: De Lara Guarch, Pablo; dev@dpdk.org > >> Cc: Doherty, Declan; hemant.agra...@nxp.com > >> Subject: Re: [PATCH] test/test: improve dequeue logic for crypto > operation > >> > >> On 4/26/2017 3:08 PM, De Lara Guarch, Pablo wrote: > >>> > >>> > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Akhil Goyal > Sent: Thursday, April 20, 2017 11:48 AM > To: De Lara Guarch, Pablo; dev@dpdk.org > Cc: Doherty, Declan; hemant.agra...@nxp.com > Subject: Re: [dpdk-dev] [PATCH] test/test: improve dequeue logic for > >> crypto > operation > > Hi Pablo, > > On 4/4/2017 8:41 PM, De Lara Guarch, Pablo wrote: > > Hi Akhil, > > > >> -Original Message- > >> From: akhil.go...@nxp.com [mailto:akhil.go...@nxp.com] > >> Sent: Monday, April 03, 2017 11:53 AM > >> To: dev@dpdk.org > >> Cc: Doherty, Declan; De Lara Guarch, Pablo; Akhil Goyal > >> Subject: [PATCH] test/test: improve dequeue logic for crypto > >> operation > >> > >> From: Akhil Goyal > >> > >> While enqueue/dequeue operations in test_perf_aes_sha, > >> the underlying implementation may not be able to dequeue > >> the same number of buffers as enqueued. So, it may be > >> necessary to perform more dequeue operations if the gap > >> is more than pparams->burst_size * NUM_MBUF_SETS. > >> > >> Other algos may also need to update the logic if required. > >> > > > > In which way this patch improves the dequeue logic? > > Is it improving the performance somehow? From what I see, it is > >> unlikely > that you are going to > > experience the problem, as the internal ring is > >> PERF_NUM_OPS_INFLIGHT, > which is 128, > > higher than pparams->burst_size * NUM_MBUF_SETS, which is 256. > > And even if you do meet that problem, then you would be reusing > >> mbufs, > > but that is OK as we are not verifying the output. > > > > > > Thanks, > > Pablo > > > Sorry for the late response. Somehow the reply went to junk in my > mail > client and it got missed. > > The problem would arise if the underlying implementation cannot > >> dequeue > the same number of ops as were enqueued in a single dequeue > >> command. > > Here we have a synchronous calls to enqueue and dequeue in the > same > thread, so it may happen that for every enqueue of 32 ops, there are > lesser number of dequeue ops (say 16). There is no thread to dequeue > >> the > left over 16 ops. So the difference would increase slowly and gradually > and the application will run out of buffers. > So we need a mechanism to drain the left over dequeue ops. > >>> > >>> Hi Akhil, > >>> > >>> I understand, I guess that this won't happen on a software device, but > >> might happen on hardware. > >>> As said, I think it is OK to reuse an mbuf by two different crypto > >> operations, because we don't check the output. > >>> > >>> Anyway, it might be safer to proceed your way. Two things about it, > >> though: > >>> 1 - This should be extended to the other tests (such as > test_perf_openssl) > >> for consistency. > >>> 2 - Since we have the test-crypto-perf app now, which cover all these > >> tests, I was thinking of removing test_cryptodev_perf.c, > >>> to avoid duplications. Any concerns on this? > >>> > >> Hi Pablo, > >> > >> yes, this shall be done for other tests also, but I do not have setup to > >> test all of them. > >> And if we are planning to remove this file altogether, then we may not > >> need it anyway. > >> cperf_throughput_test_runner can alone be modified with my changes, > but > >> I can test on NXP DPAA2 platform only. I can send the patch for this > >> after testing it on DPAA2 platform. > > > > For test-crypto-perf, you cannot encounter this problem, because the > crypto operation pool is > > the same size as the mbuf pool size, so you would run out of crypto > operations before hitting this problem. > > > > Thanks, > > Pablo > > > As I understand correctly, the pool_sz >= total crypto operations, this > means, there is no mbuf getting reused. If yes, then yes my patch is not > required at all. > But, there would be limited number of crypto operations that we can > perform in test-crypto-perf as we may not be able to allocate so many > buffers. Usually, pool size will be smaller than the total number of crypto operations. But pool size is th
Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce device removal event
Am 25.04.2017 11:06 schrieb "Gaëtan Rivet" : Hi Ferruh, On Fri, Apr 21, 2017 at 03:59:24PM +0100, Ferruh Yigit wrote: > On 4/18/2017 1:17 PM, Gaetan Rivet wrote: > >> This new API allows reacting to a device removal. >> A device removal is the sudden disappearance of a device from its >> bus. >> > I don't think this belongs into ethdev. If it is bus related we need to expose this from it so that apps can register for the low level device being unplugged. Jan >> PMDs implementing support for this notification guarantee that the removal >> of the underlying device does not incur a risk to the application. >> >> In particular, Rx/Tx bursts and all other functions can still be called >> (albeit likely returning errors) without triggering a crash, irrespective >> of an application handling this event. >> >> Signed-off-by: Gaetan Rivet >> Signed-off-by: Elad Persiko >> > > <...> > > diff --git a/doc/guides/nics/features/default.ini >> b/doc/guides/nics/features/default.ini >> index b1b9114..cafc6c7 100644 >> --- a/doc/guides/nics/features/default.ini >> +++ b/doc/guides/nics/features/default.ini >> @@ -10,6 +10,7 @@ >> Speed capabilities = >> Link status = >> Link status event= >> +Removal event= >> Queue status event = >> Rx interrupt = >> Free Tx mbuf on demand = >> > > This release a few NIC features added, and it is hard to follow them if > you are particularly looking for these features. > > So do you think does it make sense to put those new PMD features into > release notes to make it more visible? > > Yes it seems like a good idea to announce this evolution. I will send the relevant patch for this soon. Thanks, > ferruh > -- Gaėtan Rivet 6WIND
Re: [dpdk-dev] [PATCH v3] efd: support lookup using neon intrinsics
On 2 May 2017 at 14:41, Jerin Jacob wrote:
> -Original Message-
>> Date: Mon, 1 May 2017 22:59:53 -0700
>> From: Ashwin Sekhar T K
>> To: byron.mar...@intel.com, pablo.de.lara.gua...@intel.com,
>> jerin.ja...@caviumnetworks.com, jianbo@linaro.org
>> Cc: dev@dpdk.org, Ashwin Sekhar T K
>> Subject: [dpdk-dev] [PATCH v3] efd: support lookup using neon intrinsics
>> X-Mailer: git-send-email 2.13.0.rc1
>>
>> * Added file lib/librte_efd/rte_efd_arm64.h to hold arm64
>> specific definitions
>> * Verified the changes with efd_autotest unit test case
>>
>> Signed-off-by: Ashwin Sekhar T K
>> ---
>> v2:
>> * Slightly modified the content of the commit message body
>> * Added prefix [dpdk-dev] to the email subject line
>>
>> v3:
>> * Moved enum 'EFD_LOOKUP_NEON' under '#if defined(RTE_ARCH_ARM64)'
>>
>> MAINTAINERS| 1 +
>> lib/librte_efd/rte_efd.c | 24 +
>> lib/librte_efd/rte_efd_arm64.h | 76
>> ++
>> 3 files changed, 101 insertions(+)
>> create mode 100644 lib/librte_efd/rte_efd_arm64.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index b6495d2..7d708ae 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -147,6 +147,7 @@ F: lib/librte_eal/common/include/arch/arm/*_64.h
>> F: lib/librte_acl/acl_run_neon.*
>> F: lib/librte_lpm/rte_lpm_neon.h
>> F: lib/librte_hash/rte*_arm64.h
>> +F: lib/librte_efd/rte*_arm64.h
>> F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
>> F: drivers/net/i40e/i40e_rxtx_vec_neon.c
>> F: drivers/net/virtio/virtio_rxtx_simple_neon.c
>> diff --git a/lib/librte_efd/rte_efd.c b/lib/librte_efd/rte_efd.c
>> index f601d62..5cc6283 100644
>> --- a/lib/librte_efd/rte_efd.c
>> +++ b/lib/librte_efd/rte_efd.c
>> @@ -53,6 +53,8 @@
>> #include "rte_efd.h"
>> #if defined(RTE_ARCH_X86)
>> #include "rte_efd_x86.h"
>> +#elif defined(RTE_ARCH_ARM64)
>> +#include "rte_efd_arm64.h"
>> #endif
>>
>> #define EFD_KEY(key_idx, table) (table->keys + ((key_idx) * table->key_len))
>> @@ -103,6 +105,9 @@ allocated memory
>> enum efd_lookup_internal_function {
>> EFD_LOOKUP_SCALAR = 0,
>> EFD_LOOKUP_AVX2,
>> +#if defined(RTE_ARCH_ARM64)
>> + EFD_LOOKUP_NEON,
>> +#endif
>
> I think, we can remove this ifdef to
> - Make code looks clean
> - In future, in some case a new enum value gets added then the value
> will be different for each build.
>
But the enum items are same for each ARCH.
Besides, the ifdef could be considered as explanation to that enum. If
someone knows nothing about arm/neon, he can ignore it totally after
see the ifdef.
> Any valid point to keep under RTE_ARCH_ARM64?
>
>> EFD_LOOKUP_NUM
>> };
Re: [dpdk-dev] [PATCH v3] efd: support lookup using neon intrinsics
On Tue, 2017-05-02 at 15:59 +0800, Jianbo Liu wrote:
> On 2 May 2017 at 14:41, Jerin Jacob
> wrote:
> >
> > -Original Message-
> > >
> > > Date: Mon, 1 May 2017 22:59:53 -0700
> > > From: Ashwin Sekhar T K
> > > To: byron.mar...@intel.com, pablo.de.lara.gua...@intel.com,
> > > jerin.ja...@caviumnetworks.com, jianbo@linaro.org
> > > Cc: dev@dpdk.org, Ashwin Sekhar T K > > .com>
> > > Subject: [dpdk-dev] [PATCH v3] efd: support lookup using neon
> > > intrinsics
> > > X-Mailer: git-send-email 2.13.0.rc1
> > >
> > > * Added file lib/librte_efd/rte_efd_arm64.h to hold arm64
> > > specific definitions
> > > * Verified the changes with efd_autotest unit test case
> > >
> > > Signed-off-by: Ashwin Sekhar T K > > m>
> > > ---
> > > v2:
> > > * Slightly modified the content of the commit message body
> > > * Added prefix [dpdk-dev] to the email subject line
> > >
> > > v3:
> > > * Moved enum 'EFD_LOOKUP_NEON' under '#if
> > > defined(RTE_ARCH_ARM64)'
> > >
> > > MAINTAINERS| 1 +
> > > lib/librte_efd/rte_efd.c | 24 +
> > > lib/librte_efd/rte_efd_arm64.h | 76
> > > ++
> > > 3 files changed, 101 insertions(+)
> > > create mode 100644 lib/librte_efd/rte_efd_arm64.h
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index b6495d2..7d708ae 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -147,6 +147,7 @@ F:
> > > lib/librte_eal/common/include/arch/arm/*_64.h
> > > F: lib/librte_acl/acl_run_neon.*
> > > F: lib/librte_lpm/rte_lpm_neon.h
> > > F: lib/librte_hash/rte*_arm64.h
> > > +F: lib/librte_efd/rte*_arm64.h
> > > F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
> > > F: drivers/net/i40e/i40e_rxtx_vec_neon.c
> > > F: drivers/net/virtio/virtio_rxtx_simple_neon.c
> > > diff --git a/lib/librte_efd/rte_efd.c b/lib/librte_efd/rte_efd.c
> > > index f601d62..5cc6283 100644
> > > --- a/lib/librte_efd/rte_efd.c
> > > +++ b/lib/librte_efd/rte_efd.c
> > > @@ -53,6 +53,8 @@
> > > #include "rte_efd.h"
> > > #if defined(RTE_ARCH_X86)
> > > #include "rte_efd_x86.h"
> > > +#elif defined(RTE_ARCH_ARM64)
> > > +#include "rte_efd_arm64.h"
> > > #endif
> > >
> > > #define EFD_KEY(key_idx, table) (table->keys + ((key_idx) *
> > > table->key_len))
> > > @@ -103,6 +105,9 @@ allocated memory
> > > enum efd_lookup_internal_function {
> > > EFD_LOOKUP_SCALAR = 0,
> > > EFD_LOOKUP_AVX2,
> > > +#if defined(RTE_ARCH_ARM64)
> > > + EFD_LOOKUP_NEON,
> > > +#endif
> > I think, we can remove this ifdef to
> > - Make code looks clean
> > - In future, in some case a new enum value gets added then the
> > value
> > will be different for each build.
> >
> But the enum items are same for each ARCH.
> Besides, the ifdef could be considered as explanation to that enum.
> If
> someone knows nothing about arm/neon, he can ignore it totally after
> see the ifdef.
>
Have added the #if defined on your advice, but in my opinion also its
better not to have "#if defined" for enums. Because the same enum can
take different values for different builds.
For eg: If somebody adds an EFD_LOOKUP_AVX512 after EFD_LOOKUP_NEON
here, it will take value 2 for x86 builds but value 3 for arm64 builds.
> >
> > Any valid point to keep under RTE_ARCH_ARM64?
> >
> > >
> > > EFD_LOOKUP_NUM
> > > };
Re: [dpdk-dev] [PATCH] net/e1000: fix checksum valid flags error
Hi Wei,
> -Original Message-
> From: Zhao1, Wei
> Sent: Tuesday, May 2, 2017 10:46 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo; Zhao1, Wei
> Subject: [PATCH] net/e1000: fix checksum valid flags error
>
> This problem is caused by a missing set of E1000_RXCSUM_CRCOFL in
> eth_igb_rx_init(), it should be set to enable SCTP packet
> L4 checksum.If it is not set, the printf message in cksum fwd about L4 SCTP
> cksum flag is error.
It's not quite clear what's the issue. Would you like to add more details?
Thanks.
>
> Fixes: d15fcf76c8b7 ("net/e1000: move to drivers/net/")
Seems it's not the right patch. Suppose this patch only moves the files.
>
> Signed-off-by: Wei Zhao
> ---
> drivers/net/e1000/igb_rxtx.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c index
> b3b601b..6c2749b 100644
> --- a/drivers/net/e1000/igb_rxtx.c
> +++ b/drivers/net/e1000/igb_rxtx.c
> @@ -2402,10 +2402,11 @@ eth_igb_rx_init(struct rte_eth_dev *dev)
>
> /* Enable both L3/L4 rx checksum offload */
> if (dev->data->dev_conf.rxmode.hw_ip_checksum)
> - rxcsum |= (E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL);
> + rxcsum |= (E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL |
> + E1000_RXCSUM_CRCOFL);
> else
> - rxcsum &= ~(E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL);
> - E1000_WRITE_REG(hw, E1000_RXCSUM, rxcsum);
> + rxcsum &= ~(E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL
> |
> + E1000_RXCSUM_CRCOFL);
>
> /* Setup the Receive Control Register. */
> if (dev->data->dev_conf.rxmode.hw_strip_crc) {
> --
> 2.9.3
[dpdk-dev] [PATCH] net/ixgbe: fix default MAC setting
Pool 0 is not PF, it's VF 0. So the MAC is set for VF 0
but not PF.
The code introduced a weird issue. In the scenario PF + VF,
when only starting PF, the default PF MAC address is working.
But after starting a VF, the default PF MAC address becomes
the VF's address.
Use the pool which is not occupied by VFs for PF to fix it.
Fixes: 8164fe82846b ("ixgbe: add default mac address modifier")
Cc: sta...@dpdk.org
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/ixgbe_ethdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index bbae4f9..9ddd685 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -4658,9 +4658,11 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused
struct rte_eth_dev *dev,
static void
ixgbe_set_default_mac_addr(struct rte_eth_dev *dev, struct ether_addr *addr)
{
+ struct rte_pci_device *pci_dev = IXGBE_DEV_TO_PCI(dev);
+
ixgbe_remove_rar(dev, 0);
- ixgbe_add_rar(dev, addr, 0, 0);
+ ixgbe_add_rar(dev, addr, 0, pci_dev->max_vfs);
}
static bool
--
1.9.3
Re: [dpdk-dev] [PATCH] net/e1000: fix checksum valid flags error
Hi, wenzhuo
> -Original Message-
> From: Lu, Wenzhuo
> Sent: Tuesday, May 2, 2017 4:14 PM
> To: Zhao1, Wei ; dev@dpdk.org
> Subject: RE: [PATCH] net/e1000: fix checksum valid flags error
>
> Hi Wei,
>
> > -Original Message-
> > From: Zhao1, Wei
> > Sent: Tuesday, May 2, 2017 10:46 AM
> > To: dev@dpdk.org
> > Cc: Lu, Wenzhuo; Zhao1, Wei
> > Subject: [PATCH] net/e1000: fix checksum valid flags error
> >
> > This problem is caused by a missing set of E1000_RXCSUM_CRCOFL in
> > eth_igb_rx_init(), it should be set to enable SCTP packet
> > L4 checksum.If it is not set, the printf message in cksum fwd about L4
> > SCTP cksum flag is error.
> It's not quite clear what's the issue. Would you like to add more details?
> Thanks.
>
> >
> > Fixes: d15fcf76c8b7 ("net/e1000: move to drivers/net/")
> Seems it's not the right patch. Suppose this patch only moves the files.
I will fix it in v2.
>
> >
> > Signed-off-by: Wei Zhao
> > ---
> > drivers/net/e1000/igb_rxtx.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/e1000/igb_rxtx.c
> > b/drivers/net/e1000/igb_rxtx.c index b3b601b..6c2749b 100644
> > --- a/drivers/net/e1000/igb_rxtx.c
> > +++ b/drivers/net/e1000/igb_rxtx.c
> > @@ -2402,10 +2402,11 @@ eth_igb_rx_init(struct rte_eth_dev *dev)
> >
> > /* Enable both L3/L4 rx checksum offload */
> > if (dev->data->dev_conf.rxmode.hw_ip_checksum)
> > - rxcsum |= (E1000_RXCSUM_IPOFL |
> E1000_RXCSUM_TUOFL);
> > + rxcsum |= (E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL
> |
> > + E1000_RXCSUM_CRCOFL);
> > else
> > - rxcsum &= ~(E1000_RXCSUM_IPOFL |
> E1000_RXCSUM_TUOFL);
> > - E1000_WRITE_REG(hw, E1000_RXCSUM, rxcsum);
> > + rxcsum &= ~(E1000_RXCSUM_IPOFL |
> E1000_RXCSUM_TUOFL
> > |
> > + E1000_RXCSUM_CRCOFL);
> >
> > /* Setup the Receive Control Register. */
> > if (dev->data->dev_conf.rxmode.hw_strip_crc) {
> > --
> > 2.9.3
[dpdk-dev] [PATCH v2] net/e1000: fix checksum valid flags error
This problem is caused by a missing set of E1000_RXCSUM_CRCOFL
in eth_igb_rx_init(), it should be set to enable SCTP packet
L4 checksum.If it is not set, the printf message in cksum fwd
about L4 SCTP cksum flag is error.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Wei Zhao
---
Changes in v2:
fix patch log error in fixes information.
---
drivers/net/e1000/igb_rxtx.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
index b3b601b..6c2749b 100644
--- a/drivers/net/e1000/igb_rxtx.c
+++ b/drivers/net/e1000/igb_rxtx.c
@@ -2402,10 +2402,11 @@ eth_igb_rx_init(struct rte_eth_dev *dev)
/* Enable both L3/L4 rx checksum offload */
if (dev->data->dev_conf.rxmode.hw_ip_checksum)
- rxcsum |= (E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL);
+ rxcsum |= (E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL |
+ E1000_RXCSUM_CRCOFL);
else
- rxcsum &= ~(E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL);
- E1000_WRITE_REG(hw, E1000_RXCSUM, rxcsum);
+ rxcsum &= ~(E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL |
+ E1000_RXCSUM_CRCOFL);
/* Setup the Receive Control Register. */
if (dev->data->dev_conf.rxmode.hw_strip_crc) {
--
2.9.3
[dpdk-dev] [PATCH v2] net/e1000: fix checksum valid flags error
This problem is caused by a missing set of E1000_RXCSUM_CRCOFL
in eth_igb_rx_init(), it should be set to enable SCTP packet
L4 checksum.If it is not set, the printf message in cksum fwd
about L4 SCTP cksum flag is error.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Wei Zhao
---
Changes in v2:
fix patch log error in fixes information.
---
drivers/net/e1000/igb_rxtx.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
index b3b601b..6c2749b 100644
--- a/drivers/net/e1000/igb_rxtx.c
+++ b/drivers/net/e1000/igb_rxtx.c
@@ -2402,10 +2402,11 @@ eth_igb_rx_init(struct rte_eth_dev *dev)
/* Enable both L3/L4 rx checksum offload */
if (dev->data->dev_conf.rxmode.hw_ip_checksum)
- rxcsum |= (E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL);
+ rxcsum |= (E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL |
+ E1000_RXCSUM_CRCOFL);
else
- rxcsum &= ~(E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL);
- E1000_WRITE_REG(hw, E1000_RXCSUM, rxcsum);
+ rxcsum &= ~(E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL |
+ E1000_RXCSUM_CRCOFL);
/* Setup the Receive Control Register. */
if (dev->data->dev_conf.rxmode.hw_strip_crc) {
--
2.9.3
Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce device removal event
02/05/2017 09:35, Jan Blunck: > Am 25.04.2017 11:06 schrieb "Gaëtan Rivet" : > > Hi Ferruh, > > > On Fri, Apr 21, 2017 at 03:59:24PM +0100, Ferruh Yigit wrote: > > > On 4/18/2017 1:17 PM, Gaetan Rivet wrote: > > > >> This new API allows reacting to a device removal. > >> A device removal is the sudden disappearance of a device from its > >> bus. > >> > > > I don't think this belongs into ethdev. If it is bus related we need to > expose this from it so that apps can register for the low level device > being unplugged. Yes it sounds right. We could work on device notifications. We need to find a way of notifying the application that there is a device event and that it affects one or more port at ethdev/cryptodev/eventdev level.
Re: [dpdk-dev] [dpdk-users] Adding multiple fields as key in ip_pipeline application
Hi, Can we do the append/prepend (of the port id with vlan id) through config file? Thanks, Nidhia On Fri, Apr 28, 2017 at 7:24 PM, Singh, Jasvinder wrote: > Hi Nidhia, > > > I am developing an application in which I need to use both incoming port > and vlan as the key for the flow table. Port field is available at 24th > byte of mbuf and vlan(single tagged) will be at 268th byte (128 mbuf + 128 > headroom + 12 ethernet header). > How can I represent this in my config file in the src_mask field? > Is there any way to take these fields separately and keep in headroom and > then use them to calculate hash for lookup? > > > [Jasvinder] - If you look at edge_router_upstream.cfg, pass-through > pipeline have mask and offset defined for extracting the key from the > packet header and storing in the headroom at the offset 128. This key is > used in flow_classification pipeline to classify the flows. You can follow > similar approach by using pass-through pipeline doing that action at the > input port. For that, define mask () and offset fields for > extracting the vlan-tag from the packet in pass-through pipeline and store > at the desired offset in the headroom and prepend the vlan tag stored in > the metadata with port id read from mbuf. In flow-classification pipeline, > you can specify the headroom offset and mask to read the final key > (portid+vlan tag) stored in the packet-metadata for classification. > > > > Thanks for your reply and help. > > > Regards, > Nidhia Varghese > -- Regards, Nidhia Varghese
Re: [dpdk-dev] [PATCH] app/testpmd: add bus info when display port info
02/05/2017 03:58, Pei, Yulong:
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > 26/04/2017 06:31, Yulong Pei:
> > > Display pci device bus info when show port info.
> > >
> > > Signed-off-by: Yulong Pei
> > > ---
> > > --- a/app/test-pmd/config.c
> > > +++ b/app/test-pmd/config.c
> > > @@ -469,6 +469,14 @@ port_infos_display(portid_t port_id)
> > >
> > > print_ethaddr("MAC address: ", &mac_addr);
> > > printf("\nDriver name: %s", dev_info.driver_name);
> > > printf("\nConnect to socket: %u", port->socket_id);
> > >
> > > + if (dev_info.pci_dev)
> > > + printf("\nBus-info: %04x:%02x:%02x:%x",
> > > + dev_info.pci_dev->addr.domain,
> > > + dev_info.pci_dev->addr.bus,
> > > + dev_info.pci_dev->addr.devid,
> > > + dev_info.pci_dev->addr.function);
> > > + else
> > > + printf("\nBus-info: N/A");
> >
> > The bus information must be managed in a more generic way.
> > The field pci_dev will probably be removed in a next release.
>
> Could you kind to tell me more information about what does "more generic way"
> mean ?
It means we should not have a PCI field in ethdev.
We should have a function to print a bus info in each bus implementation,
and a generic function taking a rte_device object would call the right
bus-specific function via a function pointer.
Re: [dpdk-dev] [PATCH 2/5] examples/l3fwd: rename l3fwd_em_sse.h to l3fwd_em_single.h
On Tue, 2017-05-02 at 15:14 +0800, Jianbo Liu wrote:
> The l3fwd_em_sse.h is enabled by NO_HASH_LOOKUP_MULTI.
> Renaming it because it's only for single hash lookup,
> and doesn't include any x86 SSE instructions.
>
> Signed-off-by: Jianbo Liu
> ---
> examples/l3fwd/l3fwd_em.c| 2 +-
> examples/l3fwd/{l3fwd_em_sse.h => l3fwd_em_single.h} | 0
> 2 files changed, 1 insertion(+), 1 deletion(-)
> rename examples/l3fwd/{l3fwd_em_sse.h => l3fwd_em_single.h} (100%)
>
> diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
> index 939a16d..cccf797 100644
> --- a/examples/l3fwd/l3fwd_em.c
> +++ b/examples/l3fwd/l3fwd_em.c
> @@ -330,7 +330,7 @@ struct ipv6_l3fwd_em_route {
>
> #if defined(__SSE4_1__)
> #if defined(NO_HASH_MULTI_LOOKUP)
> -#include "l3fwd_em_sse.h"
> +#include "l3fwd_em_single.h"
> #else
> #include "l3fwd_em_hlm.h"
> #endif
> diff --git a/examples/l3fwd/l3fwd_em_sse.h
> b/examples/l3fwd/l3fwd_em_single.h
> similarity index 100%
> rename from examples/l3fwd/l3fwd_em_sse.h
> rename to examples/l3fwd/l3fwd_em_single.h
Shouldn't the guard __L3FWD_EM_SSE_H__ be update
to __L3FWD_EM_SINGLE_H__ to maintain consistency ?
Thanks and Regards,
Ashwin
Re: [dpdk-dev] [PATCH v2] app/testpmd: configure event display
02/05/2017 09:03, Gaetan Rivet: > * ``--bitrate-stats=N`` > > Set the logical core N to perform bitrate calculation. > + > +* ``--print-event > `` > + > + Enable printing the occurrence of the designated event. > + > +* ``--mask-event > `` > + > + Disable printing the occurrence of the designated event. You are missing alignment here.
Re: [dpdk-dev] [PATCH] doc: announce crypto structures rework
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara > Sent: Friday, April 28, 2017 7:07 PM > To: dev@dpdk.org > Cc: Doherty, Declan ; akhil.go...@nxp.com; > hemant.agra...@nxp.com; zbigniew.bo...@caviumnetworks.com; > jerin.ja...@caviumnetworks.com; De Lara Guarch, Pablo > > Subject: [dpdk-dev] [PATCH] doc: announce crypto structures rework > > The current crypto operation and symmetric crypto operation structures > will be reworked for correctness and improvement, reducing also their > sizes, to fit into less cache lines, as stated in the following RFC: > > http://dpdk.org/dev/patchwork/patch/24011/ > > Signed-off-by: Pablo de Lara Acked-by: John McNamara
[dpdk-dev] [PATCH v3] app/testpmd: configure event display
Add two parameters to testpmd:
--print-event
--mask-event
To enable or disable to printing of events. This display is configured
on a per-event basis. By default, all except VF_MBOX are displayed.
Fixes: 76ad4a2d82d4 ("app/testpmd: add generic event handler")
Cc: "Lu, Wenzhuo"
Signed-off-by: Gaetan Rivet
---
Additionally, I'm thinking about runtime commands for events, in the form
event show
event print
where show could display the state of the display for this event as well
as statistics for the event. print on|off would do the same as the two
parameters introduced by this patch.
But this is a little heavier and I wanted to propose this fix as soon as
possible.
v1 -> v2:
* Rebased on top of master
* Fixed typos in doc
v2 -> v3:
* Fixed doc alignment issues.
---
app/test-pmd/parameters.c | 46 +++
app/test-pmd/testpmd.c| 13 +-
app/test-pmd/testpmd.h| 2 ++
doc/guides/testpmd_app_ug/run_app.rst | 8 ++
4 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 787e143..5a07dea 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -206,6 +206,10 @@ usage(char* progname)
printf(" --no-rmv-interrupt: disable device removal interrupt.\n");
printf(" --bitrate-stats=N: set the logical core N to perform "
"bit-rate calculation.\n");
+ printf(" --print-event
: "
+ "enable print of designated event");
+ printf(" --mask-event
: "
+ "disable print of designated event");
}
#ifdef RTE_LIBRTE_CMDLINE
@@ -503,6 +507,36 @@ parse_ringnuma_config(const char *q_arg)
return 0;
}
+static int
+parse_event_printing_config(const char *optarg, int enable)
+{
+ uint32_t mask = 0;
+
+ if (!strcmp(optarg, "unknown"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_UNKNOWN;
+ else if (!strcmp(optarg, "intr_lsc"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_INTR_LSC;
+ else if (!strcmp(optarg, "queue_state"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_QUEUE_STATE;
+ else if (!strcmp(optarg, "intr_reset"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_INTR_RESET;
+ else if (!strcmp(optarg, "vf_mbox"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_VF_MBOX;
+ else if (!strcmp(optarg, "macsec"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_MACSEC;
+ else if (!strcmp(optarg, "intr_rmv"))
+ mask = UINT32_C(1) << RTE_ETH_EVENT_INTR_RMV;
+ else {
+ fprintf(stderr, "Invalid event: %s\n", optarg);
+ return -1;
+ }
+ if (enable)
+ event_print_mask |= mask;
+ else
+ event_print_mask &= ~mask;
+ return 0;
+}
+
void
launch_args_parse(int argc, char** argv)
{
@@ -581,6 +615,8 @@ launch_args_parse(int argc, char** argv)
{ "disable-link-check", 0, 0, 0 },
{ "no-lsc-interrupt", 0, 0, 0 },
{ "no-rmv-interrupt", 0, 0, 0 },
+ { "print-event",1, 0, 0 },
+ { "mask-event", 1, 0, 0 },
{ 0, 0, 0, 0 },
};
@@ -1036,6 +1072,16 @@ launch_args_parse(int argc, char** argv)
lsc_interrupt = 0;
if (!strcmp(lgopts[opt_idx].name, "no-rmv-interrupt"))
rmv_interrupt = 0;
+ if (!strcmp(lgopts[opt_idx].name, "print-event"))
+ if (parse_event_printing_config(optarg, 1)) {
+ rte_exit(EXIT_FAILURE,
+"invalid print-event
argument\n");
+ }
+ if (!strcmp(lgopts[opt_idx].name, "mask-event"))
+ if (parse_event_printing_config(optarg, 0)) {
+ rte_exit(EXIT_FAILURE,
+"invalid mask-event
argument\n");
+ }
break;
case 'h':
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index dfe6442..b9c385e 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -282,6 +282,17 @@ uint8_t lsc_interrupt = 1; /* enabled by default */
uint8_t rmv_interrupt = 1; /* enabled by default */
/*
+ * Display or mask ether events
+ * Default to all events except VF_MBOX
+ */
+uint32_t event_print_mask = (UINT32_C(1) << RTE_ETH_EVENT_UNKNOWN) |
+ (UINT32_C(1) << RTE_ETH_EVENT_INTR_LSC) |
+ (UINT32_C(1) << RTE_ETH_EVENT_QUEUE_STATE) |
+ (UINT32_C(1) << RTE_ETH_EVENT_INTR_RESET) |
+ (UINT32_C(1
Re: [dpdk-dev] [dpdk-users] Adding multiple fields as key in ip_pipeline application
From: Nidhia Varghese [mailto:nidhiavarghes...@gmail.com] Sent: Tuesday, May 2, 2017 10:29 AM To: Singh, Jasvinder Cc: dev@dpdk.org; us...@dpdk.org Subject: Re: [dpdk-users] Adding multiple fields as key in ip_pipeline application Hi, Can we do the append/prepend (of the port id with vlan id) through config file? [Jasvinder] - No, there isn’t anything defined for prepend or append the field through configuration file. You have to copy the desired field manually at the location adjacent to existing field in the mbuf headroom. Thanks, Nidhia
Re: [dpdk-dev] [PATCH v2] app/testpmd: add bitrate stats option
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, May 01, 2017 9:22 PM
> To: Patil, Harish; Horton, Remy
> Cc: dev@dpdk.org; De Lara Guarch, Pablo; Wu, Jingjing
> Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: add bitrate stats option
>
> 01/05/2017 22:07, Patil, Harish:
> > Hi Remy,
> > Have a small suggestion here.
> > Since testpmd uses new libraries of librte_latencystats and
> > librte_bitratestats it hurts packet processing performance.
> > Many users who use testpmd to do the initial performance benchmarks
> may
> > not be aware of such a feature is default enabled.
>
> Yes, the default config of testpmd must give good performance.
>
> > So can we disable this feature by default in the config?
> > * CONFIG_RTE_LIBRTE_BITRATE=n
> > * CONFIG_RTE_LIBRTE_LATENCY_STATS=n
> > Only those folks interested in latency/jitter measurements can recompile
> > with those configs enabled.
>
> I disagree about compile-time options.
> It should be a run-time option of testpmd.
>
> Please Remy (or others),
> disable the metrics in the default configuration of testpmd,
> before the 17.05 release.
> You have few days, it is urgent.
Bitrate stats are disabled by default, in testpmd.
I assume that the code that you want to avoid is:
for (sm_id = 0; sm_id < nb_fs; sm_id++)
(*pkt_fwd)(fsm[sm_id]);
#ifdef RTE_LIBRTE_BITRATE
if (bitrate_enabled != 0 &&
bitrate_lcore_id == rte_lcore_id()) {
tics_current = rte_rdtsc();
if (tics_current - tics_datum >= tics_per_1sec) {
Unless --bitrate-stats is used, bitrate_enabled = 0, so all this code won't be
run.
I can send a patch to check the latencystats_enabled flag first, following the
approach above, here:
#ifdef RTE_LIBRTE_LATENCY_STATS
if (latencystats_lcore_id == rte_lcore_id())
Thanks,
Pablo
Re: [dpdk-dev] [PATCH 5/5] examples/l3fwd: add neon support for l3fwd
Hi,
Please find comments inline.
On Tue, 2017-05-02 at 15:14 +0800, Jianbo Liu wrote:
> Use ARM NEON intrinsics to accelerate l3 fowarding.
>
> Signed-off-by: Jianbo Liu
> ---
> examples/l3fwd/l3fwd.h | 4 -
> examples/l3fwd/l3fwd_em.c | 4 +-
> examples/l3fwd/l3fwd_em_hlm.h | 5 +
> examples/l3fwd/l3fwd_em_hlm_neon.h | 74 +++
> examples/l3fwd/l3fwd_em_single.h | 4 +
> examples/l3fwd/l3fwd_lpm.c | 4 +-
> examples/l3fwd/l3fwd_lpm_neon.h| 157 ++
> examples/l3fwd/l3fwd_neon.h| 259
> +
> 8 files changed, 504 insertions(+), 7 deletions(-)
> create mode 100644 examples/l3fwd/l3fwd_em_hlm_neon.h
> create mode 100644 examples/l3fwd/l3fwd_lpm_neon.h
> create mode 100644 examples/l3fwd/l3fwd_neon.h
>
> diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
> index 011ba14..c45589a 100644
> --- a/examples/l3fwd/l3fwd.h
> +++ b/examples/l3fwd/l3fwd.h
> @@ -40,10 +40,6 @@
>
> #define RTE_LOGTYPE_L3FWD RTE_LOGTYPE_USER1
>
> -#if !defined(NO_HASH_MULTI_LOOKUP) &&
> defined(RTE_MACHINE_CPUFLAG_NEON)
> -#define NO_HASH_MULTI_LOOKUP 1
> -#endif
> -
> #define MAX_PKT_BURST 32
> #define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
>
> diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
> index cccf797..ac1e2e0 100644
> --- a/examples/l3fwd/l3fwd_em.c
> +++ b/examples/l3fwd/l3fwd_em.c
> @@ -328,7 +328,7 @@ struct ipv6_l3fwd_em_route {
> return (uint8_t)((ret < 0) ? portid :
> ipv6_l3fwd_out_if[ret]);
> }
>
> -#if defined(__SSE4_1__)
> +#if defined(__SSE4_1__) || defined(RTE_MACHINE_CPUFLAG_NEON)
> #if defined(NO_HASH_MULTI_LOOKUP)
> #include "l3fwd_em_single.h"
> #else
> @@ -709,7 +709,7 @@ struct ipv6_l3fwd_em_route {
> if (nb_rx == 0)
> continue;
>
> -#if defined(__SSE4_1__)
> +#if defined(__SSE4_1__) || defined(RTE_MACHINE_CPUFLAG_NEON)
> l3fwd_em_send_packets(nb_rx, pkts_burst,
> portid,
> qconf);
> #else
> diff --git a/examples/l3fwd/l3fwd_em_hlm.h
> b/examples/l3fwd/l3fwd_em_hlm.h
> index 636dea4..3329c1a 100644
> --- a/examples/l3fwd/l3fwd_em_hlm.h
> +++ b/examples/l3fwd/l3fwd_em_hlm.h
> @@ -35,8 +35,13 @@
> #ifndef __L3FWD_EM_HLM_H__
> #define __L3FWD_EM_HLM_H__
>
> +#if defined(__SSE4_1__)
> #include "l3fwd_sse.h"
> #include "l3fwd_em_hlm_sse.h"
> +#elif defined(RTE_MACHINE_CPUFLAG_NEON)
> +#include "l3fwd_neon.h"
> +#include "l3fwd_em_hlm_neon.h"
> +#endif
>
> static inline __attribute__((always_inline)) void
> em_get_dst_port_ipv4x8(struct lcore_conf *qconf, struct rte_mbuf
> *m[8],
> diff --git a/examples/l3fwd/l3fwd_em_hlm_neon.h
> b/examples/l3fwd/l3fwd_em_hlm_neon.h
> new file mode 100644
> index 000..dae1acf
> --- /dev/null
> +++ b/examples/l3fwd/l3fwd_em_hlm_neon.h
> @@ -0,0 +1,74 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright(c) 2016 Intel Corporation. All rights reserved.
> + * Copyright(c) 2017, Linaro Limited
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or
> without
> + * modification, are permitted provided that the following
> conditions
> + * are met:
> + *
> + * * Redistributions of source code must retain the above
> copyright
> + * notice, this list of conditions and the following
> disclaimer.
> + * * Redistributions in binary form must reproduce the above
> copyright
> + * notice, this list of conditions and the following
> disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + * * Neither the name of Intel Corporation nor the names of its
> + * contributors may be used to endorse or promote products
> derived
> + * from this software without specific prior written
> permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> + */
> +
> +#ifndef __L3FWD_EM_HLM_NEON_H__
> +#define __L3FWD_EM_HLM_NEON_H__
> +
> +#include
> +
> +static inline void
> +get_ipv4_5tuple(struct rte_mbuf *m0, int32x4_t mask0,
>
[dpdk-dev] [PATCH] doc: fix incorrect indexing
Because of extra space before each list item, indexing numbers
generated by Sphinx were same.
Signed-off-by: Shreyansh Jain
---
**
Current documentation has same numbering for top 3 list items, but
thereafter numbering is correct even with space. Not sure what is
wrong - but, removing space fixes complete indexing.
Also, no MAINTAINER listing is appearing for this file
**
doc/guides/prog_guide/extend_dpdk.rst | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/doc/guides/prog_guide/extend_dpdk.rst
b/doc/guides/prog_guide/extend_dpdk.rst
index 51f0b5c..73d8199 100644
--- a/doc/guides/prog_guide/extend_dpdk.rst
+++ b/doc/guides/prog_guide/extend_dpdk.rst
@@ -39,14 +39,14 @@ Example: Adding a New Library libfoo
To add a new library to the DPDK, proceed as follows:
-#. Add a new configuration option:
+#. Add a new configuration option:
.. code-block:: bash
for f in config/\*; do \
echo CONFIG_RTE_LIBFOO=y >> $f; done
-#. Create a new directory with sources:
+#. Create a new directory with sources:
.. code-block:: console
@@ -54,7 +54,7 @@ To add a new library to the DPDK, proceed as follows:
touch ${RTE_SDK}/lib/libfoo/foo.c
touch ${RTE_SDK}/lib/libfoo/foo.h
-#. Add a foo() function in libfoo.
+#. Add a foo() function in libfoo.
Definition is in foo.c:
@@ -71,7 +71,7 @@ To add a new library to the DPDK, proceed as follows:
extern void foo(void);
-#. Update lib/Makefile:
+#. Update lib/Makefile:
.. code-block:: console
@@ -79,7 +79,7 @@ To add a new library to the DPDK, proceed as follows:
# add:
# DIRS-$(CONFIG_RTE_LIBFOO) += libfoo
-#. Create a new Makefile for this library, for example, derived from mempool
Makefile:
+#. Create a new Makefile for this library, for example, derived from mempool
Makefile:
.. code-block:: console
@@ -91,11 +91,11 @@ To add a new library to the DPDK, proceed as follows:
# rte_mempool -> foo
-#. Update mk/DPDK.app.mk, and add -lfoo in LDLIBS variable when the option is
enabled.
-This will automatically add this flag when linking a DPDK application.
+#. Update mk/DPDK.app.mk, and add -lfoo in LDLIBS variable when the option is
enabled.
+ This will automatically add this flag when linking a DPDK application.
-#. Build the DPDK with the new library (we only show a specific target here):
+#. Build the DPDK with the new library (we only show a specific target here):
.. code-block:: console
@@ -104,7 +104,7 @@ To add a new library to the DPDK, proceed as follows:
make
-#. Check that the library is installed:
+#. Check that the library is installed:
.. code-block:: console
--
2.7.4
Re: [dpdk-dev] [PATCH 5/5] examples/l3fwd: add neon support for l3fwd
Hi Jianbo, I tested your neon changes on thunderx. I am seeing a performance regression of ~10% for LPM case and ~20% for EM case with your changes. Did you see improvement on any arm64 platform with these changes. If yes, how much was the improvement? FYI, I had also tried vectorizing the l3fwd app with neon. Few of the optimizations that I can suggest that helped in my case. * Packet data prefetch is missing in the x86 sse version compared to the scalar version (l3fwd_lpm_send_packets vs l3fwd_lpm_no_opt_send_packets) . I couldn't understand why this was not done in x86. But adding the prefetch was improving performance for thunderx. * Offsets to some packet elements like eth_hdr, ip header, packet type etc. are recalculated in different functions. Calculating them once, caching them and passing them directly to different functions was improving performance. * There are 3 different loops in l3fwd_lpm_send_packets where we iterate over the packets. One each for processx4_step1 and processx4_step2 and one in send_packets_multi. Unifying these loops were also helping. Thanks and Regards Ashwin
[dpdk-dev] [PATCH] doc: fix directory err in virtio guide
Signed-off-by: Yong Wang --- doc/guides/nics/virtio.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst index e1a80dc..91bedea 100644 --- a/doc/guides/nics/virtio.rst +++ b/doc/guides/nics/virtio.rst @@ -321,7 +321,7 @@ To support Rx interrupts, .. code-block:: console -python tools/dpdk-devbind.py -b vfio-pci 00:03.0 +python usertools/dpdk-devbind.py -b vfio-pci 00:03.0 Example ~~~ -- 1.8.3.1
Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce device removal event
On Tue, May 02, 2017 at 11:18:06AM +0200, Thomas Monjalon wrote: 02/05/2017 09:35, Jan Blunck: Am 25.04.2017 11:06 schrieb "Gaëtan Rivet" : Hi Ferruh, On Fri, Apr 21, 2017 at 03:59:24PM +0100, Ferruh Yigit wrote: > On 4/18/2017 1:17 PM, Gaetan Rivet wrote: > >> This new API allows reacting to a device removal. >> A device removal is the sudden disappearance of a device from its >> bus. >> > I don't think this belongs into ethdev. If it is bus related we need to expose this from it so that apps can register for the low level device being unplugged. Yes it sounds right. We could work on device notifications. We need to find a way of notifying the application that there is a device event and that it affects one or more port at ethdev/cryptodev/eventdev level. This is interesting. I developed this event with an easier integration in v17.05 in mind. It needs a proper generic implementation however (as suggested in [1]). I tried to have this discussion earlier[2], but without much interest. However, even with a bus-level event framework, we still need a way for drivers to advertize their support for specific events, and we still need to differentiate devices that are ready for specific events from those that do not. So I agree that it would be interesting to have a generic rte_device level interrupt framework to support generic events accross the whole board, but I'm not sure it would make the dichotomy between the *driver support* flag and the *device enabled* flag disappear. Regards, -- [1]: http://dpdk.org/ml/archives/dev/2017-April/064190.html [2]: http://dpdk.org/ml/archives/dev/2017-March/060998.html -- Gaëtan Rivet 6WIND
Re: [dpdk-dev] [PATCH] doc: fix incorrect indexing
> -Original Message- > From: Shreyansh Jain [mailto:shreyansh.j...@nxp.com] > Sent: Tuesday, May 2, 2017 12:45 PM > To: tho...@monjalon.net; Mcnamara, John > Cc: dev@dpdk.org; Shreyansh Jain > Subject: [PATCH] doc: fix incorrect indexing > > Because of extra space before each list item, indexing numbers generated > by Sphinx were same. > > Signed-off-by: Shreyansh Jain Acked-by: John McNamara
Re: [dpdk-dev] [PATCH] doc: fix directory err in virtio guide
> -Original Message- > From: Yong Wang [mailto:wang.yon...@zte.com.cn] > Sent: Tuesday, May 2, 2017 12:54 PM > To: Mcnamara, John > Cc: dev@dpdk.org; Yong Wang > Subject: [PATCH] doc: fix directory err in virtio guide > > Signed-off-by: Yong Wang Acked-by: John McNamara
Re: [dpdk-dev] [PATCH] doc: fix directory err in virtio guide
02/05/2017 13:54, Yong Wang: > -python tools/dpdk-devbind.py -b vfio-pci 00:03.0 > +python usertools/dpdk-devbind.py -b vfio-pci 00:03.0 There is another occurence in doc/guides/howto/pvp_reference_benchmark.rst
[dpdk-dev] [PATCH v1] doc: fix usertools path in pvp benchmark doc
Update doc to the new dpdk-devbind.py usertools path.
Fixes: 58a2551a160f ("doc: introduce PVP reference benchmark")
Signed-off-by: John McNamara
---
doc/guides/howto/pvp_reference_benchmark.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/howto/pvp_reference_benchmark.rst
b/doc/guides/howto/pvp_reference_benchmark.rst
index 208e4c7..228b4a2 100644
--- a/doc/guides/howto/pvp_reference_benchmark.rst
+++ b/doc/guides/howto/pvp_reference_benchmark.rst
@@ -366,7 +366,7 @@ Bind the virtio-net devices to DPDK:
.. code-block:: console
- $RTE_SDK/tools/dpdk-devbind.py -b vfio-pci :00:10.0 :00:11.0
+ $RTE_SDK/usertools/dpdk-devbind.py -b vfio-pci :00:10.0 :00:11.0
Start testpmd:
--
2.7.4
[dpdk-dev] [PATCH v6 2/3] doc: change type of return value of adding MAC addr
Add following lines in section of API change in release note. If a MAC address fails to be added without this change, it is still stored and may be regarded as a valid one. This may lead to errors in application. The type of return value of eth_mac_addr_add_t in rte_ethdev.h is changed. Any specific NIC also follows this change. Signed-off-by: Wei Dai Acked-by: John McNamara --- doc/guides/rel_notes/release_17_05.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/guides/rel_notes/release_17_05.rst b/doc/guides/rel_notes/release_17_05.rst index 4b47ae1..0bd07f1 100644 --- a/doc/guides/rel_notes/release_17_05.rst +++ b/doc/guides/rel_notes/release_17_05.rst @@ -489,6 +489,13 @@ ABI Changes * The ``rte_cryptodev_info.sym`` structure has new field ``max_nb_sessions_per_qp`` to support drivers which may support limited number of sessions per queue_pair. +* **Return if the MAC address is added successfully or not.** + + If a MAC address fails to be added without this change, it is still stored + and may be regarded as a valid one. This may lead to errors in application. + The type of return value of eth_mac_addr_add_t in rte_ethdev.h is changed. + Any specific NIC also follows this change. + Removed Items - -- 2.7.4
[dpdk-dev] [PATCH v6 0/3] MAC address fail to be added shouldn't be stored
Current ethdev always stores MAC address even it fails to be added. Other function may regard the failed MAC address valid and lead to some errors. So There is a need to check if the addr is added successfully or not and discard it if it fails. In 3rd patch, add a command "add_more_mac_addr port_id base_mac_addr count" to add more than one MAC address one time. This command can simplify the test for the first patch. Normally a MAC address may fails to be added only after many MAC addresses have been added. Without this command, a tester may only trigger failed MAC address by running many times of testpmd command 'mac_addr add' . For v4 patch set, have got acknowledgements from Nelio Laranjeiro for mlx changes Yuanhan Liu for virtio changes --- Changes v6: 1. rebase master branch to v17.05-rc3 2. not touch e1000 base driver code 3. fix some minor defects v5: 1. rebase master branch 2. add support to drivers/net/ark 3. fix some minor defects v4: 1. rebase master branch 2. follow code style v3: 1. Change return value for some specific NIC according to feedbacks from the community; 2. Add ABI change in release note; 3. Add more detailed commit message. v2: fix warnings and erros from check-git-log.sh and checkpatch.pl Wei Dai (3): ethdev: fix adding invalid MAC addr doc: change type of return value of adding MAC addr app/testpmd: add a command to add many MAC addrs app/test-pmd/cmdline.c | 55 ++ doc/guides/rel_notes/release_17_05.rst | 7 + drivers/net/ark/ark_ethdev.c | 15 ++ drivers/net/bnx2x/bnx2x_ethdev.c | 7 +++-- drivers/net/bnxt/bnxt_ethdev.c | 16 +- drivers/net/e1000/em_ethdev.c | 8 ++--- drivers/net/e1000/igb_ethdev.c | 9 +++--- drivers/net/enic/enic.h| 2 +- drivers/net/enic/enic_ethdev.c | 4 +-- drivers/net/enic/enic_main.c | 9 +++--- drivers/net/fm10k/fm10k_ethdev.c | 3 +- drivers/net/i40e/i40e_ethdev.c | 17 ++- drivers/net/i40e/i40e_ethdev_vf.c | 14 - drivers/net/ixgbe/ixgbe_ethdev.c | 33 drivers/net/mlx4/mlx4.c| 16 ++ drivers/net/mlx5/mlx5.h| 4 +-- drivers/net/mlx5/mlx5_mac.c| 16 ++ drivers/net/qede/qede_ethdev.c | 6 ++-- drivers/net/ring/rte_eth_ring.c| 3 +- drivers/net/virtio/virtio_ethdev.c | 13 lib/librte_ether/rte_ethdev.c | 15 ++ lib/librte_ether/rte_ethdev.h | 2 +- 22 files changed, 184 insertions(+), 90 deletions(-) -- 2.7.4
[dpdk-dev] [PATCH v6 1/3] ethdev: fix adding invalid MAC addr
Some customers find adding MAC addr to VF sometimes can fail,
but it is still stored in dev->data->mac_addrs[ ]. So this
can lead to some errors that assumes the non-zero entry in
dev->data->mac_addrs[ ] is valid.
Following acknowledgements are from specific NIC PMD
maintainer for their managing part.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Wei Dai
Acked-by: Nelio Laranjeiro
Acked-by: Yuanhan Liu
---
drivers/net/ark/ark_ethdev.c | 15 +--
drivers/net/bnx2x/bnx2x_ethdev.c | 7 +--
drivers/net/bnxt/bnxt_ethdev.c | 16
drivers/net/e1000/em_ethdev.c | 8
drivers/net/e1000/igb_ethdev.c | 9 +
drivers/net/enic/enic.h| 2 +-
drivers/net/enic/enic_ethdev.c | 4 ++--
drivers/net/enic/enic_main.c | 9 -
drivers/net/fm10k/fm10k_ethdev.c | 3 ++-
drivers/net/i40e/i40e_ethdev.c | 17 +
drivers/net/i40e/i40e_ethdev_vf.c | 14 +++---
drivers/net/ixgbe/ixgbe_ethdev.c | 33 +
drivers/net/mlx4/mlx4.c| 16 ++--
drivers/net/mlx5/mlx5.h| 4 ++--
drivers/net/mlx5/mlx5_mac.c| 16 ++--
drivers/net/qede/qede_ethdev.c | 6 --
drivers/net/ring/rte_eth_ring.c| 3 ++-
drivers/net/virtio/virtio_ethdev.c | 13 +++--
lib/librte_ether/rte_ethdev.c | 15 +--
lib/librte_ether/rte_ethdev.h | 2 +-
20 files changed, 122 insertions(+), 90 deletions(-)
diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index 83961f5..995c93d 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -71,10 +71,10 @@ static void eth_ark_dev_stats_get(struct rte_eth_dev *dev,
static void eth_ark_dev_stats_reset(struct rte_eth_dev *dev);
static void eth_ark_set_default_mac_addr(struct rte_eth_dev *dev,
struct ether_addr *mac_addr);
-static void eth_ark_macaddr_add(struct rte_eth_dev *dev,
- struct ether_addr *mac_addr,
- uint32_t index,
- uint32_t pool);
+static int eth_ark_macaddr_add(struct rte_eth_dev *dev,
+ struct ether_addr *mac_addr,
+ uint32_t index,
+ uint32_t pool);
static void eth_ark_macaddr_remove(struct rte_eth_dev *dev,
uint32_t index);
@@ -831,7 +831,7 @@ eth_ark_dev_stats_reset(struct rte_eth_dev *dev)
ark->user_ext.stats_reset(dev, ark->user_data);
}
-static void
+static int
eth_ark_macaddr_add(struct rte_eth_dev *dev,
struct ether_addr *mac_addr,
uint32_t index,
@@ -840,12 +840,15 @@ eth_ark_macaddr_add(struct rte_eth_dev *dev,
struct ark_adapter *ark =
(struct ark_adapter *)dev->data->dev_private;
- if (ark->user_ext.mac_addr_add)
+ if (ark->user_ext.mac_addr_add) {
ark->user_ext.mac_addr_add(dev,
mac_addr,
index,
pool,
ark->user_data);
+ return 0;
+ }
+ return -ENOTSUP;
}
static void
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 314e5ea..b79cfdb 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -451,14 +451,17 @@ bnx2x_dev_infos_get(struct rte_eth_dev *dev, __rte_unused
struct rte_eth_dev_inf
dev_info->speed_capa = ETH_LINK_SPEED_10G | ETH_LINK_SPEED_20G;
}
-static void
+static int
bnx2x_mac_addr_add(struct rte_eth_dev *dev, struct ether_addr *mac_addr,
uint32_t index, uint32_t pool)
{
struct bnx2x_softc *sc = dev->data->dev_private;
- if (sc->mac_ops.mac_addr_add)
+ if (sc->mac_ops.mac_addr_add) {
sc->mac_ops.mac_addr_add(dev, mac_addr, index, pool);
+ return 0;
+ }
+ return -ENOTSUP;
}
static void
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 7805221..bb87361 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -618,9 +618,9 @@ static void bnxt_mac_addr_remove_op(struct rte_eth_dev
*eth_dev,
}
}
-static void bnxt_mac_addr_add_op(struct rte_eth_dev *eth_dev,
-struct ether_addr *mac_addr,
-uint32_t index, uint32_t pool)
+static int bnxt_mac_addr_add_op(struct rte_eth_dev *eth_dev,
+ struct ether_addr *mac_addr,
+ uint32_t index, uint32_t pool)
{
struct bnxt *bp = (struct bnxt *)eth_dev->data->dev_private;
struct bnxt_vnic_info *vnic
Re: [dpdk-dev] [PATCH] doc: fix directory err in virtio guide
> -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Tuesday, May 2, 2017 1:39 PM > To: Yong Wang > Cc: dev@dpdk.org; Mcnamara, John > Subject: Re: [dpdk-dev] [PATCH] doc: fix directory err in virtio guide > > 02/05/2017 13:54, Yong Wang: > > -python tools/dpdk-devbind.py -b vfio-pci 00:03.0 > > +python usertools/dpdk-devbind.py -b vfio-pci 00:03.0 > > There is another occurence in doc/guides/howto/pvp_reference_benchmark.rst > I spotted that, ;-), and I sent a separate patch. If that is overkill then maybe fix the subject line for this patch and fix both together. John
[dpdk-dev] [PATCH v6 3/3] app/testpmd: add a command to add many MAC addrs
This patch is added to introduce a testpmd command which
is used to add more than one MAC addresses one time.
This command can simplify the test for the change where
the type of return value of adding MAC address.
Normally a MAC address may fails to be added only after
many MAC addresses have been added.
Without this command, a tester may only trigger failed
MAC address by running many times of testpmd command
'mac_addr add' .
Signed-off-by: Wei Dai
---
app/test-pmd/cmdline.c | 55 ++
1 file changed, 55 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 06c1ce2..f73bb83 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6436,6 +6436,60 @@ cmdline_parse_inst_t cmd_mac_addr = {
},
};
+/* *** ADD MORE THAN ONE MAC ADDRESS FROM A PORT *** */
+struct cmd_add_more_mac_addr_result {
+ cmdline_fixed_string_t mac_addr_cmd;
+ uint8_t port_num;
+ struct ether_addr address;
+ uint8_t cnt_addr;
+};
+
+static void cmd_add_more_mac_addr_parsed(void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_add_more_mac_addr_result *res = parsed_result;
+ int ret;
+ int k;
+
+ for (k = 0; k < res->cnt_addr; k++) {
+ ret = rte_eth_dev_mac_addr_add(res->port_num, &res->address, 0);
+ if (ret < 0) {
+ printf("Fail to add mac addr : (%s) after adding %u
addresses\n",
+ strerror(-ret), k);
+ return;
+ }
+ res->address.addr_bytes[5]++;
+ }
+ printf("Success to add %u mac addresses\n", k);
+}
+
+cmdline_parse_token_string_t cmd_add_more_mac_addr_cmd =
+ TOKEN_STRING_INITIALIZER(struct cmd_add_more_mac_addr_result,
+ mac_addr_cmd, "add_more_mac_addr");
+cmdline_parse_token_num_t cmd_add_more_mac_addr_portnum =
+ TOKEN_NUM_INITIALIZER(struct cmd_add_more_mac_addr_result,
+ port_num, UINT8);
+cmdline_parse_token_etheraddr_t cmd_add_more_mac_addr_addr =
+ TOKEN_ETHERADDR_INITIALIZER(struct cmd_add_more_mac_addr_result,
+ address);
+cmdline_parse_token_num_t cmd_add_more_mac_addr_cnt_addr =
+ TOKEN_NUM_INITIALIZER(struct cmd_add_more_mac_addr_result,
+ cnt_addr, UINT8);
+
+cmdline_parse_inst_t cmd_add_more_mac_addr = {
+ .f = cmd_add_more_mac_addr_parsed,
+ .data = (void *)0,
+ .help_str = "add_more_mac_addr : "
+ "Add cnt_addr MAC addresses on port_id",
+ .tokens = {
+ (void *)&cmd_add_more_mac_addr_cmd,
+ (void *)&cmd_add_more_mac_addr_portnum,
+ (void *)&cmd_add_more_mac_addr_addr,
+ (void *)&cmd_add_more_mac_addr_cnt_addr,
+ NULL,
+ },
+};
/* *** CONFIGURE QUEUE STATS COUNTER MAPPINGS *** */
struct cmd_set_qmap_result {
@@ -13647,6 +13701,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_read_rxd_txd,
(cmdline_parse_inst_t *)&cmd_stop,
(cmdline_parse_inst_t *)&cmd_mac_addr,
+ (cmdline_parse_inst_t *)&cmd_add_more_mac_addr,
(cmdline_parse_inst_t *)&cmd_set_qmap,
(cmdline_parse_inst_t *)&cmd_operate_port,
(cmdline_parse_inst_t *)&cmd_operate_specific_port,
--
2.7.4
Re: [dpdk-dev] [PATCH] doc: fix directory err in virtio guide
02/05/2017 14:53, Mcnamara, John: > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > 02/05/2017 13:54, Yong Wang: > > > -python tools/dpdk-devbind.py -b vfio-pci 00:03.0 > > > +python usertools/dpdk-devbind.py -b vfio-pci 00:03.0 > > > > There is another occurence in doc/guides/howto/pvp_reference_benchmark.rst > > I spotted that, ;-), and I sent a separate patch. If that is overkill > then maybe fix the subject line for this patch and fix both together. Yes it is overkill :) I will squash them
[dpdk-dev] [PATCH] app/testpmd: disable latency stats by default
Disable latency stats gathering by default,
so there is not performance degradation if user
is not interested in them.
Signed-off-by: Pablo de Lara
---
app/test-pmd/testpmd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index dfe6442..23dfdb0 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -971,7 +971,8 @@ run_pkt_fwd_on_lcore(struct fwd_lcore *fc, packet_fwd_t
pkt_fwd)
}
#endif
#ifdef RTE_LIBRTE_LATENCY_STATS
- if (latencystats_lcore_id == rte_lcore_id())
+ if (latencystats_enabled != 0 &&
+ latencystats_lcore_id == rte_lcore_id())
rte_latencystats_update();
#endif
@@ -2238,8 +2239,9 @@ main(int argc, char** argv)
rte_panic("Empty set of forwarding logical cores - check the "
"core mask supplied in the command parameters\n");
- /* Bitrate stats disabled by default */
+ /* Bitrate/latency stats disabled by default */
bitrate_enabled = 0;
+ latencystats_enabled = 0;
argc -= diag;
argv += diag;
--
2.7.4
Re: [dpdk-dev] [PATCH] app/testpmd: disable latency stats by default
CC'ing Jingjing.
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Tuesday, May 02, 2017 2:11 PM
> To: jingj...@intel.com; Pattan, Reshma
> Cc: dev@dpdk.org; De Lara Guarch, Pablo
> Subject: [PATCH] app/testpmd: disable latency stats by default
>
> Disable latency stats gathering by default,
> so there is not performance degradation if user
> is not interested in them.
>
> Signed-off-by: Pablo de Lara
> ---
> app/test-pmd/testpmd.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index dfe6442..23dfdb0 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -971,7 +971,8 @@ run_pkt_fwd_on_lcore(struct fwd_lcore *fc,
> packet_fwd_t pkt_fwd)
> }
> #endif
> #ifdef RTE_LIBRTE_LATENCY_STATS
> - if (latencystats_lcore_id == rte_lcore_id())
> + if (latencystats_enabled != 0 &&
> + latencystats_lcore_id == rte_lcore_id())
> rte_latencystats_update();
> #endif
>
> @@ -2238,8 +2239,9 @@ main(int argc, char** argv)
> rte_panic("Empty set of forwarding logical cores - check the
> "
> "core mask supplied in the command
> parameters\n");
>
> - /* Bitrate stats disabled by default */
> + /* Bitrate/latency stats disabled by default */
> bitrate_enabled = 0;
> + latencystats_enabled = 0;
>
> argc -= diag;
> argv += diag;
> --
> 2.7.4
Re: [dpdk-dev] [PATCH] net/ixgbe: fix default MAC setting
Hello Wenzhuo,
How about also delete meaningless "ixgbe_remove_rar(dev, 0);"?
Best regards,
Igor
On Tue, May 2, 2017 at 11:34 AM, Wenzhuo Lu wrote:
> Pool 0 is not PF, it's VF 0. So the MAC is set for VF 0
> but not PF.
> The code introduced a weird issue. In the scenario PF + VF,
> when only starting PF, the default PF MAC address is working.
> But after starting a VF, the default PF MAC address becomes
> the VF's address.
>
> Use the pool which is not occupied by VFs for PF to fix it.
>
> Fixes: 8164fe82846b ("ixgbe: add default mac address modifier")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wenzhuo Lu
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_
> ethdev.c
> index bbae4f9..9ddd685 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -4658,9 +4658,11 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused
> struct rte_eth_dev *dev,
> static void
> ixgbe_set_default_mac_addr(struct rte_eth_dev *dev, struct ether_addr
> *addr)
> {
> + struct rte_pci_device *pci_dev = IXGBE_DEV_TO_PCI(dev);
> +
> ixgbe_remove_rar(dev, 0);
>
> - ixgbe_add_rar(dev, addr, 0, 0);
> + ixgbe_add_rar(dev, addr, 0, pci_dev->max_vfs);
> }
>
> static bool
> --
> 1.9.3
>
>
Re: [dpdk-dev] [RFC] [PATCH] eventdev: abstract ethdev HW capability to inject packets to eventdev
-Original Message- > Date: Fri, 21 Apr 2017 22:31:52 + > From: "Eads, Gage" > To: Jerin Jacob , "dev@dpdk.org" > > CC: "Richardson, Bruce" , "Van Haaren, Harry" > , "hemant.agra...@nxp.com" > , "nipun.gu...@nxp.com" , > "Vangati, Narender" > Subject: RE: [RFC] [dpdk-dev] [PATCH] eventdev: abstract ethdev HW > capability to inject packets to eventdev > > Hi Jerin, Hi Gage, > > Thanks for getting this ball rolling, and I agree that we need a solution > that covers the three cases you described. OK. Half problem is solved if we agree on problem statement :-) > We've also been thinking about an environment where devices (NIC Rx (or even > Tx), crypto, or a timer "device" that uses librte_timer to inject events) can > plug in eventdev -- whether through a direct connection to the event > scheduler (case #3) or using software to bridge the gap -- such that > application software can have a consistent view of device interfacing on > different platforms. Make sense. Yes, The NPUs can produce events from NIC Rx, NIC Tx, crypto, timer device sources without SW service functions. > > Some initial thoughts on your proposal: > > 1. I imagine that deploying these service functions at the granularity of a > core can be excessive on devices with few (<= 8) cores. For example, if the > crypto traffic rate is low then a cryptodev service function could be > co-scheduled with other service functions and/or application work. I think > we'll need a more flexible deployment of these service functions. I agree. > > 2. Knowing which device type a service function is for would be useful -- > without it, it's not possible to assign the function to the NUMA node on > which the device is located. I guess we can use rte_eth_dev_socket_id() on requested port to get NUMA id. > > 3. Placing the service core logic in the PMDs is nice in terms of application > ease-of-use, but it forces PMD to write one-size-fits-all service core > functions, where, for example, the application's control of the NIC Rx > functionality is limited to the options that struct > rte_event_queue_producer_conf exports. An application may want customized > service core behavior such as: prioritized polling of Rx queues, using Rx > queue interrupts for low traffic rate queues, or (for "closed system" > eventdevs) control over whether/when a service core drops events (and a way > to notify applications of event drops). For such cases, I think the > appropriate solution is allow applications to plug in their own service core > functions (when hardware support isn't present). I agree. I think, we can have reusable producer code as static inline functions in librte_event with multiple event producing strategies and let application to call respective one if HW support is not present or not adequate. I will work towards this theme in RFC v2. > > Some of these thoughts are reflected in the eventdev_pipeline app[1] that > Harry submitted earlier today, like flexible service function deployment. In > that app, the user supplies a device coremask that can pin a service function > to a core, multiplex multiple functions on the core, or even affinitize the > service function to multiple cores (using cmpset-based exclusion to ensure > it's executed by one lcore at a time). Thanks for the sample application.I could make it work with NIC + HW eventdev with some tweaking. I will send the review comment on that email thread. One thing, I noticed with cmpset based scheme is that, at given point of time it can produce at most up to the events one LCORE can support.May not be well suited for low end cores.I think, we need multiple event producer strategy code as common code. > In thinking about this, Narender and I have envisioned something like a > framework for eventdev applications in which these service functions can be > registered and (in a similar manner to eventdev_pipeline's service functions) > executed. That will be useful. I think it will be not just restricted to eventdev applications, I guess, New traffic manager's SW implementation or any future offloads need a framework for service function registration and invocation. > > Thanks, > Gage > > [1] http://dpdk.org/ml/archives/dev/2017-April/064511.html
Re: [dpdk-dev] [RFC] [PATCH] eventdev: abstract ethdev HW capability to inject packets to eventdev
Some comments inline with [HvH] prefix > -Original Message- > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > Sent: Tuesday, May 2, 2017 5:01 PM > To: Eads, Gage > Cc: dev@dpdk.org; Richardson, Bruce ; Van Haaren, > Harry > ; hemant.agra...@nxp.com; nipun.gu...@nxp.com; > Vangati, Narender > > Subject: Re: [RFC] [dpdk-dev] [PATCH] eventdev: abstract ethdev HW capability > to inject packets > to eventdev > > -Original Message- > > Date: Fri, 21 Apr 2017 22:31:52 + > > From: "Eads, Gage" > > To: Jerin Jacob , "dev@dpdk.org" > > > > CC: "Richardson, Bruce" , "Van Haaren, Harry" > > , "hemant.agra...@nxp.com" > > , "nipun.gu...@nxp.com" , > > "Vangati, Narender" > > Subject: RE: [RFC] [dpdk-dev] [PATCH] eventdev: abstract ethdev HW > > capability to inject packets to eventdev > > > > Hi Jerin, > > Hi Gage, > > > > > Thanks for getting this ball rolling, and I agree that we need a solution > > that covers the > three cases you described. > > OK. Half problem is solved if we agree on problem statement :-) [HvH] +2 :) > > We've also been thinking about an environment where devices (NIC Rx (or > > even Tx), crypto, or > a timer "device" that uses librte_timer to inject events) can plug in > eventdev -- whether > through a direct connection to the event scheduler (case #3) or using > software to bridge the > gap -- such that application software can have a consistent view of device > interfacing on > different platforms. > > Make sense. Yes, The NPUs can produce events from NIC Rx, NIC Tx, crypto, > timer device > sources without SW service functions. > > > > > Some initial thoughts on your proposal: > > > > 1. I imagine that deploying these service functions at the granularity of a > > core can be > excessive on devices with few (<= 8) cores. For example, if the crypto > traffic rate is low then > a cryptodev service function could be co-scheduled with other service > functions and/or > application work. I think we'll need a more flexible deployment of these > service functions. > > I agree. > > > > > 2. Knowing which device type a service function is for would be useful -- > > without it, it's > not possible to assign the function to the NUMA node on which the device is > located. > > I guess we can use rte_eth_dev_socket_id() on requested port to get NUMA > id. > > > > > 3. Placing the service core logic in the PMDs is nice in terms of > > application ease-of-use, > but it forces PMD to write one-size-fits-all service core functions, where, > for example, the > application's control of the NIC Rx functionality is limited to the options > that struct > rte_event_queue_producer_conf exports. An application may want customized > service core behavior > such as: prioritized polling of Rx queues, using Rx queue interrupts for low > traffic rate > queues, or (for "closed system" eventdevs) control over whether/when a > service core drops > events (and a way to notify applications of event drops). For such cases, I > think the > appropriate solution is allow applications to plug in their own service core > functions (when > hardware support isn't present). > > I agree. I think, we can have reusable producer code as static inline > functions in librte_event with multiple event producing strategies and > let application to call respective one if HW support is not present or > not adequate. > > I will work towards this theme in RFC v2. [HvH] Yes agree. I'd like to suggest that there might be two issues we're solving at the same time, A) How to "grab" cores for a generic software fallback purpose, and B) how we can enable the various eth/event/crypto-dev components to "play nice" For A), I have a header file that I'd like to share as an RFC on allowing EAL to manage this requesting of cores. The RFC does not deal with B) and configuration of eth/event/crypto devs. > > Some of these thoughts are reflected in the eventdev_pipeline app[1] that > > Harry submitted > earlier today, like flexible service function deployment. In that app, the > user supplies a > device coremask that can pin a service function to a core, multiplex multiple > functions on the > core, or even affinitize the service function to multiple cores (using > cmpset-based exclusion > to ensure it's executed by one lcore at a time). > > Thanks for the sample application.I could make it work with NIC + HW > eventdev with some tweaking. I will send the review comment on that > email thread. [HvH] Great! > One thing, I noticed with cmpset based scheme is that, at given point of > time it can produce at most up to the events one LCORE can support.May not > be well suited for low end cores.I think, we need multiple event > producer strategy code as common code. > > > In thinking about this, Narender and I have envisioned something like a > > framework for > eventdev applications in which these service functions can be registered and > (in a similar > manner to event
[dpdk-dev] [PATCH] doc: API change notice for librte_table
Signed-off-by: Cristian Dumitrescu --- doc/guides/rel_notes/deprecation.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index a3e7c72..ae937f5 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -81,3 +81,9 @@ Deprecation Notices - ``rte_crpytodev_scheduler_mode_get``, replaced by ``rte_cryptodev_scheduler_mode_get`` - ``rte_crpytodev_scheduler_mode_set``, replaced by ``rte_cryptodev_scheduler_mode_set`` + +* librte_table: The “key_mask” parameter will be added to all the hash tables + that currently do not have it, as well as to the hash compute function + prototype. The non-“do-sig” versions of the hash tables will be removed + (including the “signature_offset” parameter) and the “do-sig” versions renamed + accordingly. -- 2.7.4
[dpdk-dev] [PATCH] net/bnx2x: update document for PMD usage
Correct CONFIG_RTE_LIBRTE_BNX2X_PMD config file option and add a note about external zlib dependency for loading the firmware image. Signed-off-by: Rasesh Mody --- doc/guides/nics/bnx2x.rst |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/guides/nics/bnx2x.rst b/doc/guides/nics/bnx2x.rst index a3a0665..c5b5216 100644 --- a/doc/guides/nics/bnx2x.rst +++ b/doc/guides/nics/bnx2x.rst @@ -96,9 +96,11 @@ Config File Options The following options can be modified in the ``.config`` file. Please note that enabling debugging options may affect system performance. -- ``CONFIG_RTE_LIBRTE_BNX2X_PMD`` (default **y**) +- ``CONFIG_RTE_LIBRTE_BNX2X_PMD`` (default **n**) - Toggle compilation of bnx2x driver. + Toggle compilation of bnx2x driver. To use bnx2x PMD set this config parameter + to 'y'. Also, in order for firmware binary to load user will need zlib devel + package installed. - ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG`` (default **n**) -- 1.7.10.3
[dpdk-dev] [PATCH v2] net/bnx2x: update document for PMD usage
Correct CONFIG_RTE_LIBRTE_BNX2X_PMD config file option and add a note about external zlib dependency for loading the firmware image. Signed-off-by: Rasesh Mody --- doc/guides/nics/bnx2x.rst |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/guides/nics/bnx2x.rst b/doc/guides/nics/bnx2x.rst index a3a0665..fbfc048 100644 --- a/doc/guides/nics/bnx2x.rst +++ b/doc/guides/nics/bnx2x.rst @@ -96,9 +96,11 @@ Config File Options The following options can be modified in the ``.config`` file. Please note that enabling debugging options may affect system performance. -- ``CONFIG_RTE_LIBRTE_BNX2X_PMD`` (default **y**) +- ``CONFIG_RTE_LIBRTE_BNX2X_PMD`` (default **n**) - Toggle compilation of bnx2x driver. + Toggle compilation of bnx2x driver. To use bnx2x PMD set this config parameter + to 'y'. Also, in order for firmware binary to load user will need zlib devel + package installed. - ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG`` (default **n**) -- 1.7.10.3
Re: [dpdk-dev] [PATCH v6 1/3] ethdev: fix adding invalid MAC addr
Hi,
> -Original Message-
> From: Dai, Wei
> Sent: Tuesday, May 2, 2017 8:44 PM
> To: Lu, Wenzhuo; tho...@monjalon.net; harish.pa...@cavium.com;
> rasesh.m...@cavium.com; stephen.h...@broadcom.com;
> ajit.khapa...@broadcom.com; Zhang, Helin; Ananyev, Konstantin; Wu,
> Jingjing; Chen, Jing D; adrien.mazarg...@6wind.com;
> nelio.laranje...@6wind.com; Richardson, Bruce;
> yuanhan@linux.intel.com; maxime.coque...@redhat.com;
> shepard.sie...@atomicrules.com; ed.cz...@atomicrules.com;
> john.mil...@atomicrules.com
> Cc: dev@dpdk.org; Dai, Wei; sta...@dpdk.org
> Subject: [PATCH v6 1/3] ethdev: fix adding invalid MAC addr
>
> Some customers find adding MAC addr to VF sometimes can fail, but it is still
> stored in dev->data->mac_addrs[ ]. So this can lead to some errors that
> assumes the non-zero entry in
> dev->data->mac_addrs[ ] is valid.
> Following acknowledgements are from specific NIC PMD maintainer for their
> managing part.
>
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> Acked-by: Nelio Laranjeiro
> Acked-by: Yuanhan Liu
Acked-by: Wenzhuo Lu
Re: [dpdk-dev] [PATCH] net/ixgbe: fix default MAC setting
Hi Igor,
From: Igor Ryzhov [mailto:iryz...@nfware.com]
Sent: Tuesday, May 2, 2017 9:33 PM
To: Lu, Wenzhuo
Cc: dev@dpdk.org; sta...@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: fix default MAC setting
Hello Wenzhuo,
How about also delete meaningless "ixgbe_remove_rar(dev, 0);"?
[Wenzhuo] The current behavior of this set_default_mac_addr is to delete all
the existing MAC addresses and only set the assigned address as the default
address. This patch is to fix a bug not change the behavior. So have to leave
"ixgbe_remove_rar(dev, 0);" here.
Best regards,
Igor
On Tue, May 2, 2017 at 11:34 AM, Wenzhuo Lu
mailto:wenzhuo...@intel.com>> wrote:
Pool 0 is not PF, it's VF 0. So the MAC is set for VF 0
but not PF.
The code introduced a weird issue. In the scenario PF + VF,
when only starting PF, the default PF MAC address is working.
But after starting a VF, the default PF MAC address becomes
the VF's address.
Use the pool which is not occupied by VFs for PF to fix it.
Fixes: 8164fe82846b ("ixgbe: add default mac address modifier")
Cc: sta...@dpdk.org
Signed-off-by: Wenzhuo Lu mailto:wenzhuo...@intel.com>>
---
drivers/net/ixgbe/ixgbe_ethdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index bbae4f9..9ddd685 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -4658,9 +4658,11 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused
struct rte_eth_dev *dev,
static void
ixgbe_set_default_mac_addr(struct rte_eth_dev *dev, struct ether_addr *addr)
{
+ struct rte_pci_device *pci_dev = IXGBE_DEV_TO_PCI(dev);
+
ixgbe_remove_rar(dev, 0);
- ixgbe_add_rar(dev, addr, 0, 0);
+ ixgbe_add_rar(dev, addr, 0, pci_dev->max_vfs);
}
static bool
--
1.9.3
Re: [dpdk-dev] [PATCH v6 1/3] ethdev: fix adding invalid MAC addr
On Tue, May 02, 2017 at 08:44:23PM +0800, Wei Dai wrote:
> Some customers find adding MAC addr to VF sometimes can fail,
> but it is still stored in dev->data->mac_addrs[ ]. So this
> can lead to some errors that assumes the non-zero entry in
> dev->data->mac_addrs[ ] is valid.
> Following acknowledgements are from specific NIC PMD
> maintainer for their managing part.
>
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
Just a note, this patch changes API. It should not be backported to a
stable/LTS release, even though it fixes something.
--yliu
Re: [dpdk-dev] [PATCH 5/5] examples/l3fwd: add neon support for l3fwd
Hi Ashwin, On 2 May 2017 at 19:47, Sekhar, Ashwin wrote: > Hi Jianbo, > > I tested your neon changes on thunderx. I am seeing a performance > regression of ~10% for LPM case and ~20% for EM case with your changes. > Did you see improvement on any arm64 platform with these changes. If > yes, how much was the improvement? Thanks for your reviewing and testing. For some reason, I have not done much with the performance testing. I'll send a new version later after tuning the performance. Thanks! Jianbo > > FYI, I had also tried vectorizing the l3fwd app with neon. Few of the > optimizations that I can suggest that helped in my case. > > * Packet data prefetch is missing in the x86 sse version compared to > the scalar version (l3fwd_lpm_send_packets vs > l3fwd_lpm_no_opt_send_packets) . I couldn't understand why this was not > done in x86. But adding the prefetch was improving performance for > thunderx. > > * Offsets to some packet elements like eth_hdr, ip header, packet type > etc. are recalculated in different functions. Calculating them once, > caching them and passing them directly to different functions was > improving performance. > > * There are 3 different loops in l3fwd_lpm_send_packets where we > iterate over the packets. One each for processx4_step1 and > processx4_step2 and one in send_packets_multi. Unifying these loops > were also helping. > > Thanks and Regards > Ashwin >
[dpdk-dev] [PATCH] doc: update ixgbe doc
Add more explanation about how to disable MDD on kernel PF. Signed-off-by: Wenzhuo Lu --- doc/guides/nics/ixgbe.rst | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst index 130765b..6773fe5 100644 --- a/doc/guides/nics/ixgbe.rst +++ b/doc/guides/nics/ixgbe.rst @@ -186,9 +186,12 @@ the advanced context descriptor should be set and set it. And DPDK has to ask the info about the header length from the upper layer, because parsing the packet itself is not acceptable. So, it's too expensive to support MDD. When using kernel PF + DPDK VF on x550, please make sure using the kernel -driver that disables MDD or can disable MDD. (Some kernel driver can use -this CLI 'insmod ixgbe.ko MDD=0,0' to disable MDD. Some kernel driver disables -it by default.) +PF driver that disables MDD or can disable MDD. +Some kernel driver already disables MDD by default. +Some kernel driver can use this CLI "insmod ixgbe.ko MDD=0,0" to disable MDD. +Every "0" in the CLI means a port. Users need to add more "0"s if the machine +has more ports. For example, if there're 6 ixgbe ports, the CLI should be +changed to "insmod ixgbe.ko MDD=0,0,0,0,0,0". Statistics -- 1.9.3
[dpdk-dev] Minutes of tech-board meeting 2017-04-27
Hi all, Here is the meeting notes for the last DPDK technical board meeting held on 2017-04-27. Please note that meetings are open to all to attend. Any topics to be referred to the tech board for discussion at that meeting should be emailed to techbo...@dpdk.org. Normally, it's a bi-weekly meeting. Member attendees: - Bruce Richardson - Hemant Agrawal - Jan Blunck - Jerin Jacob - Olivier Matz - Stephen Hemminger - Thomas Monjalon - Yuanhan Liu 1.Scope of cmdline and cfgfile libraries in DPDK - - DPDK will continue to keep one version of cli and cfg libs in dpdk. They can be replaced with a better version in future. - w.r.t Keith's CLI lib proposal. It should replace the existing CLI lib. If any api changes are required, the api deprecation process should be followed. - It is acknowledged that cli and cfg libs can also be used outside dpdk. They can be better hosted on a different git repository. However, DPDK needs a better external dep system to do this. - The DPDK build system should be improved to work better with external dependencies. Thomas and Bruce will send a RFC on build system reqs for handling external deps. 2. DPDK Bug Tracker - DPDK is missing a bug tracker or to-do item list. It will be discussed in next meeting. 3. Next Meeting --- As per alphabetical order, Jan Blunck will chair next meeting. He will poll for the date and time of next meeting. Regards, Hemant
[dpdk-dev] [PATCH v2] net/e1000: fix VF received problem
VF default MAC address be added in PF Mac address list
instead of VF MAC address list, makes VF can't receive
packets. This patch fixes this issue.
Fixes: be2d648a2dd3 ("igb: add PF support")
Signed-off-by: Qiming Yang
---
drivers/net/e1000/igb_pf.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/e1000/igb_pf.c b/drivers/net/e1000/igb_pf.c
index 67da3c2..923c78a 100644
--- a/drivers/net/e1000/igb_pf.c
+++ b/drivers/net/e1000/igb_pf.c
@@ -332,12 +332,16 @@ igb_vf_set_mac_addr(struct rte_eth_dev *dev, uint32_t vf,
uint32_t *msgbuf)
*(E1000_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
int rar_entry = hw->mac.rar_entry_count - (vf + 1);
uint8_t *new_mac = (uint8_t *)(&msgbuf[1]);
+ int rah;
if (is_unicast_ether_addr((struct ether_addr *)new_mac)) {
if (!is_zero_ether_addr((struct ether_addr *)new_mac))
rte_memcpy(vfinfo[vf].vf_mac_addresses, new_mac,
sizeof(vfinfo[vf].vf_mac_addresses));
hw->mac.ops.rar_set(hw, new_mac, rar_entry);
+ rah = E1000_READ_REG(hw, E1000_RAH(rar_entry));
+ rah |= (0x1 << (E1000_RAH_POOLSEL_SHIFT + vf));
+ E1000_WRITE_REG(hw, E1000_RAH(rar_entry), rah);
return 0;
}
return -1;
--
2.7.4
[dpdk-dev] [PATCH v2] net/e1000: fix VF MAC address set problem
We find that VF receive address register is not set
if MAC address is assigned by PF. This patch fixes it.
Fixes: d82170d27918 ("igb: add VF support")
Signed-off-by: Qiming Yang
---
drivers/net/e1000/igb_ethdev.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index ca9f98c..967805b 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1031,12 +1031,6 @@ eth_igbvf_dev_init(struct rte_eth_dev *eth_dev)
/* Generate a random MAC address, if none was assigned by PF. */
if (is_zero_ether_addr(perm_addr)) {
eth_random_addr(perm_addr->addr_bytes);
- diag = e1000_rar_set(hw, perm_addr->addr_bytes, 0);
- if (diag) {
- rte_free(eth_dev->data->mac_addrs);
- eth_dev->data->mac_addrs = NULL;
- return diag;
- }
PMD_INIT_LOG(INFO, "\tVF MAC address not assigned by Host PF");
PMD_INIT_LOG(INFO, "\tAssign randomly generated MAC address "
"%02x:%02x:%02x:%02x:%02x:%02x",
@@ -1048,6 +1042,12 @@ eth_igbvf_dev_init(struct rte_eth_dev *eth_dev)
perm_addr->addr_bytes[5]);
}
+ diag = e1000_rar_set(hw, perm_addr->addr_bytes, 0);
+ if (diag) {
+ rte_free(eth_dev->data->mac_addrs);
+ eth_dev->data->mac_addrs = NULL;
+ return diag;
+ }
/* Copy the permanent MAC address */
ether_addr_copy((struct ether_addr *) hw->mac.perm_addr,
ð_dev->data->mac_addrs[0]);
--
2.7.4
[dpdk-dev] [PATCH v2] doc: add VF support statement
This patch adds two note in doc build_dpdk, suggests DPDK user don't use ``vfio-pci`` and ``uio_pci_generic`` module to create virtual functions(VFs). Signed-off-by: Qiming Yang --- v2 changes: * use better expression. --- --- doc/guides/linux_gsg/build_dpdk.rst | 8 1 file changed, 8 insertions(+) diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst index 9d24573..cf6c06d 100644 --- a/doc/guides/linux_gsg/build_dpdk.rst +++ b/doc/guides/linux_gsg/build_dpdk.rst @@ -155,6 +155,10 @@ can provide the uio capability. This module can be loaded using the command sudo modprobe uio_pci_generic +.. note:: + +``uio_pci_generic`` module doesn't support the creation of virtual functions. + As an alternative to the ``uio_pci_generic``, the DPDK also includes the igb_uio module which can be found in the kmod subdirectory referred to above. It can be loaded as shown below: @@ -187,6 +191,10 @@ however please consult your distributions documentation to make sure that is the Also, to use VFIO, both kernel and BIOS must support and be configured to use IO virtualization (such as Intel® VT-d). +.. note:: + +``vfio-pci`` module doesn't support the creation of virtual functions. + For proper operation of VFIO when running DPDK applications as a non-privileged user, correct permissions should also be set up. This can be done by using the DPDK setup script (called dpdk-setup.sh and located in the usertools directory). -- 2.7.4
[dpdk-dev] app/testpmd: compilation error with bitrate/latency config flags disabled
Hi, Seeing compilation errors with DPDK 17.05-rc3 when I happened to disable bitrate/latency configs during our internal testing. CONFIG_RTE_LIBRTE_BITRATE=n and CONFIG_RTE_LIBRTE_LATENCY_STATS=n. /home/root1/hpatil/17.05-rc3/dpdk/app/test-pmd/testpmd.c: In function ?main?: /home/root1/hpatil/17.05-rc3/dpdk/app/test-pmd/testpmd.c:2242:2: error: ?bitrate_enabled? undeclared (first use in this function) bitrate_enabled = 0; ^ /home/root1/hpatil/17.05-rc3/dpdk/app/test-pmd/testpmd.c:2242:2: note: each undeclared identifier is reported only once for each function it appears in make[5]: *** [testpmd.o] Error 1 make[5]: *** Waiting for unfinished jobs Does the patch you sent for review: "[PATCH] app/testpmd: disable latency stats by default” address this? Please check. Thanks, harish
Re: [dpdk-dev] app/testpmd: compilation error with bitrate/latency config flags disabled
Hi Harish, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Patil, Harish > Sent: Wednesday, May 03, 2017 7:34 AM > To: Horton, Remy; De Lara Guarch, Pablo > Cc: dev@dpdk.org > Subject: [dpdk-dev] app/testpmd: compilation error with bitrate/latency > config flags disabled > > Hi, > Seeing compilation errors with DPDK 17.05-rc3 when I happened to disable > bitrate/latency configs during our internal testing. > CONFIG_RTE_LIBRTE_BITRATE=n and > CONFIG_RTE_LIBRTE_LATENCY_STATS=n. > > /home/root1/hpatil/17.05-rc3/dpdk/app/test-pmd/testpmd.c: In function > ?main?: > /home/root1/hpatil/17.05-rc3/dpdk/app/test-pmd/testpmd.c:2242:2: > error: > ?bitrate_enabled? undeclared (first use in this function) > bitrate_enabled = 0; > ^ > /home/root1/hpatil/17.05-rc3/dpdk/app/test-pmd/testpmd.c:2242:2: > note: > each undeclared identifier is reported only once for each function it > appears in > make[5]: *** [testpmd.o] Error 1 > make[5]: *** Waiting for unfinished jobs > > Does the patch you sent for review: "[PATCH] app/testpmd: disable latency > stats by default” address this? > Please check. No, this is a separate issue. I will send a patch to fix it (also a v2 for the patch that you mentioned, as it needs that fix too). Thanks for spotting that. Pablo > > Thanks, > > harish > > >
[dpdk-dev] [PATCH] net/mlx5: fix Tx max inline with TSO
When TSO is enabled, Verbs layer aggregates the TSO
inline size with the txq inline size for the Tx creation,
while the PMD takes the maximum among them.
Fixing it by adjusting the max inline parameter before
passing to to Verbs.
Fixes: 3f13f8c23a7c ("net/mlx5: support hardware TSO")
Signed-off-by: Shahaf Shuler
Acked-by: Yongseok Koh
---
drivers/net/mlx5/mlx5_txq.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_txq.c b/drivers/net/mlx5/mlx5_txq.c
index f80740a13..24bd8c615 100644
--- a/drivers/net/mlx5/mlx5_txq.c
+++ b/drivers/net/mlx5/mlx5_txq.c
@@ -230,6 +230,9 @@ txq_ctrl_setup(struct rte_eth_dev *dev, struct txq_ctrl
*txq_ctrl,
struct ibv_exp_cq_attr cq_attr;
} attr;
unsigned int cqe_n;
+ const unsigned int max_tso_inline = ((MLX5_MAX_TSO_HEADER +
+(RTE_CACHE_LINE_SIZE - 1)) /
+ RTE_CACHE_LINE_SIZE);
int ret = 0;
if (mlx5_getenv_int("MLX5_ENABLE_CQE_COMPRESSION")) {
@@ -307,16 +310,22 @@ txq_ctrl_setup(struct rte_eth_dev *dev, struct txq_ctrl
*txq_ctrl,
priv->inline_max_packet_sz) +
(RTE_CACHE_LINE_SIZE - 1)) /
RTE_CACHE_LINE_SIZE) * RTE_CACHE_LINE_SIZE;
+ } else if (priv->tso) {
+ int inline_diff = tmpl.txq.max_inline - max_tso_inline;
+
+ /* Adjust inline value as Verbs aggregates
+* tso_inline and txq_inline fields.
+*/
+ attr.init.cap.max_inline_data = inline_diff > 0 ?
+ inline_diff *
+ RTE_CACHE_LINE_SIZE :
+ 0;
} else {
attr.init.cap.max_inline_data =
tmpl.txq.max_inline * RTE_CACHE_LINE_SIZE;
}
}
if (priv->tso) {
- uint16_t max_tso_inline = ((MLX5_MAX_TSO_HEADER +
- (RTE_CACHE_LINE_SIZE - 1)) /
- RTE_CACHE_LINE_SIZE);
-
attr.init.max_tso_header =
max_tso_inline * RTE_CACHE_LINE_SIZE;
attr.init.comp_mask |= IBV_EXP_QP_INIT_ATTR_MAX_TSO_HEADER;
--
2.12.0
