Re: [dpdk-dev] [dpdk-announce] [HELP REQUIRED] call for reviews
On Fri, Jun 26, 2020 at 7:43 PM Thomas Monjalon wrote: > Our next milestone is approaching, 20.08-rc1 should be in 12 days : > http://core.dpdk.org/roadmap/#dates > and the roadmap is very long: > http://core.dpdk.org/roadmap/#2008 > > We all want to have our code reviewed and accepted. > In order to have a small hope of reaching our goals, > we need a large participation in reviews. > > PLEASE REVIEW some patches from the list below. [..] Hi Thomas, Wanted to check re the flow perf application which AFAIK almost made it for 20.05 but now is still waiting in patchworks [1]. I am using it and actually there are few enhancements to be applied for serving more advanced use-cases waiting for the initial acceptance to be submitted. I am politely watching it in patchworks without any real progress for couple of weeks.. so? Thanks, Or. [1] https://patchwork.dpdk.org/cover/70851/
Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte flow
On 6/26/20 2:10 PM, Jerin Jacob wrote: > On Fri, Jun 26, 2020 at 4:16 PM Thomas Monjalon wrote: >> >> 26/06/2020 12:35, Jerin Jacob: >>> On Fri, Jun 26, 2020 at 12:59 AM Thomas Monjalon >>> wrote: 25/06/2020 19:55, Jerin Jacob: > On Thu, Jun 25, 2020 at 10:20 PM Jiawei Wang wrote: >> >> When using full offload, all traffic will be handled by the HW, and >> directed to the requested vf or wire, the control application loses >> visibility on the traffic. >> So there's a need for an action that will enable the control application >> some visibility. >> >> The solution is introduced a new action that will sample the incoming >> traffic and send a duplicated traffic in some predefined ratio to the >> application, while the original packet will continue to the target >> destination. >> >> The packets sampled equals is '1/ratio', if the ratio value be set to 1 >> , means that the packets would be completely mirrored. The sample packet >> can be assigned with different set of actions from the original packet. >> >> In order to support the sample packet in rte_flow, new rte_flow action >> definition RTE_FLOW_ACTION_TYPE_SAMPLE and structure >> rte_flow_action_sample > > Isn't mirroring the packet? How about, RTE_FLOW_ACTION_TYPE_MIRROR > I am not able to understand, Why it is called sample. Sampling is a partial mirroring. >>> >>> I think, By definition, _sampling_ is the _selection_ of items from a >>> specific group. >>> I think, _sampling_ is not dictating, what is the real action for the >>> "selected" items. >>> One can get confused with the selected ones can be for forward, drop >>> any other action. >> >> I see. Good design question (I will let others reply). >> >>> So IMO, explicit mirror keyword usage makes it is clear. >>> >>> Some more related questions: >>> 1) What is the real use case for ratio? I am not against adding a >>> ratio attribute if the MLX hardware supports it. It will be good to >>> know the use case from the application perspective? And what basics >>> application set ratio != 1? >> >> If I understand well, some applications want to check, >> by picking random packets, that the processing is not failing. > > Not clear to me. I will wait for another explanation if any. > In what basics application set .1 vs .8? > >> >>> 2) If it is for "rate-limiting" or "policing", why not use rte_mtr >>> object (rte_mtr.h) via rte_flow action. >>> 3) One of the issue for driver developers and application writers are >>> overlapping APIs. This would overlap with rte_eth_mirror_rule_set() >>> API. >>> >>> Can we deprecate rte_eth_mirror_rule_set() API? It will be a pain for >>> all to have overlapping APIs. We have not fixed the VLAN filter API >>> overlap with rte_flow in ethdev. Its being TODO for multiple releases >>> now. >> >> Ooooh yes! >> I think flow-based API is more powerful, and should deprecate >> old port-based API. > > +1 from me. +1 > it is taking too much effort and time to make support duplicate APIs. > >> I want to help deprecating such API in 20.11 if possible. > > Please start that discussion. In this case, it is clear API overlap > with rte_eth_mirror_rule_set(). > We should not have two separate paths for the same function in the > same ethdev library. > > > >> Full mirroring is sampling 100% packets (ratio = 1). That's why only one action is enough. >> >> >>
Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte flow
On 6/25/20 7:26 PM, Jiawei Wang wrote:
> When using full offload, all traffic will be handled by the HW, and
> directed to the requested vf or wire, the control application loses
> visibility on the traffic.
> So there's a need for an action that will enable the control application
> some visibility.
>
> The solution is introduced a new action that will sample the incoming
> traffic and send a duplicated traffic in some predefined ratio to the
> application, while the original packet will continue to the target
> destination.
>
> The packets sampled equals is '1/ratio', if the ratio value be set to 1
> , means that the packets would be completely mirrored. The sample packet
> can be assigned with different set of actions from the original packet.
>
> In order to support the sample packet in rte_flow, new rte_flow action
> definition RTE_FLOW_ACTION_TYPE_SAMPLE and structure rte_flow_action_sample
> will be introduced.
>
> Signed-off-by: Jiawei Wang
[snip]
> @@ -2709,6 +2716,28 @@ struct rte_flow_action {
> struct rte_flow;
>
> /**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * RTE_FLOW_ACTION_TYPE_SAMPLE
> + *
> + * Adds a sample action to a matched flow.
> + *
> + * The matching packets will be duplicated to a special queue or vport
> + * in the predefined probabiilty, All the packets continues processing
> + * on the default flow path.
> + *
> + * When the sample ratio is set to 1 then the packets will be 100% mirrored.
> + * Additional action list be supported to add for sampled or mirrored
> packets.
> + */
> +struct rte_flow_action_sample {
> + /* packets sampled equals to '1/ratio' */
> + const uint32_t ratio;
> + /* sub-action list specific for the sampling hit cases */
> + const struct rte_flow_action *actions;
This design idea does not look good to me from the very
beginning. IMHO it does not fit flow API overall design.
I mean sub-action list.
As I understand Linux iptables solves it on match level
(i.e. in pattern). E.g. "limit" extension which is basically
sampling. Sampling using meta pattern item in combination
with PASSTHRU action (to make sampling actions non-terminating
if required) is a better solution from design point of view.
Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag
On 6/26/20 7:56 PM, Bruce Richardson wrote:
> On Wed, Apr 22, 2020 at 11:45:53PM +0200, Lukasz Wojciechowski wrote:
>> A new boolean meson build flag is introduced with this patch: rte_debug.
>> To enable this option add -Drte_debug=true to the meson configure command.
>>
>> By enabling this flag the globaly defined macro RTE_DEBUG becomes
>> defined. It should be used for enabling debug code in all dpdk project
>> components. Using this flag allows to make additional checks or tests
>> and provide additional logs even in performance sensitive parts of code.
>>
>> The flag is disabled by default.
>>
>> Additionally for all enabled to be built libraries
>> a RTE_DEBUG_{library name} is defined and assigned a value 1.
>> This standardize names of library specific debug macros. Those can
>> be used also without rte_debug option by using CFLAGS="-D..." build
>> parameter.
>>
>> Code put inside RTE_DEBUG* #ifdef sections should be also put inside
>> if (rte_log_can_log(...)) condition to allow run-time filtering of
>> sanity checks, validations, logs and dumps when using rte_debug option.
>>
>> Libraries will be adjusted to the change in separate patches.
>>
>> Suggested-by: Bruce Richardson
>> Signed-off-by: Lukasz Wojciechowski
>
> The drivers are missing debug flag options, which probably need to be
> defined as _ e.g. RTE_DEBUG_NET_I40E,
> RTE_DEBUG_EVENT_SW, etc.
>
> However, this is definitely a good start.
>
> Reviewed-by: Bruce Richardson
> Acked-by: Bruce Richardson
>
Acked-by: Andrew Rybchenko
Re: [dpdk-dev] [RFC v2 0/1] add flow action context API
Hi On Fri, Jun 26, 2020 at 2:44 PM Jerin Jacob wrote: > On Sat, Jun 20, 2020 at 7:02 PM Andrey Vesnovaty > wrote: > > > > Hi, and thanks a lot for your RFC v1 comments. > > > > RFC v2 emphasize the intent for sharing the flow action: > > * The term 'action context' was unclear and replaced with > >'shared action'. > > * RFC v2 subject became 'add flow shared action API'. > > * all proposed APIs renamed according the above. > > > > The new shared action is an independent entity decoupled from any flow > > while any flow can reuse such an action. Please go over the RFC > > description, it was almost entirely rewritten. > > > > @Jerin Jacob: > > Thanks again for your comments, it made me admit that v1 description was > > incomplete & unclear. I hope v2 will be better at least in terms of > > clarity. > > The public API and its usage is very clear. Thanks for this RFC. My pleasure. > > I think, RFC v2 still not addressing the concern raised in the > http://mails.dpdk.org/archives/dev/2020-June/169296.html. > > Since MLX hardware has an HW based shared object it is fine to have > public API based on that level of abstraction. > But at the PMD driver level we need to choose the correct abstraction > to support all PMD and support shared object scheme if possible. > > I purpose to introduce something below or similar > int (*action_update) > (struct rte_eth_dev *, > struct rte_flow *flow, > const struct rte_flow_action [], > struct rte_flow_error *); > Where this callback suppose to belong (struct rte_flow_ops)? How should it be implemented by PMD? Is it about shared action and if "yes" why there is 'flow' argument? > > in addition to: shared_action_create, shared_action_destroy, > shared_action_update, shared_action_query > > Have generic implementation of above, if action_update callback is not > NULL. "is not NULL" -> "is NULL"? > So that, it can work all PMDs and to > avoid the duplication of "complex" shared session management code. > Do you mean shared action in use by multiple flows by "shared session"?
[dpdk-dev] [PATCH] net/mlx5: fix flow META item validation
When flow is inserted with meta match item it requires a certain
register support.
As part of the flow validation of such flows, the validation
function is missing a check that the mlx5 driver is not in
legacy mode in terms of extended meta data support
(MLX5_XMETA_MODE_LEGACY flag).
If the driver is in legacy mode it will cause downstream
function that allocates needed register for meta data.
The fix checks explicitly the conditions for support of
meta data in FDB mode. if the conditions are not met
an error message will be issued.
Fixes: 9bf26e1318 ("ethdev: move egress metadata to dynamic field")
Cc: viachesl...@mellanox.com
Cc: sta...@dpdk.org
Signed-off-by: Shy Shyman
---
drivers/net/mlx5/mlx5_flow_dv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 6318bd99cd..e037643c98 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -1479,6 +1479,13 @@ flow_dv_validate_item_meta(struct rte_eth_dev *dev
__rte_unused,
"isn't supported");
if (reg != REG_A)
nic_mask.data = priv->sh->dv_meta_mask;
+ } else if (attr->transfer) {
+ return rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ITEM, item,
+ "extended metadata feature "
+ "should be enabled when "
+ "meta item is requested "
+ "with e-switch mode ");
}
if (!mask)
mask = &rte_flow_item_meta_mask;
--
2.21.0
Re: [dpdk-dev] [PATCH v2 3/3] eal/windows: librte_net build on Windows
> Subject: Re: [PATCH v2 3/3] eal/windows: librte_net build on Windows > > > diff --git a/lib/librte_eal/common/meson.build > > b/lib/librte_eal/common/meson.build > > index e1bdaf024..05e40a26b 100644 > > --- a/lib/librte_eal/common/meson.build > > +++ b/lib/librte_eal/common/meson.build > > @@ -28,6 +28,7 @@ if is_windows > > 'malloc_elem.c', > > 'malloc_heap.c', > > 'rte_malloc.c', > > + 'rte_random.c', > > Hitting an error when building on Windows (SDK 10.0.18362) with Clang 9.0.1: Hi Dmitry, I'm trying to reproduce the error you had, I installed the latest SDK (10.0.19041.0) but I can't find the clang v9.0.1 for Windows. Can you redirect/instruct me how did you get it for Windows ? Thanks, Fady > > [7/72] Compiling C object > lib/76b5a35@@rte_eal@sta/librte_eal_common_rte_random.c.obj. > FAILED: lib/76b5a35@@rte_eal@sta/librte_eal_common_rte_random.c.obj > clang @lib/76b5a35@@rte_eal@sta/librte_eal_common_rte_random.c.obj.rsp > In file included from ../../../../lib/librte_eal/common/rte_random.c:13: > In file included from ..\..\..\..\lib/librte_eal/include\rte_eal.h:20: > In file included from ..\..\..\..\lib/librte_eal/include\rte_per_lcore.h:25: > In file included from ..\..\..\..\lib/librte_eal/windows/include\pthread.h:20: > In file included from > ..\..\..\..\lib/librte_eal/windows/include\rte_windows.h:22: > In file included from C:\Program Files (x86)\Windows > Kits\10\include\10.0.18362.0\um\windows.h:171: > In file included from C:\Program Files (x86)\Windows > Kits\10\include\10.0.18362.0\shared\windef.h:24: > In file included from C:\Program Files (x86)\Windows > Kits\10\include\10.0.18362.0\shared\minwindef.h:182: > C:\Program Files (x86)\Windows > Kits\10\include\10.0.18362.0\um\winnt.h:3324:1: error: conflicting types for > '_m_prefetchw' > _m_prefetchw ( > ^ > C:\Program Files\LLVM\lib\clang\9.0.1\include\prfchwintrin.h:50:1: note: > previous definition is here _m_prefetchw(void *__P) > > Similar issue was seen before: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp > atches.dpdk.org%2Fpatch%2F59912%2F%23101780&data=02%7C01%7Cfady > %40mellanox.com%7Ce7e40349f14c4dbf43a408d8154f3bd1%7Ca652971c7d2e4d9 > ba6a4d149256f461b%7C0%7C0%7C637282777343746975&sdata=CsPof2eM3 > 32uC9pyDsOaeiR6voScjsbmLA0euAQHw5U%3D&reserved=0 > > -- > Dmitry Kozlyuk
Re: [dpdk-dev] [PATCH 0/3] mlx5: LACP handling for bonded devices
Hi, > -Original Message- > From: dev On Behalf Of Shiri Kuzin > Sent: Tuesday, June 23, 2020 11:41 AM > To: dev@dpdk.org > Cc: Matan Azrad ; Slava Ovsiienko > > Subject: [dpdk-dev] [PATCH 0/3] mlx5: LACP handling for bonded devices > > When the driver has a bond configured, LACP traffic should be steered to > kernel to manage the bond using a new rdma-core API. > This is done by creating a new internal action and adding a new devarg that > will allow the user to manage the bond and get lacp traffic if they wish. > > Shiri Kuzin (3): > common/mlx5: add default miss action > net/mlx5: add default miss action to flow engine > net/mlx5: add new devarg for LACP packets control > > doc/guides/nics/mlx5.rst | 10 +++ > doc/guides/rel_notes/release_20_08.rst | 1 + > drivers/common/mlx5/Makefile | 5 ++ > drivers/common/mlx5/linux/meson.build | 2 + > drivers/common/mlx5/linux/mlx5_glue.c | 13 > drivers/common/mlx5/linux/mlx5_glue.h | 1 + > drivers/net/mlx5/mlx5.c| 6 ++ > drivers/net/mlx5/mlx5.h| 11 +++ > drivers/net/mlx5/mlx5_flow.c | 92 > drivers/net/mlx5/mlx5_flow.h | 11 ++- > drivers/net/mlx5/mlx5_flow_dv.c| 127 > +++-- > drivers/net/mlx5/mlx5_trigger.c| 9 +++ > 12 files changed, 280 insertions(+), 8 deletions(-) > > -- > 1.8.3.1 Series applied to next-net-mlx, Kindest regards, Raslan Darawsheh
[dpdk-dev] [PATCH v2 4/5] telemetry: implement empty stubs for Windows
Telemetry didn't compile under Windows.
Empty stubs implementation was added for Windows.
Signed-off-by: Fady Bader
---
lib/librte_telemetry/rte_telemetry.h| 4 +++
lib/librte_telemetry/telemetry.c| 51 -
lib/librte_telemetry/telemetry_legacy.c | 26 -
3 files changed, 79 insertions(+), 2 deletions(-)
diff --git a/lib/librte_telemetry/rte_telemetry.h
b/lib/librte_telemetry/rte_telemetry.h
index eb7f2c917c..bad255c385 100644
--- a/lib/librte_telemetry/rte_telemetry.h
+++ b/lib/librte_telemetry/rte_telemetry.h
@@ -5,6 +5,10 @@
#include
#include
+#ifdef RTE_EXEC_ENV_WINDOWS
+#include
+#endif
+
#ifndef _RTE_TELEMETRY_H_
#define _RTE_TELEMETRY_H_
diff --git a/lib/librte_telemetry/telemetry.c b/lib/librte_telemetry/telemetry.c
index e7e3d861dd..c5443193a9 100644
--- a/lib/librte_telemetry/telemetry.c
+++ b/lib/librte_telemetry/telemetry.c
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2020 Intel Corporation
*/
-
+#ifndef RTE_EXEC_ENV_WINDOWS
#include
#include
#include
@@ -20,6 +20,20 @@
#include "telemetry_data.h"
#include "rte_telemetry_legacy.h"
+#else
+
+/* includes for Windows */
+#include
+#include
+
+#include "rte_telemetry.h"
+#include "telemetry_json.h"
+#include "telemetry_data.h"
+#include "rte_telemetry_legacy.h"
+
+#endif
+
+#ifndef RTE_EXEC_ENV_WINDOWS
#define MAX_CMD_LEN 56
#define MAX_HELP_LEN 64
#define MAX_OUTPUT_LEN (1024 * 16)
@@ -40,16 +54,23 @@ struct socket {
};
static struct socket v2_socket; /* socket for v2 telemetry */
static struct socket v1_socket; /* socket for v1 telemetry */
+#endif
+
static char telemetry_log_error[1024]; /* Will contain error on init failure */
+
+#ifndef RTE_EXEC_ENV_WINDOWS
/* list of command callbacks, with one command registered by default */
static struct cmd_callback callbacks[TELEMETRY_MAX_CALLBACKS];
static int num_callbacks; /* How many commands are registered */
/* Used when accessing or modifying list of command callbacks */
static rte_spinlock_t callback_sl = RTE_SPINLOCK_INITIALIZER;
+#endif
int
rte_telemetry_register_cmd(const char *cmd, telemetry_cb fn, const char *help)
{
+#ifndef RTE_EXEC_ENV_WINDOWS
+
int i = 0;
if (strlen(cmd) >= MAX_CMD_LEN || fn == NULL || cmd[0] != '/'
@@ -73,8 +94,19 @@ rte_telemetry_register_cmd(const char *cmd, telemetry_cb fn,
const char *help)
rte_spinlock_unlock(&callback_sl);
return 0;
+
+#else
+
+ RTE_SET_USED(cmd);
+ RTE_SET_USED(fn);
+ RTE_SET_USED(help);
+
+ return 0;
+
+#endif
}
+#ifndef RTE_EXEC_ENV_WINDOWS
static int
list_commands(const char *cmd __rte_unused, const char *params __rte_unused,
struct rte_tel_data *d)
@@ -396,11 +428,14 @@ telemetry_v2_init(const char *runtime_dir, rte_cpuset_t
*cpuset)
return 0;
}
+#endif
int32_t
rte_telemetry_init(const char *runtime_dir, rte_cpuset_t *cpuset,
const char **err_str)
{
+#ifndef RTE_EXEC_ENV_WINDOWS
+
if (telemetry_v2_init(runtime_dir, cpuset) != 0) {
*err_str = telemetry_log_error;
return -1;
@@ -409,4 +444,18 @@ rte_telemetry_init(const char *runtime_dir, rte_cpuset_t
*cpuset,
*err_str = telemetry_log_error;
}
return 0;
+
+#else
+
+ RTE_SET_USED(runtime_dir);
+ RTE_SET_USED(cpuset);
+ RTE_SET_USED(err_str);
+
+ snprintf(telemetry_log_error, sizeof(telemetry_log_error),
+ "Telemetry is not supported on Windows.");
+
+ return 0;
+
+#endif
}
+
diff --git a/lib/librte_telemetry/telemetry_legacy.c
b/lib/librte_telemetry/telemetry_legacy.c
index a341fe4ebd..674f9c40ef 100644
--- a/lib/librte_telemetry/telemetry_legacy.c
+++ b/lib/librte_telemetry/telemetry_legacy.c
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2020 Intel Corporation
*/
-
+#ifndef RTE_EXEC_ENV_WINDOWS
#include
#include
#include
@@ -15,6 +15,15 @@
#include "rte_telemetry_legacy.h"
+#else
+
+#include
+
+#include "rte_telemetry_legacy.h"
+
+#endif
+#ifndef RTE_EXEC_ENV_WINDOWS
+
#define MAX_LEN 128
#define BUF_SIZE 1024
#define CLIENTS_UNREG_ACTION "\"action\":2"
@@ -48,12 +57,15 @@ struct json_command
callbacks[TELEMETRY_LEGACY_MAX_CALLBACKS] = {
};
int num_legacy_callbacks = 1;
static rte_spinlock_t callback_sl = RTE_SPINLOCK_INITIALIZER;
+#endif
int
rte_telemetry_legacy_register(const char *cmd,
enum rte_telemetry_legacy_data_req data_req,
telemetry_legacy_cb fn)
{
+#ifndef RTE_EXEC_ENV_WINDOWS
+
if (fn == NULL)
return -EINVAL;
if (num_legacy_callbacks >= (int) RTE_DIM(callbacks))
@@ -71,8 +83,19 @@ rte_telemetry_legacy_register(const char *cmd,
rte_spinlock_unlock(&callback_sl);
return 0;
+
+#else
+
+ RTE_SET_USED(cmd);
+ RTE_SET_USED(data_req);
+ RTE_SET_USED(fn);
+
+ return 0;
+
[dpdk-dev] [PATCH v2 1/5] eal: added interrupts empty stubs
The ethdev lib uses interrupts. Interrupts are not implemented for Windows.
To solve this, empty interrupt stubs were added under Windows.
Signed-off-by: Fady Bader
---
lib/librte_eal/windows/eal_interrupts.c | 17 +
lib/librte_eal/windows/meson.build | 1 +
2 files changed, 18 insertions(+)
create mode 100644 lib/librte_eal/windows/eal_interrupts.c
diff --git a/lib/librte_eal/windows/eal_interrupts.c
b/lib/librte_eal/windows/eal_interrupts.c
new file mode 100644
index 00..1e3c6d20d2
--- /dev/null
+++ b/lib/librte_eal/windows/eal_interrupts.c
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+#include
+
+int
+rte_intr_rx_ctl(struct rte_intr_handle *intr_handle,
+ int epfd, int op, unsigned int vec, void *data)
+{
+ RTE_SET_USED(intr_handle);
+ RTE_SET_USED(epfd);
+ RTE_SET_USED(op);
+ RTE_SET_USED(vec);
+ RTE_SET_USED(data);
+
+ return -ENOTSUP;
+}
diff --git a/lib/librte_eal/windows/meson.build
b/lib/librte_eal/windows/meson.build
index 08c888e018..c5a19648d6 100644
--- a/lib/librte_eal/windows/meson.build
+++ b/lib/librte_eal/windows/meson.build
@@ -17,6 +17,7 @@ sources += files(
'eal_timer.c',
'fnmatch.c',
'getopt.c',
+ 'eal_interrupts.c',
)
dpdk_conf.set10('RTE_EAL_NUMA_AWARE_HUGEPAGES', true)
--
2.16.1.windows.4
[dpdk-dev] [PATCH v2 2/5] eal: updated export list for Windows
Added eal functions used by ethdev lib to the export list under Windows. Signed-off-by: Fady Bader --- lib/librte_eal/rte_eal_exports.def | 10 ++ 1 file changed, 10 insertions(+) diff --git a/lib/librte_eal/rte_eal_exports.def b/lib/librte_eal/rte_eal_exports.def index 20f7346962..3b96bbc10d 100644 --- a/lib/librte_eal/rte_eal_exports.def +++ b/lib/librte_eal/rte_eal_exports.def @@ -29,6 +29,7 @@ EXPORTS rte_eal_tailq_register rte_eal_using_phys_addrs rte_free + rte_get_tsc_hz rte_hexdump rte_log rte_malloc @@ -148,3 +149,12 @@ EXPORTS rte_mem_page_size rte_mem_unmap rte_rand + + rte_class_register + rte_devargs_parse + rte_class_find_by_name + rte_socket_id + rte_strerror + rte_intr_rx_ctl + rte_log_register + rte_log_set_level \ No newline at end of file -- 2.16.1.windows.4
[dpdk-dev] [PATCH v2 0/5] compiling ethdev lib under windows
Added needed changes in order to get ethdev compiling under windows.
Depends-on: series-10382 ("compile librte_net for windows")
v2: fixed logging issue in telemetry lib.
Fady Bader (5):
eal: added interrupts empty stubs
eal: updated export list for Windows
ethdev: remove structs from export list
telemetry: implement empty stubs for Windows
ethdev: compiling ethdev under Windows
lib/librte_eal/rte_eal_exports.def | 10 +++
lib/librte_eal/windows/eal_interrupts.c | 17 +++
lib/librte_eal/windows/meson.build | 1 +
lib/librte_ethdev/rte_ethdev_version.map | 2 --
lib/librte_telemetry/rte_telemetry.h | 4 +++
lib/librte_telemetry/telemetry.c | 51 +++-
lib/librte_telemetry/telemetry_legacy.c | 26 +++-
lib/meson.build | 7 +++--
8 files changed, 112 insertions(+), 6 deletions(-)
create mode 100644 lib/librte_eal/windows/eal_interrupts.c
--
2.16.1.windows.4
[dpdk-dev] [PATCH v2 5/5] ethdev: compiling ethdev under Windows
Compiling needed libraries for ethdev under Windows. Signed-off-by: Fady Bader --- lib/meson.build | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lib/meson.build b/lib/meson.build index 6317309ecf..34366cd614 100644 --- a/lib/meson.build +++ b/lib/meson.build @@ -37,9 +37,12 @@ libraries = [ if is_windows libraries = [ - 'kvargs','eal', + 'kvargs', + 'telemetry', # basic info querying + 'eal', 'ring', - 'mempool','mbuf', 'net', 'pci', ] # only supported libraries for windows + 'mempool','mbuf', 'net', 'meter', 'ethdev', 'pci', + ] # only supported libraries for windows endif default_cflags = machine_args -- 2.16.1.windows.4
[dpdk-dev] [PATCH v2 3/5] ethdev: remove structs from export list
Some ethdev structs were present in ethdev export list.
There structs were removed from the export list.
Signed-off-by: Fady Bader
---
lib/librte_ethdev/rte_ethdev_version.map | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/librte_ethdev/rte_ethdev_version.map
b/lib/librte_ethdev/rte_ethdev_version.map
index 7155056045..eb36766dcd 100644
--- a/lib/librte_ethdev/rte_ethdev_version.map
+++ b/lib/librte_ethdev/rte_ethdev_version.map
@@ -89,7 +89,6 @@ DPDK_20.0 {
rte_eth_iterator_next;
rte_eth_led_off;
rte_eth_led_on;
- rte_eth_link;
rte_eth_link_get;
rte_eth_link_get_nowait;
rte_eth_macaddr_get;
@@ -104,7 +103,6 @@ DPDK_20.0 {
rte_eth_rx_queue_setup;
rte_eth_set_queue_rate_limit;
rte_eth_speed_bitflag;
- rte_eth_stats;
rte_eth_stats_get;
rte_eth_stats_reset;
rte_eth_timesync_adjust_time;
--
2.16.1.windows.4
Re: [dpdk-dev] [PATCH v9 09/10] bus/pci: support Windows with bifurcated drivers
> From: Narcisa Ana Maria Vasile
> On Wed, Jun 24, 2020 at 11:28:46AM +0300, tal...@mellanox.com wrote:
> > From: Tal Shnaiderman
> >
> > Uses SetupAPI.h functions to scan PCI tree.
> > Uses DEVPKEY_Device_Numa_Node to get the PCI NUMA node.
> > Uses SPDRP_BUSNUMBER and SPDRP_BUSNUMBER to get the BDF.
> > scanning currently supports types RTE_KDRV_NONE.
> >
> > Signed-off-by: Tal Shnaiderman
> > ---
> > drivers/bus/pci/windows/pci.c| 263
> ++-
> > lib/librte_eal/rte_eal_exports.def | 1 +
> > lib/librte_eal/windows/include/rte_windows.h | 1 +
> > 3 files changed, 261 insertions(+), 4 deletions(-)
> >
> > int
> > rte_pci_scan(void)
> > {
> > - return 0;
> > + int ret = -1;
> > + DWORD device_index = 0, found_device = 0;
> > + HDEVINFO dev_info;
> > + SP_DEVINFO_DATA device_info_data;
> > +
> > + /* for debug purposes, PCI can be disabled */
> > + if (!rte_eal_has_pci())
> > + return 0;
> > +
> > + dev_info = SetupDiGetClassDevs(&GUID_DEVCLASS_NET,
> TEXT("PCI"), NULL,
> > + DIGCF_PRESENT);
>
> Should we search for PCI devices by all classes to account for future support
> of drivers that are not part of the the Net class (e.g. netuio driver)? E.g.:
> SetupDiGetClassDevs(NULL, TEXT("PCI"), NULL, DIGCF_PRESENT |
> DIGCF_ALLCLASSES);
>
> Alternatively, since this patchset supports only RTE_KDRV_NONE, we can
> change it when introducing support for other types.
>
I'd go with adding it when needed, since the netuio driver addition to bus/pci
is being worked on.
> > + if (dev_info == INVALID_HANDLE_VALUE) {
> > + RTE_LOG_WIN32_ERR("SetupDiGetClassDevs(pci_scan)");
> > + RTE_LOG(ERR, EAL, "Unable to enumerate PCI devices.\n");
> > + goto end;
> > +
Re: [dpdk-dev] [PATCH] net/octeontx2: fix dmac filtering
On Thu, Jun 4, 2020 at 11:29 AM Sunil Kumar Kori wrote:
>
> >-Original Message-
> >From: dev On Behalf Of Harman Kalra
> >Sent: Wednesday, June 3, 2020 8:22 PM
> >To: Jerin Kollanukkaran ; Nithin Kumar Dabilpuram
> >; Kiran Kumar Kokkilagadda
> >
> >Cc: dev@dpdk.org; Harman Kalra ; sta...@dpdk.org
> >Subject: [dpdk-dev] [PATCH] net/octeontx2: fix dmac filtering
> >
> >Issue has been observed where packets are getting dropped
> >at DMAC filtering if a new dmac address is added before
> >starting of port.
> >
> >Fixes: c43adf61682f ("net/octeontx2: add unicast MAC filter")
> >Cc: sta...@dpdk.org
> >
> >Signed-off-by: Harman Kalra
> >---
> >2.18.0
> Acked-by: Sunil Kumar Kori
Acked-by: Jerin Jacob
Applied to dpdk-next-net-mrvl/master. Thanks
>
Re: [dpdk-dev] [PATCH] common/mlx5: fix code arrangement in tag allocation
Hi,
> -Original Message-
> From: dev On Behalf Of Michael Baum
> Sent: Wednesday, June 24, 2020 4:21 PM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Slava Ovsiienko
> ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] common/mlx5: fix code arrangement in tag
> allocation
>
> Flow tag action is supported only when the driver has DR or DV support.
> The tag allocation is adjusted to the modes DV or DR.
>
> In case both DR and DV are not supported in the system, the driver
> handles static code for error report.
> This error code, wrongly, was compiled when DV is supported while in
> this case it cannot be accessed at all.
>
> Ignore the aforementioned static error code in case of DV by
> preprocessor commands rearrangement.
>
> Fixes: cbb66daa3c85 ("net/mlx5: prepare Direct Verbs for Direct Rule")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Michael Baum
> Acked-by: Matan Azrad
> ---
> drivers/common/mlx5/linux/mlx5_glue.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/common/mlx5/linux/mlx5_glue.c
> b/drivers/common/mlx5/linux/mlx5_glue.c
> index c91ee33..a41650d 100644
> --- a/drivers/common/mlx5/linux/mlx5_glue.c
> +++ b/drivers/common/mlx5/linux/mlx5_glue.c
> @@ -752,7 +752,7 @@
> #ifdef HAVE_IBV_FLOW_DV_SUPPORT
> #ifdef HAVE_MLX5DV_DR
> return mlx5dv_dr_action_create_tag(tag);
> -#else
> +#else /* HAVE_MLX5DV_DR */
> struct mlx5dv_flow_action_attr *action;
> action = malloc(sizeof(*action));
> if (!action)
> @@ -760,11 +760,12 @@
> action->type = MLX5DV_FLOW_ACTION_TAG;
> action->tag_value = tag;
> return action;
> -#endif
> -#endif
> +#endif /* HAVE_MLX5DV_DR */
> +#else /* HAVE_IBV_FLOW_DV_SUPPORT */
> (void)tag;
> errno = ENOTSUP;
> return NULL;
> +#endif /* HAVE_IBV_FLOW_DV_SUPPORT */
> }
>
> static void *
> --
> 1.8.3.1
Patch apply to next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [dpdk-dev] [PATCH 4/4] net/qede: add support for get register operation
On Sun, Jun 28, 2020 at 11:29 AM Rasesh Mody wrote:
>
> Add support for .get_reg eth_dev ops which will be used to collect the
> firmware debug data.
>
> PMD on detecting on some HW errors will collect the FW/HW Dump to a
> buffer and then it will save it to a file implemented in
> qede_save_fw_dump().
>
> Dump file location and name:
> Location: or DPDK root
> Name: qede_pmd_dump_mm-dd-yy_hh-mm-ss.bin
>
> DPDK applications can initiate a debug data collection by invoking DPDK
> library’s rte_eth_dev_get_reg_info() API. This API invokes .get_reg()
> interface in the PMD.
>
> PMD implementation of .get_reg() collects the FW/HW Dump, saves it to
> data field of rte_dev_reg_info and passes it to the application. It’s
> the responsibility of the application to save the FW/HW Dump to a file.
> We recommendation using the file name format used by qede_save_fw_dump().
>
> Signed-off-by: Rasesh Mody
> Signed-off-by: Igor Russkikh
> ---
> drivers/net/qede/Makefile| 1 +
> drivers/net/qede/base/bcm_osal.c | 25 +++
> drivers/net/qede/base/bcm_osal.h | 5 +
> drivers/net/qede/qede_ethdev.c | 1 +
> drivers/net/qede/qede_ethdev.h | 25 +++
> drivers/net/qede/qede_regs.c | 271 +++
> 6 files changed, 328 insertions(+)
> create mode 100644 drivers/net/qede/qede_regs.c
>
> diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
> index 717b80839..52a4f046b 100644
> --- a/drivers/net/qede/qede_ethdev.c
> +++ b/drivers/net/qede/qede_ethdev.c
> @@ -2430,6 +2430,7 @@ static const struct eth_dev_ops qede_eth_dev_ops = {
> .udp_tunnel_port_add = qede_udp_dst_port_add,
> .udp_tunnel_port_del = qede_udp_dst_port_del,
> .fw_version_get = qede_fw_version_get,
> + .get_reg = qede_get_regs,
Please update this feature in doc/guides/nics/features/qede.ini.
> };
Re: [dpdk-dev] [PATCH 3/4] net/qede: add infrastructure for debug data collection
On Sun, Jun 28, 2020 at 11:29 AM Rasesh Mody wrote:
>
> The patch adds QEDE PMD ops and APIs to calculate the size and collect
> the debug dump for various firmware components. The patch adds new files
> qede_debug.[ch] that has all the firmware debug data collection
> infrastructure changes.
>
> Signed-off-by: Rasesh Mody
> Signed-off-by: Igor Russkikh
> ---
> drivers/net/qede/Makefile|4 +-
> drivers/net/qede/base/bcm_osal.h |5 +-
> drivers/net/qede/qede_debug.c| 8119 ++
> drivers/net/qede/qede_debug.h| 759 +++
> drivers/net/qede/qede_if.h | 45 +
> drivers/net/qede/qede_main.c | 39 +-
> 6 files changed, 8967 insertions(+), 4 deletions(-)
> create mode 100644 drivers/net/qede/qede_debug.c
> create mode 100644 drivers/net/qede/qede_debug.h
Please fix the following checkpatch issues.
CHECK:MACRO_ARG_REUSE: Macro argument reuse 'field' - possible side-effects?
#494: FILE: drivers/net/qede/qede_debug.c:339:
+#define FIELD_BIT_MASK(type, field) \
+ (((1 << FIELD_BIT_SIZE(type, field)) - 1) << \
+ FIELD_DWORD_SHIFT(type, field))
CHECK:MACRO_ARG_REUSE: Macro argument reuse 'var' - possible side-effects?
#498: FILE: drivers/net/qede/qede_debug.c:343:
+#define SET_VAR_FIELD(var, type, field, val) \
+ do { \
+ var[FIELD_DWORD_OFFSET(type, field)] &= \
+ (~FIELD_BIT_MASK(type, field)); \
+ var[FIELD_DWORD_OFFSET(type, field)] |= \
+ (val) << FIELD_DWORD_SHIFT(type, field); \
+ } while (0)
CHECK:MACRO_ARG_REUSE: Macro argument reuse 'field' - possible side-effects?
#498: FILE: drivers/net/qede/qede_debug.c:343:
+#define SET_VAR_FIELD(var, type, field, val) \
+ do { \
+ var[FIELD_DWORD_OFFSET(type, field)] &= \
+ (~FIELD_BIT_MASK(type, field)); \
+ var[FIELD_DWORD_OFFSET(type, field)] |= \
+ (val) << FIELD_DWORD_SHIFT(type, field); \
+ } while (0)
CHECK:MACRO_ARG_REUSE: Macro argument reuse 'block' - possible side-effects?
#518: FILE: drivers/net/qede/qede_debug.c:363:
+#define NUM_DBG_LINES(block) \
+ ((block)->num_of_dbg_bus_lines + NUM_EXTRA_DBG_LINES(block))
WARNING:TYPO_SPELLING: 'DIDNT' may be misspelled - perhaps 'DIDN'T'?
#5814: FILE: drivers/net/qede/qede_debug.c:5659:
+ /* DBG_STATUS_DATA_DIDNT_TRIGGER */
ERROR:TRAILING_STATEMENTS: trailing statements should be on next line
#6344: FILE: drivers/net/qede/qede_debug.c:6189:
+ for (; reg_id > curr_reg_id;
[...]
+ 1);
Re: [dpdk-dev] [PATCH v9 00/10] Windows bus/pci support
> From: Narcisa Ana Maria Vasile > Subject: Re: [PATCH v9 00/10] Windows bus/pci support > > On Wed, Jun 24, 2020 at 11:28:37AM +0300, tal...@mellanox.com wrote: > > From: Tal Shnaiderman > > > > This patchset implements the EAL and PCI functions needed for probing > PMDs using RTE_KDRV_NONE on Windows. > > > > --- > > v9: > > * Split the patch of common OS file to config and options patches > (ThomasM). > > * Remove rte_ prefixes from new functions as they are eal internal > (ThomasM). > > ^ Move common declarations to eal_private.h. > > * Add get_pci_hardware_id and parse_pci_hardware_id in pci.c > (DmitryK) > > * Fix issues in pci.c (DmitryK) > > v8: > > * Move internal_config to static inside eal_common_config.c and use > getters for all external uses. > > * Fix duplicated export line (FadyB) > > * Fix FreeBSD missing function. > > v7: > > * Remove Unneeded code from MinGW mapping script (DmitryK) > > * Fix error flow issues in pci.c (DmitryK) > > * Fix Unix build errors following unity of common functions. > > * Move strerror to rte_strerror (DmitryK) > > v6: > > * Fix duplication of exported functions for mingw by modifying the > version.map in build (new commit) > > * Fix comments and move additional functions to > eal_common_config (DavidM) > > * Fix cross-compilation in mingw (DmitryK) > > * Fix Warnings > > * Move off_t type to pci (ThomasM) > > v5: > > * Adjust mem-mapping functions to changes in latest memory > management patchset. > > * Fix incorrect implib definition in drivers/meson.build > > v4: > > * Fixed various warnings and naming conventions(DmitryK). > > * Fixed broken mingw-64 build(DmitryK). > > * Improved logging(DmitryK). > > * Added patch to fix warnings on rte_pci_addr logging. > > * Fixed broken make on linux/freebsd. > > v3: > > * Changes in BDF and hardware ids retrieval(DmitryK). > > * Apply new generic MM to all pci unix callers(DmitryK). > > * Minor corrections in pci.c(DmitryK). > > v2: > > * fix style issues. > > * fix error handing flow in pci.c > > * change eal_config.c to eal_common_config.c > > --- > Compiled successfully with clang 9.0.0. > 2 warnings are generated, suggesting using safer versions of getenv() and > strncpy(). strncpy() warning will go away in v10 after applying the comment from Thomas to modify it to strlcpy. getenv() is a bit tricky: a) The function it is being used in (rte_pci_get_sysfs_path) is a UNIX only function, from the usage of the function it seems getenv is safe to use. b) Changing to code to getenv_s, _dupenv_s or GetEnvironmentVariable would mean that the user will now need to handle a buffer to store the value of the environment variables. Do we want to modify it for rte_pci_get_sysfs_path and all of the call sites? Looks like we can ignore this warning in this case. > Do we have any test application to test with? dpdk-helloworld runs > successfully. You can use rte_bus_scan() inside rte_eal_init() to test the scanning process.
Re: [dpdk-dev] [PATCH] ring: fix error vlaue of tail in the peek API for ST mode
> -Original Message-
> From: Feifei Wang
> Sent: Sunday, June 28, 2020 7:24 AM
> To: Honnappa Nagarahalli ; Ananyev, Konstantin
>
> Cc: dev@dpdk.org; n...@arm.com; Feifei Wang ;
> sta...@dpdk.org
> Subject: [PATCH] ring: fix error vlaue of tail in the peek API for ST mode
>
> The value of *tail should be the prod->tail not prod->head. After
> modification, it can record 'tail' so head/tail can be updated
> accordingly.
>
> Fixes: 664ff4b1729b ("ring: introduce peek style API")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Feifei Wang
> Reviewed-by: Ruifeng Wang
> ---
> lib/librte_ring/rte_ring_peek_c11_mem.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_ring/rte_ring_peek_c11_mem.h
> b/lib/librte_ring/rte_ring_peek_c11_mem.h
> index 99321f124..283c7e70b 100644
> --- a/lib/librte_ring/rte_ring_peek_c11_mem.h
> +++ b/lib/librte_ring/rte_ring_peek_c11_mem.h
> @@ -40,7 +40,7 @@ __rte_ring_st_get_tail(struct rte_ring_headtail *ht,
> uint32_t *tail,
> RTE_ASSERT(n >= num);
> num = (n >= num) ? num : 0;
>
> - *tail = h;
> + *tail = t;
> return num;
> }
>
> --
Thanks for the fix.
Acked-by: Konstantin Ananyev
> 2.17.1
Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte flow
On Friday, June 26, 2020 7:10 PM Jerin Jacob Wrote: > > On Fri, Jun 26, 2020 at 4:16 PM Thomas Monjalon > wrote: > > > > 26/06/2020 12:35, Jerin Jacob: > > > On Fri, Jun 26, 2020 at 12:59 AM Thomas Monjalon > wrote: > > > > > > > > 25/06/2020 19:55, Jerin Jacob: > > > > > On Thu, Jun 25, 2020 at 10:20 PM Jiawei Wang > wrote: > > > > > > > > > > > > When using full offload, all traffic will be handled by the > > > > > > HW, and directed to the requested vf or wire, the control > > > > > > application loses visibility on the traffic. > > > > > > So there's a need for an action that will enable the control > > > > > > application some visibility. > > > > > > > > > > > > The solution is introduced a new action that will sample the > > > > > > incoming traffic and send a duplicated traffic in some > > > > > > predefined ratio to the application, while the original packet > > > > > > will continue to the target destination. > > > > > > > > > > > > The packets sampled equals is '1/ratio', if the ratio value be > > > > > > set to 1 , means that the packets would be completely > > > > > > mirrored. The sample packet can be assigned with different set of > actions from the original packet. > > > > > > > > > > > > In order to support the sample packet in rte_flow, new > > > > > > rte_flow action definition RTE_FLOW_ACTION_TYPE_SAMPLE and > > > > > > structure rte_flow_action_sample > > > > > > > > > > Isn't mirroring the packet? How about, > > > > > RTE_FLOW_ACTION_TYPE_MIRROR I am not able to understand, Why > it is called sample. > > > > > > > > Sampling is a partial mirroring. > > > > > > I think, By definition, _sampling_ is the _selection_ of items from > > > a specific group. > > > I think, _sampling_ is not dictating, what is the real action for > > > the "selected" items. > > > One can get confused with the selected ones can be for forward, drop > > > any other action. > > > > I see. Good design question (I will let others reply). > > > > > So IMO, explicit mirror keyword usage makes it is clear. Sampled packet is duplicated from incoming traffic at specific ratio and will go to different sample actions; ratio=1 is 100% duplication or mirroring. All packets will continue to go to default flow actions. > > > > > > Some more related questions: > > > 1) What is the real use case for ratio? I am not against adding a > > > ratio attribute if the MLX hardware supports it. It will be good to > > > know the use case from the application perspective? And what basics > > > application set ratio != 1? > > > > If I understand well, some applications want to check, by picking > > random packets, that the processing is not failing. > > Not clear to me. I will wait for another explanation if any. > In what basics application set .1 vs .8? The real case is like monitor the traffic with full-offload. While packet hit the sample flow, the matching packets will be sampled and sent to specific Queue, align with OVS sflow probability, user application can set it different value. > > > > > > 2) If it is for "rate-limiting" or "policing", why not use rte_mtr > > > object (rte_mtr.h) via rte_flow action. The sample ratio isn’t the same as “meter’, the ratio of sampling will be calculated with incoming packets mask (every some packets sampled 1). Then the packets will be duplicated and go to do the other sample actions. > > > 3) One of the issue for driver developers and application writers > > > are overlapping APIs. This would overlap with > > > rte_eth_mirror_rule_set() API. > > > > > > Can we deprecate rte_eth_mirror_rule_set() API? It will be a pain > > > for all to have overlapping APIs. We have not fixed the VLAN filter > > > API overlap with rte_flow in ethdev. Its being TODO for multiple > > > releases now. > > > > Ooooh yes! > > I think flow-based API is more powerful, and should deprecate old > > port-based API. > > +1 from me. > > it is taking too much effort and time to make support duplicate APIs. > > > I want to help deprecating such API in 20.11 if possible. > > Please start that discussion. In this case, it is clear API overlap with > rte_eth_mirror_rule_set(). > We should not have two separate paths for the same function in the same > ethdev library. > > > > > > > > > Full mirroring is sampling 100% packets (ratio = 1). > > > > That's why only one action is enough. > > > > > >
Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte flow
On Sun, Jun 28, 2020 at 6:46 PM Jiawei(Jonny) Wang wrote: > > > On Friday, June 26, 2020 7:10 PM Jerin Jacob Wrote: > > > > On Fri, Jun 26, 2020 at 4:16 PM Thomas Monjalon > > wrote: > > > > > > 26/06/2020 12:35, Jerin Jacob: > > > > On Fri, Jun 26, 2020 at 12:59 AM Thomas Monjalon > > wrote: > > > > > > > > > > 25/06/2020 19:55, Jerin Jacob: > > > > > > On Thu, Jun 25, 2020 at 10:20 PM Jiawei Wang > > wrote: > > > > > > > > > > > > > > When using full offload, all traffic will be handled by the > > > > > > > HW, and directed to the requested vf or wire, the control > > > > > > > application loses visibility on the traffic. > > > > > > > So there's a need for an action that will enable the control > > > > > > > application some visibility. > > > > > > > > > > > > > > The solution is introduced a new action that will sample the > > > > > > > incoming traffic and send a duplicated traffic in some > > > > > > > predefined ratio to the application, while the original packet > > > > > > > will continue to the target destination. > > > > > > > > > > > > > > The packets sampled equals is '1/ratio', if the ratio value be > > > > > > > set to 1 , means that the packets would be completely > > > > > > > mirrored. The sample packet can be assigned with different set of > > actions from the original packet. > > > > > > > > > > > > > > In order to support the sample packet in rte_flow, new > > > > > > > rte_flow action definition RTE_FLOW_ACTION_TYPE_SAMPLE and > > > > > > > structure rte_flow_action_sample > > > > > > > > > > > > Isn't mirroring the packet? How about, > > > > > > RTE_FLOW_ACTION_TYPE_MIRROR I am not able to understand, Why > > it is called sample. > > > > > > > > > > Sampling is a partial mirroring. > > > > > > > > I think, By definition, _sampling_ is the _selection_ of items from > > > > a specific group. > > > > I think, _sampling_ is not dictating, what is the real action for > > > > the "selected" items. > > > > One can get confused with the selected ones can be for forward, drop > > > > any other action. > > > > > > I see. Good design question (I will let others reply). > > > > > > > So IMO, explicit mirror keyword usage makes it is clear. > > Sampled packet is duplicated from incoming traffic at specific ratio and will > go to different sample actions; > ratio=1 is 100% duplication or mirroring. > All packets will continue to go to default flow actions. Functionality is clear from the git commit log(Not from action name). The only question is what would be the appropriate name for this action. RTE_FLOW_ACTION_TYPE_SAMPLE vs RTE_FLOW_ACTION_TYPE_MIRROR > > > > > > > > > Some more related questions: > > > > 1) What is the real use case for ratio? I am not against adding a > > > > ratio attribute if the MLX hardware supports it. It will be good to > > > > know the use case from the application perspective? And what basics > > > > application set ratio != 1? > > > > > > If I understand well, some applications want to check, by picking > > > random packets, that the processing is not failing. > > > > Not clear to me. I will wait for another explanation if any. > > In what basics application set .1 vs .8? > > The real case is like monitor the traffic with full-offload. > While packet hit the sample flow, the matching packets will be sampled and > sent to specific Queue, > align with OVS sflow probability, user application can set it different value. I understand the use case for mirror and supported in a lot of HW. What I would like to understand is the use case for "ratio"? Is the "ratio" part of OpenFlow spec? Or Is it an MLX hardware feature? > > > > > > > > > > 2) If it is for "rate-limiting" or "policing", why not use rte_mtr > > > > object (rte_mtr.h) via rte_flow action. > > The sample ratio isn’t the same as “meter’, the ratio of sampling will be > calculated with incoming packets mask (every some packets sampled 1). Then > the packets will be duplicated and go to do the other sample actions. What I meant here is , If the ratio is used for rate-limiting then having a cascade rule like RTE_FLOW_ACTION_TYPE_MIRROR, RTE_FLOW_ACTION_TYPE_MTR will do the job. > > > > > > 3) One of the issue for driver developers and application writers > > > > are overlapping APIs. This would overlap with > > > > rte_eth_mirror_rule_set() API. > > > > > > > > Can we deprecate rte_eth_mirror_rule_set() API? It will be a pain > > > > for all to have overlapping APIs. We have not fixed the VLAN filter > > > > API overlap with rte_flow in ethdev. Its being TODO for multiple > > > > releases now. > > > > > > Ooooh yes! > > > I think flow-based API is more powerful, and should deprecate old > > > port-based API. > > > > +1 from me. > > > > it is taking too much effort and time to make support duplicate APIs. > > > > > I want to help deprecating such API in 20.11 if possible. > > > > Please start that discussion. In this case, it is clear API overlap with > > rte_eth_mirror_rule_set(). > > We should
Re: [dpdk-dev] [RFC v2 0/1] add flow action context API
On Sun, Jun 28, 2020 at 2:14 PM Andrey Vesnovaty wrote: > > Hi > > On Fri, Jun 26, 2020 at 2:44 PM Jerin Jacob wrote: >> >> On Sat, Jun 20, 2020 at 7:02 PM Andrey Vesnovaty >> wrote: >> > >> > Hi, and thanks a lot for your RFC v1 comments. >> > >> > RFC v2 emphasize the intent for sharing the flow action: >> > * The term 'action context' was unclear and replaced with >> >'shared action'. >> > * RFC v2 subject became 'add flow shared action API'. >> > * all proposed APIs renamed according the above. >> > >> > The new shared action is an independent entity decoupled from any flow >> > while any flow can reuse such an action. Please go over the RFC >> > description, it was almost entirely rewritten. >> > >> > @Jerin Jacob: >> > Thanks again for your comments, it made me admit that v1 description was >> > incomplete & unclear. I hope v2 will be better at least in terms of >> > clarity. >> >> The public API and its usage is very clear. Thanks for this RFC. > > > My pleasure. >> >> >> I think, RFC v2 still not addressing the concern raised in the >> http://mails.dpdk.org/archives/dev/2020-June/169296.html. >> >> Since MLX hardware has an HW based shared object it is fine to have >> public API based on that level of abstraction. >> But at the PMD driver level we need to choose the correct abstraction >> to support all PMD and support shared object scheme if possible. >> >> I purpose to introduce something below or similar >> int (*action_update) >> (struct rte_eth_dev *, >> struct rte_flow *flow, >> const struct rte_flow_action [], >> struct rte_flow_error *); > > Where this callback suppose to belong (struct rte_flow_ops)? Yes. > How should it be implemented by PMD? See below, > Is it about shared action and if "yes" why there is 'flow' argument? flow holds the "pattern" and "action" data as PMD specific handle. So PMD, implementation can just change that action if it gets the PMD specific handle. >> >> >> in addition to: shared_action_create, shared_action_destroy, >> shared_action_update, shared_action_query >> >> Have generic implementation of above, if action_update callback is not >> NULL. > > "is not NULL" -> "is NULL"? Yes. When it is NULL. > >> >> So that, it can work all PMDs and to >> avoid the duplication of "complex" shared session management code. > > Do you mean shared action in use by multiple flows by "shared session"? Yes.
Re: [dpdk-dev] [EXT] [PATCH v3 4/4] regexdev: implement regex rte level functions
> +int
> +rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db) {
> + struct rte_regexdev *dev;
> +
> + RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
> + dev = &rte_regex_devices[dev_id];
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_db_export,
> + -ENOTSUP);
> + if (rule_db == NULL) {
> + RTE_REGEXDEV_LOG(ERR, "Dev %d rules can't be NULL\n",
> + dev_id);
> + return -EINVAL;
> + }
> + return (*dev->dev_ops->dev_db_export)(dev, rule_db); }
The test if (rule_db == NULL) is not according to the description of the API
It is needed to be NULL in order to retrieve rule_db length
* @param[out] rule_db
* Block of memory to insert the rule database. Must be at least size in
* capacity. If set to NULL, function returns required capacity.
Re: [dpdk-dev] [PATCH 2/7] net/mlx5: use direct API to find port by device
Hi,
> -Original Message-
> From: dev On Behalf Of Michael Baum
> Sent: Wednesday, June 24, 2020 2:33 PM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Slava Ovsiienko
>
> Subject: [dpdk-dev] [PATCH 2/7] net/mlx5: use direct API to find port by
> device
>
> Using RTE_ETH_FOREACH_DEV_OF loop is not necessary when the driver
> wants
> to find only the first match.
>
> Use rte_eth_find_next_of to find it.
>
> Signed-off-by: Michael Baum
> Acked-by: Matan Azrad
> ---
> drivers/net/mlx5/mlx5_mr.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_mr.c b/drivers/net/mlx5/mlx5_mr.c
> index adbe07c..3b781b6 100644
> --- a/drivers/net/mlx5/mlx5_mr.c
> +++ b/drivers/net/mlx5/mlx5_mr.c
> @@ -313,9 +313,10 @@ struct mr_update_mp_data {
> {
> uint16_t port_id;
>
> - RTE_ETH_FOREACH_DEV_OF(port_id, &pdev->device)
> - return &rte_eth_devices[port_id];
> - return NULL;
> + port_id = rte_eth_find_next_of(0, &pdev->device);
> + if (port_id == RTE_MAX_ETHPORTS)
> + return NULL;
> + return &rte_eth_devices[port_id];
> }
>
> /**
> --
> 1.8.3.1
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
[dpdk-dev] [PATCH 3/6] net/mlx5: add OS specific flow related utilities
This patch introduces the first OS specific utility functions,
for use by flow engine in different OS implementation.
The first utility functions are:
bool mlx5_flow_os_item_supported(item)
bool mlx5_flow_os_action_supported(action)
They are implemented to check OS specific support for different
item types and action types.
New header file is added:
drivers/net/mlx5/linux/mlx5_flow_os.h
This file contains the utility functions mentioned above for Linux OS.
At this stage they are implemented as static inline, for efficiency,
and always return true.
Signed-off-by: Dekel Peled
---
drivers/net/mlx5/linux/mlx5_flow_os.h | 38 +++
drivers/net/mlx5/mlx5_flow_dv.c | 20 ++
2 files changed, 58 insertions(+)
create mode 100644 drivers/net/mlx5/linux/mlx5_flow_os.h
diff --git a/drivers/net/mlx5/linux/mlx5_flow_os.h
b/drivers/net/mlx5/linux/mlx5_flow_os.h
new file mode 100644
index 000..4ad4e0a
--- /dev/null
+++ b/drivers/net/mlx5/linux/mlx5_flow_os.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#ifndef RTE_PMD_MLX5_FLOW_OS_H_
+#define RTE_PMD_MLX5_FLOW_OS_H_
+
+/**
+ * Check if item type is supported.
+ *
+ * @param item
+ * Item type to check.
+ *
+ * @return
+ * True is this item type is supported, false if not supported.
+ */
+static inline bool
+mlx5_flow_os_item_supported(int item __rte_unused)
+{
+ return true;
+}
+
+/**
+ * Check if action type is supported.
+ *
+ * @param action
+ * Action type to check.
+ *
+ * @return
+ * True is this action type is supported, false if not supported.
+ */
+static inline bool
+mlx5_flow_os_action_supported(int action __rte_unused)
+{
+ return true;
+}
+
+#endif /* RTE_PMD_MLX5_FLOW_OS_H_ */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index dc8d952..d01a7e5 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -38,6 +38,7 @@
#include "mlx5.h"
#include "mlx5_common_os.h"
#include "mlx5_flow.h"
+#include "mlx5_flow_os.h"
#include "mlx5_rxtx.h"
#ifdef HAVE_IBV_FLOW_DV_SUPPORT
@@ -4939,6 +4940,10 @@ struct field_modify_info modify_tcp[] = {
int tunnel = !!(item_flags & MLX5_FLOW_LAYER_TUNNEL);
int type = items->type;
+ if (!mlx5_flow_os_item_supported(type))
+ return rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ NULL, "item not supported");
switch (type) {
case RTE_FLOW_ITEM_TYPE_VOID:
break;
@@ -5177,6 +5182,12 @@ struct field_modify_info modify_tcp[] = {
}
for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
int type = actions->type;
+
+ if (!mlx5_flow_os_action_supported(type))
+ return rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ACTION,
+ actions,
+ "action not supported");
if (actions_n == MLX5_DV_MAX_NUMBER_OF_ACTIONS)
return rte_flow_error_set(error, ENOTSUP,
RTE_FLOW_ERROR_TYPE_ACTION,
@@ -7907,6 +7918,11 @@ struct field_modify_info modify_tcp[] = {
const struct rte_flow_action *found_action = NULL;
struct mlx5_flow_meter *fm = NULL;
+ if (!mlx5_flow_os_action_supported(action_type))
+ return rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ACTION,
+ actions,
+ "action not supported");
switch (action_type) {
case RTE_FLOW_ACTION_TYPE_VOID:
break;
@@ -8347,6 +8363,10 @@ struct field_modify_info modify_tcp[] = {
int tunnel = !!(item_flags & MLX5_FLOW_LAYER_TUNNEL);
int item_type = items->type;
+ if (!mlx5_flow_os_item_supported(item_type))
+ return rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ NULL, "item not supported");
switch (item_type) {
case RTE_FLOW_ITEM_TYPE_PORT_ID:
flow_dv_translate_item_port_id(dev, match_mask,
--
1.8.3.1
[dpdk-dev] [PATCH 2/6] net/mlx5: rename Verbs action to generic name
As part of the effort to support DPDK on Windows and other OS,
rename 'verbs_action' to the generic name 'action'.
Signed-off-by: Dekel Peled
---
drivers/net/mlx5/mlx5_flow.h| 16
drivers/net/mlx5/mlx5_flow_dv.c | 28 ++--
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 74d2c49..22cc356 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -399,8 +399,8 @@ struct mlx5_flow_dv_encap_decap_resource {
ILIST_ENTRY(uint32_t)next;
/* Pointer to next element. */
rte_atomic32_t refcnt; /**< Reference counter. */
- void *verbs_action;
- /**< Verbs encap/decap action object. */
+ void *action;
+ /**< Encap/decap action object. */
uint8_t buf[MLX5_ENCAP_MAX_LEN];
size_t size;
uint8_t reformat_type;
@@ -413,7 +413,7 @@ struct mlx5_flow_dv_tag_resource {
struct mlx5_hlist_entry entry;
/**< hash list entry for tag resource, tag value as the key. */
void *action;
- /**< Verbs tag action object. */
+ /**< Tag action object. */
rte_atomic32_t refcnt; /**< Reference counter. */
uint32_t idx; /**< Index for the index memory pool. */
};
@@ -436,8 +436,8 @@ struct mlx5_flow_dv_modify_hdr_resource {
LIST_ENTRY(mlx5_flow_dv_modify_hdr_resource) next;
/* Pointer to next element. */
rte_atomic32_t refcnt; /**< Reference counter. */
- struct ibv_flow_action *verbs_action;
- /**< Verbs modify header action object. */
+ struct ibv_flow_action *action;
+ /**< Modify header action object. */
uint8_t ft_type; /**< Flow table type, Rx or Tx. */
uint32_t actions_num; /**< Number of modification actions. */
uint64_t flags; /**< Flags for RDMA API. */
@@ -458,7 +458,7 @@ struct mlx5_flow_dv_port_id_action_resource {
/* Pointer to next element. */
rte_atomic32_t refcnt; /**< Reference counter. */
void *action;
- /**< Verbs tag action object. */
+ /**< Action object. */
uint32_t port_id; /**< Port ID value. */
};
@@ -467,7 +467,7 @@ struct mlx5_flow_dv_push_vlan_action_resource {
ILIST_ENTRY(uint32_t)next;
/* Pointer to next element. */
rte_atomic32_t refcnt; /**< Reference counter. */
- void *action; /**< Direct verbs action object. */
+ void *action; /**< Action object. */
uint8_t ft_type; /**< Flow table type, Rx, Tx or FDB. */
rte_be32_t vlan_tag; /**< VLAN tag value. */
};
@@ -660,7 +660,7 @@ struct mlx5_flow_verbs_workspace {
struct mlx5_flow {
struct rte_flow *flow; /**< Pointer to the main flow. */
uint32_t flow_idx; /**< The memory pool index to the main flow. */
- uint64_t hash_fields; /**< Verbs hash Rx queue hash fields. */
+ uint64_t hash_fields; /**< Hash Rx queue hash fields. */
uint64_t act_flags;
/**< Bit-fields of detected actions, see MLX5_FLOW_ACTION_*. */
bool external; /**< true if the flow is created external to PMD. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index ae4b05c..dc8d952 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -2603,13 +2603,13 @@ struct field_modify_info modify_tcp[] = {
RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
"cannot allocate resource memory");
*cache_resource = *resource;
- cache_resource->verbs_action =
+ cache_resource->action =
mlx5_glue->dv_create_flow_action_packet_reformat
(sh->ctx, cache_resource->reformat_type,
cache_resource->ft_type, domain, cache_resource->flags,
cache_resource->size,
(cache_resource->size ? cache_resource->buf : NULL));
- if (!cache_resource->verbs_action) {
+ if (!cache_resource->action) {
rte_free(cache_resource);
return rte_flow_error_set(error, ENOMEM,
RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
@@ -4030,12 +4030,12 @@ struct field_modify_info modify_tcp[] = {
"cannot allocate resource memory");
*cache_resource = *resource;
rte_memcpy(cache_resource->actions, resource->actions, actions_len);
- cache_resource->verbs_action =
+ cache_resource->action =
mlx5_glue->dv_create_flow_action_modify_header
(sh->ctx, cache_resource->ft_type, ns,
cache_resource->flags, actions_len,
(uint64_t *)cache_resource->actions);
- if (!cache_resource->verbs_action) {
+ if (!cache_resource->action) {
[dpdk-dev] [PATCH 0/6] net/mlx5: refactor flow infrastructure
As part of the effort to support DPDK on different OS, this series adds OS abstraction for flow infrastructures. The changes include renaming using generic terms, as well as OS specific functions for flow related operations and utilities. Series-acked-by: Matan Azrad Dekel Peled (6): net/mlx5: rename IB flow to generic name DRV flow net/mlx5: rename Verbs action to generic name net/mlx5: add OS specific flow related utilities net/mlx5: add OS specific flow type selection net/mlx5: add OS specific flow create and destroy net/mlx5: add OS specific flow actions operations drivers/net/mlx5/linux/mlx5_flow_os.h | 368 ++ drivers/net/mlx5/mlx5_flow.c | 10 +- drivers/net/mlx5/mlx5_flow.h | 18 +- drivers/net/mlx5/mlx5_flow_dv.c | 250 --- drivers/net/mlx5/mlx5_flow_verbs.c| 12 +- 5 files changed, 520 insertions(+), 138 deletions(-) create mode 100644 drivers/net/mlx5/linux/mlx5_flow_os.h -- 1.8.3.1
[dpdk-dev] [PATCH 1/6] net/mlx5: rename IB flow to generic name DRV flow
As part of the effort to support DPDK on Windows and other OS,
rename from IB related name to generic name.
Signed-off-by: Dekel Peled
---
drivers/net/mlx5/mlx5_flow.h | 2 +-
drivers/net/mlx5/mlx5_flow_dv.c| 11 +--
drivers/net/mlx5/mlx5_flow_verbs.c | 12 ++--
3 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 50ec741..74d2c49 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -538,7 +538,7 @@ struct mlx5_flow_handle {
/**< Index to next device flow handle. */
uint64_t layers;
/**< Bit-fields of present layers, see MLX5_FLOW_LAYER_*. */
- void *ib_flow; /**< Verbs flow pointer. */
+ void *drv_flow; /**< pointer to driver flow object. */
uint32_t split_flow_id:28; /**< Sub flow unique match flow id. */
uint32_t mark:1; /**< Metadate rxq mark flag. */
uint32_t fate_action:3; /**< Fate action type. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index d1eb65b..ae4b05c 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -8673,12 +8673,11 @@ struct field_modify_info modify_tcp[] = {
dh->rix_default_fate = MLX5_FLOW_FATE_DEFAULT_MISS;
dv->actions[n++] = priv->sh->default_miss.action;
}
-
- dh->ib_flow =
+ dh->drv_flow =
mlx5_glue->dv_create_flow(dv_h->matcher->matcher_object,
(void *)&dv->value, n,
dv->actions);
- if (!dh->ib_flow) {
+ if (!dh->drv_flow) {
rte_flow_error_set(error, errno,
RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
NULL,
@@ -9041,9 +9040,9 @@ struct field_modify_info modify_tcp[] = {
handle_idx);
if (!dh)
return;
- if (dh->ib_flow) {
- claim_zero(mlx5_glue->dv_destroy_flow(dh->ib_flow));
- dh->ib_flow = NULL;
+ if (dh->drv_flow) {
+ claim_zero(mlx5_glue->dv_destroy_flow(dh->drv_flow));
+ dh->drv_flow = NULL;
}
if (dh->fate_action == MLX5_FLOW_FATE_DROP ||
dh->fate_action == MLX5_FLOW_FATE_QUEUE ||
diff --git a/drivers/net/mlx5/mlx5_flow_verbs.c
b/drivers/net/mlx5/mlx5_flow_verbs.c
index 6b86437..781c97f 100644
--- a/drivers/net/mlx5/mlx5_flow_verbs.c
+++ b/drivers/net/mlx5/mlx5_flow_verbs.c
@@ -1778,9 +1778,9 @@
return;
SILIST_FOREACH(priv->sh->ipool[MLX5_IPOOL_MLX5_FLOW], flow->dev_handles,
handle_idx, handle, next) {
- if (handle->ib_flow) {
- claim_zero(mlx5_glue->destroy_flow(handle->ib_flow));
- handle->ib_flow = NULL;
+ if (handle->drv_flow) {
+ claim_zero(mlx5_glue->destroy_flow(handle->drv_flow));
+ handle->drv_flow = NULL;
}
/* hrxq is union, don't touch it only the flag is set. */
if (handle->rix_hrxq) {
@@ -1901,9 +1901,9 @@
handle->rix_hrxq = hrxq_idx;
}
MLX5_ASSERT(hrxq);
- handle->ib_flow = mlx5_glue->create_flow(hrxq->qp,
-&dev_flow->verbs.attr);
- if (!handle->ib_flow) {
+ handle->drv_flow = mlx5_glue->create_flow
+ (hrxq->qp, &dev_flow->verbs.attr);
+ if (!handle->drv_flow) {
rte_flow_error_set(error, errno,
RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
NULL,
--
1.8.3.1
[dpdk-dev] [PATCH 4/6] net/mlx5: add OS specific flow type selection
In current implementation the flow type (DV/Verbs) is selected
using dedicated function flow_get_drv_type().
This patch adds OS specific function mlx5_flow_os_get_type(), to
allow OS specific flow type selection.
The new function is called by flow_get_drv_type(), and if it returns a
valid value (DV/Verbs) no more logic is required.
Otherwise the existing logic is executed.
Signed-off-by: Dekel Peled
---
drivers/net/mlx5/linux/mlx5_flow_os.h | 18 ++
drivers/net/mlx5/mlx5_flow.c | 10 ++
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/net/mlx5/linux/mlx5_flow_os.h
b/drivers/net/mlx5/linux/mlx5_flow_os.h
index 4ad4e0a..41691a1 100644
--- a/drivers/net/mlx5/linux/mlx5_flow_os.h
+++ b/drivers/net/mlx5/linux/mlx5_flow_os.h
@@ -5,6 +5,24 @@
#ifndef RTE_PMD_MLX5_FLOW_OS_H_
#define RTE_PMD_MLX5_FLOW_OS_H_
+#include "mlx5_flow.h"
+
+#ifdef HAVE_IBV_FLOW_DV_SUPPORT
+extern const struct mlx5_flow_driver_ops mlx5_flow_dv_drv_ops;
+#endif
+
+/**
+ * Get OS enforced flow type. MLX5_FLOW_TYPE_MAX means "non enforced type".
+ *
+ * @return
+ * Flow type (MLX5_FLOW_TYPE_MAX)
+ */
+static inline enum mlx5_flow_drv_type
+mlx5_flow_os_get_type(void)
+{
+ return MLX5_FLOW_TYPE_MAX;
+}
+
/**
* Check if item type is supported.
*
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 4700ec1..b8468c1 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -36,12 +36,10 @@
#include "mlx5_defs.h"
#include "mlx5.h"
#include "mlx5_flow.h"
+#include "mlx5_flow_os.h"
#include "mlx5_rxtx.h"
/** Device flow drivers. */
-#ifdef HAVE_IBV_FLOW_DV_SUPPORT
-extern const struct mlx5_flow_driver_ops mlx5_flow_dv_drv_ops;
-#endif
extern const struct mlx5_flow_driver_ops mlx5_flow_verbs_drv_ops;
const struct mlx5_flow_driver_ops mlx5_flow_null_drv_ops;
@@ -2501,8 +2499,12 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
flow_get_drv_type(struct rte_eth_dev *dev, const struct rte_flow_attr *attr)
{
struct mlx5_priv *priv = dev->data->dev_private;
- enum mlx5_flow_drv_type type = MLX5_FLOW_TYPE_MAX;
+ /* The OS can determine first a specific flow type (DV, VERBS) */
+ enum mlx5_flow_drv_type type = mlx5_flow_os_get_type();
+ if (type != MLX5_FLOW_TYPE_MAX)
+ return type;
+ /* If no OS specific type - continue with DV/VERBS selection */
if (attr->transfer && priv->config.dv_esw_en)
type = MLX5_FLOW_TYPE_DV;
if (!attr->transfer)
--
1.8.3.1
[dpdk-dev] [PATCH 5/6] net/mlx5: add OS specific flow create and destroy
This patch introduces the OS specific functions, for flow create
and flow destroy operations.
In existing implementation, the functions to create objects
(flow/table/matcher) return a pointer to the created object.
The functions to destroy objects return 0 on success and errno on
failure.
The new OS specific functions to create objects return 0 on success,
and (-1) on failure.
On success, a pointer to the created object is returned using an
additional parameter.
Signed-off-by: Dekel Peled
---
drivers/net/mlx5/linux/mlx5_flow_os.h | 114 ++
drivers/net/mlx5/mlx5_flow_dv.c | 101 +++---
2 files changed, 164 insertions(+), 51 deletions(-)
diff --git a/drivers/net/mlx5/linux/mlx5_flow_os.h
b/drivers/net/mlx5/linux/mlx5_flow_os.h
index 41691a1..2ce344c 100644
--- a/drivers/net/mlx5/linux/mlx5_flow_os.h
+++ b/drivers/net/mlx5/linux/mlx5_flow_os.h
@@ -53,4 +53,118 @@
return true;
}
+/**
+ * Create flow rule.
+ *
+ * @param[in] matcher
+ * Pointer to match mask structure.
+ * @param[in] match_value
+ * Pointer to match value structure.
+ * @param[in] num_actions
+ * Number of actions in flow rule.
+ * @param[in] actions
+ * Pointer to array of flow rule actions.
+ * @param[out] flow
+ * Pointer to a valid flow rule object on success, NULL otherwise.
+ *
+ * @return
+ * 0 on success, or -1 on failure and errno is set.
+ */
+static inline int
+mlx5_flow_os_create_flow(void *matcher, void *match_value,
+size_t num_actions, void *actions[], void **flow)
+{
+ *flow = mlx5_glue->dv_create_flow(matcher, match_value,
+ num_actions, actions);
+ return (*flow) ? 0 : -1;
+}
+
+/**
+ * Destroy flow rule.
+ *
+ * @param[in] drv_flow_ptr
+ * Pointer to flow rule object.
+ *
+ * @return
+ * 0 on success, or the value of errno on failure.
+ */
+static inline int
+mlx5_flow_os_destroy_flow(void *drv_flow_ptr)
+{
+ return mlx5_glue->dv_destroy_flow(drv_flow_ptr);
+}
+
+/**
+ * Create flow table.
+ *
+ * @param[in] domain
+ * Pointer to relevant domain.
+ * @param[in] table_id
+ * Table ID.
+ * @param[out] table
+ * Pointer to a valid flow table object on success, NULL otherwise.
+ *
+ * @return
+ * 0 on success, or -1 on failure and errno is set.
+ */
+static inline int
+mlx5_flow_os_create_flow_tbl(void *domain, uint32_t table_id, void **table)
+{
+ *table = mlx5_glue->dr_create_flow_tbl(domain, table_id);
+ return (*table) ? 0 : -1;
+}
+
+/**
+ * Destroy flow table.
+ *
+ * @param[in] table
+ * Pointer to table object to destroy.
+ *
+ * @return
+ * 0 on success, or the value of errno on failure.
+ */
+static inline int
+mlx5_flow_os_destroy_flow_tbl(void *table)
+{
+ return mlx5_glue->dr_destroy_flow_tbl(table);
+}
+
+/**
+ * Create flow matcher in a flow table.
+ *
+ * @param[in] ctx
+ * Pointer to relevant device context.
+ * @param[in] attr
+ * Pointer to relevant attributes.
+ * @param[in] table
+ * Pointer to table object.
+ * @param[out] matcher
+ * Pointer to a valid flow matcher object on success, NULL otherwise.
+ *
+ * @return
+ * 0 on success, or -1 on failure and errno is set.
+ */
+static inline int
+mlx5_flow_os_create_flow_matcher(void *ctx, void *attr, void *table,
+void **matcher)
+{
+ *matcher = mlx5_glue->dv_create_flow_matcher(ctx, attr, table);
+ return (*matcher) ? 0 : -1;
+}
+
+/**
+ * Destroy flow matcher.
+ *
+ * @param[in] matcher
+ * Pointer to matcher object to destroy.
+ *
+ * @return
+ * 0 on success, or the value of errno on failure.
+ */
+static inline int
+mlx5_flow_os_destroy_flow_matcher(void *matcher)
+{
+ return mlx5_glue->dv_destroy_flow_matcher(matcher);
+}
+
#endif /* RTE_PMD_MLX5_FLOW_OS_H_ */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index d01a7e5..eb27595 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -7340,8 +7340,8 @@ struct field_modify_info modify_tcp[] = {
domain = sh->tx_domain;
else
domain = sh->rx_domain;
- tbl->obj = mlx5_glue->dr_create_flow_tbl(domain, table_id);
- if (!tbl->obj) {
+ ret = mlx5_flow_os_create_flow_tbl(domain, table_id, &tbl->obj);
+ if (ret) {
rte_flow_error_set(error, ENOMEM,
RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
NULL, "cannot create flow table object");
@@ -7361,7 +7361,7 @@ struct field_modify_info modify_tcp[] = {
rte_flow_error_set(error, -ret,
RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
"cannot insert flow table data entry");
- mlx5_glue->dr_destroy_flow_tbl(tbl->obj);
+ mlx5_flow_os_destroy_flow_tbl(tbl->obj);
mlx5_ipool_free(sh->ipool[MLX5_IPOO
[dpdk-dev] [PATCH 6/6] net/mlx5: add OS specific flow actions operations
This patch introduces the OS specific functions, for flow actions
create and destroy operations.
In existing implementation, the functions to create flow actions
return a pointer to the created action object.
The new OS specific functions to create flow actions return 0 on
success, and (-1) on failure.
On success, a pointer to the created action object is returned
using an additional parameter.
On failure errno is set.
Signed-off-by: Dekel Peled
---
drivers/net/mlx5/linux/mlx5_flow_os.h | 198 ++
drivers/net/mlx5/mlx5_flow.h | 2 +-
drivers/net/mlx5/mlx5_flow_dv.c | 110 +--
3 files changed, 251 insertions(+), 59 deletions(-)
diff --git a/drivers/net/mlx5/linux/mlx5_flow_os.h
b/drivers/net/mlx5/linux/mlx5_flow_os.h
index 2ce344c..a6bd2c0 100644
--- a/drivers/net/mlx5/linux/mlx5_flow_os.h
+++ b/drivers/net/mlx5/linux/mlx5_flow_os.h
@@ -167,4 +167,202 @@
return mlx5_glue->dv_destroy_flow_matcher(matcher);
}
+/**
+ * Create flow action: packet reformat.
+ *
+ * @param[in] ctx
+ * Pointer to relevant device context.
+ * @param[in] domain
+ * Pointer to domain handler.
+ * @param[in] resource
+ * Pointer to action data resource.
+ * @param[out] action
+ * Pointer to a valid action on success, NULL otherwise.
+ *
+ *
+ * @return
+ * 0 on success, or -1 on failure and errno is set.
+ */
+static inline int
+mlx5_flow_os_create_flow_action_packet_reformat(void *ctx, void *domain,
+ void *resource, void **action)
+{
+ struct mlx5_flow_dv_encap_decap_resource *res =
+ (struct mlx5_flow_dv_encap_decap_resource *)resource;
+
+ *action = mlx5_glue->dv_create_flow_action_packet_reformat
+ (ctx, res->reformat_type, res->ft_type,
+domain, res->flags, res->size,
+(res->size ? res->buf : NULL));
+ return (*action) ? 0 : -1;
+}
+
+/**
+ * Create flow action: modify header.
+ *
+ * @param[in] ctx
+ * Pointer to relevant device context.
+ * @param[in] domain
+ * Pointer to domain handler.
+ * @param[in] resource
+ * Pointer to action data resource.
+ * @param[in] actions_len
+ * Total length of actions data in resource.
+ * @param[out] action
+ * Pointer to a valid action on success, NULL otherwise.
+ *
+ *
+ * @return
+ * 0 on success, or -1 on failure and errno is set.
+ */
+static inline int
+mlx5_flow_os_create_flow_action_modify_header(void *ctx, void *domain,
+ void *resource,
+ uint32_t actions_len,
+ void **action)
+{
+ struct mlx5_flow_dv_modify_hdr_resource *res =
+ (struct mlx5_flow_dv_modify_hdr_resource *)resource;
+
+ *action = mlx5_glue->dv_create_flow_action_modify_header
+ (ctx, res->ft_type, domain, res->flags,
+actions_len, (uint64_t *)res->actions);
+ return (*action) ? 0 : -1;
+}
+
+/**
+ * Create flow action: destination flow table.
+ *
+ * @param[in] tbl_obj
+ * Pointer to destination table object.
+ * @param[out] action
+ * Pointer to a valid action on success, NULL otherwise.
+ *
+ * @return
+ * 0 on success, or -1 on failure and errno is set.
+ */
+static inline int
+mlx5_flow_os_create_flow_action_dest_flow_tbl(void *tbl_obj, void **action)
+{
+ *action = mlx5_glue->dr_create_flow_action_dest_flow_tbl(tbl_obj);
+ return (*action) ? 0 : -1;
+}
+
+/**
+ * Create flow action: destination port.
+ *
+ * @param[in] domain
+ * Pointer to domain handler.
+ * @param[in] port_id
+ * Destination port ID.
+ * @param[out] action
+ * Pointer to a valid action on success, NULL otherwise.
+ *
+ * @return
+ * 0 on success, or -1 on failure and errno is set.
+ */
+static inline int
+mlx5_flow_os_create_flow_action_dest_port(void *domain, uint32_t port_id,
+ void **action)
+{
+ /*
+* Depending on rdma_core version the glue routine calls
+* either mlx5dv_dr_action_create_dest_ib_port(domain, dev_port)
+* or mlx5dv_dr_action_create_dest_vport(domain, vport_id).
+*/
+ *action = mlx5_glue->dr_create_flow_action_dest_port(domain, port_id);
+ return (*action) ? 0 : -1;
+}
+
+/**
+ * Create flow action: push vlan.
+ *
+ * @param[in] domain
+ * Pointer to domain handler.
+ * @param[in] vlan_tag
+ * VLAN tag value.
+ * @param[out] action
+ * Pointer to a valid action on success, NULL otherwise.
+ *
+ * @return
+ * 0 on success, or -1 on failure and errno is set.
+ */
+static inline int
+mlx5_flow_os_create_flow_action_push_vlan(void *domain, rte_be32_t vlan_tag,
+ void **action)
+{
+ *action = mlx5_glue->dr_create
Re: [dpdk-dev] [EXT] [PATCH v3 4/4] regexdev: implement regex rte level functions
> -Original Message-
> From: dev On Behalf Of Guy Kaneti
> Sent: Sunday, June 28, 2020 4:45 PM
> To: Ori Kam ; Jerin Jacob Kollanukkaran
> ; xiang.w.w...@intel.com
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> ; Shahaf Shuler ;
> hemant.agra...@nxp.com; Opher Reviv ; Alex
> Rosenbaum ; Dovrat Zifroni ;
> Prasun Kapoor ; nipun.gu...@nxp.com;
> bruce.richard...@intel.com; yang.a.h...@intel.com; harry.ch...@intel.com;
> gu.ji...@zte.com.cn; shanjia...@chinatelecom.cn;
> zhangy@chinatelecom.cn; lixin...@huachentel.com; wush...@inspur.com;
> yuying...@yxlink.com; fanchengg...@sunyainfo.com;
> davidf...@tencent.com; liuzho...@chinaunicom.cn;
> zhaoyon...@huawei.com; o...@yunify.com; j...@netgate.com;
> hongjun...@intel.com; j.bromh...@titan-ic.com; d...@ntop.org;
> f...@napatech.com; arthur...@lionic.com; Thomas Monjalon
>
> Subject: Re: [dpdk-dev] [EXT] [PATCH v3 4/4] regexdev: implement regex rte
> level functions
>
>
> > +int
> > +rte_regexdev_rule_db_export(uint8_t dev_id, char *rule_db) {
> > + struct rte_regexdev *dev;
> > +
> > + RTE_REGEXDEV_VALID_DEV_ID_OR_ERR_RET(dev_id, -EINVAL);
> > + dev = &rte_regex_devices[dev_id];
> > + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_db_export,
> > + -ENOTSUP);
> > + if (rule_db == NULL) {
> > + RTE_REGEXDEV_LOG(ERR, "Dev %d rules can't be NULL\n",
> > +dev_id);
> > + return -EINVAL;
> > + }
> > + return (*dev->dev_ops->dev_db_export)(dev, rule_db); }
>
> The test if (rule_db == NULL) is not according to the description of the API
> It is needed to be NULL in order to retrieve rule_db length
>
Correct will fix.
> * @param[out] rule_db
> * Block of memory to insert the rule database. Must be at least size in
> * capacity. If set to NULL, function returns required capacity.
Re: [dpdk-dev] [PATCH 6/7] cmdline: support Windows
Hi Dmitry,
I'm trying to run test-pmd on Windows and I ran into this error with cmdline.
The error log message is :
In file included from ../app/test-pmd/cmdline_flow.c:23:
..\lib\librte_cmdline/cmdline_parse_num.h:24:2: error: 'INT64' redeclared as
different kind of symbol
INT64
In file included from
C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/winnt.h:150,
from
C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
from
C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
from
C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/windows.h:69,
from ..\lib/librte_eal/windows/include/rte_windows.h:22,
from ..\lib/librte_eal/windows/include/pthread.h:20,
from ..\lib/librte_eal/include/rte_per_lcore.h:25,
from ..\lib/librte_eal/include/rte_errno.h:18,
from ..\lib\librte_ethdev/rte_ethdev.h:156,
from ../app/test-pmd/cmdline_flow.c:18:
C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/basetsd.h:32:44: note:
previous declaration of 'INT64' was here
__MINGW_EXTENSION typedef signed __int64 INT64,*PINT64;
The same error is for the other types defined in cmdline_numtype.
This problem with windows.h is popping in many places and some of them are
cmdline and test-pmd and librte_net.
We should find a way to exclude windows.h from the unneeded places, is there any
suggestions on how it can be done ?
> -Original Message-
> From: Dmitry Kozlyuk
> Sent: Sunday, June 21, 2020 12:05 AM
> To: dev@dpdk.org
> Cc: Dmitry Malloy ; Narcisa Ana Maria Vasile
> ; Fady Bader ; Tal
> Shnaiderman ; Dmitry Kozlyuk
> ; Thomas Monjalon ;
> Olivier Matz
> Subject: [PATCH 6/7] cmdline: support Windows
>
> Implement terminal handling, input polling, and vdprintf() for Windows.
>
> Because Windows I/O model differs fundamentally from Unix and there is no
> concept of character device, polling is simulated depending on the underlying
> inpue device. Supporting non-terminal input is useful for automated testing.
>
> Windows emulation of VT100 uses "ESC [ E" for newline instead of standard "ESC
> E", so a workaround is added.
>
> Signed-off-by: Dmitry Kozlyuk
> ---
> config/meson.build | 2 +
> lib/librte_cmdline/cmdline.c| 5 +
> lib/librte_cmdline/cmdline_os_windows.c | 207
> lib/librte_cmdline/cmdline_private.h| 15 ++
> lib/librte_cmdline/cmdline_socket.c | 4 +
> lib/librte_cmdline/cmdline_vt100.h | 4 +
> lib/librte_cmdline/meson.build | 4 +-
> lib/meson.build | 1 +
> 8 files changed, 241 insertions(+), 1 deletion(-) create mode 100644
> lib/librte_cmdline/cmdline_os_windows.c
>
> diff --git a/config/meson.build b/config/meson.build index
> d3f05f878..733b5e310
> 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -269,6 +269,8 @@ if is_windows
> add_project_arguments('-D__USE_MINGW_ANSI_STDIO',
> language: 'c')
> endif
>
> + add_project_link_arguments('-lws2_32', language: 'c')
> +
> # Contrary to docs, VirtualAlloc2() is exported by mincore.lib
> # in Windows SDK, while MinGW exports it by advapi32.a.
> if is_ms_linker
> diff --git a/lib/librte_cmdline/cmdline.c b/lib/librte_cmdline/cmdline.c index
> 00b9e6b2e..c0ddb5f23 100644
> --- a/lib/librte_cmdline/cmdline.c
> +++ b/lib/librte_cmdline/cmdline.c
> @@ -13,9 +13,14 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> +#ifdef RTE_EXEC_ENV_WINDOWS
> +#define write _write
> +#endif
> +
> #include "cmdline.h"
> #include "cmdline_private.h"
>
> diff --git a/lib/librte_cmdline/cmdline_os_windows.c
> b/lib/librte_cmdline/cmdline_os_windows.c
> new file mode 100644
> index 0..9736f6531
> --- /dev/null
> +++ b/lib/librte_cmdline/cmdline_os_windows.c
> @@ -0,0 +1,207 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright (c) 2020 Dmitry Kozlyuk
> + */
> +
> +#include
> +
> +#include
> +
> +#include "cmdline_private.h"
> +
> +/* Missing from some MinGW-w64 distributions. */ #ifndef
> +ENABLE_VIRTUAL_TERMINAL_PROCESSING
> +#define ENABLE_VIRTUAL_TERMINAL_PROCESSING 0x0004 #endif
> +
> +#ifndef ENABLE_VIRTUAL_TERMINAL_INPUT
> +#define ENABLE_VIRTUAL_TERMINAL_INPUT 0x0200 #endif
> +
> +void
> +terminal_adjust(struct terminal *oldterm) {
> + HANDLE handle;
> + DWORD mode;
> +
> + ZeroMemory(oldterm, sizeof(*oldterm));
> +
> + /* Detect console input, set it up and make it emulate VT100. */
> + handle = GetStdHandle(STD_INPUT_HANDLE);
> + if (GetConsoleMode(handle, &mode)) {
> + oldterm->is_console_input = 1;
> + oldterm->input_mode = mode;
> +
> + mode &= ~(
> + ENABLE_LINE_INPUT | /* no line buffering */
> + ENABLE_ECHO_INPUT | /* no echo *
Re: [dpdk-dev] [RFC] ethdev: add fragment attribute to IPv6 item
Hi,
This change is proposed for 20.11.
It is suggested after internal discussions, where multiple suggestions were
considered, some of them similar to the ones suggested below.
Continuing the earlier correspondence in this thread, please send any other
comments/suggestions you have.
Regards,
Dekel
> -Original Message-
> From: Dekel Peled
> Sent: Thursday, June 18, 2020 9:59 AM
> To: Adrien Mazarguil ; Ori Kam
> ; Andrew Rybchenko
> Cc: ferruh.yi...@intel.com; john.mcnam...@intel.com;
> marko.kovace...@intel.com; Asaf Penso ; Matan
> Azrad ; Eli Britstein ;
> dev@dpdk.org; Ivan Malov
> Subject: RE: [RFC] ethdev: add fragment attribute to IPv6 item
>
> Hi,
>
> Kind reminder, please respond on the recent correspondence so we can
> conclude this issue.
>
> Regards,
> Dekel
>
> > -Original Message-
> > From: Dekel Peled
> > Sent: Wednesday, June 3, 2020 3:11 PM
> > To: Ori Kam ; Adrien Mazarguil
> >
> > Cc: Andrew Rybchenko ;
> > ferruh.yi...@intel.com; john.mcnam...@intel.com;
> > marko.kovace...@intel.com; Asaf Penso ; Matan
> > Azrad ; Eli Britstein ;
> > dev@dpdk.org; Ivan Malov
> > Subject: RE: [RFC] ethdev: add fragment attribute to IPv6 item
> >
> > Hi, PSB.
> >
> > > -Original Message-
> > > From: Ori Kam
> > > Sent: Wednesday, June 3, 2020 11:16 AM
> > > To: Adrien Mazarguil
> > > Cc: Andrew Rybchenko ; Dekel Peled
> > > ; ferruh.yi...@intel.com;
> > > john.mcnam...@intel.com; marko.kovace...@intel.com; Asaf Penso
> > > ; Matan Azrad ; Eli
> > Britstein
> > > ; dev@dpdk.org; Ivan Malov
> > >
> > > Subject: RE: [RFC] ethdev: add fragment attribute to IPv6 item
> > >
> > > Hi Adrien,
> > >
> > > Great to hear from you again.
> > >
> > > > -Original Message-
> > > > From: Adrien Mazarguil
> > > > Sent: Tuesday, June 2, 2020 10:04 PM
> > > > To: Ori Kam
> > > > Cc: Andrew Rybchenko ; Dekel Peled
> > > > ; ferruh.yi...@intel.com;
> > > > john.mcnam...@intel.com; marko.kovace...@intel.com; Asaf Penso
> > > > ; Matan Azrad ; Eli
> > > Britstein
> > > > ; dev@dpdk.org; Ivan Malov
> > > >
> > > > Subject: Re: [RFC] ethdev: add fragment attribute to IPv6 item
> > > >
> > > > Hi Ori, Andrew, Delek,
> >
> > It's Dekel, not Delek ;-)
> >
> > > >
> > > > (been a while eh?)
> > > >
> > > > On Tue, Jun 02, 2020 at 06:28:41PM +, Ori Kam wrote:
> > > > > Hi Andrew,
> > > > >
> > > > > PSB,
> > > > [...]
> > > > > > > diff --git a/lib/librte_ethdev/rte_flow.h
> > > > > > > b/lib/librte_ethdev/rte_flow.h index b0e4199..3bc8ce1 100644
> > > > > > > --- a/lib/librte_ethdev/rte_flow.h
> > > > > > > +++ b/lib/librte_ethdev/rte_flow.h
> > > > > > > @@ -787,6 +787,8 @@ struct rte_flow_item_ipv4 {
> > > > > > > */
> > > > > > > struct rte_flow_item_ipv6 {
> > > > > > > struct rte_ipv6_hdr hdr; /**< IPv6 header definition. */
> > > > > > > + uint32_t is_frag:1; /**< Is IPv6 packet fragmented/non-
> > > fragmented. */
> > > > > > > + uint32_t reserved:31; /**< Reserved, must be zero. */
> > > > > >
> > > > > > The solution is simple, but hardly generic and adds an example
> > > > > > for the future extensions. I doubt that it is a right way to go.
> > > > > >
> > > > > I agree with you that this is not the most generic way possible,
> > > > > but the IPV6 extensions are very unique. So the solution is also
> unique.
> > > > > In general, I'm always in favor of finding the most generic way,
> > > > > but
> > > > sometimes
> > > > > it is better to keep things simple, and see how it goes.
> > > >
> > > > Same feeling here, it doesn't look right.
> > > >
> > > > > > May be we should add 256-bit string with one bit for each IP
> > > > > > protocol number and apply it to extension headers only?
> > > > > > If bit A is set in the mask:
> > > > > > - if bit A is set in spec as well, extension header with
> > > > > >IP protocol (1 << A) number must present
> > > > > > - if bit A is clear in spec, extension header with
> > > > > >IP protocol (1 << A) number must absent If bit is clear in
> > > > > > the mask, corresponding extension header may present and may
> > > > > > absent (i.e. don't care).
> > > > > >
> > > > > There are only 12 possible extension headers and currently none
> > > > > of them are supported in rte_flow. So adding a logic to parse
> > > > > the 256 just to get a max
> > > > of 12
> > > > > possible values is an overkill. Also, if we disregard the case
> > > > > of the extension, the application must select only one next proto.
> > > > > For example, the application can't select udp + tcp. There is
> > > > > the option to add a flag for each of the possible extensions,
> > > > > does it makes more
> > > sense to you?
> > > >
> > > > Each of these extension headers has its own structure, we first
> > > > need the ability to match them properly by adding the necessary
> pattern items.
> > > >
> > > > > > The RFC indirectly touches IPv6 proto (next header) matching
> > > > > > logic.
> > > > > >
> > > > > > If logic used in ETH+VLAN is applied on IPv6
Re: [dpdk-dev] [PATCH] net/mlx4: use anonymous DV allocator argument
Hi,
> -Original Message-
> From: dev On Behalf Of Michael Baum
> Sent: Wednesday, June 24, 2020 4:30 PM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Slava Ovsiienko
>
> Subject: [dpdk-dev] [PATCH] net/mlx4: use anonymous DV allocator
> argument
>
> The mlx4_pci_probe function defines an struct mlx4dv_ctx_allocators type
> variable several hundred rows after it starts, with the only use it
> being passed as a parameter to the mlx4_glue->dv_set_context_attr
> function.
> However, according to DPDK Coding Style Guidelines, variables should be
> declared at the start of a block of code rather than in the middle.
> Therefore, to improve the Coding Style, the variable is passed directly
> to the function without declaring it before.
>
> Signed-off-by: Michael Baum
> Acked-by: Matan Azrad
> ---
> drivers/net/mlx4/mlx4.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index 5d72027..ff270b4 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -1054,14 +1054,13 @@ struct mlx4_conf {
> eth_dev->dev_ops = &mlx4_dev_ops;
> #ifdef HAVE_IBV_MLX4_BUF_ALLOCATORS
> /* Hint libmlx4 to use PMD allocator for data plane resources
> */
> - struct mlx4dv_ctx_allocators alctr = {
> - .alloc = &mlx4_alloc_verbs_buf,
> - .free = &mlx4_free_verbs_buf,
> - .data = priv,
> - };
> err = mlx4_glue->dv_set_context_attr
> (ctx, MLX4DV_SET_CTX_ATTR_BUF_ALLOCATORS,
> - (void *)((uintptr_t)&alctr));
> + (void *)((uintptr_t)&(struct mlx4dv_ctx_allocators){
> + .alloc = &mlx4_alloc_verbs_buf,
> + .free = &mlx4_free_verbs_buf,
> + .data = priv,
> + }));
> if (err)
> WARN("Verbs external allocator is not supported");
> else
> --
> 1.8.3.1
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte flow
> -Original Message- > From: Jerin Jacob > Sent: Sunday, June 28, 2020 9:38 PM > To: Jiawei(Jonny) Wang > Cc: Thomas Monjalon ; Ori Kam > ; Slava Ovsiienko ; > Matan Azrad ; dpdk-dev ; Raslan > Darawsheh ; ian.sto...@intel.com; > f...@redhat.com; Ferruh Yigit ; Andrew Rybchenko > > Subject: Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte > flow > > On Sun, Jun 28, 2020 at 6:46 PM Jiawei(Jonny) Wang > wrote: > > > > > > On Friday, June 26, 2020 7:10 PM Jerin Jacob > Wrote: > > > > > > On Fri, Jun 26, 2020 at 4:16 PM Thomas Monjalon > > > > > > wrote: > > > > > > > > 26/06/2020 12:35, Jerin Jacob: > > > > > On Fri, Jun 26, 2020 at 12:59 AM Thomas Monjalon > > > wrote: > > > > > > > > > > > > 25/06/2020 19:55, Jerin Jacob: > > > > > > > On Thu, Jun 25, 2020 at 10:20 PM Jiawei Wang > > > wrote: > > > > > > > > > > > > > > > > When using full offload, all traffic will be handled by > > > > > > > > the HW, and directed to the requested vf or wire, the > > > > > > > > control application loses visibility on the traffic. > > > > > > > > So there's a need for an action that will enable the > > > > > > > > control application some visibility. > > > > > > > > > > > > > > > > The solution is introduced a new action that will sample > > > > > > > > the incoming traffic and send a duplicated traffic in some > > > > > > > > predefined ratio to the application, while the original > > > > > > > > packet will continue to the target destination. > > > > > > > > > > > > > > > > The packets sampled equals is '1/ratio', if the ratio > > > > > > > > value be set to 1 , means that the packets would be > > > > > > > > completely mirrored. The sample packet can be assigned > > > > > > > > with different set of > > > actions from the original packet. > > > > > > > > > > > > > > > > In order to support the sample packet in rte_flow, new > > > > > > > > rte_flow action definition RTE_FLOW_ACTION_TYPE_SAMPLE > and > > > > > > > > structure rte_flow_action_sample > > > > > > > > > > > > > > Isn't mirroring the packet? How about, > > > > > > > RTE_FLOW_ACTION_TYPE_MIRROR I am not able to understand, > Why > > > it is called sample. > > > > > > > > > > > > Sampling is a partial mirroring. > > > > > > > > > > I think, By definition, _sampling_ is the _selection_ of items > > > > > from a specific group. > > > > > I think, _sampling_ is not dictating, what is the real action > > > > > for the "selected" items. > > > > > One can get confused with the selected ones can be for forward, > > > > > drop any other action. > > > > > > > > I see. Good design question (I will let others reply). > > > > > > > > > So IMO, explicit mirror keyword usage makes it is clear. > > > > Sampled packet is duplicated from incoming traffic at specific ratio > > and will go to different sample actions; > > ratio=1 is 100% duplication or mirroring. > > All packets will continue to go to default flow actions. > > Functionality is clear from the git commit log(Not from action name). > The only question is what would be the appropriate name for this action. > RTE_FLOW_ACTION_TYPE_SAMPLE vs RTE_FLOW_ACTION_TYPE_MIRROR > > > > > > > > > > > > > Some more related questions: > > > > > 1) What is the real use case for ratio? I am not against adding > > > > > a ratio attribute if the MLX hardware supports it. It will be > > > > > good to know the use case from the application perspective? And > > > > > what basics application set ratio != 1? > > > > > > > > If I understand well, some applications want to check, by picking > > > > random packets, that the processing is not failing. > > > > > > Not clear to me. I will wait for another explanation if any. > > > In what basics application set .1 vs .8? > > > > The real case is like monitor the traffic with full-offload. > > While packet hit the sample flow, the matching packets will be sampled > > and sent to specific Queue, align with OVS sflow probability, user > application can set it different value. > > I understand the use case for mirror and supported in a lot of HW. > What I would like to understand is the use case for "ratio"? > Is the "ratio" part of OpenFlow spec? Or Is it an MLX hardware feature? > The same usage of the 'probability' variable of ovs sample action; MLX HW implemented it. > > > > > > > > > > > > > > > > 2) If it is for "rate-limiting" or "policing", why not use > > > > > rte_mtr object (rte_mtr.h) via rte_flow action. > > > > The sample ratio isn’t the same as “meter’, the ratio of sampling will be > calculated with incoming packets mask (every some packets sampled 1). > Then the packets will be duplicated and go to do the other sample actions. > > What I meant here is , If the ratio is used for rate-limiting then having a > cascade rule like RTE_FLOW_ACTION_TYPE_MIRROR, > RTE_FLOW_ACTION_TYPE_MTR will do the job. > The ratio means the probability with packet replication, we don't need add METER action here. > > > > > > > > > 3) One of the issue for drive
Re: [dpdk-dev] [PATCH 2/3] eventdev: use c11 atomics for lcore timer armed flag
Hi Erik,
Sorry, I was on vacation.
Thanks for your feedback. I will update it in the next version.
Thanks,
Phil
> -Original Message-
> From: Carrillo, Erik G
> Sent: Wednesday, June 24, 2020 5:02 AM
> To: Phil Yang ; dev@dpdk.org
> Cc: d...@linux.vnet.ibm.com; Honnappa Nagarahalli
> ; Ruifeng Wang
> ; Dharmik Thakkar ;
> nd
> Subject: RE: [PATCH 2/3] eventdev: use c11 atomics for lcore timer armed
> flag
>
> Hi Phil,
>
> Comment in-line:
>
> > -Original Message-
> > From: Phil Yang
> > Sent: Friday, June 12, 2020 6:20 AM
> > To: dev@dpdk.org; Carrillo, Erik G
> > Cc: d...@linux.vnet.ibm.com; honnappa.nagaraha...@arm.com;
> > ruifeng.w...@arm.com; dharmik.thak...@arm.com; n...@arm.com
> > Subject: [PATCH 2/3] eventdev: use c11 atomics for lcore timer armed flag
> >
> > The in_use flag is a per core variable which is not shared between lcores in
> > the normal case and the access of this variable should be ordered on the
> > same core. However, if non-EAL thread pick the highest lcore to insert
> timers
> > into, there is the possibility of conflicts on this flag between threads.
> > Then
> > the atomic CAS operation is needed.
> >
> > Use the c11 atomic CAS instead of the generic rte_atomic operations to
> avoid
> > the unnecessary barrier on aarch64.
> >
> > Signed-off-by: Phil Yang
> > Reviewed-by: Dharmik Thakkar
> > Reviewed-by: Ruifeng Wang
> > ---
> > lib/librte_eventdev/rte_event_timer_adapter.c | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/librte_eventdev/rte_event_timer_adapter.c
> > b/lib/librte_eventdev/rte_event_timer_adapter.c
> > index 6a0e283..6947efb 100644
> > --- a/lib/librte_eventdev/rte_event_timer_adapter.c
> > +++ b/lib/librte_eventdev/rte_event_timer_adapter.c
> > @@ -554,7 +554,7 @@ struct swtim {
> > uint32_t timer_data_id;
> > /* Track which cores have actually armed a timer */
> > struct {
> > - rte_atomic16_t v;
> > + int16_t v;
> > } __rte_cache_aligned in_use[RTE_MAX_LCORE];
> > /* Track which cores' timer lists should be polled */
> > unsigned int poll_lcores[RTE_MAX_LCORE]; @@ -606,7 +606,8 @@
> > swtim_callback(struct rte_timer *tim)
> > "with immediate expiry value");
> > }
> >
> > - if (unlikely(rte_atomic16_test_and_set(&sw-
> > >in_use[lcore].v))) {
> > + if (unlikely(sw->in_use[lcore].v == 0)) {
> > + sw->in_use[lcore].v = 1;
> > n_lcores = __atomic_fetch_add(&sw->n_poll_lcores,
> > 1,
> > __ATOMIC_RELAXED);
> > __atomic_store_n(&sw->poll_lcores[n_lcores],
> > lcore, @@ -834,7 +835,7 @@ swtim_init(struct rte_event_timer_adapter
> > *adapter)
> >
> > /* Initialize the variables that track in-use timer lists */
> > for (i = 0; i < RTE_MAX_LCORE; i++)
> > - rte_atomic16_init(&sw->in_use[i].v);
> > + sw->in_use[i].v = 0;
> >
> > /* Initialize the timer subsystem and allocate timer data instance */
> > ret = rte_timer_subsystem_init();
> > @@ -1017,6 +1018,8 @@ __swtim_arm_burst(const struct
> > rte_event_timer_adapter *adapter,
> > struct rte_timer *tim, *tims[nb_evtims];
> > uint64_t cycles;
> > int n_lcores;
> > + /* Timer is not armed state */
>
> A more accurate comment would be something like "Timer list for this lcore is
> not in use".
>
> With that change, it looks good to me:
> Acked-by: Erik Gabriel Carrillo
>
> > + int16_t exp_state = 0;
> >
> > #ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> > /* Check that the service is running. */ @@ -1035,8 +1038,12 @@
> > __swtim_arm_burst(const struct rte_event_timer_adapter *adapter,
> > /* If this is the first time we're arming an event timer on this lcore,
> > * mark this lcore as "in use"; this will cause the service
> > * function to process the timer list that corresponds to this lcore.
> > +* The atomic CAS operation can prevent the race condition on
> > in_use
> > +* flag between multiple non-EAL threads.
> > */
> > - if (unlikely(rte_atomic16_test_and_set(&sw->in_use[lcore_id].v))) {
> > + if (unlikely(__atomic_compare_exchange_n(&sw-
> > >in_use[lcore_id].v,
> > + &exp_state, 1, 0,
> > + __ATOMIC_RELAXED, __ATOMIC_RELAXED))) {
> > EVTIM_LOG_DBG("Adding lcore id = %u to list of lcores to
> > poll",
> > lcore_id);
> > n_lcores = __atomic_fetch_add(&sw->n_poll_lcores, 1,
> > --
> > 2.7.4
Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte flow
On Sunday, June 28, 2020 4:27 PM, Andrew Rybchenko
wrote:
>
> On 6/25/20 7:26 PM, Jiawei Wang wrote:
> > When using full offload, all traffic will be handled by the HW, and
> > directed to the requested vf or wire, the control application loses
> > visibility on the traffic.
> > So there's a need for an action that will enable the control
> > application some visibility.
> >
> > The solution is introduced a new action that will sample the incoming
> > traffic and send a duplicated traffic in some predefined ratio to the
> > application, while the original packet will continue to the target
> > destination.
> >
> > The packets sampled equals is '1/ratio', if the ratio value be set to
> > 1 , means that the packets would be completely mirrored. The sample
> > packet can be assigned with different set of actions from the original
> packet.
> >
> > In order to support the sample packet in rte_flow, new rte_flow action
> > definition RTE_FLOW_ACTION_TYPE_SAMPLE and structure
> > rte_flow_action_sample will be introduced.
> >
> > Signed-off-by: Jiawei Wang
>
> [snip]
>
> > @@ -2709,6 +2716,28 @@ struct rte_flow_action { struct rte_flow;
> >
> > /**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * RTE_FLOW_ACTION_TYPE_SAMPLE
> > + *
> > + * Adds a sample action to a matched flow.
> > + *
> > + * The matching packets will be duplicated to a special queue or
> > +vport
> > + * in the predefined probabiilty, All the packets continues
> > +processing
> > + * on the default flow path.
> > + *
> > + * When the sample ratio is set to 1 then the packets will be 100%
> mirrored.
> > + * Additional action list be supported to add for sampled or mirrored
> packets.
> > + */
> > +struct rte_flow_action_sample {
> > + /* packets sampled equals to '1/ratio' */
> > + const uint32_t ratio;
> > + /* sub-action list specific for the sampling hit cases */
> > + const struct rte_flow_action *actions;
>
> This design idea does not look good to me from the very beginning. IMHO it
> does not fit flow API overall design.
> I mean sub-action list.
>
> As I understand Linux iptables solves it on match level (i.e. in pattern).
> E.g.
> "limit" extension which is basically sampling. Sampling using meta pattern
> item in combination with PASSTHRU action (to make sampling actions non-
> terminating if required) is a better solution from design point of view.
On our design, there're sample flow path and normal flow path, each path can
have different actions.
The defined sub-actions list only applied for sampled packets in the sample
flow path;
For normal path, all packets will continue to go with the original actions.
Re: [dpdk-dev] [PATCH 1/8] ethdev: introduce sample action for rte flow
On 6/28/20 7:16 PM, Jiawei(Jonny) Wang wrote:
>
> On Sunday, June 28, 2020 4:27 PM, Andrew Rybchenko
> wrote:
>>
>> On 6/25/20 7:26 PM, Jiawei Wang wrote:
>>> When using full offload, all traffic will be handled by the HW, and
>>> directed to the requested vf or wire, the control application loses
>>> visibility on the traffic.
>>> So there's a need for an action that will enable the control
>>> application some visibility.
>>>
>>> The solution is introduced a new action that will sample the incoming
>>> traffic and send a duplicated traffic in some predefined ratio to the
>>> application, while the original packet will continue to the target
>>> destination.
>>>
>>> The packets sampled equals is '1/ratio', if the ratio value be set to
>>> 1 , means that the packets would be completely mirrored. The sample
>>> packet can be assigned with different set of actions from the original
>> packet.
>>>
>>> In order to support the sample packet in rte_flow, new rte_flow action
>>> definition RTE_FLOW_ACTION_TYPE_SAMPLE and structure
>>> rte_flow_action_sample will be introduced.
>>>
>>> Signed-off-by: Jiawei Wang
>>
>> [snip]
>>
>>> @@ -2709,6 +2716,28 @@ struct rte_flow_action { struct rte_flow;
>>>
>>> /**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>>> + *
>>> + * RTE_FLOW_ACTION_TYPE_SAMPLE
>>> + *
>>> + * Adds a sample action to a matched flow.
>>> + *
>>> + * The matching packets will be duplicated to a special queue or
>>> +vport
>>> + * in the predefined probabiilty, All the packets continues
>>> +processing
>>> + * on the default flow path.
>>> + *
>>> + * When the sample ratio is set to 1 then the packets will be 100%
>> mirrored.
>>> + * Additional action list be supported to add for sampled or mirrored
>> packets.
>>> + */
>>> +struct rte_flow_action_sample {
>>> + /* packets sampled equals to '1/ratio' */
>>> + const uint32_t ratio;
>>> + /* sub-action list specific for the sampling hit cases */
>>> + const struct rte_flow_action *actions;
>>
>> This design idea does not look good to me from the very beginning. IMHO it
>> does not fit flow API overall design.
>> I mean sub-action list.
>>
>> As I understand Linux iptables solves it on match level (i.e. in pattern).
>> E.g.
>> "limit" extension which is basically sampling. Sampling using meta pattern
>> item in combination with PASSTHRU action (to make sampling actions non-
>> terminating if required) is a better solution from design point of view.
>
> On our design, there're sample flow path and normal flow path, each path can
> have different actions.
> The defined sub-actions list only applied for sampled packets in the sample
> flow path;
> For normal path, all packets will continue to go with the original actions.
>
In my too.
[dpdk-dev] [PATCH] rte_flow: add eCPRI key fields to flow API
Add a new item "rte_flow_item_ecpri" in order to match eCRPI header.
eCPRI is a packet based protocol used in the fronthaul interface of
5G networks. Header format definition could be found in the
specification via the link below:
https://www.gigalight.com/downloads/standards/ecpri-specification.pdf
eCPRI message can be over Ethernet layer (.1Q supported also) or over
UDP layer. Message header formats are the same in these two variants.
Signed-off-by: Bing Zhao
---
doc/guides/prog_guide/rte_flow.rst | 8 ++
lib/librte_ethdev/rte_flow.c | 1 +
lib/librte_ethdev/rte_flow.h | 31 ++
lib/librte_net/Makefile| 1 +
lib/librte_net/meson.build | 3 +-
lib/librte_net/rte_ecpri.h | 160 +
lib/librte_net/rte_ether.h | 1 +
7 files changed, 204 insertions(+), 1 deletion(-)
create mode 100644 lib/librte_net/rte_ecpri.h
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index d5dd18ce99..669d519233 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1362,6 +1362,14 @@ Matches a PFCP Header.
- ``seid``: session endpoint identifier.
- Default ``mask`` matches s_field and seid.
+Item: ``ECPRI``
+^
+
+Matches a eCPRI header.
+
+- ``hdr``: eCPRI header definition (``rte_ecpri.h``).
+- Default ``mask`` matches message type of common header only.
+
Actions
~~~
diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
index 1685be5f73..f8fdd68fe9 100644
--- a/lib/librte_ethdev/rte_flow.c
+++ b/lib/librte_ethdev/rte_flow.c
@@ -95,6 +95,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] =
{
MK_FLOW_ITEM(HIGIG2, sizeof(struct rte_flow_item_higig2_hdr)),
MK_FLOW_ITEM(L2TPV3OIP, sizeof(struct rte_flow_item_l2tpv3oip)),
MK_FLOW_ITEM(PFCP, sizeof(struct rte_flow_item_pfcp)),
+ MK_FLOW_ITEM(ECPRI, sizeof(struct rte_flow_item_ecpri)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index b0e4199192..2683466f7a 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -527,6 +528,13 @@ enum rte_flow_item_type {
*/
RTE_FLOW_ITEM_TYPE_PFCP,
+ /**
+* Matches eCPRI Header.
+* See struct rte_flow_item_ecpri.
+*
+*/
+ RTE_FLOW_ITEM_TYPE_ECPRI,
+
};
/**
@@ -1546,6 +1554,29 @@ static const struct rte_flow_item_pfcp
rte_flow_item_pfcp_mask = {
};
#endif
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_ECPRI
+ *
+ * Match eCPRI Header
+ */
+struct rte_flow_item_ecpri {
+ struct rte_ecpri_msg_hdr hdr;
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_ECPRI. */
+#ifndef __cplusplus
+static const struct rte_flow_item_ecpri rte_flow_item_ecpri_mask = {
+ .hdr = {
+ .common = {
+ .type = 0xFF,
+ },
+ },
+};
+#endif
+
/**
* Matching pattern item definition.
*
diff --git a/lib/librte_net/Makefile b/lib/librte_net/Makefile
index aa1d6fed5a..9830e771b3 100644
--- a/lib/librte_net/Makefile
+++ b/lib/librte_net/Makefile
@@ -20,5 +20,6 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_sctp.h
rte_icmp.h rte_arp.h
SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ether.h rte_gre.h rte_net.h
SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_net_crc.h rte_mpls.h
rte_higig.h
SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_gtp.h rte_vxlan.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ecpri.h
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_net/meson.build b/lib/librte_net/meson.build
index f799349b3e..24ed8253b4 100644
--- a/lib/librte_net/meson.build
+++ b/lib/librte_net/meson.build
@@ -15,7 +15,8 @@ headers = files('rte_ip.h',
'rte_net.h',
'rte_net_crc.h',
'rte_mpls.h',
- 'rte_higig.h')
+ 'rte_higig.h',
+ 'rte_ecpri.h')
sources = files('rte_arp.c', 'rte_ether.c', 'rte_net.c', 'rte_net_crc.c')
deps += ['mbuf']
diff --git a/lib/librte_net/rte_ecpri.h b/lib/librte_net/rte_ecpri.h
new file mode 100644
index 00..c1fd000775
--- /dev/null
+++ b/lib/librte_net/rte_ecpri.h
@@ -0,0 +1,160 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2020 Mellanox Technologies, Ltd
+ */
+
+#ifndef _RTE_ECPRI_H_
+#define _RTE_ECPRI_H_
+
+#include
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * eCPRI Protocol Revision 1.0, 1.1, 1.2, 2.0: 0001b
+ * Other values are reserved for future
+ */
+#define RTE_ECPRI_REV_UPTO_20 1
+
+/**
+ * eCPRI message types in specifications
+ * IWF* types will only be supported from rev.2
+ */
+#define RTE_ECPRI_MSG_TYPE_IQ_DATA 0
+#define RTE_ECPRI_MSG_TYPE_BIT_SEQ 1
+#define RTE_ECPRI_MSG_TYPE_RTC_CTRL2
+#defi
Re: [dpdk-dev] [PATCH 2/3] eventdev: use c11 atomics for lcore timer armed flag
> -Original Message-
> From: Carrillo, Erik G
> Sent: Wednesday, June 24, 2020 5:32 AM
> To: Stephen Hemminger ; Phil Yang
>
> Cc: dev@dpdk.org; d...@linux.vnet.ibm.com; Honnappa Nagarahalli
> ; Ruifeng Wang
> ; Dharmik Thakkar ;
> nd
> Subject: RE: [dpdk-dev] [PATCH 2/3] eventdev: use c11 atomics for lcore
> timer armed flag
>
> > -Original Message-
> > From: Stephen Hemminger
> > Sent: Tuesday, June 23, 2020 4:20 PM
> > To: Phil Yang
> > Cc: dev@dpdk.org; Carrillo, Erik G ;
> > d...@linux.vnet.ibm.com; honnappa.nagaraha...@arm.com;
> > ruifeng.w...@arm.com; dharmik.thak...@arm.com; n...@arm.com
> > Subject: Re: [dpdk-dev] [PATCH 2/3] eventdev: use c11 atomics for lcore
> > timer armed flag
> >
> > On Fri, 12 Jun 2020 19:19:57 +0800
> > Phil Yang wrote:
> >
> > > /* Track which cores have actually armed a timer */
> > > struct {
> > > - rte_atomic16_t v;
> > > + int16_t v;
> > > } __rte_cache_aligned in_use[RTE_MAX_LCORE];
> >
> > Do you really need this to be cache aligned (ie one per line)?
>
> I believe I did this originally to keep a cache line from bouncing when two
> different cores are arming timers, so it's not strictly necessary.
Yeah, if we remove it, these per core variables might cause a false sharing
issue between threads.
That will hurt performance.
>
> > Why have a signed value for a reference count? Shouldn't it be unsigned?
Yes. It should be unsigned in the new code.
I will update it in the next version.
Thanks,
Phil
[dpdk-dev] bnx2x pmd crash when launching testpmd using BCM57840 Nic.
Hi DPDK team, 1. I am trying to run testpmd with BCM57840 NIC using DPDK 20.02.1, the process is crashing at bnx2x_write_dmae(). Had any one seen this kind of issue earlier. root@gic-mps-104-173:~/bnx2x# ./testpmd.new -l 0-3 -n 4 -w :37:00.4 -w :37:00.5 --log-level="pmd.net.bnx2x.driver",8 -- -i --portmask=0x3 --nb-cores=2 EAL: Detected 48 lcore(s) EAL: Detected 2 NUMA nodes EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' EAL: Debug dataplane logs available - lower performance EAL: Probing VFIO support... EAL: VFIO support initialized EAL: PCI device :37:00.4 on NUMA socket 0 EAL: probe driver: 14e4:16a2 net_bnx2x [bnx2x_load_firmware:9689(37:00.4:dpdk-port-0)] fw_len = 320936 [bnx2x_attach:9756(37:00.4:dpdk-port-0)] Starting attach... [bnx2x_probe_pci_caps:7645(37:00.4:dpdk-port-0)] Found PM capability: id=0x0001 type=0x0001 addr=0x0048 [bnx2x_pcie_capability_read:7611(37:00.4:dpdk-port-0)] Found PCIe capability: id=0x0010 type=0x0001 addr=0x00AC [bnx2x_probe_pci_caps:7658(37:00.4:dpdk-port-0)] PCIe link speed=3 width=8 [bnx2x_probe_pci_caps:7674(37:00.4:dpdk-port-0)] Found MSI-X capability at 0x bnx2x_reg_write32(37:00.4:dpdk-port-0): offset=0x9430 val=0x0001 ... [bnx2x_get_device_info:8316(37:00.4:dpdk-port-0)] chip_id=0x168d1010 (num=0x168d rev=0x1 metal=0x01 bond=0x0) ... [bnx2x_get_device_info:8345(37:00.4:dpdk-port-0)] Port mode = 2 bnx2x_reg_read32(37:00.4:dpdk-port-0): offset=0x0045 val=0x00040204 [bnx2x_get_function_num:7574(37:00.4:dpdk-port-0)] Relative function 4, Absolute function 4, Path 0 ... [bnx2x_get_device_info:8382(37:00.4:dpdk-port-0)] Bootcode version: 7.14.63 ... [bnx2x_get_shmem_info:8178(37:00.4:dpdk-port-0)] Ethernet address: 20:67:7c:0d:d0:a2 ... [bnx2x_get_device_info:8448(37:00.4:dpdk-port-0)] IGU Normal Mode ... [elink_phy_probe:13507(37:00.4:dpdk-port-0)] Begin phy probe [elink_phy_probe:13526(37:00.4:dpdk-port-0)] phy_config_swapped 0, phy_index 0, actual_phy_idx 0 ... [elink_populate_int_phy:13118(37:00.4:dpdk-port-0)] :chip_id = 0x168d1000 ... [elink_populate_int_phy:13209(37:00.4:dpdk-port-0)] media_type = f0, flags = 1400, supported = a0f00 [elink_populate_int_phy:13239(37:00.4:dpdk-port-0)] Internal phy port=0, addr=0x1, mdio_ctl=0x8000 ... [elink_populate_preemphasis:13078(37:00.4:dpdk-port-0)] phy->rx_preemphasis. = 0, phy->tx_preemphasis = 0 ... [elink_populate_preemphasis:13078(37:00.4:dpdk-port-0)] phy->rx_preemphasis = 0, phy->tx_preemphasis = 0 ... [elink_phy_def_cfg:13413(37:00.4:dpdk-port-0)] Default config phy idx 0 cfg 0x0 speed_cap_mask 0x500050 [elink_phy_def_cfg:13444(37:00.4:dpdk-port-0)] Default config phy idx 0, req_duplex config 1 [elink_phy_def_cfg:13465(37:00.4:dpdk-port-0)] Requested Duplex = 1, line_speed = 0, flow_ctrl = 0 [elink_phy_probe:13526(37:00.4:dpdk-port-0)] phy_config_swapped 0, phy_index 1, actual_phy_idx 1 bnx2x_reg_read32(37:00.4:dpdk-port-0): offset=0x003c6e34 val=0x [elink_phy_probe:13574(37:00.4:dpdk-port-0)] End phy probe. #phys found 1 bnx2x_reg_read32(37:00.4:dpdk-port-0): offset=0xa9cc val=0x0001 [bnx2x_link_settings_supported:8556(37:00.4:dpdk-port-0)] PHY addr 0x0001 [bnx2x_link_settings_supported:8610(37:00.4:dpdk-port-0)] PHY supported 0=0x000a0f00 1=0x bnx2x_reg_read32(37:00.4:dpdk-port-0): offset=0x003c7008 val=0x [bnx2x_media_detect:8193(37:00.4:dpdk-port-0)] Found 10GBase-CX4 media. bnx2x_reg_read32(37:00.4:dpdk-port-0): offset=0x003c735c val=0x211a [bnx2x_attach:9824(37:00.4:dpdk-port-0)] prev unload fw_seq 0x001a [bnx2x_nic_load_analyze_req:2785(37:00.4:dpdk-port-0)] loaded FW 0x00010d07 / my FW 0x00010d07 [bnx2x_pcie_capability_read:7611(37:00.4:dpdk-port-0)] Found PCIe capability: id=0x0010 type=0x0001 addr=0x00AC bnx2x_reg_write32(37:00.4:dpdk-port-0): offset=0x003c7360 val=0x bnx2x_reg_write32(37:00.4:dpdk-port-0): offset=0x003c735c val=0x021c [elink_cb_fw_command:836(37:00.4:dpdk-port-0)] wrote command 0x021c to FW MB param 0x bnx2x_reg_read32(37:00.4:dpdk-port-0): offset=0x003c7364 val=0x2012001b bnx2x_reg_read32(37:00.4:dpdk-port-0): offset=0x003c7364 val=0x021c [bnx2x_dcbx_set_state:9546(37:00.4:dpdk-port-0)] DCB state [OFF:user-mode] [bnx2x_print_adapter_info:11819(37:00.4:dpdk-port-0)] [bnx2x_print_adapter_info:11822(37:00.4:dpdk-port-0)] DPDK : DPDK 20.02.1 [bnx2x_print_adapter_info:11824(37:00.4:dpdk-port-0)] Driver : BNX2X PMD 1.78.18_1.1.0.1 [bnx2x_print_adapter_info:11830(37:00.4:dpdk-port-0)] Firmware : 7.13.1 [bnx2x_print_adapter_info:11832(37:00.4:dpdk-port-0)] Bootcode : 7.14.63 [bnx2x_print_adapter_info:11834(37:00.4:dpdk-port-0)] ASIC : 0x168d1010 [bnx2x_print_adapter_info:11836(37:00.4:dpdk-port-0)] Rev : B1 [bnx2x_print_adapter_info:11839(37:00.4:dpdk-port-0)]Vendor Id : 0x14e4 [bnx2x_p
Re: [dpdk-dev] [PATCH 3/3] eventdev: relax smp barriers with c11 atomics
Hi Erick,
> -Original Message-
> From: Carrillo, Erik G
> Sent: Wednesday, June 24, 2020 3:39 AM
> To: Phil Yang ; dev@dpdk.org
> Cc: d...@linux.vnet.ibm.com; Honnappa Nagarahalli
> ; Ruifeng Wang
> ; Dharmik Thakkar ;
> nd
> Subject: RE: [dpdk-dev] [PATCH 3/3] eventdev: relax smp barriers with c11
> atomics
>
> Hi Phil,
>
> Comment in-line:
>
> > -Original Message-
> > From: Phil Yang
> > Sent: Monday, June 22, 2020 5:12 AM
> > To: Phil Yang ; dev@dpdk.org; Carrillo, Erik G
> >
> > Cc: d...@linux.vnet.ibm.com; Honnappa Nagarahalli
> > ; Ruifeng Wang
> > ; Dharmik Thakkar
> > ; nd
> > Subject: RE: [dpdk-dev] [PATCH 3/3] eventdev: relax smp barriers with c11
> > atomics
> >
> > > -Original Message-
> > > From: dev On Behalf Of Phil Yang
> > > Sent: Friday, June 12, 2020 7:20 PM
> > > To: dev@dpdk.org; erik.g.carri...@intel.com
> > > Cc: d...@linux.vnet.ibm.com; Honnappa Nagarahalli
> > > ; Ruifeng Wang
> > ;
> > > Dharmik Thakkar ; nd
> > > Subject: [dpdk-dev] [PATCH 3/3] eventdev: relax smp barriers with c11
> > > atomics
> > >
> > > The implementation-specific opaque data is shared between arm and
> > > cancel operations. The state flag acts as a guard variable to make
> > > sure the update of opaque data is synchronized. This patch uses c11
> > > atomics with explicit one way memory barrier instead of full barriers
> > > rte_smp_w/rmb() to synchronize the opaque data between timer arm
> and
> > cancel threads.
> > >
> > > Signed-off-by: Phil Yang
> > > Reviewed-by: Dharmik Thakkar
> > > Reviewed-by: Ruifeng Wang
> > > ---
> > > lib/librte_eventdev/rte_event_timer_adapter.c | 55
> > > ++-
> > > lib/librte_eventdev/rte_event_timer_adapter.h | 2 +-
> > > 2 files changed, 38 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/lib/librte_eventdev/rte_event_timer_adapter.c
> > > b/lib/librte_eventdev/rte_event_timer_adapter.c
> > > index 6947efb..0a26501 100644
> > > --- a/lib/librte_eventdev/rte_event_timer_adapter.c
> > > +++ b/lib/librte_eventdev/rte_event_timer_adapter.c
> > > @@ -629,7 +629,8 @@ swtim_callback(struct rte_timer *tim)
> > > sw->expired_timers[sw->n_expired_timers++] = tim;
> > > sw->stats.evtim_exp_count++;
> > >
> > > - evtim->state = RTE_EVENT_TIMER_NOT_ARMED;
> > > + __atomic_store_n(&evtim->state,
> > > RTE_EVENT_TIMER_NOT_ARMED,
> > > + __ATOMIC_RELEASE);
> > > }
> > >
> > > if (event_buffer_batch_ready(&sw->buffer)) { @@ -1020,6 +1021,7
> > @@
> > > __swtim_arm_burst(const struct rte_event_timer_adapter *adapter,
> > > int n_lcores;
> > > /* Timer is not armed state */
> > > int16_t exp_state = 0;
> > > + enum rte_event_timer_state n_state;
> > >
> > > #ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> > > /* Check that the service is running. */ @@ -1060,30 +1062,36 @@
> > > __swtim_arm_burst(const struct rte_event_timer_adapter *adapter,
> > > }
> > >
> > > for (i = 0; i < nb_evtims; i++) {
> > > - /* Don't modify the event timer state in these cases */
> > > - if (evtims[i]->state == RTE_EVENT_TIMER_ARMED) {
> > > + n_state = __atomic_load_n(&evtims[i]->state,
> > > __ATOMIC_RELAXED);
> > > + if (n_state == RTE_EVENT_TIMER_ARMED) {
> > > rte_errno = EALREADY;
> > > break;
> > > - } else if (!(evtims[i]->state ==
> > > RTE_EVENT_TIMER_NOT_ARMED ||
> > > - evtims[i]->state ==
> > > RTE_EVENT_TIMER_CANCELED)) {
> > > + } else if (!(n_state == RTE_EVENT_TIMER_NOT_ARMED ||
> > > + n_state == RTE_EVENT_TIMER_CANCELED)) {
> > > rte_errno = EINVAL;
> > > break;
> > > }
> > >
> > > ret = check_timeout(evtims[i], adapter);
> > > if (unlikely(ret == -1)) {
> > > - evtims[i]->state =
> > > RTE_EVENT_TIMER_ERROR_TOOLATE;
> > > + __atomic_store_n(&evtims[i]->state,
> > > +
> > RTE_EVENT_TIMER_ERROR_TOOLATE,
> > > + __ATOMIC_RELAXED);
> > > rte_errno = EINVAL;
> > > break;
> > > } else if (unlikely(ret == -2)) {
> > > - evtims[i]->state =
> > > RTE_EVENT_TIMER_ERROR_TOOEARLY;
> > > + __atomic_store_n(&evtims[i]->state,
> > > +
> > > RTE_EVENT_TIMER_ERROR_TOOEARLY,
> > > + __ATOMIC_RELAXED);
> > > rte_errno = EINVAL;
> > > break;
> > > }
> > >
> > > if (unlikely(check_destination_event_queue(evtims[i],
> > > adapter) < 0)) {
> > > - evtims[i]->state = RTE_EVENT_TIMER_ERROR;
> > > + __atomic_store_n(&evtims[i]->state,
> > > + RTE_EVENT_TIMER_ERROR,
> > > + __ATOMIC_RELAXED);
> > > rte_
Re: [dpdk-dev] [PATCH v2 4/5] telemetry: implement empty stubs for Windows
On Sun, 28 Jun 2020 13:58:50 +0300 Fady Bader wrote: > Telemetry didn't compile under Windows. > Empty stubs implementation was added for Windows. > > Signed-off-by: Fady Bader Maybe ethdev could be modified to not depend on telemetry library directly. The current way means every application gets the telemetry library (on Linux) even though few use it.
[dpdk-dev] [PATCH v6] net/octeontx2: add devargs to lock Rx/Tx ctx
From: Pavan Nikhilesh
Add device arguments to lock Rx/Tx contexts.
Application can either choose to lock Rx or Tx contexts by using
'lock_rx_ctx' or 'lock_tx_ctx' respectively per each port.
Example:
-w 0002:02:00.0,lock_rx_ctx=1 -w 0002:03:00.0,lock_tx_ctx=1
Signed-off-by: Pavan Nikhilesh
Reviewed-by: Andrzej Ostruszka
---
v6 Changes:
- Rebase on next-net-mrvl.
v5 Changes:
- Remove redundant goto.(Andrzej)
v4 Changes:
- Fix return path using unnecessary goto.(Andrzej)
- Fix datatype of values passed to devargs parser.(Andrzej)
v3 Changes:
- Split series into individual patches as targets are different.
doc/guides/nics/octeontx2.rst | 16 ++
drivers/net/octeontx2/otx2_ethdev.c | 196 +++-
drivers/net/octeontx2/otx2_ethdev.h | 2 +
drivers/net/octeontx2/otx2_ethdev_devargs.c | 16 +-
drivers/net/octeontx2/otx2_rss.c| 23 +++
5 files changed, 244 insertions(+), 9 deletions(-)
diff --git a/doc/guides/nics/octeontx2.rst b/doc/guides/nics/octeontx2.rst
index 24089ce67..bb591a8b7 100644
--- a/doc/guides/nics/octeontx2.rst
+++ b/doc/guides/nics/octeontx2.rst
@@ -210,6 +210,22 @@ Runtime Config Options
With the above configuration, application can enable inline IPsec processing
on 128 SAs (SPI 0-127).
+- ``Lock Rx contexts in NDC cache``
+
+ Lock Rx contexts in NDC cache by using ``lock_rx_ctx`` parameter.
+
+ For example::
+
+ -w 0002:02:00.0,lock_rx_ctx=1
+
+- ``Lock Tx contexts in NDC cache``
+
+ Lock Tx contexts in NDC cache by using ``lock_tx_ctx`` parameter.
+
+ For example::
+
+ -w 0002:02:00.0,lock_tx_ctx=1
+
.. note::
Above devarg parameters are configurable per device, user needs to pass the
diff --git a/drivers/net/octeontx2/otx2_ethdev.c
b/drivers/net/octeontx2/otx2_ethdev.c
index 095506034..1c0fb0020 100644
--- a/drivers/net/octeontx2/otx2_ethdev.c
+++ b/drivers/net/octeontx2/otx2_ethdev.c
@@ -298,8 +298,7 @@ nix_cq_rq_init(struct rte_eth_dev *eth_dev, struct
otx2_eth_dev *dev,
NIX_CQ_ALIGN, dev->node);
if (rz == NULL) {
otx2_err("Failed to allocate mem for cq hw ring");
- rc = -ENOMEM;
- goto fail;
+ return -ENOMEM;
}
memset(rz->addr, 0, rz->len);
rxq->desc = (uintptr_t)rz->addr;
@@ -348,7 +347,7 @@ nix_cq_rq_init(struct rte_eth_dev *eth_dev, struct
otx2_eth_dev *dev,
rc = otx2_mbox_process(mbox);
if (rc) {
otx2_err("Failed to init cq context");
- goto fail;
+ return rc;
}
aq = otx2_mbox_alloc_msg_nix_aq_enq(mbox);
@@ -387,12 +386,44 @@ nix_cq_rq_init(struct rte_eth_dev *eth_dev, struct
otx2_eth_dev *dev,
rc = otx2_mbox_process(mbox);
if (rc) {
otx2_err("Failed to init rq context");
- goto fail;
+ return rc;
+ }
+
+ if (dev->lock_rx_ctx) {
+ aq = otx2_mbox_alloc_msg_nix_aq_enq(mbox);
+ aq->qidx = qid;
+ aq->ctype = NIX_AQ_CTYPE_CQ;
+ aq->op = NIX_AQ_INSTOP_LOCK;
+
+ aq = otx2_mbox_alloc_msg_nix_aq_enq(mbox);
+ if (!aq) {
+ /* The shared memory buffer can be full.
+* Flush it and retry
+*/
+ otx2_mbox_msg_send(mbox, 0);
+ rc = otx2_mbox_wait_for_rsp(mbox, 0);
+ if (rc < 0) {
+ otx2_err("Failed to LOCK cq context");
+ return rc;
+ }
+
+ aq = otx2_mbox_alloc_msg_nix_aq_enq(mbox);
+ if (!aq) {
+ otx2_err("Failed to LOCK rq context");
+ return -ENOMEM;
+ }
+ }
+ aq->qidx = qid;
+ aq->ctype = NIX_AQ_CTYPE_RQ;
+ aq->op = NIX_AQ_INSTOP_LOCK;
+ rc = otx2_mbox_process(mbox);
+ if (rc < 0) {
+ otx2_err("Failed to LOCK rq context");
+ return rc;
+ }
}
return 0;
-fail:
- return rc;
}
static int
@@ -439,6 +470,40 @@ nix_cq_rq_uninit(struct rte_eth_dev *eth_dev, struct
otx2_eth_rxq *rxq)
return rc;
}
+ if (dev->lock_rx_ctx) {
+ aq = otx2_mbox_alloc_msg_nix_aq_enq(mbox);
+ aq->qidx = rxq->rq;
+ aq->ctype = NIX_AQ_CTYPE_CQ;
+ aq->op = NIX_AQ_INSTOP_UNLOCK;
+
+ aq = otx2_mbox_alloc_msg_nix_aq_enq(mbox);
+ if (!aq) {
+ /* The shared memory buffer can be full.
+* Flush it and retry
+*/
+ otx2_mbox_msg_send(mbox, 0);
+
[dpdk-dev] [PATCH] net/octeontx2: free CQ ring memzone on queue release
From: Pavan Nikhilesh
Free CQ ring memzone on Rx queue release. This prevents CQ using
incorrect memory size when ring size is reconfigured.
Signed-off-by: Pavan Nikhilesh
---
This patch depends on the following patch
http://patches.dpdk.org/patch/72035/
drivers/net/octeontx2/otx2_ethdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/octeontx2/otx2_ethdev.c
b/drivers/net/octeontx2/otx2_ethdev.c
index 3f3f0a693..a1084bf96 100644
--- a/drivers/net/octeontx2/otx2_ethdev.c
+++ b/drivers/net/octeontx2/otx2_ethdev.c
@@ -528,6 +528,7 @@ otx2_nix_rx_queue_setup(struct rte_eth_dev *eth_dev,
uint16_t rq,
if (eth_dev->data->rx_queues[rq] != NULL) {
otx2_nix_dbg("Freeing memory prior to re-allocation %d", rq);
otx2_nix_rx_queue_release(eth_dev->data->rx_queues[rq]);
+ rte_eth_dma_zone_free(eth_dev, "cq", rq);
eth_dev->data->rx_queues[rq] = NULL;
}
--
2.17.1
Re: [dpdk-dev] [PATCH v1 1/2] vhost: introduce async data path registration API
Hi Maxime,
> -Original Message-
> From: Maxime Coquelin
> Sent: Friday, June 26, 2020 10:29 PM
> To: Fu, Patrick ; dev@dpdk.org; Xia, Chenbo
> ; Wang, Zhihong ; Ye,
> Xiaolong
> Cc: Jiang, Cheng1 ; Liang, Cunming
>
> Subject: Re: [PATCH v1 1/2] vhost: introduce async data path registration API
>
>
>
> On 6/11/20 12:02 PM, patrick...@intel.com wrote:
> > From: Patrick
> >
> > diff --git a/lib/librte_vhost/socket.c b/lib/librte_vhost/socket.c
> > index 0a66ef9..f817783 100644
> > --- a/lib/librte_vhost/socket.c
> > +++ b/lib/librte_vhost/socket.c
> > @@ -42,6 +42,7 @@ struct vhost_user_socket {
> > bool use_builtin_virtio_net;
> > bool extbuf;
> > bool linearbuf;
> > + bool async_copy;
> >
> > /*
> > * The "supported_features" indicates the feature bits the @@ -210,6
> > +211,7 @@ struct vhost_user {
> > size_t size;
> > struct vhost_user_connection *conn;
> > int ret;
> > + struct virtio_net *dev;
> >
> > if (vsocket == NULL)
> > return;
> > @@ -241,6 +243,13 @@ struct vhost_user {
> > if (vsocket->linearbuf)
> > vhost_enable_linearbuf(vid);
> >
> > + if (vsocket->async_copy) {
> > + dev = get_device(vid);
> > +
> > + if (dev)
> > + dev->async_copy = 1;
> > + }
> > +
> > VHOST_LOG_CONFIG(INFO, "new device, handle is %d\n", vid);
> >
> > if (vsocket->notify_ops->new_connection) { @@ -891,6 +900,17 @@
> > struct vhost_user_reconnect_list {
> > goto out_mutex;
> > }
> >
> > + vsocket->async_copy = flags & RTE_VHOST_USER_ASYNC_COPY;
> > +
> > + if (vsocket->async_copy &&
> > + (flags & (RTE_VHOST_USER_IOMMU_SUPPORT |
> > + RTE_VHOST_USER_POSTCOPY_SUPPORT))) {
> > + VHOST_LOG_CONFIG(ERR, "error: enabling async copy and
> IOMMU "
> > + "or post-copy feature simultaneously is not "
> > + "supported\n");
> > + goto out_mutex;
> > + }
> > +
>
> Have you ensure compatibility with the linearbuf feature (TSO)?
> You will want to do same kind of check if not compatible.
>
I think this concern comes primarily from dequeue side. As current patch is for
enqueue only,
linearbuf check doesn't seem to be necessary. For future dequeue
implementation, we may
need to add an additional feature bit to let application to decide if the async
callback is
compatible with linearbuf or not. For a real hardware DMA engine, it should
usually support
linearbuf. For a pure software backend (something like dequeue-zero-copy), it
may not support.
> > /*
> > * Set the supported features correctly for the builtin vhost-user
> > * net driver.
> > diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c index
> > 0266318..e6b688a 100644
> > --- a/lib/librte_vhost/vhost.c
> > +++ b/lib/librte_vhost/vhost.c
> > @@ -332,8 +332,13 @@
> > {
> > if (vq_is_packed(dev))
> > rte_free(vq->shadow_used_packed);
> > - else
> > + else {
> > rte_free(vq->shadow_used_split);
> > + if (vq->async_pkts_pending)
> > + rte_free(vq->async_pkts_pending);
> > + if (vq->async_pending_info)
> > + rte_free(vq->async_pending_info);
> > + }
> > rte_free(vq->batch_copy_elems);
> > rte_mempool_free(vq->iotlb_pool);
> > rte_free(vq);
> > @@ -1527,3 +1532,70 @@ int rte_vhost_extern_callback_register(int vid,
> > if (vhost_data_log_level >= 0)
> > rte_log_set_level(vhost_data_log_level,
> RTE_LOG_WARNING); }
> > +
> > +int rte_vhost_async_channel_register(int vid, uint16_t queue_id,
> > + uint32_t features,
> > + struct rte_vhost_async_channel_ops
> *ops) {
> > + struct vhost_virtqueue *vq;
> > + struct virtio_net *dev = get_device(vid);
> > + struct dma_channel_features f;
> > +
> > + if (dev == NULL || ops == NULL)
> > + return -1;
> > +
> > + f.intval = features;
> > +
> > + vq = dev->virtqueue[queue_id];
> > +
> > + if (vq == NULL)
> > + return -1;
> > +
> > + /** packed queue is not supported */
> > + if (vq_is_packed(dev) || !f.inorder)
> > + return -1;
>
> You might want to print an error message to help the user understanding
> why it fails.
>
Will update in v2 patch
> > +
> > + if (ops->check_completed_copies == NULL ||
> > + ops->transfer_data == NULL)
> > + return -1;
> > +
> > + rte_spinlock_lock(&vq->access_lock);
> > +
> > + vq->async_ops.check_completed_copies = ops-
> >check_completed_copies;
> > + vq->async_ops.transfer_data = ops->transfer_data;
> > +
> > + vq->async_inorder = f.inorder;
> > + vq->async_threshold = f.threshold;
> > +
> > + vq->async_registered = true;
> > +
> > + rte_spinlock_unlock(&vq->access_lock);
> > +
> > + return 0;
> > +}
> > +
> > +int rte_vhost_async_channel_unregister(int vid, uint16_t queue_id) {
>
Re: [dpdk-dev] [PATCH v1 2/2] vhost: introduce async enqueue for split ring
Hi Maxime, > -Original Message- > From: Maxime Coquelin > Sent: Friday, June 26, 2020 10:46 PM > To: Fu, Patrick ; dev@dpdk.org; Xia, Chenbo > ; Wang, Zhihong ; Ye, > Xiaolong > Cc: Jiang, Cheng1 ; Liang, Cunming > > Subject: Re: [PATCH v1 2/2] vhost: introduce async enqueue for split ring > > > > On 6/11/20 12:02 PM, patrick...@intel.com wrote: > > From: Patrick > > > > This patch implement async enqueue data path for split ring. > > > > Signed-off-by: Patrick > > --- > > lib/librte_vhost/rte_vhost_async.h | 38 +++ > > lib/librte_vhost/virtio_net.c | 538 > - > > 2 files changed, 574 insertions(+), 2 deletions(-) > > > > diff --git a/lib/librte_vhost/rte_vhost_async.h > > b/lib/librte_vhost/rte_vhost_async.h > > index 82f2ebe..efcba0a 100644 > > --- a/lib/librte_vhost/rte_vhost_async.h > > +++ b/lib/librte_vhost/rte_vhost_async.h > > @@ -131,4 +131,42 @@ int rte_vhost_async_channel_register(int vid, > uint16_t queue_id, > > */ > > int rte_vhost_async_channel_unregister(int vid, uint16_t queue_id); > > > > +/** > > + * This function submit enqueue data to DMA. This function has no > > + * guranttee to the transfer completion upon return. Applications > > +should > > + * poll transfer status by rte_vhost_poll_enqueue_completed() > > + * > > + * @param vid > > + * id of vhost device to enqueue data > > + * @param queue_id > > + * queue id to enqueue data > > + * @param pkts > > + * array of packets to be enqueued > > + * @param count > > + * packets num to be enqueued > > + * @return > > + * num of packets enqueued > > + */ > > +uint16_t rte_vhost_submit_enqueue_burst(int vid, uint16_t queue_id, > > + struct rte_mbuf **pkts, uint16_t count); > > + > > +/** > > + * This function check DMA completion status for a specific vhost > > + * device queue. Packets which finish copying (enqueue) operation > > + * will be returned in an array. > > + * > > + * @param vid > > + * id of vhost device to enqueue data > > + * @param queue_id > > + * queue id to enqueue data > > + * @param pkts > > + * blank array to get return packet pointer > > + * @param count > > + * size of the packet array > > + * @return > > + * num of packets returned > > + */ > > +uint16_t rte_vhost_poll_enqueue_completed(int vid, uint16_t queue_id, > > + struct rte_mbuf **pkts, uint16_t count); > > + > > These new APIs need to be tagged as experimental. We'll need a few releases > before considering them stable. > > You need to add them to rte_vhost_version.map too. > > > #endif /* _RTE_VDPA_H_ */ > You need to fix the comment here (/* _RTE_VHOST_ASYNC_H_ */) I will update in the v2 version Thanks, Patrick
Re: [dpdk-dev] [PATCH 20.08] mempool/ring: add support for new ring sync modes
Hi Konstantin, I think this warrants a bullet point in the release notes. With that: Acked-by: Gage Eads mailto:gage.e...@intel.com>> Thanks, Gage
[dpdk-dev] [PATCH 2/3] event/octeontx2: fix sub event type violation
From: Pavan Nikhilesh
In OCTEONTX2 event device we use sub_event_type to store the ethernet
port identifier when we receive work from OCTEONTX2 ethernet device.
This violates the event device spec as sub_event_type should be 0 in
the initial receive stage.
Set sub_event_type to 0 after copying the port id.
Fixes: 0fe4accd8ec8 ("event/octeontx2: add Rx adapter fastpath ops")
Cc: sta...@dpdk.org
Signed-off-by: Pavan Nikhilesh
---
drivers/event/octeontx2/otx2_worker_dual.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/event/octeontx2/otx2_worker_dual.h
b/drivers/event/octeontx2/otx2_worker_dual.h
index c88420eb4..60aa14cca 100644
--- a/drivers/event/octeontx2/otx2_worker_dual.h
+++ b/drivers/event/octeontx2/otx2_worker_dual.h
@@ -65,8 +65,11 @@ otx2_ssogws_dual_get_work(struct otx2_ssogws_state *ws,
if (event.sched_type != SSO_TT_EMPTY &&
event.event_type == RTE_EVENT_TYPE_ETHDEV) {
- otx2_wqe_to_mbuf(get_work1, mbuf, event.sub_event_type,
-(uint32_t) event.get_work0, flags, lookup_mem);
+ uint8_t port = event.sub_event_type;
+
+ event.sub_event_type = 0;
+ otx2_wqe_to_mbuf(get_work1, mbuf, port,
+event.flow_id, flags, lookup_mem);
/* Extracting tstamp, if PTP enabled. CGX will prepend the
* timestamp at starting of packet data and it can be derieved
* from WQE 9 dword which corresponds to SG iova.
--
2.17.1
[dpdk-dev] [PATCH 1/3] event/octeontx2: fix device reconfigure
From: Pavan Nikhilesh
When event device is re-configured maintain the event queue to event port
links and event port status instead of resetting them.
Fixes: cd24e70258bd ("event/octeontx2: add device configure function")
Cc: sta...@dpdk.org
Signed-off-by: Pavan Nikhilesh
---
drivers/event/octeontx2/otx2_evdev.c | 60 +++-
1 file changed, 50 insertions(+), 10 deletions(-)
diff --git a/drivers/event/octeontx2/otx2_evdev.c
b/drivers/event/octeontx2/otx2_evdev.c
index 630073de5..b8b57c388 100644
--- a/drivers/event/octeontx2/otx2_evdev.c
+++ b/drivers/event/octeontx2/otx2_evdev.c
@@ -725,6 +725,46 @@ sso_clr_links(const struct rte_eventdev *event_dev)
}
}
+static void
+sso_restore_links(const struct rte_eventdev *event_dev)
+{
+ struct otx2_sso_evdev *dev = sso_pmd_priv(event_dev);
+ uint16_t *links_map;
+ int i, j;
+
+ for (i = 0; i < dev->nb_event_ports; i++) {
+ links_map = event_dev->data->links_map;
+ /* Point links_map to this port specific area */
+ links_map += (i * RTE_EVENT_MAX_QUEUES_PER_DEV);
+ if (dev->dual_ws) {
+ struct otx2_ssogws_dual *ws;
+
+ ws = event_dev->data->ports[i];
+ for (j = 0; j < dev->nb_event_queues; j++) {
+ if (links_map[j] == 0xdead)
+ continue;
+ sso_port_link_modify((struct otx2_ssogws *)
+ &ws->ws_state[0], j, true);
+ sso_port_link_modify((struct otx2_ssogws *)
+ &ws->ws_state[1], j, true);
+ sso_func_trace("Restoring port %d queue %d "
+ "link", i, j);
+ }
+ } else {
+ struct otx2_ssogws *ws;
+
+ ws = event_dev->data->ports[i];
+ for (j = 0; j < dev->nb_event_queues; j++) {
+ if (links_map[j] == 0xdead)
+ continue;
+ sso_port_link_modify(ws, j, true);
+ sso_func_trace("Restoring port %d queue %d "
+ "link", i, j);
+ }
+ }
+ }
+}
+
static void
sso_set_port_ops(struct otx2_ssogws *ws, uintptr_t base)
{
@@ -765,18 +805,15 @@ sso_configure_dual_ports(const struct rte_eventdev
*event_dev)
struct otx2_ssogws_dual *ws;
uintptr_t base;
- /* Free memory prior to re-allocation if needed */
if (event_dev->data->ports[i] != NULL) {
ws = event_dev->data->ports[i];
- rte_free(ws);
- ws = NULL;
- }
-
- /* Allocate event port memory */
- ws = rte_zmalloc_socket("otx2_sso_ws",
+ } else {
+ /* Allocate event port memory */
+ ws = rte_zmalloc_socket("otx2_sso_ws",
sizeof(struct otx2_ssogws_dual),
RTE_CACHE_LINE_SIZE,
event_dev->data->socket_id);
+ }
if (ws == NULL) {
otx2_err("Failed to alloc memory for port=%d", i);
rc = -ENOMEM;
@@ -1061,8 +1098,11 @@ otx2_sso_configure(const struct rte_eventdev *event_dev)
return -EINVAL;
}
- if (dev->configured)
+ if (dev->configured) {
sso_unregister_irqs(event_dev);
+ /* Clear any prior port-queue mapping. */
+ sso_clr_links(event_dev);
+ }
if (dev->nb_event_queues) {
/* Finit any previous queues. */
@@ -1097,8 +1137,8 @@ otx2_sso_configure(const struct rte_eventdev *event_dev)
goto teardown_hwggrp;
}
- /* Clear any prior port-queue mapping. */
- sso_clr_links(event_dev);
+ /* Restore any prior port-queue mapping. */
+ sso_restore_links(event_dev);
rc = sso_ggrp_alloc_xaq(dev);
if (rc < 0) {
otx2_err("Failed to alloc xaq to ggrp %d", rc);
--
2.17.1
[dpdk-dev] [PATCH 3/3] event/octeontx2: improve datapath memory locality
From: Pavan Nikhilesh
When event device is transmitting packet on OCTEONTX2 it needs to access
the destined ethernet device TXq data.
Currently, we get the TXq data through rte_eth_devices global array.
Instead save the TXq address inside event port memory.
Cc: sta...@dpdk.org
Signed-off-by: Pavan Nikhilesh
---
drivers/event/octeontx2/otx2_evdev.h | 5 ++
drivers/event/octeontx2/otx2_evdev_adptr.c | 67 +-
drivers/event/octeontx2/otx2_worker.c | 15 +++--
drivers/event/octeontx2/otx2_worker.h | 21 ---
drivers/event/octeontx2/otx2_worker_dual.c | 15 +++--
5 files changed, 103 insertions(+), 20 deletions(-)
diff --git a/drivers/event/octeontx2/otx2_evdev.h
b/drivers/event/octeontx2/otx2_evdev.h
index 3b477820f..873724dd4 100644
--- a/drivers/event/octeontx2/otx2_evdev.h
+++ b/drivers/event/octeontx2/otx2_evdev.h
@@ -141,6 +141,7 @@ struct otx2_sso_evdev {
uint64_t adptr_xae_cnt;
uint16_t rx_adptr_pool_cnt;
uint64_t *rx_adptr_pools;
+ uint16_t max_port_id;
uint16_t tim_adptr_ring_cnt;
uint16_t *timer_adptr_rings;
uint64_t *timer_adptr_sz;
@@ -185,6 +186,8 @@ struct otx2_ssogws {
uintptr_t grps_base[OTX2_SSO_MAX_VHGRP];
/* PTP timestamp */
struct otx2_timesync_info *tstamp;
+ /* Tx Fastpath data */
+ uint8_t tx_adptr_data[] __rte_cache_aligned;
} __rte_cache_aligned;
struct otx2_ssogws_state {
@@ -204,6 +207,8 @@ struct otx2_ssogws_dual {
uintptr_t grps_base[OTX2_SSO_MAX_VHGRP];
/* PTP timestamp */
struct otx2_timesync_info *tstamp;
+ /* Tx Fastpath data */
+ uint8_t tx_adptr_data[] __rte_cache_aligned;
} __rte_cache_aligned;
static inline struct otx2_sso_evdev *
diff --git a/drivers/event/octeontx2/otx2_evdev_adptr.c
b/drivers/event/octeontx2/otx2_evdev_adptr.c
index 8bdcfa3ea..0a5d7924a 100644
--- a/drivers/event/octeontx2/otx2_evdev_adptr.c
+++ b/drivers/event/octeontx2/otx2_evdev_adptr.c
@@ -438,6 +438,60 @@ sso_sqb_aura_limit_edit(struct rte_mempool *mp, uint16_t
nb_sqb_bufs)
return otx2_mbox_process(npa_lf->mbox);
}
+static int
+sso_add_tx_queue_data(const struct rte_eventdev *event_dev,
+ uint16_t eth_port_id, uint16_t tx_queue_id,
+ struct otx2_eth_txq *txq)
+{
+ struct otx2_sso_evdev *dev = sso_pmd_priv(event_dev);
+ int i;
+
+ for (i = 0; i < event_dev->data->nb_ports; i++) {
+ dev->max_port_id = RTE_MAX(dev->max_port_id, eth_port_id);
+ if (dev->dual_ws) {
+ struct otx2_ssogws_dual *old_dws;
+ struct otx2_ssogws_dual *dws;
+
+ old_dws = event_dev->data->ports[i];
+ dws = rte_realloc_socket(old_dws,
+sizeof(struct otx2_ssogws_dual)
++ (sizeof(uint64_t) *
+ (dev->max_port_id + 1) *
+ RTE_MAX_QUEUES_PER_PORT),
+RTE_CACHE_LINE_SIZE,
+event_dev->data->socket_id);
+ if (dws == NULL)
+ return -ENOMEM;
+
+ ((uint64_t (*)[RTE_MAX_QUEUES_PER_PORT]
+)&dws->tx_adptr_data)[eth_port_id][tx_queue_id] =
+ (uint64_t)txq;
+ event_dev->data->ports[i] = dws;
+ } else {
+ struct otx2_ssogws *old_ws;
+ struct otx2_ssogws *ws;
+
+ old_ws = event_dev->data->ports[i];
+ ws = rte_realloc_socket(old_ws,
+ sizeof(struct otx2_ssogws_dual)
+ + (sizeof(uint64_t) *
+ (dev->max_port_id + 1) *
+ RTE_MAX_QUEUES_PER_PORT),
+ RTE_CACHE_LINE_SIZE,
+ event_dev->data->socket_id);
+ if (ws == NULL)
+ return -ENOMEM;
+
+ ((uint64_t (*)[RTE_MAX_QUEUES_PER_PORT]
+)&ws->tx_adptr_data)[eth_port_id][tx_queue_id] =
+ (uint64_t)txq;
+ event_dev->data->ports[i] = ws;
+ }
+ }
+
+ return 0;
+}
+
int
otx2_sso_tx_adapter_queue_add(uint8_t id, const struct rte_eventdev *event_dev,
const struct rte_eth_dev *eth_dev,
@@ -446,18 +500,27 @@ otx2_sso_tx_adapter_queue_add(uint8_t id, const struct
rte_eventdev *event_dev,
struct otx2_eth_dev *otx2_eth_dev = eth_dev->data->
Re: [dpdk-dev] [PATCH v4 2/2] ethdev: fix VLAN offloads set if no relative capabilities
Hi, Heinrich Kuhn & Harman Kalra & Jerin Jacob & Nithin Dabilpuram &
Kiran Kumar K &
Rasesh Mody & Shahed Shaikh & Qi Zhang & Xiao Wang & Beilei Xing & Jeff Guo.
Could you please help to review this patch and give 'Acked-by' if there
are no objects.
Thanks, Xavier
On 2020/6/22 16:09, Wei Hu (Xavier) wrote:
Currently, there is a potential problem that calling the API function
rte_eth_dev_set_vlan_offload to start VLAN hardware offloads which the
driver does not support. If the PMD driver does not support certain VLAN
hardware offloads and does not check for it, the hardware setting will
not change, but the VLAN offloads in dev->data->dev_conf.rxmode.offloads
will be turned on.
It is supposed to check the hardware capabilities to decide whether the
relative callback needs to be called just like the behavior in the API
function named rte_eth_dev_configure. And it is also needed to cleanup
duplicated checks which are done in some PMDs. Also, note that it is
behaviour change for some PMDs which simply ignore (with error/warning log
message) unsupported VLAN offloads, but now it will fail.
Fixes: a4996bd89c42 ("ethdev: new Rx/Tx offloads API")
Cc: sta...@dpdk.org
Signed-off-by: Chengchang Tang
Signed-off-by: Wei Hu (Xavier)
Acked-by: Andrew Rybchenko
Acked-by: Hyong Youb Kim
---
v3 -> v4: Delete "next_mask" label and modify the function that when the
offload is not supported the function fail.
v2 -> v3: Add __rte_unused to avoid unused parameter 'dev' and 'mask'
warning.
v1 -> v2: Cleanup duplicated checks which are done in some PMDs.
---
drivers/net/dpaa2/dpaa2_ethdev.c | 12 +++-
drivers/net/enic/enic_ethdev.c | 12
drivers/net/fm10k/fm10k_ethdev.c | 23 ++-
drivers/net/hinic/hinic_pmd_ethdev.c | 6 --
drivers/net/i40e/i40e_ethdev.c | 5 -
drivers/net/nfp/nfp_net.c | 5 -
drivers/net/octeontx/octeontx_ethdev_ops.c | 10 --
drivers/net/octeontx2/otx2_vlan.c | 5 -
drivers/net/qede/qede_ethdev.c | 3 ---
lib/librte_ethdev/rte_ethdev.c | 21 +
10 files changed, 26 insertions(+), 76 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index 2f031ec..17a7a49 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -147,7 +147,7 @@ dpaa2_vlan_offload_set(struct rte_eth_dev *dev, int mask)
{
struct dpaa2_dev_priv *priv = dev->data->dev_private;
struct fsl_mc_io *dpni = dev->process_private;
- int ret;
+ int ret = 0;
PMD_INIT_FUNC_TRACE();
@@ -155,7 +155,7 @@ dpaa2_vlan_offload_set(struct rte_eth_dev *dev, int mask)
/* VLAN Filter not avaialble */
if (!priv->max_vlan_filters) {
DPAA2_PMD_INFO("VLAN filter not available");
- goto next_mask;
+ return -ENOTSUP;
}
if (dev->data->dev_conf.rxmode.offloads &
@@ -168,14 +168,8 @@ dpaa2_vlan_offload_set(struct rte_eth_dev *dev, int mask)
if (ret < 0)
DPAA2_PMD_INFO("Unable to set vlan filter = %d", ret);
}
-next_mask:
- if (mask & ETH_VLAN_EXTEND_MASK) {
- if (dev->data->dev_conf.rxmode.offloads &
- DEV_RX_OFFLOAD_VLAN_EXTEND)
- DPAA2_PMD_INFO("VLAN extend offload not supported");
- }
- return 0;
+ return ret;
}
static int
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 32d5397..ef8900d 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -374,18 +374,6 @@ static int enicpmd_vlan_offload_set(struct rte_eth_dev
*eth_dev, int mask)
enic->ig_vlan_strip_en = 0;
}
- if ((mask & ETH_VLAN_FILTER_MASK) &&
- (offloads & DEV_RX_OFFLOAD_VLAN_FILTER)) {
- dev_warning(enic,
- "Configuration of VLAN filter is not supported\n");
- }
-
- if ((mask & ETH_VLAN_EXTEND_MASK) &&
- (offloads & DEV_RX_OFFLOAD_VLAN_EXTEND)) {
- dev_warning(enic,
- "Configuration of extended VLAN is not supported\n");
- }
-
return enic_set_vlan_strip(enic);
}
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index f537ab2..f5b854e 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1575,28 +1575,9 @@ fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t
vlan_id, int on)
}
static int
-fm10k_vlan_offload_set(struct rte_eth_dev *dev, int mask)
+fm10k_vlan_offload_set(struct rte_eth_dev *dev __rte_unused,
+ int mask __rte_unused)
{
- if (mask & ETH_VLAN_STRIP_MASK) {
- if (!(dev->
Re: [dpdk-dev] [PATCH v3 3/4] net/ice: support switch flow for specific L4 type
> -Original Message-
> From: Zhao1, Wei
> Sent: Sunday, June 28, 2020 1:02 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Zhang, Qi Z ; Lu, Nannan
> ; Zhao1, Wei
> Subject: [PATCH v3 3/4] net/ice: support switch flow for specific L4 type
>
> This patch add more specific tunnel type for ipv4/ipv6 packet, it enable
> tcp/udp layer of ipv4/ipv6 as L4 payload but without
> L4 dst/src port number as input set for the switch filter rule.
>
> Fixes: 47d460d63233 ("net/ice: rework switch filter")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Zhao
> ---
> drivers/net/ice/ice_switch_filter.c | 27 ---
> 1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ice/ice_switch_filter.c
> b/drivers/net/ice/ice_switch_filter.c
> index c607e8d17..c1ea74c73 100644
> --- a/drivers/net/ice/ice_switch_filter.c
> +++ b/drivers/net/ice/ice_switch_filter.c
> @@ -29,6 +29,8 @@
> #define ICE_PPP_IPV4_PROTO 0x0021
> #define ICE_PPP_IPV6_PROTO 0x0057
> #define ICE_IPV4_PROTO_NVGRE 0x002F
> +#define ICE_TUN_VXLAN_VALID 0x0001
> +#define ICE_TUN_NVGRE_VALID 0x0002
Why not apply the same pattern with other valid flag?
I mean use vxlan_valid and nvgre_valid.
Could be tunnel_valid = vxlan_valid | nvgre_valid.
>
> #define ICE_SW_INSET_ETHER ( \
> ICE_INSET_DMAC | ICE_INSET_SMAC | ICE_INSET_ETHERTYPE) @@
> -471,11 +473,11 @@ ice_switch_inset_get(const struct rte_flow_item
> pattern[],
> const struct rte_flow_item_l2tpv3oip *l2tp_spec, *l2tp_mask;
> const struct rte_flow_item_pfcp *pfcp_spec, *pfcp_mask;
> uint64_t input_set = ICE_INSET_NONE;
> + uint16_t tunnel_valid = 0;
> bool pppoe_elem_valid = 0;
> bool pppoe_patt_valid = 0;
> bool pppoe_prot_valid = 0;
> bool profile_rule = 0;
> - bool tunnel_valid = 0;
> bool ipv6_valiad = 0;
> bool ipv4_valiad = 0;
> bool udp_valiad = 0;
> @@ -924,7 +926,7 @@ ice_switch_inset_get(const struct rte_flow_item
> pattern[],
> return 0;
> }
>
> - tunnel_valid = 1;
> + tunnel_valid = ICE_TUN_VXLAN_VALID;
> if (vxlan_spec && vxlan_mask) {
> list[t].type = ICE_VXLAN;
> if (vxlan_mask->vni[0] ||
> @@ -960,7 +962,7 @@ ice_switch_inset_get(const struct rte_flow_item
> pattern[],
> "Invalid NVGRE item");
> return 0;
> }
> - tunnel_valid = 1;
> + tunnel_valid = ICE_TUN_NVGRE_VALID;
> if (nvgre_spec && nvgre_mask) {
> list[t].type = ICE_NVGRE;
> if (nvgre_mask->tni[0] ||
> @@ -1325,6 +1327,21 @@ ice_switch_inset_get(const struct rte_flow_item
> pattern[],
> *tun_type = ICE_SW_TUN_PPPOE;
> }
>
> + if (*tun_type == ICE_NON_TUN) {
> + if (tunnel_valid == ICE_TUN_VXLAN_VALID)
> + *tun_type = ICE_SW_TUN_VXLAN;
> + else if (tunnel_valid == ICE_TUN_NVGRE_VALID)
> + *tun_type = ICE_SW_TUN_NVGRE;
> + else if (ipv4_valiad && tcp_valiad)
> + *tun_type = ICE_SW_IPV4_TCP;
> + else if (ipv4_valiad && udp_valiad)
> + *tun_type = ICE_SW_IPV4_UDP;
> + else if (ipv6_valiad && tcp_valiad)
> + *tun_type = ICE_SW_IPV6_TCP;
> + else if (ipv6_valiad && udp_valiad)
> + *tun_type = ICE_SW_IPV6_UDP;
> + }
> +
> *lkups_num = t;
>
> return input_set;
> @@ -1536,10 +1553,6 @@ ice_switch_parse_pattern_action(struct
> ice_adapter *ad,
>
> for (; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
> item_num++;
> - if (item->type == RTE_FLOW_ITEM_TYPE_VXLAN)
> - tun_type = ICE_SW_TUN_VXLAN;
> - if (item->type == RTE_FLOW_ITEM_TYPE_NVGRE)
> - tun_type = ICE_SW_TUN_NVGRE;
> if (item->type == RTE_FLOW_ITEM_TYPE_ETH) {
> const struct rte_flow_item_eth *eth_mask;
> if (item->mask)
> --
> 2.19.1
Re: [dpdk-dev] [PATCH v3 3/4] net/ice: support switch flow for specific L4 type
Hi,
> -Original Message-
> From: Zhang, Qi Z
> Sent: Monday, June 29, 2020 9:56 AM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: sta...@dpdk.org; Lu, Nannan
> Subject: RE: [PATCH v3 3/4] net/ice: support switch flow for specific L4 type
>
>
>
> > -Original Message-
> > From: Zhao1, Wei
> > Sent: Sunday, June 28, 2020 1:02 PM
> > To: dev@dpdk.org
> > Cc: sta...@dpdk.org; Zhang, Qi Z ; Lu, Nannan
> > ; Zhao1, Wei
> > Subject: [PATCH v3 3/4] net/ice: support switch flow for specific L4
> > type
> >
> > This patch add more specific tunnel type for ipv4/ipv6 packet, it
> > enable tcp/udp layer of ipv4/ipv6 as L4 payload but without
> > L4 dst/src port number as input set for the switch filter rule.
> >
> > Fixes: 47d460d63233 ("net/ice: rework switch filter")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Zhao
> > ---
> > drivers/net/ice/ice_switch_filter.c | 27 ---
> > 1 file changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/ice/ice_switch_filter.c
> > b/drivers/net/ice/ice_switch_filter.c
> > index c607e8d17..c1ea74c73 100644
> > --- a/drivers/net/ice/ice_switch_filter.c
> > +++ b/drivers/net/ice/ice_switch_filter.c
> > @@ -29,6 +29,8 @@
> > #define ICE_PPP_IPV4_PROTO 0x0021
> > #define ICE_PPP_IPV6_PROTO 0x0057
> > #define ICE_IPV4_PROTO_NVGRE 0x002F
> > +#define ICE_TUN_VXLAN_VALID0x0001
> > +#define ICE_TUN_NVGRE_VALID0x0002
>
> Why not apply the same pattern with other valid flag?
> I mean use vxlan_valid and nvgre_valid.
> Could be tunnel_valid = vxlan_valid | nvgre_valid.
Because we will extend to gtp-u or other kinds of packet, there will be more
and more xxx_valid variable.
I think we can follow rte layer to use bit define kinds of tunnel packet.
It is too complex to define too many valid flag.
>
> >
> > #define ICE_SW_INSET_ETHER ( \
> > ICE_INSET_DMAC | ICE_INSET_SMAC | ICE_INSET_ETHERTYPE) @@
> > -471,11 +473,11 @@ ice_switch_inset_get(const struct rte_flow_item
> > pattern[],
> > const struct rte_flow_item_l2tpv3oip *l2tp_spec, *l2tp_mask;
> > const struct rte_flow_item_pfcp *pfcp_spec, *pfcp_mask;
> > uint64_t input_set = ICE_INSET_NONE;
> > + uint16_t tunnel_valid = 0;
> > bool pppoe_elem_valid = 0;
> > bool pppoe_patt_valid = 0;
> > bool pppoe_prot_valid = 0;
> > bool profile_rule = 0;
> > - bool tunnel_valid = 0;
> > bool ipv6_valiad = 0;
> > bool ipv4_valiad = 0;
> > bool udp_valiad = 0;
> > @@ -924,7 +926,7 @@ ice_switch_inset_get(const struct rte_flow_item
> > pattern[],
> > return 0;
> > }
> >
> > - tunnel_valid = 1;
> > + tunnel_valid = ICE_TUN_VXLAN_VALID;
> > if (vxlan_spec && vxlan_mask) {
> > list[t].type = ICE_VXLAN;
> > if (vxlan_mask->vni[0] ||
> > @@ -960,7 +962,7 @@ ice_switch_inset_get(const struct rte_flow_item
> > pattern[],
> >"Invalid NVGRE item");
> > return 0;
> > }
> > - tunnel_valid = 1;
> > + tunnel_valid = ICE_TUN_NVGRE_VALID;
> > if (nvgre_spec && nvgre_mask) {
> > list[t].type = ICE_NVGRE;
> > if (nvgre_mask->tni[0] ||
> > @@ -1325,6 +1327,21 @@ ice_switch_inset_get(const struct rte_flow_item
> > pattern[],
> > *tun_type = ICE_SW_TUN_PPPOE;
> > }
> >
> > + if (*tun_type == ICE_NON_TUN) {
> > + if (tunnel_valid == ICE_TUN_VXLAN_VALID)
> > + *tun_type = ICE_SW_TUN_VXLAN;
> > + else if (tunnel_valid == ICE_TUN_NVGRE_VALID)
> > + *tun_type = ICE_SW_TUN_NVGRE;
> > + else if (ipv4_valiad && tcp_valiad)
> > + *tun_type = ICE_SW_IPV4_TCP;
> > + else if (ipv4_valiad && udp_valiad)
> > + *tun_type = ICE_SW_IPV4_UDP;
> > + else if (ipv6_valiad && tcp_valiad)
> > + *tun_type = ICE_SW_IPV6_TCP;
> > + else if (ipv6_valiad && udp_valiad)
> > + *tun_type = ICE_SW_IPV6_UDP;
> > + }
> > +
> > *lkups_num = t;
> >
> > return input_set;
> > @@ -1536,10 +1553,6 @@ ice_switch_parse_pattern_action(struct
> > ice_adapter *ad,
> >
> > for (; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
> > item_num++;
> > - if (item->type == RTE_FLOW_ITEM_TYPE_VXLAN)
> > - tun_type = ICE_SW_TUN_VXLAN;
> > - if (item->type == RTE_FLOW_ITEM_TYPE_NVGRE)
> > - tun_type = ICE_SW_TUN_NVGRE;
> > if (item->type == RTE_FLOW_ITEM_TYPE_ETH) {
> > const struct rte_flow_item_eth *eth_mask;
> > if (item->mask)
> > --
> > 2.19.1
>
Re: [dpdk-dev] [PATCH v5 00/12] enable DCF datapath configuration
Reviewed-by: Qiming Yang > -Original Message- > From: Xu, Ting > Sent: Tuesday, June 23, 2020 10:38 > To: dev@dpdk.org > Cc: Zhang, Qi Z ; Yang, Qiming > ; Wu, Jingjing ; Xing, Beilei > ; Kovacevic, Marko ; > Mcnamara, John ; Xu, Ting > Subject: [PATCH v5 00/12] enable DCF datapath configuration > > This patchset adds support to configure DCF datapath, including Rx/Tx > queues setup, start and stop, device configuration, RSS and flexible > descriptor RXDID initialization and MAC filter setup. > > Qi Zhang (11): > net/ice: init RSS and supported RXDID in DCF > net/ice: complete device info get in DCF > net/ice: complete dev configure in DCF > net/ice: complete queue setup in DCF > net/ice: add stop flag for device start / stop > net/ice: add Rx queue init in DCF > net/ice: init RSS during DCF start > net/ice: add queue config in DCF > net/ice: add queue start and stop for DCF > net/ice: enable stats for DCF > net/ice: set MAC filter during dev start for DCF > > Ting Xu (1): > doc: enable DCF datapath configuration > > --- > v4->v5: > Add driver's feature doc > > v3->v4: > Clean codes based on comments > > v2->v3: > Correct coding style issue > > v1->v2: > Optimize coding style > Correct some return values > Add support to stop started queues when queue start failed > > doc/guides/nics/features/ice_dcf.ini | 19 + > doc/guides/rel_notes/release_20_08.rst | 6 + > drivers/net/ice/ice_dcf.c | 408 - > drivers/net/ice/ice_dcf.h | 17 + > drivers/net/ice/ice_dcf_ethdev.c | 773 +++-- > drivers/net/ice/ice_dcf_ethdev.h | 3 - > drivers/net/ice/ice_dcf_parent.c | 8 + > 7 files changed, 1181 insertions(+), 53 deletions(-) create mode 100644 > doc/guides/nics/features/ice_dcf.ini > > -- > 2.17.1
Re: [dpdk-dev] [PATCH 4/8] net/ice/base: code clean in FDIR module
> -Original Message-
> From: Zhang, Qi Z
> Sent: Saturday, June 27, 2020 23:06
> To: Yang, Qiming
> Cc: dev@dpdk.org; Zhang, Qi Z ; Stillwell Jr, Paul M
>
> Subject: [PATCH 4/8] net/ice/base: code clean in FDIR module
>
> Remove unused macro and funciton.
funciton / Function
> Declare no external referenced function as static.
>
> Signed-off-by: Paul M Stillwell Jr
> Signed-off-by: Qi Zhang
> ---
> drivers/net/ice/base/ice_fdir.c | 23 +--
> drivers/net/ice/base/ice_fdir.h | 3 ---
> 2 files changed, 1 insertion(+), 25 deletions(-)
>
> diff --git a/drivers/net/ice/base/ice_fdir.c b/drivers/net/ice/base/ice_fdir.c
> index c5a20632c..b1dc2afb7 100644
> --- a/drivers/net/ice/base/ice_fdir.c
> +++ b/drivers/net/ice/base/ice_fdir.c
> @@ -597,7 +597,7 @@ static const struct ice_fdir_base_pkt ice_fdir_pkt[] = {
> * ice_set_dflt_val_fd_desc
> * @fd_fltr_ctx: pointer to fd filter descriptor
> */
> -void ice_set_dflt_val_fd_desc(struct ice_fd_fltr_desc_ctx *fd_fltr_ctx)
> +static void ice_set_dflt_val_fd_desc(struct ice_fd_fltr_desc_ctx
> +*fd_fltr_ctx)
> {
> fd_fltr_ctx->comp_q = ICE_FXD_FLTR_QW0_COMP_Q_ZERO;
> fd_fltr_ctx->comp_report =
> ICE_FXD_FLTR_QW0_COMP_REPORT_SW_FAIL;
> @@ -1389,27 +1389,6 @@ bool ice_fdir_is_dup_fltr(struct ice_hw *hw,
> struct ice_fdir_fltr *input) }
>
> /**
> - * ice_clear_vsi_fd_table - admin command to clear FD table for a VSI
> - * @hw: hardware data structure
> - * @vsi_num: vsi_num (HW VSI num)
> - *
> - * Clears FD table entries by issuing admin command (direct, 0x0B06)
> - * Must to pass valid vsi_num as returned by "AddVSI".
> - */
> -enum ice_status ice_clear_vsi_fd_table(struct ice_hw *hw, u16 vsi_num) -{
> - struct ice_aqc_clear_fd_table *cmd;
> - struct ice_aq_desc desc;
> -
> - cmd = &desc.params.clear_fd_table;
> - ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_clear_fd_table);
> - cmd->clear_type = CL_FD_VM_VF_TYPE_VSI_IDX;
> -
> - cmd->vsi_index = CPU_TO_LE16(vsi_num);
> - return ice_aq_send_cmd(hw, &desc, NULL, 0, NULL);
> -}
> -
> -/**
> * ice_clear_pf_fd_table - admin command to clear FD table for PF
> * @hw: hardware data structure
> *
> diff --git a/drivers/net/ice/base/ice_fdir.h b/drivers/net/ice/base/ice_fdir.h
> index 1f31debe6..ad3e11a5b 100644
> --- a/drivers/net/ice/base/ice_fdir.h
> +++ b/drivers/net/ice/base/ice_fdir.h
> @@ -17,7 +17,6 @@
> #define ICE_FDIR_TUN_PKT_OFF 50
> #define ICE_FDIR_MAX_RAW_PKT_SIZE(512 +
> ICE_FDIR_TUN_PKT_OFF)
> #define ICE_FDIR_BUF_FULL_MARGIN 10
> -#define ICE_FDIR_BUF_HEAD_ROOM 32
>
> /* macros for offsets into packets for flow director programming */
> #define ICE_IPV4_SRC_ADDR_OFFSET 26
> @@ -222,7 +221,6 @@ struct ice_fdir_base_pkt {
>
> enum ice_status ice_alloc_fd_res_cntr(struct ice_hw *hw, u16 *cntr_id);
> enum ice_status ice_free_fd_res_cntr(struct ice_hw *hw, u16 cntr_id); -void
> ice_set_dflt_val_fd_desc(struct ice_fd_fltr_desc_ctx *fd_fltr_ctx); enum
> ice_status ice_alloc_fd_guar_item(struct ice_hw *hw, u16 *cntr_id, u16
> num_fltr); enum ice_status @@ -231,7 +229,6 @@ enum ice_status
> ice_alloc_fd_shrd_item(struct ice_hw *hw, u16 *cntr_id, u16 num_fltr);
> enum ice_status ice_free_fd_shrd_item(struct ice_hw *hw, u16 cntr_id,
> u16 num_fltr); -enum ice_status ice_clear_vsi_fd_table(struct ice_hw *hw,
> u16 vsi_num); enum ice_status ice_clear_pf_fd_table(struct ice_hw *hw);
> void ice_fdir_get_prgm_desc(struct ice_hw *hw, struct ice_fdir_fltr *input,
> --
> 2.13.6
Re: [dpdk-dev] [PATCH] net/i40e: fix modifying the number of queues
Hi Jia,
> -Original Message-
> From: Guo, Jia
> Sent: Sunday, June 21, 2020 9:36 PM
> To: Zhang, AlvinX ; dev@dpdk.org
> Cc: sta...@dpdk.org; Xing, Beilei ; Jiang, MaoX
>
> Subject: Re: [PATCH] net/i40e: fix modifying the number of queues
>
> hi, alvin
>
> On 6/10/2020 8:07 PM, alvinx.zh...@intel.com wrote:
> > From: Alvin Zhang
> >
> > For the newly created VF, if the number of qps is greater than 4 at
> > startup, it may fail to start. This patch updates the API
> > `i40evf_dev_configure`.
>
>
> Could you explicit explain why it limit to 4 qps, and more detail about below
> code change with the purpose of the patch.
For each VF, the kernel PF driver assign 4 qps when the VF be created.
>
>
> > Fixes: c48eb308ed13 ("net/i40e: support VF request more queues")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Alvin Zhang
> > ---
> > drivers/net/i40e/i40e_ethdev_vf.c | 32 ---
> -
> > 1 file changed, 24 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> b/drivers/net/i40e/i40e_ethdev_vf.c
> > index bb5d28a..7500e0a 100644
> > --- a/drivers/net/i40e/i40e_ethdev_vf.c
> > +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> > @@ -1082,13 +1082,10 @@ static int i40evf_dev_xstats_get(struct
> rte_eth_dev *dev,
> > args.out_buffer = vf->aq_resp;
> > args.out_size = I40E_AQ_BUF_SZ;
> >
> > - rte_eal_alarm_cancel(i40evf_dev_alarm_handler, dev);
>
>
> Why interrupt handler is no need to cancel here and more why this change
> is related with this patch according with the commit log?
Here, the handler has been cancecled by the caller.
>
>
> > err = i40evf_execute_vf_cmd(dev, &args);
> > if (err)
> > PMD_DRV_LOG(ERR, "fail to execute command
> OP_REQUEST_QUEUES");
> >
> > - rte_eal_alarm_set(I40EVF_ALARM_INTERVAL,
> > - i40evf_dev_alarm_handler, dev);
> > return err;
> > }
> >
> > @@ -1516,7 +1513,7 @@ static int i40evf_dev_xstats_get(struct
> rte_eth_dev *dev,
> > hw->bus.device = pci_dev->addr.devid;
> > hw->bus.func = pci_dev->addr.function;
> > hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
> > - hw->adapter_stopped = 0;
> > + hw->adapter_stopped = 1;
>
>
> Why it should be set stopped when init dev?
The Device has not been started until the API ` i40evf_dev_start ` been called.
Here we just initiate the device, so it should be set to 1.
>
>
> > hw->adapter_closed = 0;
> >
> > /* Pass the information to the rte_eth_dev_close() that it should
> also
> > @@ -1612,16 +1609,35 @@ static int eth_i40evf_pci_remove(struct
> rte_pci_device *pci_dev)
> > ad->tx_vec_allowed = true;
> >
> > if (num_queue_pairs > vf->vsi_res->num_queue_pairs) {
> > - int ret = 0;
> > + struct i40e_hw *hw;
> > + int ret;
> >
> > + hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > PMD_DRV_LOG(INFO, "change queue pairs from %u to %u",
> > vf->vsi_res->num_queue_pairs,
> num_queue_pairs);
> > + if (hw->adapter_stopped == 0) {
> > + PMD_DRV_LOG(WARNING, "Device must be
> stopped first!");
> > + return -EINVAL;
> > + }
> > +
> > + rte_eal_alarm_cancel(i40evf_dev_alarm_handler, dev);
> > ret = i40evf_request_queues(dev, num_queue_pairs);
> > - if (ret != 0)
> > + if (ret)
> > return ret;
> >
> > - ret = i40evf_dev_reset(dev);
> > - if (ret != 0)
> > + /*
> > +* The device must be reinitiated after queue resources
> > +* changed
> > +*/
>
>
> Should you check below part is reinitialize process according to exist
> dev_close and dev_init.
Yes, it stops and reinitializes the device , but if call the dev_close to do,
some process is no needed and should report errors.
>
>
> > + i40e_shutdown_adminq(hw);
> > + i40evf_disable_irq0(hw);
> > + rte_free(vf->vf_res);
> > + vf->vf_res = NULL;
> > + rte_free(vf->aq_resp);
> > + vf->aq_resp = NULL;
> > +
> > + ret = i40evf_dev_init(dev);
> > + if (ret)
> > return ret;
> > }
> >
Re: [dpdk-dev] [PATCH v2 01/42] net/e1000/base: resolve flash presence for i210 devices
> -Original Message-
> From: dev On Behalf Of Guinan Sun
> Sent: Wednesday, June 24, 2020 15:53
> To: dev@dpdk.org
> Cc: Guo, Jia ; Lu, Wenzhuo ;
> Sun, GuinanX ; Neftin, Sasha
>
> Subject: [dpdk-dev] [PATCH v2 01/42] net/e1000/base: resolve flash
> presence for i210 devices
>
> There is a conflict with legacy i210.
> This patch is for compatibility with i211.
Confuse commit log and name.
This patch should be add support for i211 and should merge other support for
i211 in this patch.
>
> Signed-off-by: Sasha Neftin
> Signed-off-by: Guinan Sun
> ---
> drivers/net/e1000/base/e1000_nvm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/e1000/base/e1000_nvm.c
> b/drivers/net/e1000/base/e1000_nvm.c
> index 56e2db122..4d4a8e04b 100644
> --- a/drivers/net/e1000/base/e1000_nvm.c
> +++ b/drivers/net/e1000/base/e1000_nvm.c
> @@ -749,8 +749,9 @@ s32 e1000_read_pba_string_generic(struct e1000_hw
> *hw, u8 *pba_num,
>
> DEBUGFUNC("e1000_read_pba_string_generic");
>
> - if ((hw->mac.type >= e1000_i210) &&
> - !e1000_get_flash_presence_i210(hw)) {
> + if ((hw->mac.type == e1000_i210 ||
> + hw->mac.type == e1000_i211) &&
> + !e1000_get_flash_presence_i210(hw)) {
> DEBUGOUT("Flashless no PBA string\n");
> return -E1000_ERR_NVM_PBA_SECTION;
> }
> --
> 2.17.1
Re: [dpdk-dev] [PATCH v2 06/42] net/e1000/base: modify MAC initialization for i211
This one should merge to the first patch.
> -Original Message-
> From: dev On Behalf Of Guinan Sun
> Sent: Wednesday, June 24, 2020 15:53
> To: dev@dpdk.org
> Cc: Guo, Jia ; Lu, Wenzhuo ;
> Sun, GuinanX ; Fujinaka, Todd
>
> Subject: [dpdk-dev] [PATCH v2 06/42] net/e1000/base: modify MAC
> initialization for i211
>
> Introduce SF/FW syncronization, acquire and release for i211 devices.
>
> Signed-off-by: Todd Fujinaka
> Signed-off-by: Guinan Sun
> ---
> drivers/net/e1000/base/e1000_82575.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/e1000/base/e1000_82575.c
> b/drivers/net/e1000/base/e1000_82575.c
> index 4c3611c6d..952bb4235 100644
> --- a/drivers/net/e1000/base/e1000_82575.c
> +++ b/drivers/net/e1000/base/e1000_82575.c
> @@ -486,7 +486,7 @@ STATIC s32 e1000_init_mac_params_82575(struct
> e1000_hw *hw)
> /* acquire SW_FW sync */
> mac->ops.acquire_swfw_sync = e1000_acquire_swfw_sync_82575;
> mac->ops.release_swfw_sync = e1000_release_swfw_sync_82575;
> - if (mac->type >= e1000_i210) {
> + if (mac->type == e1000_i210 || mac->type == e1000_i211) {
> mac->ops.acquire_swfw_sync =
> e1000_acquire_swfw_sync_i210;
> mac->ops.release_swfw_sync =
> e1000_release_swfw_sync_i210;
> }
> --
> 2.17.1
Re: [dpdk-dev] [PATCH v5 3/4] devtools: prevent use of rte atomic APIs in future patches
> Subject: [PATCH v5 3/4] devtools: prevent use of rte atomic APIs in future
> patches
>
> In order to deprecate the rte_atomic APIs, prevent the patches from using
> rte_atomic APIs in the converted modules and compilers __sync built-ins in
> all modules.
>
> The converted modules:
> lib/librte_distributor
> lib/librte_hash
> lib/librte_kni
> lib/librte_lpm
> lib/librte_rcu
> lib/librte_ring
> lib/librte_stack
> lib/librte_vhost
> lib/librte_timer
> lib/librte_ipsec
> drivers/event/octeontx
> drivers/event/octeontx2
> drivers/event/opdl
> drivers/net/bnx2x
> drivers/net/hinic
> drivers/net/hns3
> drivers/net/memif
> drivers/net/thunderx
> drivers/net/virtio
> examples/l2fwd-event
>
> On x86 the __atomic_thread_fence(__ATOMIC_SEQ_CST) is quite expensive
> for SMP case. Flag the new code which use SEQ_CST memory ordering in
> __atomic_thread_fence API.
>
> Signed-off-by: Phil Yang
> Reviewed-by: Ruifeng Wang
> Reviewed-by: Honnappa Nagarahalli
> ---
> devtools/checkpatches.sh | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh index
> 158087f..5983f05 100755
> --- a/devtools/checkpatches.sh
> +++ b/devtools/checkpatches.sh
> @@ -69,6 +69,38 @@ check_forbidden_additions() { #
> -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> "$1" || res=1
>
> + # refrain from new additions of 16/32/64 bits rte_atomic_xxx()
> + # multiple folders and expressions are separated by spaces
> + awk -v FOLDERS="lib/librte_distributor lib/librte_hash lib/librte_kni
> + lib/librte_lpm lib/librte_rcu lib/librte_ring
> + lib/librte_stack lib/librte_vhost
> drivers/event/octeontx
> + drivers/event/octeontx2 drivers/event/opdl
> + drivers/net/bnx2x drivers/net/hinic drivers/net/hns3
> + drivers/net/memif drivers/net/thunderx
> + drivers/net/virtio examples/l2fwd-event" \
> + -v EXPRESSIONS="rte_atomic[0-9][0-9]_.*\\\(" \
> + -v RET_ON_FAIL=1 \
> + -v MESSAGE='Use of rte_atomicNN_xxx APIs not allowed, use
> __atomic_xxx APIs' \
> + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> + "$1" || res=1
> +
> + # refrain from using compiler __sync built-ins
> + awk -v FOLDERS="lib drivers app examples" \
> + -v EXPRESSIONS="__sync_.*\\\(" \
> + -v RET_ON_FAIL=1 \
> + -v MESSAGE='Use of __sync_xxx built-ins not allowed, use
> __atomic_xxx APIs' \
> + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> + "$1" || res=1
Can you please add rte_smp_*mb as well?
> +
> + # refrain from using compiler
> __atomic_thread_fence(__ATOMIC_SEQ_CST)
> + # It should be avoided on x86 for SMP case.
> + awk -v FOLDERS="lib drivers app examples" \
> + -v
> EXPRESSIONS="__atomic_thread_fence\\\(__ATOMIC_SEQ_CST" \
> + -v RET_ON_FAIL=1 \
> + -v MESSAGE='Use of __atomic_thread_fence with SEQ_CST
> ordering is not allowed, use rte_atomic_thread_fence' \
> + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> + "$1" || res=1
> +
> # svg figures must be included with wildcard extension
> # because of png conversion for pdf docs
> awk -v FOLDERS='doc' \
> --
> 2.7.4
Re: [dpdk-dev] [PATCH v5 4/4] eal/atomic: add wrapper for c11 atomic thread fence
> Subject: [PATCH v5 4/4] eal/atomic: add wrapper for c11 atomic thread fence
>
> Provide a wrapper for __atomic_thread_fence built-in to support optimized
> code for __ATOMIC_SEQ_CST memory order for x86 platforms.
>
> Suggested-by: Honnappa Nagarahalli
> Signed-off-by: Phil Yang
> Reviewed-by: Ola Liljedahl
> ---
> lib/librte_eal/arm/include/rte_atomic_32.h | 6 ++
> lib/librte_eal/arm/include/rte_atomic_64.h | 6 ++
> lib/librte_eal/include/generic/rte_atomic.h | 6 ++
> lib/librte_eal/ppc/include/rte_atomic.h | 6 ++
> lib/librte_eal/x86/include/rte_atomic.h | 17 +
> 5 files changed, 41 insertions(+)
>
> diff --git a/lib/librte_eal/arm/include/rte_atomic_32.h
> b/lib/librte_eal/arm/include/rte_atomic_32.h
> index 7dc0d06..dbe7cc6 100644
> --- a/lib/librte_eal/arm/include/rte_atomic_32.h
> +++ b/lib/librte_eal/arm/include/rte_atomic_32.h
> @@ -37,6 +37,12 @@ extern "C" {
>
> #define rte_cio_rmb() rte_rmb()
>
> +static __rte_always_inline void
> +rte_atomic_thread_fence(int mo)
> +{
> + __atomic_thread_fence(mo);
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_eal/arm/include/rte_atomic_64.h
> b/lib/librte_eal/arm/include/rte_atomic_64.h
> index 7b7099c..22ff8ec 100644
> --- a/lib/librte_eal/arm/include/rte_atomic_64.h
> +++ b/lib/librte_eal/arm/include/rte_atomic_64.h
> @@ -41,6 +41,12 @@ extern "C" {
>
> #define rte_cio_rmb() asm volatile("dmb oshld" : : : "memory")
>
> +static __rte_always_inline void
> +rte_atomic_thread_fence(int mo)
> +{
> + __atomic_thread_fence(mo);
> +}
> +
> /* 128 bit atomic operations
> -*/
>
> #if defined(__ARM_FEATURE_ATOMICS) ||
> defined(RTE_ARM_FEATURE_ATOMICS) diff --git
> a/lib/librte_eal/include/generic/rte_atomic.h
> b/lib/librte_eal/include/generic/rte_atomic.h
> index e6ab15a..5b941db 100644
> --- a/lib/librte_eal/include/generic/rte_atomic.h
> +++ b/lib/librte_eal/include/generic/rte_atomic.h
> @@ -158,6 +158,12 @@ static inline void rte_cio_rmb(void);
> asm volatile ("" : : : "memory"); \
> } while(0)
>
> +/**
> + * Synchronization fence between threads based on the specified
> + * memory order.
> + */
> +static inline void rte_atomic_thread_fence(int mo);
> +
> /*- 16 bit atomic operations
> -*/
>
> /**
> diff --git a/lib/librte_eal/ppc/include/rte_atomic.h
> b/lib/librte_eal/ppc/include/rte_atomic.h
> index 7e3e131..91c5f30 100644
> --- a/lib/librte_eal/ppc/include/rte_atomic.h
> +++ b/lib/librte_eal/ppc/include/rte_atomic.h
> @@ -40,6 +40,12 @@ extern "C" {
>
> #define rte_cio_rmb() rte_rmb()
>
> +static __rte_always_inline void
> +rte_atomic_thread_fence(int mo)
> +{
> + __atomic_thread_fence(mo);
> +}
> +
> /*- 16 bit atomic operations
> -*/
> /* To be compatible with Power7, use GCC built-in functions for 16 bit
> * operations */
> diff --git a/lib/librte_eal/x86/include/rte_atomic.h
> b/lib/librte_eal/x86/include/rte_atomic.h
> index b9dcd30..bd256e7 100644
> --- a/lib/librte_eal/x86/include/rte_atomic.h
> +++ b/lib/librte_eal/x86/include/rte_atomic.h
> @@ -83,6 +83,23 @@ rte_smp_mb(void)
>
> #define rte_cio_rmb() rte_compiler_barrier()
>
> +/**
> + * Synchronization fence between threads based on the specified
> + * memory order.
> + *
> + * On x86 the __atomic_thread_fence(__ATOMIC_SEQ_CST) generates
> + * full 'mfence' which is quite expensive. The optimized
> + * implementation of rte_smp_mb is used instead.
> + */
> +static __rte_always_inline void
> +rte_atomic_thread_fence(int mo)
> +{
> + if (mo == __ATOMIC_SEQ_CST)
> + rte_smp_mb();
> + else
> + __atomic_thread_fence(mo);
> +}
I think __ATOMIC_SEQ_CST needs to be used rarely. IMO, rte_atomic_thread_fence
should be called only for __ATOMIC_SEQ_CST memory order. For all others the
__atomic_thread_fence can be used directly. This will help us to stick to using
the atomic built-ins in most of the cases.
Konstantin, is this ok for you?
> +
> /*- 16 bit atomic operations
> -*/
>
> #ifndef RTE_FORCE_INTRINSICS
> --
> 2.7.4
Re: [dpdk-dev] [PATCH v2 3/3] examples/ipsec-secgw: Remove the re-implementation of inet_pton
Thank you Ananyev.
I will update it and send it after testing on freebsd.
On Mon, Jun 22, 2020 at 5:17 PM Ananyev, Konstantin <
konstantin.anan...@intel.com> wrote:
>
>
> >
> > inet_pton4 and inet_pton6 was reimplemented. Replace implementation of
> > inet_pton4 and inet_pton6 with libc inet_pton function
> >
> > Bugzilla ID: 365
> > Fixes: 0d547ed03717 ("examples/ipsec-secgw: support configuration file")
> > Cc: roy.fan.zh...@intel.com
> >
> > Reported-by: David Marchand
> > Signed-off-by: Ibtisam Tariq
>
> LGTM
> One thing to address - freebsd build is failing:
> http://mails.dpdk.org/archives/test-report/2020-June/134949.html
> Presumably extra include ( ?) is missing.
>
> > ---
> > v2:
> > * Fixed the name of variable, passed as input to inet_pton function.
> > * Add fixed id in commit body
> > ---
> > examples/ipsec-secgw/parser.c | 171 +-
> > 1 file changed, 3 insertions(+), 168 deletions(-)
> >
> > diff --git a/examples/ipsec-secgw/parser.c
> b/examples/ipsec-secgw/parser.c
> > index 65eb7e9e2..58ef3de0a 100644
> > --- a/examples/ipsec-secgw/parser.c
> > +++ b/examples/ipsec-secgw/parser.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "ipsec.h"
> > #include "parser.h"
> > @@ -39,172 +40,6 @@ parse_tokenize_string(char *string, char *tokens[],
> uint32_t *n_tokens)
> > return 0;
> > }
> >
> > -#define INADDRSZ 4
> > -#define IN6ADDRSZ 16
> > -
> > -/* int
> > - * inet_pton4(src, dst)
> > - * like inet_aton() but without all the hexadecimal and shorthand.
> > - * return:
> > - * 1 if `src' is a valid dotted quad, else 0.
> > - * notice:
> > - * does not touch `dst' unless it's returning 1.
> > - * author:
> > - * Paul Vixie, 1996.
> > - */
> > -static int
> > -inet_pton4(const char *src, unsigned char *dst)
> > -{
> > - static const char digits[] = "0123456789";
> > - int saw_digit, octets, ch;
> > - unsigned char tmp[INADDRSZ], *tp;
> > -
> > - saw_digit = 0;
> > - octets = 0;
> > - *(tp = tmp) = 0;
> > - while ((ch = *src++) != '\0') {
> > - const char *pch;
> > -
> > - pch = strchr(digits, ch);
> > - if (pch != NULL) {
> > - unsigned int new = *tp * 10 + (pch - digits);
> > -
> > - if (new > 255)
> > - return 0;
> > - if (!saw_digit) {
> > - if (++octets > 4)
> > - return 0;
> > - saw_digit = 1;
> > - }
> > - *tp = (unsigned char)new;
> > - } else if (ch == '.' && saw_digit) {
> > - if (octets == 4)
> > - return 0;
> > - *++tp = 0;
> > - saw_digit = 0;
> > - } else
> > - return 0;
> > - }
> > - if (octets < 4)
> > - return 0;
> > -
> > - memcpy(dst, tmp, INADDRSZ);
> > - return 1;
> > -}
> > -
> > -/* int
> > - * inet_pton6(src, dst)
> > - * convert presentation level address to network order binary form.
> > - * return:
> > - * 1 if `src' is a valid [RFC1884 2.2] address, else 0.
> > - * notice:
> > - * (1) does not touch `dst' unless it's returning 1.
> > - * (2) :: in a full address is silently ignored.
> > - * credit:
> > - * inspired by Mark Andrews.
> > - * author:
> > - * Paul Vixie, 1996.
> > - */
> > -static int
> > -inet_pton6(const char *src, unsigned char *dst)
> > -{
> > - static const char xdigits_l[] = "0123456789abcdef",
> > - xdigits_u[] = "0123456789ABCDEF";
> > - unsigned char tmp[IN6ADDRSZ], *tp = 0, *endp = 0, *colonp = 0;
> > - const char *xdigits = 0, *curtok = 0;
> > - int ch = 0, saw_xdigit = 0, count_xdigit = 0;
> > - unsigned int val = 0;
> > - unsigned dbloct_count = 0;
> > -
> > - memset((tp = tmp), '\0', IN6ADDRSZ);
> > - endp = tp + IN6ADDRSZ;
> > - colonp = NULL;
> > - /* Leading :: requires some special handling. */
> > - if (*src == ':')
> > - if (*++src != ':')
> > - return 0;
> > - curtok = src;
> > - saw_xdigit = count_xdigit = 0;
> > - val = 0;
> > -
> > - while ((ch = *src++) != '\0') {
> > - const char *pch;
> > -
> > - pch = strchr((xdigits = xdigits_l), ch);
> > - if (pch == NULL)
> > - pch = strchr((xdigits = xdigits_u), ch);
> > - if (pch != NULL) {
> > - if (count_xdigit >= 4)
> > - return 0;
> > - val <<= 4;
> > - val |= (pch - xdigits);
> > - if (val > 0x)
> > - return 0;
> > - saw_xdigit = 1;
> > - count_xdigit++;
> > -
[dpdk-dev] [PATCH v5 0/5] enable more PPPoE packet type for switch
1. add more support for switch parser of pppoe packet. 2. add check for NVGRE protocol 3. support flow for specific L4 type 4. add input set byte number check 5. fix typo This patchset is based on: [1] https://patches.dpdk.org/cover/70762/ : net/ice: base code update Depends-on: series-10300 v2: fix bug in patch add redirect support for VSI list rule. add information in release note. v3: add input set byte number check code update as comment of code style v4: fix typo in patch v5: add more valid flag Wei Zhao (5): net/ice: add support more PPPoE packet type for switch net/ice: fix tunnel type for switch rule net/ice: support switch flow for specific L4 type net/ice: add input set byte number check net/ice: fix typo doc/guides/rel_notes/release_20_08.rst | 1 + drivers/net/ice/ice_switch_filter.c| 241 - 2 files changed, 192 insertions(+), 50 deletions(-) -- 2.19.1
[dpdk-dev] [PATCH v5 3/5] net/ice: support switch flow for specific L4 type
This patch add more specific tunnel type for ipv4/ipv6 packet,
it enable tcp/udp layer of ipv4/ipv6 as L4 payload but without
L4 dst/src port number as input set for the switch filter rule.
Fixes: 47d460d63233 ("net/ice: rework switch filter")
Cc: sta...@dpdk.org
Signed-off-by: Wei Zhao
---
drivers/net/ice/ice_switch_filter.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ice/ice_switch_filter.c
b/drivers/net/ice/ice_switch_filter.c
index c607e8d17..7d1cd98f5 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -474,8 +474,10 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
bool pppoe_elem_valid = 0;
bool pppoe_patt_valid = 0;
bool pppoe_prot_valid = 0;
- bool profile_rule = 0;
bool tunnel_valid = 0;
+ bool profile_rule = 0;
+ bool nvgre_valid = 0;
+ bool vxlan_valid = 0;
bool ipv6_valiad = 0;
bool ipv4_valiad = 0;
bool udp_valiad = 0;
@@ -923,7 +925,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
"Invalid VXLAN item");
return 0;
}
-
+ vxlan_valid = 1;
tunnel_valid = 1;
if (vxlan_spec && vxlan_mask) {
list[t].type = ICE_VXLAN;
@@ -960,6 +962,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
"Invalid NVGRE item");
return 0;
}
+ nvgre_valid = 1;
tunnel_valid = 1;
if (nvgre_spec && nvgre_mask) {
list[t].type = ICE_NVGRE;
@@ -1325,6 +1328,21 @@ ice_switch_inset_get(const struct rte_flow_item
pattern[],
*tun_type = ICE_SW_TUN_PPPOE;
}
+ if (*tun_type == ICE_NON_TUN) {
+ if (vxlan_valid)
+ *tun_type = ICE_SW_TUN_VXLAN;
+ else if (nvgre_valid)
+ *tun_type = ICE_SW_TUN_NVGRE;
+ else if (ipv4_valiad && tcp_valiad)
+ *tun_type = ICE_SW_IPV4_TCP;
+ else if (ipv4_valiad && udp_valiad)
+ *tun_type = ICE_SW_IPV4_UDP;
+ else if (ipv6_valiad && tcp_valiad)
+ *tun_type = ICE_SW_IPV6_TCP;
+ else if (ipv6_valiad && udp_valiad)
+ *tun_type = ICE_SW_IPV6_UDP;
+ }
+
*lkups_num = t;
return input_set;
@@ -1536,10 +1554,6 @@ ice_switch_parse_pattern_action(struct ice_adapter *ad,
for (; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
item_num++;
- if (item->type == RTE_FLOW_ITEM_TYPE_VXLAN)
- tun_type = ICE_SW_TUN_VXLAN;
- if (item->type == RTE_FLOW_ITEM_TYPE_NVGRE)
- tun_type = ICE_SW_TUN_NVGRE;
if (item->type == RTE_FLOW_ITEM_TYPE_ETH) {
const struct rte_flow_item_eth *eth_mask;
if (item->mask)
--
2.19.1
[dpdk-dev] [PATCH v5 1/5] net/ice: add support more PPPoE packet type for switch
This patch add more support for switch parser of pppoe packet,
it enable parse tcp/udp L4 layer and ipv4/ipv6 L3 layer parser for
pppoe payload, so we can use L4 dst/src port and L3 ip address as
input set for switch filter pppoe related rule.
Signed-off-by: Wei Zhao
---
doc/guides/rel_notes/release_20_08.rst | 1 +
drivers/net/ice/ice_switch_filter.c| 115 +
2 files changed, 101 insertions(+), 15 deletions(-)
diff --git a/doc/guides/rel_notes/release_20_08.rst
b/doc/guides/rel_notes/release_20_08.rst
index 3c40424cc..90b58a027 100644
--- a/doc/guides/rel_notes/release_20_08.rst
+++ b/doc/guides/rel_notes/release_20_08.rst
@@ -86,6 +86,7 @@ New Features
Updated the Intel ice driver with new features and improvements, including:
* Added support for DCF datapath configuration.
+ * Added support for more PPPoE packet type for switch filter.
Removed Items
-
diff --git a/drivers/net/ice/ice_switch_filter.c
b/drivers/net/ice/ice_switch_filter.c
index 5ccd020c5..3c0c36bce 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -26,6 +26,8 @@
#define MAX_QGRP_NUM_TYPE 7
+#define ICE_PPP_IPV4_PROTO 0x0021
+#define ICE_PPP_IPV6_PROTO 0x0057
#define ICE_SW_INSET_ETHER ( \
ICE_INSET_DMAC | ICE_INSET_SMAC | ICE_INSET_ETHERTYPE)
@@ -95,6 +97,18 @@
ICE_INSET_VLAN_OUTER | ICE_INSET_VLAN_INNER | \
ICE_INSET_DMAC | ICE_INSET_ETHERTYPE | ICE_INSET_PPPOE_SESSION | \
ICE_INSET_PPPOE_PROTO)
+#define ICE_SW_INSET_MAC_PPPOE_IPV4 ( \
+ ICE_SW_INSET_MAC_PPPOE | ICE_SW_INSET_MAC_IPV4)
+#define ICE_SW_INSET_MAC_PPPOE_IPV4_TCP ( \
+ ICE_SW_INSET_MAC_PPPOE | ICE_SW_INSET_MAC_IPV4_TCP)
+#define ICE_SW_INSET_MAC_PPPOE_IPV4_UDP ( \
+ ICE_SW_INSET_MAC_PPPOE | ICE_SW_INSET_MAC_IPV4_UDP)
+#define ICE_SW_INSET_MAC_PPPOE_IPV6 ( \
+ ICE_SW_INSET_MAC_PPPOE | ICE_SW_INSET_MAC_IPV6)
+#define ICE_SW_INSET_MAC_PPPOE_IPV6_TCP ( \
+ ICE_SW_INSET_MAC_PPPOE | ICE_SW_INSET_MAC_IPV6_TCP)
+#define ICE_SW_INSET_MAC_PPPOE_IPV6_UDP ( \
+ ICE_SW_INSET_MAC_PPPOE | ICE_SW_INSET_MAC_IPV6_UDP)
#define ICE_SW_INSET_MAC_IPV4_ESP ( \
ICE_SW_INSET_MAC_IPV4 | ICE_INSET_ESP_SPI)
#define ICE_SW_INSET_MAC_IPV6_ESP ( \
@@ -154,10 +168,6 @@ ice_pattern_match_item ice_switch_pattern_dist_comms[] = {
ICE_SW_INSET_DIST_NVGRE_IPV4_UDP, ICE_INSET_NONE},
{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,
ICE_SW_INSET_DIST_NVGRE_IPV4_TCP, ICE_INSET_NONE},
- {pattern_eth_pppoed,
- ICE_SW_INSET_MAC_PPPOE, ICE_INSET_NONE},
- {pattern_eth_vlan_pppoed,
- ICE_SW_INSET_MAC_PPPOE, ICE_INSET_NONE},
{pattern_eth_pppoes,
ICE_SW_INSET_MAC_PPPOE, ICE_INSET_NONE},
{pattern_eth_vlan_pppoes,
@@ -166,6 +176,30 @@ ice_pattern_match_item ice_switch_pattern_dist_comms[] = {
ICE_SW_INSET_MAC_PPPOE_PROTO, ICE_INSET_NONE},
{pattern_eth_vlan_pppoes_proto,
ICE_SW_INSET_MAC_PPPOE_PROTO, ICE_INSET_NONE},
+ {pattern_eth_pppoes_ipv4,
+ ICE_SW_INSET_MAC_PPPOE_IPV4, ICE_INSET_NONE},
+ {pattern_eth_pppoes_ipv4_tcp,
+ ICE_SW_INSET_MAC_PPPOE_IPV4_TCP, ICE_INSET_NONE},
+ {pattern_eth_pppoes_ipv4_udp,
+ ICE_SW_INSET_MAC_PPPOE_IPV4_UDP, ICE_INSET_NONE},
+ {pattern_eth_pppoes_ipv6,
+ ICE_SW_INSET_MAC_PPPOE_IPV6, ICE_INSET_NONE},
+ {pattern_eth_pppoes_ipv6_tcp,
+ ICE_SW_INSET_MAC_PPPOE_IPV6_TCP, ICE_INSET_NONE},
+ {pattern_eth_pppoes_ipv6_udp,
+ ICE_SW_INSET_MAC_PPPOE_IPV6_UDP, ICE_INSET_NONE},
+ {pattern_eth_vlan_pppoes_ipv4,
+ ICE_SW_INSET_MAC_PPPOE_IPV4, ICE_INSET_NONE},
+ {pattern_eth_vlan_pppoes_ipv4_tcp,
+ ICE_SW_INSET_MAC_PPPOE_IPV4_TCP, ICE_INSET_NONE},
+ {pattern_eth_vlan_pppoes_ipv4_udp,
+ ICE_SW_INSET_MAC_PPPOE_IPV4_UDP, ICE_INSET_NONE},
+ {pattern_eth_vlan_pppoes_ipv6,
+ ICE_SW_INSET_MAC_PPPOE_IPV6, ICE_INSET_NONE},
+ {pattern_eth_vlan_pppoes_ipv6_tcp,
+ ICE_SW_INSET_MAC_PPPOE_IPV6_TCP, ICE_INSET_NONE},
+ {pattern_eth_vlan_pppoes_ipv6_udp,
+ ICE_SW_INSET_MAC_PPPOE_IPV6_UDP, ICE_INSET_NONE},
{pattern_eth_ipv4_esp,
ICE_SW_INSET_MAC_IPV4_ESP, ICE_INSET_NONE},
{pattern_eth_ipv4_udp_esp,
@@ -254,10 +288,6 @@ ice_pattern_match_item ice_switch_pattern_perm[] = {
ICE_SW_INSET_PERM_TUNNEL_IPV4_UDP, ICE_INSET_NONE},
{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,
ICE_SW_INSET_PERM_TUNNEL_IPV4_TCP, ICE_INSET_NONE},
- {pattern_eth_pppoed,
- ICE_SW_INSET_MAC_PPPOE, ICE_INSET_NONE},
- {pattern
[dpdk-dev] [PATCH v5 2/5] net/ice: fix tunnel type for switch rule
This patch add check for protocol type of IPv4 packet,
it need to update tunnel type when NVGRE is in payload.
Fixes: 6bc7628c5e0b ("net/ice: change default tunnel type")
Cc: sta...@dpdk.org
Signed-off-by: Wei Zhao
---
drivers/net/ice/ice_switch_filter.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ice/ice_switch_filter.c
b/drivers/net/ice/ice_switch_filter.c
index 3c0c36bce..c607e8d17 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -28,6 +28,7 @@
#define MAX_QGRP_NUM_TYPE 7
#define ICE_PPP_IPV4_PROTO 0x0021
#define ICE_PPP_IPV6_PROTO 0x0057
+#define ICE_IPV4_PROTO_NVGRE 0x002F
#define ICE_SW_INSET_ETHER ( \
ICE_INSET_DMAC | ICE_INSET_SMAC | ICE_INSET_ETHERTYPE)
@@ -632,6 +633,10 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
list[t].m_u.ipv4_hdr.protocol =
ipv4_mask->hdr.next_proto_id;
}
+ if ((ipv4_spec->hdr.next_proto_id &
+ ipv4_mask->hdr.next_proto_id) ==
+ ICE_IPV4_PROTO_NVGRE)
+ *tun_type = ICE_SW_TUN_AND_NON_TUN;
if (ipv4_mask->hdr.type_of_service) {
list[t].h_u.ipv4_hdr.tos =
ipv4_spec->hdr.type_of_service;
@@ -1526,7 +1531,7 @@ ice_switch_parse_pattern_action(struct ice_adapter *ad,
const struct rte_flow_item *item = pattern;
uint16_t item_num = 0;
enum ice_sw_tunnel_type tun_type =
- ICE_SW_TUN_AND_NON_TUN;
+ ICE_NON_TUN;
struct ice_pattern_match_item *pattern_match_item = NULL;
for (; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
--
2.19.1
[dpdk-dev] [PATCH v5 5/5] net/ice: fix typo
fix typo of "valid".
Fixes: 8f5d8e74fb38 ("net/ice: support flow for AH ESP and L2TP")
Fixes: 66ff8851792f ("net/ice: support ESP/AH/L2TP")
Fixes: 45b53ed3701d ("net/ice: support IPv6 NAT-T")
Cc: sta...@dpdk.org
Signed-off-by: Wei Zhao
---
drivers/net/ice/ice_switch_filter.c | 76 ++---
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ice/ice_switch_filter.c
b/drivers/net/ice/ice_switch_filter.c
index 5054555c2..267af5a54 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -480,10 +480,10 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
bool profile_rule = 0;
bool nvgre_valid = 0;
bool vxlan_valid = 0;
- bool ipv6_valiad = 0;
- bool ipv4_valiad = 0;
- bool udp_valiad = 0;
- bool tcp_valiad = 0;
+ bool ipv6_valid = 0;
+ bool ipv4_valid = 0;
+ bool udp_valid = 0;
+ bool tcp_valid = 0;
uint16_t j, t = 0;
for (item = pattern; item->type !=
@@ -570,7 +570,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
case RTE_FLOW_ITEM_TYPE_IPV4:
ipv4_spec = item->spec;
ipv4_mask = item->mask;
- ipv4_valiad = 1;
+ ipv4_valid = 1;
if (ipv4_spec && ipv4_mask) {
/* Check IPv4 mask and update input set */
if (ipv4_mask->hdr.version_ihl ||
@@ -662,7 +662,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
case RTE_FLOW_ITEM_TYPE_IPV6:
ipv6_spec = item->spec;
ipv6_mask = item->mask;
- ipv6_valiad = 1;
+ ipv6_valid = 1;
if (ipv6_spec && ipv6_mask) {
if (ipv6_mask->hdr.payload_len) {
rte_flow_error_set(error, EINVAL,
@@ -780,7 +780,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
case RTE_FLOW_ITEM_TYPE_UDP:
udp_spec = item->spec;
udp_mask = item->mask;
- udp_valiad = 1;
+ udp_valid = 1;
if (udp_spec && udp_mask) {
/* Check UDP mask and update input set*/
if (udp_mask->hdr.dgram_len ||
@@ -833,7 +833,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
case RTE_FLOW_ITEM_TYPE_TCP:
tcp_spec = item->spec;
tcp_mask = item->mask;
- tcp_valiad = 1;
+ tcp_valid = 1;
if (tcp_spec && tcp_mask) {
/* Check TCP mask and update input set */
if (tcp_mask->hdr.sent_seq ||
@@ -1151,16 +1151,16 @@ ice_switch_inset_get(const struct rte_flow_item
pattern[],
if (!esp_spec && !esp_mask && !input_set) {
profile_rule = 1;
- if (ipv6_valiad && udp_valiad)
+ if (ipv6_valid && udp_valid)
*tun_type =
ICE_SW_TUN_PROFID_IPV6_NAT_T;
- else if (ipv6_valiad)
+ else if (ipv6_valid)
*tun_type = ICE_SW_TUN_PROFID_IPV6_ESP;
- else if (ipv4_valiad)
+ else if (ipv4_valid)
return 0;
} else if (esp_spec && esp_mask &&
esp_mask->hdr.spi){
- if (udp_valiad)
+ if (udp_valid)
list[t].type = ICE_NAT_T;
else
list[t].type = ICE_ESP;
@@ -1174,13 +1174,13 @@ ice_switch_inset_get(const struct rte_flow_item
pattern[],
}
if (!profile_rule) {
- if (ipv6_valiad && udp_valiad)
+ if (ipv6_valid && udp_valid)
*tun_type = ICE_SW_TUN_IPV6_NAT_T;
- else if (ipv4_valiad && udp_valiad)
+ else if (ipv4_valid && udp_valid)
*tun_type = ICE_SW_TUN_IPV4_NAT_T;
- else if (ipv6_valiad)
+ else if (ipv6_valid)
*tun_type = ICE_SW_TUN_IPV6_ESP;
- else if (ipv4_valiad)
+
[dpdk-dev] [PATCH v5 4/5] net/ice: add input set byte number check
This patch add the total input set byte number check,
as there is a hardware requirement for the total number
of 32 byte.
Fixes: 47d460d63233 ("net/ice: rework switch filter")
Cc: sta...@dpdk.org
Signed-off-by: Wei Zhao
---
drivers/net/ice/ice_switch_filter.c | 43 +++--
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ice/ice_switch_filter.c
b/drivers/net/ice/ice_switch_filter.c
index 7d1cd98f5..5054555c2 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -25,7 +25,8 @@
#include "ice_generic_flow.h"
-#define MAX_QGRP_NUM_TYPE 7
+#define MAX_QGRP_NUM_TYPE 7
+#define MAX_INPUT_SET_BYTE 32
#define ICE_PPP_IPV4_PROTO 0x0021
#define ICE_PPP_IPV6_PROTO 0x0057
#define ICE_IPV4_PROTO_NVGRE 0x002F
@@ -471,6 +472,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
const struct rte_flow_item_l2tpv3oip *l2tp_spec, *l2tp_mask;
const struct rte_flow_item_pfcp *pfcp_spec, *pfcp_mask;
uint64_t input_set = ICE_INSET_NONE;
+ uint16_t input_set_byte = 0;
bool pppoe_elem_valid = 0;
bool pppoe_patt_valid = 0;
bool pppoe_prot_valid = 0;
@@ -540,6 +542,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
m->src_addr[j] =
eth_mask->src.addr_bytes[j];
i = 1;
+ input_set_byte++;
}
if (eth_mask->dst.addr_bytes[j]) {
h->dst_addr[j] =
@@ -547,6 +550,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
m->dst_addr[j] =
eth_mask->dst.addr_bytes[j];
i = 1;
+ input_set_byte++;
}
}
if (i)
@@ -557,6 +561,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
eth_spec->type;
list[t].m_u.ethertype.ethtype_id =
eth_mask->type;
+ input_set_byte += 2;
t++;
}
}
@@ -616,24 +621,28 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
ipv4_spec->hdr.src_addr;
list[t].m_u.ipv4_hdr.src_addr =
ipv4_mask->hdr.src_addr;
+ input_set_byte += 2;
}
if (ipv4_mask->hdr.dst_addr) {
list[t].h_u.ipv4_hdr.dst_addr =
ipv4_spec->hdr.dst_addr;
list[t].m_u.ipv4_hdr.dst_addr =
ipv4_mask->hdr.dst_addr;
+ input_set_byte += 2;
}
if (ipv4_mask->hdr.time_to_live) {
list[t].h_u.ipv4_hdr.time_to_live =
ipv4_spec->hdr.time_to_live;
list[t].m_u.ipv4_hdr.time_to_live =
ipv4_mask->hdr.time_to_live;
+ input_set_byte++;
}
if (ipv4_mask->hdr.next_proto_id) {
list[t].h_u.ipv4_hdr.protocol =
ipv4_spec->hdr.next_proto_id;
list[t].m_u.ipv4_hdr.protocol =
ipv4_mask->hdr.next_proto_id;
+ input_set_byte++;
}
if ((ipv4_spec->hdr.next_proto_id &
ipv4_mask->hdr.next_proto_id) ==
@@ -644,6 +653,7 @@ ice_switch_inset_get(const struct rte_flow_item pattern[],
ipv4_spec->hdr.type_of_service;
list[t].m_u.ipv4_hdr.tos =
ipv4_mask->hdr.type_of_service;
+ input_set_byte++;
}
t++;
Re: [dpdk-dev] [PATCH v5 00/12] enable DCF datapath configuration
> -Original Message- > From: Yang, Qiming > Sent: Monday, June 29, 2020 10:44 AM > To: Xu, Ting ; dev@dpdk.org > Cc: Zhang, Qi Z ; Wu, Jingjing ; > Xing, Beilei ; Kovacevic, Marko > ; Mcnamara, John > Subject: RE: [PATCH v5 00/12] enable DCF datapath configuration > > Reviewed-by: Qiming Yang Applied to dpdk-next-net-intel. Thanks Qi > > > -Original Message- > > From: Xu, Ting > > Sent: Tuesday, June 23, 2020 10:38 > > To: dev@dpdk.org > > Cc: Zhang, Qi Z ; Yang, Qiming > > ; Wu, Jingjing ; Xing, > > Beilei ; Kovacevic, Marko > > ; Mcnamara, John > ; > > Xu, Ting > > Subject: [PATCH v5 00/12] enable DCF datapath configuration > > > > This patchset adds support to configure DCF datapath, including Rx/Tx > > queues setup, start and stop, device configuration, RSS and flexible > > descriptor RXDID initialization and MAC filter setup. > > > > Qi Zhang (11): > > net/ice: init RSS and supported RXDID in DCF > > net/ice: complete device info get in DCF > > net/ice: complete dev configure in DCF > > net/ice: complete queue setup in DCF > > net/ice: add stop flag for device start / stop > > net/ice: add Rx queue init in DCF > > net/ice: init RSS during DCF start > > net/ice: add queue config in DCF > > net/ice: add queue start and stop for DCF > > net/ice: enable stats for DCF > > net/ice: set MAC filter during dev start for DCF > > > > Ting Xu (1): > > doc: enable DCF datapath configuration > > > > --- > > v4->v5: > > Add driver's feature doc > > > > v3->v4: > > Clean codes based on comments > > > > v2->v3: > > Correct coding style issue > > > > v1->v2: > > Optimize coding style > > Correct some return values > > Add support to stop started queues when queue start failed > > > > doc/guides/nics/features/ice_dcf.ini | 19 + > > doc/guides/rel_notes/release_20_08.rst | 6 + > > drivers/net/ice/ice_dcf.c | 408 - > > drivers/net/ice/ice_dcf.h | 17 + > > drivers/net/ice/ice_dcf_ethdev.c | 773 +++-- > > drivers/net/ice/ice_dcf_ethdev.h | 3 - > > drivers/net/ice/ice_dcf_parent.c | 8 + > > 7 files changed, 1181 insertions(+), 53 deletions(-) create mode > > 100644 doc/guides/nics/features/ice_dcf.ini > > > > -- > > 2.17.1 >
Re: [dpdk-dev] [PATCH v5 3/4] devtools: prevent use of rte atomic APIs in future patches
> -Original Message-
> From: Honnappa Nagarahalli
> Sent: Monday, June 29, 2020 12:38 PM
> To: Phil Yang ; dev@dpdk.org
> Cc: mattias.ronnb...@ericsson.com; m...@smartsharesystems.com;
> step...@networkplumber.org; tho...@monjalon.net;
> bruce.richard...@intel.com; ferruh.yi...@intel.com;
> hemant.agra...@nxp.com; jer...@marvell.com; ktray...@redhat.com;
> konstantin.anan...@intel.com; maxime.coque...@redhat.com;
> olivier.m...@6wind.com; harry.van.haa...@intel.com;
> erik.g.carri...@intel.com; d...@linux.vnet.ibm.com;
> david.march...@redhat.com; zhaoyan.c...@intel.com; Ola Liljedahl
> ; Ruifeng Wang ; Phil
> Yang ; nd ; Honnappa Nagarahalli
> ; nd
> Subject: RE: [PATCH v5 3/4] devtools: prevent use of rte atomic APIs in future
> patches
>
>
>
> > Subject: [PATCH v5 3/4] devtools: prevent use of rte atomic APIs in future
> > patches
> >
> > In order to deprecate the rte_atomic APIs, prevent the patches from using
> > rte_atomic APIs in the converted modules and compilers __sync built-ins in
> > all modules.
> >
> > The converted modules:
> > lib/librte_distributor
> > lib/librte_hash
> > lib/librte_kni
> > lib/librte_lpm
> > lib/librte_rcu
> > lib/librte_ring
> > lib/librte_stack
> > lib/librte_vhost
> > lib/librte_timer
> > lib/librte_ipsec
> > drivers/event/octeontx
> > drivers/event/octeontx2
> > drivers/event/opdl
> > drivers/net/bnx2x
> > drivers/net/hinic
> > drivers/net/hns3
> > drivers/net/memif
> > drivers/net/thunderx
> > drivers/net/virtio
> > examples/l2fwd-event
> >
> > On x86 the __atomic_thread_fence(__ATOMIC_SEQ_CST) is quite
> expensive
> > for SMP case. Flag the new code which use SEQ_CST memory ordering in
> > __atomic_thread_fence API.
> >
> > Signed-off-by: Phil Yang
> > Reviewed-by: Ruifeng Wang
> > Reviewed-by: Honnappa Nagarahalli
> > ---
> > devtools/checkpatches.sh | 32
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh index
> > 158087f..5983f05 100755
> > --- a/devtools/checkpatches.sh
> > +++ b/devtools/checkpatches.sh
> > @@ -69,6 +69,38 @@ check_forbidden_additions() { #
> > -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> > "$1" || res=1
> >
> > + # refrain from new additions of 16/32/64 bits rte_atomic_xxx()
> > + # multiple folders and expressions are separated by spaces
> > + awk -v FOLDERS="lib/librte_distributor lib/librte_hash lib/librte_kni
> > + lib/librte_lpm lib/librte_rcu lib/librte_ring
> > + lib/librte_stack lib/librte_vhost
> > drivers/event/octeontx
> > + drivers/event/octeontx2 drivers/event/opdl
> > + drivers/net/bnx2x drivers/net/hinic drivers/net/hns3
> > + drivers/net/memif drivers/net/thunderx
> > + drivers/net/virtio examples/l2fwd-event" \
> > + -v EXPRESSIONS="rte_atomic[0-9][0-9]_.*\\\(" \
> > + -v RET_ON_FAIL=1 \
> > + -v MESSAGE='Use of rte_atomicNN_xxx APIs not allowed,
> use
> > __atomic_xxx APIs' \
> > + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> > + "$1" || res=1
> > +
> > + # refrain from using compiler __sync built-ins
> > + awk -v FOLDERS="lib drivers app examples" \
> > + -v EXPRESSIONS="__sync_.*\\\(" \
> > + -v RET_ON_FAIL=1 \
> > + -v MESSAGE='Use of __sync_xxx built-ins not allowed, use
> > __atomic_xxx APIs' \
> > + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> > + "$1" || res=1
> Can you please add rte_smp_*mb as well?
Sure. Will do.
Thanks,
Phil
>
> > +
> > + # refrain from using compiler
> > __atomic_thread_fence(__ATOMIC_SEQ_CST)
> > + # It should be avoided on x86 for SMP case.
> > + awk -v FOLDERS="lib drivers app examples" \
> > + -v
> > EXPRESSIONS="__atomic_thread_fence\\\(__ATOMIC_SEQ_CST" \
> > + -v RET_ON_FAIL=1 \
> > + -v MESSAGE='Use of __atomic_thread_fence with SEQ_CST
> > ordering is not allowed, use rte_atomic_thread_fence' \
> > + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> > + "$1" || res=1
> > +
> > # svg figures must be included with wildcard extension
> > # because of png conversion for pdf docs
> > awk -v FOLDERS='doc' \
> > --
> > 2.7.4
Re: [dpdk-dev] [PATCH v2] net/ice: support original VF action for DCF
> -Original Message-
> From: Xu, Ting
> Sent: Thursday, June 11, 2020 18:15
> To: dev@dpdk.org
> Cc: Yang, Qiming ; Zhang, Qi Z
> ; Ye, Xiaolong
> Subject: [PATCH v2] net/ice: support original VF action for DCF
>
> From: Qi Zhang
>
> Add support to allow the original VF actions in DCF.
>
> Signed-off-by: Qi Zhang
> Signed-off-by: Ting Xu
>
> ---
> v1->v2: correct commit log.
> ---
> drivers/net/ice/ice_switch_filter.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ice/ice_switch_filter.c
> b/drivers/net/ice/ice_switch_filter.c
> index 20e8187d3..33327e905 100644
> --- a/drivers/net/ice/ice_switch_filter.c
> +++ b/drivers/net/ice/ice_switch_filter.c
> @@ -23,6 +23,7 @@
> #include "ice_logs.h"
> #include "ice_ethdev.h"
> #include "ice_generic_flow.h"
> +#include "ice_dcf_ethdev.h"
>
>
> #define MAX_QGRP_NUM_TYPE 7
> @@ -1240,7 +1241,8 @@ ice_switch_inset_get(const struct rte_flow_item
> pattern[], }
>
> static int
> -ice_switch_parse_dcf_action(const struct rte_flow_action *actions,
> +ice_switch_parse_dcf_action(struct ice_dcf_adapter *ad,
> + const struct rte_flow_action *actions,
> struct rte_flow_error *error,
> struct ice_adv_rule_info *rule_info) { @@ -1255,7
> +1257,11 @@ ice_switch_parse_dcf_action(const struct rte_flow_action
> *actions,
> case RTE_FLOW_ACTION_TYPE_VF:
> rule_info->sw_act.fltr_act = ICE_FWD_TO_VSI;
> act_vf = action->conf;
> - rule_info->sw_act.vsi_handle = act_vf->id;
> + if (act_vf->original)
> + rule_info->sw_act.vsi_handle =
> + ad->real_hw.avf.bus.func;
> + else
> + rule_info->sw_act.vsi_handle = act_vf->id;
> break;
> default:
> rte_flow_error_set(error,
> @@ -1515,7 +1521,8 @@ ice_switch_parse_pattern_action(struct
> ice_adapter *ad,
> }
>
> if (ad->hw.dcf_enabled)
> - ret = ice_switch_parse_dcf_action(actions, error, &rule_info);
> + ret = ice_switch_parse_dcf_action((void *)ad, actions, error,
> + &rule_info);
> else
> ret = ice_switch_parse_action(pf, actions, error, &rule_info);
>
> --
> 2.17.1
Acked-by: Qiming Yang
Re: [dpdk-dev] [PATCH 6/7] cmdline: support Windows
On 6/28/2020 7:20 AM, Fady Bader wrote: Hi Dmitry, I'm trying to run test-pmd on Windows and I ran into this error with cmdline. The error log message is : In file included from ../app/test-pmd/cmdline_flow.c:23: ..\lib\librte_cmdline/cmdline_parse_num.h:24:2: error: 'INT64' redeclared as different kind of symbol INT64 In file included from C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/winnt.h:150, from C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163, from C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/windef.h:8, from C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/windows.h:69, from ..\lib/librte_eal/windows/include/rte_windows.h:22, from ..\lib/librte_eal/windows/include/pthread.h:20, from ..\lib/librte_eal/include/rte_per_lcore.h:25, from ..\lib/librte_eal/include/rte_errno.h:18, from ..\lib\librte_ethdev/rte_ethdev.h:156, from ../app/test-pmd/cmdline_flow.c:18: C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/basetsd.h:32:44: note: previous declaration of 'INT64' was here __MINGW_EXTENSION typedef signed __int64 INT64,*PINT64; The same error is for the other types defined in cmdline_numtype. This problem with windows.h is popping in many places and some of them are cmdline and test-pmd and librte_net. We should find a way to exclude windows.h from the unneeded places, is there any suggestions on how it can be done ? We ran into this same issue when working with the code that is on the draft repo. The issue is that UINT8, UINT16, INT32, INT64 etc. are reserved types in Windows headers for integer types. We found that it is easier to change the enum in cmdline_parse_num.h than try to play with the include order of headers. AFAIK, the enums were only used to determine the type in a series of switch() statements in librte_cmdline, so we simply renamed the enums. Not sure, if that will be acceptable here. ranjit m.
