Re: [dpdk-dev] [PATCH v3 1/2] ethdev: add new ext hdr for gtp psc
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, April 1, 2021 7:51 PM
> To: Raslan Darawsheh ; dev@dpdk.org
> Cc: Ori Kam ; andrew.rybche...@oktetlabs.ru;
> ivan.ma...@oktetlabs.ru; ying.a.w...@intel.com; olivier.m...@6wind.com;
> Slava Ovsiienko ; Shiri Kuzin
> Subject: Re: [PATCH v3 1/2] ethdev: add new ext hdr for gtp psc
>
> On 3/30/2021 9:00 AM, Raslan Darawsheh wrote:
> > Define new rte header for gtp PDU session container
> > based on RFC 38415-g30
> >
> > Signed-off-by: Raslan Darawsheh
> > ---
> > lib/librte_net/rte_gtp.h | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/lib/librte_net/rte_gtp.h b/lib/librte_net/rte_gtp.h
> > index 6a6f9b238d..bfaae26535 100644
> > --- a/lib/librte_net/rte_gtp.h
> > +++ b/lib/librte_net/rte_gtp.h
> > @@ -61,6 +61,40 @@ struct rte_gtp_hdr_ext_word {
> > uint8_t next_ext; /**< Next Extension Header Type. */
> > } __rte_packed;
> >
> > +/**
> > + * Optional extension for GTP with next_ext set to 0x85
> > + * defined based on RFC 38415-g30.
> > + */
> > +__extension__
> > +struct rte_gtp_psc {
>
> general consensus in other protocols seems having '_hdr' suffix in the struct
> name, I can see this is extension but do you think does it make to add suffix?
Yes sure, will send in a new version.
>
> > + uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */
> > + uint8_t type:4; /**< PDU type */
> > + uint8_t qmp:1; /**< Qos Monitoring Packet */
> > + union {
> > + struct {
> > + uint8_t snp:1; /**< Sequence number presence */
> > + uint8_t spare_dl1:2; /**< spare down link bits */
> > + };
> > + struct {
> > + uint8_t dl_delay_ind:1; /**< dl delay result presence
> */
> > + uint8_t ul_delay_ind:1; /**< ul delay result presence
> */
> > + uint8_t snp_ul1:1; /**< Sequence number presence
> ul */
> > + };
> > + };
> > + union {
> > + struct {
> > + uint8_t ppp:1; /**< Paging policy presence */
> > + uint8_t rqi:1; /**< Reflective Qos Indicator */
> > + };
> > + struct {
> > + uint8_t n_delay_ind:1; /**< N3/N9 delay result
> presence */
> > + uint8_t spare_ul2:1; /**< spare up link bits */
> > + };
> > + };
> > + uint8_t qfi:6; /**< Qos Flow Identifier */
> > + uint8_t data[0]; /**< data feilds */
> > +} __rte_packed;
> > +
> > /** GTP header length */
> > #define RTE_ETHER_GTP_HLEN \
> > (sizeof(struct rte_udp_hdr) + sizeof(struct rte_gtp_hdr))
> >
Kindest regards
Raslan Darawsheh
Re: [dpdk-dev] [PATCH v3 2/2] ethdev: update qfi definition
Hi Ferruh,
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, April 1, 2021 7:54 PM
> To: Raslan Darawsheh ; dev@dpdk.org
> Cc: Ori Kam ; andrew.rybche...@oktetlabs.ru;
> ivan.ma...@oktetlabs.ru; ying.a.w...@intel.com; olivier.m...@6wind.com;
> Slava Ovsiienko ; Shiri Kuzin ;
> sta...@dpdk.org
> Subject: Re: [PATCH v3 2/2] ethdev: update qfi definition
>
> On 3/30/2021 9:00 AM, Raslan Darawsheh wrote:
> > qfi field is 8 bits which represent single bit for
> > PPP (paging Policy Presence) single bit for RQI
> > (Reflective QoS Indicator) and 6 bits for qfi
> > (QoS Flow Identifier) based on RFC 38415-g30
> >
> > This update the doxygen format and the mask for qfi
> > to properly identify the full 8 bits of the field.
> >
> > note: changing the default mask would cause different
> > patterns generated by testpmd.
> >
> > Fixes: 346553db5bd1 ("ethdev: add GTP extension header to flow API")
> > Cc: ying.a.w...@intel.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Raslan Darawsheh
> > ---
> > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++-
> > lib/librte_ethdev/rte_flow.h| 18 +++---
> > 2 files changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > index f59eb8a27d..dd39c4c3c2 100644
> > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> > @@ -3742,7 +3742,8 @@ This section lists supported pattern items and
> their attributes, if any.
> > - ``gtp_psc``: match GTP PDU extension header with type 0x85.
> >
> > - ``pdu_type {unsigned}``: PDU type.
> > - - ``qfi {unsigned}``: QoS flow identifier.
> > +
> > + - ``qfi {unsigned}``: PPP, RQI and QoS flow identifier.
> >
> > - ``pppoes``, ``pppoed``: match PPPoE header.
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > index 6cc57136ac..1eb9711707 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1421,16 +1422,27 @@ static const struct rte_flow_item_meta
> rte_flow_item_meta_mask = {
> >*
> >* Matches a GTP PDU extension header with type 0x85.
> >*/
> > +RTE_STD_C11
> > struct rte_flow_item_gtp_psc {
> > - uint8_t pdu_type; /**< PDU type. */
> > - uint8_t qfi; /**< QoS flow identifier. */
> > + union {
> > + struct {
> > + /*
> > +* These fields are retained for compatibility.
> > +* Please switch to the new header field below.
> > +*/
> > + uint8_t pdu_type; /**< PDU type. */
> > + uint8_t qfi; /**< PPP, RQI, QoS flow identifier. */
> > +
> > + };
> > + struct rte_gtp_psc gtp_psc;
>
> Again for consistency, what do you think to rename the variable as 'hdr'?
Will do,
>
> > + };
> > };
> >
> > /** Default mask for RTE_FLOW_ITEM_TYPE_GTP_PSC. */
> > #ifndef __cplusplus
> > static const struct rte_flow_item_gtp_psc
> > rte_flow_item_gtp_psc_mask = {
> > - .qfi = 0x3f,
> > + .qfi = 0xff,
>
> Since the protocol header is the preferred way, (individual fields may be
> deprecated in the future), can you please switch to new field, like:
Yes, will do it accordingly
> .gtp_psc.qfi = 0xff,
>
> > };
> > #endif
> >
> >
[dpdk-dev] [PATCH v4 0/2] fix gtp psc qfi support
This is fixing the gtp psc support to match the RFC 38415-g30 v2: introduce new header definition for gtp psc update commit msg for rte flow item change. v3: fixed typo in comment Cc relevant people. v4: update hdr definition to have hdr suffix. update variable name to be hdr in the gtp_psc item. update default max to use the new added hdr. Raslan Darawsheh (2): ethdev: add new ext hdr for gtp psc ethdev: update qfi definition doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 +- lib/librte_ethdev/rte_flow.h| 20 ++-- lib/librte_net/rte_gtp.h| 34 + 3 files changed, 53 insertions(+), 4 deletions(-) -- 2.29.0
[dpdk-dev] [PATCH v4 2/2] ethdev: update qfi definition
qfi field is 8 bits which represent single bit for
PPP (paging Policy Presence) single bit for RQI
(Reflective QoS Indicator) and 6 bits for qfi
(QoS Flow Identifier) based on RFC 38415-g30
This update the doxygen format and the mask for qfi
to properly identify the full 8 bits of the field.
note: changing the default mask would cause different
patterns generated by testpmd.
Fixes: 346553db5bd1 ("ethdev: add GTP extension header to flow API")
Cc: ying.a.w...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Raslan Darawsheh
---
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++-
lib/librte_ethdev/rte_flow.h| 20 +---
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index f59eb8a27d..dd39c4c3c2 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3742,7 +3742,8 @@ This section lists supported pattern items and their
attributes, if any.
- ``gtp_psc``: match GTP PDU extension header with type 0x85.
- ``pdu_type {unsigned}``: PDU type.
- - ``qfi {unsigned}``: QoS flow identifier.
+
+ - ``qfi {unsigned}``: PPP, RQI and QoS flow identifier.
- ``pppoes``, ``pppoed``: match PPPoE header.
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index 6cc57136ac..20b4389429 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1421,16 +1422,29 @@ static const struct rte_flow_item_meta
rte_flow_item_meta_mask = {
*
* Matches a GTP PDU extension header with type 0x85.
*/
+RTE_STD_C11
struct rte_flow_item_gtp_psc {
- uint8_t pdu_type; /**< PDU type. */
- uint8_t qfi; /**< QoS flow identifier. */
+ union {
+ struct {
+ /*
+* These fields are retained for compatibility.
+* Please switch to the new header field below.
+*/
+ uint8_t pdu_type; /**< PDU type. */
+ uint8_t qfi; /**< PPP, RQI, QoS flow identifier. */
+
+ };
+ struct rte_gtp_psc_hdr hdr;
+ };
};
/** Default mask for RTE_FLOW_ITEM_TYPE_GTP_PSC. */
#ifndef __cplusplus
static const struct rte_flow_item_gtp_psc
rte_flow_item_gtp_psc_mask = {
- .qfi = 0x3f,
+ .hdr.ppp = 1,
+ .hdr.rqi = 1,
+ .hdr.qfi = 0x3f,
};
#endif
--
2.29.0
[dpdk-dev] [PATCH v4 1/2] ethdev: add new ext hdr for gtp psc
Define new rte header for gtp PDU session container
based on RFC 38415-g30
Signed-off-by: Raslan Darawsheh
---
lib/librte_net/rte_gtp.h | 34 ++
1 file changed, 34 insertions(+)
diff --git a/lib/librte_net/rte_gtp.h b/lib/librte_net/rte_gtp.h
index 6a6f9b238d..088b0b5a53 100644
--- a/lib/librte_net/rte_gtp.h
+++ b/lib/librte_net/rte_gtp.h
@@ -61,6 +61,40 @@ struct rte_gtp_hdr_ext_word {
uint8_t next_ext; /**< Next Extension Header Type. */
} __rte_packed;
+/**
+ * Optional extension for GTP with next_ext set to 0x85
+ * defined based on RFC 38415-g30.
+ */
+__extension__
+struct rte_gtp_psc_hdr {
+ uint8_t ext_hdr_len; /**< PDU ext hdr len in multiples of 4 bytes */
+ uint8_t type:4; /**< PDU type */
+ uint8_t qmp:1; /**< Qos Monitoring Packet */
+ union {
+ struct {
+ uint8_t snp:1; /**< Sequence number presence */
+ uint8_t spare_dl1:2; /**< spare down link bits */
+ };
+ struct {
+ uint8_t dl_delay_ind:1; /**< dl delay result presence */
+ uint8_t ul_delay_ind:1; /**< ul delay result presence */
+ uint8_t snp_ul1:1; /**< Sequence number presence ul */
+ };
+ };
+ union {
+ struct {
+ uint8_t ppp:1; /**< Paging policy presence */
+ uint8_t rqi:1; /**< Reflective Qos Indicator */
+ };
+ struct {
+ uint8_t n_delay_ind:1; /**< N3/N9 delay result presence
*/
+ uint8_t spare_ul2:1; /**< spare up link bits */
+ };
+ };
+ uint8_t qfi:6; /**< Qos Flow Identifier */
+ uint8_t data[0]; /**< data feilds */
+} __rte_packed;
+
/** GTP header length */
#define RTE_ETHER_GTP_HLEN \
(sizeof(struct rte_udp_hdr) + sizeof(struct rte_gtp_hdr))
--
2.29.0
[dpdk-dev] [PATCH v4 0/7] Add support for VXLAN and NVGRE encap as a sample actions
This series adds support for VXLAN and NVGRE encap as a sample actions with the proper documentation, this series depends on [1] and [2] for the documentation part. [1] http://patches.dpdk.org/project/dpdk/patch/1615907899-399082-1-git-send-email-jiaw...@nvidia.com/ [2] http://patches.dpdk.org/project/dpdk/patch/1617244796-358287-1-git-send-email-jiaw...@nvidia.com/ Jiawei Wang (1): app/testpmd: store VXLAN/NVGRE encap data globally Salem Sol (6): net/mlx5: support VXLAN encap action in sample net/mlx5: support NVGRE encap action in sample app/testpmd: support VXLAN encap for sample action app/testpmd: support NVGRE encap for sample action doc: update sample actions support in testpmd guide doc: update sample actions support in mlx5 guide app/test-pmd/cmdline_flow.c | 86 ++--- doc/guides/nics/mlx5.rst| 4 +- doc/guides/rel_notes/release_21_05.rst | 6 ++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 24 ++ drivers/net/mlx5/mlx5_flow_dv.c | 13 5 files changed, 103 insertions(+), 30 deletions(-) -- 2.21.0
[dpdk-dev] [PATCH v4 2/7] net/mlx5: support VXLAN encap action in sample
Add support for VXLAN encap as a sample action and validate it. Signed-off-by: Salem Sol --- doc/guides/rel_notes/release_21_05.rst | 6 ++ drivers/net/mlx5/mlx5_flow_dv.c| 11 +++ 2 files changed, 17 insertions(+) diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index 23f7f0bff9..38213c4f50 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -65,6 +65,12 @@ New Features * Added support for txgbevf PMD. +* **Updated Mellanox mlx5 driver.** + + Updated the Mellanox mlx5 driver with new features and improvements, including: + + * Added support for VXLAN encap as a sample action. + * **Updated testpmd.** * Added command to display Rx queue used descriptor count. diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c index 1a74d5ac2b..4b2db47e39 100644 --- a/drivers/net/mlx5/mlx5_flow_dv.c +++ b/drivers/net/mlx5/mlx5_flow_dv.c @@ -5242,6 +5242,16 @@ flow_dv_validate_action_sample(uint64_t *action_flags, return ret; ++actions_n; break; + case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP: + ret = flow_dv_validate_action_l2_encap(dev, + sub_action_flags, + act, attr, + error); + if (ret < 0) + return ret; + sub_action_flags |= MLX5_FLOW_ACTION_ENCAP; + ++actions_n; + break; default: return rte_flow_error_set(error, ENOTSUP, RTE_FLOW_ERROR_TYPE_ACTION, @@ -10407,6 +10417,7 @@ flow_dv_translate_action_sample(struct rte_eth_dev *dev, action_flags |= MLX5_FLOW_ACTION_PORT_ID; break; } + case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP: case RTE_FLOW_ACTION_TYPE_RAW_ENCAP: /* Save the encap resource before sample */ pre_rix = dev_flow->handle->dvh.rix_encap_decap; -- 2.21.0
[dpdk-dev] [PATCH v4 4/7] app/testpmd: support VXLAN encap for sample action
Add support for rte_flow_action_vxlan_encap as a sample action.
The example of test-pmd command:
1. set vxlan ip-version ... vni ... udp-src ...
set raw_encap 1 eth src.../ ipv4.../...
set sample_actions 2 vxlan_encap / port_id id 0 / end
flow create 0 ... pattern eth / end actions
sample ratio 1 index 2 / raw_encap index 1 / port_id id 0...
The flow will result in all the matched egress packets will be
encapsulated and sent to wire, and also mirrored the packets
using VXLAN encapsulation data and sent to wire.
Signed-off-by: Salem Sol
---
app/test-pmd/cmdline_flow.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 16b2120dbc..978ce9c2c7 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -582,6 +582,7 @@ struct rte_flow_action_queue
sample_queue[RAW_SAMPLE_CONFS_MAX_NUM];
struct rte_flow_action_count sample_count[RAW_SAMPLE_CONFS_MAX_NUM];
struct rte_flow_action_port_id sample_port_id[RAW_SAMPLE_CONFS_MAX_NUM];
struct rte_flow_action_raw_encap sample_encap[RAW_SAMPLE_CONFS_MAX_NUM];
+struct action_vxlan_encap_data sample_vxlan_encap[RAW_SAMPLE_CONFS_MAX_NUM];
struct action_rss_data sample_rss_data[RAW_SAMPLE_CONFS_MAX_NUM];
struct rte_flow_action_vf sample_vf[RAW_SAMPLE_CONFS_MAX_NUM];
@@ -1615,6 +1616,7 @@ static const enum index next_action_sample[] = {
ACTION_COUNT,
ACTION_PORT_ID,
ACTION_RAW_ENCAP,
+ ACTION_VXLAN_ENCAP,
ACTION_NEXT,
ZERO,
};
@@ -7943,6 +7945,11 @@ cmd_set_raw_parsed_sample(const struct buffer *in)
(const void *)action->conf, size);
action->conf = &sample_vf[idx];
break;
+ case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP:
+ size = sizeof(struct rte_flow_action_vxlan_encap);
+ parse_setup_vxlan_encap_data(&sample_vxlan_encap[idx]);
+ action->conf = &sample_vxlan_encap[idx].conf;
+ break;
default:
printf("Error - Not supported action\n");
return;
--
2.21.0
[dpdk-dev] [PATCH v4 1/7] app/testpmd: store VXLAN/NVGRE encap data globally
From: Jiawei Wang
With the current code the VXLAN/NVGRE parsing routine
stored the configuration of the header on stack, this
might lead to overwriting the data on the stack.
This patch stores the external data of vxlan and nvgre encap
into global data as a pre-step to supporting vxlan and nvgre
encap as a sample actions.
Signed-off-by: Jiawei Wang
---
app/test-pmd/cmdline_flow.c | 72 ++---
1 file changed, 44 insertions(+), 28 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 49d9f9c043..16b2120dbc 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -5244,31 +5244,11 @@ parse_vc_action_rss_queue(struct context *ctx, const
struct token *token,
return len;
}
-/** Parse VXLAN encap action. */
+/** Setup VXLAN encap configuration. */
static int
-parse_vc_action_vxlan_encap(struct context *ctx, const struct token *token,
- const char *str, unsigned int len,
- void *buf, unsigned int size)
+parse_setup_vxlan_encap_data(struct action_vxlan_encap_data
*action_vxlan_encap_data)
{
- struct buffer *out = buf;
- struct rte_flow_action *action;
- struct action_vxlan_encap_data *action_vxlan_encap_data;
- int ret;
-
- ret = parse_vc(ctx, token, str, len, buf, size);
- if (ret < 0)
- return ret;
- /* Nothing else to do if there is no buffer. */
- if (!out)
- return ret;
- if (!out->args.vc.actions_n)
- return -1;
- action = &out->args.vc.actions[out->args.vc.actions_n - 1];
- /* Point to selected object. */
- ctx->object = out->args.vc.data;
- ctx->objmask = NULL;
/* Set up default configuration. */
- action_vxlan_encap_data = ctx->object;
*action_vxlan_encap_data = (struct action_vxlan_encap_data){
.conf = (struct rte_flow_action_vxlan_encap){
.definition = action_vxlan_encap_data->items,
@@ -5372,19 +5352,18 @@ parse_vc_action_vxlan_encap(struct context *ctx, const
struct token *token,
}
memcpy(action_vxlan_encap_data->item_vxlan.vni, vxlan_encap_conf.vni,
RTE_DIM(vxlan_encap_conf.vni));
- action->conf = &action_vxlan_encap_data->conf;
- return ret;
+ return 0;
}
-/** Parse NVGRE encap action. */
+/** Parse VXLAN encap action. */
static int
-parse_vc_action_nvgre_encap(struct context *ctx, const struct token *token,
+parse_vc_action_vxlan_encap(struct context *ctx, const struct token *token,
const char *str, unsigned int len,
void *buf, unsigned int size)
{
struct buffer *out = buf;
struct rte_flow_action *action;
- struct action_nvgre_encap_data *action_nvgre_encap_data;
+ struct action_vxlan_encap_data *action_vxlan_encap_data;
int ret;
ret = parse_vc(ctx, token, str, len, buf, size);
@@ -5399,8 +5378,17 @@ parse_vc_action_nvgre_encap(struct context *ctx, const
struct token *token,
/* Point to selected object. */
ctx->object = out->args.vc.data;
ctx->objmask = NULL;
+ action_vxlan_encap_data = ctx->object;
+ parse_setup_vxlan_encap_data(action_vxlan_encap_data);
+ action->conf = &action_vxlan_encap_data->conf;
+ return ret;
+}
+
+/** Setup NVGRE encap configuration. */
+static int
+parse_setup_nvgre_encap_data(struct action_nvgre_encap_data
*action_nvgre_encap_data)
+{
/* Set up default configuration. */
- action_nvgre_encap_data = ctx->object;
*action_nvgre_encap_data = (struct action_nvgre_encap_data){
.conf = (struct rte_flow_action_nvgre_encap){
.definition = action_nvgre_encap_data->items,
@@ -5463,6 +5451,34 @@ parse_vc_action_nvgre_encap(struct context *ctx, const
struct token *token,
RTE_FLOW_ITEM_TYPE_VOID;
memcpy(action_nvgre_encap_data->item_nvgre.tni, nvgre_encap_conf.tni,
RTE_DIM(nvgre_encap_conf.tni));
+ return 0;
+}
+
+/** Parse NVGRE encap action. */
+static int
+parse_vc_action_nvgre_encap(struct context *ctx, const struct token *token,
+ const char *str, unsigned int len,
+ void *buf, unsigned int size)
+{
+ struct buffer *out = buf;
+ struct rte_flow_action *action;
+ struct action_nvgre_encap_data *action_nvgre_encap_data;
+ int ret;
+
+ ret = parse_vc(ctx, token, str, len, buf, size);
+ if (ret < 0)
+ return ret;
+ /* Nothing else to do if there is no buffer. */
+ if (!out)
+ return ret;
+ if (!out->args.vc.actions_n)
+ return -1;
+ action = &out->args.vc.actions[out->args.vc.actions_n - 1];
+ /* Point to selected object. */
+ ctx->object = out->args.vc.data;
+ c
[dpdk-dev] [PATCH v4 3/7] net/mlx5: support NVGRE encap action in sample
Add support for NVGRE encap as a sample action and validate it. Signed-off-by: Salem Sol --- doc/guides/rel_notes/release_21_05.rst | 2 +- drivers/net/mlx5/mlx5_flow_dv.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index 38213c4f50..cdedca6db7 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -69,7 +69,7 @@ New Features Updated the Mellanox mlx5 driver with new features and improvements, including: - * Added support for VXLAN encap as a sample action. + * Added support for VXLAN and NVGRE encap as sample actions. * **Updated testpmd.** diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c index 4b2db47e39..590abdc822 100644 --- a/drivers/net/mlx5/mlx5_flow_dv.c +++ b/drivers/net/mlx5/mlx5_flow_dv.c @@ -5243,6 +5243,7 @@ flow_dv_validate_action_sample(uint64_t *action_flags, ++actions_n; break; case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP: + case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP: ret = flow_dv_validate_action_l2_encap(dev, sub_action_flags, act, attr, @@ -10418,6 +10419,7 @@ flow_dv_translate_action_sample(struct rte_eth_dev *dev, break; } case RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP: + case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP: case RTE_FLOW_ACTION_TYPE_RAW_ENCAP: /* Save the encap resource before sample */ pre_rix = dev_flow->handle->dvh.rix_encap_decap; -- 2.21.0
[dpdk-dev] [PATCH v4 5/7] app/testpmd: support NVGRE encap for sample action
Add support for rte_flow_action_nvge_encap as a sample action.
The example of test-pmd command:
1. set nvgre ip-version ... tni ... ip-src ... ip-dst ...
set raw_encap 1 eth src... / ipv4... /...
set sample_actions 2 nvgre / port_id id 0 / end
flow create 0 ... pattern eth / end actions
sample ratio 1 index 2 / raw_encap index 1 / port_id id 0...
The flow will result in all the matched egress packets will be
encapsulated and sent to wire, and also mirrored the packets
using NVGRE encapsulation data and sent to wire.
Signed-off-by: Salem Sol
---
app/test-pmd/cmdline_flow.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 978ce9c2c7..70896e27c7 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -583,6 +583,7 @@ struct rte_flow_action_count
sample_count[RAW_SAMPLE_CONFS_MAX_NUM];
struct rte_flow_action_port_id sample_port_id[RAW_SAMPLE_CONFS_MAX_NUM];
struct rte_flow_action_raw_encap sample_encap[RAW_SAMPLE_CONFS_MAX_NUM];
struct action_vxlan_encap_data sample_vxlan_encap[RAW_SAMPLE_CONFS_MAX_NUM];
+struct action_nvgre_encap_data sample_nvgre_encap[RAW_SAMPLE_CONFS_MAX_NUM];
struct action_rss_data sample_rss_data[RAW_SAMPLE_CONFS_MAX_NUM];
struct rte_flow_action_vf sample_vf[RAW_SAMPLE_CONFS_MAX_NUM];
@@ -1617,6 +1618,7 @@ static const enum index next_action_sample[] = {
ACTION_PORT_ID,
ACTION_RAW_ENCAP,
ACTION_VXLAN_ENCAP,
+ ACTION_NVGRE_ENCAP,
ACTION_NEXT,
ZERO,
};
@@ -7950,6 +7952,11 @@ cmd_set_raw_parsed_sample(const struct buffer *in)
parse_setup_vxlan_encap_data(&sample_vxlan_encap[idx]);
action->conf = &sample_vxlan_encap[idx].conf;
break;
+ case RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP:
+ size = sizeof(struct rte_flow_action_nvgre_encap);
+ parse_setup_nvgre_encap_data(&sample_nvgre_encap[idx]);
+ action->conf = &sample_nvgre_encap[idx];
+ break;
default:
printf("Error - Not supported action\n");
return;
--
2.21.0
[dpdk-dev] [PATCH v4 6/7] doc: update sample actions support in testpmd guide
Update documentation for sample action usage in testpmd utilizing rte_flow_action_vxlan_encap and rte_flow_action_nvgre_encap and show the command line example. Signed-off-by: Salem Sol --- doc/guides/testpmd_app_ug/testpmd_funcs.rst | 24 + 1 file changed, 24 insertions(+) diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index 2b407a3e9a..36f0a328a5 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -4893,6 +4893,30 @@ encapsulation header and sent to port id 0. testpmd> flow create 0 ingress transfer pattern eth / end actions sample ratio 1 index 0 / port_id id 2 / end +Mirroring rule with port representors (with "transfer" attribute), the matched +ingress packets are sent to port id 2, and also mirrored the packets with +VXLAN encapsulation header and sent to port id 0. + +:: + + testpmd> set vxlan ip-version ipv4 vni 4 udp-src 4 udp-dst 4 ip-src 127.0.0.1 +ip-dst 128.0.0.1 eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22 + testpmd> set sample_actions 0 vxlan_encap / port_id id 0 / end + testpmd> flow create 0 ingress transfer pattern eth / end actions +sample ratio 1 index 0 / port_id id 2 / end + +Mirroring rule with port representors (with "transfer" attribute), the matched +ingress packets are sent to port id 2, and also mirrored the packets with +NVGRE encapsulation header and sent to port id 0. + +:: + + testpmd> set nvgre ip-version ipv4 tni 4 ip-src 127.0.0.1 ip-dst 128.0.0.1 +eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22 + testpmd> set sample_actions 0 nvgre_encap / port_id id 0 / end + testpmd> flow create 0 ingress transfer pattern eth / end actions +sample ratio 1 index 0 / port_id id 2 / end + BPF Functions -- -- 2.21.0
[dpdk-dev] [PATCH v4 7/7] doc: update sample actions support in mlx5 guide
Updates the documentation with the added support for sample actions VXLAN and NVGRE encap in E-Switch steering flow. Signed-off-by: Salem Sol --- doc/guides/nics/mlx5.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index 96fce36e3c..378b7202d9 100644 --- a/doc/guides/nics/mlx5.rst +++ b/doc/guides/nics/mlx5.rst @@ -376,8 +376,8 @@ Limitations encapsulation actions. - For NIC Rx flow, supports ``MARK``, ``COUNT``, ``QUEUE``, ``RSS`` in the sample actions list. - - For E-Switch mirroring flow, supports ``RAW ENCAP``, ``Port ID`` in the -sample actions list. + - For E-Switch mirroring flow, supports ``RAW ENCAP``, ``Port ID``, +``VXLAN ENCAP``, ``NVGRE ENCAP`` in the sample actions list. - Modify Field flow: -- 2.21.0
Re: [dpdk-dev] [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API
Hi Cristian From: Dumitrescu, Cristian > Hi Matan, > > > -Original Message- > > From: Matan Azrad > > Sent: Monday, March 29, 2021 9:44 PM > > To: Dumitrescu, Cristian ; Li Zhang > > ; Dekel Peled ; Ori Kam > > ; Slava Ovsiienko ; Shahaf > > Shuler ; lir...@marvell.com; Singh, Jasvinder > > ; NBU-Contact-Thomas Monjalon > > ; Yigit, Ferruh ; Andrew > > Rybchenko ; Jerin Jacob > > ; Hemant Agrawal ; > Ajit > > Khaparde > > Cc: dev@dpdk.org; Raslan Darawsheh ; Roni Bar > > Yanai > > Subject: RE: [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy > > API > > > > > > > > From: Dumitrescu, Cristian > > > Hi Matan, > > > > > > > -Original Message- > > > > From: Matan Azrad > > > > Sent: Thursday, March 25, 2021 6:57 AM > > > > To: Dumitrescu, Cristian ; Li Zhang > > > > ; Dekel Peled ; Ori Kam > > > > ; Slava Ovsiienko ; > > > > Shahaf Shuler ; lir...@marvell.com; Singh, > > > > Jasvinder ; NBU-Contact-Thomas Monjalon > > > > ; Yigit, Ferruh ; > > Andrew > > > > Rybchenko ; Jerin Jacob > > > > ; Hemant Agrawal > > ; > > > Ajit > > > > Khaparde > > > > Cc: dev@dpdk.org; Raslan Darawsheh ; Roni Bar > > > > Yanai > > > > Subject: RE: [PATCH 1/2] [RFC]: ethdev: add pre-defined meter > > > > policy API > > > > > > > > Hi Cristian > > > > > > > > Thank you for your important review! > > > > I agree with all your comments except one, please see inline. > > > > > > > > From: Dumitrescu, Cristian > > > > > Hi Li and Matan, > > > > > > > > > > Thank you for your proposal, some comments below. > > > > > > > > > > I am also adding Jerin and Hemant to this thread, as they also > > > > > participated > > > > in > > > > > the definition of the rte_mtr API in 2017. Also Ajit expressed > > > > > some interest > > > > in a > > > > > previous email. > > > > > > > > > > > -Original Message- > > > > > > From: Li Zhang > > > > > > Sent: Thursday, March 18, 2021 8:58 AM > > > > > > To: dek...@nvidia.com; or...@nvidia.com; > > > > > > viachesl...@nvidia.com; ma...@nvidia.com; shah...@nvidia.com; > > > > > > lir...@marvell.com; Singh, Jasvinder > > > > > > ; Thomas Monjalon > > > > > > ; Yigit, Ferruh ; > > > > Andrew > > > > > > Rybchenko ; Dumitrescu, > > > > > > Cristian > > > > > > Cc: dev@dpdk.org; rasl...@nvidia.com; ron...@nvidia.com > > > > > > Subject: [PATCH 1/2] [RFC]: ethdev: add pre-defined meter > > > > > > policy API > > > > > > > > > > > > Currently, the flow meter policy does not support multiple > > > > > > actions per color; also the allowed action types per color are very > limited. > > > > > > In addition, the policy cannot be pre-defined. > > > > > > > > > > > > Due to the growing in flow actions offload abilities there is > > > > > > a potential for the user to use variety of actions per color > > > > > > differently. > > > > > > This new meter policy API comes to allow this potential in the > > > > > > most ethdev common way using rte_flow action definition. > > > > > > A list of rte_flow actions will be provided by the user per > > > > > > color in order to create a meter policy. > > > > > > In addition, the API forces to pre-define the policy before > > > > > > the meters creation in order to allow sharing of single policy > > > > > > with multiple meters efficiently. > > > > > > > > > > > > meter_policy_id is added into struct rte_mtr_params. > > > > > > So that it can get the policy during the meters creation. > > > > > > > > > > > > Policy id 0 is default policy. Action per color as below: > > > > > > green - no action, yellow - no action, red - drop > > > > > > > > > > > > Allow coloring the packet using a new rte_flow_action_color as > > > > > > could be done by the old policy API, > > > > > > > > > > > > > > > > The proposal essentially is to define the meter policy based on > > > > > rte_flow > > > > actions > > > > > rather than a reduced action set defined specifically just for > > > > > meter > > object. > > > > This > > > > > makes sense to me. > > > > > > > > > > > The next API function were added: > > > > > > - rte_mtr_meter_policy_add > > > > > > - rte_mtr_meter_policy_delete > > > > > > - rte_mtr_meter_policy_update > > > > > > - rte_mtr_meter_policy_validate The next struct was changed: > > > > > > - rte_mtr_params > > > > > > - rte_mtr_capabilities > > > > > > The next API was deleted: > > > > > > - rte_mtr_policer_actions_update > > > > > > > > > > > > Signed-off-by: Li Zhang > > > > > > --- > > > > > > lib/librte_ethdev/rte_flow.h | 18 > > > > > > lib/librte_ethdev/rte_mtr.c| 55 -- > > > > > > lib/librte_ethdev/rte_mtr.h| 166 > > > > > > --- > > -- > > > > > > lib/librte_ethdev/rte_mtr_driver.h | 45 ++-- > > > > > > 4 files changed, 210 insertions( > > > > > > > > +/** > > > > > > + * Policy id 0 is default policy. > > > > > > > > > > I suggest you do not redundantly specify the value of the > > > > > default policy ID > > > > in the > > > > > comment. Replace by "Default policy
[dpdk-dev] vfio error
Hi, I have a dpdk application which binds nic with igb_uio. My problem is whenever the kernel updates, I must recompile igb_uio.ko as well. I want to use vfio instead but I got an error: Error: bind failed for :06:00.0 - Cannot bind to driver vfio-pci Error: unbind failed for :06:00.0 - Cannot open /sys/bus/pci/drivers//unbind I used ubuntu 20.04 and dpdk-18.05 and use dpdk-setup.py helper script Regards, hamid
Re: [dpdk-dev] vfio error
Look at kernel log (dmesg). Probably you don't have VT-d enabled. On Sun, Apr 4, 2021, 7:40 AM hamidreza Kheirabadi < hamidreza.kheirab...@gmail.com> wrote: > Hi, > I have a dpdk application which binds nic with igb_uio. My problem is > whenever the kernel updates, I must recompile igb_uio.ko as well. > I want to use vfio instead but I got an error: > > Error: bind failed for :06:00.0 - Cannot bind to driver vfio-pci > Error: unbind failed for :06:00.0 - Cannot open > /sys/bus/pci/drivers//unbind > > I used ubuntu 20.04 and dpdk-18.05 and use dpdk-setup.py helper script > > Regards, > hamid >
[dpdk-dev] [PATCH v2] cryptodev: support multiple cipher data-units
In cryptography, a block cipher is a deterministic algorithm operating
on fixed-length groups of bits, called blocks.
A block cipher consists of two paired algorithms, one for encryption
and the other for decryption. Both algorithms accept two inputs:
an input block of size n bits and a key of size k bits; and both yield
an n-bit output block. The decryption algorithm is defined to be the
inverse function of the encryption.
For AES standard the block size is 16 bytes.
For AES in XTS mode, the data to be encrypted\decrypted does not have to
be multiple of 16B size, the unit of data is called data-unit.
The data-unit size can be any size in range [16B, 2^24B], so, in this
case, a data stream is divided into N amount of equal data-units and
must be encrypted\decrypted in the same data-unit resolution.
The current cryptodev API doesn't allow the user to select a specific
data-unit length supported by the devices.
In addition, there is no definition how the IV is detected per data-unit
when single operation includes more than one data-unit.
That causes applications to use single operation per data-unit even though
all the data is continuous in memory what reduces datapath performance.
Add a new feature flag to support multiple data-unit sizes, called
RTE_CRYPTODEV_FF_CIPHER_MULITPLE_DATA_UNITS.
Add a new field in cipher capability, called dataunit_set,
where the devices can report the range of the supported data-unit sizes.
Add a new cipher transformation field, called dataunit_len, where the user
can select the data-unit length for all the operations.
All the new fields do not change the size of their structures.
Using a bitmap to report the supported data-unit sizes capability allows
the devices to report a range simply as same as the user to read it
simply. also, thus sizes are usually common and probably will be shared
among different devices.
Signed-off-by: Matan Azrad
---
RFC->V1:
- Use data-unit term instead of block.
- Update cipher length description in OP.
- Improve descriptions on xform and capability.
- Improve commit log.
V1->V2:
- Fix typo: MULITPLE->MULITPLE.
- Remain only planned supported sizes for data-unit capability.
doc/guides/cryptodevs/features/default.ini | 1 +
doc/guides/cryptodevs/overview.rst | 3 +++
doc/guides/rel_notes/release_21_05.rst | 6 ++
lib/librte_cryptodev/rte_crypto_sym.h | 17 +++--
lib/librte_cryptodev/rte_cryptodev.c | 2 ++
lib/librte_cryptodev/rte_cryptodev.h | 15 +++
6 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/doc/guides/cryptodevs/features/default.ini
b/doc/guides/cryptodevs/features/default.ini
index 17b177fc45..978bb30cc1 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -31,6 +31,7 @@ CPU crypto =
Symmetric sessionless =
Non-Byte aligned data =
Sym raw data path API =
+Cipher multiple data units =
;
; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/cryptodevs/overview.rst
b/doc/guides/cryptodevs/overview.rst
index e2a1e08ec1..e24e3e1993 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -46,6 +46,9 @@ Supported Feature Flags
- "Digest encrypted" feature flag means PMD support hash-cipher cases,
where generated digest is appended to and encrypted with the data.
+ - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support operations
+ on multiple data-units message.
+
Supported Cipher Algorithms
---
diff --git a/doc/guides/rel_notes/release_21_05.rst
b/doc/guides/rel_notes/release_21_05.rst
index 873140b433..1537fac4bc 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -126,6 +126,12 @@ New Features
* Added command to display Rx queue used descriptor count.
``show port (port_id) rxq (queue_id) desc used count``
+* **Added feature to support multiple data-units on cryptodev library API.**
+
+ The Cryptodev library has been enhanced to allow operations on multiple
+ data-units for AES-XTS algorithm, the data-unit length should be set in the
+ transformation. A capability for it was added too.
+
Removed Items
-
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
b/lib/librte_cryptodev/rte_crypto_sym.h
index 9d572ec057..5973e31f30 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -265,6 +265,18 @@ struct rte_crypto_cipher_xform {
* which can be in the range 7 to 13 inclusive.
*/
} iv; /**< Initialisation vector parameters */
+
+ uint32_t dataunit_len;
+ /**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is enabled,
+* this is the data-unit length of the algorithm, otherwise or when the
+* value is 0, use the operation length.
+* The value should be in the range defi
Re: [dpdk-dev] [PATCH v4 3/3] test/event_crypto: use crypto adapter enqueue API
On Sat, Apr 03, 2021 at 11:08:28AM +, Gujjar, Abhinandan S wrote:
>
>
> > -Original Message-
> > From: Shijith Thotton
> > Sent: Friday, April 2, 2021 10:31 PM
> > To: dev@dpdk.org
> > Cc: Shijith Thotton ; tho...@monjalon.net;
> > jer...@marvell.com; Gujjar, Abhinandan S ;
> > hemant.agra...@nxp.com; nipun.gu...@nxp.com;
> > sachin.sax...@oss.nxp.com; ano...@marvell.com; ma...@nvidia.com;
> > Zhang, Roy Fan ; g.si...@nxp.com; Carrillo, Erik
> > G ; Jayatheerthan, Jay
> > ; pbhagavat...@marvell.com; Van Haaren,
> > Harry ; Akhil Goyal
> > Subject: [PATCH v4 3/3] test/event_crypto: use crypto adapter enqueue API
> >
> > Use rte_event_crypto_adapter_enqueue() API to enqueue events to crypto
> > adapter if forward mode is supported in driver.
> >
> > Signed-off-by: Shijith Thotton
> > ---
> > app/test/test_event_crypto_adapter.c | 29 +++-
> > 1 file changed, 20 insertions(+), 9 deletions(-)
> >
> > diff --git a/app/test/test_event_crypto_adapter.c
> > b/app/test/test_event_crypto_adapter.c
> > index 335211cd8..2b07f1582 100644
> > --- a/app/test/test_event_crypto_adapter.c
> > +++ b/app/test/test_event_crypto_adapter.c
> > @@ -64,6 +64,7 @@ struct event_crypto_adapter_test_params {
> > struct rte_mempool *session_priv_mpool;
> > struct rte_cryptodev_config *config;
> > uint8_t crypto_event_port_id;
> > + uint8_t internal_port_op_fwd;
> > };
> >
> > struct rte_event response_info = {
> > @@ -110,9 +111,12 @@ send_recv_ev(struct rte_event *ev)
> > struct rte_event recv_ev;
> > int ret;
> >
> > - ret = rte_event_enqueue_burst(evdev, TEST_APP_PORT_ID, ev,
> > NUM);
> > - TEST_ASSERT_EQUAL(ret, NUM,
> > - "Failed to send event to crypto adapter\n");
> > + if (params.internal_port_op_fwd)
> > + ret = rte_event_crypto_adapter_enqueue(evdev,
> > TEST_APP_PORT_ID,
> > + ev, NUM);
> > + else
> > + ret = rte_event_enqueue_burst(evdev,
> > TEST_APP_PORT_ID, ev, NUM);
> > + TEST_ASSERT_EQUAL(ret, NUM, "Failed to send event to crypto
> > +adapter\n");
> >
> > while (rte_event_dequeue_burst(evdev,
> > TEST_APP_PORT_ID, &recv_ev, NUM, 0) == 0) @@ -
> > 741,6 +745,11 @@ configure_event_crypto_adapter(enum
> > rte_event_crypto_adapter_mode mode)
> > ret = rte_event_crypto_adapter_caps_get(evdev, TEST_CDEV_ID,
> > &cap);
> > TEST_ASSERT_SUCCESS(ret, "Failed to get adapter capabilities\n");
> >
> > + if (cap &
> > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD)
> > + params.internal_port_op_fwd = 1;
> > + else
> > + params.internal_port_op_fwd = 0;
> > +
> There is a check at line 760 for FWD mode. Can't this be set there?
>
Yes, I will move it over there.
> > /* Skip mode and capability mismatch check for SW eventdev */
> > if (!(cap &
> > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW) &&
> > !(cap &
> > RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD) && @@ -
> > 771,9 +780,11 @@ configure_event_crypto_adapter(enum
> > rte_event_crypto_adapter_mode mode)
> >
> > TEST_ASSERT_SUCCESS(ret, "Failed to add queue pair\n");
> >
> > - ret =
> > rte_event_crypto_adapter_event_port_get(TEST_ADAPTER_ID,
> > - ¶ms.crypto_event_port_id);
> > - TEST_ASSERT_SUCCESS(ret, "Failed to get event port\n");
> > + if (!params.internal_port_op_fwd) {
> > + ret =
> > rte_event_crypto_adapter_event_port_get(TEST_ADAPTER_ID,
> > +
> > ¶ms.crypto_event_port_id);
> > + TEST_ASSERT_SUCCESS(ret, "Failed to get event port\n");
> > + }
> >
> > return TEST_SUCCESS;
> > }
> > @@ -809,15 +820,15 @@ test_crypto_adapter_conf(enum
> > rte_event_crypto_adapter_mode mode)
> >
> > if (!crypto_adapter_setup_done) {
> > ret = configure_event_crypto_adapter(mode);
> > - if (!ret) {
> > + if (ret)
> > + return ret;
> > + if (!params.internal_port_op_fwd) {
> > qid = TEST_CRYPTO_EV_QUEUE_ID;
> > ret = rte_event_port_link(evdev,
> > params.crypto_event_port_id, &qid, NULL,
> > 1);
> > TEST_ASSERT(ret >= 0, "Failed to link queue %d "
> > "port=%u\n", qid,
> > params.crypto_event_port_id);
> > - } else {
> > - return ret;
> > }
> > crypto_adapter_setup_done = 1;
> > }
> > --
> > 2.25.1
>
Re: [dpdk-dev] [PATCH RFC] raw: add dpaa qdma driver
Hi Thomas, > -Original Message- > From: Thomas Monjalon > Sent: Thursday, March 25, 2021 2:56 AM > To: Gagandeep Singh ; Hemant Agrawal > > Cc: dev@dpdk.org; Nipun Gupta ; Peng Ma > > Subject: Re: [dpdk-dev] [PATCH RFC] raw: add dpaa qdma driver > > 25/09/2020 08:10, Hemant Agrawal: > > Hi Gagan, > > > > On 9/7/2020 3:20 PM, Gagandeep Singh wrote: > > > This patch adds support for dpaa qdma based driver. > > > > > Can you provide more details and break it into logical parts? > > Is it abandoned? > > It is abandoned for now. I will try to send the patches next month for next DPDK release.
