Re: [dpdk-dev] [PATCH v2 00/10] Introduce generic 'rawdevice' support
On Tuesday 30 January 2018 05:19 AM, Thomas Monjalon wrote: 25/01/2018 23:21, Thomas Monjalon: 23/01/2018 14:59, Shreyansh Jain: Defining a very generic super-set of device type and its device operations that can be exposed such that any new/upcoming/experimental device can be layered over it. 'rawdevice' semantic in this patchset represents a device that doesn't have any flavor/type associated with it which is advertised (like net, crypto etc). A *rte_rawdevice* is a raw/generic device without any standard configuration or input/output method assumption. Please HELP! Some reviews would be more than welcome :) No review at all of this new driver class? Shreyansh, please could you rebase on latest master and add the __rte_experimental tag as done in this commit: http://dpdk.org/commit/77b7b81e32e Thanks OK. I will do that - thanks for reference. I will send a v3 along with some documentation support as well.
Re: [dpdk-dev] [PATCH] app/testpmd: move variables definition in source
Hi, This is a kind reminder to review this short patch. There seems to be 1 build failure out of 15, but the error looks irrelevant to the patch according to: http://dpdk.org/dev/patchwork/patch/34403/ Please let me know if there is something I could fix. Best regards, Georgios On Wed, Jan 24, 2018 at 12:53 PM Georgios P. Katsikas wrote: > From: Georgios Katsikas > > This patch moves the definition of 3 variables in testpmd.h > into the respective .c file. The idea behind this move is > to allow external applications to compile against testpmd > without throwing compilation errors related to multiple > definition of variables. > > Also, an extern dcb_q_mapping in testpmd.h is removed > since it appears that this variable is not defined > elsewhere in the tree. > > Signed-off-by: Georgios Katsikas > --- > app/test-pmd/testpmd.c | 18 ++ > app/test-pmd/testpmd.h | 7 +++ > 2 files changed, 21 insertions(+), 4 deletions(-) > > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c > index 5dc8cca..02e8787 100644 > --- a/app/test-pmd/testpmd.c > +++ b/app/test-pmd/testpmd.c > @@ -91,6 +91,24 @@ uint8_t socket_num = UMA_NO_CONFIG; > uint8_t mp_anon = 0; > > /* > + * Store specified sockets on which memory pool to be used by ports > + * is allocated. > + */ > +uint8_t port_numa[RTE_MAX_ETHPORTS]; > + > +/* > + * Store specified sockets on which RX ring to be used by ports > + * is allocated. > + */ > +uint8_t rxring_numa[RTE_MAX_ETHPORTS]; > + > +/* > + * Store specified sockets on which TX ring to be used by ports > + * is allocated. > + */ > +uint8_t txring_numa[RTE_MAX_ETHPORTS]; > + > +/* > * Record the Ethernet address of peer target ports to which packets are > * forwarded. > * Must be instantiated with the ethernet addresses of peer traffic > generator > diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h > index 47f8fa8..153abea 100644 > --- a/app/test-pmd/testpmd.h > +++ b/app/test-pmd/testpmd.h > @@ -329,19 +329,19 @@ extern uint32_t bypass_timeout; /**< Store the NIC > bypass watchdog timeout */ > * Store specified sockets on which memory pool to be used by ports > * is allocated. > */ > -uint8_t port_numa[RTE_MAX_ETHPORTS]; > +extern uint8_t port_numa[RTE_MAX_ETHPORTS]; > > /* > * Store specified sockets on which RX ring to be used by ports > * is allocated. > */ > -uint8_t rxring_numa[RTE_MAX_ETHPORTS]; > +extern uint8_t rxring_numa[RTE_MAX_ETHPORTS]; > > /* > * Store specified sockets on which TX ring to be used by ports > * is allocated. > */ > -uint8_t txring_numa[RTE_MAX_ETHPORTS]; > +extern uint8_t txring_numa[RTE_MAX_ETHPORTS]; > > extern uint8_t socket_num; > > @@ -384,7 +384,6 @@ extern int16_t tx_rs_thresh; > > extern uint8_t dcb_config; > extern uint8_t dcb_test; > -extern enum dcb_queue_mapping_mode dcb_q_mapping; > > extern uint16_t mbuf_data_size; /**< Mbuf data space size. */ > extern uint32_t param_total_num_mbufs; > -- > 2.7.4 > >
Re: [dpdk-dev] [PATCH] app/eventdev: fix port dequeue depth configuration
-Original Message-
> Date: Wed, 24 Jan 2018 15:00:33 +0530
> From: Pavan Nikhilesh
> To: jerin.ja...@caviumnetworks.com, harry.van.haa...@intel.com
> Cc: dev@dpdk.org, Pavan Nikhilesh
> Subject: [dpdk-dev] [PATCH] app/eventdev: fix port dequeue depth
> configuration
> X-Mailer: git-send-email 2.14.1
>
> The port dequeue depth value has to be compared against the maximum
> allowed dequeue depth reported by the event drivers.
>
> Fixes: 3617aae53f92 ("app/eventdev: add event Rx adapter setup")
>
> Signed-off-by: Pavan Nikhilesh
> ---
> app/test-eventdev/test_perf_atq.c | 13 -
> app/test-eventdev/test_perf_common.c| 25 +
> app/test-eventdev/test_perf_common.h| 3 ++-
> app/test-eventdev/test_perf_queue.c | 12 +++-
> app/test-eventdev/test_pipeline_atq.c | 3 +++
> app/test-eventdev/test_pipeline_queue.c | 3 +++
> 6 files changed, 36 insertions(+), 23 deletions(-)
>
> diff --git a/app/test-eventdev/test_perf_atq.c
> b/app/test-eventdev/test_perf_atq.c
> index d07a05425..b36b22a77 100644
> --- a/app/test-eventdev/test_perf_atq.c
> +++ b/app/test-eventdev/test_perf_atq.c
> @@ -207,7 +207,18 @@ perf_atq_eventdev_setup(struct evt_test *test, struct
> evt_options *opt)
> }
> }
>
> - ret = perf_event_dev_port_setup(test, opt, 1 /* stride */, nb_queues);
> + if (opt->wkr_deq_dep > dev_info.max_event_port_dequeue_depth)
> + opt->wkr_deq_dep = dev_info.max_event_port_dequeue_depth;
> +
> + /* port configuration */
> + const struct rte_event_port_conf p_conf = {
> + .dequeue_depth = opt->wkr_deq_dep,
> + .enqueue_depth = dev_info.max_event_port_dequeue_depth,
> + .new_event_threshold = dev_info.max_num_events,
> + };
> +
> + ret = perf_event_dev_port_setup(test, opt, 1 /* stride */, nb_queues,
> + &p_conf);
> if (ret)
> return ret;
>
> diff --git a/app/test-eventdev/test_perf_common.c
> b/app/test-eventdev/test_perf_common.c
> index e279d81a5..59fa0a49e 100644
> --- a/app/test-eventdev/test_perf_common.c
> +++ b/app/test-eventdev/test_perf_common.c
> @@ -285,22 +285,12 @@ perf_event_rx_adapter_setup(struct evt_options *opt,
> uint8_t stride,
>
> int
> perf_event_dev_port_setup(struct evt_test *test, struct evt_options *opt,
> - uint8_t stride, uint8_t nb_queues)
> + uint8_t stride, uint8_t nb_queues,
> + const struct rte_event_port_conf *port_conf)
> {
> struct test_perf *t = evt_test_priv(test);
> uint16_t port, prod;
> int ret = -1;
> - struct rte_event_port_conf port_conf;
> -
> - memset(&port_conf, 0, sizeof(struct rte_event_port_conf));
> - rte_event_port_default_conf_get(opt->dev_id, 0, &port_conf);
> -
> - /* port configuration */
> - const struct rte_event_port_conf wkr_p_conf = {
> - .dequeue_depth = opt->wkr_deq_dep,
> - .enqueue_depth = port_conf.enqueue_depth,
> - .new_event_threshold = port_conf.new_event_threshold,
> - };
>
> /* setup one port per worker, linking to all queues */
> for (port = 0; port < evt_nr_active_lcores(opt->wlcores);
> @@ -313,7 +303,7 @@ perf_event_dev_port_setup(struct evt_test *test, struct
> evt_options *opt,
> w->processed_pkts = 0;
> w->latency = 0;
>
> - ret = rte_event_port_setup(opt->dev_id, port, &wkr_p_conf);
> + ret = rte_event_port_setup(opt->dev_id, port, port_conf);
> if (ret) {
> evt_err("failed to setup port %d", port);
> return ret;
> @@ -327,18 +317,13 @@ perf_event_dev_port_setup(struct evt_test *test, struct
> evt_options *opt,
> }
>
> /* port for producers, no links */
> - struct rte_event_port_conf prod_conf = {
> - .dequeue_depth = port_conf.dequeue_depth,
> - .enqueue_depth = port_conf.enqueue_depth,
> - .new_event_threshold = port_conf.new_event_threshold,
> - };
> if (opt->prod_type == EVT_PROD_TYPE_ETH_RX_ADPTR) {
> for ( ; port < perf_nb_event_ports(opt); port++) {
> struct prod_data *p = &t->prod[port];
> p->t = t;
> }
>
> - ret = perf_event_rx_adapter_setup(opt, stride, prod_conf);
> + ret = perf_event_rx_adapter_setup(opt, stride, *port_conf);
I think, it is better to pass port_conf as pointer.
With that change:
Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH 5/5] config: enable dpaaX drivers compilation for ARMv8
Hi Jerin, On 1/25/2018 4:51 PM, Jerin Jacob wrote: -Original Message- Date: Thu, 25 Jan 2018 15:23:31 +0530 From: Hemant Agrawal To: dev@dpdk.org CC: jerin.ja...@caviumnetworks.com Subject: [PATCH 5/5] config: enable dpaaX drivers compilation for ARMv8 X-Mailer: git-send-email 2.7.4 This patch enables the NXP DPAA & DPAA2 drivers for ARMV8 targets. They can be used with standard armv8 config with command line mempool argument or newly introduced platform mempool internal registration mechanism. Note that the dpaa(x) specific config files are still preserved to continue customer support. They also contain some of the ARM performance tuning flags. e.g the default ARM cache size of 128 is not optimal for NXP platforms. However, these configs will eventually be removed once a dynamic mechanisms are developed to detect the performance settings. Signed-off-by: Hemant Agrawal --- config/common_armv8a_linuxapp | 58 +++ 1 file changed, 58 insertions(+) diff --git a/config/common_armv8a_linuxapp b/config/common_armv8a_linuxapp index 790e716..572db11 100644 --- a/config/common_armv8a_linuxapp +++ b/config/common_armv8a_linuxapp @@ -34,3 +34,61 @@ CONFIG_RTE_LIBRTE_SFC_EFX_PMD=n CONFIG_RTE_LIBRTE_AVP_PMD=n CONFIG_RTE_SCHED_VECTOR=n + +# +# ARMv8 Specific driver compilation flags +# Will it be better if it is enabled in generic config? If you have any assembly code then you just stub it for non arm64. Since these are integrate controllers, I guess, there is no issue in stubbing the non arm64 specific things. I believe in that way, it will be maintainable. i.e there will not any case where arm64 config failing but not non arm64 configs. On the upside, The common code(ethdev, cryptodev) changes will be build against your driver by all the developers. It is a good suggestion and we did attempted it and realized that the amount of changes required are more than expected. We will attempt it for next release. However, if you are ok, please ack it in ARM for now.
[dpdk-dev] [PATCH v3] app/testpmd: do not enable Rx offloads by default
Removed the hardcoded preconfigured Rx offload configuration from
testpmd and changed the Rx offload command line parameters from
disable to enable.
Testers who wish to use these offloads will now have to explicitly
write them in the command-line when running testpmd.
Motivation:
Some PMDs such at the mlx4 may not implement all the offloads.
After the offload API rework assuming no offload is enabled by default,
commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API")
commit cba7f53b717d ("ethdev: introduce Tx queue offloads API") trying
to enable a not supported offload is clearly an error which will cause
configuration failing.
Considering that testpmd is an application to test the PMD, it should
not fail on a configuration which was not explicitly requested.
The behavior of this test application is then turned to an opt-in
model.
Signed-off-by: Moti Haimovsky
---
V3:
Updated documentation to reflect the change in the command-line parameters.
Updated testpmd help to also reflect the change in the command-line parameters.
V2:
Modified Rx offload command line parameters from disable to enable.
This way the user can choose the offload parameters to configure the
device with in a consistent manner.
---
app/test-pmd/parameters.c | 40 +++---
app/test-pmd/testpmd.c | 4 +--
doc/guides/contributing/documentation.rst | 2 +-
doc/guides/howto/lm_virtio_vhost_user.rst | 2 +-
doc/guides/howto/pvp_reference_benchmark.rst | 4 +--
.../howto/virtio_user_as_exceptional_path.rst | 4 +--
doc/guides/nics/mrvl.rst | 4 +--
doc/guides/nics/octeontx.rst | 4 +--
doc/guides/nics/thunderx.rst | 2 +-
doc/guides/nics/virtio.rst | 5 +--
doc/guides/testpmd_app_ug/run_app.rst | 20 +--
doc/guides/testpmd_app_ug/testpmd_funcs.rst| 18 +-
12 files changed, 54 insertions(+), 55 deletions(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index fd59071..a93e1f0 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -129,14 +129,14 @@
printf(" --latencystats=N: enable latency and jitter statistcs "
"monitoring on forwarding lcore id N.\n");
#endif
- printf(" --disable-crc-strip: disable CRC stripping by hardware.\n");
+ printf(" --enable-crc-strip: enable CRC stripping by hardware.\n");
printf(" --enable-lro: enable large receive offload.\n");
printf(" --enable-rx-cksum: enable rx hardware checksum offload.\n");
printf(" --enable-rx-timestamp: enable rx hardware timestamp
offload.\n");
- printf(" --disable-hw-vlan: disable hardware vlan.\n");
- printf(" --disable-hw-vlan-filter: disable hardware vlan filter.\n");
- printf(" --disable-hw-vlan-strip: disable hardware vlan strip.\n");
- printf(" --disable-hw-vlan-extend: disable hardware vlan extend.\n");
+ printf(" --enable-hw-vlan: enable hardware vlan.\n");
+ printf(" --enable-hw-vlan-filter: enable hardware vlan filter.\n");
+ printf(" --enable-hw-vlan-strip: enable hardware vlan strip.\n");
+ printf(" --enable-hw-vlan-extend: enable hardware vlan extend.\n");
printf(" --enable-drop-en: enable per queue packet drop.\n");
printf(" --disable-rss: disable rss.\n");
printf(" --port-topology=N: set port topology (N: paired (default) or "
@@ -580,15 +580,15 @@
#ifdef RTE_LIBRTE_BITRATE
{ "bitrate-stats", 1, 0, 0 },
#endif
- { "disable-crc-strip", 0, 0, 0 },
+ { "enable-crc-strip", 0, 0, 0 },
{ "enable-lro", 0, 0, 0 },
{ "enable-rx-cksum",0, 0, 0 },
{ "enable-rx-timestamp",0, 0, 0 },
{ "enable-scatter", 0, 0, 0 },
- { "disable-hw-vlan",0, 0, 0 },
- { "disable-hw-vlan-filter", 0, 0, 0 },
- { "disable-hw-vlan-strip", 0, 0, 0 },
- { "disable-hw-vlan-extend", 0, 0, 0 },
+ { "enable-hw-vlan", 0, 0, 0 },
+ { "enable-hw-vlan-filter", 0, 0, 0 },
+ { "enable-hw-vlan-strip", 0, 0, 0 },
+ { "enable-hw-vlan-extend", 0, 0, 0 },
{ "enable-drop-en",0, 0, 0 },
{ "disable-rss",0, 0, 0 },
{ "port-topology", 1, 0, 0 },
@@ -875,8 +875,8 @@
" must be >= 0\n", n);
}
#endif
- if (!strcmp(lgopts[opt_idx].name, "disable-crc-strip"))
- rx_offloads &= ~DEV_RX_OFFLOAD_CRC_STRIP;
+ if (!strcmp(lgopts[
[dpdk-dev] [PATCH] ring: fix compilation error with a broken else clause
From: Gowrishankar Muthukrishnan
Calling rte_smp_wmb macro expands into a compound block, which
would break compiling a else clause following it, if that calling
place has been terminated already with ";", as in below code.
This patch adds { } around this macro to allow compiling else too.
Fixes: git show c9fb3c6289 ("ring: move code in a new header file")
Signed-off-by: Gowrishankar Muthukrishnan
---
Error in compiling source:
In file included from /tmp/dpdk/lib/librte_ring/rte_ring.h:372:0,
from /tmp/dpdk/lib/librte_ring/rte_ring.c:90:
/tmp/dpdk/lib/librte_ring/rte_ring_generic.h: In function ‘update_tail’:
/tmp/dpdk/lib/librte_ring/rte_ring_generic.h:75:2: error: ‘else’ without a
previous ‘if’
else
^~~~
/tmp/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target 'rte_ring.o'
failed
lib/librte_ring/rte_ring_generic.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ring/rte_ring_generic.h
b/lib/librte_ring/rte_ring_generic.h
index 8c3e65b..a668489 100644
--- a/lib/librte_ring/rte_ring_generic.h
+++ b/lib/librte_ring/rte_ring_generic.h
@@ -70,8 +70,9 @@
update_tail(struct rte_ring_headtail *ht, uint32_t old_val, uint32_t new_val,
uint32_t single, uint32_t enqueue)
{
- if (enqueue)
+ if (enqueue) {
rte_smp_wmb();
+ }
else
rte_smp_rmb();
/*
--
1.9.1
Re: [dpdk-dev] [PATCH] net/tap: define __NR_bpf for powerpc
Acked-by: Pascal Mazon
On 30/01/2018 08:05, Gowrishankar wrote:
> From: Gowrishankar Muthukrishnan
>
> This patch defines __NR_bpf for powerpc architecture and hence,
> fixes compiling tap driver for this architecture.
>
> Fixes: b02d85e1 ("net/tap: add eBPF API")
>
> Signed-off-by: Gowrishankar Muthukrishnan
> ---
> drivers/net/tap/tap_bpf.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/tap/tap_bpf.h b/drivers/net/tap/tap_bpf.h
> index 8d6f9a2..06e9509 100644
> --- a/drivers/net/tap/tap_bpf.h
> +++ b/drivers/net/tap/tap_bpf.h
> @@ -97,6 +97,8 @@ enum bpf_map_type {
> # define __NR_bpf 349
> # elif defined(__s390__)
> # define __NR_bpf 351
> +# elif defined(__powerpc__)
> +# define __NR_bpf 361
> # else
> # error __NR_bpf not defined
> # endif
Re: [dpdk-dev] [PATCH] ring: fix compilation error with a broken else clause
-Original Message-
> Date: Tue, 30 Jan 2018 14:18:46 +0530
> From: Gowrishankar
> To: dev@dpdk.org
> CC: Olivier Matz , tho...@monjalon.net,
> Gowrishankar Muthukrishnan
> Subject: [dpdk-dev] [PATCH] ring: fix compilation error with a broken else
> clause
> X-Mailer: git-send-email 1.9.1
>
> From: Gowrishankar Muthukrishnan
>
> Calling rte_smp_wmb macro expands into a compound block, which
> would break compiling a else clause following it, if that calling
> place has been terminated already with ";", as in below code.
> This patch adds { } around this macro to allow compiling else too.
>
> Fixes: git show c9fb3c6289 ("ring: move code in a new header file")
>
> Signed-off-by: Gowrishankar Muthukrishnan
> ---
>
> Error in compiling source:
>
> In file included from /tmp/dpdk/lib/librte_ring/rte_ring.h:372:0,
> from /tmp/dpdk/lib/librte_ring/rte_ring.c:90:
> /tmp/dpdk/lib/librte_ring/rte_ring_generic.h: In function ‘update_tail’:
> /tmp/dpdk/lib/librte_ring/rte_ring_generic.h:75:2: error: ‘else’ without a
> previous ‘if’
> else
> ^~~~
> /tmp/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target 'rte_ring.o'
> failed
>
> lib/librte_ring/rte_ring_generic.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_ring/rte_ring_generic.h
> b/lib/librte_ring/rte_ring_generic.h
> index 8c3e65b..a668489 100644
> --- a/lib/librte_ring/rte_ring_generic.h
> +++ b/lib/librte_ring/rte_ring_generic.h
> @@ -70,8 +70,9 @@
> update_tail(struct rte_ring_headtail *ht, uint32_t old_val, uint32_t new_val,
> uint32_t single, uint32_t enqueue)
> {
> - if (enqueue)
> + if (enqueue) {
Just wondering, Is it because of rte_smp_wmb() implementation of ppc64 is
not just correct?
We had a similar fix for arm64.
http://dpdk.org/browse/dpdk/commit/?id=59a3cae5305816b3739b4197d277f9455af53b9f
> rte_smp_wmb();
> + }
> else
> rte_smp_rmb();
> /*
> --
> 1.9.1
>
[dpdk-dev] [PATCH] eal/ppc64: revert implement arch-specific TSC freq query
From: Gowrishankar Muthukrishnan
This reverts commit 15692396fd68932b6a81f00f12d4b0da12baa7d3
(eal/ppc64: implement arch-specific TSC freq query). We intended
to derive pkt/sec estimation with cpu clock frequency. As timebase
register serves the timer purpose, we need to stick with it for
calculating pkt/sec, hence reverting the change.
Fixes: 15692396fd (eal/ppc64: implement arch-specific TSC freq query)
Signed-off-by: Gowrishankar Muthukrishnan
---
lib/librte_eal/common/arch/ppc_64/rte_cycles.c | 47 +-
1 file changed, 1 insertion(+), 46 deletions(-)
diff --git a/lib/librte_eal/common/arch/ppc_64/rte_cycles.c
b/lib/librte_eal/common/arch/ppc_64/rte_cycles.c
index 69a9f74..851fd02 100644
--- a/lib/librte_eal/common/arch/ppc_64/rte_cycles.c
+++ b/lib/librte_eal/common/arch/ppc_64/rte_cycles.c
@@ -1,52 +1,7 @@
-/*
- * BSD LICENSE
- *
- * Copyright (C) IBM Corporation 2014.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- * * Neither the name of IBM Corporation nor the names of its
- * contributors may be used to endorse or promote products derived
- * from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#include
-#include
-#include "eal_filesystem.h"
#include "eal_private.h"
-static const char sys_cpu_dir[] = "/sys/devices/system/cpu";
-
uint64_t
get_tsc_freq_arch(void)
{
- unsigned long cpu_hz;
- char path[PATH_MAX];
-
- snprintf(path, sizeof(path), "%s/cpu%d/cpufreq/cpuinfo_cur_freq",
- sys_cpu_dir, rte_get_master_lcore());
- if (eal_parse_sysfs_value(path, &cpu_hz) < 0)
- RTE_LOG(WARNING, EAL, "Unable to parse %s\n", path);
-
- return cpu_hz*1000;
+ return 0;
}
--
1.9.1
[dpdk-dev] [PATCH v4] app/testpmd: do not enable Rx offloads by default
Removed the hardcoded preconfigured Rx offload configuration from
testpmd and changed the Rx offload command line parameters from
disable to enable.
Testers who wish to use these offloads will now have to explicitly
write them in the command-line when running testpmd.
Motivation:
Some PMDs such at the mlx4 may not implement all the offloads.
After the offload API rework assuming no offload is enabled by default,
commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API")
commit cba7f53b717d ("ethdev: introduce Tx queue offloads API") trying
to enable a not supported offload is clearly an error which will cause
configuration failing.
Considering that testpmd is an application to test the PMD, it should
not fail on a configuration which was not explicitly requested.
The behavior of this test application is then turned to an opt-in
model.
Signed-off-by: Moti Haimovsky
---
V4:
Fixed checkpatches warnings.
V3:
Updated documentation to reflect the change in the command-line parameters.
Updated testpmd help to also reflect the change in the command-line parameters.
V2:
Modified Rx offload command line parameters from disable to enable.
This way the user can choose the offload parameters to configure the
device with in a consistent manner.
---
app/test-pmd/parameters.c | 40 +++---
app/test-pmd/testpmd.c | 4 +--
doc/guides/contributing/documentation.rst | 2 +-
doc/guides/howto/lm_virtio_vhost_user.rst | 2 +-
doc/guides/howto/pvp_reference_benchmark.rst | 4 +--
.../howto/virtio_user_as_exceptional_path.rst | 4 +--
doc/guides/nics/mrvl.rst | 4 +--
doc/guides/nics/octeontx.rst | 4 +--
doc/guides/nics/thunderx.rst | 2 +-
doc/guides/nics/virtio.rst | 5 +--
doc/guides/testpmd_app_ug/run_app.rst | 20 +--
doc/guides/testpmd_app_ug/testpmd_funcs.rst| 18 +-
12 files changed, 54 insertions(+), 55 deletions(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index fd59071..a93e1f0 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -129,14 +129,14 @@
printf(" --latencystats=N: enable latency and jitter statistcs "
"monitoring on forwarding lcore id N.\n");
#endif
- printf(" --disable-crc-strip: disable CRC stripping by hardware.\n");
+ printf(" --enable-crc-strip: enable CRC stripping by hardware.\n");
printf(" --enable-lro: enable large receive offload.\n");
printf(" --enable-rx-cksum: enable rx hardware checksum offload.\n");
printf(" --enable-rx-timestamp: enable rx hardware timestamp
offload.\n");
- printf(" --disable-hw-vlan: disable hardware vlan.\n");
- printf(" --disable-hw-vlan-filter: disable hardware vlan filter.\n");
- printf(" --disable-hw-vlan-strip: disable hardware vlan strip.\n");
- printf(" --disable-hw-vlan-extend: disable hardware vlan extend.\n");
+ printf(" --enable-hw-vlan: enable hardware vlan.\n");
+ printf(" --enable-hw-vlan-filter: enable hardware vlan filter.\n");
+ printf(" --enable-hw-vlan-strip: enable hardware vlan strip.\n");
+ printf(" --enable-hw-vlan-extend: enable hardware vlan extend.\n");
printf(" --enable-drop-en: enable per queue packet drop.\n");
printf(" --disable-rss: disable rss.\n");
printf(" --port-topology=N: set port topology (N: paired (default) or "
@@ -580,15 +580,15 @@
#ifdef RTE_LIBRTE_BITRATE
{ "bitrate-stats", 1, 0, 0 },
#endif
- { "disable-crc-strip", 0, 0, 0 },
+ { "enable-crc-strip", 0, 0, 0 },
{ "enable-lro", 0, 0, 0 },
{ "enable-rx-cksum",0, 0, 0 },
{ "enable-rx-timestamp",0, 0, 0 },
{ "enable-scatter", 0, 0, 0 },
- { "disable-hw-vlan",0, 0, 0 },
- { "disable-hw-vlan-filter", 0, 0, 0 },
- { "disable-hw-vlan-strip", 0, 0, 0 },
- { "disable-hw-vlan-extend", 0, 0, 0 },
+ { "enable-hw-vlan", 0, 0, 0 },
+ { "enable-hw-vlan-filter", 0, 0, 0 },
+ { "enable-hw-vlan-strip", 0, 0, 0 },
+ { "enable-hw-vlan-extend", 0, 0, 0 },
{ "enable-drop-en",0, 0, 0 },
{ "disable-rss",0, 0, 0 },
{ "port-topology", 1, 0, 0 },
@@ -875,8 +875,8 @@
" must be >= 0\n", n);
}
#endif
- if (!strcmp(lgopts[opt_idx].name, "disable-crc-strip"))
- rx_offloads &= ~DEV_RX_OFFLOAD_CRC_STRIP;
+
Re: [dpdk-dev] [PATCH] ring: fix compilation error with a broken else clause
On Tuesday 30 January 2018 02:26 PM, Jerin Jacob wrote:
-Original Message-
Date: Tue, 30 Jan 2018 14:18:46 +0530
From: Gowrishankar
To: dev@dpdk.org
CC: Olivier Matz , tho...@monjalon.net,
Gowrishankar Muthukrishnan
Subject: [dpdk-dev] [PATCH] ring: fix compilation error with a broken else
clause
X-Mailer: git-send-email 1.9.1
From: Gowrishankar Muthukrishnan
Calling rte_smp_wmb macro expands into a compound block, which
would break compiling a else clause following it, if that calling
place has been terminated already with ";", as in below code.
This patch adds { } around this macro to allow compiling else too.
Fixes: git show c9fb3c6289 ("ring: move code in a new header file")
Signed-off-by: Gowrishankar Muthukrishnan
---
Error in compiling source:
In file included from /tmp/dpdk/lib/librte_ring/rte_ring.h:372:0,
from /tmp/dpdk/lib/librte_ring/rte_ring.c:90:
/tmp/dpdk/lib/librte_ring/rte_ring_generic.h: In function ‘update_tail’:
/tmp/dpdk/lib/librte_ring/rte_ring_generic.h:75:2: error: ‘else’ without a
previous ‘if’
else
^~~~
/tmp/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target 'rte_ring.o'
failed
lib/librte_ring/rte_ring_generic.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ring/rte_ring_generic.h
b/lib/librte_ring/rte_ring_generic.h
index 8c3e65b..a668489 100644
--- a/lib/librte_ring/rte_ring_generic.h
+++ b/lib/librte_ring/rte_ring_generic.h
@@ -70,8 +70,9 @@
update_tail(struct rte_ring_headtail *ht, uint32_t old_val, uint32_t new_val,
uint32_t single, uint32_t enqueue)
{
- if (enqueue)
+ if (enqueue) {
Just wondering, Is it because of rte_smp_wmb() implementation of ppc64 is
not just correct?
We had a similar fix for arm64.
http://dpdk.org/browse/dpdk/commit/?id=59a3cae5305816b3739b4197d277f9455af53b9f
Thanks Jerin. Yes. Similar fix also works. I did not want to touch
include/ at this time, as it is called at various places in source.
As same problem is seen in arm64, I think it is ok to go with your
change. If so, I can send version 2 patch with similar change as you showed.
Thanks,
Gowrishankar
rte_smp_wmb();
+ }
else
rte_smp_rmb();
/*
--
1.9.1
Re: [dpdk-dev] [PATCH] ring: fix compilation error with a broken else clause
30/01/2018 10:09, gowrishankar muthukrishnan:
> On Tuesday 30 January 2018 02:26 PM, Jerin Jacob wrote:
> > -Original Message-
> >> Date: Tue, 30 Jan 2018 14:18:46 +0530
> >> From: Gowrishankar
> >> To: dev@dpdk.org
> >> CC: Olivier Matz , tho...@monjalon.net,
> >> Gowrishankar Muthukrishnan
> >> Subject: [dpdk-dev] [PATCH] ring: fix compilation error with a broken else
> >> clause
> >> X-Mailer: git-send-email 1.9.1
> >>
> >> From: Gowrishankar Muthukrishnan
> >>
> >> Calling rte_smp_wmb macro expands into a compound block, which
> >> would break compiling a else clause following it, if that calling
> >> place has been terminated already with ";", as in below code.
> >> This patch adds { } around this macro to allow compiling else too.
> >>
> >> Fixes: git show c9fb3c6289 ("ring: move code in a new header file")
> >>
> >> Signed-off-by: Gowrishankar Muthukrishnan
> >>
> >> ---
> >>
> >> Error in compiling source:
> >>
> >> In file included from /tmp/dpdk/lib/librte_ring/rte_ring.h:372:0,
> >> from /tmp/dpdk/lib/librte_ring/rte_ring.c:90:
> >> /tmp/dpdk/lib/librte_ring/rte_ring_generic.h: In function ‘update_tail’:
> >> /tmp/dpdk/lib/librte_ring/rte_ring_generic.h:75:2: error: ‘else’ without a
> >> previous ‘if’
> >>else
> >>^~~~
> >> /tmp/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target
> >> 'rte_ring.o' failed
> >>
> >> lib/librte_ring/rte_ring_generic.h | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/lib/librte_ring/rte_ring_generic.h
> >> b/lib/librte_ring/rte_ring_generic.h
> >> index 8c3e65b..a668489 100644
> >> --- a/lib/librte_ring/rte_ring_generic.h
> >> +++ b/lib/librte_ring/rte_ring_generic.h
> >> @@ -70,8 +70,9 @@
> >> update_tail(struct rte_ring_headtail *ht, uint32_t old_val, uint32_t
> >> new_val,
> >>uint32_t single, uint32_t enqueue)
> >> {
> >> - if (enqueue)
> >> + if (enqueue) {
> > Just wondering, Is it because of rte_smp_wmb() implementation of ppc64 is
> > not just correct?
> >
> > We had a similar fix for arm64.
> > http://dpdk.org/browse/dpdk/commit/?id=59a3cae5305816b3739b4197d277f9455af53b9f
> Thanks Jerin. Yes. Similar fix also works. I did not want to touch
> include/ at this time, as it is called at various places in source.
> As same problem is seen in arm64, I think it is ok to go with your
> change. If so, I can send version 2 patch with similar change as you showed.
Please send a patch for the fix in atomics.
[dpdk-dev] [PATCH] net/avf: fix unchecked return value issue
This patch fixes the coverity CHECKED_RETURN issue.
Coverity issue: 257045
Fixes: 48de41ca11f0 ("net/avf: enable link status update")
Reported-by: John McNamara
Signed-off-by: Jingjing Wu
---
drivers/net/avf/avf_ethdev.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/avf/avf_ethdev.c b/drivers/net/avf/avf_ethdev.c
index cf7bbb2..3009f5d 100644
--- a/drivers/net/avf/avf_ethdev.c
+++ b/drivers/net/avf/avf_ethdev.c
@@ -609,9 +609,10 @@ avf_dev_link_update(struct rte_eth_dev *dev,
new_link.link_autoneg = !!(dev->data->dev_conf.link_speeds &
ETH_LINK_SPEED_FIXED);
- rte_atomic64_cmpset((uint64_t *)&dev->data->dev_link,
- *(uint64_t *)&dev->data->dev_link,
- *(uint64_t *)&new_link);
+ if (rte_atomic64_cmpset((uint64_t *)&dev->data->dev_link,
+ *(uint64_t *)&dev->data->dev_link,
+ *(uint64_t *)&new_link) == 0)
+ return -1;
return 0;
}
--
2.4.11
Re: [dpdk-dev] [PATCH 11/17] net/mlx5: use SPDX tags on 6WIND copyrighted files
On Mon, Jan 29, 2018 at 02:11:30PM +0100, Olivier Matz wrote: > Cc: Adrien Mazarguil > Cc: Nelio Laranjeiro > Cc: Yongseok Koh > > Signed-off-by: Olivier Matz Acked-by: Nelio Laranjeiro -- Nélio Laranjeiro 6WIND
[dpdk-dev] Some flow rules not supported by igb_uio
Hi, I am testing rte flow API across different DPDK-based NICs using some rules. I noticed that flow rules that match L2 information, such as rule: flow create 0 ingress pattern eth type is 0x800 / end actions queue index 6 / end does not work on an Intel 82599ES (igb_uio driver), while a Mellanox ConnectX-4 (mlx5_core driver) accepts this rule. Is there any reason behind this or could be a bug? I am testing using DPDK v17.11. Thanks, Georgios -- Georgios Katsikas Industrial Ph.D. Student Network Intelligence Group Decision, Networks, and Analytics (DNA) Lab RISE SICS E-Mail: georgios.katsi...@ri.se
Re: [dpdk-dev] [dpdk-stable] [PATCH v3] net/mlx4: fix dev rmv not detected after port stop
29/01/2018 11:54, Shahaf Shuler:
> Mordechay Haimovsky, Monday, January 29, 2018 10:35 AM:
> > In failsafe device start can be called for ports/devices that had been
> > plugged
> > out.
> > The mlx4 PMD detects device removal by listening to the device RMV events,
> > when the mlx4 port is being stopped, the PMD no longer listens to these
> > events causing the PMD to stop detecting device removals.
> > This patch fixes this issue by moving installation of the interrupt handler
> > to
> > device configuration, and toggle only the Rx-queue interrupts on start/stop.
> >
> > Fixes: a6e8b01c3c26 ("net/mlx4: compact interrupt functions")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Moti Haimovsky
>
> Acked-by: Shahaf Shuler
>
> Adrien - let me know if you see issues with this patch, I want to include it
> on RC2.
Applied, thanks
Re: [dpdk-dev] [PATCH v2] doc: update flow filting document
Hi Wei,
You have a typo in the patch subject and comment,
It should be filtering
Ori
> -Original Message-
> From: Wei Zhao [mailto:wei.zh...@intel.com]
> Sent: Tuesday, January 30, 2018 9:45 AM
> To: dev@dpdk.org
> Cc: Ori Kam ; sta...@dpdk.org;
> john.mcnam...@intel.com; Wei Zhao
> Subject: [PATCH v2] doc: update flow filting document
>
> This patch will update example application of flow_filting document.
> It add Tx queues configuration related comment.
>
> Signed-off-by: Wei Zhao
>
> ---
>
> v2:
> -change code indentation style.
> ---
> doc/guides/sample_app_ug/flow_filtering.rst | 108 ++-
> -
> 1 file changed, 72 insertions(+), 36 deletions(-)
>
> diff --git a/doc/guides/sample_app_ug/flow_filtering.rst
> b/doc/guides/sample_app_ug/flow_filtering.rst
> index 725dcb4..b4a1dd7 100644
> --- a/doc/guides/sample_app_ug/flow_filtering.rst
> +++ b/doc/guides/sample_app_ug/flow_filtering.rst
> @@ -167,44 +167,65 @@ application is shown below:
> struct rte_eth_conf port_conf = {
> .rxmode = {
> .split_hdr_size = 0,
> - /**< Header Split disabled */
> - .header_split = 0,
> - /**< IP checksum offload disabled */
> - .hw_ip_checksum = 0,
> - /**< VLAN filtering disabled */
> - .hw_vlan_filter = 0,
> - /**< Jumbo Frame Support disabled */
> - .jumbo_frame= 0,
> - /**< CRC stripped by hardware */
> - .hw_strip_crc = 1,
> + .ignore_offload_bitfield = 1,
> + .offloads = DEV_RX_OFFLOAD_CRC_STRIP,
> + },
> + .txmode = {
> + .offloads =
> + DEV_TX_OFFLOAD_VLAN_INSERT |
> + DEV_TX_OFFLOAD_IPV4_CKSUM |
> + DEV_TX_OFFLOAD_UDP_CKSUM |
> + DEV_TX_OFFLOAD_TCP_CKSUM |
> + DEV_TX_OFFLOAD_SCTP_CKSUM |
> + DEV_TX_OFFLOAD_TCP_TSO,
> },
> };
> + struct rte_eth_txconf txq_conf;
> + struct rte_eth_rxconf rxq_conf;
> + struct rte_eth_dev_info dev_info;
>
> printf(":: initializing port: %d\n", port_id);
> ret = rte_eth_dev_configure(port_id,
> - nr_queues, nr_queues, &port_conf);
> + nr_queues, nr_queues, &port_conf);
> if (ret < 0) {
> rte_exit(EXIT_FAILURE,
> ":: cannot configure device: err=%d, port=%u\n",
> ret, port_id);
> }
>
> + rte_eth_dev_info_get(port_id, &dev_info);
> + rxq_conf = dev_info.default_rxconf;
> + rxq_conf.offloads = port_conf.rxmode.offloads;
> /* only set Rx queues: something we care only so far */
> for (i = 0; i < nr_queues; i++) {
> ret = rte_eth_rx_queue_setup(port_id, i, 512,
> -rte_eth_dev_socket_id(port_id),
> -NULL,
> -mbuf_pool);
> + rte_eth_dev_socket_id(port_id),
> + &rxq_conf,
> + mbuf_pool);
> if (ret < 0) {
> - rte_exit(EXIT_FAILURE,
> - ":: Rx queue setup failed: err=%d, port=%u\n",
> - ret, port_id);
> +rte_exit(EXIT_FAILURE,
> +":: Rx queue setup failed: err=%d,
> +port=%u\n",
> +ret, port_id);
> }
> }
>
> + txq_conf = dev_info.default_txconf;
> + txq_conf.offloads = port_conf.txmode.offloads;
>
> - rte_eth_promiscuous_enable(port_id);
> + for (i = 0; i < nr_queues; i++) {
> + ret = rte_eth_tx_queue_setup(port_id, i, 512,
> + rte_eth_dev_socket_id(port_id),
> + &txq_conf);
> + if (ret < 0) {
> + rte_exit(EXIT_FAILURE,
> + ":: Tx queue setup failed: err=%d,
> + port=%u\n",
> + ret, port_id);
> + }
> + }
>
> + rte_eth_promiscuous_enable(port_id);
> ret = rte_eth_dev_start(port_id);
> if (ret < 0) {
> r
Re: [dpdk-dev] [PATCH v5 1/5] lib: add Port Representor library
On 01/10/2018 06:54 PM, Remy Horton wrote:
Port Representors provide a logical presentation in DPDK of VF (virtual
function) ports for the purposes of control and monitoring. Each port
representor device represents a single VF and is associated with it's
parent physical function (PF) PMD which provides the back-end hooks for
the representor device ops and defines the control domain to which that
port belongs. This allows to use existing DPDK APIs to monitor and control
the port without the need to create and maintain VF specific APIs.
The library provides the broker infrastructure to be instantiated by
base driver and corresponding methods to manage the broker
infrastructure. The broker keeps records of list of representor PMDs.
The library also provides methods to manage the representor PMDs by the
broker.
Signed-off-by: Declan Doherty
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Remy Horton
---
MAINTAINERS| 9 +-
config/common_base | 5 +
doc/api/doxy-api-index.md | 1 +
doc/api/doxy-api.conf | 1 +
doc/guides/prog_guide/index.rst| 1 +
doc/guides/prog_guide/representor_lib.rst | 62
doc/guides/rel_notes/release_18_02.rst | 10 +
lib/Makefile | 3 +
lib/librte_eal/common/eal_common_log.c | 1 +
lib/librte_eal/common/include/rte_log.h| 1 +
lib/librte_representor/Makefile| 26 ++
lib/librte_representor/rte_port_representor.c | 345 +
lib/librte_representor/rte_port_representor.h | 60
.../rte_port_representor_driver.h | 140 +
.../rte_port_representor_version.map | 8 +
mk/rte.app.mk | 1 +
16 files changed, 673 insertions(+), 1 deletion(-)
create mode 100644 doc/guides/prog_guide/representor_lib.rst
create mode 100644 lib/librte_representor/Makefile
create mode 100644 lib/librte_representor/rte_port_representor.c
create mode 100644 lib/librte_representor/rte_port_representor.h
create mode 100644 lib/librte_representor/rte_port_representor_driver.h
create mode 100644 lib/librte_representor/rte_port_representor_version.map
It look like it deserves an entry in the doc/guides/nics/features.
Also right now it is bound to rte_eth_dev inside, but does not bound to
ethdev outside (API, naming). May be it is really good since it could be
useful to other cases of VFs (not networking).
Ideally it should use dynamic logging from the very beginning.
Also there is a work to standardize device identification in current
release cycle. I think it would be good if the first argument of
rte_representor_register/unregister() follow it (right now it is
something like pci_:01:00.1). May be it is not a problem to
change it in the next release cycle if the API is EXPERIMENTAL.
Wouldn't it be easier for user if register/unregister gets VFs
device string on input (not PF string plus VF number).
It is just a question and I'd like to know your thoughts on it.
<...>
diff --git a/lib/librte_representor/rte_port_representor_version.map
b/lib/librte_representor/rte_port_representor_version.map
new file mode 100644
index 000..b26600c
--- /dev/null
+++ b/lib/librte_representor/rte_port_representor_version.map
@@ -0,0 +1,8 @@
+DPDK_18.02 {
+ global:
+
+ rte_representor_port_register;
+ rte_representor_port_unregister;
+
+ local: *;
+};
As I understand it should be EXPERIMENTAL (with __rte_experimental and
EXPERIMENTAL marks in the doxygen documentation as well).
<...>
Acked-by: Andrew Rybchenko
[dpdk-dev] [PATCH] crypto/dpaa2_sec: fix build with GCC 6 or prior
This patch fixes the compilation with compiler GCC < 7
dpaa2_sec/hw/rta/operation_cmd.h:12:32: error: unknown option after
‘#pragma GCC diagnostic’ kind [-Werror=pragmas]
#pragma GCC diagnostic ignored "-Wimplicit-fallthrough"
Fixes: 2ab9a9483196 ("crypto/dpaa2_sec: fix build with GCC 7")
Signed-off-by: Hemant Agrawal
---
drivers/crypto/dpaa2_sec/hw/rta/operation_cmd.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/dpaa2_sec/hw/rta/operation_cmd.h
b/drivers/crypto/dpaa2_sec/hw/rta/operation_cmd.h
index c4febcb..90ce39f 100644
--- a/drivers/crypto/dpaa2_sec/hw/rta/operation_cmd.h
+++ b/drivers/crypto/dpaa2_sec/hw/rta/operation_cmd.h
@@ -8,7 +8,9 @@
#ifndef __RTA_OPERATION_CMD_H__
#define __RTA_OPERATION_CMD_H__
+#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION > 7)
#pragma GCC diagnostic ignored "-Wimplicit-fallthrough"
+#endif
extern enum rta_sec_era rta_sec_era;
--
2.7.4
Re: [dpdk-dev] [PATCH 5/5] config: enable dpaaX drivers compilation for ARMv8
On 1/30/2018 2:12 PM, Hemant Agrawal wrote: Hi Jerin, On 1/25/2018 4:51 PM, Jerin Jacob wrote: -Original Message- Date: Thu, 25 Jan 2018 15:23:31 +0530 From: Hemant Agrawal To: dev@dpdk.org CC: jerin.ja...@caviumnetworks.com Subject: [PATCH 5/5] config: enable dpaaX drivers compilation for ARMv8 X-Mailer: git-send-email 2.7.4 This patch enables the NXP DPAA & DPAA2 drivers for ARMV8 targets. They can be used with standard armv8 config with command line mempool argument or newly introduced platform mempool internal registration mechanism. Note that the dpaa(x) specific config files are still preserved to continue customer support. They also contain some of the ARM performance tuning flags. e.g the default ARM cache size of 128 is not optimal for NXP platforms. However, these configs will eventually be removed once a dynamic mechanisms are developed to detect the performance settings. Signed-off-by: Hemant Agrawal --- config/common_armv8a_linuxapp | 58 +++ 1 file changed, 58 insertions(+) diff --git a/config/common_armv8a_linuxapp b/config/common_armv8a_linuxapp index 790e716..572db11 100644 --- a/config/common_armv8a_linuxapp +++ b/config/common_armv8a_linuxapp @@ -34,3 +34,61 @@ CONFIG_RTE_LIBRTE_SFC_EFX_PMD=n CONFIG_RTE_LIBRTE_AVP_PMD=n CONFIG_RTE_SCHED_VECTOR=n + +# +# ARMv8 Specific driver compilation flags +# Will it be better if it is enabled in generic config? If you have any assembly code then you just stub it for non arm64. Since these are integrate controllers, I guess, there is no issue in stubbing the non arm64 specific things. I believe in that way, it will be maintainable. i.e there will not any case where arm64 config failing but not non arm64 configs. On the upside, The common code(ethdev, cryptodev) changes will be build against your driver by all the developers. It is a good suggestion and we did attempted it and realized that the amount of changes required are more than expected. We will attempt it for next release. However, if you are ok, please ack it in ARM for now. I take it back. I figured out easy changes to make it compile for x86 as well. We will submit the v2.
Re: [dpdk-dev] [PATCH v3] net/mlx4: fix dev rmv not detected after port stop
Hi,
On Mon, Jan 29, 2018 at 10:54:16AM +, Shahaf Shuler wrote:
> Mordechay Haimovsky, Monday, January 29, 2018 10:35 AM:
> > In failsafe device start can be called for ports/devices that had been
> > plugged
> > out.
> > The mlx4 PMD detects device removal by listening to the device RMV events,
> > when the mlx4 port is being stopped, the PMD no longer listens to these
> > events causing the PMD to stop detecting device removals.
> > This patch fixes this issue by moving installation of the interrupt handler
> > to
> > device configuration, and toggle only the Rx-queue interrupts on start/stop.
> >
> > Fixes: a6e8b01c3c26 ("net/mlx4: compact interrupt functions")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Moti Haimovsky
> > ---
> > V3:
> > Modifications according to review inputs from Shahaf Shuler
> > See: 1516357009-15463-1-git-send-email-mo...@mellanox.com
> >
> > V2:
> > Fixed commit message.
> > ---
> >
> > drivers/net/mlx4/mlx4.c | 10 --
> > drivers/net/mlx4/mlx4.h | 2 ++
> > drivers/net/mlx4/mlx4_intr.c | 41
> > ++---
> > 3 files changed, 48 insertions(+), 5 deletions(-)
> >
>
> Acked-by: Shahaf Shuler
>
> Adrien - let me know if you see issues with this patch, I want to include it
> on RC2.
Unfortunately I didn't get a chance to review this patch before it was
applied. I'm not sure a stopped port is supposed to report events
(interrupts). Will applications expect them to occur at this point?
In my opinion it's not a fix, as in, it doesn't address an issue introduced
by the mentioned patch whose behavior was correct.
It's probably too late to change it now and it does address an issue seen
with a use case involving this PMD, however I think the fail-safe PMD could
as well poll using the recently-added rte_eth_dev_is_removed() when it's
aware the underlying port is stopped instead of expecting interrupts.
--
Adrien Mazarguil
6WIND
Re: [dpdk-dev] [PATCH] app/testpmd: add missing args to TM show cap cmd
> -Original Message-
> From: Tomasz Duszynski [mailto:t...@semihalf.com]
> Sent: Sunday, January 28, 2018 3:08 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; Wu, Jingjing
> ; Mcnamara, John ;
> Kovacevic, Marko ; Tomasz Duszynski
> ; Singh, Jasvinder
> Subject: [PATCH] app/testpmd: add missing args to TM show cap cmd
>
> Command used for querying node or level capabilities requires argument
> which specifies which set of capabilities to show.
>
> Thus trying to show node/level capabilities using current documentation will
> not work. Fix that by adding missing arguments to command documentation.
>
> Fixes: 5b590fbe09b6 ("app/testpmd: add traffic management forwarding
> mode")
> Cc: jasvinder.si...@intel.com
>
> Signed-off-by: Tomasz Duszynski
Acked-by: Jasvinder Singh
[dpdk-dev] [PATCH] igb_uio: fix uevent montior issue
udev could not detect remove and add event of device when hotplug in
and out devices, that related with the fix about using pointer of
rte_uio_pci_dev as dev_id instead of uio_device for irq device handler,
that would result igb uio irq failure to deliver the uevent to udev when
kernel version after than 3.17. so this patch correct it by use kernel
version check before handle the pci interrupt.
Signed-off-by: Jeff Guo
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 9f0fb5e..14ce2ea 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -192,9 +192,14 @@ igbuio_pci_irqcontrol(struct uio_info *info, s32 irq_state)
static irqreturn_t
igbuio_pci_irqhandler(int irq, void *dev_id)
{
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
struct rte_uio_pci_dev *udev = (struct rte_uio_pci_dev *)dev_id;
struct uio_info *info = &udev->info;
-
+#else
+ struct uio_device *idev = (struct uio_device *)dev_id;
+ struct uio_info *info = idev->info;
+ struct rte_uio_pci_dev *udev = info->priv;
+#endif
/* Legacy mode need to mask in hardware */
if (udev->mode == RTE_INTR_MODE_LEGACY &&
!pci_check_and_mask_intx(udev->pdev))
@@ -279,9 +284,15 @@ igbuio_pci_enable_interrupts(struct rte_uio_pci_dev *udev)
}
if (udev->info.irq != UIO_IRQ_NONE)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
err = request_irq(udev->info.irq, igbuio_pci_irqhandler,
udev->info.irq_flags, udev->info.name,
udev);
+#else
+ err = request_irq(udev->info.irq, igbuio_pci_irqhandler,
+ udev->info.irq_flags, udev->info.name,
+ udev->info.uio_dev);
+#endif
dev_info(&udev->pdev->dev, "uio device registered with irq %lx\n",
udev->info.irq);
@@ -292,7 +303,11 @@ static void
igbuio_pci_disable_interrupts(struct rte_uio_pci_dev *udev)
{
if (udev->info.irq) {
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
free_irq(udev->info.irq, udev);
+#else
+ free_irq(udev->info.irq, udev->info.uio_dev);
+#endif
udev->info.irq = 0;
}
--
2.7.4
Re: [dpdk-dev] [PATCH] app/testpmd: add meter to the actions table
On Sun, Jan 28, 2018 at 12:58:39PM +0100, Tomasz Duszynski wrote:
> Since METER action is supported by the testpmd application
> suitable entry should exist in flow actions information table.
>
> Without that testpmd will return error on adding a new flow to
> the list of flows attached to a given port.
>
> Signed-off-by: Tomasz Duszynski
> Acked-by: Jasvinder Singh
I think it's also candidate for:
Fixes: 30ffb4e67ee3 ("app/testpmd: add commands traffic metering and policing")
Cc: sta...@dpdk.org
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
[dpdk-dev] [PATCH] igb_uio: fix uevent montior issue
udev could not detect remove and add event of device when hotplug in
and out devices, that related with the fix about using pointer of
rte_uio_pci_dev as dev_id instead of uio_device for irq device handler,
that would result igb uio irq failure when kernel version after than 3.17.
so this patch correct it by use kernel version check before handle the
pci interrupt.
Fixes: 6b9ed026a870 ("igb_uio: fix build with kernel <= 3.17")
Signed-off-by: Jeff Guo
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 9f0fb5e..14ce2ea 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -192,9 +192,14 @@ igbuio_pci_irqcontrol(struct uio_info *info, s32 irq_state)
static irqreturn_t
igbuio_pci_irqhandler(int irq, void *dev_id)
{
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
struct rte_uio_pci_dev *udev = (struct rte_uio_pci_dev *)dev_id;
struct uio_info *info = &udev->info;
-
+#else
+ struct uio_device *idev = (struct uio_device *)dev_id;
+ struct uio_info *info = idev->info;
+ struct rte_uio_pci_dev *udev = info->priv;
+#endif
/* Legacy mode need to mask in hardware */
if (udev->mode == RTE_INTR_MODE_LEGACY &&
!pci_check_and_mask_intx(udev->pdev))
@@ -279,9 +284,15 @@ igbuio_pci_enable_interrupts(struct rte_uio_pci_dev *udev)
}
if (udev->info.irq != UIO_IRQ_NONE)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
err = request_irq(udev->info.irq, igbuio_pci_irqhandler,
udev->info.irq_flags, udev->info.name,
udev);
+#else
+ err = request_irq(udev->info.irq, igbuio_pci_irqhandler,
+ udev->info.irq_flags, udev->info.name,
+ udev->info.uio_dev);
+#endif
dev_info(&udev->pdev->dev, "uio device registered with irq %lx\n",
udev->info.irq);
@@ -292,7 +303,11 @@ static void
igbuio_pci_disable_interrupts(struct rte_uio_pci_dev *udev)
{
if (udev->info.irq) {
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
free_irq(udev->info.irq, udev);
+#else
+ free_irq(udev->info.irq, udev->info.uio_dev);
+#endif
udev->info.irq = 0;
}
--
2.7.4
Re: [dpdk-dev] [PATCH 14/14] vhost: enable packed virtqueues
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> index a3d4214b6..fbde54f9a 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -181,6 +181,7 @@ struct vhost_msg {
> (1ULL << VIRTIO_NET_F_GUEST_ANNOUNCE) | \
> (1ULL << VIRTIO_NET_F_MQ) | \
> (1ULL << VIRTIO_F_VERSION_1) | \
> + (1ULL << VIRTIO_F_PACKED) | \
Should be VIRTIO_F_PACKED_RING. Will fix it here and in other patches as well.
regards
Jens
[dpdk-dev] [PATCH v2] eal/ppc: fix compilation error with a broken else clause
From: Gowrishankar Muthukrishnan
Calling rte_smp_{w/r}mb macro expands into a compound block, which
would break compiling a else clause following it, if that calling
place has been terminated already with ";", as in below code.
This patch adds { } around this macro to allow compiling else too.
Fixes: d23a6bd04d ("eal/ppc: fix memory barrier for IBM POWER")
Fixes: 05c3fd7110 ("eal/ppc: atomic operations for IBM Power")
Signed-off-by: Gowrishankar Muthukrishnan
---
v2:
fixed ppc_64 atomic defines for a below error.
In file included from /tmp/dpdk/lib/librte_ring/rte_ring.h:372:0,
from /tmp/dpdk/lib/librte_ring/rte_ring.c:90:
/tmp/dpdk/lib/librte_ring/rte_ring_generic.h: In function ???update_tail???:
/tmp/dpdk/lib/librte_ring/rte_ring_generic.h:75:2: error: ???else??? without a
previous ???if???
else
^~~~
/tmp/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for target 'rte_ring.o'
failed
lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
index f38618f..39fce7b 100644
--- a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
@@ -64,9 +64,9 @@
* occur before the STORE operations generated after.
*/
#ifdef RTE_ARCH_64
-#definerte_wmb() {asm volatile("lwsync" : : : "memory"); }
+#definerte_wmb() asm volatile("lwsync" : : : "memory")
#else
-#definerte_wmb() {asm volatile("sync" : : : "memory"); }
+#definerte_wmb() asm volatile("sync" : : : "memory")
#endif
/**
@@ -76,9 +76,9 @@
* occur before the LOAD operations generated after.
*/
#ifdef RTE_ARCH_64
-#definerte_rmb() {asm volatile("lwsync" : : : "memory"); }
+#definerte_rmb() asm volatile("lwsync" : : : "memory")
#else
-#definerte_rmb() {asm volatile("sync" : : : "memory"); }
+#definerte_rmb() asm volatile("sync" : : : "memory")
#endif
#define rte_smp_mb() rte_mb()
--
1.9.1
[dpdk-dev] [PATCH v2] app/eventdev: fix port dequeue depth configuration
The port dequeue depth value has to be compared against the maximum
allowed dequeue depth reported by the event drivers.
Fixes: 3617aae53f92 ("app/eventdev: add event Rx adapter setup")
Signed-off-by: Pavan Nikhilesh
Acked-by: Jerin Jacob
---
v2 Changes:
- Pass port_conf as pointer.
app/test-eventdev/test_perf_atq.c | 13 -
app/test-eventdev/test_perf_common.c| 29 +++--
app/test-eventdev/test_perf_common.h| 3 ++-
app/test-eventdev/test_perf_queue.c | 12 +++-
app/test-eventdev/test_pipeline_atq.c | 3 +++
app/test-eventdev/test_pipeline_queue.c | 3 +++
6 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/app/test-eventdev/test_perf_atq.c
b/app/test-eventdev/test_perf_atq.c
index d07a05425..18c02562b 100644
--- a/app/test-eventdev/test_perf_atq.c
+++ b/app/test-eventdev/test_perf_atq.c
@@ -207,7 +207,18 @@ perf_atq_eventdev_setup(struct evt_test *test, struct
evt_options *opt)
}
}
- ret = perf_event_dev_port_setup(test, opt, 1 /* stride */, nb_queues);
+ if (opt->wkr_deq_dep > dev_info.max_event_port_dequeue_depth)
+ opt->wkr_deq_dep = dev_info.max_event_port_dequeue_depth;
+
+ /* port configuration */
+ struct rte_event_port_conf p_conf = {
+ .dequeue_depth = opt->wkr_deq_dep,
+ .enqueue_depth = dev_info.max_event_port_dequeue_depth,
+ .new_event_threshold = dev_info.max_num_events,
+ };
+
+ ret = perf_event_dev_port_setup(test, opt, 1 /* stride */, nb_queues,
+ &p_conf);
if (ret)
return ret;
diff --git a/app/test-eventdev/test_perf_common.c
b/app/test-eventdev/test_perf_common.c
index e279d81a5..3be210452 100644
--- a/app/test-eventdev/test_perf_common.c
+++ b/app/test-eventdev/test_perf_common.c
@@ -217,7 +217,7 @@ perf_launch_lcores(struct evt_test *test, struct
evt_options *opt,
static int
perf_event_rx_adapter_setup(struct evt_options *opt, uint8_t stride,
- struct rte_event_port_conf prod_conf)
+ struct rte_event_port_conf *prod_conf)
{
int ret = 0;
uint16_t prod;
@@ -239,7 +239,7 @@ perf_event_rx_adapter_setup(struct evt_options *opt,
uint8_t stride,
}
queue_conf.ev.queue_id = prod * stride;
ret = rte_event_eth_rx_adapter_create(prod, opt->dev_id,
- &prod_conf);
+ prod_conf);
if (ret) {
evt_err("failed to create rx adapter[%d]", prod);
return ret;
@@ -285,22 +285,12 @@ perf_event_rx_adapter_setup(struct evt_options *opt,
uint8_t stride,
int
perf_event_dev_port_setup(struct evt_test *test, struct evt_options *opt,
- uint8_t stride, uint8_t nb_queues)
+ uint8_t stride, uint8_t nb_queues,
+ struct rte_event_port_conf *port_conf)
{
struct test_perf *t = evt_test_priv(test);
uint16_t port, prod;
int ret = -1;
- struct rte_event_port_conf port_conf;
-
- memset(&port_conf, 0, sizeof(struct rte_event_port_conf));
- rte_event_port_default_conf_get(opt->dev_id, 0, &port_conf);
-
- /* port configuration */
- const struct rte_event_port_conf wkr_p_conf = {
- .dequeue_depth = opt->wkr_deq_dep,
- .enqueue_depth = port_conf.enqueue_depth,
- .new_event_threshold = port_conf.new_event_threshold,
- };
/* setup one port per worker, linking to all queues */
for (port = 0; port < evt_nr_active_lcores(opt->wlcores);
@@ -313,7 +303,7 @@ perf_event_dev_port_setup(struct evt_test *test, struct
evt_options *opt,
w->processed_pkts = 0;
w->latency = 0;
- ret = rte_event_port_setup(opt->dev_id, port, &wkr_p_conf);
+ ret = rte_event_port_setup(opt->dev_id, port, port_conf);
if (ret) {
evt_err("failed to setup port %d", port);
return ret;
@@ -327,18 +317,13 @@ perf_event_dev_port_setup(struct evt_test *test, struct
evt_options *opt,
}
/* port for producers, no links */
- struct rte_event_port_conf prod_conf = {
- .dequeue_depth = port_conf.dequeue_depth,
- .enqueue_depth = port_conf.enqueue_depth,
- .new_event_threshold = port_conf.new_event_threshold,
- };
if (opt->prod_type == EVT_PROD_TYPE_ETH_RX_ADPTR) {
for ( ; port < perf_nb_event_ports(opt); port++) {
struct prod_data *p = &t->prod[port];
p->t = t;
}
- ret = perf_event_rx_adapter_setup(opt, stride, prod_conf);
+
Re: [dpdk-dev] [PATCH] doc: announce ABI change for crypto info struct
Hi Shally/Ahkil, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Verma, Shally > Sent: Tuesday, January 30, 2018 7:56 AM > To: Akhil Goyal ; De Lara Guarch, Pablo > ; Trahe, Fiona ; > hemant.agra...@nxp.com; Doherty, Declan ; > Griffin, John ; Jain, Deepak K > ; j...@semihalf.com; t...@semihalf.com; > d...@marvell.com; nsams...@marvell.com; jianbo@arm.com; Jacob, > Jerin ; Athreya, Narayana Prasad > ; Murthy, Nidadavolu > > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for crypto info > struct > > I do see current cryptodev unit testcase (inside \test dir) uses > info.sym.max_nb_sessions param for session mempool_create. So, such > testcases change are also in proposal? Yes, for these tests, we can just define a macro in the tests, instead of using the info structure. > > Another point, we recently submitted an RFC patch on lib/cryptodev with > asymmetric crypto support > (https://dpdk.org/dev/patchwork/patch/34308/) which is awaiting review > and these fields have role to play there. > So, could this change be please viewed in conjunction with asym RFC? Do you need it for asymmetric? Anyway, this would remove the symmetric function and structures, not applicable for you. > > Thanks > Shally > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Akhil Goyal > > Sent: 29 January 2018 14:57 > > To: De Lara Guarch, Pablo ; Trahe, > > Fiona ; hemant.agra...@nxp.com; Doherty, > Declan > > ; Griffin, John ; > > Jain, Deepak K ; j...@semihalf.com; > > t...@semihalf.com; d...@marvell.com; nsams...@marvell.com; > > jianbo@arm.com; Jacob, Jerin > > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for crypto > > info struct > > > > Hi Pablo/Fiona, > > > > On 1/26/2018 4:38 PM, De Lara Guarch, Pablo wrote: > > > > > > > > >> -Original Message- > > >> From: Trahe, Fiona > > >> Sent: Friday, January 26, 2018 10:45 AM > > >> To: De Lara Guarch, Pablo ; > > >> akhil.go...@nxp.com; hemant.agra...@nxp.com; Doherty, Declan > > >> ; jerin.ja...@intel.com; Griffin, John > > >> ; Jain, Deepak K ; > > >> j...@semihalf.com; t...@semihalf.com; d...@marvell.com; > > >> nsams...@marvell.com; jianbo@arm.com > > >> Cc: dev@dpdk.org; Trahe, Fiona > > >> Subject: RE: [PATCH] doc: announce ABI change for crypto info > > >> struct > > >> > > >> Hi Pablo, > > >> > > >>> -Original Message- > > >>> From: De Lara Guarch, Pablo > > >>> Sent: Friday, January 26, 2018 9:04 AM > > >>> To: akhil.go...@nxp.com; hemant.agra...@nxp.com; Doherty, > Declan > > >>> ; jerin.ja...@intel.com; Trahe, Fiona > > >>> ; Griffin, John ; > > >>> Jain, Deepak K ; j...@semihalf.com; > > >>> t...@semihalf.com; d...@marvell.com; nsams...@marvell.com; > > >>> jianbo@arm.com > > >>> Cc: dev@dpdk.org; De Lara Guarch, Pablo > > >>> > > >>> Subject: [PATCH] doc: announce ABI change for crypto info struct > > >>> > > >>> Since the API changes made in 17.08, the session mempool is not > > >>> created anymore in each crypto device. > > >>> Therefore, there is no need to have, in the cryptodev info > > >>> structure, the maximum number of sessions supported per device > and > > >>> per queue pair. > > >>> > > >>> Signed-off-by: Pablo de Lara > > >>> --- > > >>> doc/guides/rel_notes/deprecation.rst | 5 + > > >>> 1 file changed, 5 insertions(+) > > >>> > > >>> diff --git a/doc/guides/rel_notes/deprecation.rst > > >>> b/doc/guides/rel_notes/deprecation.rst > > >>> index d59ad5988..5588ba7c1 100644 > > >>> --- a/doc/guides/rel_notes/deprecation.rst > > >>> +++ b/doc/guides/rel_notes/deprecation.rst > > >>> @@ -59,3 +59,8 @@ Deprecation Notices > > >>> be added between the producer and consumer structures. The > > >>> size of > > >> the > > >>> structure and the offset of the fields will remain the same on > > >>> platforms with 64B cache line, but will change on other platforms. > > >>> + > > >>> +* cryptodev: The structure ``sym``, including its fields > > >>> +``max_nb_sessions`` > > >>> + and ``max_nb_sessions_per_qp``, in structure > > >>> +``rte_cryptodev_info``, > > >>> + will be removed in 18.05, as these fields are not relevant > > >>> +anymore > > >>> + since the session mempool is not internal in the crypto device > > >> anymore. > > >>> -- > > >> [Fiona] max_nb_sessions must be also removed from struct > > >> rte_cryptodev_pmd_init_params > > > > > > Good point. Since this structure is internal, I guess we don't need > > > a > > deprecation notice for it, > > > but I will remove it in the patch for 18.05. > > > > > >> Regards deprecation of max_nb_sessions from both structs: > > >> Acked-by: Fiona Trahe > > >> > > >> If removing the max_nb_sessions_per_qp, then the following > > >> functions should also be deprecated. > > >> rte_cryptodev_queue_pair_attach_sym_session > > >> rte_cryptodev_queue_pair_detach_sym_session > > >> These and the max_nb_session_per_qp were added
Re: [dpdk-dev] [PATCH] doc: announce ABI change for crypto info struct
On 1/26/2018 2:33 PM, Pablo de Lara wrote: Since the API changes made in 17.08, the session mempool is not created anymore in each crypto device. Therefore, there is no need to have, in the cryptodev info structure, the maximum number of sessions supported per device and per queue pair. Signed-off-by: Pablo de Lara --- doc/guides/rel_notes/deprecation.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index d59ad5988..5588ba7c1 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -59,3 +59,8 @@ Deprecation Notices be added between the producer and consumer structures. The size of the structure and the offset of the fields will remain the same on platforms with 64B cache line, but will change on other platforms. + +* cryptodev: The structure ``sym``, including its fields ``max_nb_sessions`` + and ``max_nb_sessions_per_qp``, in structure ``rte_cryptodev_info``, + will be removed in 18.05, as these fields are not relevant anymore + since the session mempool is not internal in the crypto device anymore. Acked-by: Akhil Goyal
Re: [dpdk-dev] [PATCH] doc: announce ABI change for crypto info struct
>-Original Message- >From: De Lara Guarch, Pablo [mailto:pablo.de.lara.gua...@intel.com] >Sent: 30 January 2018 16:51 >To: Verma, Shally ; Akhil Goyal >; Trahe, Fiona ; >hemant.agra...@nxp.com; Doherty, Declan ; Griffin, >John ; Jain, Deepak K >; j...@semihalf.com; t...@semihalf.com; >d...@marvell.com; nsams...@marvell.com; >jianbo@arm.com; Jacob, Jerin ; >Athreya, Narayana Prasad >; Murthy, Nidadavolu > >Cc: dev@dpdk.org >Subject: RE: [dpdk-dev] [PATCH] doc: announce ABI change for crypto info struct > >Hi Shally/Ahkil, > >> -Original Message- >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Verma, Shally >> Sent: Tuesday, January 30, 2018 7:56 AM >> To: Akhil Goyal ; De Lara Guarch, Pablo >> ; Trahe, Fiona ; >> hemant.agra...@nxp.com; Doherty, Declan ; >> Griffin, John ; Jain, Deepak K >> ; j...@semihalf.com; t...@semihalf.com; >> d...@marvell.com; nsams...@marvell.com; jianbo@arm.com; Jacob, >> Jerin ; Athreya, Narayana Prasad >> ; Murthy, Nidadavolu >> >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for crypto info >> struct >> >> I do see current cryptodev unit testcase (inside \test dir) uses >> info.sym.max_nb_sessions param for session mempool_create. So, such >> testcases change are also in proposal? > >Yes, for these tests, we can just define a macro in the tests, instead of >using the info structure. [Shally] Ok, then you mean applications will choose any random number during mempool_create and not dependent on device max_nb_sessions? >> >> Another point, we recently submitted an RFC patch on lib/cryptodev with >> asymmetric crypto support >> (https://dpdk.org/dev/patchwork/patch/34308/) which is awaiting review >> and these fields have role to play there. >> So, could this change be please viewed in conjunction with asym RFC? > >Do you need it for asymmetric? Anyway, this would remove the symmetric >function and structures, not applicable for you. [Shally] I would say addition of asym in lib/cryptodev is not entirely standalone, specifically for PMDs that can support both. My key concern are max_nb_sessions_per_qp and related qp_attach_sym/asym APIs which enable management of queue distribution among sym and asym in current proposal, specifically, for PMDs that can support both but have dedicated qp for each. Right now proposal is open for feedback and would prefer to be covered before sym related changes could be applied. >> >> Thanks >> Shally >> >> > -Original Message- >> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Akhil Goyal >> > Sent: 29 January 2018 14:57 >> > To: De Lara Guarch, Pablo ; Trahe, >> > Fiona ; hemant.agra...@nxp.com; Doherty, >> Declan >> > ; Griffin, John ; >> > Jain, Deepak K ; j...@semihalf.com; >> > t...@semihalf.com; d...@marvell.com; nsams...@marvell.com; >> > jianbo@arm.com; Jacob, Jerin >> >> > Cc: dev@dpdk.org >> > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for crypto >> > info struct >> > >> > Hi Pablo/Fiona, >> > >> > On 1/26/2018 4:38 PM, De Lara Guarch, Pablo wrote: >> > > >> > > >> > >> -Original Message- >> > >> From: Trahe, Fiona >> > >> Sent: Friday, January 26, 2018 10:45 AM >> > >> To: De Lara Guarch, Pablo ; >> > >> akhil.go...@nxp.com; hemant.agra...@nxp.com; Doherty, Declan >> > >> ; jerin.ja...@intel.com; Griffin, John >> > >> ; Jain, Deepak K ; >> > >> j...@semihalf.com; t...@semihalf.com; d...@marvell.com; >> > >> nsams...@marvell.com; jianbo@arm.com >> > >> Cc: dev@dpdk.org; Trahe, Fiona >> > >> Subject: RE: [PATCH] doc: announce ABI change for crypto info >> > >> struct >> > >> >> > >> Hi Pablo, >> > >> >> > >>> -Original Message- >> > >>> From: De Lara Guarch, Pablo >> > >>> Sent: Friday, January 26, 2018 9:04 AM >> > >>> To: akhil.go...@nxp.com; hemant.agra...@nxp.com; Doherty, >> Declan >> > >>> ; jerin.ja...@intel.com; Trahe, Fiona >> > >>> ; Griffin, John ; >> > >>> Jain, Deepak K ; j...@semihalf.com; >> > >>> t...@semihalf.com; d...@marvell.com; nsams...@marvell.com; >> > >>> jianbo@arm.com >> > >>> Cc: dev@dpdk.org; De Lara Guarch, Pablo >> > >>> >> > >>> Subject: [PATCH] doc: announce ABI change for crypto info struct >> > >>> >> > >>> Since the API changes made in 17.08, the session mempool is not >> > >>> created anymore in each crypto device. >> > >>> Therefore, there is no need to have, in the cryptodev info >> > >>> structure, the maximum number of sessions supported per device >> and >> > >>> per queue pair. >> > >>> >> > >>> Signed-off-by: Pablo de Lara >> > >>> --- >> > >>> doc/guides/rel_notes/deprecation.rst | 5 + >> > >>> 1 file changed, 5 insertions(+) >> > >>> >> > >>> diff --git a/doc/guides/rel_notes/deprecation.rst >> > >>> b/doc/guides/rel_notes/deprecation.rst >> > >>> index d59ad5988..5588ba7c1 100644 >> > >>> --- a/doc/guides/rel_notes/deprecation.rst >> > >>> +++ b/doc/guides/rel_notes/deprecation.rst >> > >>> @@ -59,3 +59,8 @@ Deprecation Notices >> > >>> be a
[dpdk-dev] [PATCH v2 0/3] Cryptodev API/ABI deprecation notices
v2: - Added an extra deprecation announcement - Bonded the other two deprecation notices with the new one in a patchset Pablo de Lara (3): doc: announce ABI change for crypto info struct doc: announce deprecation for attach/detach crypto session doc: announce deprecation in crypto queue pair start/stop doc/guides/rel_notes/deprecation.rst | 15 +++ lib/librte_cryptodev/rte_cryptodev.h | 4 2 files changed, 19 insertions(+) -- 2.14.3
[dpdk-dev] [PATCH v2 2/3] doc: announce deprecation for attach/detach crypto session
Functions rte_cryptodev_queue_pair_attach_sym_session and rte_cryptodev_queue_pair_detach_sym_sessions are not really used in any of the crypto drivers (only one driver implements it and it just return 0). Therefore, this API can be deprecated from 18.02 and removed in 18.05. Signed-off-by: Pablo de Lara --- doc/guides/rel_notes/deprecation.rst | 5 + lib/librte_cryptodev/rte_cryptodev.h | 2 ++ 2 files changed, 7 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 5588ba7c1..bd4200bba 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -64,3 +64,8 @@ Deprecation Notices and ``max_nb_sessions_per_qp``, in structure ``rte_cryptodev_info``, will be removed in 18.05, as these fields are not relevant anymore since the session mempool is not internal in the crypto device anymore. + +* cryptodev: Functions ``rte_cryptodev_queue_pair_attach_sym_session()`` and + ``rte_cryptodev_queue_pair_dettach_sym_session()`` will be deprecated from + 18.02 and removed in 18.05, as there are no drivers doing anything useful + with them. diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h index c8fa68935..4597f864d 100644 --- a/lib/librte_cryptodev/rte_cryptodev.h +++ b/lib/librte_cryptodev/rte_cryptodev.h @@ -986,6 +986,7 @@ unsigned int rte_cryptodev_get_private_session_size(uint8_t dev_id); /** + * @deprecated * Attach queue pair with sym session. * * @param dev_id Device to which the session will be attached. @@ -1002,6 +1003,7 @@ rte_cryptodev_queue_pair_attach_sym_session(uint8_t dev_id, uint16_t qp_id, struct rte_cryptodev_sym_session *session); /** + * @deprecated * Detach queue pair with sym session. * * @param dev_id Device to which the session is attached. -- 2.14.3
[dpdk-dev] [PATCH v2 1/3] doc: announce ABI change for crypto info struct
Since the API changes made in 17.08, the session mempool is not created anymore in each crypto device. Therefore, there is no need to have, in the cryptodev info structure, the maximum number of sessions supported per device and per queue pair. Signed-off-by: Pablo de Lara Acked-by: Fiona Trahe --- doc/guides/rel_notes/deprecation.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index d59ad5988..5588ba7c1 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -59,3 +59,8 @@ Deprecation Notices be added between the producer and consumer structures. The size of the structure and the offset of the fields will remain the same on platforms with 64B cache line, but will change on other platforms. + +* cryptodev: The structure ``sym``, including its fields ``max_nb_sessions`` + and ``max_nb_sessions_per_qp``, in structure ``rte_cryptodev_info``, + will be removed in 18.05, as these fields are not relevant anymore + since the session mempool is not internal in the crypto device anymore. -- 2.14.3
[dpdk-dev] [PATCH v2 3/3] doc: announce deprecation in crypto queue pair start/stop
Functions rte_cryptodev_queue_pair_start/stop are not really used in any of the crypto drivers (they all just return 0 or -ENOTSUP). Therefore, this API can be deprecated from 18.02 and removed in 18.05. Signed-off-by: Pablo de Lara Acked-by: Akhil Goyal --- doc/guides/rel_notes/deprecation.rst | 5 + lib/librte_cryptodev/rte_cryptodev.h | 2 ++ 2 files changed, 7 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index bd4200bba..805fb885e 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -69,3 +69,8 @@ Deprecation Notices ``rte_cryptodev_queue_pair_dettach_sym_session()`` will be deprecated from 18.02 and removed in 18.05, as there are no drivers doing anything useful with them. + +* cryptodev: Functions ``rte_cryptodev_queue_pair_start()`` and + ``rte_cryptodev_queue_pair_stop()`` will be deprecated from 18.02 + and removed in 18.05, as there are no drivers doing anything useful + with them. diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h index 4597f864d..712342c72 100644 --- a/lib/librte_cryptodev/rte_cryptodev.h +++ b/lib/librte_cryptodev/rte_cryptodev.h @@ -602,6 +602,7 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id, struct rte_mempool *session_pool); /** + * @deprecated * Start a specified queue pair of a device. It is used * when deferred_start flag of the specified queue is true. * @@ -619,6 +620,7 @@ extern int rte_cryptodev_queue_pair_start(uint8_t dev_id, uint16_t queue_pair_id); /** + * @deprecated * Stop specified queue pair of a device * * @param dev_id The identifier of the device -- 2.14.3
[dpdk-dev] [PATCH] doc: update procinfo for shared library
added note category to procinfo guide, to intimate users in shared library mode. Procinfo requires same NIC libraries to probe the NIC devices as Primary Application. Signed-off-by: Vipin Varghese --- doc/guides/tools/proc_info.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/tools/proc_info.rst b/doc/guides/tools/proc_info.rst index fd17e27..78c5a9e 100644 --- a/doc/guides/tools/proc_info.rst +++ b/doc/guides/tools/proc_info.rst @@ -38,6 +38,12 @@ statistics, resetting port statistics and printing DPDK memory information. This application extends the original functionality that was supported by dump_cfg. +.. Note:: + When running `dpdk-procinfo`` with shared library mode, it is required to + pass the same NIC PMD libraries as used for the primary application. Any + mismatch in PMD library arguments can lead to undefined behaviour and results + affecting primary application too. + Running the Application --- The application has a number of command line options: -- 1.9.1
Re: [dpdk-dev] [PATCH v2] crypto/scheduler: fix strncpy
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Monday, January 29, 2018 9:22 AM
> To: Zhang, Roy Fan
> Cc: dev@dpdk.org; Richardson, Bruce ; De
> Lara Guarch, Pablo ; sta...@dpdk.org
> Subject: [PATCH v2] crypto/scheduler: fix strncpy
>
> The coverity issue was not completely fixed, since strncpy should not be
> called with max length.
> Instead, snprintf is used as a safer option.
>
> Coverity issue: 143431
> Fixes: d040aca67170 ("crypto/scheduler: fix strings not null terminated")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Pablo de Lara
> ---
>
> v2:
> - Replaced strncpy with snprintf
Acked-by: Fan Zhang
Re: [dpdk-dev] [PATCH V13 1/3] eal: add uevent monitor api and callback func
On 1/30/2018 8:14 AM, Thomas Monjalon wrote:
27/01/2018 04:48, Guo, Jia:
On 1/27/2018 12:53 AM, Bruce Richardson wrote:
On Fri, Jan 26, 2018 at 11:49:35AM +0800, Jeff Guo wrote:
+ ret = rte_service_lcore_add(slcore);
+ if (ret) {
+ RTE_LOG(ERR, EAL, "dev event monitor lcore add fail");
+ return ret;
+ }
+
I don't think you should be taking another service core for this purpose
without the user asking for it. I also don't think service cores is the
right "tool" for monitoring the epoll. Rather than using a non-blocking
poll on a service core, I think you should look to reuse the existing
infrastructure for handling interrupts in the EAL, which relies on a
separate thread blocked on fd's awaiting input.
bruce, seems that you might be see the other view of the mountain, so if
service cores tools basically be born to need user knowledge and
control it, and it is no need to add user to control service tool in the
case, i thinks we might not use the existing interrupts infrastructure
because it is the device uevent not interrupt as the same functional
scope , we could use a separate thread which i have used before in v7
to specialize poll the uevent, please check v7 part to see if it is good.
The v7 was using pthread_create, so it was not the right solution.
@tomas, do you agree with that above , or other suggestion, could it be
got agreement all or let it improvement later?
I have no issue about using rte_service.
I think the other events processing in EAL could use rte_service.
Maybe Harry has a different view?
My main concerns are:
1/ There is not enough review
2/ The callback lookup is using device name from uevent
3/ There is no reference to the rte_device struct
Minor extra requirement: the new __rte_experimental should be used,
see http://dpdk.org/commit/77b7b81e32e
please review my patch v14 , hope i can fix all your concern, about
rte_device struct , i think if there is not better idea to handler the
null struct issue, the device name should be use as experimental and i
have verify that is ok for use.
[dpdk-dev] [PATCH V14 1/3] eal: add uevent monitor api and callback func
This patch aim to add a general uevent mechanism in eal device layer,
to enable all linux kernel object uevent monitoring, user could use these
APIs to monitor and read out the device status info that sent from the
kernel side, then corresponding to handle it, such as when detect hotplug
uevent type, user could detach or attach the device, and more it benefit
to use to do smoothly fail safe work.
About uevent monitoring:
a: add one epolling to poll the netlink socket, to monitor the uevent of
the device.
b: add enum of rte_eal_dev_event_type and struct of rte_eal_uevent.
c: add below APIs in rte eal device layer.
rte_dev_callback_register
rte_dev_callback_unregister
_rte_dev_callback_process
rte_dev_event_monitor_start
rte_dev_event_monitor_stop
Signed-off-by: Jeff Guo
---
v14->v13:
add __rte_experimental on function defind and fix bsd build issue
---
lib/librte_eal/bsdapp/eal/Makefile | 1 +
lib/librte_eal/bsdapp/eal/eal_dev.c | 33 +
lib/librte_eal/common/eal_common_dev.c | 132 +
lib/librte_eal/common/include/rte_dev.h | 121
lib/librte_eal/linuxapp/eal/Makefile| 1 +
lib/librte_eal/linuxapp/eal/eal_dev.c | 243
6 files changed, 531 insertions(+)
create mode 100644 lib/librte_eal/bsdapp/eal/eal_dev.c
create mode 100644 lib/librte_eal/linuxapp/eal/eal_dev.c
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index dd455e6..c0921dd 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -33,6 +33,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_lcore.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_timer.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_interrupts.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_alarm.c
+SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_dev.c
# from common dir
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_lcore.c
diff --git a/lib/librte_eal/bsdapp/eal/eal_dev.c
b/lib/librte_eal/bsdapp/eal/eal_dev.c
new file mode 100644
index 000..3b7bbf2
--- /dev/null
+++ b/lib/librte_eal/bsdapp/eal/eal_dev.c
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "eal_thread.h"
+
+int __rte_experimental
+rte_dev_event_monitor_start(void)
+{
+ RTE_LOG(ERR, EAL, "Not support event monitor for FreeBSD\n");
+ return -1;
+}
+
+int __rte_experimental
+rte_dev_event_monitor_stop(void)
+{
+ RTE_LOG(ERR, EAL, "Not support event monitor for FreeBSD\n");
+ return -1;
+}
diff --git a/lib/librte_eal/common/eal_common_dev.c
b/lib/librte_eal/common/eal_common_dev.c
index 0de1c5d..8e3934c 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -43,9 +43,31 @@
#include
#include
#include
+#include
+#include
#include "eal_private.h"
+/* spinlock for device callbacks */
+static rte_spinlock_t rte_dev_event_lock = RTE_SPINLOCK_INITIALIZER;
+
+/**
+ * The user application callback description.
+ *
+ * It contains callback address to be registered by user application,
+ * the pointer to the parameters for callback, and the device name.
+ */
+struct rte_dev_event_callback {
+ TAILQ_ENTRY(rte_dev_event_callback) next; /**< Callbacks list */
+ rte_dev_event_cb_fn cb_fn;/**< Callback address */
+ void *cb_arg; /**< Callback parameter */
+ char *dev_name; /**< Callback devcie name, NULL is for all device */
+ uint32_t active;/**< Callback is executing */
+};
+
+/* A general callbacks list for all callback of devices */
+static struct rte_dev_event_cb_list dev_event_cbs;
+
static int cmp_detached_dev_name(const struct rte_device *dev,
const void *_name)
{
@@ -236,3 +258,113 @@ rte_eal_hotplug_remove(const char *busname, const char
*devname)
rte_eal_devargs_remove(busname, devname);
return ret;
}
+
+int __rte_experimental
+rte_dev_callback_register(char *device_name, rte_dev_event_cb_fn cb_fn,
+ void *cb_arg)
+{
+ struct rte_dev_event_callback *event_cb = NULL;
+
+ rte_spinlock_lock(&rte_dev_event_lock);
+
+ if (TAILQ_EMPTY(&(dev_event_cbs)))
+ TAILQ_INIT(&(dev_event_cbs));
+
+ TAILQ_FOREACH(event_cb, &(dev_event_cbs), next) {
+ if (event_cb->cb_fn == cb_fn &&
+ event_cb->cb_arg == cb_arg &&
+ ((!device_name && !event_cb->dev_name) ? 1 :
+ (!strcmp(event_cb->dev_name, device_name
+ break;
+ }
+
+ /* create a new callback. */
+ if (event_cb == NULL) {
+ /* allocate a new user callback entity */
+ event_cb = malloc(sizeof(struct rte_dev
[dpdk-dev] [PATCH V14 3/3] app/testpmd: use uevent to monitor hotplug
use testpmd for example, to show app how to request and use
uevent monitoring to handle the hot removal event and the
hot insertion event.
Signed-off-by: Jeff Guo
---
v14->v13:
no change
---
app/test-pmd/testpmd.c | 169 +
app/test-pmd/testpmd.h | 9 +++
2 files changed, 178 insertions(+)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index d8ac432..36b7325 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -368,6 +369,8 @@ uint8_t bitrate_enabled;
struct gro_status gro_ports[RTE_MAX_ETHPORTS];
uint8_t gro_flush_cycles = GRO_DEFAULT_FLUSH_CYCLES;
+static struct hotplug_request_list hp_list;
+
/* Forward function declarations */
static void map_port_queue_stats_mapping_registers(portid_t pi,
struct rte_port *port);
@@ -375,6 +378,13 @@ static void check_all_ports_link_status(uint32_t
port_mask);
static int eth_event_callback(portid_t port_id,
enum rte_eth_event_type type,
void *param, void *ret_param);
+static int eth_uevent_callback(char *device_name, enum rte_dev_event_type type,
+ void *param);
+static int eth_uevent_callback_register(portid_t port_id);
+static bool in_hotplug_list(const char *dev_name);
+
+static int hotplug_list_add(const char *dev_name,
+ enum rte_dev_event_type event);
/*
* Check if all the ports are started.
@@ -1838,6 +1848,27 @@ reset_port(portid_t pid)
printf("Done\n");
}
+static int
+eth_uevent_callback_register(portid_t port_id)
+{
+ int diag;
+ char device_name[128];
+
+ snprintf(device_name, sizeof(device_name),
+ "%s", rte_eth_devices[port_id].device->name);
+
+ /* register the uevent callback */
+
+ diag = rte_dev_callback_register(device_name,
+ eth_uevent_callback, (void *)(intptr_t)port_id);
+ if (diag) {
+ printf("Failed to setup uevent callback\n");
+ return -1;
+ }
+
+ return 0;
+}
+
void
attach_port(char *identifier)
{
@@ -1854,6 +1885,8 @@ attach_port(char *identifier)
if (rte_eth_dev_attach(identifier, &pi))
return;
+ eth_uevent_callback_register(pi);
+
socket_id = (unsigned)rte_eth_dev_socket_id(pi);
/* if socket_id is invalid, set to 0 */
if (check_socket_id(socket_id) < 0)
@@ -1865,6 +1898,8 @@ attach_port(char *identifier)
ports[pi].port_status = RTE_PORT_STOPPED;
+ hotplug_list_add(identifier, RTE_DEV_EVENT_REMOVE);
+
printf("Port %d is attached. Now total ports is %d\n", pi, nb_ports);
printf("Done\n");
}
@@ -1891,6 +1926,9 @@ detach_port(portid_t port_id)
nb_ports = rte_eth_dev_count();
+ hotplug_list_add(rte_eth_devices[port_id].device->name,
+RTE_DEV_EVENT_ADD);
+
printf("Port '%s' is detached. Now total ports is %d\n",
name, nb_ports);
printf("Done\n");
@@ -1914,6 +1952,9 @@ pmd_test_exit(void)
close_port(pt_id);
}
}
+
+ rte_dev_event_monitor_stop();
+
printf("\nBye...\n");
}
@@ -1998,6 +2039,49 @@ rmv_event_callback(void *arg)
dev->device->name);
}
+static void
+rmv_uevent_callback(void *arg)
+{
+ char name[RTE_ETH_NAME_MAX_LEN];
+ uint8_t port_id = (intptr_t)arg;
+
+ rte_eal_alarm_cancel(rmv_uevent_callback, arg);
+
+ RTE_ETH_VALID_PORTID_OR_RET(port_id);
+ printf("removing port id:%u\n", port_id);
+
+ if (!in_hotplug_list(rte_eth_devices[port_id].device->name))
+ return;
+
+ stop_packet_forwarding();
+
+ stop_port(port_id);
+ close_port(port_id);
+ if (rte_eth_dev_detach(port_id, name)) {
+ TESTPMD_LOG(ERR, "Failed to detach port '%s'\n", name);
+ return;
+ }
+
+ nb_ports = rte_eth_dev_count();
+
+ printf("Port '%s' is detached. Now total ports is %d\n",
+ name, nb_ports);
+}
+
+static void
+add_uevent_callback(void *arg)
+{
+ char *dev_name = (char *)arg;
+
+ rte_eal_alarm_cancel(add_uevent_callback, arg);
+
+ if (!in_hotplug_list(dev_name))
+ return;
+
+ printf("add device: %s\n", dev_name);
+ attach_port(dev_name);
+}
+
/* This function is used by the interrupt thread */
static int
eth_event_callback(portid_t port_id, enum rte_eth_event_type type, void *param,
@@ -2041,6 +2125,82 @@ eth_event_callback(portid_t port_id, enum
rte_eth_event_type type, void *param,
return 0;
}
+static bool
+in_hotplug_list(const char *dev_name)
+{
+ struct hotplug_request *hp_request = NULL;
+
+ TAILQ_FOREACH(hp_request, &hp_list, next) {
+
[dpdk-dev] [PATCH V14 2/3] eal: add uevent pass and process function
In order to handle the uevent which have been detected from the kernel
side, add uevent process function, let hot plug event to be example to
show uevent mechanism how to pass the uevent and process the uevent.
About uevent passing and processing, add below functions in linux eal
dev layer. FreeBSD not support uevent ,so let it to be void and do not
implement in function.
a.dev_uev_parse
b.dev_uev_receive
c.dev_uev_process
Signed-off-by: Jeff Guo
Reviewed-by: Jingjing Wu
---
v14->v13:
no change.
---
lib/librte_eal/common/include/rte_dev.h | 16 +
lib/librte_eal/linuxapp/eal/eal_dev.c | 105 +++-
2 files changed, 119 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index 82082d8..bd883a7 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -53,6 +53,22 @@ extern "C" {
#include
#include
+#define RTE_EAL_UEV_MSG_LEN 4096
+#define RTE_EAL_UEV_MSG_ELEM_LEN 128
+
+enum rte_dev_state {
+ RTE_DEV_UNDEFINED, /**< unknown device state */
+ RTE_DEV_FAULT, /**< device fault or error */
+ RTE_DEV_PARSED, /**< device has been scanned on bus*/
+ RTE_DEV_PROBED, /**< device has been probed driver */
+};
+
+enum rte_dev_event_subsystem {
+ RTE_DEV_EVENT_SUBSYSTEM_UIO,
+ RTE_DEV_EVENT_SUBSYSTEM_VFIO,
+ RTE_DEV_EVENT_SUBSYSTEM_MAX
+};
+
/**
* The device event type.
*/
diff --git a/lib/librte_eal/linuxapp/eal/eal_dev.c
b/lib/librte_eal/linuxapp/eal/eal_dev.c
index 22ef85e..7b01f53 100644
--- a/lib/librte_eal/linuxapp/eal/eal_dev.c
+++ b/lib/librte_eal/linuxapp/eal/eal_dev.c
@@ -79,10 +79,111 @@ dev_monitor_enable(int netlink_fd)
return -1;
}
+static void
+dev_uev_parse(const char *buf, struct rte_dev_event *event)
+{
+ char action[RTE_EAL_UEV_MSG_ELEM_LEN];
+ char subsystem[RTE_EAL_UEV_MSG_ELEM_LEN];
+ char dev_path[RTE_EAL_UEV_MSG_ELEM_LEN];
+ char pci_slot_name[RTE_EAL_UEV_MSG_ELEM_LEN];
+ int i = 0;
+
+ memset(action, 0, RTE_EAL_UEV_MSG_ELEM_LEN);
+ memset(subsystem, 0, RTE_EAL_UEV_MSG_ELEM_LEN);
+ memset(dev_path, 0, RTE_EAL_UEV_MSG_ELEM_LEN);
+ memset(pci_slot_name, 0, RTE_EAL_UEV_MSG_ELEM_LEN);
+
+ while (i < RTE_EAL_UEV_MSG_LEN) {
+ for (; i < RTE_EAL_UEV_MSG_LEN; i++) {
+ if (*buf)
+ break;
+ buf++;
+ }
+
+ if (!strncmp(buf, "ACTION=", 7)) {
+ buf += 7;
+ i += 7;
+ snprintf(action, sizeof(action), "%s", buf);
+ } else if (!strncmp(buf, "DEVPATH=", 8)) {
+ buf += 8;
+ i += 8;
+ snprintf(dev_path, sizeof(dev_path), "%s", buf);
+ } else if (!strncmp(buf, "SUBSYSTEM=", 10)) {
+ buf += 10;
+ i += 10;
+ snprintf(subsystem, sizeof(subsystem), "%s", buf);
+ } else if (!strncmp(buf, "PCI_SLOT_NAME=", 14)) {
+ buf += 14;
+ i += 14;
+ snprintf(pci_slot_name, sizeof(subsystem), "%s", buf);
+ }
+ for (; i < RTE_EAL_UEV_MSG_LEN; i++) {
+ if (*buf == '\0')
+ break;
+ buf++;
+ }
+ }
+
+
+ if ((!strncmp(subsystem, "uio", 3)) ||
+ (!strncmp(subsystem, "pci", 3))) {
+ event->subsystem = RTE_DEV_EVENT_SUBSYSTEM_UIO;
+ if (!strncmp(action, "add", 3))
+ event->type = RTE_DEV_EVENT_ADD;
+ if (!strncmp(action, "remove", 6))
+ event->type = RTE_DEV_EVENT_REMOVE;
+ event->devname = pci_slot_name;
+ }
+}
+
+static int
+dev_uev_receive(int fd, struct rte_dev_event *uevent)
+{
+ int ret;
+ char buf[RTE_EAL_UEV_MSG_LEN];
+
+ memset(uevent, 0, sizeof(struct rte_dev_event));
+ memset(buf, 0, RTE_EAL_UEV_MSG_LEN);
+
+ ret = recv(fd, buf, RTE_EAL_UEV_MSG_LEN - 1, MSG_DONTWAIT);
+ if (ret < 0) {
+ RTE_LOG(ERR, EAL,
+ "Socket read error(%d): %s\n",
+ errno, strerror(errno));
+ return -1;
+ } else if (ret == 0)
+ /* connection closed */
+ return -1;
+
+ dev_uev_parse(buf, uevent);
+
+ return 0;
+}
+
static int
-dev_uev_process(__rte_unused struct epoll_event *events, __rte_unused int nfds)
+dev_uev_process(struct epoll_event *events, int nfds)
{
- /* TODO: device uevent processing */
+ struct rte_dev_event uevent;
+ int i;
+
+ for (i = 0; i < nfds; i++) {
+ if (dev_uev_receive(events[i].data.fd, &uevent))
+
Re: [dpdk-dev] [PATCH] net/ixgbe: fix reconfiguration of rx queues
> > >
> > > From: "Charles (Chas) Williams"
> > >
> > > .dev_configure() may be called again after RX queues have been setup.
> > > This has the effect of clearing whatever setting the RX queues made for
> > > rx_bulk_alloc_allowed or rx_vec_allowed. Only reset this configuration
> > > is there aren't any currently allocated queues.
> > >
> > > Fixes: 01fa1d6215fa ("ixgbe: unify Rx setup")
> > >
> > > Signed-off-by: Chas Williams
> > > ---
> > > drivers/net/ixgbe/ixgbe_ethdev.c | 18 --
> > > 1 file changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > index 37eb668..b39249a 100644
> > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > @@ -2348,6 +2348,7 @@ ixgbe_dev_configure(struct rte_eth_dev *dev)
> > > struct ixgbe_adapter *adapter =
> > > (struct ixgbe_adapter *)dev->data->dev_private;
> > > int ret;
> > > + uint16_t i;
> > >
> > > PMD_INIT_FUNC_TRACE();
> > > /* multipe queue mode checking */
> > > @@ -2363,11 +2364,17 @@ ixgbe_dev_configure(struct rte_eth_dev *dev)
> > >
> > > /*
> > > * Initialize to TRUE. If any of Rx queues doesn't meet the bulk
> > > - * allocation or vector Rx preconditions we will reset it.
> > > + * allocation or vector Rx preconditions we will reset it. We
> > > + * can only do this is there aren't any existing RX queues.
> > > */
> > > + for (i = 0; i < dev->data->nb_rx_queues; i++) {
> > > + if (dev->data->rx_queues[i])
> > > + goto out;
> > > + }
> > I don't see why this is needed.
> > It surely should be possible to reconfigure device with different
> > number of queues.
> > Konstantin
> >
> > Yes, you can add new queues but you shouldn't reset the bulk and vec
> > settings
> > that have already been chosen by the previously allocated queues.
> Why is that? Might be in new queue setup user will change settings?
>
> There is no requirement that the user allocates all the RX queues in the same
> way.
> Some could have a different numbers of descs which is one of the checks in
> check_rx_burst_bulk_alloc_preconditions()
Exactly. That's why after dev_configure() user has to call queue_setup() for
*all*
queues he plans to use.
>
>
>
> > If those queues
> > set rx_bulk_alloc_allowed to be false, then this is going to cause an issue
> > with queue
> > release later on.
>
> Could you be a bit more specific here:
> What you think will be broken in ixgbe_rx_queue_release() in that case?
>
> Sorry, I mispoke. It's this function, ixgbe_reset_rx_queue(),
>
> /*
> * By default, the Rx queue setup function allocates enough memory for
> * IXGBE_MAX_RING_DESC. The Rx Burst bulk allocation function
> requires
> * extra memory at the end of the descriptor ring to be zero'd out.
> */
> if (adapter->rx_bulk_alloc_allowed)
> /* zero out extra memory */
> len += RTE_PMD_IXGBE_RX_MAX_BURST;
>
> /*
> * Zero out HW ring memory. Zero out extra memory at the end of
> * the H/W ring so look-ahead logic in Rx Burst bulk alloc function
> * reads extra memory as zeros.
> */
> for (i = 0; i < len; i++) {
> rxq->rx_ring[i] = zeroed_desc;
> }
>
> So you potentially write past the rx_ring[] you allocated.
We always allocate rx_ring[] to maximum possible size plus space for fake
descriptors:
drivers/net/ixgbe/ixgbe_rxtx.h:
#define RX_RING_SZ ((IXGBE_MAX_RING_DESC + RTE_PMD_IXGBE_RX_MAX_BURST) * \
sizeof(union ixgbe_adv_rx_desc))
then at ixgbe_dev_rx_queue_setup(...):
/*
* Allocate RX ring hardware descriptors. A memzone large enough to
* handle the maximum ring size is allocated in order to allow for
* resizing in later calls to the queue setup function.
*/
rz = rte_eth_dma_zone_reserve(dev, "rx_ring", queue_idx,
RX_RING_SZ, IXGBE_ALIGN, socket_id);
...
rxq->rx_ring = (union ixgbe_adv_rx_desc *) rz->addr;
>
> You can't change rx_bulk_alloc_allowed once it has been set and you have
> allocated queues.
> In fact, you can't really let some later queue change this setting after the
> first queue decides
> what itshould be.
See above.
>
>
>
> > This breaks:
> >
> > rte_eth_dev_configure(..., 1, 1, ...);
> > rx_queue_setup(1)
> > [rx_queue_setup decides that it can't support rx_bulk_alloc_allowed]
> > ..
> >
> > Later, you want to add some more queues, you call
> >
> > eth_eth_dev_configure(..., 2, 2, ...);
>
> After you call dev_configure, you'll have to do queue_setup() for all your
> queues.
> dev_configure() can changes some global device settings, so each queue has to
> be
> reconfigured.
> In your example It should be:
> eth_eth_dev_configure(..., 2, 2,
Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel offloads
Hi Xueming,
> > > This patch introduce new TX offloads flag for devices that support
> > > tunnel agnostic checksum and TSO offloads.
> > >
> > > The support from the device is for inner and outer checksums on
> > > IPV4/TCP/UDP and TSO for *any packet with the following format*:
> > >
> > > < some headers > / [optional IPv4/IPv6] / [optional TCP/UDP] / > > headers> / [optional inner IPv4/IPv6] / [optional TCP/UDP]
> > >
> > > For example the following packets can use this feature:
> > >
> > > 1. eth / ipv4 / udp / VXLAN / ip / tcp 2. eth / ipv4 / GRE / MPLS /
> > > ipv4 / udp
> >
> > So in terms of usage - what is the difference with current TSO types?
> > Konstantin
> >
>
> Traditionally, HW only recognize "known" tunnel type, do TSO calculation
> based on L3/L4 headers known to tunnel type. For example, it must be
> L2 header after VXLAN, then L3. While this Generic offloading provides
> inner/outer L3/L4 header info(len and offset) to HW, and thus tunnel
> info become less important. Please note the MPLS over GRE tunnel in last
> example above.
Ok, but I wonder when the user would like to do TSO on tunnel packet, for this
offload -
would he need to do something differently from what he has to do now:
raise PKT_TX_TCP_SEG and related flags, raise appropriate PKT_TX_TUNNEL_* flag,
fill l2_len, l3_len, l4_len,tso_segsz,outer_l2_len,outer_l3_len?
Konstantin
>
> > >
> > > Signed-off-by: Xueming Li
> > > ---
> > > lib/librte_ether/rte_ethdev.h | 10 ++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > b/lib/librte_ether/rte_ethdev.h index 1a5b4cdc5..d8d08ccb2 100644
> > > --- a/lib/librte_ether/rte_ethdev.h
> > > +++ b/lib/librte_ether/rte_ethdev.h
> > > @@ -979,6 +979,16 @@ struct rte_eth_conf {
> > > * the same mempool and has refcnt = 1.
> > > */
> > > #define DEV_TX_OFFLOAD_SECURITY 0x0002
> > > +/**< Device supports generic tunnel checksum and TSO offloading.
> > > + * Checksum and TSO are done based on following mbuf fields:
> > > + * - Length of each header
> > > + * - Type of outer/inner L3 type, IPv4 or IPv6
> > > + * - Type of outer/inner L4 type, TCP or UDP.
> > > + * - PKT_TX_TUNNEL_VXLAN implies outer UDP type.
> > > + * - PKT_TX_TCP_SEG implies inner TCP type.
> > > + * Tunnel type is optional except PKT_TX_TUNNEL_VXLAN to hint outer UDP.
> > > + */
> > > +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO 0x0004
> > >
> > > /*
> > > * If new Tx offload capabilities are defined, they also must be
> > > --
> > > 2.13.3
Re: [dpdk-dev] [PATCH] net/tap: define __NR_bpf for powerpc
30/01/2018 09:51, Pascal Mazon:
> Acked-by: Pascal Mazon
>
> On 30/01/2018 08:05, Gowrishankar wrote:
> > From: Gowrishankar Muthukrishnan
> >
> > This patch defines __NR_bpf for powerpc architecture and hence,
> > fixes compiling tap driver for this architecture.
> >
> > Fixes: b02d85e1 ("net/tap: add eBPF API")
> >
> > Signed-off-by: Gowrishankar Muthukrishnan
> >
Applied, thanks
[dpdk-dev] [PATCH] net/mlx5: fix port stop by verify flows are still present
priv_flow_stop() may be called several times, in such situation flows are
already removed from the NIC and thus all associated objects are no present
in the flow object (ibv_flow, indirections tables, ).
Fixes: 71ee11c83bc4 ("net/mlx5: fix flow stop when flows are already stopped")
Fixes: 8086cf08b2f0 ("net/mlx5: handle RSS hash configuration in RSS flow")
Signed-off-by: Nelio Laranjeiro
---
drivers/net/mlx5/mlx5_flow.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index bf8eff8a5..1167c741c 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -2208,6 +2208,7 @@ priv_flow_stop(struct priv *priv, struct mlx5_flows *list)
TAILQ_FOREACH_REVERSE(flow, list, mlx5_flows, next) {
unsigned int i;
+ struct mlx5_ind_table_ibv *ind_tbl = NULL;
if (flow->drop) {
if (!flow->frxq[HASH_RXQ_ETH].ibv_flow)
@@ -2215,17 +2216,26 @@ priv_flow_stop(struct priv *priv, struct mlx5_flows
*list)
claim_zero(ibv_destroy_flow
(flow->frxq[HASH_RXQ_ETH].ibv_flow));
flow->frxq[HASH_RXQ_ETH].ibv_flow = NULL;
+ DEBUG("Flow %p removed", (void *)flow);
/* Next flow. */
continue;
}
+ /* Verify the flow has not already been cleaned. */
+ for (i = 0; i != hash_rxq_init_n; ++i) {
+ if (!flow->frxq[i].ibv_flow)
+ continue;
+ /*
+* Indirection table may be necessary to remove the
+* flags in the Rx queues.
+* This helps to speed-up the process by avoiding
+* another loop.
+*/
+ ind_tbl = flow->frxq[i].hrxq->ind_table;
+ break;
+ }
+ if (i == hash_rxq_init_n)
+ return;
if (flow->mark) {
- struct mlx5_ind_table_ibv *ind_tbl = NULL;
-
- for (i = 0; i != hash_rxq_init_n; ++i) {
- if (!flow->frxq[i].hrxq)
- continue;
- ind_tbl = flow->frxq[i].hrxq->ind_table;
- }
assert(ind_tbl);
for (i = 0; i != ind_tbl->queues_n; ++i)
(*priv->rxqs)[ind_tbl->queues[i]]->mark = 0;
--
2.11.0
Re: [dpdk-dev] [PATCH] doc: update procinfo for shared library
> added note category to procinfo guide, to intimate users in shared library > mode. > Procinfo requires same NIC libraries to probe the NIC devices as Primary > Application. > > Signed-off-by: Vipin Varghese > > doc/guides/tools/proc_info.rst | 6 ++ Acked-by: Marko Kovacevic
Re: [dpdk-dev] [PATCH v2] eal/ppc: fix compilation error with a broken else clause
30/01/2018 11:53, Gowrishankar:
> From: Gowrishankar Muthukrishnan
>
> Calling rte_smp_{w/r}mb macro expands into a compound block, which
> would break compiling a else clause following it, if that calling
> place has been terminated already with ";", as in below code.
> This patch adds { } around this macro to allow compiling else too.
>
> Fixes: d23a6bd04d ("eal/ppc: fix memory barrier for IBM POWER")
> Fixes: 05c3fd7110 ("eal/ppc: atomic operations for IBM Power")
>
> Signed-off-by: Gowrishankar Muthukrishnan
Applied, thanks
Re: [dpdk-dev] [PATCH v2 0/3] Increase default RX/TX ring sizes
On Mon, Jan 29, 2018 at 04:25:00PM +, Bruce Richardson wrote: > On Tue, Jan 16, 2018 at 02:13:19PM +0100, Adrien Mazarguil wrote: > > Hi Kevin, > > > > On Fri, Jan 12, 2018 at 10:48:43AM +, Kevin Laatz wrote: > > > Increasing the RX/TX default ring size to 1024/1024 to accommodate for > > > faster NICs. With the increase of number of PPS, a larger RX buffer is > > > required in order to avoid packet loss. While a ring size of 128 may be > > > large enough for 1G and possibly 10G NICs, this is not going to scale to > > > small packet sizes at 25G and 40G line rates. As we are increasing the RX > > > buffer size to 1024, we also need to increase the TX buffer size to ensure > > > that the TX side does not become the bottleneck. > > > > > > v2 > > > - fixed typos in commit messages > > > - fixed typo in Cc email address > > > > I agree with the above and this series contents but would like to comment > > anyway. > > > > Since typical TX/RX bursts are usually somewhere between 16 to 64 packets > > depending on the application, increasing ring size instead of burst size to > > keep up with packet rate may mean that software (PMD/application) is too > > slow on the RX side or hardware is too slow on the TX side (rings always > > full basically), and this is worked around by introducing latency to absorb > > packet loss. This is not necessarily a good trade-off. > > Well, if RX burst size of 64 is in use, the existing default of 128 is > definely very much too low - though point taken about slowness of RX. Agreed, I just wanted to stress that increasing TX/RX ring sizes may result in rings still full, but thanks to their FIFO nature, now with increased latency and resource consumption while still dropping packets in case of HW/SW slowness. This is not the proper workaround for such a scenario (not uncommon). > > Granted the most appropriate burst/ring/threshold values always depend on > > the application and underlying hardware, and each vendor is responsible for > > documenting ideal values for typical applications by providing performance > > results. > > I actually think it probably depends a lot on the NIC hardware in > question. What is the optimal size for an app with a 1G NIC will be > different for a 25G or 100G NIC. I therefore think in a future release > we should have an ethdev API to allow each driver to propose it's > recommended ring sizes. The app can perhaps provide a burst size hint as > parameter. What do you think? Sounds like a good idea. It could also be implemented without hurting any API by making 0 descriptors a special value for rte_eth_[rt]x_queue_setup(), so that being lazy translates to optimized defaults at the cost of some uncertainty regarding mbuf pool sizing. PMDs that do not implement this would reject queue creation as they likely already do. > > My concern is that modifying defaults makes performance comparison > > with past DPDK releases more difficult for existing automated tests > > that do not provide ring size and other parameters. There should an > > impact given that larger rings require more buffers, use more cache, > > and access more memory in general. > > > I'm actually not too concerned about that, as I would expect most > serious performance comparisons to be done with individually tuned rx > and tx ring size parameters. For zero loss throughput tests, larger ring > sizes are needed for any of the NIC I've tested anyway. > > Overall, I feel this change is long overdue. > > Series Acked-by: Bruce Richardson True, therefore: Acked-by: Adrien Mazarguil -- Adrien Mazarguil 6WIND
Re: [dpdk-dev] [PATCH] crypto/dpaa2_sec: fix build with GCC 6 or prior
30/01/2018 10:23, Hemant Agrawal:
> This patch fixes the compilation with compiler GCC < 7
>
> dpaa2_sec/hw/rta/operation_cmd.h:12:32: error: unknown option after
> ‘#pragma GCC diagnostic’ kind [-Werror=pragmas]
> #pragma GCC diagnostic ignored "-Wimplicit-fallthrough"
>
> Fixes: 2ab9a9483196 ("crypto/dpaa2_sec: fix build with GCC 7")
Sorry for having broken it with a quick fix yesterday.
> Signed-off-by: Hemant Agrawal
[...]
> +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION > 7)
> #pragma GCC diagnostic ignored "-Wimplicit-fallthrough"
> +#endif
I think it must be GCC_VERSION >= 7
Applied with this change, thanks
Re: [dpdk-dev] [PATCH 00/17] use SPDX tags on 6WIND copyrighted files
On 1/29/2018 6:41 PM, Olivier Matz wrote: This patchset updates the license on files that contain a 6WIND copyright to use a SPDX tag. It applies on master + https://dpdk.org/dev/patchwork/patch/34604/ For components I am maintaining (mempool, mbuf, cmdline, kvargs, net), I update all the *.[ch] files. For the other components, I only update files where there is a 6WIND copyright. The change is done automatically: the copyrights stay as is, except: - standardisation of the text for 6WIND copyright - as discussed with Bruce, Thomas, and Ferruh, the "All rights reserved" mention is removed if the copyright are from 6WIND, Intel or Mellanox. For each patch, the maintainers are Cc'd. The series LGTM. Bruce/Ferruh, please ack it from Intel side. Thomas, you may ack it from Mellanox side or someelse can ack the relevant patches form Mellanox side. Regards, Hemant
[dpdk-dev] [PATCH 2/2] app/testpmd: fix invalid port detach
Using registration to all ports includes also the ports which should not
be used by the application.
It is nice to print each port event by testpmd but in case of RMV
event, testpmd tries to detach the port and this case is problematic
when the port should not be used by the application.
Check the port validation before detach API calling.
Fixes: 4fb82244b394 ("app/testpmd: extend event printing")
Signed-off-by: Matan Azrad
---
app/test-pmd/testpmd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 5dc8cca..71b03d5 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2026,6 +2026,9 @@ struct pmd_test_command {
fflush(stdout);
}
+ if (port_id_is_invalid(port_id, DISABLED_WARN))
+ return 0;
+
switch (type) {
case RTE_ETH_EVENT_INTR_RMV:
if (rte_eal_alarm_set(10,
--
1.8.3.1
[dpdk-dev] [PATCH 1/2] app/testpmd: fix port validation
rte_eth_dev_is_valid_port() API validates each valid port from ethdev
point of view and may validate ports which should not be used by the
application.
Testpmd should use only the ports available through the
RTE_ETH_FOREACH_DEV iterator.
Replace rte_eth_dev_is_valid_port() usage by RTE_ETH_FOREACH_DEV
iterator usage for testpmd ports validation.
Fixes: 7d89b2610353 ("app/testpmd: use ethdev iterator to list devices")
Cc: sta...@dpdk.org
Signed-off-by: Matan Azrad
---
app/test-pmd/config.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 957b820..8c920a2 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -756,11 +756,14 @@ struct rss_type_info {
int
port_id_is_invalid(portid_t port_id, enum print_warning warning)
{
+ uint16_t pid;
+
if (port_id == (portid_t)RTE_PORT_ALL)
return 0;
- if (rte_eth_dev_is_valid_port(port_id))
- return 0;
+ RTE_ETH_FOREACH_DEV(pid)
+ if (port_id == pid)
+ return 0;
if (warning == ENABLED_WARN)
printf("Invalid port %d\n", port_id);
--
1.8.3.1
[dpdk-dev] [PATCH] test/test: add new tests in 18.02-rc2 to meson build
Signed-off-by: Bruce Richardson
---
test/test/meson.build | 6 ++
1 file changed, 6 insertions(+)
diff --git a/test/test/meson.build b/test/test/meson.build
index b8bae5afa..d5b768b9d 100644
--- a/test/test/meson.build
+++ b/test/test/meson.build
@@ -7,6 +7,7 @@ test_sources = files('commands.c',
'test_acl.c',
'test_alarm.c',
'test_atomic.c',
+ 'test_barrier.c',
'test_byteorder.c',
'test_cmdline.c',
'test_cmdline_cirbuf.c',
@@ -70,6 +71,8 @@ test_sources = files('commands.c',
'test_power_acpi_cpufreq.c',
'test_power_kvm_vm.c',
'test_prefetch.c',
+ 'test_reciprocal_division.c',
+ 'test_reciprocal_division_perf.c',
'test_red.c',
'test_reorder.c',
'test_ring.c',
@@ -118,6 +121,7 @@ test_names = [
'acl_autotest',
'alarm_autotest',
'atomic_autotest',
+ 'barrier_autotest',
'byteorder_autotest',
'cmdline_autotest',
'common_autotest',
@@ -184,6 +188,8 @@ test_names = [
'power_autotest',
'power_kvm_vm_autotest',
'prefetch_autotest',
+ 'reciprocal_division',
+ 'reciprocal_division_perf',
'red_all',
'red_autotest',
'red_perf',
--
2.14.3
Re: [dpdk-dev] [PATCH 5/5] config: enable dpaaX drivers compilation for ARMv8
On 1/30/2018 3:03 PM, Hemant Agrawal wrote: On 1/30/2018 2:12 PM, Hemant Agrawal wrote: Hi Jerin, On 1/25/2018 4:51 PM, Jerin Jacob wrote: -Original Message- Date: Thu, 25 Jan 2018 15:23:31 +0530 From: Hemant Agrawal To: dev@dpdk.org CC: jerin.ja...@caviumnetworks.com Subject: [PATCH 5/5] config: enable dpaaX drivers compilation for ARMv8 X-Mailer: git-send-email 2.7.4 This patch enables the NXP DPAA & DPAA2 drivers for ARMV8 targets. They can be used with standard armv8 config with command line mempool argument or newly introduced platform mempool internal registration mechanism. Note that the dpaa(x) specific config files are still preserved to continue customer support. They also contain some of the ARM performance tuning flags. e.g the default ARM cache size of 128 is not optimal for NXP platforms. However, these configs will eventually be removed once a dynamic mechanisms are developed to detect the performance settings. Signed-off-by: Hemant Agrawal --- config/common_armv8a_linuxapp | 58 +++ 1 file changed, 58 insertions(+) diff --git a/config/common_armv8a_linuxapp b/config/common_armv8a_linuxapp index 790e716..572db11 100644 --- a/config/common_armv8a_linuxapp +++ b/config/common_armv8a_linuxapp @@ -34,3 +34,61 @@ CONFIG_RTE_LIBRTE_SFC_EFX_PMD=n CONFIG_RTE_LIBRTE_AVP_PMD=n CONFIG_RTE_SCHED_VECTOR=n + +# +# ARMv8 Specific driver compilation flags +# Will it be better if it is enabled in generic config? If you have any assembly code then you just stub it for non arm64. Since these are integrate controllers, I guess, there is no issue in stubbing the non arm64 specific things. I believe in that way, it will be maintainable. i.e there will not any case where arm64 config failing but not non arm64 configs. On the upside, The common code(ethdev, cryptodev) changes will be build against your driver by all the developers. It is a good suggestion and we did attempted it and realized that the amount of changes required are more than expected. We will attempt it for next release. However, if you are ok, please ack it in ARM for now. I take it back. I figured out easy changes to make it compile for x86 as well. We will submit the v2. I think, we need to leave this patch as it is for this release. We are running into freebsd issue w.r.t common_base and 32 bit issues with common_linuxapp. We will do these changes incrementally in next release.
Re: [dpdk-dev] [PATCH v7 0/2] generic channel for multi-process communication
30/01/2018 07:58, Jianfeng Tan: > This patchset adds a generic channel for multi-process (primary/secondary) > communication. Applied, thanks
Re: [dpdk-dev] [PATCH RFC 1/2] vhost: make capabilities configurable
Hi Zhihong On 12/23/2017 04:36 AM, Zhihong Wang wrote: This patch makes vhost device capabilities configurable to adopt various engines. Such capabilities include supported features, protocol features, queue number. APIs are introduced to let app configure these capabilities. Why does the vDPA driver need to mask protocol features? Maxime
Re: [dpdk-dev] [PATCH] drivers: improve pmdinfo generation when using meson
On Thu, Jan 25, 2018 at 11:14:43AM +, Bruce Richardson wrote: > Since meson 0.44, changing any file inside a PMD directory (quite > correctly) triggers a full re-run of meson on build, rather than an > incremental build as with earlier versions. This rerun is needed because > we use "grep" in meson to search for files on which to run pmdinfogen, and > changing any of those files means that grep and, therefore meson, needs to > be rerun. [Previous versions of meson did not track this dependency on the > grep command, and so did incremental builds only.] > > If, however, we take advantage of pmdinfogen's ability to use stdin and > stdout instead of files, we can instead use a shell script to process an > entire static archive and generate a single .c file from it. This > eliminates the need for grep, and means that changes to a PMD file only > need an incremental build - a significant time saving. > > Signed-off-by: Bruce Richardson > --- Applied to dpdk-next-build /Bruce
Re: [dpdk-dev] [PATCH 00/17] use SPDX tags on 6WIND copyrighted files
On Tue, Jan 30, 2018 at 07:36:30PM +0530, Hemant Agrawal wrote: > On 1/29/2018 6:41 PM, Olivier Matz wrote: > > This patchset updates the license on files that contain a 6WIND copyright > > to use a SPDX tag. > > It applies on master + https://dpdk.org/dev/patchwork/patch/34604/ > > > > For components I am maintaining (mempool, mbuf, cmdline, kvargs, net), I > > update all the *.[ch] files. For the other components, I only update > > files where there is a 6WIND copyright. > > > > The change is done automatically: the copyrights stay as is, except: > > - standardisation of the text for 6WIND copyright > > - as discussed with Bruce, Thomas, and Ferruh, the "All rights reserved" > >mention is removed if the copyright are from 6WIND, Intel or Mellanox. > > > > For each patch, the maintainers are Cc'd. > > The series LGTM. > > Bruce/Ferruh, please ack it from Intel side. > Acked-by: Bruce Richardson
[dpdk-dev] [PATCH v2] config: enable dpaaX drivers compilation for ARMv8
This patch enables the NXP DPAA & DPAA2 drivers for ARMV8 targets. They can be used with standard armv8 config with command line mempool argument or newly introduced platform mempool internal registration mechanism. Note that the dpaa(x) specific config files are still preserved to continue customer support. They also contain some of the ARM performance tuning flags. e.g the default ARM cache size of 128 is not optimal for NXP platforms. However, these configs will eventually be removed once a dynamic mechanisms are developed to detect the performance settings. Signed-off-by: Hemant Agrawal --- config/common_armv8a_linuxapp | 58 +++ config/defconfig_arm64-dpaa-linuxapp-gcc | 20 --- config/defconfig_arm64-dpaa2-linuxapp-gcc | 19 -- 3 files changed, 58 insertions(+), 39 deletions(-) diff --git a/config/common_armv8a_linuxapp b/config/common_armv8a_linuxapp index 111c005..507b28a 100644 --- a/config/common_armv8a_linuxapp +++ b/config/common_armv8a_linuxapp @@ -36,3 +36,61 @@ CONFIG_RTE_LIBRTE_SFC_EFX_PMD=n CONFIG_RTE_LIBRTE_AVP_PMD=n CONFIG_RTE_SCHED_VECTOR=n + +# +# ARMv8 Specific driver compilation flags +# + +# +# Compile NXP DPAA Bus +# +CONFIG_RTE_LIBRTE_DPAA_BUS=y +CONFIG_RTE_LIBRTE_DPAA_HWDEBUG=n + +# +# Compile NXP DPAA2 FSL-MC Bus +# +CONFIG_RTE_LIBRTE_FSLMC_BUS=y + +# +# Compile NXP DPAA Mempool +# +CONFIG_RTE_LIBRTE_DPAA_MEMPOOL=y + +# +# Compile NXP DPAA2 Mempool +# +CONFIG_RTE_LIBRTE_DPAA2_MEMPOOL=y + +# +# Compile bust-oriented NXP DPAA PMD +# +CONFIG_RTE_LIBRTE_DPAA_PMD=y + +# +# Compile burst-oriented NXP DPAA2 PMD driver +# +CONFIG_RTE_LIBRTE_DPAA2_PMD=y + +# +# Compile schedule-oriented NXP DPAA Event Dev PMD +# +CONFIG_RTE_LIBRTE_PMD_DPAA_EVENTDEV=y + +# +# Compile schedule-oriented NXP DPAA2 EVENTDEV driver +# +CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV=y + +# +# Compile NXP DPAA caam - crypto driver +# +CONFIG_RTE_LIBRTE_PMD_DPAA_SEC=y +CONFIG_RTE_LIBRTE_DPAA_MAX_CRYPTODEV=4 +CONFIG_RTE_DPAA_SEC_PMD_MAX_NB_SESSIONS=2048 + +# +# Compile NXP DPAA2 crypto sec driver for CAAM HW +# +CONFIG_RTE_LIBRTE_PMD_DPAA2_SEC=y +CONFIG_RTE_DPAA2_SEC_PMD_MAX_NB_SESSIONS=2048 diff --git a/config/defconfig_arm64-dpaa-linuxapp-gcc b/config/defconfig_arm64-dpaa-linuxapp-gcc index ab9e67d..52bfc79 100644 --- a/config/defconfig_arm64-dpaa-linuxapp-gcc +++ b/config/defconfig_arm64-dpaa-linuxapp-gcc @@ -19,32 +19,12 @@ CONFIG_RTE_CACHE_LINE_SIZE=64 CONFIG_RTE_PKTMBUF_HEADROOM=128 # NXP DPAA Bus -CONFIG_RTE_LIBRTE_DPAA_BUS=y CONFIG_RTE_LIBRTE_DPAA_DEBUG_DRIVER=n CONFIG_RTE_LIBRTE_DPAA_HWDEBUG=n -# NXP DPAA Mempool -CONFIG_RTE_LIBRTE_DPAA_MEMPOOL=y - -# Compile software NXP DPAA PMD -CONFIG_RTE_LIBRTE_DPAA_PMD=y - -# Compile software NXP DPAA Event Dev PMD -CONFIG_RTE_LIBRTE_PMD_DPAA_EVENTDEV=y - # # FSL DPAA caam - crypto driver # -CONFIG_RTE_LIBRTE_PMD_DPAA_SEC=y CONFIG_RTE_LIBRTE_DPAA_SEC_DEBUG_INIT=n CONFIG_RTE_LIBRTE_DPAA_SEC_DEBUG_DRIVER=n CONFIG_RTE_LIBRTE_DPAA_SEC_DEBUG_RX=n - -# DPAA CAAM driver instances -CONFIG_RTE_LIBRTE_DPAA_MAX_CRYPTODEV=4 - -# -# Number of sessions to create in the session memory pool -# on a single DPAA SEC device. -# -CONFIG_RTE_DPAA_SEC_PMD_MAX_NB_SESSIONS=2048 diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc b/config/defconfig_arm64-dpaa2-linuxapp-gcc index 5d4437c..d4f266a 100644 --- a/config/defconfig_arm64-dpaa2-linuxapp-gcc +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc @@ -25,18 +25,11 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n # # Compile Support Libraries for DPAA2 # -CONFIG_RTE_LIBRTE_DPAA2_MEMPOOL=y CONFIG_RTE_LIBRTE_DPAA2_USE_PHYS_IOVA=n # -# Compile NXP DPAA2 FSL-MC Bus -# -CONFIG_RTE_LIBRTE_FSLMC_BUS=y - -# # Compile burst-oriented NXP DPAA2 PMD driver # -CONFIG_RTE_LIBRTE_DPAA2_PMD=y CONFIG_RTE_LIBRTE_DPAA2_DEBUG_INIT=n CONFIG_RTE_LIBRTE_DPAA2_DEBUG_DRIVER=n CONFIG_RTE_LIBRTE_DPAA2_DEBUG_RX=n @@ -46,18 +39,6 @@ CONFIG_RTE_LIBRTE_DPAA2_DEBUG_TX_FREE=n # # Compile NXP DPAA2 crypto sec driver for CAAM HW # -CONFIG_RTE_LIBRTE_PMD_DPAA2_SEC=y CONFIG_RTE_LIBRTE_DPAA2_SEC_DEBUG_INIT=n CONFIG_RTE_LIBRTE_DPAA2_SEC_DEBUG_DRIVER=n CONFIG_RTE_LIBRTE_DPAA2_SEC_DEBUG_RX=n - -# -# Number of sessions to create in the session memory pool -# on a single DPAA2 SEC device. -# -CONFIG_RTE_DPAA2_SEC_PMD_MAX_NB_SESSIONS=2048 - -# -# Compile schedule-oriented NXP DPAA2 EVENTDEV driver -# -CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV=y -- 2.7.4
[dpdk-dev] [PATCH] net/dpaa2: fix the err with testpmd in Tx only mode
Fixes: 043b36f621dd ("net/dpaa2: support more than 16 burst size in Rx")
Signed-off-by: Hemant Agrawal
---
*This patch is applicable on top of next-net*
drivers/net/dpaa2/dpaa2_rxtx.c | 126 +++--
1 file changed, 33 insertions(+), 93 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_rxtx.c b/drivers/net/dpaa2/dpaa2_rxtx.c
index 3d45669..46d633f 100644
--- a/drivers/net/dpaa2/dpaa2_rxtx.c
+++ b/drivers/net/dpaa2/dpaa2_rxtx.c
@@ -473,10 +473,10 @@ dpaa2_dev_prefetch_rx(void *queue, struct rte_mbuf
**bufs, uint16_t nb_pkts)
{
/* Function receive frames for a given device and VQ*/
struct dpaa2_queue *dpaa2_q = (struct dpaa2_queue *)queue;
- struct qbman_result *dq_storage, *dq_storage1 = 0;
+ struct qbman_result *dq_storage, *dq_storage1 = NULL;
uint32_t fqid = dpaa2_q->fqid;
- int ret, num_rx = 0, next_pull = 0, num_pulled, num_to_pull;
- uint8_t pending, is_repeat, status;
+ int ret, num_rx = 0;
+ uint8_t pending, status;
struct qbman_swp *swp;
const struct qbman_fd *fd, *next_fd;
struct qbman_pull_desc pulldesc;
@@ -491,19 +491,6 @@ dpaa2_dev_prefetch_rx(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
}
}
swp = DPAA2_PER_LCORE_PORTAL;
-
- /* if the original request for this q was from another portal */
- if (unlikely(DPAA2_PER_LCORE_DPIO->index !=
- q_storage->active_dpio_id)) {
- if (check_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index)) {
- while (!qbman_check_command_complete(get_swp_active_dqs
- (DPAA2_PER_LCORE_DPIO->index)))
- ;
- clear_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index);
- }
- q_storage->active_dpio_id = DPAA2_PER_LCORE_DPIO->index;
- }
-
if (unlikely(!q_storage->active_dqs)) {
q_storage->toggle = 0;
dq_storage = q_storage->dq_storage[q_storage->toggle];
@@ -515,27 +502,41 @@ dpaa2_dev_prefetch_rx(void *queue, struct rte_mbuf
**bufs, uint16_t nb_pkts)
qbman_pull_desc_set_fq(&pulldesc, fqid);
qbman_pull_desc_set_storage(&pulldesc, dq_storage,
(dma_addr_t)(DPAA2_VADDR_TO_IOVA(dq_storage)), 1);
+ if (check_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index)) {
+ while (!qbman_check_command_complete(
+ get_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index)))
+ ;
+ clear_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index);
+ }
while (1) {
if (qbman_swp_pull(swp, &pulldesc)) {
- PMD_RX_LOG(WARNING,
- "VDQ command not issued.QBMAN busy\n");
+ PMD_RX_LOG(WARNING, "VDQ command is not issued."
+ "QBMAN is busy\n");
/* Portal was busy, try again */
continue;
}
break;
}
q_storage->active_dqs = dq_storage;
+ q_storage->active_dpio_id = DPAA2_PER_LCORE_DPIO->index;
set_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index, dq_storage);
}
- /* pkt to pull in current pull request */
- num_to_pull = q_storage->last_num_pkts;
+ dq_storage = q_storage->active_dqs;
+ rte_prefetch0((void *)((uint64_t)(dq_storage)));
+ rte_prefetch0((void *)((uint64_t)(dq_storage + 1)));
- /* Number of packet requested is more than current pull request */
- if (nb_pkts > num_to_pull)
- next_pull = nb_pkts - num_to_pull;
+ /* Prepare next pull descriptor. This will give space for the
+ * prefething done on DQRR entries
+ */
+ q_storage->toggle ^= 1;
+ dq_storage1 = q_storage->dq_storage[q_storage->toggle];
+ qbman_pull_desc_clear(&pulldesc);
+ qbman_pull_desc_set_numframes(&pulldesc, DPAA2_DQRR_RING_SIZE);
+ qbman_pull_desc_set_fq(&pulldesc, fqid);
+ qbman_pull_desc_set_storage(&pulldesc, dq_storage1,
+ (dma_addr_t)(DPAA2_VADDR_TO_IOVA(dq_storage1)), 1);
- dq_storage = q_storage->active_dqs;
/* Check if the previous issued command is completed.
* Also seems like the SWP is shared between the Ethernet Driver
* and the SEC driver.
@@ -545,45 +546,6 @@ dpaa2_dev_prefetch_rx(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
if (dq_storage == get_swp_active_dqs(q_storage->active_dpio_id))
clear_swp_active_dqs(q_storage->active_dpio_id);
-repeat:
- is_repeat = 0;
-
- /* issue the deq command one more time to get another set of packets */
- if (next_
Re: [dpdk-dev] [PATCH] test/test: add new tests in 18.02-rc2 to meson build
On Tue, 2018-01-30 at 14:41 +, Bruce Richardson wrote: > Signed-off-by: Bruce Richardson > --- > test/test/meson.build | 6 ++ > 1 file changed, 6 insertions(+) Reviewed-by: Luca Boccassi LGTM! -- Kind regards, Luca Boccassi
[dpdk-dev] [PATCH v3 10/11] maintainers: claim ownership of rawdev
Signed-off-by: Shreyansh Jain --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5afa9cc6e..e422c871c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -306,6 +306,12 @@ F: lib/librte_eventdev/*eth_rx_adapter* F: test/test/test_event_eth_rx_adapter.c F: doc/guides/prog_guide/event_ethernet_rx_adapter.rst +Rawdev API - EXPERIMENTAL +M: Shreyansh Jain +M: Hemant Agrawal +F: lib/librte_rawdev/* +F: test/test/test_rawdev.c +F: drivers/rawdev/skeleton/* Bus Drivers --- -- 2.14.1
[dpdk-dev] [PATCH v3 06/11] rawdev: add self test support
Signed-off-by: Shreyansh Jain
---
lib/librte_rawdev/rte_rawdev.c | 10 ++
lib/librte_rawdev/rte_rawdev.h | 13 +
lib/librte_rawdev/rte_rawdev_pmd.h | 11 +++
lib/librte_rawdev/rte_rawdev_version.map | 1 +
4 files changed, 35 insertions(+)
diff --git a/lib/librte_rawdev/rte_rawdev.c b/lib/librte_rawdev/rte_rawdev.c
index b52293c47..d314ef96b 100644
--- a/lib/librte_rawdev/rte_rawdev.c
+++ b/lib/librte_rawdev/rte_rawdev.c
@@ -363,6 +363,16 @@ rte_rawdev_firmware_unload(uint16_t dev_id)
return (*dev->dev_ops->firmware_unload)(dev);
}
+int __rte_experimental
+rte_rawdev_selftest(uint16_t dev_id)
+{
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ struct rte_rawdev *dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_selftest, -ENOTSUP);
+ return (*dev->dev_ops->dev_selftest)();
+}
+
int __rte_experimental
rte_rawdev_start(uint16_t dev_id)
{
diff --git a/lib/librte_rawdev/rte_rawdev.h b/lib/librte_rawdev/rte_rawdev.h
index 8eab3974f..5946ea67c 100644
--- a/lib/librte_rawdev/rte_rawdev.h
+++ b/lib/librte_rawdev/rte_rawdev.h
@@ -577,6 +577,19 @@ rte_rawdev_firmware_load(uint16_t dev_id, rte_rawdev_obj_t
firmware_image);
int __rte_experimental
rte_rawdev_firmware_unload(uint16_t dev_id);
+/**
+ * Trigger the rawdev self test.
+ *
+ * @param dev_id
+ * The identifier of the device
+ * @return
+ * - 0: Selftest successful
+ * - -ENOTSUP if the device doesn't support selftest
+ * - other values < 0 on failure.
+ */
+int __rte_experimental
+rte_rawdev_selftest(uint16_t dev_id);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_rawdev/rte_rawdev_pmd.h
b/lib/librte_rawdev/rte_rawdev_pmd.h
index f74bf171a..eb8f68b8b 100644
--- a/lib/librte_rawdev/rte_rawdev_pmd.h
+++ b/lib/librte_rawdev/rte_rawdev_pmd.h
@@ -475,6 +475,14 @@ typedef int (*rawdev_firmware_load_t)(struct rte_rawdev
*dev,
*/
typedef int (*rawdev_firmware_unload_t)(struct rte_rawdev *dev);
+/**
+ * Start rawdev selftest
+ *
+ * @return
+ * Return 0 on success
+ */
+typedef int (*rawdev_selftest_t)(void);
+
/** Rawdevice operations function pointer table */
struct rte_rawdev_ops {
/**< Get device info. */
@@ -528,6 +536,9 @@ struct rte_rawdev_ops {
rawdev_firmware_load_t firmware_load;
/**< Unload firmware */
rawdev_firmware_unload_t firmware_unload;
+
+ /**< Device selftest function */
+ rawdev_selftest_t dev_selftest;
};
/**
diff --git a/lib/librte_rawdev/rte_rawdev_version.map
b/lib/librte_rawdev/rte_rawdev_version.map
index 8de9abdc4..af4465e26 100644
--- a/lib/librte_rawdev/rte_rawdev_version.map
+++ b/lib/librte_rawdev/rte_rawdev_version.map
@@ -19,6 +19,7 @@ EXPERIMENTAL {
rte_rawdev_queue_setup;
rte_rawdev_queue_release;
rte_rawdev_reset;
+ rte_rawdev_selftest;
rte_rawdev_set_attr;
rte_rawdev_socket_id;
rte_rawdev_start;
--
2.14.1
[dpdk-dev] [PATCH 3/3] bus/fslmc: fix incorrect string compare length
Fixes: 828d51d8fc3e ("bus/fslmc: refactor scan and probe functions")
Cc: shreyansh.j...@nxp.com
Incorrect string length was being compared while scanning DPCI object.
Signed-off-by: Shreyansh Jain
---
drivers/bus/fslmc/fslmc_bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/fslmc/fslmc_bus.c b/drivers/bus/fslmc/fslmc_bus.c
index e9acd3588..5ee0beb85 100644
--- a/drivers/bus/fslmc/fslmc_bus.c
+++ b/drivers/bus/fslmc/fslmc_bus.c
@@ -141,7 +141,7 @@ scan_one_fslmc_device(char *dev_name)
dev->dev_type = DPAA2_BPOOL;
else if (!strncmp("dpio", t_ptr, 4))
dev->dev_type = DPAA2_IO;
- else if (!strncmp("dpci", t_ptr, 5))
+ else if (!strncmp("dpci", t_ptr, 4))
dev->dev_type = DPAA2_CI;
else if (!strncmp("dpmcp", t_ptr, 5))
dev->dev_type = DPAA2_MPORTAL;
--
2.14.1
[dpdk-dev] [PATCH v3 11/11] doc: add rawdev library page
Signed-off-by: Shreyansh Jain --- doc/guides/prog_guide/index.rst | 1 + doc/guides/prog_guide/rawdev_lib.rst | 83 2 files changed, 84 insertions(+) create mode 100644 doc/guides/prog_guide/rawdev_lib.rst diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst index af5f65a33..beead3105 100644 --- a/doc/guides/prog_guide/index.rst +++ b/doc/guides/prog_guide/index.rst @@ -75,6 +75,7 @@ Programmer's Guide vhost_lib metrics_lib port_hotplug_framework +rawdev_lib source_org dev_kit_build_system dev_kit_root_make_help diff --git a/doc/guides/prog_guide/rawdev_lib.rst b/doc/guides/prog_guide/rawdev_lib.rst new file mode 100644 index 0..d21d284ca --- /dev/null +++ b/doc/guides/prog_guide/rawdev_lib.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: BSD-3-Clause +Copyright 2018 NXP + +Rawdevice Library += + +Introduction + + +In terms of device flavor (type) support, DPDK currently has ethernet +(lib_ether), cryptodev (libcryptodev), eventdev (libeventdev) and vdev +(virtual device) support. + +For a new type of device, for example an accelerator, there are not many +options except: +1. create another lib/librte_MySpecialDev, driver/MySpecialDrv and use it +through Bus/PMD model. +2. Or, create a vdev and implement necessary custom APIs which are directly +exposed from driver layer. However this may still require changes in bus code +in DPDK. + +The DPDK Rawdev library is an abstraction that provides the DPDK framework a +way to manage such devices in a generic manner without expecting changes to +library or EAL for each device type. This library provides a generic set of +operations and APIs for framework and Applications to use, respectively, for +interfacing with such type of devices. + +Design +-- + +Key factors guiding design of the Rawdevice library: + +1. Following are some generic operations which can be treated as applicable + to a large subset of device types. None of the operations are mandatory to + be implemented by a driver. Application should also be design for proper + handling for unsupported APIs. + + * Device Start/Stop - In some cases, 'reset' might also be required which +has different semantics than a start-stop-start cycle. + * Configuration - Device, Queue or any other sub-system configuration + * I/O - Sending a series of buffers which can enclose any arbitrary data + * Statistics - Fetch arbitrary device statistics + * Firmware Management - Firmware load/unload/status + +2. Application API should be able to pass along arbitrary state information + to/fro device driver. This can be achieved by maintaining context + information through opaque data or pointers. + +Figure below outlines the layout of the rawdevice library and device vis-a-vis +other well known device types like eth and crypto: + +.. code-block:: console + + +---+ + |Application(s) | + +--.+ +| +| + +--'+ + | DPDK Framework (APIs) | + +--||-|-+ + / \ \ +(crypto ops) (eth ops) (rawdev ops)++ +/ \ \ |DrvA| + +-'---++`++---'-+ ++ + | crypto || ethdev || raw | + +--/--++---/-++/+ ++ + /\__/\ / ..|DrvB| + / \ /\/ ../\ ++ + ++ ++++ +++==/=+ ```Bus Probe + |DevA| |DevB||DevC| |DevD||DevF| + ++ ++++ ++++ +| || | | + ``|``||``|`|Bus Scan + (PCI) | (PCI) (PCI)(PCI) + (BusA) + + * It is assumed above that DrvB is a PCI type driver which registers itself + with PCI Bus + * Thereafter, when the PCI scan is done, during probe DrvB would match the + rawdev DevF ID and take control of device + * Applications can then continue using the device through rawdev API + interfaces -- 2.14.1
[dpdk-dev] [PATCH 1/3] config: change dpaa2 mbuf headroom size to 128
From: Hemant Agrawal Signed-off-by: Hemant Agrawal --- config/defconfig_arm64-dpaa2-linuxapp-gcc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc b/config/defconfig_arm64-dpaa2-linuxapp-gcc index 5d4437ca5..aa135caab 100644 --- a/config/defconfig_arm64-dpaa2-linuxapp-gcc +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc @@ -16,7 +16,7 @@ CONFIG_RTE_MAX_LCORE=16 CONFIG_RTE_MAX_NUMA_NODES=1 CONFIG_RTE_CACHE_LINE_SIZE=64 -CONFIG_RTE_PKTMBUF_HEADROOM=256 +CONFIG_RTE_PKTMBUF_HEADROOM=128 # Doesn't support NUMA CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n -- 2.14.1
[dpdk-dev] [PATCH v3 05/11] rawdev: support for firmware management
Some generic operations for firmware management can loading, unloading,
starting, stopping and querying firmware of a device.
This patch adds support for such generic operations.
Signed-off-by: Shreyansh Jain
---
lib/librte_rawdev/rte_rawdev.c | 43
lib/librte_rawdev/rte_rawdev.h | 64 +
lib/librte_rawdev/rte_rawdev_pmd.h | 70
lib/librte_rawdev/rte_rawdev_version.map | 4 ++
4 files changed, 181 insertions(+)
diff --git a/lib/librte_rawdev/rte_rawdev.c b/lib/librte_rawdev/rte_rawdev.c
index d6c284554..b52293c47 100644
--- a/lib/librte_rawdev/rte_rawdev.c
+++ b/lib/librte_rawdev/rte_rawdev.c
@@ -320,6 +320,49 @@ rte_rawdev_xstats_reset(uint16_t dev_id,
return (*dev->dev_ops->xstats_reset)(dev, ids, nb_ids);
}
+int __rte_experimental
+rte_rawdev_firmware_status_get(uint16_t dev_id, rte_rawdev_obj_t status_info)
+{
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ struct rte_rawdev *dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->firmware_status_get, -ENOTSUP);
+ return (*dev->dev_ops->firmware_status_get)(dev, status_info);
+}
+
+int __rte_experimental
+rte_rawdev_firmware_version_get(uint16_t dev_id, rte_rawdev_obj_t version_info)
+{
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ struct rte_rawdev *dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->firmware_version_get, -ENOTSUP);
+ return (*dev->dev_ops->firmware_version_get)(dev, version_info);
+}
+
+int __rte_experimental
+rte_rawdev_firmware_load(uint16_t dev_id, rte_rawdev_obj_t firmware_image)
+{
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ struct rte_rawdev *dev = &rte_rawdevs[dev_id];
+
+ if (!firmware_image)
+ return -EINVAL;
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->firmware_load, -ENOTSUP);
+ return (*dev->dev_ops->firmware_load)(dev, firmware_image);
+}
+
+int __rte_experimental
+rte_rawdev_firmware_unload(uint16_t dev_id)
+{
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ struct rte_rawdev *dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->firmware_load, -ENOTSUP);
+ return (*dev->dev_ops->firmware_unload)(dev);
+}
+
int __rte_experimental
rte_rawdev_start(uint16_t dev_id)
{
diff --git a/lib/librte_rawdev/rte_rawdev.h b/lib/librte_rawdev/rte_rawdev.h
index 8e3d72273..8eab3974f 100644
--- a/lib/librte_rawdev/rte_rawdev.h
+++ b/lib/librte_rawdev/rte_rawdev.h
@@ -513,6 +513,70 @@ rte_rawdev_xstats_reset(uint16_t dev_id,
const uint32_t ids[],
uint32_t nb_ids);
+/**
+ * Get Firmware status of the device..
+ * Returns a memory allocated by driver/implementation containing status
+ * information block. It is responsibility of caller to release the buffer.
+ *
+ * @param dev_id
+ * Raw device identifier
+ * @param status_info
+ * Pointer to status information area. Caller is responsible for releasing
+ * the memory associated.
+ * @return
+ * 0 for success,
+ * !0 for failure, `status_info` argument state is undefined
+ */
+int __rte_experimental
+rte_rawdev_firmware_status_get(uint16_t dev_id,
+ rte_rawdev_obj_t status_info);
+
+/**
+ * Get Firmware version of the device.
+ * Returns a memory allocated by driver/implementation containing version
+ * information block. It is responsibility of caller to release the buffer.
+ *
+ * @param dev_id
+ * Raw device identifier
+ * @param version_info
+ * Pointer to version information area. Caller is responsible for releasing
+ * the memory associated.
+ * @return
+ * 0 for success,
+ * !0 for failure, `version_info` argument state is undefined
+ */
+int __rte_experimental
+rte_rawdev_firmware_version_get(uint16_t dev_id,
+ rte_rawdev_obj_t version_info);
+
+/**
+ * Load firmware on the device.
+ * TODO: In future, methods like directly flashing from file too can be
+ * supported.
+ *
+ * @param dev_id
+ * Raw device identifier
+ * @param firmware_image
+ * Pointer to buffer containing image binary data
+ * @return
+ * 0 for successful load
+ * !0 for failure to load the provided image, or image incorrect.
+ */
+int __rte_experimental
+rte_rawdev_firmware_load(uint16_t dev_id, rte_rawdev_obj_t firmware_image);
+
+/**
+ * Unload firmware from the device.
+ *
+ * @param dev_id
+ * Raw device identifiers
+ * @return
+ * 0 for successful Unload
+ * !0 for failure in unloading
+ */
+int __rte_experimental
+rte_rawdev_firmware_unload(uint16_t dev_id);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_rawdev/rte_rawdev_pmd.h
b/lib/librte_rawdev/rte_rawdev_pmd.h
index 2ef380988..f74bf171a 100644
--- a/lib/librte_rawdev/rte_rawdev_pmd.h
+++ b/lib/librte_rawdev/rte_rawdev_pmd.h
@@ -414,6 +414,67 @@ typedef int (*rawdev_xstats_get_names_t)
[dpdk-dev] [PATCH 2/3] net/dpaa2: fix the bpid offset
From: Hemant Agrawal
Fixes: 774e9ea91992 ("net/dpaa2: add support for multi seg buffers")
Cc: hemant.agra...@nxp.com
Fixes: d2ef05d5c13e ("net/dpaa2: optimize Rx/Tx path")
Cc: hemant.agra...@nxp.com
Signed-off-by: Hemant Agrawal
---
drivers/net/dpaa2/dpaa2_rxtx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_rxtx.c b/drivers/net/dpaa2/dpaa2_rxtx.c
index 3d4566988..898cf3bd6 100644
--- a/drivers/net/dpaa2/dpaa2_rxtx.c
+++ b/drivers/net/dpaa2/dpaa2_rxtx.c
@@ -334,8 +334,8 @@ eth_mbuf_to_sg_fd(struct rte_mbuf *mbuf,
DPAA2_SET_FD_ADDR(fd, DPAA2_MBUF_VADDR_TO_IOVA(temp));
DPAA2_SET_FD_LEN(fd, mbuf->pkt_len);
+ DPAA2_SET_ONLY_FD_BPID(fd, bpid);
DPAA2_SET_FD_OFFSET(fd, temp->data_off);
- DPAA2_SET_FD_BPID(fd, bpid);
DPAA2_SET_FD_ASAL(fd, DPAA2_ASAL_VAL);
DPAA2_FD_SET_FORMAT(fd, qbman_fd_sg);
/*Set Scatter gather table and Scatter gather entries*/
@@ -776,7 +776,6 @@ dpaa2_dev_tx(void *queue, struct rte_mbuf **bufs, uint16_t
nb_pkts)
(*bufs)->seqn = DPAA2_INVALID_MBUF_SEQN;
}
- fd_arr[loop].simple.bpid_offset = 0;
fd_arr[loop].simple.frc = 0;
DPAA2_RESET_FD_CTRL((&fd_arr[loop]));
DPAA2_SET_FD_FLC((&fd_arr[loop]), NULL);
--
2.14.1
[dpdk-dev] [PATCH v3 02/11] rawdev: add attribute get and set support
A rawdevice can have various attributes. This patch introduce support
for transparently setting attribute value or getting current attribute
state. This is done by allowing an opaque set of key and value to be
passed through rawdev library.
Signed-off-by: Shreyansh Jain
---
lib/librte_rawdev/rte_rawdev.c | 28 +
lib/librte_rawdev/rte_rawdev.h | 43
lib/librte_rawdev/rte_rawdev_pmd.h | 42 +++
lib/librte_rawdev/rte_rawdev_version.map | 2 ++
4 files changed, 115 insertions(+)
diff --git a/lib/librte_rawdev/rte_rawdev.c b/lib/librte_rawdev/rte_rawdev.c
index 46353a4eb..08dd982a4 100644
--- a/lib/librte_rawdev/rte_rawdev.c
+++ b/lib/librte_rawdev/rte_rawdev.c
@@ -175,6 +175,34 @@ rte_rawdev_queue_release(uint16_t dev_id, uint16_t
queue_id)
return (*dev->dev_ops->queue_release)(dev, queue_id);
}
+int __rte_experimental
+rte_rawdev_get_attr(uint16_t dev_id,
+ const char *attr_name,
+ uint64_t *attr_value)
+{
+ struct rte_rawdev *dev;
+
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->attr_get, -ENOTSUP);
+ return (*dev->dev_ops->attr_get)(dev, attr_name, attr_value);
+}
+
+int __rte_experimental
+rte_rawdev_set_attr(uint16_t dev_id,
+ const char *attr_name,
+ const uint64_t attr_value)
+{
+ struct rte_rawdev *dev;
+
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->attr_set, -ENOTSUP);
+ return (*dev->dev_ops->attr_set)(dev, attr_name, attr_value);
+}
+
int __rte_experimental
rte_rawdev_dump(uint16_t dev_id, FILE *f)
{
diff --git a/lib/librte_rawdev/rte_rawdev.h b/lib/librte_rawdev/rte_rawdev.h
index e13b11400..bfcbe1270 100644
--- a/lib/librte_rawdev/rte_rawdev.h
+++ b/lib/librte_rawdev/rte_rawdev.h
@@ -307,6 +307,49 @@ struct rte_rawdev_buf {
int __rte_experimental
rte_rawdev_dump(uint16_t dev_id, FILE *f);
+/**
+ * Get an attribute value from implementation.
+ * Attribute is an opaque handle agreed upon between application and PMD.
+ *
+ * Implementations are expected to maintain an array of attribute-value pairs
+ * based on application calls. Memory management for this structure is
+ * shared responsibility of implementation and application.
+ *
+ * @param dev_id
+ * The identifier of the device to configure.
+ * @attr_name
+ * Opaque object representing an attribute in implementation.
+ * @attr_value [out]
+ * Opaque response to the attribute value. In case of error, this remains
+ * untouched. This is double pointer of void type.
+ * @return
+ * 0 for success
+ * !0 Error; attr_value remains untouched in case of error.
+ */
+int __rte_experimental
+rte_rawdev_get_attr(uint16_t dev_id,
+ const char *attr_name,
+ uint64_t *attr_value);
+
+/**
+ * Set an attribute value.
+ * Attribute is an opaque handle agreed upon between application and PMD.
+ *
+ * @param dev_id
+ * The identifier of the device to configure.
+ * @attr_name
+ * Opaque object representing an attribute in implementation.
+ * @attr_value
+ * Value of the attribute represented by attr_name
+ * @return
+ * 0 for success
+ * !0 Error
+ */
+int __rte_experimental
+rte_rawdev_set_attr(uint16_t dev_id,
+ const char *attr_name,
+ const uint64_t attr_value);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_rawdev/rte_rawdev_pmd.h
b/lib/librte_rawdev/rte_rawdev_pmd.h
index ca6e6a1c8..aa67c4f39 100644
--- a/lib/librte_rawdev/rte_rawdev_pmd.h
+++ b/lib/librte_rawdev/rte_rawdev_pmd.h
@@ -262,6 +262,43 @@ typedef int (*rawdev_queue_release_t)(struct rte_rawdev
*dev,
*/
typedef int (*rawdev_dump_t)(struct rte_rawdev *dev, FILE *f);
+/**
+ * Get an attribute value from implementation.
+ * Attribute is an opaque handle agreed upon between application and PMD.
+ *
+ * @param dev
+ * Raw device pointer
+ * @attr_name
+ * Opaque object representing an attribute in implementation.
+ * @attr_value [out]
+ * Opaque response to the attribute value. In case of error, this remains
+ * untouched. This is double pointer of void type.
+ * @return
+ * 0 for success
+ * !0 Error; attr_value remains untouched in case of error.
+ */
+typedef int (*rawdev_get_attr_t)(struct rte_rawdev *dev,
+const char *attr_name,
+uint64_t *attr_value);
+
+/**
+ * Set an attribute value.
+ * Attribute is an opaque handle agreed upon between application and PMD.
+ *
+ * @param dev
+ * Raw device pointer
+ * @attr_name
+ * Opaque object representing an attribute in implementation.
+ * @attr_value
+ * Value of the attribute represented by attr_name
+ * @return
+ * 0 for success
+ * !0 Error
+ *
[dpdk-dev] [PATCH v3 09/11] test: enable rawdev skeleton test
Skeleton rawdevice test cases are part of driver layer. This patch
allows test cases to be executed using 'rawdev_autotest' command
in test framework.
Signed-off-by: Shreyansh Jain
---
test/test/Makefile | 4
test/test/test_rawdev.c | 27 +++
2 files changed, 31 insertions(+)
create mode 100644 test/test/test_rawdev.c
diff --git a/test/test/Makefile b/test/test/Makefile
index cb3884a69..a88cc38bf 100644
--- a/test/test/Makefile
+++ b/test/test/Makefile
@@ -187,6 +187,10 @@ SRCS-y += test_event_ring.c
SRCS-y += test_event_eth_rx_adapter.c
endif
+ifeq ($(CONFIG_RTE_LIBRTE_RAWDEV),y)
+SRCS-y += test_rawdev.c
+endif
+
SRCS-$(CONFIG_RTE_LIBRTE_KVARGS) += test_kvargs.c
CFLAGS += -DALLOW_EXPERIMENTAL_API
diff --git a/test/test/test_rawdev.c b/test/test/test_rawdev.c
new file mode 100644
index 0..043a38a13
--- /dev/null
+++ b/test/test/test_rawdev.c
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2017 NXP
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "test.h"
+
+static int
+test_rawdev_selftest_impl(const char *pmd, const char *opts)
+{
+ rte_vdev_init(pmd, opts);
+ return rte_rawdev_selftest(rte_rawdev_get_dev_id(pmd));
+}
+
+static int
+test_rawdev_selftest_skeleton(void)
+{
+ return test_rawdev_selftest_impl("rawdev_skeleton", "");
+}
+
+REGISTER_TEST_COMMAND(rawdev_autotest, test_rawdev_selftest_skeleton);
--
2.14.1
[dpdk-dev] [PATCH v3 00/11] Introduce generic 'rawdevice' support
Change History ~~ v3: - rebased over master (367bc2a9fd) - added __rte_experimental flag - added initial documentation v2: - restructure comments to prefix model - split patches pivoted on APIs introduced in library - moved test into drivers/rawdev/skeleton from test/test - removed unused RTE_MAX_RAWDEVPORTS and RTE_MAX_RAWDEVS - merge patch configurations - checkpatch fixes Rawdevice Support in DPDK - RFC [1] v1: [2] v2: [3] This patchset introduces rawdevices or generic device support in DPDK. Motivation == In terms of device flavor (type) support, DPDK currently has ethernet (lib_ether), cryptodev (libcryptodev), eventdev (libeventdev) and vdev (virtual device) support. For a new type of device, for example an accelerator, there are not many options except either of: 1. create another lib/librte_MySpecialDev, driver/MySpecialDrv and use it through Bus/PMD model. 2. Or, create a vdev and implement necessary custom APIs which are directly exposed from driver layer. However this may still require changes in bus code in DPDK. Either method is unclean (touching lib for specific context) and possibly non-upstreamable (custom APIs). Applications and customers prefers uniform device view and programming model. Scope = The rawdevice implementation is targetted towards various accelerator use cases which cannot be generalized within existing device models. Aim is to provided a generalized structure at the cost of portability guarantee. Specific PMDs may also expose any specific config APIs. Applications built over such devices are special use-cases involving IP blocks. The rawdevice may also connect to other standard devices using adapter or other methods, similar to eventdev adpter for ethernet/crypto devices. Proposed Solution = Defining a very generic super-set of device type and its device operations that can be exposed such that any new/upcoming/experimental device can be layered over it. 'rawdevice' semantic in this patchset represents a device that doesn't have any flavor/type associated with it which is advertised (like net, crypto etc). A *rte_rawdevice* is a raw/generic device without any standard configuration or input/output method assumption. Thus, driver for a new accelerator block, which requires operations for start/stop/enqueue/dequeue, can be quickly strapped over this rawdevice layer. Thereafter, any appropriate bus can scan for it (assuming device is discoverable over the Linux interfaces like sysfs) and match it against registered drivers. Similarly, for a new accelerator or a wireless device, which doesn't fit the eth type, a driver can be registered with a bus (on which its device would be scannable) and use this layer for configuring the device. It can also serve as a staging area for new type of devices till they find some commonality and can be standardized. The outline of this proposed library is same as existing ether/crypto devices. +---+ |Application(s) | +--.+ | | +--'+ | DPDK Framework (APIs) | +--||-|-+ / \ \ (crypto ops) (eth ops) (rawdev ops)++ / \ \ |DrvA| +-'---++`++---'-+ ++ | crypto || ethdev || raw | +--/--++---/-++/+ ++ /\__/\ / ..|DrvB| / \ /\/ ../\ ++ ++ ++++ +++==/=+ ```Bus Probe |DevA| |DevB||DevC| |DevD||DevF| ++ ++++ ++++ | || | | ``|``||``|`|Bus Scan (PCI) | (PCI) (PCI)(PCI) (BusA) * It is assumed above that DrvB is a PCI type driver which registers itself with PCI Bus * Thereafter, when the PCI scan is done, during probe DrvB would match the rawdev DevF ID and take control of device * Applications can then continue using the device through rawdev API interfaces Proposed Interfaces === Following broad API categories are exposed by the rawdevice: 1) Device State Operations (start/stop/reset) 2) Communication Channel setup/teardown (queue) 3) Attribute get/set operations (~ioctls) 4) Enqueue/Dequeue Operations (using opaque buffers) 5) Firmware Operations (Load/unload) Notes: For (1), other than standar
[dpdk-dev] [PATCH v3 04/11] rawdev: support for extended stats
Generic rawdev library cannot define a pre-defined set of stats
for devices which are yet to be defined.
This patch introduces the xstats support for rawdev so that any
implementation can create its own statistics.
Signed-off-by: Shreyansh Jain
---
lib/librte_rawdev/rte_rawdev.c | 75 ++
lib/librte_rawdev/rte_rawdev.h | 105 +++
lib/librte_rawdev/rte_rawdev_pmd.h | 72 +
lib/librte_rawdev/rte_rawdev_version.map | 4 ++
4 files changed, 256 insertions(+)
diff --git a/lib/librte_rawdev/rte_rawdev.c b/lib/librte_rawdev/rte_rawdev.c
index a6d937c34..d6c284554 100644
--- a/lib/librte_rawdev/rte_rawdev.c
+++ b/lib/librte_rawdev/rte_rawdev.c
@@ -245,6 +245,81 @@ rte_rawdev_dump(uint16_t dev_id, FILE *f)
return (*dev->dev_ops->dump)(dev, f);
}
+static int
+xstats_get_count(uint16_t dev_id)
+{
+ struct rte_rawdev *dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->xstats_get_names, -ENOTSUP);
+ return (*dev->dev_ops->xstats_get_names)(dev, NULL, 0);
+}
+
+int __rte_experimental
+rte_rawdev_xstats_names_get(uint16_t dev_id,
+ struct rte_rawdev_xstats_name *xstats_names,
+ unsigned int size)
+{
+ const struct rte_rawdev *dev;
+ int cnt_expected_entries;
+
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -ENODEV);
+
+ cnt_expected_entries = xstats_get_count(dev_id);
+
+ if (xstats_names == NULL || cnt_expected_entries < 0 ||
+ (int)size < cnt_expected_entries || size <= 0)
+ return cnt_expected_entries;
+
+ dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->xstats_get_names, -ENOTSUP);
+ return (*dev->dev_ops->xstats_get_names)(dev, xstats_names, size);
+}
+
+/* retrieve rawdev extended statistics */
+int __rte_experimental
+rte_rawdev_xstats_get(uint16_t dev_id,
+ const unsigned int ids[],
+ uint64_t values[],
+ unsigned int n)
+{
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -ENODEV);
+ const struct rte_rawdev *dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->xstats_get, -ENOTSUP);
+ return (*dev->dev_ops->xstats_get)(dev, ids, values, n);
+}
+
+uint64_t __rte_experimental
+rte_rawdev_xstats_by_name_get(uint16_t dev_id,
+ const char *name,
+ unsigned int *id)
+{
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, 0);
+ const struct rte_rawdev *dev = &rte_rawdevs[dev_id];
+ unsigned int temp = -1;
+
+ if (id != NULL)
+ *id = (unsigned int)-1;
+ else
+ id = &temp; /* driver never gets a NULL value */
+
+ /* implemented by driver */
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->xstats_get_by_name, -ENOTSUP);
+ return (*dev->dev_ops->xstats_get_by_name)(dev, name, id);
+}
+
+int __rte_experimental
+rte_rawdev_xstats_reset(uint16_t dev_id,
+ const uint32_t ids[], uint32_t nb_ids)
+{
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ struct rte_rawdev *dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->xstats_reset, -ENOTSUP);
+ return (*dev->dev_ops->xstats_reset)(dev, ids, nb_ids);
+}
+
int __rte_experimental
rte_rawdev_start(uint16_t dev_id)
{
diff --git a/lib/librte_rawdev/rte_rawdev.h b/lib/librte_rawdev/rte_rawdev.h
index b4f9aee37..8e3d72273 100644
--- a/lib/librte_rawdev/rte_rawdev.h
+++ b/lib/librte_rawdev/rte_rawdev.h
@@ -408,6 +408,111 @@ rte_rawdev_dequeue_buffers(uint16_t dev_id,
unsigned int count,
rte_rawdev_obj_t context);
+/** Maximum name length for extended statistics counters */
+#define RTE_RAW_DEV_XSTATS_NAME_SIZE 64
+
+/**
+ * A name-key lookup element for extended statistics.
+ *
+ * This structure is used to map between names and ID numbers
+ * for extended ethdev statistics.
+ */
+struct rte_rawdev_xstats_name {
+ char name[RTE_RAW_DEV_XSTATS_NAME_SIZE];
+};
+
+/**
+ * Retrieve names of extended statistics of a raw device.
+ *
+ * @param dev_id
+ * The identifier of the raw device.
+ * @param[out] xstats_names
+ * Block of memory to insert names into. Must be at least size in capacity.
+ * If set to NULL, function returns required capacity.
+ * @param size
+ * Capacity of xstats_names (number of names).
+ * @return
+ * - positive value lower or equal to size: success. The return value
+ * is the number of entries filled in the stats table.
+ * - positive value higher than size: error, the given statistics table
+ * is too small. The return value corresponds to the size that should
+ * be given to succeed. The entries in the table are not valid and
+ * shall not be used by the caller.
+ * - negative value on error:
+ *-ENODEV for invalid *dev_id*
[dpdk-dev] [PATCH v3 07/11] drivers/raw: introduce skeleton rawdev driver
Skeleton rawdevice driver, on the lines of eventdev skeleton, is for
showcasing the rawdev library. This driver implements some of the
operations of the library based on which a test module can be
developed.
Design of skeleton involves a virtual device which is plugged into
VDEV bus on initialization.
Also, enable compilation of rawdev skeleton driver.
Signed-off-by: Shreyansh Jain
---
config/common_base | 1 +
drivers/Makefile | 2 +
drivers/raw/Makefile | 9 +
drivers/raw/skeleton_rawdev/Makefile | 27 +
.../rte_pmd_skeleton_rawdev_version.map| 4 +
drivers/raw/skeleton_rawdev/skeleton_rawdev.c | 690 +
drivers/raw/skeleton_rawdev/skeleton_rawdev.h | 136
mk/rte.app.mk | 4 +
8 files changed, 873 insertions(+)
create mode 100644 drivers/raw/Makefile
create mode 100644 drivers/raw/skeleton_rawdev/Makefile
create mode 100644
drivers/raw/skeleton_rawdev/rte_pmd_skeleton_rawdev_version.map
create mode 100644 drivers/raw/skeleton_rawdev/skeleton_rawdev.c
create mode 100644 drivers/raw/skeleton_rawdev/skeleton_rawdev.h
diff --git a/config/common_base b/config/common_base
index 812cff129..0002f83a2 100644
--- a/config/common_base
+++ b/config/common_base
@@ -811,6 +811,7 @@ CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
#
CONFIG_RTE_LIBRTE_RAWDEV=y
CONFIG_RTE_RAWDEV_MAX_DEVS=10
+CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV=y
#
# Compile vhost PMD
diff --git a/drivers/Makefile b/drivers/Makefile
index e0488aa2b..ee65c87b0 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -14,5 +14,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += crypto
DEPDIRS-crypto := bus mempool
DIRS-$(CONFIG_RTE_LIBRTE_EVENTDEV) += event
DEPDIRS-event := bus mempool net
+DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += raw
+DEPDIRS-raw := bus mempool net event
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/raw/Makefile b/drivers/raw/Makefile
new file mode 100644
index 0..da7c8b449
--- /dev/null
+++ b/drivers/raw/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2017 NXP
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# DIRS-$() +=
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV) += skeleton_rawdev
+
+include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/raw/skeleton_rawdev/Makefile
b/drivers/raw/skeleton_rawdev/Makefile
new file mode 100644
index 0..6318359d1
--- /dev/null
+++ b/drivers/raw/skeleton_rawdev/Makefile
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2017 NXP
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_skeleton_rawdev.a
+
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrte_eal
+LDLIBS += -lrte_rawdev
+LDLIBS += -lrte_bus_vdev
+
+EXPORT_MAP := rte_pmd_skeleton_rawdev_version.map
+
+LIBABIVER := 1
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV) += skeleton_rawdev.c
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/raw/skeleton_rawdev/rte_pmd_skeleton_rawdev_version.map
b/drivers/raw/skeleton_rawdev/rte_pmd_skeleton_rawdev_version.map
new file mode 100644
index 0..179140fb8
--- /dev/null
+++ b/drivers/raw/skeleton_rawdev/rte_pmd_skeleton_rawdev_version.map
@@ -0,0 +1,4 @@
+DPDK_18.02 {
+
+ local: *;
+};
diff --git a/drivers/raw/skeleton_rawdev/skeleton_rawdev.c
b/drivers/raw/skeleton_rawdev/skeleton_rawdev.c
new file mode 100644
index 0..b38188e11
--- /dev/null
+++ b/drivers/raw/skeleton_rawdev/skeleton_rawdev.c
@@ -0,0 +1,690 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2017 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "skeleton_rawdev.h"
+
+/* Dynamic log type identifier */
+int skeleton_pmd_logtype;
+
+/* Count of instances */
+uint16_t skeldev_init_once;
+
+/**< Rawdev Skeleton dummy driver name */
+#define SKELETON_PMD_RAWDEV_NAME rawdev_skeleton
+
+/**< Skeleton rawdev driver object */
+static struct rte_vdev_driver skeleton_pmd_drv;
+
+struct queue_buffers {
+ void *bufs[SKELETON_QUEUE_MAX_DEPTH];
+};
+
+static struct queue_buffers queue_buf[SKELETON_MAX_QUEUES] = {0};
+static void clear_queue_bufs(int queue_id);
+
+static void skeleton_rawdev_info_get(struct rte_rawdev *dev,
+rte_rawdev_obj_t dev_info)
+{
+ struct skeleton_rawdev *skeldev;
+ struct skeleton_rawdev_conf *skeldev_conf;
+
+ SKELETON_PMD_FUNC_TRACE();
+
+ if (!dev_info) {
+ SKELETON_PMD_ERR("Invalid request");
+ return;
+ }
+
+ skeldev = skeleton_rawdev_get_priv(dev);
+
+ skeldev_conf = dev_info;
+
+ skeldev_conf->num_queu
[dpdk-dev] [PATCH v3 01/11] rawdev: introduce raw device library support
Each device in DPDK has a type associated with it - ethernet, crypto,
event etc. This patch introduces 'rawdevice' which is a generic
type of device, not currently handled out-of-the-box by DPDK.
A device which can be scanned on an installed bus (pci, fslmc, ...)
or instantiated through devargs, can be interfaced using
standardized APIs just like other standardized devices.
This library introduces an API set which can be plugged on the
northbound side to the application layer, and on the southbound side
to the driver layer.
The APIs of rawdev library exposes some generic operations which can
enable configuration and I/O with the raw devices. Using opaque
data (pointer) as API arguments, library allows a high flexibility
for application and driver implementation.
This patch introduces basic device operations like start, stop, reset,
queue and info support.
Subsequent patches would introduce other operations like buffer
enqueue/dequeue and firmware support.
Signed-off-by: Shreyansh Jain
---
config/common_base | 7 +
lib/Makefile | 3 +
lib/librte_rawdev/Makefile | 28 +++
lib/librte_rawdev/rte_rawdev.c | 360 +++
lib/librte_rawdev/rte_rawdev.h | 314 +++
lib/librte_rawdev/rte_rawdev_pmd.h | 352 ++
lib/librte_rawdev/rte_rawdev_version.map | 21 ++
mk/rte.app.mk| 1 +
8 files changed, 1086 insertions(+)
create mode 100644 lib/librte_rawdev/Makefile
create mode 100644 lib/librte_rawdev/rte_rawdev.c
create mode 100644 lib/librte_rawdev/rte_rawdev.h
create mode 100644 lib/librte_rawdev/rte_rawdev_pmd.h
create mode 100644 lib/librte_rawdev/rte_rawdev_version.map
diff --git a/config/common_base b/config/common_base
index c560b73da..812cff129 100644
--- a/config/common_base
+++ b/config/common_base
@@ -805,6 +805,13 @@ CONFIG_RTE_LIBRTE_VHOST=n
CONFIG_RTE_LIBRTE_VHOST_NUMA=n
CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
+#
+# Compile raw device support
+# EXPERIMENTAL: API may change without prior notice
+#
+CONFIG_RTE_LIBRTE_RAWDEV=y
+CONFIG_RTE_RAWDEV_MAX_DEVS=10
+
#
# Compile vhost PMD
# To compile, CONFIG_RTE_LIBRTE_VHOST should be enabled.
diff --git a/lib/Makefile b/lib/Makefile
index 427f34b00..97080a590 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -102,4 +102,7 @@ endif
DEPDIRS-librte_kni := librte_eal librte_mempool librte_mbuf librte_ether
DEPDIRS-librte_kni += librte_pci
+DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev
+DEPDIRS-librte_rawdev := librte_eal librte_ether
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/lib/librte_rawdev/Makefile b/lib/librte_rawdev/Makefile
new file mode 100644
index 0..b9105b060
--- /dev/null
+++ b/lib/librte_rawdev/Makefile
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2017 NXP
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# library name
+LIB = librte_rawdev.a
+
+# library version
+LIBABIVER := 1
+
+# build flags
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrte_eal
+
+# library source files
+SRCS-y += rte_rawdev.c
+
+# export include files
+SYMLINK-y-include += rte_rawdev.h
+SYMLINK-y-include += rte_rawdev_pmd.h
+
+# versioning export map
+EXPORT_MAP := rte_rawdev_version.map
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_rawdev/rte_rawdev.c b/lib/librte_rawdev/rte_rawdev.c
new file mode 100644
index 0..46353a4eb
--- /dev/null
+++ b/lib/librte_rawdev/rte_rawdev.c
@@ -0,0 +1,360 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2017 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rte_rawdev.h"
+#include "rte_rawdev_pmd.h"
+
+/* dynamic log identifier */
+int librawdev_logtype;
+
+struct rte_rawdev rte_rawdevices[RTE_RAWDEV_MAX_DEVS];
+
+struct rte_rawdev *rte_rawdevs = &rte_rawdevices[0];
+
+static struct rte_rawdev_global rawdev_globals = {
+ .nb_devs= 0
+};
+
+struct rte_rawdev_global *rte_rawdev_globals = &rawdev_globals;
+
+/* Raw device, northbound API implementation */
+uint8_t __rte_experimental
+rte_rawdev_count(void)
+{
+ return rte_rawdev_globals->nb_devs;
+}
+
+uint16_t __rte_experimental
+rte_rawdev_get_dev_id(const char *name)
+{
+ uint16_t i;
+
+ if (!name)
+ return -EINVAL;
+
+ for (i = 0; i < rte_rawdev_globals->nb_devs; i++)
+ if ((strcmp(rte_rawdevices[i].name, name)
+ == 0) &&
+ (rte_rawdevices[i].attached ==
+ RTE_RAWDEV_ATTACHED))
+ return i;
+ return -ENODEV;
+}
+
+int __rte_exp
[dpdk-dev] [PATCH v3 03/11] rawdev: add buffer stream IO support
Introduce handlers for raw buffer enqueue and dequeue. A raw buffer
is essentially a void object which is transparently passed via the
library onto the driver.
Using a context field as argument, any arbitrary meta information
can be passed by application to the driver/implementation. This can
be any data on which driver needs to define the operation semantics.
For example, passing along a queue identifier can suggest the driver
the queue context to perform I/O on.
Signed-off-by: Shreyansh Jain
---
lib/librte_rawdev/rte_rawdev.c | 30 +
lib/librte_rawdev/rte_rawdev.h | 58
lib/librte_rawdev/rte_rawdev_pmd.h | 58
lib/librte_rawdev/rte_rawdev_version.map | 2 ++
4 files changed, 148 insertions(+)
diff --git a/lib/librte_rawdev/rte_rawdev.c b/lib/librte_rawdev/rte_rawdev.c
index 08dd982a4..a6d937c34 100644
--- a/lib/librte_rawdev/rte_rawdev.c
+++ b/lib/librte_rawdev/rte_rawdev.c
@@ -203,6 +203,36 @@ rte_rawdev_set_attr(uint16_t dev_id,
return (*dev->dev_ops->attr_set)(dev, attr_name, attr_value);
}
+int __rte_experimental
+rte_rawdev_enqueue_buffers(uint16_t dev_id,
+ struct rte_rawdev_buf **buffers,
+ unsigned int count,
+ rte_rawdev_obj_t context)
+{
+ struct rte_rawdev *dev;
+
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->enqueue_bufs, -ENOTSUP);
+ return (*dev->dev_ops->enqueue_bufs)(dev, buffers, count, context);
+}
+
+int __rte_experimental
+rte_rawdev_dequeue_buffers(uint16_t dev_id,
+ struct rte_rawdev_buf **buffers,
+ unsigned int count,
+ rte_rawdev_obj_t context)
+{
+ struct rte_rawdev *dev;
+
+ RTE_RAWDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ dev = &rte_rawdevs[dev_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dequeue_bufs, -ENOTSUP);
+ return (*dev->dev_ops->dequeue_bufs)(dev, buffers, count, context);
+}
+
int __rte_experimental
rte_rawdev_dump(uint16_t dev_id, FILE *f)
{
diff --git a/lib/librte_rawdev/rte_rawdev.h b/lib/librte_rawdev/rte_rawdev.h
index bfcbe1270..b4f9aee37 100644
--- a/lib/librte_rawdev/rte_rawdev.h
+++ b/lib/librte_rawdev/rte_rawdev.h
@@ -350,6 +350,64 @@ rte_rawdev_set_attr(uint16_t dev_id,
const char *attr_name,
const uint64_t attr_value);
+/**
+ * Enqueue a stream of buffers to the device.
+ *
+ * Rather than specifying a queue, this API passes along an opaque object
+ * to the driver implementation. That object can be a queue or any other
+ * contextual information necessary for the device to enqueue buffers.
+ *
+ * @param dev_id
+ * The identifier of the device to configure.
+ * @param bufs
+ * Collection of buffers for enqueueing
+ * @param count
+ * Count of buffers to enqueue
+ * @param context
+ * Opaque context information.
+ * @return
+ * >=0 for buffers enqueued
+ * !0 for failure.
+ * Whether partial enqueue is failure or success is defined between app
+ * and driver implementation.
+ */
+int __rte_experimental
+rte_rawdev_enqueue_buffers(uint16_t dev_id,
+ struct rte_rawdev_buf **buffers,
+ unsigned int count,
+ rte_rawdev_obj_t context);
+
+/**
+ * Dequeue a stream of buffers from the device.
+ *
+ * Rather than specifying a queue, this API passes along an opaque object
+ * to the driver implementation. That object can be a queue or any other
+ * contextual information necessary for the device to dequeue buffers.
+ *
+ * Application should have allocated enough space to store `count` response
+ * buffers.
+ * Releasing buffers dequeued is responsibility of the application.
+ *
+ * @param dev_id
+ * The identifier of the device to configure.
+ * @param bufs
+ * Collection of buffers dequeued
+ * @param count
+ * Max buffers expected to be dequeued
+ * @param context
+ * Opaque context information.
+ * @return
+ * >=0 for buffers dequeued
+ * !0 for failure.
+ * Whether partial enqueue is failure or success is defined between app
+ * and driver implementation.
+ */
+int __rte_experimental
+rte_rawdev_dequeue_buffers(uint16_t dev_id,
+ struct rte_rawdev_buf **buffers,
+ unsigned int count,
+ rte_rawdev_obj_t context);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_rawdev/rte_rawdev_pmd.h
b/lib/librte_rawdev/rte_rawdev_pmd.h
index aa67c4f39..da891dc4d 100644
--- a/lib/librte_rawdev/rte_rawdev_pmd.h
+++ b/lib/librte_rawdev/rte_rawdev_pmd.h
@@ -248,6 +248,58 @@ typedef int (*rawdev_queue_setup_t)(struct rte_rawdev *dev,
typedef int (*rawdev_queue_release_t)(struct rte_rawdev *dev,
uint1
[dpdk-dev] [PATCH v3 08/11] drivers/raw: support for rawdev testcases
Patch introduces rawdev unit testcase for validation against the
Skeleton rawdev dummy PMD implementation.
Test cases are added along with the skeleton driver implementation.
It can be enabled by using vdev argument to any DPDK binary:
--vdev="rawdev_skeleton,self_test=1"
In case 'self_test=1' is not provided, autotest doesn't execute the
test cases but the vdev is still available for application use.
Signed-off-by: Shreyansh Jain
---
drivers/raw/skeleton_rawdev/Makefile | 1 +
drivers/raw/skeleton_rawdev/skeleton_rawdev.c | 66 +++-
drivers/raw/skeleton_rawdev/skeleton_rawdev_test.c | 431 +
3 files changed, 497 insertions(+), 1 deletion(-)
create mode 100644 drivers/raw/skeleton_rawdev/skeleton_rawdev_test.c
diff --git a/drivers/raw/skeleton_rawdev/Makefile
b/drivers/raw/skeleton_rawdev/Makefile
index 6318359d1..379cb9d17 100644
--- a/drivers/raw/skeleton_rawdev/Makefile
+++ b/drivers/raw/skeleton_rawdev/Makefile
@@ -23,5 +23,6 @@ LIBABIVER := 1
# all source are stored in SRCS-y
#
SRCS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV) += skeleton_rawdev.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV) += skeleton_rawdev_test.c
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/raw/skeleton_rawdev/skeleton_rawdev.c
b/drivers/raw/skeleton_rawdev/skeleton_rawdev.c
index b38188e11..2dfba0081 100644
--- a/drivers/raw/skeleton_rawdev/skeleton_rawdev.c
+++ b/drivers/raw/skeleton_rawdev/skeleton_rawdev.c
@@ -541,6 +541,8 @@ static const struct rte_rawdev_ops skeleton_rawdev_ops = {
.firmware_version_get = skeleton_rawdev_firmware_version_get,
.firmware_load = skeleton_rawdev_firmware_load,
.firmware_unload = skeleton_rawdev_firmware_unload,
+
+ .dev_selftest = test_rawdev_skeldev,
};
static int
@@ -630,11 +632,62 @@ skeleton_rawdev_destroy(const char *name)
return 0;
}
+static int
+skeldev_get_selftest(const char *key __rte_unused,
+const char *value,
+void *opaque)
+{
+ int *flag = opaque;
+ *flag = atoi(value);
+ return 0;
+}
+
+static int
+skeldev_parse_vdev_args(struct rte_vdev_device *vdev)
+{
+ int selftest = 0;
+ const char *name;
+ const char *params;
+
+ static const char *const args[] = {
+ SKELETON_SELFTEST_ARG,
+ NULL
+ };
+
+ name = rte_vdev_device_name(vdev);
+
+ params = rte_vdev_device_args(vdev);
+ if (params != NULL && params[0] != '\0') {
+ struct rte_kvargs *kvlist = rte_kvargs_parse(params, args);
+
+ if (!kvlist) {
+ SKELETON_PMD_INFO(
+ "Ignoring unsupported params supplied '%s'",
+ name);
+ } else {
+ int ret = rte_kvargs_process(kvlist,
+ SKELETON_SELFTEST_ARG,
+ skeldev_get_selftest, &selftest);
+ if (ret != 0 || (selftest < 0 || selftest > 1)) {
+ SKELETON_PMD_ERR("%s: Error in parsing args",
+name);
+ rte_kvargs_free(kvlist);
+ ret = -1; /* enforce if selftest is invalid */
+ return ret;
+ }
+ }
+
+ rte_kvargs_free(kvlist);
+ }
+
+ return selftest;
+}
+
static int
skeleton_rawdev_probe(struct rte_vdev_device *vdev)
{
const char *name;
- int ret = 0;
+ int selftest = 0, ret = 0;
name = rte_vdev_device_name(vdev);
@@ -647,7 +700,18 @@ skeleton_rawdev_probe(struct rte_vdev_device *vdev)
SKELETON_PMD_INFO("Init %s on NUMA node %d", name, rte_socket_id());
+ selftest = skeldev_parse_vdev_args(vdev);
+ /* In case of invalid argument, selftest != 1; ignore other values */
+
ret = skeleton_rawdev_create(name, vdev, rte_socket_id());
+ if (!ret) {
+ /* In case command line argument for 'selftest' was passed;
+* if invalid arguments were passed, execution continues but
+* without selftest.
+*/
+ if (selftest == 1)
+ test_rawdev_skeldev();
+ }
/* Device instance created; Second instance not posible */
skeldev_init_once = 1;
diff --git a/drivers/raw/skeleton_rawdev/skeleton_rawdev_test.c
b/drivers/raw/skeleton_rawdev/skeleton_rawdev_test.c
new file mode 100644
index 0..5c6abc13c
--- /dev/null
+++ b/drivers/raw/skeleton_rawdev/skeleton_rawdev_test.c
@@ -0,0 +1,431 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2017 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Using relative path as skeleton_rawdev is not part of exported headers */
+
[dpdk-dev] [PATCH v2] net/dpaa2: fix the err with testpmd in Tx only mode
Fixes: 043b36f621dd ("net/dpaa2: support more than 16 burst size in Rx")
Signed-off-by: Hemant Agrawal
---
v2: fix checkpatch warning
* This patch is applicable over net-next tree*
drivers/net/dpaa2/dpaa2_rxtx.c | 126 +++--
1 file changed, 33 insertions(+), 93 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_rxtx.c b/drivers/net/dpaa2/dpaa2_rxtx.c
index 3d45669..dc3c3a6 100644
--- a/drivers/net/dpaa2/dpaa2_rxtx.c
+++ b/drivers/net/dpaa2/dpaa2_rxtx.c
@@ -473,10 +473,10 @@ dpaa2_dev_prefetch_rx(void *queue, struct rte_mbuf
**bufs, uint16_t nb_pkts)
{
/* Function receive frames for a given device and VQ*/
struct dpaa2_queue *dpaa2_q = (struct dpaa2_queue *)queue;
- struct qbman_result *dq_storage, *dq_storage1 = 0;
+ struct qbman_result *dq_storage, *dq_storage1 = NULL;
uint32_t fqid = dpaa2_q->fqid;
- int ret, num_rx = 0, next_pull = 0, num_pulled, num_to_pull;
- uint8_t pending, is_repeat, status;
+ int ret, num_rx = 0;
+ uint8_t pending, status;
struct qbman_swp *swp;
const struct qbman_fd *fd, *next_fd;
struct qbman_pull_desc pulldesc;
@@ -491,19 +491,6 @@ dpaa2_dev_prefetch_rx(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
}
}
swp = DPAA2_PER_LCORE_PORTAL;
-
- /* if the original request for this q was from another portal */
- if (unlikely(DPAA2_PER_LCORE_DPIO->index !=
- q_storage->active_dpio_id)) {
- if (check_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index)) {
- while (!qbman_check_command_complete(get_swp_active_dqs
- (DPAA2_PER_LCORE_DPIO->index)))
- ;
- clear_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index);
- }
- q_storage->active_dpio_id = DPAA2_PER_LCORE_DPIO->index;
- }
-
if (unlikely(!q_storage->active_dqs)) {
q_storage->toggle = 0;
dq_storage = q_storage->dq_storage[q_storage->toggle];
@@ -515,27 +502,41 @@ dpaa2_dev_prefetch_rx(void *queue, struct rte_mbuf
**bufs, uint16_t nb_pkts)
qbman_pull_desc_set_fq(&pulldesc, fqid);
qbman_pull_desc_set_storage(&pulldesc, dq_storage,
(dma_addr_t)(DPAA2_VADDR_TO_IOVA(dq_storage)), 1);
+ if (check_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index)) {
+ while (!qbman_check_command_complete(
+ get_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index)))
+ ;
+ clear_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index);
+ }
while (1) {
if (qbman_swp_pull(swp, &pulldesc)) {
- PMD_RX_LOG(WARNING,
- "VDQ command not issued.QBMAN busy\n");
+ PMD_RX_LOG(WARNING, "VDQ command is not issued."
+ "QBMAN is busy\n");
/* Portal was busy, try again */
continue;
}
break;
}
q_storage->active_dqs = dq_storage;
+ q_storage->active_dpio_id = DPAA2_PER_LCORE_DPIO->index;
set_swp_active_dqs(DPAA2_PER_LCORE_DPIO->index, dq_storage);
}
- /* pkt to pull in current pull request */
- num_to_pull = q_storage->last_num_pkts;
+ dq_storage = q_storage->active_dqs;
+ rte_prefetch0((void *)((uint64_t)(dq_storage)));
+ rte_prefetch0((void *)((uint64_t)(dq_storage + 1)));
- /* Number of packet requested is more than current pull request */
- if (nb_pkts > num_to_pull)
- next_pull = nb_pkts - num_to_pull;
+ /* Prepare next pull descriptor. This will give space for the
+* prefething done on DQRR entries
+*/
+ q_storage->toggle ^= 1;
+ dq_storage1 = q_storage->dq_storage[q_storage->toggle];
+ qbman_pull_desc_clear(&pulldesc);
+ qbman_pull_desc_set_numframes(&pulldesc, DPAA2_DQRR_RING_SIZE);
+ qbman_pull_desc_set_fq(&pulldesc, fqid);
+ qbman_pull_desc_set_storage(&pulldesc, dq_storage1,
+ (dma_addr_t)(DPAA2_VADDR_TO_IOVA(dq_storage1)), 1);
- dq_storage = q_storage->active_dqs;
/* Check if the previous issued command is completed.
* Also seems like the SWP is shared between the Ethernet Driver
* and the SEC driver.
@@ -545,45 +546,6 @@ dpaa2_dev_prefetch_rx(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
if (dq_storage == get_swp_active_dqs(q_storage->active_dpio_id))
clear_swp_active_dqs(q_storage->active_dpio_id);
-repeat:
- is_repeat = 0;
-
- /* issue the deq command one more time to get another set o
Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel offloads
Hi Ananyev,
> -Original Message-
> From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> Sent: Tuesday, January 30, 2018 9:28 PM
> To: Xueming(Steven) Li ; Olivier MATZ
>
> Cc: dev@dpdk.org; Wu, Jingjing ; Shahaf Shuler
> ; Yongseok Koh ; Thomas Monjalon
> ; Yigit, Ferruh
> Subject: RE: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel
> offloads
>
>
> Hi Xueming,
>
> > > > This patch introduce new TX offloads flag for devices that support
> > > > tunnel agnostic checksum and TSO offloads.
> > > >
> > > > The support from the device is for inner and outer checksums on
> > > > IPV4/TCP/UDP and TSO for *any packet with the following format*:
> > > >
> > > > < some headers > / [optional IPv4/IPv6] / [optional TCP/UDP] /
> > > > > > > headers> / [optional inner IPv4/IPv6] / [optional TCP/UDP]
> > > >
> > > > For example the following packets can use this feature:
> > > >
> > > > 1. eth / ipv4 / udp / VXLAN / ip / tcp 2. eth / ipv4 / GRE / MPLS
> > > > /
> > > > ipv4 / udp
> > >
> > > So in terms of usage - what is the difference with current TSO types?
> > > Konstantin
> > >
> >
> > Traditionally, HW only recognize "known" tunnel type, do TSO
> > calculation based on L3/L4 headers known to tunnel type. For example,
> > it must be
> > L2 header after VXLAN, then L3. While this Generic offloading provides
> > inner/outer L3/L4 header info(len and offset) to HW, and thus tunnel
> > info become less important. Please note the MPLS over GRE tunnel in
> > last example above.
>
> Ok, but I wonder when the user would like to do TSO on tunnel packet, for
> this offload - would he need to do something differently from what he has
> to do now:
> raise PKT_TX_TCP_SEG and related flags, raise appropriate PKT_TX_TUNNEL_*
> flag, fill l2_len, l3_len, l4_len,tso_segsz,outer_l2_len,outer_l3_len?
>
Yes, these fields are sufficient except PKT_TX_TUNNEL_*, major target of this
new feature is to support "unknown" tunnel offloading, it supports "known"
tunnel type as well.
PKT_TX_TUNNEL_VXLAN has to be used as a hint if outer UDP expected.
> Konstantin
>
> >
> > > >
> > > > Signed-off-by: Xueming Li
> > > > ---
> > > > lib/librte_ether/rte_ethdev.h | 10 ++
> > > > 1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > > b/lib/librte_ether/rte_ethdev.h index 1a5b4cdc5..d8d08ccb2 100644
> > > > --- a/lib/librte_ether/rte_ethdev.h
> > > > +++ b/lib/librte_ether/rte_ethdev.h
> > > > @@ -979,6 +979,16 @@ struct rte_eth_conf {
> > > > * the same mempool and has refcnt = 1.
> > > > */
> > > > #define DEV_TX_OFFLOAD_SECURITY 0x0002
> > > > +/**< Device supports generic tunnel checksum and TSO offloading.
> > > > + * Checksum and TSO are done based on following mbuf fields:
> > > > + * - Length of each header
> > > > + * - Type of outer/inner L3 type, IPv4 or IPv6
> > > > + * - Type of outer/inner L4 type, TCP or UDP.
> > > > + * - PKT_TX_TUNNEL_VXLAN implies outer UDP type.
> > > > + * - PKT_TX_TCP_SEG implies inner TCP type.
> > > > + * Tunnel type is optional except PKT_TX_TUNNEL_VXLAN to hint outer
> UDP.
> > > > + */
> > > > +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO 0x0004
> > > >
> > > > /*
> > > > * If new Tx offload capabilities are defined, they also must be
> > > > --
> > > > 2.13.3
Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel offloads
> -Original Message-
> From: Xueming(Steven) Li [mailto:xuemi...@mellanox.com]
> Sent: Tuesday, January 30, 2018 3:27 PM
> To: Ananyev, Konstantin ; Olivier MATZ
>
> Cc: dev@dpdk.org; Wu, Jingjing ; Shahaf Shuler
> ; Yongseok Koh
> ; Thomas Monjalon ; Yigit, Ferruh
>
> Subject: RE: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel
> offloads
>
> Hi Ananyev,
>
> > -Original Message-
> > From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> > Sent: Tuesday, January 30, 2018 9:28 PM
> > To: Xueming(Steven) Li ; Olivier MATZ
> >
> > Cc: dev@dpdk.org; Wu, Jingjing ; Shahaf Shuler
> > ; Yongseok Koh ; Thomas Monjalon
> > ; Yigit, Ferruh
> > Subject: RE: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel
> > offloads
> >
> >
> > Hi Xueming,
> >
> > > > > This patch introduce new TX offloads flag for devices that support
> > > > > tunnel agnostic checksum and TSO offloads.
> > > > >
> > > > > The support from the device is for inner and outer checksums on
> > > > > IPV4/TCP/UDP and TSO for *any packet with the following format*:
> > > > >
> > > > > < some headers > / [optional IPv4/IPv6] / [optional TCP/UDP] /
> > > > > > > > > headers> / [optional inner IPv4/IPv6] / [optional TCP/UDP]
> > > > >
> > > > > For example the following packets can use this feature:
> > > > >
> > > > > 1. eth / ipv4 / udp / VXLAN / ip / tcp 2. eth / ipv4 / GRE / MPLS
> > > > > /
> > > > > ipv4 / udp
> > > >
> > > > So in terms of usage - what is the difference with current TSO types?
> > > > Konstantin
> > > >
> > >
> > > Traditionally, HW only recognize "known" tunnel type, do TSO
> > > calculation based on L3/L4 headers known to tunnel type. For example,
> > > it must be
> > > L2 header after VXLAN, then L3. While this Generic offloading provides
> > > inner/outer L3/L4 header info(len and offset) to HW, and thus tunnel
> > > info become less important. Please note the MPLS over GRE tunnel in
> > > last example above.
> >
> > Ok, but I wonder when the user would like to do TSO on tunnel packet, for
> > this offload - would he need to do something differently from what he has
> > to do now:
> > raise PKT_TX_TCP_SEG and related flags, raise appropriate PKT_TX_TUNNEL_*
> > flag, fill l2_len, l3_len, l4_len,tso_segsz,outer_l2_len,outer_l3_len?
> >
>
> Yes, these fields are sufficient except PKT_TX_TUNNEL_*, major target of this
> new feature is to support "unknown" tunnel offloading, it supports "known"
> tunnel type as well.
Ok, but user would still need to set some flag to indicate that this is a
tunnel packet,
and he wants TSO over it, right?
For pre-defined tunnel types it can be one of PKT_TX_TUNNEL_*
(which actually means that user still have to know tunnel type anyway?)
But for some not defined tunnel type - what it would be?
Konstantin
>
> PKT_TX_TUNNEL_VXLAN has to be used as a hint if outer UDP expected.
>
> > Konstantin
> >
> > >
> > > > >
> > > > > Signed-off-by: Xueming Li
> > > > > ---
> > > > > lib/librte_ether/rte_ethdev.h | 10 ++
> > > > > 1 file changed, 10 insertions(+)
> > > > >
> > > > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > > > b/lib/librte_ether/rte_ethdev.h index 1a5b4cdc5..d8d08ccb2 100644
> > > > > --- a/lib/librte_ether/rte_ethdev.h
> > > > > +++ b/lib/librte_ether/rte_ethdev.h
> > > > > @@ -979,6 +979,16 @@ struct rte_eth_conf {
> > > > > * the same mempool and has refcnt = 1.
> > > > > */
> > > > > #define DEV_TX_OFFLOAD_SECURITY 0x0002
> > > > > +/**< Device supports generic tunnel checksum and TSO offloading.
> > > > > + * Checksum and TSO are done based on following mbuf fields:
> > > > > + * - Length of each header
> > > > > + * - Type of outer/inner L3 type, IPv4 or IPv6
> > > > > + * - Type of outer/inner L4 type, TCP or UDP.
> > > > > + * - PKT_TX_TUNNEL_VXLAN implies outer UDP type.
> > > > > + * - PKT_TX_TCP_SEG implies inner TCP type.
> > > > > + * Tunnel type is optional except PKT_TX_TUNNEL_VXLAN to hint outer
> > UDP.
> > > > > + */
> > > > > +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO 0x0004
> > > > >
> > > > > /*
> > > > > * If new Tx offload capabilities are defined, they also must be
> > > > > --
> > > > > 2.13.3
[dpdk-dev] [PATCH v4 1/4] net/mlx4: move rdma-core calls to separate file
This lays the groundwork for externalizing rdma-core as an optional
run-time dependency instead of a mandatory one.
No functional change.
Signed-off-by: Adrien Mazarguil
Acked-by: Nelio Laranjeiro
---
drivers/net/mlx4/Makefile | 1 +
drivers/net/mlx4/mlx4.c| 35 ++---
drivers/net/mlx4/mlx4_ethdev.c | 3 +-
drivers/net/mlx4/mlx4_flow.c | 32 +++--
drivers/net/mlx4/mlx4_glue.c | 275
drivers/net/mlx4/mlx4_glue.h | 80 +++
drivers/net/mlx4/mlx4_intr.c | 10 +-
drivers/net/mlx4/mlx4_mr.c | 7 +-
drivers/net/mlx4/mlx4_rxq.c| 53 +++
drivers/net/mlx4/mlx4_txq.c| 17 +--
10 files changed, 440 insertions(+), 73 deletions(-)
diff --git a/drivers/net/mlx4/Makefile b/drivers/net/mlx4/Makefile
index 1f95e0df9..1d33c38ed 100644
--- a/drivers/net/mlx4/Makefile
+++ b/drivers/net/mlx4/Makefile
@@ -38,6 +38,7 @@ LIB = librte_pmd_mlx4.a
SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_ethdev.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_flow.c
+SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_glue.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_intr.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_mr.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_rxq.c
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 952dae08a..f304359bb 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -67,6 +67,7 @@
#include
#include "mlx4.h"
+#include "mlx4_glue.h"
#include "mlx4_flow.h"
#include "mlx4_rxtx.h"
#include "mlx4_utils.h"
@@ -218,8 +219,8 @@ mlx4_dev_close(struct rte_eth_dev *dev)
mlx4_tx_queue_release(dev->data->tx_queues[i]);
if (priv->pd != NULL) {
assert(priv->ctx != NULL);
- claim_zero(ibv_dealloc_pd(priv->pd));
- claim_zero(ibv_close_device(priv->ctx));
+ claim_zero(mlx4_glue->dealloc_pd(priv->pd));
+ claim_zero(mlx4_glue->close_device(priv->ctx));
} else
assert(priv->ctx == NULL);
mlx4_intr_uninstall(priv);
@@ -436,7 +437,7 @@ mlx4_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
(void)pci_drv;
assert(pci_drv == &mlx4_driver);
- list = ibv_get_device_list(&i);
+ list = mlx4_glue->get_device_list(&i);
if (list == NULL) {
rte_errno = errno;
assert(rte_errno);
@@ -465,12 +466,12 @@ mlx4_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
PCI_DEVICE_ID_MELLANOX_CONNECTX3VF);
INFO("PCI information matches, using device \"%s\" (VF: %s)",
list[i]->name, (vf ? "true" : "false"));
- attr_ctx = ibv_open_device(list[i]);
+ attr_ctx = mlx4_glue->open_device(list[i]);
err = errno;
break;
}
if (attr_ctx == NULL) {
- ibv_free_device_list(list);
+ mlx4_glue->free_device_list(list);
switch (err) {
case 0:
rte_errno = ENODEV;
@@ -487,7 +488,7 @@ mlx4_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
}
ibv_dev = list[i];
DEBUG("device opened");
- if (ibv_query_device(attr_ctx, &device_attr)) {
+ if (mlx4_glue->query_device(attr_ctx, &device_attr)) {
rte_errno = ENODEV;
goto error;
}
@@ -502,7 +503,7 @@ mlx4_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
if (!conf.ports.enabled)
conf.ports.enabled = conf.ports.present;
/* Retrieve extended device attributes. */
- if (ibv_query_device_ex(attr_ctx, NULL, &device_attr_ex)) {
+ if (mlx4_glue->query_device_ex(attr_ctx, NULL, &device_attr_ex)) {
rte_errno = ENODEV;
goto error;
}
@@ -520,13 +521,13 @@ mlx4_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
if (!(conf.ports.enabled & (1 << i)))
continue;
DEBUG("using port %u", port);
- ctx = ibv_open_device(ibv_dev);
+ ctx = mlx4_glue->open_device(ibv_dev);
if (ctx == NULL) {
rte_errno = ENODEV;
goto port_error;
}
/* Check port status. */
- err = ibv_query_port(ctx, port, &port_attr);
+ err = mlx4_glue->query_port(ctx, port, &port_attr);
if (err) {
rte_errno = err;
ERROR("port query failed: %s", strerror(rte_errno));
@@ -540,7 +541,7 @@ mlx4_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
}
if (port_attr.state != IBV_PORT_ACTIVE)
DEBUG("port %d is not
[dpdk-dev] [PATCH v4 0/4] net/mlx: make rdma-core optional at run-time
A problem encountered with Mellanox PMDs and frequently reported by DPDK application developers and Linux distribution package maintainers is their dependency on rdma-core components, namely libibverbs, libmlx4, and libmlx5. For best performance in applications, DPDK is normally built as a collection of library archives (.a files), whose external dependencies are inherited through rte.app.mk during link. When these PMDs are built-in, any binary DPDK package, whether DPDK itself or derived applications, always have to pull rdma-core. This dependency is not obvious and may be missed during the packaging of any intermediate layer between DPDK itself and the end application. While still required during compilation, this series trades this hard dependency for an optional one, dynamically loaded at run-time through dlopen(). It supersedes Shachar's previous work on the same topic [1] using a different approach in order to preserve symbol versioning and address the remaining issues. [1] http://dpdk.org/ml/archives/dev/2017-December/085090.html v4 changes: - Addressed remaining compilation issue against MLNX_OFED due to missing function definitions in mlx5. - Fixed sign of errno code returned by glue functions when counters are not supported. v3 changes: - Rebased on dpdk-next-net-mlx. - Modified patches to generate mlx4/mlx5 glue objects as independent libraries to install on the target system (they are not generated at run time anymore) in order to address security concerns. - As a consequence, glue libraries generation is now disabled by default and binary distributions must take care of properly packaging them if enabled. v2 changes: - Rebased on dpdk-next-net-mlx. - Rely on CONFIG_RTE_LIBRTE_MLX[45]_DLOPEN_DEPS instead of CONFIG_RTE_BUILD_SHARED_LIB to enable this mode, so it can be overridden if necessary. - Fixed -lmlx5 -libibverbs leftovers in rte.app.mk. - Minor fixes for indentation and unnecessary includes in mlx5. Adrien Mazarguil (3): net/mlx4: move rdma-core calls to separate file net/mlx4: spawn rdma-core dependency plug-in net/mlx5: spawn rdma-core dependency plug-in Nelio Laranjeiro (1): net/mlx5: move rdma-core calls to separate file config/common_base | 2 + doc/guides/nics/mlx4.rst | 13 ++ doc/guides/nics/mlx5.rst | 13 ++ drivers/net/mlx4/Makefile | 30 +++ drivers/net/mlx4/mlx4.c| 84 +++-- drivers/net/mlx4/mlx4_ethdev.c | 3 +- drivers/net/mlx4/mlx4_flow.c | 32 ++-- drivers/net/mlx4/mlx4_glue.c | 275 drivers/net/mlx4/mlx4_glue.h | 80 drivers/net/mlx4/mlx4_intr.c | 10 +- drivers/net/mlx4/mlx4_mr.c | 7 +- drivers/net/mlx4/mlx4_rxq.c| 53 +++--- drivers/net/mlx4/mlx4_txq.c| 17 +- drivers/net/mlx5/Makefile | 30 +++ drivers/net/mlx5/mlx5.c| 92 +++--- drivers/net/mlx5/mlx5_ethdev.c | 7 +- drivers/net/mlx5/mlx5_flow.c | 92 +- drivers/net/mlx5/mlx5_glue.c | 352 drivers/net/mlx5/mlx5_glue.h | 106 +++ drivers/net/mlx5/mlx5_mr.c | 7 +- drivers/net/mlx5/mlx5_rxq.c| 54 +++--- drivers/net/mlx5/mlx5_txq.c| 22 ++- drivers/net/mlx5/mlx5_vlan.c | 13 +- mk/rte.app.mk | 8 + 24 files changed, 1217 insertions(+), 185 deletions(-) create mode 100644 drivers/net/mlx4/mlx4_glue.c create mode 100644 drivers/net/mlx4/mlx4_glue.h create mode 100644 drivers/net/mlx5/mlx5_glue.c create mode 100644 drivers/net/mlx5/mlx5_glue.h -- 2.11.0
[dpdk-dev] [PATCH v4 4/4] net/mlx5: spawn rdma-core dependency plug-in
When mlx5 is not compiled directly as an independent shared object (e.g.
CONFIG_RTE_BUILD_SHARED_LIB not enabled for performance reasons), DPDK
applications inherit its dependencies on libibverbs and libmlx5 through
rte.app.mk.
This is an issue both when DPDK is delivered as a binary package (Linux
distributions) and for end users because rdma-core then propagates as a
mandatory dependency for everything.
Application writers relying on binary DPDK packages are not necessarily
aware of this fact and may end up delivering packages with broken
dependencies.
This patch therefore introduces an intermediate internal plug-in
hard-linked with rdma-core (to preserve symbol versioning) loaded by the
PMD through dlopen(), so that a missing rdma-core does not cause unresolved
symbols, allowing applications to start normally.
Signed-off-by: Adrien Mazarguil
---
config/common_base| 1 +
doc/guides/nics/mlx5.rst | 13
drivers/net/mlx5/Makefile | 31 ++-
drivers/net/mlx5/mlx5.c | 48 ++
mk/rte.app.mk | 4
5 files changed, 96 insertions(+), 1 deletion(-)
diff --git a/config/common_base b/config/common_base
index 6df20be0e..b9b421db7 100644
--- a/config/common_base
+++ b/config/common_base
@@ -306,6 +306,7 @@ CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
#
CONFIG_RTE_LIBRTE_MLX5_PMD=n
CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
+CONFIG_RTE_LIBRTE_MLX5_DLOPEN_DEPS=n
CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE=8
#
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 2e6d1e45a..a9e4bf51a 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -159,6 +159,19 @@ These options can be modified in the ``.config`` file.
Toggle compilation of librte_pmd_mlx5 itself.
+- ``CONFIG_RTE_LIBRTE_MLX5_DLOPEN_DEPS`` (default **n**)
+
+ Build PMD with additional code to make it loadable without hard
+ dependencies on **libibverbs** nor **libmlx5**, which may not be installed
+ on the target system.
+
+ In this mode, their presence is still required for it to run properly,
+ however their absence won't prevent a DPDK application from starting (with
+ ``CONFIG_RTE_BUILD_SHARED_LIB`` disabled) and they won't show up as
+ missing with ``ldd(1)``.
+
+ This option has no performance impact.
+
- ``CONFIG_RTE_LIBRTE_MLX5_DEBUG`` (default **n**)
Toggle debugging code and stricter compilation flags. Enabling this option
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index bdec30692..4b20d718b 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -33,9 +33,13 @@ include $(RTE_SDK)/mk/rte.vars.mk
# Library name.
LIB = librte_pmd_mlx5.a
+LIB_GLUE = librte_pmd_mlx5_glue.so
# Sources.
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5.c
+ifneq ($(CONFIG_RTE_LIBRTE_MLX5_DLOPEN_DEPS),y)
+SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_glue.c
+endif
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_rxq.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_txq.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_rxtx.c
@@ -53,7 +57,10 @@ SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_rss.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_mr.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_flow.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_socket.c
-SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_glue.c
+
+ifeq ($(CONFIG_RTE_LIBRTE_MLX5_DLOPEN_DEPS),y)
+INSTALL-$(CONFIG_RTE_LIBRTE_MLX5_PMD)-lib += $(LIB_GLUE)
+endif
# Basic CFLAGS.
CFLAGS += -O3
@@ -65,7 +72,13 @@ CFLAGS += -D_DEFAULT_SOURCE
CFLAGS += -D_XOPEN_SOURCE=600
CFLAGS += $(WERROR_FLAGS)
CFLAGS += -Wno-strict-prototypes
+ifeq ($(CONFIG_RTE_LIBRTE_MLX5_DLOPEN_DEPS),y)
+CFLAGS += -DMLX5_GLUE='"$(LIB_GLUE)"'
+CFLAGS_mlx5_glue.o += -fPIC
+LDLIBS += -ldl
+else
LDLIBS += -libverbs -lmlx5
+endif
LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
LDLIBS += -lrte_ethdev -lrte_net -lrte_kvargs
LDLIBS += -lrte_bus_pci
@@ -158,7 +171,23 @@ mlx5_autoconf.h: mlx5_autoconf.h.new
$(SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD):.c=.o): mlx5_autoconf.h
+# Generate dependency plug-in for rdma-core when the PMD must not be linked
+# directly, so that applications do not inherit this dependency.
+
+ifeq ($(CONFIG_RTE_LIBRTE_MLX5_DLOPEN_DEPS),y)
+
+$(LIB): $(LIB_GLUE)
+
+$(LIB_GLUE): mlx5_glue.o
+ $Q $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) \
+ -s -shared -o $@ $< -libverbs -lmlx5
+
+mlx5_glue.o: mlx5_autoconf.h
+
+endif
+
clean_mlx5: FORCE
$Q rm -f -- mlx5_autoconf.h mlx5_autoconf.h.new
+ $Q rm -f -- mlx5_glue.o $(LIB_GLUE)
clean: clean_mlx5
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index b911d0ad4..466a8b0a2 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -57,6 +58,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1075,6 +1077,47 @@ static struct rte_pci_driver mlx5_driver = {
[dpdk-dev] [PATCH v4 3/4] net/mlx5: move rdma-core calls to separate file
From: Nelio Laranjeiro
This lays the groundwork for externalizing rdma-core as an optional
run-time dependency instead of a mandatory one.
No functional change.
Signed-off-by: Nelio Laranjeiro
Signed-off-by: Adrien Mazarguil
---
drivers/net/mlx5/Makefile | 1 +
drivers/net/mlx5/mlx5.c| 44 ++---
drivers/net/mlx5/mlx5_ethdev.c | 7 +-
drivers/net/mlx5/mlx5_flow.c | 92 +-
drivers/net/mlx5/mlx5_glue.c | 352
drivers/net/mlx5/mlx5_glue.h | 106 +++
drivers/net/mlx5/mlx5_mr.c | 7 +-
drivers/net/mlx5/mlx5_rxq.c| 54 +++---
drivers/net/mlx5/mlx5_txq.c| 22 ++-
drivers/net/mlx5/mlx5_vlan.c | 13 +-
10 files changed, 586 insertions(+), 112 deletions(-)
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index a3984eb9f..bdec30692 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -53,6 +53,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_rss.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_mr.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_flow.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_socket.c
+SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_glue.c
# Basic CFLAGS.
CFLAGS += -O3
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 5a959f7c5..b911d0ad4 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -65,6 +65,7 @@
#include "mlx5_rxtx.h"
#include "mlx5_autoconf.h"
#include "mlx5_defs.h"
+#include "mlx5_glue.h"
/* Device parameter to enable RX completion queue compression. */
#define MLX5_RXQ_CQE_COMP_EN "rxq_cqe_comp_en"
@@ -218,8 +219,8 @@ mlx5_dev_close(struct rte_eth_dev *dev)
}
if (priv->pd != NULL) {
assert(priv->ctx != NULL);
- claim_zero(ibv_dealloc_pd(priv->pd));
- claim_zero(ibv_close_device(priv->ctx));
+ claim_zero(mlx5_glue->dealloc_pd(priv->pd));
+ claim_zero(mlx5_glue->close_device(priv->ctx));
} else
assert(priv->ctx == NULL);
if (priv->rss_conf.rss_key != NULL)
@@ -625,7 +626,7 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
/* Save PCI address. */
mlx5_dev[idx].pci_addr = pci_dev->addr;
- list = ibv_get_device_list(&i);
+ list = mlx5_glue->get_device_list(&i);
if (list == NULL) {
assert(errno);
if (errno == ENOSYS)
@@ -675,12 +676,12 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
" (SR-IOV: %s)",
list[i]->name,
sriov ? "true" : "false");
- attr_ctx = ibv_open_device(list[i]);
+ attr_ctx = mlx5_glue->open_device(list[i]);
err = errno;
break;
}
if (attr_ctx == NULL) {
- ibv_free_device_list(list);
+ mlx5_glue->free_device_list(list);
switch (err) {
case 0:
ERROR("cannot access device, is mlx5_ib loaded?");
@@ -699,7 +700,7 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
* Multi-packet send is supported by ConnectX-4 Lx PF as well
* as all ConnectX-5 devices.
*/
- mlx5dv_query_device(attr_ctx, &attrs_out);
+ mlx5_glue->dv_query_device(attr_ctx, &attrs_out);
if (attrs_out.flags & MLX5DV_CONTEXT_FLAGS_MPW_ALLOWED) {
if (attrs_out.flags & MLX5DV_CONTEXT_FLAGS_ENHANCED_MPW) {
DEBUG("Enhanced MPW is supported");
@@ -717,7 +718,7 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
cqe_comp = 0;
else
cqe_comp = 1;
- if (ibv_query_device_ex(attr_ctx, NULL, &device_attr))
+ if (mlx5_glue->query_device_ex(attr_ctx, NULL, &device_attr))
goto error;
INFO("%u port(s) detected", device_attr.orig_attr.phys_port_cnt);
@@ -794,15 +795,15 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
DEBUG("using port %u (%08" PRIx32 ")", port, test);
- ctx = ibv_open_device(ibv_dev);
+ ctx = mlx5_glue->open_device(ibv_dev);
if (ctx == NULL) {
err = ENODEV;
goto port_error;
}
- ibv_query_device_ex(ctx, NULL, &device_attr);
+ mlx5_glue->query_device_ex(ctx, NULL, &device_attr);
/* Check port status. */
- err = ibv_query_port(ctx, port, &port_attr);
+ err = mlx5_glue->query_port(ctx, port, &port_attr);
if (err) {
ERROR("port query failed: %s", strerror(err));
goto port_error;
@@ -817,11 +818,11 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct
rte_pc
[dpdk-dev] [PATCH v4 2/4] net/mlx4: spawn rdma-core dependency plug-in
When mlx4 is not compiled directly as an independent shared object (e.g. CONFIG_RTE_BUILD_SHARED_LIB not enabled for performance reasons), DPDK applications inherit its dependencies on libibverbs and libmlx4 through rte.app.mk. This is an issue both when DPDK is delivered as a binary package (Linux distributions) and for end users because rdma-core then propagates as a mandatory dependency for everything. Application writers relying on binary DPDK packages are not necessarily aware of this fact and may end up delivering packages with broken dependencies. This patch therefore introduces an intermediate internal plug-in hard-linked with rdma-core (to preserve symbol versioning) loaded by the PMD through dlopen(), so that a missing rdma-core does not cause unresolved symbols, allowing applications to start normally. Signed-off-by: Adrien Mazarguil --- config/common_base| 1 + doc/guides/nics/mlx4.rst | 13 +++ drivers/net/mlx4/Makefile | 29 + drivers/net/mlx4/mlx4.c | 49 ++ mk/rte.app.mk | 4 5 files changed, 96 insertions(+) diff --git a/config/common_base b/config/common_base index 170a38939..6df20be0e 100644 --- a/config/common_base +++ b/config/common_base @@ -298,6 +298,7 @@ CONFIG_RTE_LIBRTE_AVF_16BYTE_RX_DESC=n # CONFIG_RTE_LIBRTE_MLX4_PMD=n CONFIG_RTE_LIBRTE_MLX4_DEBUG=n +CONFIG_RTE_LIBRTE_MLX4_DLOPEN_DEPS=n CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8 # diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst index cab45dfe8..88161781c 100644 --- a/doc/guides/nics/mlx4.rst +++ b/doc/guides/nics/mlx4.rst @@ -86,6 +86,19 @@ These options can be modified in the ``.config`` file. Toggle compilation of librte_pmd_mlx4 itself. +- ``CONFIG_RTE_LIBRTE_MLX4_DLOPEN_DEPS`` (default **n**) + + Build PMD with additional code to make it loadable without hard + dependencies on **libibverbs** nor **libmlx4**, which may not be installed + on the target system. + + In this mode, their presence is still required for it to run properly, + however their absence won't prevent a DPDK application from starting (with + ``CONFIG_RTE_BUILD_SHARED_LIB`` disabled) and they won't show up as + missing with ``ldd(1)``. + + This option has no performance impact. + - ``CONFIG_RTE_LIBRTE_MLX4_DEBUG`` (default **n**) Toggle debugging code and stricter compilation flags. Enabling this option diff --git a/drivers/net/mlx4/Makefile b/drivers/net/mlx4/Makefile index 1d33c38ed..c004ac71c 100644 --- a/drivers/net/mlx4/Makefile +++ b/drivers/net/mlx4/Makefile @@ -33,12 +33,15 @@ include $(RTE_SDK)/mk/rte.vars.mk # Library name. LIB = librte_pmd_mlx4.a +LIB_GLUE = librte_pmd_mlx4_glue.so # Sources. SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4.c SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_ethdev.c SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_flow.c +ifneq ($(CONFIG_RTE_LIBRTE_MLX4_DLOPEN_DEPS),y) SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_glue.c +endif SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_intr.c SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_mr.c SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_rxq.c @@ -46,6 +49,10 @@ SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_rxtx.c SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_txq.c SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4_utils.c +ifeq ($(CONFIG_RTE_LIBRTE_MLX4_DLOPEN_DEPS),y) +INSTALL-$(CONFIG_RTE_LIBRTE_MLX4_PMD)-lib += $(LIB_GLUE) +endif + # Basic CFLAGS. CFLAGS += -O3 CFLAGS += -std=c11 -Wall -Wextra @@ -55,7 +62,13 @@ CFLAGS += -D_BSD_SOURCE CFLAGS += -D_DEFAULT_SOURCE CFLAGS += -D_XOPEN_SOURCE=600 CFLAGS += $(WERROR_FLAGS) +ifeq ($(CONFIG_RTE_LIBRTE_MLX4_DLOPEN_DEPS),y) +CFLAGS += -DMLX4_GLUE='"$(LIB_GLUE)"' +CFLAGS_mlx4_glue.o += -fPIC +LDLIBS += -ldl +else LDLIBS += -libverbs -lmlx4 +endif LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring LDLIBS += -lrte_ethdev -lrte_net -lrte_kvargs LDLIBS += -lrte_bus_pci @@ -109,7 +122,23 @@ mlx4_autoconf.h: mlx4_autoconf.h.new $(SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD):.c=.o): mlx4_autoconf.h +# Generate dependency plug-in for rdma-core when the PMD must not be linked +# directly, so that applications do not inherit this dependency. + +ifeq ($(CONFIG_RTE_LIBRTE_MLX4_DLOPEN_DEPS),y) + +$(LIB): $(LIB_GLUE) + +$(LIB_GLUE): mlx4_glue.o + $Q $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) \ + -s -shared -o $@ $< -libverbs -lmlx4 + +mlx4_glue.o: mlx4_autoconf.h + +endif + clean_mlx4: FORCE $Q rm -f -- mlx4_autoconf.h mlx4_autoconf.h.new + $Q rm -f -- mlx4_glue.o $(LIB_GLUE) clean: clean_mlx4 diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c index f304359bb..12e6b431c 100644 --- a/drivers/net/mlx4/mlx4.c +++ b/drivers/net/mlx4/mlx4.c @@ -37,6 +37,7 @@ */ #include +#include #include #include #include @@ -44,6 +45,7 @@ #include #include #include +#include /* Verbs headers do not support -pedantic. */ #ifdef PEDANTIC @@ -55,6 +57,7 @@ #endif #includ
Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel offloads
> -Original Message-
> From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> Sent: Tuesday, January 30, 2018 11:34 PM
> To: Xueming(Steven) Li ; Olivier MATZ
>
> Cc: dev@dpdk.org; Wu, Jingjing ; Shahaf Shuler
> ; Yongseok Koh ; Thomas Monjalon
> ; Yigit, Ferruh
> Subject: RE: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel
> offloads
>
>
>
> > -Original Message-
> > From: Xueming(Steven) Li [mailto:xuemi...@mellanox.com]
> > Sent: Tuesday, January 30, 2018 3:27 PM
> > To: Ananyev, Konstantin ; Olivier MATZ
> >
> > Cc: dev@dpdk.org; Wu, Jingjing ; Shahaf Shuler
> > ; Yongseok Koh ; Thomas
> > Monjalon ; Yigit, Ferruh
> > Subject: RE: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic
> > tunnel offloads
> >
> > Hi Ananyev,
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> > > Sent: Tuesday, January 30, 2018 9:28 PM
> > > To: Xueming(Steven) Li ; Olivier MATZ
> > >
> > > Cc: dev@dpdk.org; Wu, Jingjing ; Shahaf
> > > Shuler ; Yongseok Koh ;
> > > Thomas Monjalon ; Yigit, Ferruh
> > >
> > > Subject: RE: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic
> > > tunnel offloads
> > >
> > >
> > > Hi Xueming,
> > >
> > > > > > This patch introduce new TX offloads flag for devices that
> > > > > > support tunnel agnostic checksum and TSO offloads.
> > > > > >
> > > > > > The support from the device is for inner and outer checksums
> > > > > > on IPV4/TCP/UDP and TSO for *any packet with the following
> format*:
> > > > > >
> > > > > > < some headers > / [optional IPv4/IPv6] / [optional TCP/UDP] /
> > > > > > > > > > > headers> / [optional inner IPv4/IPv6] / [optional TCP/UDP]
> > > > > >
> > > > > > For example the following packets can use this feature:
> > > > > >
> > > > > > 1. eth / ipv4 / udp / VXLAN / ip / tcp 2. eth / ipv4 / GRE /
> > > > > > MPLS /
> > > > > > ipv4 / udp
> > > > >
> > > > > So in terms of usage - what is the difference with current TSO
> types?
> > > > > Konstantin
> > > > >
> > > >
> > > > Traditionally, HW only recognize "known" tunnel type, do TSO
> > > > calculation based on L3/L4 headers known to tunnel type. For
> > > > example, it must be
> > > > L2 header after VXLAN, then L3. While this Generic offloading
> > > > provides inner/outer L3/L4 header info(len and offset) to HW, and
> > > > thus tunnel info become less important. Please note the MPLS over
> > > > GRE tunnel in last example above.
> > >
> > > Ok, but I wonder when the user would like to do TSO on tunnel
> > > packet, for this offload - would he need to do something differently
> > > from what he has to do now:
> > > raise PKT_TX_TCP_SEG and related flags, raise appropriate
> > > PKT_TX_TUNNEL_* flag, fill l2_len, l3_len,
> l4_len,tso_segsz,outer_l2_len,outer_l3_len?
> > >
> >
> > Yes, these fields are sufficient except PKT_TX_TUNNEL_*, major target
> > of this new feature is to support "unknown" tunnel offloading, it
> supports "known"
> > tunnel type as well.
>
> Ok, but user would still need to set some flag to indicate that this is a
> tunnel packet, and he wants TSO over it, right?
> For pre-defined tunnel types it can be one of PKT_TX_TUNNEL_* (which
> actually means that user still have to know tunnel type anyway?) But for
> some not defined tunnel type - what it would be?
> Konstantin
>
As this feature target to TX path, Outer length as tunnel indication,
leave it empty if tunnel not defined.
But I think it good to define something like:
PKT_TX_TUNNEL_GENERIC = PKT_TX_TUNNEL_MASK
And a new flag PKT_TX_OUTER_UDP, how do you think?
> >
> > PKT_TX_TUNNEL_VXLAN has to be used as a hint if outer UDP expected.
> >
> > > Konstantin
> > >
> > > >
> > > > > >
> > > > > > Signed-off-by: Xueming Li
> > > > > > ---
> > > > > > lib/librte_ether/rte_ethdev.h | 10 ++
> > > > > > 1 file changed, 10 insertions(+)
> > > > > >
> > > > > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > > > > b/lib/librte_ether/rte_ethdev.h index 1a5b4cdc5..d8d08ccb2
> > > > > > 100644
> > > > > > --- a/lib/librte_ether/rte_ethdev.h
> > > > > > +++ b/lib/librte_ether/rte_ethdev.h
> > > > > > @@ -979,6 +979,16 @@ struct rte_eth_conf {
> > > > > > * the same mempool and has refcnt = 1.
> > > > > > */
> > > > > > #define DEV_TX_OFFLOAD_SECURITY 0x0002
> > > > > > +/**< Device supports generic tunnel checksum and TSO offloading.
> > > > > > + * Checksum and TSO are done based on following mbuf fields:
> > > > > > + * - Length of each header
> > > > > > + * - Type of outer/inner L3 type, IPv4 or IPv6
> > > > > > + * - Type of outer/inner L4 type, TCP or UDP.
> > > > > > + * - PKT_TX_TUNNEL_VXLAN implies outer UDP type.
> > > > > > + * - PKT_TX_TCP_SEG implies inner TCP type.
> > > > > > + * Tunnel type is optional except PKT_TX_TUNNEL_VXLAN to hint
> > > > > > +outer
> > > UDP.
> > > > > > + */
> > > > > > +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO 0x0004
> > > > > >
> > > >
Re: [dpdk-dev] [PATCH] test/test: add new tests in 18.02-rc2 to meson build
On Tue, Jan 30, 2018 at 03:20:35PM +, Luca Boccassi wrote: > On Tue, 2018-01-30 at 14:41 +, Bruce Richardson wrote: > > Signed-off-by: Bruce Richardson > > --- > > test/test/meson.build | 6 ++ > > 1 file changed, 6 insertions(+) > > Reviewed-by: Luca Boccassi > > LGTM! > Applied to dpdk-next-build /Bruce
[dpdk-dev] [PATCH] net/mlx4: fix drop flow resources not freed
This patch fixes the drop-flow resources not being freed when the device
is closed.
Issue can be observed when running testpmd and adding the following rule
more than once:
"flow create 0 ingress pattern eth / end actions drop / end"
then either exiting testpmd using the "quit" command or by running the
command: "port stop all"
Fixes: d3a7e09234e4 ("net/mlx4: allocate drop flow resources on demand")
Cc: sta...@dpdk.org
Signed-off-by: Moti Haimovsky
---
drivers/net/mlx4/mlx4_flow.c | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/net/mlx4/mlx4_flow.c b/drivers/net/mlx4/mlx4_flow.c
index fb84060..9e6d8dc 100644
--- a/drivers/net/mlx4/mlx4_flow.c
+++ b/drivers/net/mlx4/mlx4_flow.c
@@ -895,6 +895,30 @@ struct mlx4_drop {
}
/**
+ * Return the number of active drop flow rules currently present
+ * in the list of flows.
+ * Active flow is defined as a flow associated with an ibv_flow.
+ *
+ * @param priv
+ * Pointer to private structure.
+ *
+ * @return
+ * Number of active drop-flows.
+ */
+static int
+drop_refcnt(struct priv *priv)
+{
+ struct rte_flow *flow;
+ int count = 0;
+
+ LIST_FOREACH(flow, &priv->flows, next) {
+ if (flow->drop && flow->ibv_flow)
+ count++;
+ }
+ return count;
+}
+
+/**
* Get a drop flow rule resources instance.
*
* @param priv
@@ -910,9 +934,8 @@ struct mlx4_drop {
struct mlx4_drop *drop = priv->drop;
if (drop) {
- assert(drop->refcnt);
+ assert(drop_refcnt(priv));
assert(drop->priv == priv);
- ++drop->refcnt;
return drop;
}
drop = rte_malloc(__func__, sizeof(*drop), 0);
@@ -955,8 +978,10 @@ struct mlx4_drop {
static void
mlx4_drop_put(struct mlx4_drop *drop)
{
- assert(drop->refcnt);
- if (--drop->refcnt)
+ int refcnt = drop_refcnt(drop->priv);
+
+ assert(refcnt >= 0);
+ if (refcnt)
return;
drop->priv->drop = NULL;
claim_zero(ibv_destroy_qp(drop->qp));
--
1.8.3.1
Re: [dpdk-dev] [PATCH 0/5] dpdk: enhance EXPERIMENTAL api tagging
On Mon, Jan 29, 2018 at 10:46:27PM +0100, Thomas Monjalon wrote: > 22/01/2018 02:48, Neil Horman: > > v5 Changes > > * Clean ups suggested by Thomas > > There were a lot of new functions to tag when rebasing this v5. > Rebased and applied, thanks. > Sorry, not clear what you mean by this. Are you saying that there were several new experimental API's added recently that my initial set of tags missed? If so, thanks for doing that. I will also be sending another patch set soon, to reconcile API's that are documented as experimental but not listed in the version map as such Neil
[dpdk-dev] [PATCH] eal: fix default mempool ops returning NULL
If '--mbuf-pool-ops' is not passed to EAL as command line argument then
rte_eal_mbuf_default_mempool_ops will return NULL.
Instead check if internal_config.user_mbuf_pool_ops_name is NULL and
return compile time RTE_MBUF_DEFAULT_MEMPOOL_OPS.
Fixes: 8b0f7f43413 ("mbuf: maintain user and compile time mempool ops name")
Signed-off-by: Pavan Nikhilesh
---
Currently, test/test/test_mempool_autotest is broken as it relies on
rte_eal_mbuf_default_mempool_ops().
lib/librte_eal/bsdapp/eal/eal.c | 3 +++
lib/librte_eal/linuxapp/eal/eal.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index ba1811a00..07b229fc7 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -115,6 +115,9 @@ int rte_cycles_vmware_tsc_map;
const char *
rte_eal_mbuf_default_mempool_ops(void)
{
+ if (internal_config.user_mbuf_pool_ops_name == NULL)
+ return RTE_MBUF_DEFAULT_MEMPOOL_OPS;
+
return internal_config.user_mbuf_pool_ops_name;
}
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 66f7585a3..ddcdb6e1f 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -125,6 +125,9 @@ int rte_cycles_vmware_tsc_map;
const char *
rte_eal_mbuf_default_mempool_ops(void)
{
+ if (internal_config.user_mbuf_pool_ops_name == NULL)
+ return RTE_MBUF_DEFAULT_MEMPOOL_OPS;
+
return internal_config.user_mbuf_pool_ops_name;
}
--
2.16.0
[dpdk-dev] [PATCH v2 0/2] fix eBPF TAP RSS leakage and map key handling
v2: fix eBPF RSS map key handling v1: fix eBPF file descriptors leakage Ophir Munk (2): net/tap: fix eBPF file descriptors leakage net/tap: fix eBPF RSS map key handling drivers/net/tap/tap_flow.c | 104 +++-- 1 file changed, 73 insertions(+), 31 deletions(-) -- 2.7.4
[dpdk-dev] [PATCH v2 1/2] net/tap: fix eBPF file descriptors leakage
When a user creates an RSS rule, the tap PMD dynamically allocates
a 'flow' data structure, and uploads BPF programs (represented by file
descriptors) to the kernel.
The kernel might reject the rule (due to filters overlap, for example)
in which case, flow memory should be freed and BPF file descriptors
should be closed.
In the corrupted code there were scenarios where BPF file descriptors
were not closed.
The fix is to add a new function - tap_flow_free(), which will make sure
to always close BPF file descriptors before freeing the flow allocated
memory.
Fixes: 036d721a8229 ("net/tap: implement RSS using eBPF")
Signed-off-by: Ophir Munk
---
drivers/net/tap/tap_flow.c | 57 ++
1 file changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/net/tap/tap_flow.c b/drivers/net/tap/tap_flow.c
index 6aa53a7..533879d 100644
--- a/drivers/net/tap/tap_flow.c
+++ b/drivers/net/tap/tap_flow.c
@@ -212,6 +212,10 @@ tap_flow_create(struct rte_eth_dev *dev,
const struct rte_flow_action actions[],
struct rte_flow_error *error);
+static void
+tap_flow_free(struct pmd_internals *pmd,
+ struct rte_flow *flow);
+
static int
tap_flow_destroy(struct rte_eth_dev *dev,
struct rte_flow *flow,
@@ -1311,6 +1315,38 @@ tap_flow_set_handle(struct rte_flow *flow)
}
/**
+ * Free the flow opened file descriptors and allocated memory
+ *
+ * @param[in] flow
+ * Pointer to the flow to free
+ *
+ */
+static void
+tap_flow_free(struct pmd_internals *pmd, struct rte_flow *flow)
+{
+ int i;
+
+ if (!flow)
+ return;
+
+ if (pmd->rss_enabled) {
+ /* Close flow BPF file descriptors */
+ for (i = 0; i < SEC_MAX; i++)
+ if (flow->bpf_fd[i] != 0) {
+ close(flow->bpf_fd[i]);
+ flow->bpf_fd[i] = 0;
+ }
+
+ /* Release the map key for this RSS rule */
+ bpf_rss_key(KEY_CMD_RELEASE, &flow->key_idx);
+ flow->key_idx = 0;
+ }
+
+ /* Free flow allocated memory */
+ rte_free(flow);
+}
+
+/**
* Create a flow.
*
* @see rte_flow_create()
@@ -1428,7 +1464,7 @@ tap_flow_create(struct rte_eth_dev *dev,
if (remote_flow)
rte_free(remote_flow);
if (flow)
- rte_free(flow);
+ tap_flow_free(pmd, flow);
return NULL;
}
@@ -1450,7 +1486,6 @@ tap_flow_destroy_pmd(struct pmd_internals *pmd,
struct rte_flow_error *error)
{
struct rte_flow *remote_flow = flow->remote_flow;
- int i;
int ret = 0;
LIST_REMOVE(flow, next);
@@ -1476,22 +1511,6 @@ tap_flow_destroy_pmd(struct pmd_internals *pmd,
"couldn't receive kernel ack to our request");
goto end;
}
- /* Close opened BPF file descriptors of this flow */
- for (i = 0; i < SEC_MAX; i++)
- if (flow->bpf_fd[i] != 0) {
- close(flow->bpf_fd[i]);
- flow->bpf_fd[i] = 0;
- }
-
- /* Release map key for this RSS rule */
- ret = bpf_rss_key(KEY_CMD_RELEASE, &flow->key_idx);
- if (ret < 0) {
- rte_flow_error_set(
- error, EINVAL, RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
- "Failed to release BPF RSS key");
-
- goto end;
- }
if (remote_flow) {
remote_flow->msg.nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
@@ -1520,7 +1539,7 @@ tap_flow_destroy_pmd(struct pmd_internals *pmd,
end:
if (remote_flow)
rte_free(remote_flow);
- rte_free(flow);
+ tap_flow_free(pmd, flow);
return ret;
}
--
2.7.4
[dpdk-dev] [PATCH v2 2/2] net/tap: fix eBPF RSS map key handling
This commit addresses a case of RSS and non RSS flows mixture.
In the corrupted code, if a non-RSS flow is destroyed, it has an eBPF map
index 0 (initialized upon flow creation). This might unintentionally remove
RSS entry 0 from eBPF map.
To fix this issue, add an offset to the real index during a KEY_CMD_GET
operation, and subtract this offset during a KEY_CMD_RELEASE operation, in
order to restore the real index.
Thus, if a non RSS flow is falsely trying to release map entry 0 - The
offset subtraction will calculate the real map index as an
out-of-range value, and the release operation will be silently ignored.
Fixes: 036d721a8229 ("net/tap: implement RSS using eBPF")
Signed-off-by: Ophir Munk
---
drivers/net/tap/tap_flow.c | 47 ++
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/drivers/net/tap/tap_flow.c b/drivers/net/tap/tap_flow.c
index 533879d..18cfb91 100644
--- a/drivers/net/tap/tap_flow.c
+++ b/drivers/net/tap/tap_flow.c
@@ -1797,6 +1797,7 @@ tap_flow_implicit_flush(struct pmd_internals *pmd, struct
rte_flow_error *error)
}
#define MAX_RSS_KEYS 256
+#define KEY_IDX_OFFSET (3 * MAX_RSS_KEYS)
#define SEC_NAME_CLS_Q "cls_q"
const char *sec_name[SEC_MAX] = {
@@ -1953,38 +1954,62 @@ static int rss_enable(struct pmd_internals *pmd,
static int bpf_rss_key(enum bpf_rss_key_e cmd, __u32 *key_idx)
{
__u32 i;
- int err = -1;
+ int err = 0;
static __u32 num_used_keys;
static __u32 rss_keys[MAX_RSS_KEYS] = {KEY_STAT_UNSPEC};
static __u32 rss_keys_initialized;
switch (cmd) {
case KEY_CMD_GET:
- if (!rss_keys_initialized)
+ if (!rss_keys_initialized) {
+ err = -1;
break;
+ }
- if (num_used_keys == RTE_DIM(rss_keys))
+ if (num_used_keys == RTE_DIM(rss_keys)) {
+ err = -1;
break;
+ }
*key_idx = num_used_keys % RTE_DIM(rss_keys);
while (rss_keys[*key_idx] == KEY_STAT_USED)
*key_idx = (*key_idx + 1) % RTE_DIM(rss_keys);
rss_keys[*key_idx] = KEY_STAT_USED;
+
+ /*
+* Add an offset to key_idx in order to handle a case of
+* RSS and non RSS flows mixture.
+* If a non RSS flow is destroyed it has an eBPF map
+* index 0 (initialized on flow creation) and might
+* unintentionally remove RSS entry 0 from eBPF map.
+* To avoid this issue, add an offset to the real index
+* during a KEY_CMD_GET operation and subtract this offset
+* during a KEY_CMD_RELEASE operation in order to restore
+* the real index.
+*/
+ *key_idx += KEY_IDX_OFFSET;
num_used_keys++;
- err = 0;
break;
case KEY_CMD_RELEASE:
- if (!rss_keys_initialized) {
- err = 0;
+ if (!rss_keys_initialized)
+ break;
+
+ /*
+* Subtract offest to restore real key index
+* If a non RSS flow is falsely trying to release map
+* entry 0 - the offset subtraction will calculate the real
+* map index as an out-of-range value and the release operation
+* will be silently ignored.
+*/
+ __u32 key = *key_idx - KEY_IDX_OFFSET;
+ if (key >= RTE_DIM(rss_keys))
break;
- }
- if (rss_keys[*key_idx] == KEY_STAT_USED) {
- rss_keys[*key_idx] = KEY_STAT_AVAILABLE;
+ if (rss_keys[key] == KEY_STAT_USED) {
+ rss_keys[key] = KEY_STAT_AVAILABLE;
num_used_keys--;
- err = 0;
}
break;
@@ -1994,7 +2019,6 @@ static int bpf_rss_key(enum bpf_rss_key_e cmd, __u32
*key_idx)
rss_keys_initialized = 1;
num_used_keys = 0;
- err = 0;
break;
case KEY_CMD_DEINIT:
@@ -2003,7 +2027,6 @@ static int bpf_rss_key(enum bpf_rss_key_e cmd, __u32
*key_idx)
rss_keys_initialized = 0;
num_used_keys = 0;
- err = 0;
break;
default:
--
2.7.4
Re: [dpdk-dev] [PATCH 0/5] ARMv8: enable DPAA-X driver compilation
25/01/2018 10:53, Hemant Agrawal: > This patchset enables DPAA drivers compilation for ARM targets. > This also includes patches to fix the DPAA compilation for clang > compiler. > > Note that the dpaa(x) specific config files are still preserved > to continue customer support. They also contain some of the ARM > performance tuning flags. e.g the default ARM cache size of 128 > is not optimal for NXP platforms. > > However, these configs will be cleaned up and eventually be > removed once a dynamic mechanisms are developed to detect the > performance settings. > > Hemant Agrawal (5): > bus/dpaa: fix compilation warnings with clang > bus/dpaa: fix unused function warning with clang > crypto/dpaa2_sec: fix enum conversion for GCM > crypto/dpaa_sec: fix enum conversion for GCM > config: enable dpaaX drivers compilation for ARMv8 First patches are squashed (2nd patch log was not accurate anyway). Last patch is replaced by the v2. Series applied, thanks
Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel offloads
> > > >
> > > > > > > This patch introduce new TX offloads flag for devices that
> > > > > > > support tunnel agnostic checksum and TSO offloads.
> > > > > > >
> > > > > > > The support from the device is for inner and outer checksums
> > > > > > > on IPV4/TCP/UDP and TSO for *any packet with the following
> > format*:
> > > > > > >
> > > > > > > < some headers > / [optional IPv4/IPv6] / [optional TCP/UDP] /
> > > > > > > > > > > > > headers> / [optional inner IPv4/IPv6] / [optional TCP/UDP]
> > > > > > >
> > > > > > > For example the following packets can use this feature:
> > > > > > >
> > > > > > > 1. eth / ipv4 / udp / VXLAN / ip / tcp 2. eth / ipv4 / GRE /
> > > > > > > MPLS /
> > > > > > > ipv4 / udp
> > > > > >
> > > > > > So in terms of usage - what is the difference with current TSO
> > types?
> > > > > > Konstantin
> > > > > >
> > > > >
> > > > > Traditionally, HW only recognize "known" tunnel type, do TSO
> > > > > calculation based on L3/L4 headers known to tunnel type. For
> > > > > example, it must be
> > > > > L2 header after VXLAN, then L3. While this Generic offloading
> > > > > provides inner/outer L3/L4 header info(len and offset) to HW, and
> > > > > thus tunnel info become less important. Please note the MPLS over
> > > > > GRE tunnel in last example above.
> > > >
> > > > Ok, but I wonder when the user would like to do TSO on tunnel
> > > > packet, for this offload - would he need to do something differently
> > > > from what he has to do now:
> > > > raise PKT_TX_TCP_SEG and related flags, raise appropriate
> > > > PKT_TX_TUNNEL_* flag, fill l2_len, l3_len,
> > l4_len,tso_segsz,outer_l2_len,outer_l3_len?
> > > >
> > >
> > > Yes, these fields are sufficient except PKT_TX_TUNNEL_*, major target
> > > of this new feature is to support "unknown" tunnel offloading, it
> > supports "known"
> > > tunnel type as well.
> >
> > Ok, but user would still need to set some flag to indicate that this is a
> > tunnel packet, and he wants TSO over it, right?
> > For pre-defined tunnel types it can be one of PKT_TX_TUNNEL_* (which
> > actually means that user still have to know tunnel type anyway?) But for
> > some not defined tunnel type - what it would be?
> > Konstantin
> >
>
> As this feature target to TX path, Outer length as tunnel indication,
> leave it empty if tunnel not defined.
Sorry, I didn't get it.
We need to let PMD know that it is a tunnel packet, right?
So we do need to raise PKT_TX_TUNNEL_* flag.
>
> But I think it good to define something like:
> PKT_TX_TUNNEL_GENERIC = PKT_TX_TUNNEL_MASK
Yes, that's an option, I would probably name it PKT_TX_TUNNEL_UNKNOWN.
> And a new flag PKT_TX_OUTER_UDP, how do you think?
Not sure why do we need it?
HW still needs to know outer_l4_type to be able to work correctly?
Konstantin
>
> > >
> > > PKT_TX_TUNNEL_VXLAN has to be used as a hint if outer UDP expected.
> > >
> > > > Konstantin
> > > >
> > > > >
> > > > > > >
> > > > > > > Signed-off-by: Xueming Li
> > > > > > > ---
> > > > > > > lib/librte_ether/rte_ethdev.h | 10 ++
> > > > > > > 1 file changed, 10 insertions(+)
> > > > > > >
> > > > > > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > > > > > b/lib/librte_ether/rte_ethdev.h index 1a5b4cdc5..d8d08ccb2
> > > > > > > 100644
> > > > > > > --- a/lib/librte_ether/rte_ethdev.h
> > > > > > > +++ b/lib/librte_ether/rte_ethdev.h
> > > > > > > @@ -979,6 +979,16 @@ struct rte_eth_conf {
> > > > > > > * the same mempool and has refcnt = 1.
> > > > > > > */
> > > > > > > #define DEV_TX_OFFLOAD_SECURITY 0x0002
> > > > > > > +/**< Device supports generic tunnel checksum and TSO offloading.
> > > > > > > + * Checksum and TSO are done based on following mbuf fields:
> > > > > > > + * - Length of each header
> > > > > > > + * - Type of outer/inner L3 type, IPv4 or IPv6
> > > > > > > + * - Type of outer/inner L4 type, TCP or UDP.
> > > > > > > + * - PKT_TX_TUNNEL_VXLAN implies outer UDP type.
> > > > > > > + * - PKT_TX_TCP_SEG implies inner TCP type.
> > > > > > > + * Tunnel type is optional except PKT_TX_TUNNEL_VXLAN to hint
> > > > > > > +outer
> > > > UDP.
> > > > > > > + */
> > > > > > > +#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO 0x0004
> > > > > > >
> > > > > > > /*
> > > > > > > * If new Tx offload capabilities are defined, they also must
> > > > > > > be
> > > > > > > --
> > > > > > > 2.13.3
Re: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel offloads
> -Original Message-
> From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> Sent: Wednesday, January 31, 2018 12:03 AM
> To: Xueming(Steven) Li ; Olivier MATZ
>
> Cc: dev@dpdk.org; Wu, Jingjing ; Shahaf Shuler
> ; Yongseok Koh ; Thomas Monjalon
> ; Yigit, Ferruh
> Subject: RE: [dpdk-dev] [PATCH v2 1/5] ethdev: introduce Tx generic tunnel
> offloads
>
>
>
> > > > >
> > > > > > > > This patch introduce new TX offloads flag for devices that
> > > > > > > > support tunnel agnostic checksum and TSO offloads.
> > > > > > > >
> > > > > > > > The support from the device is for inner and outer
> > > > > > > > checksums on IPV4/TCP/UDP and TSO for *any packet with the
> > > > > > > > following
> > > format*:
> > > > > > > >
> > > > > > > > < some headers > / [optional IPv4/IPv6] / [optional
> > > > > > > > TCP/UDP] / > > > > > > > headers> / [optional inner IPv4/IPv6] / [optional TCP/UDP]
> > > > > > > >
> > > > > > > > For example the following packets can use this feature:
> > > > > > > >
> > > > > > > > 1. eth / ipv4 / udp / VXLAN / ip / tcp 2. eth / ipv4 / GRE
> > > > > > > > / MPLS /
> > > > > > > > ipv4 / udp
> > > > > > >
> > > > > > > So in terms of usage - what is the difference with current
> > > > > > > TSO
> > > types?
> > > > > > > Konstantin
> > > > > > >
> > > > > >
> > > > > > Traditionally, HW only recognize "known" tunnel type, do TSO
> > > > > > calculation based on L3/L4 headers known to tunnel type. For
> > > > > > example, it must be
> > > > > > L2 header after VXLAN, then L3. While this Generic offloading
> > > > > > provides inner/outer L3/L4 header info(len and offset) to HW,
> > > > > > and thus tunnel info become less important. Please note the
> > > > > > MPLS over GRE tunnel in last example above.
> > > > >
> > > > > Ok, but I wonder when the user would like to do TSO on tunnel
> > > > > packet, for this offload - would he need to do something
> > > > > differently from what he has to do now:
> > > > > raise PKT_TX_TCP_SEG and related flags, raise appropriate
> > > > > PKT_TX_TUNNEL_* flag, fill l2_len, l3_len,
> > > l4_len,tso_segsz,outer_l2_len,outer_l3_len?
> > > > >
> > > >
> > > > Yes, these fields are sufficient except PKT_TX_TUNNEL_*, major
> > > > target of this new feature is to support "unknown" tunnel
> > > > offloading, it
> > > supports "known"
> > > > tunnel type as well.
> > >
> > > Ok, but user would still need to set some flag to indicate that this
> > > is a tunnel packet, and he wants TSO over it, right?
> > > For pre-defined tunnel types it can be one of PKT_TX_TUNNEL_* (which
> > > actually means that user still have to know tunnel type anyway?) But
> > > for some not defined tunnel type - what it would be?
> > > Konstantin
> > >
> >
> > As this feature target to TX path, Outer length as tunnel indication,
> > leave it empty if tunnel not defined.
>
> Sorry, I didn't get it.
> We need to let PMD know that it is a tunnel packet, right?
> So we do need to raise PKT_TX_TUNNEL_* flag.
>
In my current code, mbuf.outer_l2_len is used to test tunnel packet.
Agree a new tunnel flag would be better.
> >
> > But I think it good to define something like:
> > PKT_TX_TUNNEL_GENERIC = PKT_TX_TUNNEL_MASK
>
> Yes, that's an option, I would probably name it PKT_TX_TUNNEL_UNKNOWN.
>
> > And a new flag PKT_TX_OUTER_UDP, how do you think?
>
> Not sure why do we need it?
> HW still needs to know outer_l4_type to be able to work correctly?
For tunnel type like vxlan, if outer UDP present, hw has to update UDP
length field for each TSO packet segment.
> Konstantin
>
> >
> > > >
> > > > PKT_TX_TUNNEL_VXLAN has to be used as a hint if outer UDP expected.
> > > >
> > > > > Konstantin
> > > > >
> > > > > >
> > > > > > > >
> > > > > > > > Signed-off-by: Xueming Li
> > > > > > > > ---
> > > > > > > > lib/librte_ether/rte_ethdev.h | 10 ++
> > > > > > > > 1 file changed, 10 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > > > > > > b/lib/librte_ether/rte_ethdev.h index 1a5b4cdc5..d8d08ccb2
> > > > > > > > 100644
> > > > > > > > --- a/lib/librte_ether/rte_ethdev.h
> > > > > > > > +++ b/lib/librte_ether/rte_ethdev.h
> > > > > > > > @@ -979,6 +979,16 @@ struct rte_eth_conf {
> > > > > > > > * the same mempool and has refcnt = 1.
> > > > > > > > */
> > > > > > > > #define DEV_TX_OFFLOAD_SECURITY 0x0002
> > > > > > > > +/**< Device supports generic tunnel checksum and TSO
> offloading.
> > > > > > > > + * Checksum and TSO are done based on following mbuf fields:
> > > > > > > > + * - Length of each header
> > > > > > > > + * - Type of outer/inner L3 type, IPv4 or IPv6
> > > > > > > > + * - Type of outer/inner L4 type, TCP or UDP.
> > > > > > > > + * - PKT_TX_TUNNEL_VXLAN implies outer UDP type.
> > > > > > > > + * - PKT_TX_TCP_SEG implies inner TCP type.
> > > > > > > > + * Tunnel type is optional except PKT_TX_TUNNEL_VXLAN to
> > > > > > > > +hint outer
> > > > > UDP.
Re: [dpdk-dev] [PATCH v2 0/2] fix eBPF TAP RSS leakage and map key handling
The patches look good to me. Good catch. Acked-by: Pascal Mazon for the series. On 30/01/2018 17:00, Ophir Munk wrote: > v2: > fix eBPF RSS map key handling > > v1: > fix eBPF file descriptors leakage > > Ophir Munk (2): > net/tap: fix eBPF file descriptors leakage > net/tap: fix eBPF RSS map key handling > > drivers/net/tap/tap_flow.c | 104 > +++-- > 1 file changed, 73 insertions(+), 31 deletions(-) >
Re: [dpdk-dev] [PATCH 0/5] dpdk: enhance EXPERIMENTAL api tagging
30/01/2018 16:54, Neil Horman: > On Mon, Jan 29, 2018 at 10:46:27PM +0100, Thomas Monjalon wrote: > > 22/01/2018 02:48, Neil Horman: > > > v5 Changes > > > * Clean ups suggested by Thomas > > > > There were a lot of new functions to tag when rebasing this v5. > > Rebased and applied, thanks. > > > Sorry, not clear what you mean by this. Are you saying that there were > several > new experimental API's added recently that my initial set of tags missed? If > so, thanks for doing that. I will also be sending another patch set soon, to > reconcile API's that are documented as experimental but not listed in the > version map as such I meant that I have applied a lot of new experimental functions after you sent the v5. So I had to add the tag and CFLAGS for these new functions. Usual rebase work. About reconciling experimental functions and map, we should also consider upgrading some functions to non-experimental.
Re: [dpdk-dev] [PATCH] net/ixgbe: fix reconfiguration of rx queues
On Tue, Jan 30, 2018 at 8:14 AM, Ananyev, Konstantin <
konstantin.anan...@intel.com> wrote:
>
>
> > > >
> > > > From: "Charles (Chas) Williams"
> > > >
> > > > .dev_configure() may be called again after RX queues have been setup.
> > > > This has the effect of clearing whatever setting the RX queues made
> for
> > > > rx_bulk_alloc_allowed or rx_vec_allowed. Only reset this
> configuration
> > > > is there aren't any currently allocated queues.
> > > >
> > > > Fixes: 01fa1d6215fa ("ixgbe: unify Rx setup")
> > > >
> > > > Signed-off-by: Chas Williams
> > > > ---
> > > > drivers/net/ixgbe/ixgbe_ethdev.c | 18 --
> > > > 1 file changed, 16 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > > index 37eb668..b39249a 100644
> > > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > > @@ -2348,6 +2348,7 @@ ixgbe_dev_configure(struct rte_eth_dev *dev)
> > > > struct ixgbe_adapter *adapter =
> > > > (struct ixgbe_adapter *)dev->data->dev_private;
> > > > int ret;
> > > > + uint16_t i;
> > > >
> > > > PMD_INIT_FUNC_TRACE();
> > > > /* multipe queue mode checking */
> > > > @@ -2363,11 +2364,17 @@ ixgbe_dev_configure(struct rte_eth_dev *dev)
> > > >
> > > > /*
> > > >* Initialize to TRUE. If any of Rx queues doesn't meet the
> bulk
> > > > - * allocation or vector Rx preconditions we will reset it.
> > > > + * allocation or vector Rx preconditions we will reset it. We
> > > > + * can only do this is there aren't any existing RX queues.
> > > >*/
> > > > + for (i = 0; i < dev->data->nb_rx_queues; i++) {
> > > > + if (dev->data->rx_queues[i])
> > > > + goto out;
> > > > + }
> > > I don't see why this is needed.
> > > It surely should be possible to reconfigure device with different
> > > number of queues.
> > > Konstantin
> > >
> > > Yes, you can add new queues but you shouldn't reset the bulk and vec
> settings
> > > that have already been chosen by the previously allocated queues.
> > Why is that? Might be in new queue setup user will change settings?
> >
> > There is no requirement that the user allocates all the RX queues in the
> same way.
> > Some could have a different numbers of descs which is one of the checks
> in
> > check_rx_burst_bulk_alloc_preconditions()
>
> Exactly. That's why after dev_configure() user has to call queue_setup()
> for *all*
> queues he plans to use.
>
Where the API or documentation does it say that this is necessary? If this
was a requirement
then rte_eth_dev_configure() should drop every allocated queue. Since it
doesn't do this
I can only assume that you are allowed to keep using queues after calling
rte_eth_dev_configure()
without having to set them up again.
>
> >
> >
> >
> > > If those queues
> > > set rx_bulk_alloc_allowed to be false, then this is going to cause an
> issue with queue
> > > release later on.
> >
> > Could you be a bit more specific here:
> > What you think will be broken in ixgbe_rx_queue_release() in that case?
> >
> > Sorry, I mispoke. It's this function, ixgbe_reset_rx_queue(),
> >
> > /*
> > * By default, the Rx queue setup function allocates enough
> memory for
> > * IXGBE_MAX_RING_DESC. The Rx Burst bulk allocation function
> requires
> > * extra memory at the end of the descriptor ring to be zero'd
> out.
> > */
> > if (adapter->rx_bulk_alloc_allowed)
> > /* zero out extra memory */
> > len += RTE_PMD_IXGBE_RX_MAX_BURST;
> >
> > /*
> > * Zero out HW ring memory. Zero out extra memory at the end of
> > * the H/W ring so look-ahead logic in Rx Burst bulk alloc
> function
> > * reads extra memory as zeros.
> > */
> > for (i = 0; i < len; i++) {
> > rxq->rx_ring[i] = zeroed_desc;
> > }
> >
> > So you potentially write past the rx_ring[] you allocated.
>
> We always allocate rx_ring[] to maximum possible size plus space for fake
> descriptors:
>
> drivers/net/ixgbe/ixgbe_rxtx.h:
> #define RX_RING_SZ ((IXGBE_MAX_RING_DESC + RTE_PMD_IXGBE_RX_MAX_BURST) * \
> sizeof(union ixgbe_adv_rx_desc))
>
> then at ixgbe_dev_rx_queue_setup(...):
>
> /*
> * Allocate RX ring hardware descriptors. A memzone large enough to
> * handle the maximum ring size is allocated in order to allow for
> * resizing in later calls to the queue setup function.
> */
> rz = rte_eth_dma_zone_reserve(dev, "rx_ring", queue_idx,
> RX_RING_SZ, IXGBE_ALIGN, socket_id);
> ...
> rxq->rx_ring = (union ixgbe_adv_rx_desc *) rz->addr;
>
What about here?
len = nb_desc;
if (adapter->rx_bulk_alloc_allowed)
len += RTE_PMD_IXGBE_RX_MAX_BURST;
rxq->sw_ring = rt
Re: [dpdk-dev] [PATCH] net/mlx4: fix drop flow resources not freed
Hi Moti,
On Tue, Jan 30, 2018 at 05:54:00PM +0200, Moti Haimovsky wrote:
> This patch fixes the drop-flow resources not being freed when the device
> is closed.
> Issue can be observed when running testpmd and adding the following rule
> more than once:
> "flow create 0 ingress pattern eth / end actions drop / end"
> then either exiting testpmd using the "quit" command or by running the
> command: "port stop all"
>
> Fixes: d3a7e09234e4 ("net/mlx4: allocate drop flow resources on demand")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Moti Haimovsky
Thanks for investigating this problem, however I do not think the proposed
patch uses the right approach to address it, more below.
> ---
> drivers/net/mlx4/mlx4_flow.c | 33 +
> 1 file changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/mlx4/mlx4_flow.c b/drivers/net/mlx4/mlx4_flow.c
> index fb84060..9e6d8dc 100644
> --- a/drivers/net/mlx4/mlx4_flow.c
> +++ b/drivers/net/mlx4/mlx4_flow.c
> @@ -895,6 +895,30 @@ struct mlx4_drop {
> }
>
> /**
> + * Return the number of active drop flow rules currently present
> + * in the list of flows.
> + * Active flow is defined as a flow associated with an ibv_flow.
> + *
> + * @param priv
> + * Pointer to private structure.
> + *
> + * @return
> + * Number of active drop-flows.
> + */
> +static int
> +drop_refcnt(struct priv *priv)
> +{
> + struct rte_flow *flow;
> + int count = 0;
> +
> + LIST_FOREACH(flow, &priv->flows, next) {
> + if (flow->drop && flow->ibv_flow)
> + count++;
> + }
> + return count;
> +}
> +
> +/**
> * Get a drop flow rule resources instance.
> *
> * @param priv
> @@ -910,9 +934,8 @@ struct mlx4_drop {
> struct mlx4_drop *drop = priv->drop;
>
> if (drop) {
> - assert(drop->refcnt);
> + assert(drop_refcnt(priv));
> assert(drop->priv == priv);
> - ++drop->refcnt;
> return drop;
> }
> drop = rte_malloc(__func__, sizeof(*drop), 0);
> @@ -955,8 +978,10 @@ struct mlx4_drop {
> static void
> mlx4_drop_put(struct mlx4_drop *drop)
> {
> - assert(drop->refcnt);
> - if (--drop->refcnt)
> + int refcnt = drop_refcnt(drop->priv);
> +
> + assert(refcnt >= 0);
> + if (refcnt)
> return;
> drop->priv->drop = NULL;
> claim_zero(ibv_destroy_qp(drop->qp));
It looks like brute force to me, as in "if the counter doesn't have the
right value at this point, decrement it until it does, then assert() will
finally shut up". Getting rid of the refcount altogether would have also
worked.
We need to find out why we do not end up with a number of mlx5_drop_put()
calls matching that of mlx5_drop_get(). One is likely missing somewhere.
I'll have a look as well.
--
Adrien Mazarguil
6WIND
Re: [dpdk-dev] [PATCH v3 07/11] drivers/raw: introduce skeleton rawdev driver
There is a compilation error with clang-5.0:
30/01/2018 15:57, Shreyansh Jain:
> +struct queue_buffers {
> + void *bufs[SKELETON_QUEUE_MAX_DEPTH];
> +};
> +
> +static struct queue_buffers queue_buf[SKELETON_MAX_QUEUES] = {0};
drivers/raw/skeleton_rawdev/skeleton_rawdev.c:46:63: fatal error:
suggest braces around initialization of subobject [-Wmissing-braces]
static struct queue_buffers queue_buf[SKELETON_MAX_QUEUES] = {0};
