Re: [dpdk-dev] [PATCH v5 00/10] examples/ipsec-secgw: make app to use ipsec library
Hi Konstantin,
I just got results on running the ipsec-secgw on NXP hardware.
it seems there is a drop of around 10% for lookaside proto with normal
command(i.e. without -l option)
with -l option, I got a seg fault while running traffic. gdb suggest
that pkt_func is not filled up and is NULL.
#1 0x004689bc in rte_ipsec_pkt_crypto_prepare (ss=0x17ad82d80,
mb=0xe498, cop=0xdfc0, num=1)
at
/home/akhil/netperf/dpdk_up/dpdk-next-crypto/arm64-dpaa-linuxapp-gcc/include/rte_ipsec.h:115
(gdb) p /x *ss
$1 = {sa = 0x17ad7ea40, type = 0x3, {crypto = {ses = 0x165a4e900},
security = {ses = 0x165a4e900, ctx = 0x0, ol_flags = 0x0}}, pkt_func = {
prepare = 0x0, process = 0x0}}
On 12/28/2018 9:03 PM, Konstantin Ananyev wrote:
> This patch series depends on the patch series:
>
> ipsec: new library for IPsec data-path processing
> http://patches.dpdk.org/patch/49332/
> http://patches.dpdk.org/patch/49333/
> http://patches.dpdk.org/patch/49334/
> http://patches.dpdk.org/patch/49335/
> http://patches.dpdk.org/patch/49336/
> http://patches.dpdk.org/patch/49337/
> http://patches.dpdk.org/patch/49338/
> http://patches.dpdk.org/patch/49339/
> http://patches.dpdk.org/patch/49340/
> http://patches.dpdk.org/patch/49341/
>
> to be applied first.
>
> v4 -> v5
> - Address Akhil comments:
> documentation update
> spell checks spacing etc.
> introduce rxoffload/txoffload parameters
> single SA for ipv6
> update Makefile
>
> v3 -> v4
> - fix few issues with the test scripts
> - update docs
>
> v2 -> v3
> - add IPv6 cases into test scripts
> - fixes for IPv6 support
> - fixes for inline-crypto support
> - some code restructuring
>
> v1 -> v2
> - Several bug fixes
>
> That series contians few bug-fixes and changes to make ipsec-secgw
> to utilize librte_ipsec library:
> - changes in the related data structures.
> - changes in the initialization code.
> - changes in the data-path code.
> - new command-line parameters to enable librte_ipsec codepath
> and related features.
> - test scripts to help automate ipsec-secgw functional testing.
>
> Note that right now by default current (non-librte_ipsec) code-path
> will be used. User has to run application with new command-line option
> ('-l')
> to enable new codepath.
> The main reason for that:
>- current librte_ipsec doesn't support all ipsec algorithms
> and features that the app does.
>- allow users to run both versions in parallel for some time
> to figure out any functional or performance degradation with the
> new code.
>
> Test scripts were run with the following crypto devices:
> - aesni_mb
> - aesni_gcm
> - qat
>
> Konstantin Ananyev (10):
>examples/ipsec-secgw: allow user to disable some RX/TX offloads
>examples/ipsec-secgw: allow to specify neighbour mac address
>examples/ipsec-secgw: fix crypto-op might never get dequeued
>examples/ipsec-secgw: fix outbound codepath for single SA
>examples/ipsec-secgw: make local variables static
>examples/ipsec-secgw: fix inbound SA checking
>examples/ipsec-secgw: make app to use ipsec library
>examples/ipsec-secgw: make data-path to use ipsec library
>examples/ipsec-secgw: add scripts for functional test
>doc: update ipsec-secgw guide and relelase notes
>
> doc/guides/rel_notes/release_19_02.rst| 14 +
> doc/guides/sample_app_ug/ipsec_secgw.rst | 159 +-
> examples/ipsec-secgw/Makefile | 5 +-
> examples/ipsec-secgw/ipsec-secgw.c| 480 ++
> examples/ipsec-secgw/ipsec.c | 62 ++-
> examples/ipsec-secgw/ipsec.h | 67 +++
> examples/ipsec-secgw/ipsec_process.c | 341 +
> examples/ipsec-secgw/meson.build | 6 +-
> examples/ipsec-secgw/parser.c | 91
> examples/ipsec-secgw/parser.h | 8 +-
> examples/ipsec-secgw/sa.c | 263 +-
> examples/ipsec-secgw/sp4.c| 35 +-
> examples/ipsec-secgw/sp6.c| 35 +-
> examples/ipsec-secgw/test/common_defs.sh | 153 ++
> examples/ipsec-secgw/test/data_rxtx.sh| 62 +++
> examples/ipsec-secgw/test/linux_test4.sh | 63 +++
> examples/ipsec-secgw/test/linux_test6.sh | 64 +++
> examples/ipsec-secgw/test/run_test.sh | 80 +++
> .../test/trs_aescbc_sha1_common_defs.sh | 69 +++
> .../ipsec-secgw/test/trs_aescbc_sha1_defs.sh | 67 +++
> .../test/trs_aescbc_sha1_esn_atom_defs.sh | 5 +
> .../test/trs_aescbc_sha1_esn_defs.sh | 66 +++
> .../test/trs_aescbc_sha1_old_defs.sh | 5 +
> .../test/trs_aesgcm_common_defs.sh| 60 +++
> examples/ipsec-secgw/test/trs_aesgcm_defs.sh | 66 +++
> .../test/trs_aesgcm_esn_atom_defs.sh | 5 +
> .../ipsec-secgw/test/trs_aesgcm_esn_defs.
Re: [dpdk-dev] rte_eal_hotplug_remove() generates error message
On Thu, Dec 27, 2018 at 02:52:17PM +0900, Hideyuki Yamashita wrote: > Q1. > I CCed my patch to sta...@dpdk.org > Is that mean it will be reflected into 18.11 stable release? Yes. > The reason why I ask this is I think it is better that bug should > be reflected into LTS because I and SPP users mainly use DPDK LTS(18.11). > > Q2. > If yes, when will those stable release will be released? > (e.g. once a month ) Plans can be found here: https://core.dpdk.org/roadmap/#stable > > Q3. > I understand my patch is acked and merged into > dpdk-next-virtio. > What is dpdk-next-virtio? > It is the branch which will be reflected into next release? It's already in main repo now: http://git.dpdk.org/dpdk/commit/drivers/net/vhost?id=6e3339ca07734e59cd0c24594e3014ab49a0ffc0
[dpdk-dev] [PATCH v3 2/3] net/mlx5: add devx functions to glue
This patch adds glue functions for operations:
- dv_open_device.
- devx object create, destroy, query and modify.
- devx general command
The new operations depend on HAVE_IBV_DEVX_OBJ.
Signed-off-by: Moti Haimovsky
---
v2:
* Modifications according to review inputs.
see message Id: 1545748697-3385-3-git-send-email-mo...@mellanox.com
---
drivers/net/mlx5/Makefile| 5 +++
drivers/net/mlx5/meson.build | 2 +
drivers/net/mlx5/mlx5_glue.c | 98
drivers/net/mlx5/mlx5_glue.h | 19 +
4 files changed, 124 insertions(+)
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index 1353c18..8ddad1a 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -148,6 +148,11 @@ mlx5_autoconf.h.new: $(RTE_SDK)/buildtools/auto-config-h.sh
func mlx5dv_create_flow_action_packet_reformat \
$(AUTOCONF_OUTPUT)
$Q sh -- '$<' '$@' \
+ HAVE_IBV_DEVX_OBJ \
+ infiniband/mlx5dv.h \
+ func mlx5dv_devx_obj_create \
+ $(AUTOCONF_OUTPUT)
+ $Q sh -- '$<' '$@' \
HAVE_ETHTOOL_LINK_MODE_25G \
/usr/include/linux/ethtool.h \
enum ETHTOOL_LINK_MODE_25000baseCR_Full_BIT \
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index 8ba19e8..e2fc4ea 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -104,6 +104,8 @@ if build
'IBV_FLOW_SPEC_MPLS' ],
[ 'HAVE_IBV_WQ_FLAG_RX_END_PADDING', 'infiniband/verbs.h',
'IBV_WQ_FLAG_RX_END_PADDING' ],
+ [ 'HAVE_IBV_DEVX_OBJ', 'infiniband/mlx5dv.h',
+ 'mlx5dv_devx_obj_create' ],
[ 'HAVE_SUPPORTED_4baseKR4_Full', 'linux/ethtool.h',
'SUPPORTED_4baseKR4_Full' ],
[ 'HAVE_SUPPORTED_4baseCR4_Full', 'linux/ethtool.h',
diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c
index a806d92..c817d86 100644
--- a/drivers/net/mlx5/mlx5_glue.c
+++ b/drivers/net/mlx5/mlx5_glue.c
@@ -498,6 +498,98 @@
#endif
}
+static struct ibv_context *
+mlx5_glue_dv_open_device(struct ibv_device *device)
+{
+#ifdef HAVE_IBV_DEVX_OBJ
+ return mlx5dv_open_device(device,
+ &(struct mlx5dv_context_attr){
+ .flags = MLX5DV_CONTEXT_FLAGS_DEVX,
+ });
+#else
+ (void)device;
+ return NULL;
+#endif
+}
+
+static struct mlx5dv_devx_obj *
+mlx5_glue_devx_obj_create(struct ibv_context *ctx,
+ const void *in, size_t inlen,
+ void *out, size_t outlen)
+{
+#ifdef HAVE_IBV_DEVX_OBJ
+ return mlx5dv_devx_obj_create(ctx, in, inlen, out, outlen);
+#else
+ (void)ctx;
+ (void)in;
+ (void)inlen;
+ (void)out;
+ (void)outlen;
+ return NULL;
+#endif
+}
+
+static int
+mlx5_glue_devx_obj_destroy(struct mlx5dv_devx_obj *obj)
+{
+#ifdef HAVE_IBV_DEVX_OBJ
+ return mlx5dv_devx_obj_destroy(obj);
+#else
+ (void)obj;
+ return -ENOTSUP;
+#endif
+}
+
+static int
+mlx5_glue_devx_obj_query(struct mlx5dv_devx_obj *obj,
+const void *in, size_t inlen,
+void *out, size_t outlen)
+{
+#ifdef HAVE_IBV_DEVX_OBJ
+ return mlx5dv_devx_obj_query(obj, in, inlen, out, outlen);
+#else
+ (void)obj;
+ (void)in;
+ (void)inlen;
+ (void)out;
+ (void)outlen;
+ return -ENOTSUP;
+#endif
+}
+
+static int
+mlx5_glue_devx_obj_modify(struct mlx5dv_devx_obj *obj,
+ const void *in, size_t inlen,
+ void *out, size_t outlen)
+{
+#ifdef HAVE_IBV_DEVX_OBJ
+ return mlx5dv_devx_obj_modify(obj, in, inlen, out, outlen);
+#else
+ (void)obj;
+ (void)in;
+ (void)inlen;
+ (void)out;
+ (void)outlen;
+ return -ENOTSUP;
+#endif
+}
+
+static int
+mlx5_glue_devx_general_cmd(struct ibv_context *ctx,
+ const void *in, size_t inlen,
+ void *out, size_t outlen)
+{
+#ifdef HAVE_IBV_DEVX_OBJ
+ return mlx5dv_devx_general_cmd(ctx, in, inlen, out, outlen);
+#else
+ (void)ctx;
+ (void)in;
+ (void)inlen;
+ (void)out;
+ (void)outlen;
+ return -ENOTSUP;
+#endif
+}
alignas(RTE_CACHE_LINE_SIZE)
const struct mlx5_glue *mlx5_glue = &(const struct mlx5_glue){
@@ -557,4 +649,10 @@
mlx5_glue_dv_create_flow_action_packet_reformat,
.dv_create_flow_action_modify_header =
mlx5_glue_dv_create_flow_action_modify_header,
+ .dv_open_device = mlx5_glue_dv_open_device,
+ .devx_obj_create = mlx5_glue_devx_obj_create,
+ .devx_obj_destroy = mlx5_glue_devx_obj_destroy,
+ .devx_obj_query = mlx5_glue_devx_obj_query,
+ .devx_obj_modify = mlx5
[dpdk-dev] [PATCH v3 0/3] support flow counters using devx
This series of commits add support for creating, allocating, querying and destroying flow counters in mlx5 PMD using the devx interface. Moti Haimovsky (3): net/mlx5: fix shared counter allocation logic net/mlx5: add devx functions to glue net/mlx5: support flow counters using devx drivers/net/mlx5/Makefile | 11 ++ drivers/net/mlx5/meson.build | 5 + drivers/net/mlx5/mlx5.c| 16 ++- drivers/net/mlx5/mlx5.h| 15 +++ drivers/net/mlx5/mlx5_devx_cmds.c | 107 + drivers/net/mlx5/mlx5_flow.h | 10 +- drivers/net/mlx5/mlx5_flow_dv.c| 232 +++-- drivers/net/mlx5/mlx5_flow_verbs.c | 14 +-- drivers/net/mlx5/mlx5_glue.c | 98 drivers/net/mlx5/mlx5_glue.h | 19 +++ drivers/net/mlx5/mlx5_prm.h| 71 11 files changed, 576 insertions(+), 22 deletions(-) create mode 100644 drivers/net/mlx5/mlx5_devx_cmds.c -- 1.8.3.1
[dpdk-dev] [PATCH v3 1/3] net/mlx5: fix shared counter allocation logic
This commit fixes the logic for searching and allocating a shared
counter in mlx5_flow_verbs.
Now only the shared counters in the counters list are checked for
a match and not all the counters as before.
Fixes: 84c406e74524 ("net/mlx5: add flow translate function")
Cc: sta...@dpdk.org
Signed-off-by: Moti Haimovsky
---
v2:
* Modified commit header
---
drivers/net/mlx5/mlx5_flow_verbs.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow_verbs.c
b/drivers/net/mlx5/mlx5_flow_verbs.c
index 81ec59d..409e1cd 100644
--- a/drivers/net/mlx5/mlx5_flow_verbs.c
+++ b/drivers/net/mlx5/mlx5_flow_verbs.c
@@ -121,13 +121,13 @@
struct mlx5_flow_counter *cnt;
int ret;
- LIST_FOREACH(cnt, &priv->flow_counters, next) {
- if (!cnt->shared || cnt->shared != shared)
- continue;
- if (cnt->id != id)
- continue;
- cnt->ref_cnt++;
- return cnt;
+ if (shared) {
+ LIST_FOREACH(cnt, &priv->flow_counters, next) {
+ if (cnt->shared && cnt->id == id) {
+ cnt->ref_cnt++;
+ return cnt;
+ }
+ }
}
cnt = rte_calloc(__func__, 1, sizeof(*cnt), 0);
if (!cnt) {
--
1.8.3.1
[dpdk-dev] [PATCH v3 3/3] net/mlx5: support flow counters using devx
This commit adds counters support when creating flows via direct
verbs. The implementation uses devx interface in order to create
query and delete the counters.
This support requires MLNX_OFED_LINUX-4.5-0.1.0.1 installation.
Signed-off-by: Moti Haimovsky
---
v2:
* Modifications according to code review,
See message Id: 1545748697-3385-4-git-send-email-mo...@mellanox.com
v3:
* Modified calls to devx routins to be done through the glue interface.
See message Id: 1545949196-3355-4-git-send-email-mo...@mellanox.com
---
drivers/net/mlx5/Makefile | 6 +
drivers/net/mlx5/meson.build | 3 +
drivers/net/mlx5/mlx5.c | 16 ++-
drivers/net/mlx5/mlx5.h | 15 +++
drivers/net/mlx5/mlx5_devx_cmds.c | 107 ++
drivers/net/mlx5/mlx5_flow.h | 10 +-
drivers/net/mlx5/mlx5_flow_dv.c | 232 --
drivers/net/mlx5/mlx5_prm.h | 71
8 files changed, 445 insertions(+), 15 deletions(-)
create mode 100644 drivers/net/mlx5/mlx5_devx_cmds.c
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index 8ddad1a..a1749e4 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -36,6 +36,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_flow_tcf.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_flow_verbs.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_socket.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_nl.c
+SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_devx_cmds.c
ifeq ($(CONFIG_RTE_LIBRTE_MLX5_DLOPEN_DEPS),y)
INSTALL-$(CONFIG_RTE_LIBRTE_MLX5_PMD)-lib += $(LIB_GLUE)
@@ -153,6 +154,11 @@ mlx5_autoconf.h.new: $(RTE_SDK)/buildtools/auto-config-h.sh
func mlx5dv_devx_obj_create \
$(AUTOCONF_OUTPUT)
$Q sh -- '$<' '$@' \
+ HAVE_IBV_FLOW_DEVX_COUNTERS \
+ infiniband/mlx5dv.h \
+ enum MLX5DV_FLOW_ACTION_COUNTER_DEVX \
+ $(AUTOCONF_OUTPUT)
+ $Q sh -- '$<' '$@' \
HAVE_ETHTOOL_LINK_MODE_25G \
/usr/include/linux/ethtool.h \
enum ETHTOOL_LINK_MODE_25000baseCR_Full_BIT \
diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
index e2fc4ea..e9db36c 100644
--- a/drivers/net/mlx5/meson.build
+++ b/drivers/net/mlx5/meson.build
@@ -46,6 +46,7 @@ if build
'mlx5_trigger.c',
'mlx5_txq.c',
'mlx5_vlan.c',
+ 'mlx5_devx_cmds.c',
)
if dpdk_conf.has('RTE_ARCH_X86_64') or dpdk_conf.has('RTE_ARCH_ARM64')
sources += files('mlx5_rxtx_vec.c')
@@ -106,6 +107,8 @@ if build
'IBV_WQ_FLAG_RX_END_PADDING' ],
[ 'HAVE_IBV_DEVX_OBJ', 'infiniband/mlx5dv.h',
'mlx5dv_devx_obj_create' ],
+ [ 'HAVE_IBV_FLOW_DEVX_COUNTERS', 'infiniband/mlx5dv.h',
+ 'MLX5DV_FLOW_ACTION_COUNTER_DEVX' ],
[ 'HAVE_SUPPORTED_4baseKR4_Full', 'linux/ethtool.h',
'SUPPORTED_4baseKR4_Full' ],
[ 'HAVE_SUPPORTED_4baseCR4_Full', 'linux/ethtool.h',
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 4521045..c5ed402 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -727,7 +727,7 @@
struct mlx5_dev_config config,
const struct mlx5_switch_info *switch_info)
{
- struct ibv_context *ctx;
+ struct ibv_context *ctx = NULL;
struct ibv_device_attr_ex attr;
struct ibv_port_attr port_attr;
struct ibv_pd *pd = NULL;
@@ -786,10 +786,16 @@
/* Prepare shared data between primary and secondary process. */
mlx5_prepare_shared_data();
errno = 0;
- ctx = mlx5_glue->open_device(ibv_dev);
- if (!ctx) {
- rte_errno = errno ? errno : ENODEV;
- return NULL;
+ ctx = mlx5_glue->dv_open_device(ibv_dev);
+ if (ctx) {
+ config.devx = 1;
+ DRV_LOG(DEBUG, "DEVX is supported");
+ } else {
+ ctx = mlx5_glue->open_device(ibv_dev);
+ if (!ctx) {
+ rte_errno = errno ? errno : ENODEV;
+ return NULL;
+ }
}
#ifdef HAVE_IBV_MLX5_MOD_SWP
dv_attr.comp_mask |= MLX5DV_CONTEXT_MASK_SWP;
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index b48cd94..45f0398 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -98,6 +98,12 @@ struct mlx5_stats_ctrl {
uint64_t imissed_base;
};
+/* devx counter object */
+struct mlx5_devx_counter_set {
+ struct mlx5dv_devx_obj *obj;
+ int id; /* Flow counter ID */
+};
+
/* Flow list . */
TAILQ_HEAD(mlx5_flows, rte_flow);
@@ -131,6 +137,7 @@ struct mlx5_dev_config {
unsigned int vf_nl_en:1; /* Enable Netlink requests in VF mode. */
unsigned int dv_flow_en:1; /* Enable DV flow. */
unsigned int swp:1; /* Tx g
Re: [dpdk-dev] [PATCH v5 03/10] examples/ipsec-secgw: fix crypto-op might never get dequeued
On 12/28/2018 9:03 PM, Konstantin Ananyev wrote:
> In some cases crypto-ops could never be dequeued from the crypto-device.
> The easiest way to reproduce:
> start ipsec-secgw with crypto-dev and send to it less then 32 packets.
> none packets will be forwarded.
> Reason for that is that the application does dequeue() from crypto-queues
> only when new packets arrive.
> This patch makes sure it calls dequeue() on a regular basis.
>
> Fixes: c64278c0c18b ("examples/ipsec-secgw: rework processing loop")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Konstantin Ananyev
> Acked-by: Radu Nicolau
> ---
> examples/ipsec-secgw/ipsec-secgw.c | 136 -
> examples/ipsec-secgw/ipsec.c | 60 -
> examples/ipsec-secgw/ipsec.h | 11 +++
> 3 files changed, 165 insertions(+), 42 deletions(-)
[snip]
> +
> /* main processing loop */
> static int32_t
> main_loop(__attribute__((unused)) void *dummy)
> @@ -866,7 +958,8 @@ main_loop(__attribute__((unused)) void *dummy)
> diff_tsc = cur_tsc - prev_tsc;
>
> if (unlikely(diff_tsc > drain_tsc)) {
> - drain_buffers(qconf);
> + drain_tx_buffers(qconf);
> + drain_crypto_buffers(qconf);
> prev_tsc = cur_tsc;
> }
>
> @@ -880,6 +973,9 @@ main_loop(__attribute__((unused)) void *dummy)
> if (nb_rx > 0)
> process_pkts(qconf, pkts, nb_rx, portid);
> }
> +
> + drain_inbound_crypto_queues(qconf, &qconf->inbound);
> + drain_outbound_crypto_queues(qconf, &qconf->outbound);
drain_inbound_crypto_queues and drain_outbound_crypto_queues should be called
based on diff_tsc.
moving these two lines above after drain_crypto_buffers will improve the
performance drop caused due to this patch.
Re: [dpdk-dev] [PATCH] eal: fix core number validation
Hi, From: David Marchand [mailto:david.march...@redhat.com] Sent: Friday, December 21, 2018 2:58 PM To: Burakov, Anatoly ; Vemula, Hari KumarX Cc: dev@dpdk.org; Pattan, Reshma ; Yigit, Ferruh ; sta...@dpdk.org Subject: Re: [dpdk-dev] [PATCH] eal: fix core number validation On Fri, Dec 21, 2018 at 10:19 AM Burakov, Anatoly mailto:anatoly.bura...@intel.com>> wrote: On 21-Dec-18 8:27 AM, David Marchand wrote: > Since you have identified a potential crash, can you give an example of > such a crash ? > Besides, we have tests that check arguments, so an update of the test would > be nice. I believe these lcore numbers are used to index the lcore list later, which would cause out-of-bounds access, which may or may not cause a crash, depending on how lucky you get. Sure, that and the fact that my testpmd was doing nothing with them :-). Anyway, the unit tests missed this case, so we need an update. And the more I look at those string parsing, the more I think that the service cores parsing has the same issue (copy/paste yay ;-)). DPDK EAL doesn’t have eal parameter valid/invalid core number check. For example, if we use following command to launch dpdk testpmd sample, it will return segmentation fault directly: ./x86_64-native-linuxapp-gcc/app/testpmd -l 999 -n 4 –-i EAL: Detected 48 lcore(s) EAL: Detected 2 NUMA nodes Segmentation fault (core dumped) UT is present for -l command line option to validate core number, but there is no check for higher core list number like above. -- Hari. -- David Marchand -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: [dpdk-dev] [PATCH v4 1/3] test/ring: ring perf test case enhancement
> Suggested-by: Gavin Hu > Signed-off-by: Joyce Kong > Reviewed-by: Ruifeng Wang > Reviewed-by: Honnappa Nagarahalli > Reviewed-by: Dharmik Thakkar > Reviewed-by: Ola Liljedahl > Reviewed-by: Gavin Hu Small comment about the email addresses, Please do not use uppercase so we can match/grep more easily.
Re: [dpdk-dev] [PATCH v4 0/3] add rte ring reset api and use it to flush a ring by hash
02/01/2019 01:55, Gavin Hu: > V4: Include the ring perf test case enhancement patch in the series. > > V3: Allow experimental API for meson build > > V2: Fix the coding style issue(commit message line too long) > > V1: To flush a ring not in use, dequeue one by one is wasting cpu cycles. > The patch is to just resetting the head and tail indices to save cpu > cycle. It is too late for adding this API in 19.02, but we should review and give opinion, so it will be ready to integrate in early February.
Re: [dpdk-dev] [PATCH v5 00/10] examples/ipsec-secgw: make app to use ipsec library
Hi Akhil,
> Hi Konstantin,
>
> I just got results on running the ipsec-secgw on NXP hardware.
Thanks for doing that.
We don't have NXP HW, so would need more help from you.
>
> with -l option, I got a seg fault while running traffic. gdb suggest
> that pkt_func is not filled up and is NULL.
> #1 0x004689bc in rte_ipsec_pkt_crypto_prepare (ss=0x17ad82d80,
> mb=0xe498, cop=0xdfc0, num=1)
> at
> /home/akhil/netperf/dpdk_up/dpdk-next-crypto/arm64-dpaa-linuxapp-gcc/include/rte_ipsec.h:115
> (gdb) p /x *ss
> $1 = {sa = 0x17ad7ea40, type = 0x3, {crypto = {ses = 0x165a4e900},
> security = {ses = 0x165a4e900, ctx = 0x0, ol_flags = 0x0}}, pkt_func = {
> prepare = 0x0, process = 0x0}}
>
I guess I understand the reason:
right now rte_ipsec_session_prepare() expects that
for all modes except RTE_SECURITY_ACTION_TYPE_NONE
security.ctx to be not NULL.
Which as I understand is not necessary for lookaside-proto.
Could you try the fix below?
If it would work as expected, I'll include these changes into v6?
Konstantin
---
examples/ipsec-secgw/ipsec_process.c | 24
lib/librte_ipsec/ses.c | 11 +--
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec_process.c
b/examples/ipsec-secgw/ipsec_process.c
index 7ab378f6a..e403c461a 100644
--- a/examples/ipsec-secgw/ipsec_process.c
+++ b/examples/ipsec-secgw/ipsec_process.c
@@ -87,19 +87,36 @@ enqueue_cop_bulk(struct cdev_qp *cqp, struct rte_crypto_op
*cop[], uint32_t num)
}
static inline int
-fill_ipsec_session(struct rte_ipsec_session *ss, const struct ipsec_sa *sa)
+fill_ipsec_session(struct rte_ipsec_session *ss, struct ipsec_ctx *ctx,
+ struct ipsec_sa *sa)
{
+ int32_t rc;
+
/* setup crypto section */
if (ss->type == RTE_SECURITY_ACTION_TYPE_NONE) {
+ if (sa->crypto_session == NULL) {
+ rc = create_session(ctx, sa);
+ if (rc != 0)
+ return rc;
+ }
ss->crypto.ses = sa->crypto_session;
/* setup session action type */
} else {
+ if (sa->sec_session == NULL) {
+ rc = create_session(ctx, sa);
+ if (rc != 0)
+ return rc;
+ }
ss->security.ses = sa->sec_session;
ss->security.ctx = sa->security_ctx;
ss->security.ol_flags = sa->ol_flags;
}
- return rte_ipsec_session_prepare(ss);
+ rc = rte_ipsec_session_prepare(ss);
+ if (rc != 0)
+ memset(ss, 0, sizeof(*ss));
+
+ return rc;
}
/*
@@ -209,8 +226,7 @@ ipsec_process(struct ipsec_ctx *ctx, struct ipsec_traffic
*trf)
/* no valid HW session for that SA, try to create one */
if (ips->crypto.ses == NULL &&
- (create_session(ctx, sa) != 0 ||
- fill_ipsec_session(ips, sa) != 0))
+ fill_ipsec_session(ips, ctx, sa) != 0)
k = 0;
/* process packets inline */
diff --git a/lib/librte_ipsec/ses.c b/lib/librte_ipsec/ses.c
index 562c1423e..11580970e 100644
--- a/lib/librte_ipsec/ses.c
+++ b/lib/librte_ipsec/ses.c
@@ -14,8 +14,15 @@ session_check(struct rte_ipsec_session *ss)
if (ss->type == RTE_SECURITY_ACTION_TYPE_NONE) {
if (ss->crypto.ses == NULL)
return -EINVAL;
- } else if (ss->security.ses == NULL || ss->security.ctx == NULL)
- return -EINVAL;
+ } else {
+ if (ss->security.ses == NULL)
+ return -EINVAL;
+ if ((ss->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO ||
+ ss->type ==
+ RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) &&
+ ss->security.ctx == NULL)
+ return -EINVAL;
+ }
return 0;
}
--
2.17.1
Re: [dpdk-dev] [PATCH v5 01/10] examples/ipsec-secgw: allow user to disable some RX/TX offloads
On 12/28/2018 9:03 PM, Konstantin Ananyev wrote:
> Right now ipsec-secgw always enables TX offloads
> (DEV_TX_OFFLOAD_MULTI_SEGS, DEV_TX_OFFLOAD_SECURITY),
> even when they are not requested by the config.
> That causes many PMD to choose full-featured TX function,
> which in many cases is much slower then one without offloads.
> That patch adds ability for the user to disable unneeded HW offloads.
> If DEV_TX_OFFLOAD_IPV4_CKSUM is disabled by user, then
> SW version of ip cksum calculation is used.
> That allows to use vector TX function, when inline-ipsec is not
> requested.
>
> Signed-off-by: Remy Horton
> Signed-off-by: Konstantin Ananyev
> Acked-by: Radu Nicolau
> ---
> doc/guides/sample_app_ug/ipsec_secgw.rst | 12 +++
> examples/ipsec-secgw/ipsec-secgw.c | 126 ---
> examples/ipsec-secgw/ipsec.h | 6 ++
> examples/ipsec-secgw/sa.c| 35 +++
> 4 files changed, 164 insertions(+), 15 deletions(-)
>
> diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst
> b/doc/guides/sample_app_ug/ipsec_secgw.rst
> index 4869a011d..244bde2de 100644
> --- a/doc/guides/sample_app_ug/ipsec_secgw.rst
> +++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
> @@ -95,6 +95,8 @@ The application has a number of command line options::
> -p PORTMASK -P -u PORTMASK -j FRAMESIZE
> --config (port,queue,lcore)[,(port,queue,lcore]
> --single-sa SAIDX
> +--rxoffload MASK
> +--txoffload MASK
> -f CONFIG_FILE_PATH
>
> Where:
> @@ -119,6 +121,16 @@ Where:
> on both Inbound and Outbound. This option is meant for
> debugging/performance
> purposes.
>
> +* ``--rxoffload MASK``: RX HW offload capabilities to enable/use on this
> port
> +(bitmask of DEV_RX_OFFLOAD_* values). It is an optional parameter and
> +allows user to disable some of the RX HW offload capabilities.
> +By default all HW RX offloads are enabled.
> +
> +* ``--txoffload MASK``: TX HW offload capabilities to enable/use on this
> port
> +(bitmask of DEV_TX_OFFLOAD_* values). It is an optional parameter and
> +allows user to disable some of the TX HW offload capabilities.
> +By default all HW TX offloads are enabled.
> +
by default all should not be enabled. It should remain as it was before
your patchset.
It would be good if you can add a link to ethdev section where it
explain different offloads available.
If anyone needs to change the default behavior, a patch need to be
submitted to add that.
> * ``-f CONFIG_FILE_PATH``: the full path of text-based file containing all
> configuration items for running the application (See Configuration file
> syntax section below). ``-f CONFIG_FILE_PATH`` **must** be specified.
> diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> b/examples/ipsec-secgw/ipsec-secgw.c
> index 1bc0b5b50..f5db3da0c 100644
> --- a/examples/ipsec-secgw/ipsec-secgw.c
> +++ b/examples/ipsec-secgw/ipsec-secgw.c
> @@ -124,6 +124,8 @@ struct ethaddr_info ethaddr_tbl[RTE_MAX_ETHPORTS] = {
> #define CMD_LINE_OPT_CONFIG "config"
> #define CMD_LINE_OPT_SINGLE_SA "single-sa"
> #define CMD_LINE_OPT_CRYPTODEV_MASK "cryptodev_mask"
> +#define CMD_LINE_OPT_RX_OFFLOAD "rxoffload"
> +#define CMD_LINE_OPT_TX_OFFLOAD "txoffload"
>
> enum {
> /* long options mapped to a short option */
> @@ -135,12 +137,16 @@ enum {
> CMD_LINE_OPT_CONFIG_NUM,
> CMD_LINE_OPT_SINGLE_SA_NUM,
> CMD_LINE_OPT_CRYPTODEV_MASK_NUM,
> + CMD_LINE_OPT_RX_OFFLOAD_NUM,
> + CMD_LINE_OPT_TX_OFFLOAD_NUM,
> };
>
> static const struct option lgopts[] = {
> {CMD_LINE_OPT_CONFIG, 1, 0, CMD_LINE_OPT_CONFIG_NUM},
> {CMD_LINE_OPT_SINGLE_SA, 1, 0, CMD_LINE_OPT_SINGLE_SA_NUM},
> {CMD_LINE_OPT_CRYPTODEV_MASK, 1, 0, CMD_LINE_OPT_CRYPTODEV_MASK_NUM},
> + {CMD_LINE_OPT_RX_OFFLOAD, 1, 0, CMD_LINE_OPT_RX_OFFLOAD_NUM},
> + {CMD_LINE_OPT_TX_OFFLOAD, 1, 0, CMD_LINE_OPT_TX_OFFLOAD_NUM},
> {NULL, 0, 0, 0}
> };
>
> @@ -155,6 +161,13 @@ static uint32_t single_sa;
> static uint32_t single_sa_idx;
> static uint32_t frame_size;
>
> +/*
> + * RX/TX HW offload capabilities to enable/use on ethernet ports.
> + * By default all capabilities are enabled.
> + */
> +static uint64_t dev_rx_offload = UINT64_MAX;
> +static uint64_t dev_tx_offload = UINT64_MAX;
> +
> struct lcore_rx_queue {
> uint16_t port_id;
> uint8_t queue_id;
> @@ -208,8 +221,6 @@ static struct rte_eth_conf port_conf = {
> },
> .txmode = {
> .mq_mode = ETH_MQ_TX_NONE,
> - .offloads = (DEV_TX_OFFLOAD_IPV4_CKSUM |
> - DEV_TX_OFFLOAD_MULTI_SEGS),
> },
> };
>
> @@ -315,7 +326,8 @@ prepare_traffic(struct rte_mbuf **pkts, struct
> ipsec_traffic *t,
> }
>
> static inlin
Re: [dpdk-dev] [PATCH v5 03/10] examples/ipsec-secgw: fix crypto-op might never get dequeued
>
> On 12/28/2018 9:03 PM, Konstantin Ananyev wrote:
> > In some cases crypto-ops could never be dequeued from the crypto-device.
> > The easiest way to reproduce:
> > start ipsec-secgw with crypto-dev and send to it less then 32 packets.
> > none packets will be forwarded.
> > Reason for that is that the application does dequeue() from crypto-queues
> > only when new packets arrive.
> > This patch makes sure it calls dequeue() on a regular basis.
> >
> > Fixes: c64278c0c18b ("examples/ipsec-secgw: rework processing loop")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Konstantin Ananyev
> > Acked-by: Radu Nicolau
> > ---
> > examples/ipsec-secgw/ipsec-secgw.c | 136 -
> > examples/ipsec-secgw/ipsec.c | 60 -
> > examples/ipsec-secgw/ipsec.h | 11 +++
> > 3 files changed, 165 insertions(+), 42 deletions(-)
> [snip]
> > +
> > /* main processing loop */
> > static int32_t
> > main_loop(__attribute__((unused)) void *dummy)
> > @@ -866,7 +958,8 @@ main_loop(__attribute__((unused)) void *dummy)
> > diff_tsc = cur_tsc - prev_tsc;
> >
> > if (unlikely(diff_tsc > drain_tsc)) {
> > - drain_buffers(qconf);
> > + drain_tx_buffers(qconf);
> > + drain_crypto_buffers(qconf);
> > prev_tsc = cur_tsc;
> > }
> >
> > @@ -880,6 +973,9 @@ main_loop(__attribute__((unused)) void *dummy)
> > if (nb_rx > 0)
> > process_pkts(qconf, pkts, nb_rx, portid);
> > }
> > +
> > + drain_inbound_crypto_queues(qconf, &qconf->inbound);
> > + drain_outbound_crypto_queues(qconf, &qconf->outbound);
>
> drain_inbound_crypto_queues and drain_outbound_crypto_queues should be called
> based on diff_tsc.
> moving these two lines above after drain_crypto_buffers will improve the
> performance drop caused due to this patch.
Thanks, good to know.
To make what you suggest above to work properly with non-legacy mode ('-l')
extra changes
would be needed...
Do you have an idea - what exactly causing a slowdown?
Just an extra function calls (drain_inbound_crypto_queues/
drain_outbound_crypto_queues)?
Or is that because we do dequeue() from crypto PMD more often then before?
Konstantin
Re: [dpdk-dev] [PATCH v5 03/10] examples/ipsec-secgw: fix crypto-op might never get dequeued
On 1/2/2019 7:13 PM, Ananyev, Konstantin wrote:
>
>> On 12/28/2018 9:03 PM, Konstantin Ananyev wrote:
>>> In some cases crypto-ops could never be dequeued from the crypto-device.
>>> The easiest way to reproduce:
>>> start ipsec-secgw with crypto-dev and send to it less then 32 packets.
>>> none packets will be forwarded.
>>> Reason for that is that the application does dequeue() from crypto-queues
>>> only when new packets arrive.
>>> This patch makes sure it calls dequeue() on a regular basis.
>>>
>>> Fixes: c64278c0c18b ("examples/ipsec-secgw: rework processing loop")
>>> Cc: sta...@dpdk.org
>>>
>>> Signed-off-by: Konstantin Ananyev
>>> Acked-by: Radu Nicolau
>>> ---
>>>examples/ipsec-secgw/ipsec-secgw.c | 136 -
>>>examples/ipsec-secgw/ipsec.c | 60 -
>>>examples/ipsec-secgw/ipsec.h | 11 +++
>>>3 files changed, 165 insertions(+), 42 deletions(-)
>> [snip]
>>> +
>>>/* main processing loop */
>>>static int32_t
>>>main_loop(__attribute__((unused)) void *dummy)
>>> @@ -866,7 +958,8 @@ main_loop(__attribute__((unused)) void *dummy)
>>> diff_tsc = cur_tsc - prev_tsc;
>>>
>>> if (unlikely(diff_tsc > drain_tsc)) {
>>> - drain_buffers(qconf);
>>> + drain_tx_buffers(qconf);
>>> + drain_crypto_buffers(qconf);
>>> prev_tsc = cur_tsc;
>>> }
>>>
>>> @@ -880,6 +973,9 @@ main_loop(__attribute__((unused)) void *dummy)
>>> if (nb_rx > 0)
>>> process_pkts(qconf, pkts, nb_rx, portid);
>>> }
>>> +
>>> + drain_inbound_crypto_queues(qconf, &qconf->inbound);
>>> + drain_outbound_crypto_queues(qconf, &qconf->outbound);
>> drain_inbound_crypto_queues and drain_outbound_crypto_queues should be
>> called based on diff_tsc.
>> moving these two lines above after drain_crypto_buffers will improve the
>> performance drop caused due to this patch.
> Thanks, good to know.
> To make what you suggest above to work properly with non-legacy mode ('-l')
> extra changes
> would be needed...
What changes do you see?
> Do you have an idea - what exactly causing a slowdown?
> Just an extra function calls (drain_inbound_crypto_queues/
> drain_outbound_crypto_queues)?
> Or is that because we do dequeue() from crypto PMD more often then before?
I have not profiled it, but it should be because of more dequeues. On a
single call to dequeue, a burst of packets get dequeued. but now there
will be a lot more dequeues which have lesser packets than the burst
size which will deteriorate the performance as it would be wasting the
dequeue cycles.
This patch is causing around 5% drop out of the 10% that I mentioned in
the other mail.
With the change that I suggested, I am almost able to get back those 5%.
> Konstantin
>
>
[dpdk-dev] [PATCH] app/testbbdev: fix checking for return value
Added assert check for rte_bbdev_*_op_alloc_bulk in bbdev test app
Coverity issue: 328516
Coverity issue: 328525
Fixes: f714a18885a6 ("app/testbbdev: add test application for bbdev")
Signed-off-by: Amr Mokhtar
---
app/test-bbdev/test_bbdev_perf.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index 1c4a645..d18ddae 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -2104,7 +2104,10 @@ offload_latency_test_dec(struct rte_mempool *mempool,
struct test_buffers *bufs,
if (unlikely(num_to_process - dequeued < burst_sz))
burst_sz = num_to_process - dequeued;
- rte_bbdev_dec_op_alloc_bulk(mempool, ops_enq, burst_sz);
+ ret = rte_bbdev_dec_op_alloc_bulk(mempool, ops_enq, burst_sz);
+ TEST_ASSERT_SUCCESS(ret, "Allocation failed for %d ops",
+ burst_sz);
+
if (test_vector.op_type != RTE_BBDEV_OP_NONE)
copy_reference_dec_op(ops_enq, burst_sz, dequeued,
bufs->inputs,
@@ -2186,7 +2189,10 @@ offload_latency_test_enc(struct rte_mempool *mempool,
struct test_buffers *bufs,
if (unlikely(num_to_process - dequeued < burst_sz))
burst_sz = num_to_process - dequeued;
- rte_bbdev_enc_op_alloc_bulk(mempool, ops_enq, burst_sz);
+ ret = rte_bbdev_enc_op_alloc_bulk(mempool, ops_enq, burst_sz);
+ TEST_ASSERT_SUCCESS(ret, "Allocation failed for %d ops",
+ burst_sz);
+
if (test_vector.op_type != RTE_BBDEV_OP_NONE)
copy_reference_enc_op(ops_enq, burst_sz, dequeued,
bufs->inputs,
--
2.4.11
Re: [dpdk-dev] [PATCH] eal: fix core number validation
On Thu, Dec 20, 2018 at 11:01 AM Hari Kumar Vemula <
hari.kumarx.vem...@intel.com> wrote:
> When incorrect core value or range provided,
> as part of -l command line option, a crash occurs.
>
> Added valid range checks to fix the crash.
>
> Fixes: d888cb8b9613 ("eal: add core list input format")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Hari Kumar Vemula
> ---
> lib/librte_eal/common/eal_common_options.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/lib/librte_eal/common/eal_common_options.c
> b/lib/librte_eal/common/eal_common_options.c
> index e31eca5c0..ea6bb508b 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -602,6 +602,14 @@ eal_parse_corelist(const char *corelist)
> max = idx;
> if (min == RTE_MAX_LCORE)
> min = idx;
> + if ((unsigned int)idx >= cfg->lcore_count ||
> + (unsigned int)min >=
> cfg->lcore_count) {
>
Rather than check those conditions here, check directly after parsing the
input string.
Those casts will have side effects with negative values and the use of
current strtoul is suspicious to me.
You should switch to strtol, check for negative values and for the max
value according to cfg->lcore_count.
> + RTE_LOG(ERR, EAL,
> + "Invalid core number given core
> range should be(0-%u)\n",
> + cfg->lcore_count);
>
This log message will be a duplicate with the message in
eal_parse_common_option() so please drop this.
We could add the range in the current log message in
eal_parse_common_option(), but please, the range is [0, cfg->lcore_count -
1].
+ return -1;
> + }
> +
> for (idx = min; idx <= max; idx++) {
> if (cfg->lcore_role[idx] != ROLE_RTE) {
> cfg->lcore_role[idx] = ROLE_RTE;
>
--
David Marchand
Re: [dpdk-dev] [PATCH v5 00/10] examples/ipsec-secgw: make app to use ipsec library
On 1/2/2019 6:31 PM, Ananyev, Konstantin wrote:
> Hi Akhil,
>
>> Hi Konstantin,
>>
>> I just got results on running the ipsec-secgw on NXP hardware.
> Thanks for doing that.
> We don't have NXP HW, so would need more help from you.
>
>> with -l option, I got a seg fault while running traffic. gdb suggest
>> that pkt_func is not filled up and is NULL.
>> #1 0x004689bc in rte_ipsec_pkt_crypto_prepare (ss=0x17ad82d80,
>> mb=0xe498, cop=0xdfc0, num=1)
>> at
>> /home/akhil/netperf/dpdk_up/dpdk-next-crypto/arm64-dpaa-linuxapp-gcc/include/rte_ipsec.h:115
>> (gdb) p /x *ss
>> $1 = {sa = 0x17ad7ea40, type = 0x3, {crypto = {ses = 0x165a4e900},
>> security = {ses = 0x165a4e900, ctx = 0x0, ol_flags = 0x0}}, pkt_func = {
>> prepare = 0x0, process = 0x0}}
>>
> I guess I understand the reason:
> right now rte_ipsec_session_prepare() expects that
> for all modes except RTE_SECURITY_ACTION_TYPE_NONE
> security.ctx to be not NULL.
> Which as I understand is not necessary for lookaside-proto.
> Could you try the fix below?
> If it would work as expected, I'll include these changes into v6?
It did not crash this time with the below fix but the performance is
very very poor(~95% drop) if I use -l option with lookaside mode.
I have not analyzed the issue yet. Will be doing it on Friday.
> Konstantin
>
> ---
> examples/ipsec-secgw/ipsec_process.c | 24
> lib/librte_ipsec/ses.c | 11 +--
> 2 files changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/examples/ipsec-secgw/ipsec_process.c
> b/examples/ipsec-secgw/ipsec_process.c
> index 7ab378f6a..e403c461a 100644
> --- a/examples/ipsec-secgw/ipsec_process.c
> +++ b/examples/ipsec-secgw/ipsec_process.c
> @@ -87,19 +87,36 @@ enqueue_cop_bulk(struct cdev_qp *cqp, struct
> rte_crypto_op *cop[], uint32_t num)
> }
>
> static inline int
> -fill_ipsec_session(struct rte_ipsec_session *ss, const struct ipsec_sa *sa)
> +fill_ipsec_session(struct rte_ipsec_session *ss, struct ipsec_ctx *ctx,
> + struct ipsec_sa *sa)
> {
> + int32_t rc;
> +
> /* setup crypto section */
> if (ss->type == RTE_SECURITY_ACTION_TYPE_NONE) {
> + if (sa->crypto_session == NULL) {
> + rc = create_session(ctx, sa);
> + if (rc != 0)
> + return rc;
> + }
> ss->crypto.ses = sa->crypto_session;
> /* setup session action type */
> } else {
> + if (sa->sec_session == NULL) {
> + rc = create_session(ctx, sa);
> + if (rc != 0)
> + return rc;
> + }
> ss->security.ses = sa->sec_session;
> ss->security.ctx = sa->security_ctx;
> ss->security.ol_flags = sa->ol_flags;
> }
>
> - return rte_ipsec_session_prepare(ss);
> + rc = rte_ipsec_session_prepare(ss);
> + if (rc != 0)
> + memset(ss, 0, sizeof(*ss));
> +
> + return rc;
> }
>
> /*
> @@ -209,8 +226,7 @@ ipsec_process(struct ipsec_ctx *ctx, struct ipsec_traffic
> *trf)
>
> /* no valid HW session for that SA, try to create one */
> if (ips->crypto.ses == NULL &&
> - (create_session(ctx, sa) != 0 ||
> - fill_ipsec_session(ips, sa) != 0))
> + fill_ipsec_session(ips, ctx, sa) != 0)
> k = 0;
>
> /* process packets inline */
> diff --git a/lib/librte_ipsec/ses.c b/lib/librte_ipsec/ses.c
> index 562c1423e..11580970e 100644
> --- a/lib/librte_ipsec/ses.c
> +++ b/lib/librte_ipsec/ses.c
> @@ -14,8 +14,15 @@ session_check(struct rte_ipsec_session *ss)
> if (ss->type == RTE_SECURITY_ACTION_TYPE_NONE) {
> if (ss->crypto.ses == NULL)
> return -EINVAL;
> - } else if (ss->security.ses == NULL || ss->security.ctx == NULL)
> - return -EINVAL;
> + } else {
> + if (ss->security.ses == NULL)
> + return -EINVAL;
> + if ((ss->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO ||
> + ss->type ==
> + RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) &&
> + ss->security.ctx == NULL)
> + return -EINVAL;
> + }
>
> return 0;
> }
Re: [dpdk-dev] [PATCH 1/3] eal: add --dev-hotplug option
Hello Jeff, On Sat, Dec 29, 2018 at 5:06 AM Jeff Guo wrote: > On 12/17/2018 6:15 PM, David Marchand wrote: > > > On Fri, Dec 14, 2018 at 8:41 AM Jeff Guo wrote: > >> This command-line option will enable hotplug event detecting and enable >> hotplug handling for device hotplug. >> >> Signed-off-by: Jeff Guo >> > > Is there a reason why we would want this disabled by default and enabled > via option ? > > > Before i can give you an answer, let's see what will bring on if enable > it. > > When enable the hotplug will means that it will bring a new netlink socket > communication > > and a sigbus detecting and specific processing. So if user not want to add > this work load, just > > let it to be optional. Do you agree with that? If not please show what is > your concern. Thanks. > If the user does nothing about the sigbus signal handling but the eal signal handler was not registered, the dpdk app will end up being terminated by the kernel. If the user wants to do its own things and don't want the eal to mess with it... I am under the impression that he can disable the eal sigbus handler by calling rte_dev_hotplug_handle_disable(). The netlink stuff is handled in the interrupt thread, no impact on the processing threads and no additional thread afaics. -- David Marchand
Re: [dpdk-dev] [PATCH] examples/flow_filtering: fix example documentation
On 12/25/2018 6:30 AM, Dekel Peled wrote: > PSB. > >> -Original Message- >> From: Ori Kam >> Sent: Tuesday, December 25, 2018 5:25 AM >> To: Dekel Peled >> Cc: dev@dpdk.org; Dekel Peled >> Subject: RE: [dpdk-dev] [PATCH] examples/flow_filtering: fix example >> documentation >> >> >> >>> -Original Message- >>> From: dev On Behalf Of Dekel Peled >>> Sent: Monday, December 24, 2018 12:51 PM >>> To: Ori Kam >>> Cc: dev@dpdk.org; Dekel Peled >>> Subject: [dpdk-dev] [PATCH] examples/flow_filtering: fix example >>> documentation >>> >>> Previous patch removed the VLAN item from example code. >>> This patch fixes the documentation accordingly. >> >> So why are you modifying the c file? >> > > The doc file quotes the c file, needed to modify both to align doc with code. > Code change includes fix of comments, and removing redundant variables and > their initialization. What about removing the code from doc file, it is guaranteed that it will be outdated again? Or perhaps just add pseudo code if required.
Re: [dpdk-dev] vmovdqa64 instruction: how to be disabled in skylake CPU
On 12/23/2018 12:43 PM, zhuangyan wrote: > Hello, > > Is there any way to disable the generation of “vmovdqa64” instruction during > the compilation of dpdk library on Intel Skylake CPU? > > My dev VM uses Intel Skylake CPU while my test machine uses Intel uses > Intel(R) Xeon(R) CPU E5-2630 v4 that is some sort of Intel Broadwell CPU. > > And my generated executable file of dpdk application contains "vmovdqa64" > instruction that is NOT supported in Intel Broadwell CPU so my dpdk > application fails to be run. > > I tried MACHINE_CFLAGS= -march=native/broadwell/ivybridge within > dpdk-stable-17.11.2/mk/machine/native/rte.vars.mk, however it does not work. > > Additionally, my gcc version is gcc (Debian 4.9.2-10+deb8u1) 4.9.2. In config file, it is possible to select machine type, via "CONFIG_RTE_MACHINE=" config option. If it is "native", it will use all available CPU features host machine supports. For portability there is also "default" machine type, which will build for "corei7", this should work for your case. You can check available machine types at: 'mk/machine/*'
Re: [dpdk-dev] [PATCH v5 03/10] examples/ipsec-secgw: fix crypto-op might never get dequeued
> -Original Message-
> From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> Sent: Wednesday, January 2, 2019 1:51 PM
> To: Ananyev, Konstantin ; dev@dpdk.org
> Cc: sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 03/10] examples/ipsec-secgw: fix crypto-op
> might never get dequeued
>
>
>
> On 1/2/2019 7:13 PM, Ananyev, Konstantin wrote:
> >
> >> On 12/28/2018 9:03 PM, Konstantin Ananyev wrote:
> >>> In some cases crypto-ops could never be dequeued from the crypto-device.
> >>> The easiest way to reproduce:
> >>> start ipsec-secgw with crypto-dev and send to it less then 32 packets.
> >>> none packets will be forwarded.
> >>> Reason for that is that the application does dequeue() from crypto-queues
> >>> only when new packets arrive.
> >>> This patch makes sure it calls dequeue() on a regular basis.
> >>>
> >>> Fixes: c64278c0c18b ("examples/ipsec-secgw: rework processing loop")
> >>> Cc: sta...@dpdk.org
> >>>
> >>> Signed-off-by: Konstantin Ananyev
> >>> Acked-by: Radu Nicolau
> >>> ---
> >>>examples/ipsec-secgw/ipsec-secgw.c | 136 -
> >>>examples/ipsec-secgw/ipsec.c | 60 -
> >>>examples/ipsec-secgw/ipsec.h | 11 +++
> >>>3 files changed, 165 insertions(+), 42 deletions(-)
> >> [snip]
> >>> +
> >>>/* main processing loop */
> >>>static int32_t
> >>>main_loop(__attribute__((unused)) void *dummy)
> >>> @@ -866,7 +958,8 @@ main_loop(__attribute__((unused)) void *dummy)
> >>> diff_tsc = cur_tsc - prev_tsc;
> >>>
> >>> if (unlikely(diff_tsc > drain_tsc)) {
> >>> - drain_buffers(qconf);
> >>> + drain_tx_buffers(qconf);
> >>> + drain_crypto_buffers(qconf);
> >>> prev_tsc = cur_tsc;
> >>> }
> >>>
> >>> @@ -880,6 +973,9 @@ main_loop(__attribute__((unused)) void *dummy)
> >>> if (nb_rx > 0)
> >>> process_pkts(qconf, pkts, nb_rx,
> >>> portid);
> >>> }
> >>> +
> >>> + drain_inbound_crypto_queues(qconf, &qconf->inbound);
> >>> + drain_outbound_crypto_queues(qconf, &qconf->outbound);
> >> drain_inbound_crypto_queues and drain_outbound_crypto_queues should be
> >> called based on diff_tsc.
> >> moving these two lines above after drain_crypto_buffers will improve the
> >> performance drop caused due to this patch.
> > Thanks, good to know.
> > To make what you suggest above to work properly with non-legacy mode ('-l')
> > extra changes
> > would be needed...
> What changes do you see?
Non-legacy mode relies on a drain_crypto_queues() to dequeuer crypto-ops.
It doesn't do that as part of process_pkts().
It is doable, but it means I have to rework my patches a bit.
> > Do you have an idea - what exactly causing a slowdown?
> > Just an extra function calls (drain_inbound_crypto_queues/
> > drain_outbound_crypto_queues)?
> > Or is that because we do dequeue() from crypto PMD more often then before?
> I have not profiled it, but it should be because of more dequeues. On a
> single call to dequeue, a burst of packets get dequeued. but now there
> will be a lot more dequeues which have lesser packets than the burst
> size which will deteriorate the performance as it would be wasting the
> dequeue cycles.
>
> This patch is causing around 5% drop out of the 10% that I mentioned in
> the other mail.
> With the change that I suggested, I am almost able to get back those 5%.
Great, any idea what causing other 5%?
Konstantin
Re: [dpdk-dev] [PATCH v5 00/10] examples/ipsec-secgw: make app to use ipsec library
> -Original Message-
> From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> Sent: Wednesday, January 2, 2019 2:29 PM
> To: Ananyev, Konstantin ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 00/10] examples/ipsec-secgw: make app to
> use ipsec library
>
>
>
> On 1/2/2019 6:31 PM, Ananyev, Konstantin wrote:
> > Hi Akhil,
> >
> >> Hi Konstantin,
> >>
> >> I just got results on running the ipsec-secgw on NXP hardware.
> > Thanks for doing that.
> > We don't have NXP HW, so would need more help from you.
> >
> >> with -l option, I got a seg fault while running traffic. gdb suggest
> >> that pkt_func is not filled up and is NULL.
> >> #1 0x004689bc in rte_ipsec_pkt_crypto_prepare (ss=0x17ad82d80,
> >> mb=0xe498, cop=0xdfc0, num=1)
> >> at
> >> /home/akhil/netperf/dpdk_up/dpdk-next-crypto/arm64-dpaa-linuxapp-gcc/include/rte_ipsec.h:115
> >> (gdb) p /x *ss
> >> $1 = {sa = 0x17ad7ea40, type = 0x3, {crypto = {ses = 0x165a4e900},
> >> security = {ses = 0x165a4e900, ctx = 0x0, ol_flags = 0x0}}, pkt_func = {
> >> prepare = 0x0, process = 0x0}}
> >>
> > I guess I understand the reason:
> > right now rte_ipsec_session_prepare() expects that
> > for all modes except RTE_SECURITY_ACTION_TYPE_NONE
> > security.ctx to be not NULL.
> > Which as I understand is not necessary for lookaside-proto.
> > Could you try the fix below?
> > If it would work as expected, I'll include these changes into v6?
> It did not crash this time with the below fix but the performance is
> very very poor(~95% drop) if I use -l option with lookaside mode.
> I have not analyzed the issue yet. Will be doing it on Friday.
Did you run it with your previous change applied?
With drain_crypto_queues() moved under 'if (unlikely(diff_tsc > drain_tsc))'
condition?
If so, that could be the reason for such slowdown, see my other mail
regarding it.
Can you try to revert it (yes it would mean 5% drop for legacy mode)
and try again ((yes it would mean 5% drop for legacy mode,
but we can deal with it later)?
Konstantin
> >
> > ---
> > examples/ipsec-secgw/ipsec_process.c | 24
> > lib/librte_ipsec/ses.c | 11 +--
> > 2 files changed, 29 insertions(+), 6 deletions(-)
> >
> > diff --git a/examples/ipsec-secgw/ipsec_process.c
> > b/examples/ipsec-secgw/ipsec_process.c
> > index 7ab378f6a..e403c461a 100644
> > --- a/examples/ipsec-secgw/ipsec_process.c
> > +++ b/examples/ipsec-secgw/ipsec_process.c
> > @@ -87,19 +87,36 @@ enqueue_cop_bulk(struct cdev_qp *cqp, struct
> > rte_crypto_op *cop[], uint32_t num)
> > }
> >
> > static inline int
> > -fill_ipsec_session(struct rte_ipsec_session *ss, const struct ipsec_sa *sa)
> > +fill_ipsec_session(struct rte_ipsec_session *ss, struct ipsec_ctx *ctx,
> > + struct ipsec_sa *sa)
> > {
> > + int32_t rc;
> > +
> > /* setup crypto section */
> > if (ss->type == RTE_SECURITY_ACTION_TYPE_NONE) {
> > + if (sa->crypto_session == NULL) {
> > + rc = create_session(ctx, sa);
> > + if (rc != 0)
> > + return rc;
> > + }
> > ss->crypto.ses = sa->crypto_session;
> > /* setup session action type */
> > } else {
> > + if (sa->sec_session == NULL) {
> > + rc = create_session(ctx, sa);
> > + if (rc != 0)
> > + return rc;
> > + }
> > ss->security.ses = sa->sec_session;
> > ss->security.ctx = sa->security_ctx;
> > ss->security.ol_flags = sa->ol_flags;
> > }
> >
> > - return rte_ipsec_session_prepare(ss);
> > + rc = rte_ipsec_session_prepare(ss);
> > + if (rc != 0)
> > + memset(ss, 0, sizeof(*ss));
> > +
> > + return rc;
> > }
> >
> > /*
> > @@ -209,8 +226,7 @@ ipsec_process(struct ipsec_ctx *ctx, struct
> > ipsec_traffic *trf)
> >
> > /* no valid HW session for that SA, try to create one */
> > if (ips->crypto.ses == NULL &&
> > - (create_session(ctx, sa) != 0 ||
> > - fill_ipsec_session(ips, sa) != 0))
> > + fill_ipsec_session(ips, ctx, sa) != 0)
> > k = 0;
> >
> > /* process packets inline */
> > diff --git a/lib/librte_ipsec/ses.c b/lib/librte_ipsec/ses.c
> > index 562c1423e..11580970e 100644
> > --- a/lib/librte_ipsec/ses.c
> > +++ b/lib/librte_ipsec/ses.c
> > @@ -14,8 +14,15 @@ session_check(struct rte_ipsec_session *ss)
> > if (ss->type == RTE_SECURITY_ACTION_TYPE_NONE) {
> > if (ss->crypto.ses == NULL)
> > return -EINVAL;
> > - } else if (ss->security.ses == NULL || ss->security.ctx == NULL)
> > - return -EINVAL;
> > + } else {
> > + if (ss->security.ses == NULL)
> > + return -EINVAL;
> > + if ((ss->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO ||
> > +
[dpdk-dev] [PATCH] net/nfp: fix device start/stop for VFs
Previous commit adding multiprocess support broke VF support.
When VFs, the PMD does not set the link up or down.
Fixes: ef28aa96e53b ("net/nfp: support multiprocess")
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index ffef97d80..05a44a2a9 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -766,12 +766,14 @@ nfp_net_start(struct rte_eth_dev *dev)
goto error;
}
- if (hw->is_pf && rte_eal_process_type() == RTE_PROC_PRIMARY)
- /* Configure the physical port up */
- nfp_eth_set_configured(hw->cpp, hw->pf_port_idx, 1);
- else
- nfp_eth_set_configured(dev->process_private,
- hw->pf_port_idx, 1);
+ if (hw->is_pf) {
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ /* Configure the physical port up */
+ nfp_eth_set_configured(hw->cpp, hw->pf_port_idx, 1);
+ else
+ nfp_eth_set_configured(dev->process_private,
+ hw->pf_port_idx, 1);
+ }
hw->ctrl = new_ctrl;
@@ -820,12 +822,14 @@ nfp_net_stop(struct rte_eth_dev *dev)
(struct nfp_net_rxq *)dev->data->rx_queues[i]);
}
- if (hw->is_pf && rte_eal_process_type() == RTE_PROC_PRIMARY)
- /* Configure the physical port down */
- nfp_eth_set_configured(hw->cpp, hw->pf_port_idx, 0);
- else
- nfp_eth_set_configured(dev->process_private,
- hw->pf_port_idx, 0);
+ if (hw->is_pf) {
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ /* Configure the physical port down */
+ nfp_eth_set_configured(hw->cpp, hw->pf_port_idx, 0);
+ else
+ nfp_eth_set_configured(dev->process_private,
+ hw->pf_port_idx, 0);
+ }
}
/* Reset and stop device. The device can not be restarted. */
--
2.17.1
Re: [dpdk-dev] [PATCH v5 01/10] examples/ipsec-secgw: allow user to disable some RX/TX offloads
> -Original Message-
> From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> Sent: Wednesday, January 2, 2019 1:43 PM
> To: Ananyev, Konstantin ; dev@dpdk.org
> Cc: Horton, Remy
> Subject: Re: [dpdk-dev] [PATCH v5 01/10] examples/ipsec-secgw: allow user to
> disable some RX/TX offloads
>
>
>
> On 12/28/2018 9:03 PM, Konstantin Ananyev wrote:
> > Right now ipsec-secgw always enables TX offloads
> > (DEV_TX_OFFLOAD_MULTI_SEGS, DEV_TX_OFFLOAD_SECURITY),
> > even when they are not requested by the config.
> > That causes many PMD to choose full-featured TX function,
> > which in many cases is much slower then one without offloads.
> > That patch adds ability for the user to disable unneeded HW offloads.
> > If DEV_TX_OFFLOAD_IPV4_CKSUM is disabled by user, then
> > SW version of ip cksum calculation is used.
> > That allows to use vector TX function, when inline-ipsec is not
> > requested.
> >
> > Signed-off-by: Remy Horton
> > Signed-off-by: Konstantin Ananyev
> > Acked-by: Radu Nicolau
> > ---
> > doc/guides/sample_app_ug/ipsec_secgw.rst | 12 +++
> > examples/ipsec-secgw/ipsec-secgw.c | 126 ---
> > examples/ipsec-secgw/ipsec.h | 6 ++
> > examples/ipsec-secgw/sa.c| 35 +++
> > 4 files changed, 164 insertions(+), 15 deletions(-)
> >
> > diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst
> > b/doc/guides/sample_app_ug/ipsec_secgw.rst
> > index 4869a011d..244bde2de 100644
> > --- a/doc/guides/sample_app_ug/ipsec_secgw.rst
> > +++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
> > @@ -95,6 +95,8 @@ The application has a number of command line options::
> > -p PORTMASK -P -u PORTMASK -j FRAMESIZE
> > --config (port,queue,lcore)[,(port,queue,lcore]
> > --single-sa SAIDX
> > +--rxoffload MASK
> > +--txoffload MASK
> > -f CONFIG_FILE_PATH
> >
> > Where:
> > @@ -119,6 +121,16 @@ Where:
> > on both Inbound and Outbound. This option is meant for
> > debugging/performance
> > purposes.
> >
> > +* ``--rxoffload MASK``: RX HW offload capabilities to enable/use on this
> > port
> > +(bitmask of DEV_RX_OFFLOAD_* values). It is an optional parameter and
> > +allows user to disable some of the RX HW offload capabilities.
> > +By default all HW RX offloads are enabled.
> > +
> > +* ``--txoffload MASK``: TX HW offload capabilities to enable/use on this
> > port
> > +(bitmask of DEV_TX_OFFLOAD_* values). It is an optional parameter and
> > +allows user to disable some of the TX HW offload capabilities.
> > +By default all HW TX offloads are enabled.
> > +
> by default all should not be enabled. It should remain as it was before
> your patchset.
It remains as it was before the patchset.
By default we initialize dev_rx_offload/dev_tx_offloads to (uint64_t)-1;
Then:
dev_info.rx_offload_capa &= dev_rx_offload;
to disable unwanted capabilities.
Then:
if ((local_port_conf.rxmode.offloads & dev_info.rx_offload_capa)
to check that all required capabilities are supported.
> It would be good if you can add a link to ethdev section where it
> explain different offloads available.
>
> If anyone needs to change the default behavior, a patch need to be
> submitted to add that.
> > * ``-f CONFIG_FILE_PATH``: the full path of text-based file containing
> > all
> > configuration items for running the application (See Configuration
> > file
> > syntax section below). ``-f CONFIG_FILE_PATH`` **must** be specified.
> > diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> > b/examples/ipsec-secgw/ipsec-secgw.c
> > index 1bc0b5b50..f5db3da0c 100644
> > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > @@ -124,6 +124,8 @@ struct ethaddr_info ethaddr_tbl[RTE_MAX_ETHPORTS] = {
> > #define CMD_LINE_OPT_CONFIG "config"
> > #define CMD_LINE_OPT_SINGLE_SA"single-sa"
> > #define CMD_LINE_OPT_CRYPTODEV_MASK "cryptodev_mask"
> > +#define CMD_LINE_OPT_RX_OFFLOAD"rxoffload"
> > +#define CMD_LINE_OPT_TX_OFFLOAD"txoffload"
> >
> > enum {
> > /* long options mapped to a short option */
> > @@ -135,12 +137,16 @@ enum {
> > CMD_LINE_OPT_CONFIG_NUM,
> > CMD_LINE_OPT_SINGLE_SA_NUM,
> > CMD_LINE_OPT_CRYPTODEV_MASK_NUM,
> > + CMD_LINE_OPT_RX_OFFLOAD_NUM,
> > + CMD_LINE_OPT_TX_OFFLOAD_NUM,
> > };
> >
> > static const struct option lgopts[] = {
> > {CMD_LINE_OPT_CONFIG, 1, 0, CMD_LINE_OPT_CONFIG_NUM},
> > {CMD_LINE_OPT_SINGLE_SA, 1, 0, CMD_LINE_OPT_SINGLE_SA_NUM},
> > {CMD_LINE_OPT_CRYPTODEV_MASK, 1, 0, CMD_LINE_OPT_CRYPTODEV_MASK_NUM},
> > + {CMD_LINE_OPT_RX_OFFLOAD, 1, 0, CMD_LINE_OPT_RX_OFFLOAD_NUM},
> > + {CMD_LINE_OPT_TX_OFFLOAD, 1, 0, CMD_LINE_OPT_TX_OFFLOAD_NUM},
> > {NULL, 0, 0, 0}
> > };
> >
> > @@ -155,6 +161,13 @@ static
[dpdk-dev] DPDK 17.11.4 (Madvise)Transparent Huge pages
Hi, I am using DPDK 17.11.4 version . Do anybody have idea that DPDK is using benefit of Transparent huge-pages in case of Madvise. Thanks, Chetan Bhasin
[dpdk-dev] [PATCH] test/pmd_perf: change the way to drain the port
If the port has received less than ``pkt_per_port`` packets (for
example, the port has missed some packets), the test is in an infinite
loop.
Instead of expecting a number of packet to receive, let the port to be
drained by itself. If no more packets are received, the test can
continue.
Fixes: 002ade70e933 ("app/test: measure cycles per packet in Rx/Tx")
Cc: sta...@dpdk.org
Signed-off-by: Julien Meunier
---
test/test/test_pmd_perf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/test/test/test_pmd_perf.c b/test/test/test_pmd_perf.c
index f5095c8..286e09d 100644
--- a/test/test/test_pmd_perf.c
+++ b/test/test/test_pmd_perf.c
@@ -493,15 +493,15 @@ main_loop(__rte_unused void *args)
for (i = 0; i < conf->nb_ports; i++) {
portid = conf->portlist[i];
- int nb_free = pkt_per_port;
+ int nb_free = 0;
do { /* dry out */
nb_rx = rte_eth_rx_burst(portid, 0,
pkts_burst, MAX_PKT_BURST);
nb_tx = 0;
while (nb_tx < nb_rx)
rte_pktmbuf_free(pkts_burst[nb_tx++]);
- nb_free -= nb_rx;
- } while (nb_free != 0);
+ nb_free += nb_rx;
+ } while (nb_rx != 0);
printf("free %d mbuf left in port %u\n", pkt_per_port, portid);
}
--
2.10.2
[dpdk-dev] [PATCH] net/fm10k: initialize sm_down variable
Fixes: 6f22f2f67268 ("net/fm10k: redefine link status semantics")
Cc: sta...@dpdk.org
Signed-off-by: Julien Meunier
---
drivers/net/fm10k/fm10k_ethdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 85fb6c5..caf4d1b 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -3003,6 +3003,7 @@ fm10k_params_init(struct rte_eth_dev *dev)
hw->bus.payload = fm10k_bus_payload_256;
info->rx_vec_allowed = true;
+ info->sm_down = false;
}
static int
--
2.10.2
[dpdk-dev] [PATCH] net/ixgbe: add support of loopback for X540/X550
Loopback mode is also supported on X540 and X550 NICs, according to
their datasheet (section 15.2). The way to set it up is a little
different of the 82599.
Signed-off-by: Julien Meunier
---
drivers/net/ixgbe/ixgbe_ethdev.c | 10 ++---
drivers/net/ixgbe/ixgbe_ethdev.h | 5 ++---
drivers/net/ixgbe/ixgbe_rxtx.c | 47 ++--
3 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 7493110..7eb3303 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2652,9 +2652,13 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
goto error;
}
- /* Skip link setup if loopback mode is enabled for 82599. */
- if (hw->mac.type == ixgbe_mac_82599EB &&
- dev->data->dev_conf.lpbk_mode == IXGBE_LPBK_82599_TX_RX)
+ /* Skip link setup if loopback mode is enabled. */
+ if ((hw->mac.type == ixgbe_mac_82599EB ||
+hw->mac.type == ixgbe_mac_X540 ||
+hw->mac.type == ixgbe_mac_X550 ||
+hw->mac.type == ixgbe_mac_X550EM_x ||
+hw->mac.type == ixgbe_mac_X550EM_a) &&
+ dev->data->dev_conf.lpbk_mode == IXGBE_LPBK_TX_RX)
goto skip_link_setup;
if (ixgbe_is_sfp(hw) && hw->phy.multispeed_fiber) {
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 565c69c..c60a697 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -65,9 +65,8 @@
#define IXGBE_QUEUE_ITR_INTERVAL_DEFAULT 500 /* 500us */
/* Loopback operation modes */
-/* 82599 specific loopback operation types */
-#define IXGBE_LPBK_82599_NONE 0x0 /* Default value. Loopback is disabled. */
-#define IXGBE_LPBK_82599_TX_RX 0x1 /* Tx->Rx loopback operation is enabled. */
+#define IXGBE_LPBK_NONE 0x0 /* Default value. Loopback is disabled. */
+#define IXGBE_LPBK_TX_RX 0x1 /* Tx->Rx loopback operation is enabled. */
#define IXGBE_MAX_JUMBO_FRAME_SIZE 0x2600 /* Maximum Jumbo frame size. */
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 9a79d18..0ef7fdf 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -4879,10 +4879,14 @@ ixgbe_dev_rx_init(struct rte_eth_dev *dev)
hlreg0 &= ~IXGBE_HLREG0_JUMBOEN;
/*
-* If loopback mode is configured for 82599, set LPBK bit.
+* If loopback mode is configured, set LPBK bit.
*/
- if (hw->mac.type == ixgbe_mac_82599EB &&
- dev->data->dev_conf.lpbk_mode == IXGBE_LPBK_82599_TX_RX)
+ if ((hw->mac.type == ixgbe_mac_82599EB ||
+hw->mac.type == ixgbe_mac_X540 ||
+hw->mac.type == ixgbe_mac_X550 ||
+hw->mac.type == ixgbe_mac_X550EM_x ||
+hw->mac.type == ixgbe_mac_X550EM_a) &&
+ dev->data->dev_conf.lpbk_mode == IXGBE_LPBK_TX_RX)
hlreg0 |= IXGBE_HLREG0_LPBK;
else
hlreg0 &= ~IXGBE_HLREG0_LPBK;
@@ -5088,6 +5092,29 @@ ixgbe_setup_loopback_link_82599(struct ixgbe_hw *hw)
msec_delay(50);
}
+/*
+ * Set up link loopback for X540 / X550 mode Tx->Rx.
+ */
+static inline void __attribute__((cold))
+ixgbe_setup_loopback_link_x540_x550(struct ixgbe_hw *hw)
+{
+ uint32_t macc;
+ PMD_INIT_FUNC_TRACE();
+
+ /* datasheet 15.2.1: MACC.FLU = 1 (force link up) */
+ macc = IXGBE_READ_REG(hw, IXGBE_MACC);
+ macc |= IXGBE_MACC_FLU;
+ IXGBE_WRITE_REG(hw, IXGBE_MACC, macc);
+
+ /* Restart link */
+ IXGBE_WRITE_REG(hw,
+ IXGBE_AUTOC,
+ IXGBE_AUTOC_LMS_10G_LINK_NO_AN | IXGBE_AUTOC_FLU);
+
+ hw->mac.ops.release_swfw_sync(hw, IXGBE_GSSR_MAC_CSR_SM);
+ msec_delay(50);
+}
+
/*
* Start Transmit and Receive Units.
@@ -5148,10 +5175,16 @@ ixgbe_dev_rxtx_start(struct rte_eth_dev *dev)
rxctrl |= IXGBE_RXCTRL_RXEN;
hw->mac.ops.enable_rx_dma(hw, rxctrl);
- /* If loopback mode is enabled for 82599, set up the link accordingly */
- if (hw->mac.type == ixgbe_mac_82599EB &&
- dev->data->dev_conf.lpbk_mode == IXGBE_LPBK_82599_TX_RX)
- ixgbe_setup_loopback_link_82599(hw);
+ /* If loopback mode is enabled, set up the link accordingly */
+ if (dev->data->dev_conf.lpbk_mode == IXGBE_LPBK_TX_RX) {
+ if (hw->mac.type == ixgbe_mac_82599EB)
+ ixgbe_setup_loopback_link_82599(hw);
+ else if (hw->mac.type == ixgbe_mac_X540 ||
+hw->mac.type == ixgbe_mac_X550 ||
+hw->mac.type == ixgbe_mac_X550EM_x ||
+hw->mac.type == ixgbe_mac_X550EM_a)
+ ixgbe_setup_loopback_link_x540_x550(hw);
+ }
#ifdef RTE_LIBRTE_SECURITY
if ((dev->data->dev
Re: [dpdk-dev] [PATCH 1/3] rte_ethdev: Add API function to read dev clock
On 12/23/2018 6:06 AM, Shahaf Shuler wrote: > Ferruh, > > I share the same thoughts as Tom here. > > > >>Ferruh Yigit wrote : > >>> Is this a common enough feature to include into ethdev abstraction layer? >>> Or a > >>> feature for a single vendor? > >> > >>I found reference to mbuf’s timestamp field only in MLX5. I think it is the > only one to support timestamp offloading. This new API is only useful to make > sense out of the timestamp value. And without this patch, timestamp offloading > is completely useless… Why timestamp offloading become useless? When timestamp offloading enabled, device fills 'mbuf.timestamp' and you can use it. For your case this timestamp for mlx is device clock and you are adding this API to be able to convert device clock to real time, this is not something enables the timestamp offload. Technically driver can set the 'mbuf.timestamp' with the real clock right, if it is required? Or this can be defined by a devarg? Also this relates to how other HW vendors implemented this, if it is common approach to fill the timestamp with the device clock and there is way to clock reference from device, this may make sense. If other vendors already providing the real time on timestamp, this needs to be handled in mlx driver. That is why it is good to know what other vendors need / use this? > >> > >>What would be the other way ? Define something in mlx5 header and ask clients > to check for the driver and call the specific API ? > >> > >>I see reference to timestamp offloading in Netronome Agilio, CC-ing > maintainers. Is timestamp offloading a feature you could potentially provide ? > Would it be host time reference or a value that need conversion with an API > like > this? > > > > I don’t think that the number of vendors which implement the feature at > current > time is the qualifier for a feature to enter. Rather we should consider how > generic it is and its need in the world of networking (since it is ethdev). > > IMO, It is perfectly reasonable to expose a generic channel to read the device > clock, same as reading device register (which exists). > The concern is ethdev bloats with single vendor specific APIs. In the past we moved some of the ethdev APIs as PMD specific APIs to PMDs. It is not nice to have "PMD specific APIs" but that was the trade off for more usable ethdev API. And according techboard discussion [1] for new API(): " If the API is about HW abstraction, at least one driver should be implemented. Preferably two. " I am questioning if is there possible second one, and how is their implementation is like. [1] https://mails.dpdk.org/archives/dev/2018-November/118697.html
Re: [dpdk-dev] [PATCH] net/enic: fix possible uninitialized variable
On 12/22/2018 12:41 PM, Haiyang Tan wrote:
> The uninitialized field 'extra_flag' of hash parameter may enable
> certain feature silently. Typically, if bit0 of 'extra_flag' set, the
> hardware transactional memory support will be enabled unexpectedly.
>
> Signed-off-by: Haiyang Tan
> ---
> drivers/net/enic/enic_clsf.c | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/enic/enic_clsf.c b/drivers/net/enic/enic_clsf.c
> index 9d95201ec..f9707c78f 100644
> --- a/drivers/net/enic/enic_clsf.c
> +++ b/drivers/net/enic/enic_clsf.c
> @@ -475,14 +475,15 @@ void enic_clsf_destroy(struct enic *enic)
> int enic_clsf_init(struct enic *enic)
> {
> char clsf_name[RTE_HASH_NAMESIZE];
> - struct rte_hash_parameters hash_params = {
> - .name = clsf_name,
> - .entries = ENICPMD_CLSF_HASH_ENTRIES,
> - .key_len = sizeof(struct rte_eth_fdir_filter),
> - .hash_func = DEFAULT_HASH_FUNC,
> - .hash_func_init_val = 0,
> - .socket_id = SOCKET_ID_ANY,
> - };
> + struct rte_hash_parameters hash_params = { 0 };
> +
> + hash_params.name = clsf_name;
> + hash_params.entries = ENICPMD_CLSF_HASH_ENTRIES;
> + hash_params.key_len = sizeof(struct rte_eth_fdir_filter);
> + hash_params.hash_func = DEFAULT_HASH_FUNC;
> + hash_params.hash_func_init_val = 0;
> + hash_params.socket_id = SOCKET_ID_ANY;
Both code should be doing same thing, since unassigned values are set to 0 by
default, and 'extra_flag' should be already set to zero with old code.
There are a few patches for same thing, I am updating all as 'Rejected', please
shout if I am missing something here.
Re: [dpdk-dev] [PATCH v1] examples/l3fwd: enable hash multi lookup for ARM
Thanks Ruifeng for the patch. I have one question inline.
Jerin/Hemant,
It would be good if you could test this on your platforms, since this
is being made default.
Thanks,
Honnappa
> -Original Message-
> From: Ruifeng Wang
> Sent: Tuesday, January 1, 2019 11:28 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; jer...@marvell.com; hemant.agra...@nxp.com;
> bruce.richard...@intel.com; chao...@linux.vnet.ibm.com; Honnappa
> Nagarahalli ; nd ; Ruifeng
> Wang (Arm Technology China) ;
> tomaszx.kula...@intel.com
> Subject: [PATCH v1] examples/l3fwd: enable hash multi lookup for ARM
>
> Compile option for hash_multi_lookup was broken, and caused feature cannot
> be enabled on Arm.
> This patch sets hash_multi_lookup method as default, and sequential lookup
> becomes optional.
>
> In test of 8192 flows with 128-byte packets, throughput increased by 25.6%
> after enabling hash_multi_lookup.
>
I assume these are lookup-hit numbers. Do you have look-up miss numbers?
> Fixes: 52c97adc1f0f ("examples/l3fwd: fix exact match performance")
> Cc: tomaszx.kula...@intel.com
>
> Signed-off-by: Ruifeng Wang
> Reviewed-by: Gavin Hu
> Reviewed-by: Phil Yang
> Tested-by: Ruifeng Wang
> ---
> examples/l3fwd/l3fwd.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h index
> c962deac3..063b80018 100644
> --- a/examples/l3fwd/l3fwd.h
> +++ b/examples/l3fwd/l3fwd.h
> @@ -11,10 +11,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 */
>
> --
> 2.17.1
Re: [dpdk-dev] [PATCH v4 0/3] add rte ring reset api and use it to flush a ring by hash
> > 02/01/2019 01:55, Gavin Hu: > > V4: Include the ring perf test case enhancement patch in the series. This change is not related to this patch. Should be a separate patch? There were comments provided: http://mails.dpdk.org/archives/dev/2018-December/121893.html http://mails.dpdk.org/archives/dev/2018-December/122157.html Do you plan to address these? > > > > V3: Allow experimental API for meson build > > > > V2: Fix the coding style issue(commit message line too long) > > > > V1: To flush a ring not in use, dequeue one by one is wasting cpu cycles. > > The patch is to just resetting the head and tail indices to save cpu > > cycle. > > It is too late for adding this API in 19.02, but we should review and give > opinion, so it will be ready to integrate in early February. >
[dpdk-dev] Compiler for Windows
Hi, We need to gather inputs about the pros/cons of the C compilers available for Windows. Interesting criterias could be: - ease of use - availability - standards compliance - performance When the comparison will be complete, we should publish it in the doc/ directory, while porting DPDK to Windows. I start with few data: * gcc|clang on cygwin - not native * gcc/mingw * gcc/mingw-w64 * clang/mingw-w64 * clang --target=x86_64-windows-msvc * icc - not freely available * msvc - native - specific command line - not C99
Re: [dpdk-dev] [PATCH v1] examples/l3fwd: enable hash multi lookup for ARM
Hi Honnappa,
> -Original Message-
> From: Honnappa Nagarahalli
> Sent: Thursday, January 3, 2019 2:23
> To: Ruifeng Wang (Arm Technology China) ;
> dev@dpdk.org
> Cc: tho...@monjalon.net; jer...@marvell.com; hemant.agra...@nxp.com;
> bruce.richard...@intel.com; chao...@linux.vnet.ibm.com; nd
> ; Ruifeng Wang (Arm Technology China)
> ; tomaszx.kula...@intel.com; nd
> Subject: RE: [PATCH v1] examples/l3fwd: enable hash multi lookup for ARM
>
> Thanks Ruifeng for the patch. I have one question inline.
>
> Jerin/Hemant,
> It would be good if you could test this on your platforms, since this is
> being made default.
>
> Thanks,
> Honnappa
>
> > -Original Message-
> > From: Ruifeng Wang
> > Sent: Tuesday, January 1, 2019 11:28 PM
> > To: dev@dpdk.org
> > Cc: tho...@monjalon.net; jer...@marvell.com;
> hemant.agra...@nxp.com;
> > bruce.richard...@intel.com; chao...@linux.vnet.ibm.com; Honnappa
> > Nagarahalli ; nd ;
> Ruifeng
> > Wang (Arm Technology China) ;
> > tomaszx.kula...@intel.com
> > Subject: [PATCH v1] examples/l3fwd: enable hash multi lookup for ARM
> >
> > Compile option for hash_multi_lookup was broken, and caused feature
> > cannot be enabled on Arm.
> > This patch sets hash_multi_lookup method as default, and sequential
> > lookup becomes optional.
> >
> > In test of 8192 flows with 128-byte packets, throughput increased by
> > 25.6% after enabling hash_multi_lookup.
> >
> I assume these are lookup-hit numbers. Do you have look-up miss numbers?
>
Yes, lookup-hit had 25.6% gain.
In lookup-miss tests, throughput had over 33% gain.
> > Fixes: 52c97adc1f0f ("examples/l3fwd: fix exact match performance")
> > Cc: tomaszx.kula...@intel.com
> >
> > Signed-off-by: Ruifeng Wang
> > Reviewed-by: Gavin Hu
> > Reviewed-by: Phil Yang
> > Tested-by: Ruifeng Wang
> > ---
> > examples/l3fwd/l3fwd.h | 4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h index
> > c962deac3..063b80018 100644
> > --- a/examples/l3fwd/l3fwd.h
> > +++ b/examples/l3fwd/l3fwd.h
> > @@ -11,10 +11,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 */
> >
> > --
> > 2.17.1
Re: [dpdk-dev] [PATCH] net/fm10k: initialize sm_down variable
Hi Julien,
> -Original Message-
> From: Julien Meunier [mailto:julien.meun...@nokia.com]
> Sent: Wednesday, January 2, 2019 11:58 PM
> To: Zhang, Qi Z ; Wang, Xiao W
>
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: [PATCH] net/fm10k: initialize sm_down variable
>
> Fixes: 6f22f2f67268 ("net/fm10k: redefine link status semantics")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Julien Meunier
> ---
> drivers/net/fm10k/fm10k_ethdev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> b/drivers/net/fm10k/fm10k_ethdev.c
> index 85fb6c5..caf4d1b 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -3003,6 +3003,7 @@ fm10k_params_init(struct rte_eth_dev *dev)
> hw->bus.payload = fm10k_bus_payload_256;
>
> info->rx_vec_allowed = true;
> + info->sm_down = false;
> }
>
> static int
> --
> 2.10.2
Acked-by: Xiao Wang
BRs,
Xiao
[dpdk-dev] [PATCH v5 2/3] ring: add reset API to flush the ring when not in use
From: Gavin Hu
Currently, the flush is done by dequeuing the ring in a while loop. It is
much simpler to flush the queue by resetting the head and tail indices.
Signed-off-by: gavin hu
Reviewed-by: ruifeng wang
Reviewed-by: honnappa nagarahalli
---
lib/librte_ring/rte_ring.h | 20
lib/librte_ring/rte_ring_version.map | 7 +++
2 files changed, 27 insertions(+)
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af5444a..2830300 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -671,6 +671,26 @@ rte_ring_dequeue(struct rte_ring *r, void **obj_p)
}
/**
+ * Flush a ring.
+ *
+ * This function flush all the elements in a ring
+ *
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * @warning
+ * Make sure the ring is not in use while calling this function.
+ *
+ * @param r
+ * A pointer to the ring structure.
+ */
+static inline void __rte_experimental
+rte_ring_reset(struct rte_ring *r)
+{
+ r->prod.head = r->cons.head = 0;
+ r->prod.tail = r->cons.tail = 0;
+}
+
+/**
* Return the number of entries in a ring.
*
* @param r
diff --git a/lib/librte_ring/rte_ring_version.map
b/lib/librte_ring/rte_ring_version.map
index d935efd..581d9ca 100644
--- a/lib/librte_ring/rte_ring_version.map
+++ b/lib/librte_ring/rte_ring_version.map
@@ -17,3 +17,10 @@ DPDK_2.2 {
rte_ring_free;
} DPDK_2.0;
+
+EXPERIMENTAL {
+global:
+
+ rte_ring_reset;
+
+};
--
2.7.4
[dpdk-dev] [PATCH v5 3/3] hash: flush the rings instead of dequeuing one by one
From: Gavin Hu
Within rte_hash_reset, calling a while loop to dequeue one by
one from the ring, while not using them at all, is wasting cycles,
The patch just flush the ring by resetting the indices can save cpu
cycles.
Fixes: b26473ff8f4a ("hash: add reset function")
Fixes: 75706568a7eb ("hash: add extendable bucket feature")
Cc: sta...@dpdk.org
Signed-off-by: gavin hu
Reviewed-by: honnappa nagarahalli
---
lib/librte_hash/Makefile | 2 +-
lib/librte_hash/meson.build | 3 +++
lib/librte_hash/rte_cuckoo_hash.c | 11 ---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile
index c8c435d..5669d83 100644
--- a/lib/librte_hash/Makefile
+++ b/lib/librte_hash/Makefile
@@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
# library name
LIB = librte_hash.a
-CFLAGS += -O3
+CFLAGS += -O3 -DALLOW_EXPERIMENTAL_API
CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)
LDLIBS += -lrte_eal -lrte_ring
diff --git a/lib/librte_hash/meson.build b/lib/librte_hash/meson.build
index efc06ed..ebf70de 100644
--- a/lib/librte_hash/meson.build
+++ b/lib/librte_hash/meson.build
@@ -14,3 +14,6 @@ headers = files('rte_cmp_arm64.h',
sources = files('rte_cuckoo_hash.c', 'rte_fbk_hash.c')
deps += ['ring']
+
+# rte ring reset is not yet part of stable API
+allow_experimental_apis = true
diff --git a/lib/librte_hash/rte_cuckoo_hash.c
b/lib/librte_hash/rte_cuckoo_hash.c
index c01489b..4b08049 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -559,7 +559,6 @@ __hash_rw_reader_unlock(const struct rte_hash *h)
void
rte_hash_reset(struct rte_hash *h)
{
- void *ptr;
uint32_t tot_ring_cnt, i;
if (h == NULL)
@@ -570,16 +569,14 @@ rte_hash_reset(struct rte_hash *h)
memset(h->key_store, 0, h->key_entry_size * (h->entries + 1));
*h->tbl_chng_cnt = 0;
- /* clear the free ring */
- while (rte_ring_dequeue(h->free_slots, &ptr) == 0)
- continue;
+ /* reset the free ring */
+ rte_ring_reset(h->free_slots);
- /* clear free extendable bucket ring and memory */
+ /* flush free extendable bucket ring and memory */
if (h->ext_table_support) {
memset(h->buckets_ext, 0, h->num_buckets *
sizeof(struct rte_hash_bucket));
- while (rte_ring_dequeue(h->free_ext_bkts, &ptr) == 0)
- continue;
+ rte_ring_reset(h->free_ext_bkts);
}
/* Repopulate the free slots ring. Entry zero is reserved for key
misses */
--
2.7.4
[dpdk-dev] [PATCH v5 0/3] ring test enhancement and new ring reset api and use it by hash
V5: 1. Commit message tweaking for ring test case enhancement patch 2. Upper to lower for mails to make match/grep more easily V4: 1. Include the ring perf test case enhancement patch in the series. 2. Replace ARRAY_SIZE with RTE_DIM. 3. Call memset to avoid clang compling complains. V3: Allow experimental API for meson build V2: Fix the coding style issue(commit message line too long) V1: To flush a ring not in use, dequeue one by one is wasting cpu cycles. The patch is to just resetting the head and tail indices to save cpu cycle. Gavin Hu (2): ring: add reset API to flush the ring when not in use hash: flush the rings instead of dequeuing one by one Joyce Kong (1): test/ring: ring perf test case enhancement lib/librte_hash/Makefile | 2 +- lib/librte_hash/meson.build | 3 ++ lib/librte_hash/rte_cuckoo_hash.c| 11 ++--- lib/librte_ring/rte_ring.h | 20 + lib/librte_ring/rte_ring_version.map | 7 +++ test/test/test_ring_perf.c | 82 ++-- 6 files changed, 114 insertions(+), 11 deletions(-) -- 2.7.4
[dpdk-dev] [PATCH v5 1/3] test/ring: ring perf test case enhancement
From: Joyce Kong
Run ring perf test on all available cores to really verify MPMC operations.
The old way of running on a pair of cores is not enough for MPMC rings.
Suggested-by: gavin hu
Signed-off-by: joyce kong
Reviewed-by: ruifeng wang
Reviewed-by: honnappa nagarahalli
Reviewed-by: dharmik thakkar
Reviewed-by: ola liljedahl
Reviewed-by: gavin hu
---
test/test/test_ring_perf.c | 82 --
1 file changed, 79 insertions(+), 3 deletions(-)
diff --git a/test/test/test_ring_perf.c b/test/test/test_ring_perf.c
index ebb3939..01c6937 100644
--- a/test/test/test_ring_perf.c
+++ b/test/test/test_ring_perf.c
@@ -9,7 +9,7 @@
#include
#include
#include
-
+#include
#include "test.h"
/*
@@ -20,6 +20,7 @@
* * Empty ring dequeue
* * Enqueue/dequeue of bursts in 1 threads
* * Enqueue/dequeue of bursts in 2 threads
+ * * Enqueue/dequeue of bursts in all available threads
*/
#define RING_NAME "RING_PERF"
@@ -248,9 +249,80 @@ run_on_core_pair(struct lcore_pair *cores, struct rte_ring
*r,
}
}
+static rte_atomic32_t synchro;
+static uint64_t queue_count[RTE_MAX_LCORE];
+
+#define TIME_MS 100
+
+static int
+load_loop_fn(void *p)
+{
+ uint64_t time_diff = 0;
+ uint64_t begin = 0;
+ uint64_t hz = rte_get_timer_hz();
+ uint64_t lcount = 0;
+ const unsigned int lcore = rte_lcore_id();
+ struct thread_params *params = p;
+ void *burst[MAX_BURST] = {0};
+
+ /* wait synchro for slaves */
+ if (lcore != rte_get_master_lcore())
+ while (rte_atomic32_read(&synchro) == 0)
+ rte_pause();
+
+ begin = rte_get_timer_cycles();
+ while (time_diff < hz * TIME_MS / 1000) {
+ rte_ring_mp_enqueue_bulk(params->r, burst, params->size, NULL);
+ rte_ring_mc_dequeue_bulk(params->r, burst, params->size, NULL);
+ lcount++;
+ time_diff = rte_get_timer_cycles() - begin;
+ }
+ queue_count[lcore] = lcount;
+ return 0;
+}
+
+static int
+run_on_all_cores(struct rte_ring *r)
+{
+ uint64_t total = 0;
+ unsigned int i, c;
+ struct thread_params param;
+
+ memset(¶m, 0, sizeof(struct thread_params));
+ for (i = 0; i < RTE_DIM(bulk_sizes); i++) {
+ printf("\nBulk enq/dequeue count on size %u\n", bulk_sizes[i]);
+ param.size = bulk_sizes[i];
+ param.r = r;
+
+ /* clear synchro and start slaves */
+ rte_atomic32_set(&synchro, 0);
+ if (rte_eal_mp_remote_launch(load_loop_fn,
+ ¶m, SKIP_MASTER) < 0)
+ return -1;
+
+ /* start synchro and launch test on master */
+ rte_atomic32_set(&synchro, 1);
+ load_loop_fn(¶m);
+
+ rte_eal_mp_wait_lcore();
+
+ RTE_LCORE_FOREACH(c) {
+ printf("Core [%u] count = %"PRIu64"\n",
+ c, queue_count[c]);
+ total += queue_count[c];
+ }
+
+ printf("Total count (size: %u): %"PRIu64"\n", bulk_sizes[i],
+ total);
+ }
+
+ return 0;
+}
+
/*
- * Test function that determines how long an enqueue + dequeue of a single item
- * takes on a single lcore. Result is for comparison with the bulk enq+deq.
+ * Test function that determines how long an enqueue + dequeue of a single
+ * item takes on a single lcore. Result is for comparison with the bulk
+ * enq+deq.
*/
static void
test_single_enqueue_dequeue(struct rte_ring *r)
@@ -394,6 +466,10 @@ test_ring_perf(void)
printf("\n### Testing using two NUMA nodes ###\n");
run_on_core_pair(&cores, r, enqueue_bulk, dequeue_bulk);
}
+
+ printf("\n### Testing using all slave nodes ###\n");
+ run_on_all_cores(r);
+
rte_ring_free(r);
return 0;
}
--
2.7.4
Re: [dpdk-dev] [PATCH v4 1/3] test/ring: ring perf test case enhancement
> -Original Message- > From: Thomas Monjalon > Sent: Wednesday, January 2, 2019 8:49 PM > To: Gavin Hu (Arm Technology China) > Cc: dev@dpdk.org; jer...@marvell.com; hemant.agra...@nxp.com; > bruce.richard...@intel.com; chao...@linux.vnet.ibm.com; Honnappa > Nagarahalli ; nd ; > olivier.m...@6wind.com; Joyce Kong (Arm Technology China) > > Subject: Re: [PATCH v4 1/3] test/ring: ring perf test case enhancement > > > Suggested-by: Gavin Hu > > Signed-off-by: Joyce Kong > > Reviewed-by: Ruifeng Wang > > Reviewed-by: Honnappa Nagarahalli > > Reviewed-by: Dharmik Thakkar > > Reviewed-by: Ola Liljedahl > > Reviewed-by: Gavin Hu > > Small comment about the email addresses, > Please do not use uppercase so we can match/grep more easily. > Thanks for reminding, already fixed this in v5.
[dpdk-dev] [PATCH 2/2] net/virtio-user: fix supported features list
Currently virtio-user doesn't support event idx.
Fixes: aea29aa5d37b ("net/virtio: enable packed virtqueues by default")
Signed-off-by: Tiwei Bie
---
drivers/net/virtio/virtio_user/virtio_user_dev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c
b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index e21e3ec3c..b9044faff 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -410,8 +410,7 @@ virtio_user_dev_setup(struct virtio_user_dev *dev)
1ULL << VIRTIO_NET_F_GUEST_TSO6| \
1ULL << VIRTIO_F_IN_ORDER | \
1ULL << VIRTIO_F_VERSION_1 | \
-1ULL << VIRTIO_F_RING_PACKED | \
-1ULL << VIRTIO_RING_F_EVENT_IDX)
+1ULL << VIRTIO_F_RING_PACKED)
int
virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
--
2.17.1
[dpdk-dev] [PATCH 1/2] net/virtio-user: fix packed vq option parsing
Add the RING_PACKED feature to dev->unsupported_features
when it's disabled, and add the missing packed vq param
string. And also revert the unexpected change to MAC option
introduced when adding packed vq option.
Fixes: 34f3966c7f81 ("net/virtio-user: add option to use packed queues")
Signed-off-by: Tiwei Bie
---
drivers/net/virtio/virtio_user/virtio_user_dev.c | 11 ---
drivers/net/virtio/virtio_user_ethdev.c | 7 ---
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c
b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index 5560bd9a3..e21e3ec3c 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -474,17 +474,14 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char
*path, int queues,
"packed virtqueues\n");
return -1;
}
- dev->device_features |= (1ull << VIRTIO_F_RING_PACKED);
} else {
- dev->device_features &= ~(1ull << VIRTIO_F_RING_PACKED);
+ dev->unsupported_features |= (1ull << VIRTIO_F_RING_PACKED);
}
- if (dev->mac_specified) {
- dev->device_features |= (1ull << VIRTIO_NET_F_MAC);
- } else {
- dev->device_features &= ~(1ull << VIRTIO_NET_F_MAC);
+ if (dev->mac_specified)
+ dev->frontend_features |= (1ull << VIRTIO_NET_F_MAC);
+ else
dev->unsupported_features |= (1ull << VIRTIO_NET_F_MAC);
- }
if (cq) {
/* device does not really need to know anything about CQ,
diff --git a/drivers/net/virtio/virtio_user_ethdev.c
b/drivers/net/virtio/virtio_user_ethdev.c
index af2800605..2df6eb695 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -361,7 +361,7 @@ static const char *valid_args[] = {
VIRTIO_USER_ARG_MRG_RXBUF,
#define VIRTIO_USER_ARG_IN_ORDER "in_order"
VIRTIO_USER_ARG_IN_ORDER,
-#define VIRTIO_USER_ARG_PACKED_VQ "packed_vq"
+#define VIRTIO_USER_ARG_PACKED_VQ "packed_vq"
VIRTIO_USER_ARG_PACKED_VQ,
NULL
};
@@ -466,11 +466,11 @@ virtio_user_pmd_probe(struct rte_vdev_device *dev)
uint64_t server_mode = VIRTIO_USER_DEF_SERVER_MODE;
uint64_t mrg_rxbuf = 1;
uint64_t in_order = 1;
+ uint64_t packed_vq = 0;
char *path = NULL;
char *ifname = NULL;
char *mac_addr = NULL;
int ret = -1;
- uint64_t packed_vq = 0;
kvlist = rte_kvargs_parse(rte_vdev_device_args(dev), valid_args);
if (!kvlist) {
@@ -689,4 +689,5 @@ RTE_PMD_REGISTER_PARAM_STRING(net_virtio_user,
"iface= "
"server=<0|1> "
"mrg_rxbuf=<0|1> "
- "in_order=<0|1>");
+ "in_order=<0|1> "
+ "packed_vq=<0|1>");
--
2.17.1
[dpdk-dev] [PATCH 0/2] Some fixes for virtio-user/packed-ring
Tiwei Bie (2): net/virtio-user: fix packed vq option parsing net/virtio-user: fix supported features list drivers/net/virtio/virtio_user/virtio_user_dev.c | 14 +- drivers/net/virtio/virtio_user_ethdev.c | 7 --- 2 files changed, 9 insertions(+), 12 deletions(-) -- 2.17.1
Re: [dpdk-dev] [PATCH v4 0/3] add rte ring reset api and use it to flush a ring by hash
> -Original Message- > From: Honnappa Nagarahalli > Sent: Thursday, January 3, 2019 2:41 AM > To: Thomas Monjalon ; Gavin Hu (Arm Technology > China) > Cc: dev@dpdk.org; jer...@marvell.com; hemant.agra...@nxp.com; > bruce.richard...@intel.com; chao...@linux.vnet.ibm.com; nd > ; olivier.m...@6wind.com; nd > Subject: RE: [PATCH v4 0/3] add rte ring reset api and use it to flush a ring > by > hash > > > > > 02/01/2019 01:55, Gavin Hu: > > > V4: Include the ring perf test case enhancement patch in the series. > This change is not related to this patch. Should be a separate patch? I included it in this patch set to avoid patches scattering here and there, Anyway I updated the title of the cover letter to reflect this. > There were comments provided: > http://mails.dpdk.org/archives/dev/2018-December/121893.html > http://mails.dpdk.org/archives/dev/2018-December/122157.html > > Do you plan to address these? One was addressed in v4 and the other was address in new v5. Thanks! > > > > > > > V3: Allow experimental API for meson build > > > > > > V2: Fix the coding style issue(commit message line too long) > > > > > > V1: To flush a ring not in use, dequeue one by one is wasting cpu cycles. > > > The patch is to just resetting the head and tail indices to save cpu > > > cycle. > > > > It is too late for adding this API in 19.02, but we should review and give > > opinion, so it will be ready to integrate in early February. > >
Re: [dpdk-dev] [EXT] [PATCH v1] examples/l3fwd: enable hash multi lookup for ARM
On Wed, 2019-01-02 at 13:28 +0800, Ruifeng Wang wrote:
> ---
> ---
> Compile option for hash_multi_lookup was broken, and caused feature
> cannot be enabled on Arm.
> This patch sets hash_multi_lookup method as default, and sequential
> lookup becomes optional.
>
> In test of 8192 flows with 128-byte packets, throughput increased by
> 25.6% after enabling hash_multi_lookup.
# Are you changing l3fwd source code to test with 8K flows? meaning it
has only a few flows for hit case.
# Are you testing with ThunderX2?
# Can you check with single flow with 64B and one core? In my case,
I am getting >20% regression with octeontx.
Command used:
#./l3fwd -c 0x80 -n 4 -- -P -E -p 0x3 --config="(0, 0,
23),(1,0,23)"
In addition to that,
The file examples/l3fwd/l3fwd_em_hlm.h has following change, Not sure
why we need ARM64 specific change there?
#ifdef RTE_ARCH_ARM64
#define EM_HASH_LOOKUP_COUNT 16
#else
#define EM_HASH_LOOKUP_COUNT 8
#endif
> Fixes: 52c97adc1f0f ("examples/l3fwd: fix exact match performance")
> Cc: tomaszx.kula...@intel.com
>
> Signed-off-by: Ruifeng Wang
> Reviewed-by: Gavin Hu
> Reviewed-by: Phil Yang
> Tested-by: Ruifeng Wang
> ---
> examples/l3fwd/l3fwd.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
> index c962deac3..063b80018 100644
> --- a/examples/l3fwd/l3fwd.h
> +++ b/examples/l3fwd/l3fwd.h
> @@ -11,10 +11,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 */
>
Re: [dpdk-dev] Compiler for Windows
What about Gcc under the WSL thing (ie Linux emulation in Windows). Much better than Cygwin type stuff. -Original Message- From: Thomas Monjalon Sent: Wednesday, January 2, 2019 2:45 PM To: Jason Messer ; Harini Ramakrishnan ; Omar Cardona ; Ranjit Menon Cc: Mattias Rönnblom ; Jeff Shaw ; step...@networkplumber.org; dev@dpdk.org Subject: Compiler for Windows Hi, We need to gather inputs about the pros/cons of the C compilers available for Windows. Interesting criterias could be: - ease of use - availability - standards compliance - performance When the comparison will be complete, we should publish it in the doc/ directory, while porting DPDK to Windows. I start with few data: * gcc|clang on cygwin - not native * gcc/mingw * gcc/mingw-w64 * clang/mingw-w64 * clang --target=x86_64-windows-msvc * icc - not freely available * msvc - native - specific command line - not C99
Re: [dpdk-dev] [PATCH] examples/flow_filtering: fix example documentation
Hi Ferruh, PSB > -Original Message- > From: Ferruh Yigit > Sent: Wednesday, January 2, 2019 4:53 PM > To: Dekel Peled ; Ori Kam > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] examples/flow_filtering: fix example > documentation > > On 12/25/2018 6:30 AM, Dekel Peled wrote: > > PSB. > > > >> -Original Message- > >> From: Ori Kam > >> Sent: Tuesday, December 25, 2018 5:25 AM > >> To: Dekel Peled > >> Cc: dev@dpdk.org; Dekel Peled > >> Subject: RE: [dpdk-dev] [PATCH] examples/flow_filtering: fix example > >> documentation > >> > >> > >> > >>> -Original Message- > >>> From: dev On Behalf Of Dekel Peled > >>> Sent: Monday, December 24, 2018 12:51 PM > >>> To: Ori Kam > >>> Cc: dev@dpdk.org; Dekel Peled > >>> Subject: [dpdk-dev] [PATCH] examples/flow_filtering: fix example > >>> documentation > >>> > >>> Previous patch removed the VLAN item from example code. > >>> This patch fixes the documentation accordingly. > >> > >> So why are you modifying the c file? > >> > > > > The doc file quotes the c file, needed to modify both to align doc with > > code. > > Code change includes fix of comments, and removing redundant variables > and their initialization. > > What about removing the code from doc file, it is guaranteed that it will be > outdated again? Or perhaps just add pseudo code if required. I Agree with you, I think it will be better to change the doc to show only the key lines just as in the code while the rest of the lines as pseudo code. Do to time limitation, I will update the doc hopefully only for the 19.05 version. So please merge the current patch. Thanks, Ori
Re: [dpdk-dev] [PATCH v5 1/3] test/ring: ring perf test case enhancement
03/01/2019 03:38, gavin hu: > From: Joyce Kong > > Run ring perf test on all available cores to really verify MPMC operations. > The old way of running on a pair of cores is not enough for MPMC rings. > > Suggested-by: gavin hu > Signed-off-by: joyce kong > Reviewed-by: ruifeng wang > Reviewed-by: honnappa nagarahalli > Reviewed-by: dharmik thakkar > Reviewed-by: ola liljedahl > Reviewed-by: gavin hu Sorry Gavin, there is a misunderstanding. I was suggesting to not use uppercase in email addresses, but please keep uppercase in names in front of the addresses. Example: Real Name As for many guidelines, in doubt, you can check the git history. Thanks
