RE: [PATCH v7 1/6] eal: trace: add trace point emit for blob

[Morten Brørup]

> From: Sunil Kumar Kori [mailto:sk...@marvell.com]
> Sent: Monday, 30 January 2023 08.31
> 
> > From: Ankur Dwivedi 
> > Sent: Monday, January 23, 2023 2:32 PM
> >

[...]

> > +RTE_TRACE_POINT(
> > +   rte_eal_trace_generic_blob,
> > +   RTE_TRACE_POINT_ARGS(void *in, uint8_t len),
> > +   rte_trace_point_emit_blob(in, len);
> > +)
> > +
> 
> As per documentation rte_eal_trace_generic_blob() will emit 64 bytes
> only i.e. input array cannot be other than uint8_t.
> So will it not be better to make it more readable like
> RTE_TRACE_POINT_ARGS(uint8_t *in, uint8_t len) instead of using void
> *in.

No. Using uint8_t* would cause type conversion problems. The advantage of using 
void* is that it is has no type - which is exactly the purpose of a BLOB (which 
is short for Binary Large OBject). We want to be able to pass a pointer to e.g. 
a structure. Using void* makes that directly available.

I didn't notice before, but the const qualifier is missing. It should be:

RTE_TRACE_POINT_ARGS(const void *in, uint8_t len),

> 
> Rest is fine. Already acked above.
> 
> >  #define RTE_EAL_TRACE_GENERIC_FUNC
> > rte_eal_trace_generic_func(__func__)
> >
> >  /* Interrupt */
> 
> [snipped]
> 
> > 2.25.1
> 

[PATCH v2] net/i40e: support enabling/disabling source pruning

[Ke Zhang]

VRRP advertisement packets are dropped on i40e PF devices because
when a MAC address is added to a device, packets originating from
that MAC address are dropped.

This patch adds a PMD specific API to enable/disable source
pruning to fix above issue.

Bugzilla ID: 648

Signed-off-by: Ke Zhang 
---
 app/test-pmd/cmdline.c  | 84 +
 drivers/net/i40e/i40e_ethdev.c  | 43 +
 drivers/net/i40e/i40e_ethdev.h  |  1 +
 drivers/net/i40e/rte_pmd_i40e.c | 20 
 drivers/net/i40e/rte_pmd_i40e.h | 16 +++
 5 files changed, 164 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index cb8c174020..76a574affd 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -776,6 +776,9 @@ static void cmd_help_long_parsed(void *parsed_result,
 
"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
"Cleanup txq mbufs for a specific Tx queue\n\n"
+
+   "port config (port_id|all) src_prune (on|off)\n"
+   "Set source prune on port_id, or all.\n\n"
);
}
 
@@ -1619,6 +1622,84 @@ static cmdline_parse_inst_t cmd_config_loopback_specific 
= {
},
 };
 
+/* *** configure source prune for port *** */
+struct cmd_config_src_prune_result {
+   cmdline_fixed_string_t port;
+   cmdline_fixed_string_t keyword;
+   cmdline_fixed_string_t port_all; /* valid if "allports" argument == 1 */
+   uint16_t port_num;   /* valid if "allports" argument == 0 */
+   cmdline_fixed_string_t item;
+   cmdline_fixed_string_t enable;
+};
+
+static void cmd_config_src_prune_parsed(void *parsed_result,
+   __rte_unused struct cmdline *cl,
+   void *allports)
+{
+   struct cmd_config_src_prune_result *res = parsed_result;
+   int enable;
+   portid_t i;
+
+   if (!strcmp(res->enable, "on"))
+   enable = 1;
+   else
+   enable = 0;
+
+   /* all ports */
+   if (allports) {
+   RTE_ETH_FOREACH_DEV(i)
+   rte_pmd_i40e_set_src_prune(i, enable);
+   } else {
+   rte_pmd_i40e_set_src_prune(res->port_num, enable);
+   }
+}
+
+static cmdline_parse_token_string_t cmd_config_src_prune_port =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_src_prune_result, port, 
"port");
+static cmdline_parse_token_string_t cmd_config_src_prune_keyword =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_src_prune_result, keyword,
+"config");
+static cmdline_parse_token_string_t cmd_config_src_prune_portall =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_src_prune_result, port_all,
+"all");
+static cmdline_parse_token_num_t cmd_config_src_prune_portnum =
+   TOKEN_NUM_INITIALIZER(struct cmd_config_src_prune_result, port_num,
+ RTE_UINT16);
+static cmdline_parse_token_string_t cmd_config_src_prune_item =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_src_prune_result,
+   item, "src_prune");
+static cmdline_parse_token_string_t cmd_config_src_prune_enable =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_src_prune_result, enable,
+"on#off");
+
+static cmdline_parse_inst_t cmd_config_src_prune_all = {
+   .f = cmd_config_src_prune_parsed,
+   .data = (void *)1,
+   .help_str = "port config all src_prune (on|off): Set source prune on 
all ports.",
+   .tokens = {
+   (void *)&cmd_config_src_prune_port,
+   (void *)&cmd_config_src_prune_keyword,
+   (void *)&cmd_config_src_prune_portall,
+   (void *)&cmd_config_src_prune_item,
+   (void *)&cmd_config_src_prune_enable,
+   NULL,
+   },
+};
+
+static cmdline_parse_inst_t cmd_config_src_prune_specific = {
+   .f = cmd_config_src_prune_parsed,
+   .data = (void *)0,
+   .help_str = "port config all src_prune (on|off): Set source prune on 
specific port.",
+   .tokens = {
+   (void *)&cmd_config_src_prune_port,
+   (void *)&cmd_config_src_prune_keyword,
+   (void *)&cmd_config_src_prune_portnum,
+   (void *)&cmd_config_src_prune_item,
+   (void *)&cmd_config_src_prune_enable,
+   NULL,
+   },
+};
+
 /* *** configure txq/rxq, txd/rxd *** */
 struct cmd_config_rx_tx {
cmdline_fixed_string_t port;
@@ -12731,6 +12812,8 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
(cmdline_parse_inst_t *)&cmd_config_speed_specific,
(cmdline_parse_inst_t *)&cmd_config_loopback_all,
(cmdline_parse_inst_t *)&cmd_config_loopback_specific,
+   (cmdline_parse_inst_t *)&cmd_config_src_prune_all,
+   (cmdline_parse_inst_t *)&cmd_config_src_prune_specific,
(cmdli

RE: [PATCH v2] net/i40e: support enabling/disabling source pruning

[Morten Brørup]

> From: Ke Zhang [mailto:ke1x.zh...@intel.com]
> Sent: Monday, 30 January 2023 09.09
> 
> VRRP advertisement packets are dropped on i40e PF devices because
> when a MAC address is added to a device, packets originating from
> that MAC address are dropped.
> 
> This patch adds a PMD specific API to enable/disable source
> pruning to fix above issue.
> 
> Bugzilla ID: 648
> 
> Signed-off-by: Ke Zhang 
> ---

This fixes what I considered a bug in the driver, so source pruning is now 
disabled by default. Thank you.

Acked-by: Morten Brørup 

Should rte_pmd_i40e_set_src_prune be added to a maps file? (I'm not sure about 
a PMD specific APIs, so please check.)

RE: [PATCH v7 1/6] eal: trace: add trace point emit for blob

[Sunil Kumar Kori]

> -Original Message-
> From: Morten Brørup 
> Sent: Monday, January 30, 2023 1:45 PM
> To: Sunil Kumar Kori ; Ankur Dwivedi
> ; dev@dpdk.org
> Cc: tho...@monjalon.net; david.march...@redhat.com; m...@ashroe.eu;
> or...@nvidia.com; ferruh.yi...@amd.com; ch...@att.com;
> humi...@huawei.com; linvi...@tuxdriver.com; ciara.lof...@intel.com;
> qi.z.zh...@intel.com; m...@semihalf.com; m...@semihalf.com;
> shaib...@amazon.com; evge...@amazon.com; igo...@amazon.com;
> cha...@amd.com; Igor Russkikh ;
> shepard.sie...@atomicrules.com; ed.cz...@atomicrules.com;
> john.mil...@atomicrules.com; ajit.khapa...@broadcom.com;
> somnath.ko...@broadcom.com; Jerin Jacob Kollanukkaran
> ; Maciej Czekaj [C] ; Shijith
> Thotton ; Srisivasubramanian Srinivasan
> ; Harman Kalra ;
> rahul.lakkire...@chelsio.com; johnd...@cisco.com; hyon...@cisco.com;
> liudongdo...@huawei.com; yisen.zhu...@huawei.com;
> xuanziya...@huawei.com; cloud.wangxiao...@huawei.com;
> zhouguoy...@huawei.com; simei...@intel.com; wenjun1...@intel.com;
> qiming.y...@intel.com; yuying.zh...@intel.com; beilei.x...@intel.com;
> xiao.w.w...@intel.com; jingjing...@intel.com; junfeng@intel.com;
> rosen...@intel.com; Nithin Kumar Dabilpuram
> ; Kiran Kumar Kokkilagadda
> ; Satha Koteswara Rao Kottidi
> ; Liron Himi ;
> z...@semihalf.com; Radha Chintakuntla ;
> Veerasenareddy Burru ; Sathesh B Edara
> ; ma...@nvidia.com; viachesl...@nvidia.com;
> lon...@microsoft.com; spin...@cesnet.cz; chaoyong...@corigine.com;
> niklas.soderl...@corigine.com; hemant.agra...@nxp.com;
> sachin.sax...@oss.nxp.com; g.si...@nxp.com; apeksha.gu...@nxp.com;
> sachin.sax...@nxp.com; abo...@pensando.io; Rasesh Mody
> ; Shahed Shaikh ; Devendra
> Singh Rawat ; andrew.rybche...@oktetlabs.ru;
> jiawe...@trustnetic.com; jianw...@trustnetic.com;
> jbehr...@vmware.com; maxime.coque...@redhat.com;
> chenbo@intel.com; steven.webs...@windriver.com;
> matt.pet...@windriver.com; bruce.richard...@intel.com;
> mtetsu...@gmail.com; gr...@u256.net; jasvinder.si...@intel.com;
> cristian.dumitre...@intel.com; jgraj...@cisco.com; Ankur Dwivedi
> 
> Subject: [EXT] RE: [PATCH v7 1/6] eal: trace: add trace point emit for blob
> 
> External Email
> 
> --
> > From: Sunil Kumar Kori [mailto:sk...@marvell.com]
> > Sent: Monday, 30 January 2023 08.31
> >
> > > From: Ankur Dwivedi 
> > > Sent: Monday, January 23, 2023 2:32 PM
> > >
> 
> [...]
> 
> > > +RTE_TRACE_POINT(
> > > + rte_eal_trace_generic_blob,
> > > + RTE_TRACE_POINT_ARGS(void *in, uint8_t len),
> > > + rte_trace_point_emit_blob(in, len);
> > > +)
> > > +
> >
> > As per documentation rte_eal_trace_generic_blob() will emit 64 bytes
> > only i.e. input array cannot be other than uint8_t.
> > So will it not be better to make it more readable like
> > RTE_TRACE_POINT_ARGS(uint8_t *in, uint8_t len) instead of using void
> > *in.
> 
> No. Using uint8_t* would cause type conversion problems. The advantage of
> using void* is that it is has no type - which is exactly the purpose of a BLOB
> (which is short for Binary Large OBject). We want to be able to pass a pointer
> to e.g. a structure. Using void* makes that directly available.
> 
> I didn't notice before, but the const qualifier is missing. It should be:
> 
> RTE_TRACE_POINT_ARGS(const void *in, uint8_t len),
> 

Makes sense. Ack.

> >
> > Rest is fine. Already acked above.
> >
> > >  #define RTE_EAL_TRACE_GENERIC_FUNC
> > > rte_eal_trace_generic_func(__func__)
> > >
> > >  /* Interrupt */
> >
> > [snipped]
> >
> > > 2.25.1
> >

RE: [PATCH v7 2/6] ethdev: add trace points for ethdev (part one)

[Sunil Kumar Kori]

> -Original Message-
> From: Ankur Dwivedi 
> Sent: Monday, January 23, 2023 2:32 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; david.march...@redhat.com; m...@ashroe.eu;
> or...@nvidia.com; ferruh.yi...@amd.com; ch...@att.com;
> humi...@huawei.com; linvi...@tuxdriver.com; ciara.lof...@intel.com;
> qi.z.zh...@intel.com; m...@semihalf.com; m...@semihalf.com;
> shaib...@amazon.com; evge...@amazon.com; igo...@amazon.com;
> cha...@amd.com; Igor Russkikh ;
> shepard.sie...@atomicrules.com; ed.cz...@atomicrules.com;
> john.mil...@atomicrules.com; ajit.khapa...@broadcom.com;
> somnath.ko...@broadcom.com; Jerin Jacob Kollanukkaran
> ; Maciej Czekaj [C] ; Shijith
> Thotton ; Srisivasubramanian Srinivasan
> ; Harman Kalra ;
> rahul.lakkire...@chelsio.com; johnd...@cisco.com; hyon...@cisco.com;
> liudongdo...@huawei.com; yisen.zhu...@huawei.com;
> xuanziya...@huawei.com; cloud.wangxiao...@huawei.com;
> zhouguoy...@huawei.com; simei...@intel.com; wenjun1...@intel.com;
> qiming.y...@intel.com; yuying.zh...@intel.com; beilei.x...@intel.com;
> xiao.w.w...@intel.com; jingjing...@intel.com; junfeng@intel.com;
> rosen...@intel.com; Nithin Kumar Dabilpuram
> ; Kiran Kumar Kokkilagadda
> ; Sunil Kumar Kori ; Satha
> Koteswara Rao Kottidi ; Liron Himi
> ; z...@semihalf.com; Radha Chintakuntla
> ; Veerasenareddy Burru ;
> Sathesh B Edara ; ma...@nvidia.com;
> viachesl...@nvidia.com; lon...@microsoft.com; spin...@cesnet.cz;
> chaoyong...@corigine.com; niklas.soderl...@corigine.com;
> hemant.agra...@nxp.com; sachin.sax...@oss.nxp.com; g.si...@nxp.com;
> apeksha.gu...@nxp.com; sachin.sax...@nxp.com; abo...@pensando.io;
> Rasesh Mody ; Shahed Shaikh
> ; Devendra Singh Rawat
> ; andrew.rybche...@oktetlabs.ru;
> jiawe...@trustnetic.com; jianw...@trustnetic.com;
> jbehr...@vmware.com; maxime.coque...@redhat.com;
> chenbo@intel.com; steven.webs...@windriver.com;
> matt.pet...@windriver.com; bruce.richard...@intel.com;
> mtetsu...@gmail.com; gr...@u256.net; jasvinder.si...@intel.com;
> cristian.dumitre...@intel.com; jgraj...@cisco.com;
> m...@smartsharesystems.com; Ankur Dwivedi 
> Subject: [PATCH v7 2/6] ethdev: add trace points for ethdev (part one)
> 
> Adds trace points for ethdev functions.
> Moved the rte_ethdev_trace_rx_burst and rte_ethdev_trace_tx_burst to
> a new file rte_ethdev_trace_fp_burst.h. This is needed to resolve
> cyclic dependency between rte_ethdev.h and rte_ethdev_trace_fp.h.
> 
> Signed-off-by: Ankur Dwivedi 
> ---
>  lib/ethdev/ethdev_private.c|   5 +
>  lib/ethdev/ethdev_trace_points.c   | 193 +
>  lib/ethdev/meson.build |   1 +
>  lib/ethdev/rte_ethdev.c| 235 +---
>  lib/ethdev/rte_ethdev.h|   2 +-
>  lib/ethdev/rte_ethdev_trace.h  | 285 +
>  lib/ethdev/rte_ethdev_trace_fp.h   | 279 +++-
>  lib/ethdev/rte_ethdev_trace_fp_burst.h |  44 
>  lib/ethdev/version.map |  66 ++
>  9 files changed, 1075 insertions(+), 35 deletions(-)
>  create mode 100644 lib/ethdev/rte_ethdev_trace_fp_burst.h
> 
Acked-by: Sunil Kumar Kori 

> diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
> index 48090c879a..fd16b25e55 100644
> --- a/lib/ethdev/ethdev_private.c
> +++ b/lib/ethdev/ethdev_private.c
> @@ -5,6 +5,7 @@
>  #include 
> 
>  #include "rte_ethdev.h"
> +#include "rte_ethdev_trace_fp.h"
>  #include "ethdev_driver.h"
>  #include "ethdev_private.h"
> 
> --
> 2.25.1

RE: [PATCH v7 3/6] ethdev: add trace points for ethdev (part two)

[Sunil Kumar Kori]

> -Original Message-
> From: Ankur Dwivedi 
> Sent: Monday, January 23, 2023 2:32 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; david.march...@redhat.com; m...@ashroe.eu;
> or...@nvidia.com; ferruh.yi...@amd.com; ch...@att.com;
> humi...@huawei.com; linvi...@tuxdriver.com; ciara.lof...@intel.com;
> qi.z.zh...@intel.com; m...@semihalf.com; m...@semihalf.com;
> shaib...@amazon.com; evge...@amazon.com; igo...@amazon.com;
> cha...@amd.com; Igor Russkikh ;
> shepard.sie...@atomicrules.com; ed.cz...@atomicrules.com;
> john.mil...@atomicrules.com; ajit.khapa...@broadcom.com;
> somnath.ko...@broadcom.com; Jerin Jacob Kollanukkaran
> ; Maciej Czekaj [C] ; Shijith
> Thotton ; Srisivasubramanian Srinivasan
> ; Harman Kalra ;
> rahul.lakkire...@chelsio.com; johnd...@cisco.com; hyon...@cisco.com;
> liudongdo...@huawei.com; yisen.zhu...@huawei.com;
> xuanziya...@huawei.com; cloud.wangxiao...@huawei.com;
> zhouguoy...@huawei.com; simei...@intel.com; wenjun1...@intel.com;
> qiming.y...@intel.com; yuying.zh...@intel.com; beilei.x...@intel.com;
> xiao.w.w...@intel.com; jingjing...@intel.com; junfeng@intel.com;
> rosen...@intel.com; Nithin Kumar Dabilpuram
> ; Kiran Kumar Kokkilagadda
> ; Sunil Kumar Kori ; Satha
> Koteswara Rao Kottidi ; Liron Himi
> ; z...@semihalf.com; Radha Chintakuntla
> ; Veerasenareddy Burru ;
> Sathesh B Edara ; ma...@nvidia.com;
> viachesl...@nvidia.com; lon...@microsoft.com; spin...@cesnet.cz;
> chaoyong...@corigine.com; niklas.soderl...@corigine.com;
> hemant.agra...@nxp.com; sachin.sax...@oss.nxp.com; g.si...@nxp.com;
> apeksha.gu...@nxp.com; sachin.sax...@nxp.com; abo...@pensando.io;
> Rasesh Mody ; Shahed Shaikh
> ; Devendra Singh Rawat
> ; andrew.rybche...@oktetlabs.ru;
> jiawe...@trustnetic.com; jianw...@trustnetic.com;
> jbehr...@vmware.com; maxime.coque...@redhat.com;
> chenbo@intel.com; steven.webs...@windriver.com;
> matt.pet...@windriver.com; bruce.richard...@intel.com;
> mtetsu...@gmail.com; gr...@u256.net; jasvinder.si...@intel.com;
> cristian.dumitre...@intel.com; jgraj...@cisco.com;
> m...@smartsharesystems.com; Ankur Dwivedi 
> Subject: [PATCH v7 3/6] ethdev: add trace points for ethdev (part two)
> 
> Adds trace points for remaining ethdev functions.
> 
> Signed-off-by: Ankur Dwivedi 
> ---
>  lib/ethdev/ethdev_trace_points.c | 252 +++
>  lib/ethdev/rte_ethdev.c  | 476 ++-
>  lib/ethdev/rte_ethdev_cman.c |  30 +-
>  lib/ethdev/rte_ethdev_trace.h| 529 +++
>  lib/ethdev/rte_ethdev_trace_fp.h | 342 
>  lib/ethdev/version.map   |  81 +
>  6 files changed, 1622 insertions(+), 88 deletions(-)
> 
Acked-by: Sunil Kumar Kori 

> diff --git a/lib/ethdev/ethdev_trace_points.c
> b/lib/ethdev/ethdev_trace_points.c
> index 4fea76e0ff..102a18fcc1 100644
> --- a/lib/ethdev/ethdev_trace_points.c
> +++ b/lib/ethdev/ethdev_trace_points.c
> @@ -222,3 +222,255 @@
> --
> 2.25.1

RE: [PATCH v7 5/6] ethdev: add trace points for mtr

[Sunil Kumar Kori]

> -Original Message-
> From: Ankur Dwivedi 
> Sent: Monday, January 23, 2023 2:32 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; david.march...@redhat.com; m...@ashroe.eu;
> or...@nvidia.com; ferruh.yi...@amd.com; ch...@att.com;
> humi...@huawei.com; linvi...@tuxdriver.com; ciara.lof...@intel.com;
> qi.z.zh...@intel.com; m...@semihalf.com; m...@semihalf.com;
> shaib...@amazon.com; evge...@amazon.com; igo...@amazon.com;
> cha...@amd.com; Igor Russkikh ;
> shepard.sie...@atomicrules.com; ed.cz...@atomicrules.com;
> john.mil...@atomicrules.com; ajit.khapa...@broadcom.com;
> somnath.ko...@broadcom.com; Jerin Jacob Kollanukkaran
> ; Maciej Czekaj [C] ; Shijith
> Thotton ; Srisivasubramanian Srinivasan
> ; Harman Kalra ;
> rahul.lakkire...@chelsio.com; johnd...@cisco.com; hyon...@cisco.com;
> liudongdo...@huawei.com; yisen.zhu...@huawei.com;
> xuanziya...@huawei.com; cloud.wangxiao...@huawei.com;
> zhouguoy...@huawei.com; simei...@intel.com; wenjun1...@intel.com;
> qiming.y...@intel.com; yuying.zh...@intel.com; beilei.x...@intel.com;
> xiao.w.w...@intel.com; jingjing...@intel.com; junfeng@intel.com;
> rosen...@intel.com; Nithin Kumar Dabilpuram
> ; Kiran Kumar Kokkilagadda
> ; Sunil Kumar Kori ; Satha
> Koteswara Rao Kottidi ; Liron Himi
> ; z...@semihalf.com; Radha Chintakuntla
> ; Veerasenareddy Burru ;
> Sathesh B Edara ; ma...@nvidia.com;
> viachesl...@nvidia.com; lon...@microsoft.com; spin...@cesnet.cz;
> chaoyong...@corigine.com; niklas.soderl...@corigine.com;
> hemant.agra...@nxp.com; sachin.sax...@oss.nxp.com; g.si...@nxp.com;
> apeksha.gu...@nxp.com; sachin.sax...@nxp.com; abo...@pensando.io;
> Rasesh Mody ; Shahed Shaikh
> ; Devendra Singh Rawat
> ; andrew.rybche...@oktetlabs.ru;
> jiawe...@trustnetic.com; jianw...@trustnetic.com;
> jbehr...@vmware.com; maxime.coque...@redhat.com;
> chenbo@intel.com; steven.webs...@windriver.com;
> matt.pet...@windriver.com; bruce.richard...@intel.com;
> mtetsu...@gmail.com; gr...@u256.net; jasvinder.si...@intel.com;
> cristian.dumitre...@intel.com; jgraj...@cisco.com;
> m...@smartsharesystems.com; Ankur Dwivedi 
> Subject: [PATCH v7 5/6] ethdev: add trace points for mtr
> 
> Adds trace points for rte_mtr specific functions in ethdev lib.
> 
> Signed-off-by: Ankur Dwivedi 
> ---
>  lib/ethdev/ethdev_trace_points.c |  63 +
>  lib/ethdev/rte_ethdev_trace.h| 112 ++
>  lib/ethdev/rte_ethdev_trace_fp.h | 100 
>  lib/ethdev/rte_mtr.c | 156 +++
>  lib/ethdev/version.map   |  21 +
>  5 files changed, 434 insertions(+), 18 deletions(-)
> 

Acked-by: Sunil Kumar Kori 

> diff --git a/lib/ethdev/ethdev_trace_points.c
> b/lib/ethdev/ethdev_trace_points.c
> index 1953d90a5a..067e5fdab4 100644
> --- a/lib/ethdev/ethdev_trace_points.c
> +++ b/lib/ethdev/ethdev_trace_points.c
> @@ -591,3 +591,66 @@
> --
> 2.25.1

Re: [PATCH v2] net/i40e: support enabling/disabling source pruning

[David Marchand]

On Mon, Jan 30, 2023 at 9:23 AM Ke Zhang  wrote:
>
> VRRP advertisement packets are dropped on i40e PF devices because
> when a MAC address is added to a device, packets originating from
> that MAC address are dropped.
>
> This patch adds a PMD specific API to enable/disable source
> pruning to fix above issue.
>
> Bugzilla ID: 648
>
> Signed-off-by: Ke Zhang 
> ---
>  app/test-pmd/cmdline.c  | 84 +
>  drivers/net/i40e/i40e_ethdev.c  | 43 +
>  drivers/net/i40e/i40e_ethdev.h  |  1 +
>  drivers/net/i40e/rte_pmd_i40e.c | 20 
>  drivers/net/i40e/rte_pmd_i40e.h | 16 +++
>  5 files changed, 164 insertions(+)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index cb8c174020..76a574affd 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -776,6 +776,9 @@ static void cmd_help_long_parsed(void *parsed_result,
>
> "port cleanup (port_id) txq (queue_id) (free_cnt)\n"
> "Cleanup txq mbufs for a specific Tx queue\n\n"
> +
> +   "port config (port_id|all) src_prune (on|off)\n"
> +   "Set source prune on port_id, or all.\n\n"
> );
> }
>

- This seems i40e specific, please move to drivers/net/i40e/i40e_testpmd.c.

- Besides, I would prefer that something in the command name clearly
states this is driver (here, i40e) specific.
Like "port config XX i40e_src_prune" or maybe the other way around,
start with a "driver i40e" prefix.

Maybe others have an opinion.


-- 
David Marchand

Re: [PATCH v3] app/dma-perf: introduce dma-perf application

[Bruce Richardson]

On Sat, Jan 28, 2023 at 01:32:05PM +, Jiang, Cheng1 wrote:
> Hi Bruce,
> 
> Sorry for the late reply. We are in the Spring Festival holiday last week.
> Thanks for your comments.
> Replies are inline.
> 
> Thanks,
> Cheng
> 
> > -Original Message-
> > From: Richardson, Bruce 
> > Sent: Wednesday, January 18, 2023 12:52 AM
> > To: Jiang, Cheng1 
> > Cc: tho...@monjalon.net; m...@smartsharesystems.com; dev@dpdk.org; Hu,
> > Jiayu ; Ding, Xuan ; Ma, WenwuX
> > ; Wang, YuanX ; He,
> > Xingguang 
> > Subject: Re: [PATCH v3] app/dma-perf: introduce dma-perf application
> > 
> > On Tue, Jan 17, 2023 at 12:05:26PM +, Cheng Jiang wrote:
> > > There are many high-performance DMA devices supported in DPDK now, and
> > > these DMA devices can also be integrated into other modules of DPDK as
> > > accelerators, such as Vhost. Before integrating DMA into applications,
> > > developers need to know the performance of these DMA devices in
> > > various scenarios and the performance of CPUs in the same scenario,
> > > such as different buffer lengths. Only in this way can we know the
> > > target performance of the application accelerated by using them. This
> > > patch introduces a high-performance testing tool, which supports
> > > comparing the performance of CPU and DMA in different scenarios
> > > automatically with a pre-set config file. Memory Copy performance test are
> > supported for now.
> > >
> > > Signed-off-by: Cheng Jiang 
> > > Signed-off-by: Jiayu Hu 
> > > Signed-off-by: Yuan Wang 
> > > Acked-by: Morten Brørup 
> > > ---
> > 
> > More input based off trying running the application, including some 
> > thoughts on
> > the testing methodology below.
> > 
> > 
> > > +static void
> > > +output_result(uint8_t scenario_id, uint32_t lcore_id, uint16_t dev_id,
> > uint64_t ave_cycle,
> > > + uint32_t buf_size, uint32_t nr_buf, uint32_t memory,
> > > + float bandwidth, uint64_t ops, bool is_dma) {
> > > + if (is_dma)
> > > + printf("lcore %u, DMA %u:\n"
> > > + "average cycles: %" PRIu64 ","
> > > + " buffer size: %u, nr_buf: %u,"
> > > + " memory: %uMB, frequency: %" PRIu64 ".\n",
> > > + lcore_id,
> > > + dev_id,
> > > + ave_cycle,
> > > + buf_size,
> > > + nr_buf,
> > > + memory,
> > > + rte_get_timer_hz());
> > > + else
> > > + printf("lcore %u\n"
> > > + "average cycles: %" PRIu64 ","
> > > + " buffer size: %u, nr_buf: %u,"
> > > + " memory: %uMB, frequency: %" PRIu64 ".\n",
> > > + lcore_id,
> > > + ave_cycle,
> > > + buf_size,
> > > + nr_buf,
> > > + memory,
> > > + rte_get_timer_hz());
> > > +
> > 
> > The term "average cycles" is unclear here - is it average cycles per test 
> > iteration,
> > or average cycles per buffer copy?
> 
> The average cycles stands for average cycles per buffer copy, I'll clarify it 
> in the next version.
> 
> > 
> > 
> > > + printf("Average bandwidth: %.3lfGbps, OPS: %" PRIu64 "\n",
> > > +bandwidth, ops);
> > > +
> > 
> > 
> > 
> > > +
> > > +static inline void
> > > +do_dma_mem_copy(uint16_t dev_id, uint32_t nr_buf, uint16_t kick_batch,
> > uint32_t buf_size,
> > > + uint16_t mpool_iter_step, struct rte_mbuf **srcs,
> > struct rte_mbuf
> > > +**dsts) {
> > > + int64_t async_cnt = 0;
> > > + int nr_cpl = 0;
> > > + uint32_t index;
> > > + uint16_t offset;
> > > + uint32_t i;
> > > +
> > > + for (offset = 0; offset < mpool_iter_step; offset++) {
> > > + for (i = 0; index = i * mpool_iter_step + offset, index < 
> > > nr_buf;
> > i++) {
> > > + if (unlikely(rte_dma_copy(dev_id,
> > > + 0,
> > > + srcs[index]->buf_iova +
> > srcs[index]->data_off,
> > > + dsts[index]->buf_iova +
> > dsts[index]->data_off,
> > > + buf_size,
> > > + 0) < 0)) {
> > > + rte_dma_submit(dev_id, 0);
> > > + while (rte_dma_burst_capacity(dev_id, 0) == 0)
> > {
> > > + nr_cpl = rte_dma_completed(dev_id, 0,
> > MAX_DMA_CPL_NB,
> > > + NULL, NULL);
> > > + async_cnt -= nr_cpl;
> > > + }
> > > + if (rte_dma_copy(dev_id,
> > > + 0,
> > > + srcs[index]->buf_iova +
> > srcs[index]->data_off,
> > > + dsts[

[RFC] config: customize max memzones configuration

[Ophir Munk]

In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard
coded as 2560.  For applications requiring different values of this
parameter – it is more convenient to set its value as part of the meson
command line or to set the max value via an rte API - rather than
changing the dpdk source code per application.

An example would be of an application that uses the DPDK mempool library
which is based on DPDK memzone library.  The application may need to
create a number of steering tables, each of which will require its own
mempool allocation.  This RFC is not about how to optimize the
application usage of mempool nor about how to improve the mempool
implementation based on memzone.  It is about how to make the max
memzone definition - build-time or run-time customized.

I would like to suggest three options.

Option 1

Add a Meson option in meson options.txt and remove the
RTE_MAX_MEMZONE definition from config/rte_config.h

For example,

 config/meson.build

 # set other values pulled from the build options
 dpdk_conf.set('RTE_MAX_LCORE', get_option('max_lcores'))
 +dpdk_conf.set('RTE_MAX_MEMZONE', get_option('max_memzones'))
 dpdk_conf.set('RTE_MAX_NUMA_NODES', get_option('max_numa_nodes'))

 meson_options.txt

 option('max_lcores', type: 'integer', value: 128,
description: 'maximum number of cores/threads supported by EAL')
 +option('max_memzones', type: 'integer', value: 2560,
 +   description: 'maximum number of memory zones supported by EAL')
 option('max_numa_nodes', type: 'integer', value: 32,
description: 'maximum number of NUMA nodes supported by EAL')

 config/rte_config.h

 #define RTE_MAX_MEM_MB_PER_TYPE 65536
 -#define RTE_MAX_MEMZONE 2560
 #define RTE_MAX_TAILQ 32

Option 2

Use Meson setup -Dc_args="-DRTE_MAX_MEMZONE=XXX" and
make RTE_MAX_MEMZONE conditional in config/rte_config.h

For example, see the code of this commit.

Option 3

Add a function which must be called before rte_eal_init():
void rte_memzone_set_max(int max) {memzone_max = max;}
If not called, the default memzone (RTE_MAX_MEMZONE) is used.

With this option there is no need to recompile DPDK and it allows
using an in-box packaged DPDK.

Signed-off-by: Ophir Munk 
---
 config/rte_config.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/config/rte_config.h b/config/rte_config.h
index fed174a..ca653cc 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -35,7 +35,9 @@
 #define RTE_MAX_MEM_MB_PER_LIST 32768
 #define RTE_MAX_MEMSEG_PER_TYPE 32768
 #define RTE_MAX_MEM_MB_PER_TYPE 65536
+#ifndef RTE_MAX_MEMZONE
 #define RTE_MAX_MEMZONE 2560
+#endif
 #define RTE_MAX_TAILQ 32
 #define RTE_LOG_DP_LEVEL RTE_LOG_INFO
 #define RTE_BACKTRACE 1
-- 
2.8.4

[PATCH V2 01/10] net/hns3: fix error log about indirection table size

[Dongdong Liu]

From: Huisong Li 

The error log about indirection table size during initialization phase
of PF and VF is unreasonable when the indirection table size obtained
from firmware or PF function should be zero. In addition, VF driver
should use error level to print this log.

Fixes: 0fce2c46dc16 ("net/hns3: fix RSS indirection table size")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_ethdev.c| 2 +-
 drivers/net/hns3/hns3_ethdev_vf.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index d326f70129..eb809cd8c9 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2679,7 +2679,7 @@ hns3_check_dev_specifications(struct hns3_hw *hw)
 {
if (hw->rss_ind_tbl_size == 0 ||
hw->rss_ind_tbl_size > HNS3_RSS_IND_TBL_SIZE_MAX) {
-   hns3_err(hw, "the size of hash lookup table configured (%u) 
exceeds the maximum(%u)",
+   hns3_err(hw, "the indirection table size obtained (%u) is 
invalid, and should not be zero or exceed the maximum(%u)",
 hw->rss_ind_tbl_size, HNS3_RSS_IND_TBL_SIZE_MAX);
return -EINVAL;
}
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c 
b/drivers/net/hns3/hns3_ethdev_vf.c
index d220522c43..e43815607a 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -718,8 +718,8 @@ hns3vf_check_dev_specifications(struct hns3_hw *hw)
 {
if (hw->rss_ind_tbl_size == 0 ||
hw->rss_ind_tbl_size > HNS3_RSS_IND_TBL_SIZE_MAX) {
-   hns3_warn(hw, "the size of hash lookup table configured (%u) 
exceeds the maximum(%u)",
- hw->rss_ind_tbl_size, HNS3_RSS_IND_TBL_SIZE_MAX);
+   hns3_err(hw, "the indirection table size obtained (%u) is 
invalid, and should not be zero or exceed the maximum(%u)",
+hw->rss_ind_tbl_size, HNS3_RSS_IND_TBL_SIZE_MAX);
return -EINVAL;
}
 
-- 
2.22.0

[PATCH V2 00/10] net/hns3: some bugfixes for rss

[Dongdong Liu]

This patchset is to do some bugfixes for hns3 rss.

v1->v2:
- Fix missing comparison of types and level when verifying duplicate
  rules for [PATCH 10/10].

Huisong Li (10):
  net/hns3: fix error log about indirection table size
  net/hns3: extract common API to query device
  net/hns3: refactor set RSS hash algorithm and key interface
  net/hns3: fix fixed RSS key size to be more compatibility
  net/hns3: fix misclearing RSS configuration
  net/hns3: using RSS filter list to check duplicated rule
  net/hns3: remove useless code when destroy valid RSS rule
  net/hns3: fix useless warning when flush or destroy rule
  net/hns3: fix bad memory structure conversion
  net/hns3: fix incorrect check for duplicate RSS rule

 drivers/net/hns3/hns3_common.c|  87 +++-
 drivers/net/hns3/hns3_common.h|   2 +
 drivers/net/hns3/hns3_ethdev.c|  63 -
 drivers/net/hns3/hns3_ethdev_vf.c |  65 +
 drivers/net/hns3/hns3_flow.c  | 222 +++---
 drivers/net/hns3/hns3_rss.c   |  63 -
 drivers/net/hns3/hns3_rss.h   |   7 +-
 7 files changed, 232 insertions(+), 277 deletions(-)

--
2.22.0

[PATCH V2 04/10] net/hns3: fix fixed RSS key size to be more compatibility

[Dongdong Liu]

From: Huisong Li 

For better compatibility, the RSS key size of PF and VF are obtained from
firmware. However, many places still used the old macro HNS3_RSS_KEY_SIZE
as the key size.

Fixes: 9c740336f024 ("net/hns3: get device specifications from firmware")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_common.c | 12 +++-
 drivers/net/hns3/hns3_flow.c   | 26 --
 drivers/net/hns3/hns3_rss.c| 23 +++
 drivers/net/hns3/hns3_rss.h|  3 ++-
 4 files changed, 36 insertions(+), 28 deletions(-)

diff --git a/drivers/net/hns3/hns3_common.c b/drivers/net/hns3/hns3_common.c
index b0c7f8d62c..2da0f30964 100644
--- a/drivers/net/hns3/hns3_common.c
+++ b/drivers/net/hns3/hns3_common.c
@@ -129,7 +129,7 @@ hns3_dev_infos_get(struct rte_eth_dev *eth_dev, struct 
rte_eth_dev_info *info)
};
 
info->reta_size = hw->rss_ind_tbl_size;
-   info->hash_key_size = HNS3_RSS_KEY_SIZE;
+   info->hash_key_size = hw->rss_key_size;
info->flow_type_rss_offloads = HNS3_ETH_RSS_SUPPORT;
 
info->default_rxportconf.burst_size = HNS3_DEFAULT_PORT_CONF_BURST_SIZE;
@@ -895,6 +895,16 @@ hns3_check_dev_specifications(struct hns3_hw *hw)
return -EINVAL;
}
 
+   if (hw->rss_key_size == 0 || hw->rss_key_size > HNS3_RSS_KEY_SIZE_MAX) {
+   hns3_err(hw, "the RSS key size obtained (%u) is invalid, and 
should not be zero or exceed the maximum(%u)",
+hw->rss_key_size, HNS3_RSS_KEY_SIZE_MAX);
+   return -EINVAL;
+   }
+
+   if (hw->rss_key_size > HNS3_RSS_KEY_SIZE)
+   hns3_warn(hw, "the RSS key size obtained (%u) is greater than 
the default key size (%u)",
+ hw->rss_key_size, HNS3_RSS_KEY_SIZE);
+
return 0;
 }
 
diff --git a/drivers/net/hns3/hns3_flow.c b/drivers/net/hns3/hns3_flow.c
index 95609f8483..a18ec7650d 100644
--- a/drivers/net/hns3/hns3_flow.c
+++ b/drivers/net/hns3/hns3_flow.c
@@ -1406,10 +1406,10 @@ hns3_parse_rss_filter(struct rte_eth_dev *dev,
return rte_flow_error_set(error, ENOTSUP,
  RTE_FLOW_ERROR_TYPE_ACTION_CONF, act,
  "a nonzero RSS encapsulation level is 
not supported");
-   if (rss->key_len && rss->key_len != RTE_DIM(rss_conf->key))
+   if (rss->key_len && rss->key_len != hw->rss_key_size)
return rte_flow_error_set(error, ENOTSUP,
  RTE_FLOW_ERROR_TYPE_ACTION_CONF, act,
- "RSS hash key must be exactly 40 
bytes");
+ "invalid RSS key length");
 
if (!hns3_rss_input_tuple_supported(hw, rss))
return rte_flow_error_set(error, EINVAL,
@@ -1443,16 +1443,6 @@ hns3_disable_rss(struct hns3_hw *hw)
return 0;
 }
 
-static void
-hns3_adjust_rss_key(struct hns3_hw *hw, struct rte_flow_action_rss *rss_conf)
-{
-   if (rss_conf->key == NULL || rss_conf->key_len < HNS3_RSS_KEY_SIZE) {
-   hns3_warn(hw, "Default RSS hash key to be set");
-   rss_conf->key = hns3_hash_key;
-   rss_conf->key_len = HNS3_RSS_KEY_SIZE;
-   }
-}
-
 static int
 hns3_parse_rss_algorithm(struct hns3_hw *hw, enum rte_eth_hash_function *func,
 uint8_t *hash_algo)
@@ -1485,9 +1475,16 @@ hns3_parse_rss_algorithm(struct hns3_hw *hw, enum 
rte_eth_hash_function *func,
 static int
 hns3_hw_rss_hash_set(struct hns3_hw *hw, struct rte_flow_action_rss 
*rss_config)
 {
+   uint8_t rss_key[HNS3_RSS_KEY_SIZE_MAX] = {0};
+   bool use_default_key = false;
int ret;
 
-   hns3_adjust_rss_key(hw, rss_config);
+   if (rss_config->key == NULL || rss_config->key_len != hw->rss_key_size) 
{
+   hns3_warn(hw, "Default RSS hash key to be set");
+   memcpy(rss_key, hns3_hash_key,
+   RTE_MIN(sizeof(hns3_hash_key), hw->rss_key_size));
+   use_default_key = true;
+   }
 
ret = hns3_parse_rss_algorithm(hw, &rss_config->func,
   &hw->rss_info.hash_algo);
@@ -1495,7 +1492,8 @@ hns3_hw_rss_hash_set(struct hns3_hw *hw, struct 
rte_flow_action_rss *rss_config)
return ret;
 
ret = hns3_rss_set_algo_key(hw, hw->rss_info.hash_algo,
-   rss_config->key, HNS3_RSS_KEY_SIZE);
+   use_default_key ? rss_key : rss_config->key,
+   hw->rss_key_size);
if (ret)
return ret;
 
diff --git a/drivers/net/hns3/hns3_rss.c b/drivers/net/hns3/hns3_rss.c
index 3db7bf0445..d6e0754273 100644
--- a/drivers/net/hns3/hns3_rss.c
+++ b/drivers/net/hns3/hns3_rss.c
@@ -316,7 +316,7 @@ hns3_rss_set_algo_key(struct hns3_hw *hw, uint8_t hash_algo,
   

[PATCH V2 03/10] net/hns3: refactor set RSS hash algorithm and key interface

[Dongdong Liu]

From: Huisong Li 

The hns3_rss_set_algo_key() is used to set RSS hash algorithm and key to
hardware. The maximum times of command sent to firmware depend on the
length of key. However, now this times is fixed, which isn't good for
key expansion. In addition, hash algorithm comes from rss_info::hash_algo
maintained in driver, which also isn't good for the usage of this function.
This patch has to use hash algorithm and key length as the input parameters
of this interface.

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_flow.c |  3 ++-
 drivers/net/hns3/hns3_rss.c  | 48 
 drivers/net/hns3/hns3_rss.h  |  4 ++-
 3 files changed, 26 insertions(+), 29 deletions(-)

diff --git a/drivers/net/hns3/hns3_flow.c b/drivers/net/hns3/hns3_flow.c
index a2c1589c39..95609f8483 100644
--- a/drivers/net/hns3/hns3_flow.c
+++ b/drivers/net/hns3/hns3_flow.c
@@ -1494,7 +1494,8 @@ hns3_hw_rss_hash_set(struct hns3_hw *hw, struct 
rte_flow_action_rss *rss_config)
if (ret)
return ret;
 
-   ret = hns3_rss_set_algo_key(hw, rss_config->key);
+   ret = hns3_rss_set_algo_key(hw, hw->rss_info.hash_algo,
+   rss_config->key, HNS3_RSS_KEY_SIZE);
if (ret)
return ret;
 
diff --git a/drivers/net/hns3/hns3_rss.c b/drivers/net/hns3/hns3_rss.c
index ca5a129234..3db7bf0445 100644
--- a/drivers/net/hns3/hns3_rss.c
+++ b/drivers/net/hns3/hns3_rss.c
@@ -277,45 +277,37 @@ static const struct {
 
 /*
  * rss_generic_config command function, opcode:0x0D01.
- * Used to set algorithm, key_offset and hash key of rss.
+ * Used to set algorithm and hash key of RSS.
  */
 int
-hns3_rss_set_algo_key(struct hns3_hw *hw, const uint8_t *key)
+hns3_rss_set_algo_key(struct hns3_hw *hw, uint8_t hash_algo,
+ const uint8_t *key, uint8_t key_len)
 {
-#define HNS3_KEY_OFFSET_MAX3
-#define HNS3_SET_HASH_KEY_BYTE_FOUR2
-
struct hns3_rss_generic_config_cmd *req;
struct hns3_cmd_desc desc;
-   uint32_t key_offset, key_size;
-   const uint8_t *key_cur;
-   uint8_t cur_offset;
+   const uint8_t *cur_key;
+   uint16_t cur_key_size;
+   uint16_t max_bd_num;
+   uint16_t idx;
int ret;
 
req = (struct hns3_rss_generic_config_cmd *)desc.data;
 
-   /*
-* key_offset=0, hash key byte0~15 is set to hardware.
-* key_offset=1, hash key byte16~31 is set to hardware.
-* key_offset=2, hash key byte32~39 is set to hardware.
-*/
-   for (key_offset = 0; key_offset < HNS3_KEY_OFFSET_MAX; key_offset++) {
+   max_bd_num = DIV_ROUND_UP(key_len, HNS3_RSS_HASH_KEY_NUM);
+   for (idx = 0; idx < max_bd_num; idx++) {
hns3_cmd_setup_basic_desc(&desc, HNS3_OPC_RSS_GENERIC_CONFIG,
  false);
 
-   req->hash_config |=
-   (hw->rss_info.hash_algo & HNS3_RSS_HASH_ALGO_MASK);
-   req->hash_config |= (key_offset << HNS3_RSS_HASH_KEY_OFFSET_B);
+   req->hash_config |= (hash_algo & HNS3_RSS_HASH_ALGO_MASK);
+   req->hash_config |= (idx << HNS3_RSS_HASH_KEY_OFFSET_B);
 
-   if (key_offset == HNS3_SET_HASH_KEY_BYTE_FOUR)
-   key_size = HNS3_RSS_KEY_SIZE - HNS3_RSS_HASH_KEY_NUM *
-   HNS3_SET_HASH_KEY_BYTE_FOUR;
+   if (idx == max_bd_num - 1)
+   cur_key_size = key_len % HNS3_RSS_HASH_KEY_NUM;
else
-   key_size = HNS3_RSS_HASH_KEY_NUM;
+   cur_key_size = HNS3_RSS_HASH_KEY_NUM;
 
-   cur_offset = key_offset * HNS3_RSS_HASH_KEY_NUM;
-   key_cur = key + cur_offset;
-   memcpy(req->hash_key, key_cur, key_size);
+   cur_key = key + idx * HNS3_RSS_HASH_KEY_NUM;
+   memcpy(req->hash_key, cur_key, cur_key_size);
 
ret = hns3_cmd_send(hw, &desc, 1);
if (ret) {
@@ -518,7 +510,8 @@ hns3_dev_rss_hash_update(struct rte_eth_dev *dev,
goto set_tuple_fail;
 
if (key) {
-   ret = hns3_rss_set_algo_key(hw, key);
+   ret = hns3_rss_set_algo_key(hw, hw->rss_info.hash_algo,
+   key, HNS3_RSS_KEY_SIZE);
if (ret)
goto set_algo_key_fail;
}
@@ -795,8 +788,9 @@ hns3_config_rss(struct hns3_adapter *hns)
break;
}
 
-   /* Configure RSS hash algorithm and hash key offset */
-   ret = hns3_rss_set_algo_key(hw, hash_key);
+   /* Configure RSS hash algorithm and hash key */
+   ret = hns3_rss_set_algo_key(hw, hw->rss_info.hash_algo, hash_key,
+   HNS3_RSS_KEY_SIZE);
if (ret)
return ret;
 
diff --git a/drivers/n

[PATCH V2 02/10] net/hns3: extract common API to query device

[Dongdong Liu]

From: Huisong Li 

Extract common function to query device specifications.

Fixes: 9c740336f024 ("net/hns3: get device specifications from firmware")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_common.c| 75 +++
 drivers/net/hns3/hns3_common.h|  2 +
 drivers/net/hns3/hns3_ethdev.c| 63 --
 drivers/net/hns3/hns3_ethdev_vf.c | 65 +--
 4 files changed, 79 insertions(+), 126 deletions(-)

diff --git a/drivers/net/hns3/hns3_common.c b/drivers/net/hns3/hns3_common.c
index 7adc6a4972..b0c7f8d62c 100644
--- a/drivers/net/hns3/hns3_common.c
+++ b/drivers/net/hns3/hns3_common.c
@@ -10,6 +10,7 @@
 #include "hns3_logs.h"
 #include "hns3_regs.h"
 #include "hns3_rxtx.h"
+#include "hns3_dcb.h"
 #include "hns3_common.h"
 
 int
@@ -845,3 +846,77 @@ hns3_get_pci_revision_id(struct hns3_hw *hw, uint8_t 
*revision_id)
 
return 0;
 }
+
+void
+hns3_set_default_dev_specifications(struct hns3_hw *hw)
+{
+   struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
+
+   hw->max_non_tso_bd_num = HNS3_MAX_NON_TSO_BD_PER_PKT;
+   hw->rss_ind_tbl_size = HNS3_RSS_IND_TBL_SIZE;
+   hw->rss_key_size = HNS3_RSS_KEY_SIZE;
+   hw->intr.int_ql_max = HNS3_INTR_QL_NONE;
+
+   if (hns->is_vf)
+   return;
+
+   hw->max_tm_rate = HNS3_ETHER_MAX_RATE;
+}
+
+static void
+hns3_parse_dev_specifications(struct hns3_hw *hw, struct hns3_cmd_desc *desc)
+{
+   struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
+   struct hns3_dev_specs_0_cmd *req0;
+   struct hns3_dev_specs_1_cmd *req1;
+
+   req0 = (struct hns3_dev_specs_0_cmd *)desc[0].data;
+   req1 = (struct hns3_dev_specs_1_cmd *)desc[1].data;
+
+   hw->max_non_tso_bd_num = req0->max_non_tso_bd_num;
+   hw->rss_ind_tbl_size = rte_le_to_cpu_16(req0->rss_ind_tbl_size);
+   hw->rss_key_size = rte_le_to_cpu_16(req0->rss_key_size);
+   hw->intr.int_ql_max = rte_le_to_cpu_16(req0->intr_ql_max);
+   hw->min_tx_pkt_len = req1->min_tx_pkt_len;
+
+   if (hns->is_vf)
+   return;
+
+   hw->max_tm_rate = rte_le_to_cpu_32(req0->max_tm_rate);
+}
+
+static int
+hns3_check_dev_specifications(struct hns3_hw *hw)
+{
+   if (hw->rss_ind_tbl_size == 0 ||
+   hw->rss_ind_tbl_size > HNS3_RSS_IND_TBL_SIZE_MAX) {
+   hns3_err(hw, "the indirection table size obtained (%u) is 
invalid, and should not be zero or exceed the maximum(%u)",
+hw->rss_ind_tbl_size, HNS3_RSS_IND_TBL_SIZE_MAX);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+int
+hns3_query_dev_specifications(struct hns3_hw *hw)
+{
+   struct hns3_cmd_desc desc[HNS3_QUERY_DEV_SPECS_BD_NUM];
+   int ret;
+   int i;
+
+   for (i = 0; i < HNS3_QUERY_DEV_SPECS_BD_NUM - 1; i++) {
+   hns3_cmd_setup_basic_desc(&desc[i], HNS3_OPC_QUERY_DEV_SPECS,
+ true);
+   desc[i].flag |= rte_cpu_to_le_16(HNS3_CMD_FLAG_NEXT);
+   }
+   hns3_cmd_setup_basic_desc(&desc[i], HNS3_OPC_QUERY_DEV_SPECS, true);
+
+   ret = hns3_cmd_send(hw, desc, HNS3_QUERY_DEV_SPECS_BD_NUM);
+   if (ret)
+   return ret;
+
+   hns3_parse_dev_specifications(hw, desc);
+
+   return hns3_check_dev_specifications(hw);
+}
diff --git a/drivers/net/hns3/hns3_common.h b/drivers/net/hns3/hns3_common.h
index 5aa001f0cc..8eaeda26e7 100644
--- a/drivers/net/hns3/hns3_common.h
+++ b/drivers/net/hns3/hns3_common.h
@@ -60,5 +60,7 @@ void hns3_unmap_rx_interrupt(struct rte_eth_dev *dev);
 int hns3_restore_rx_interrupt(struct hns3_hw *hw);
 
 int hns3_get_pci_revision_id(struct hns3_hw *hw, uint8_t *revision_id);
+void hns3_set_default_dev_specifications(struct hns3_hw *hw);
+int hns3_query_dev_specifications(struct hns3_hw *hw);
 
 #endif /* HNS3_COMMON_H */
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index eb809cd8c9..ab565ce128 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -2647,69 +2647,6 @@ hns3_parse_speed(int speed_cmd, uint32_t *speed)
return 0;
 }
 
-static void
-hns3_set_default_dev_specifications(struct hns3_hw *hw)
-{
-   hw->max_non_tso_bd_num = HNS3_MAX_NON_TSO_BD_PER_PKT;
-   hw->rss_ind_tbl_size = HNS3_RSS_IND_TBL_SIZE;
-   hw->rss_key_size = HNS3_RSS_KEY_SIZE;
-   hw->max_tm_rate = HNS3_ETHER_MAX_RATE;
-   hw->intr.int_ql_max = HNS3_INTR_QL_NONE;
-}
-
-static void
-hns3_parse_dev_specifications(struct hns3_hw *hw, struct hns3_cmd_desc *desc)
-{
-   struct hns3_dev_specs_0_cmd *req0;
-   struct hns3_dev_specs_1_cmd *req1;
-
-   req0 = (struct hns3_dev_specs_0_cmd *)desc[0].data;
-   req1 = (struct hns3_dev_specs_1_cmd *)desc[1].data;
-
-   hw->max_non_tso_bd_num = req0->max_non_tso_bd_num;
-   hw->rss_ind_tbl_size = rte_le_to_cpu_16(req0->rss_ind_tbl_size);
-   

[PATCH V2 05/10] net/hns3: fix misclearing RSS configuration

[Dongdong Liu]

From: Huisong Li 

The RSS configuration will be miscleared when driver receives a RSS rule
which has more one RSS action.

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_flow.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/hns3/hns3_flow.c b/drivers/net/hns3/hns3_flow.c
index a18ec7650d..c338eab049 100644
--- a/drivers/net/hns3/hns3_flow.c
+++ b/drivers/net/hns3/hns3_flow.c
@@ -1421,12 +1421,10 @@ hns3_parse_rss_filter(struct rte_eth_dev *dev,
 
/* Check if the next not void action is END */
NEXT_ITEM_OF_ACTION(act, actions, act_index);
-   if (act->type != RTE_FLOW_ACTION_TYPE_END) {
-   memset(rss_conf, 0, sizeof(struct hns3_rss_conf));
+   if (act->type != RTE_FLOW_ACTION_TYPE_END)
return rte_flow_error_set(error, EINVAL,
  RTE_FLOW_ERROR_TYPE_ACTION,
  act, "Not supported action.");
-   }
 
return 0;
 }
-- 
2.22.0

[PATCH V2 08/10] net/hns3: fix useless warning when flush or destroy rule

[Dongdong Liu]

From: Huisong Li 

The types of the rule will no longer be used when user flush all rules or
destroy a rule. But user would receive some RSS types warnings, like,
"modified RSS types based on hardware support, requested:0x137f83fffc
configured:0x3ffc".

Fixes: ec674cb742e5 ("net/hns3: fix flushing RSS rule")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_flow.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/net/hns3/hns3_flow.c b/drivers/net/hns3/hns3_flow.c
index 7adde16cbc..fbc38dd3d4 100644
--- a/drivers/net/hns3/hns3_flow.c
+++ b/drivers/net/hns3/hns3_flow.c
@@ -1537,17 +1537,6 @@ hns3_config_rss_filter(struct hns3_hw *hw,
.queue = conf->conf.queue,
};
 
-   /* Filter the unsupported flow types */
-   flow_types = conf->conf.types ?
-rss_flow_conf.types & HNS3_ETH_RSS_SUPPORT :
-hw->rss_info.conf.types;
-   if (flow_types != rss_flow_conf.types)
-   hns3_warn(hw, "modified RSS types based on hardware support, "
- "requested:0x%" PRIx64 " configured:0x%" PRIx64,
- rss_flow_conf.types, flow_types);
-   /* Update the useful flow types */
-   rss_flow_conf.types = flow_types;
-
if (!add) {
if (!conf->valid)
return 0;
@@ -1573,6 +1562,17 @@ hns3_config_rss_filter(struct hns3_hw *hw,
return ret;
}
 
+   /* Filter the unsupported flow types */
+   flow_types = conf->conf.types ?
+rss_flow_conf.types & HNS3_ETH_RSS_SUPPORT :
+hw->rss_info.conf.types;
+   if (flow_types != rss_flow_conf.types)
+   hns3_warn(hw, "modified RSS types based on hardware support,"
+ " requested:0x%" PRIx64 " configured:0x%" PRIx64,
+ rss_flow_conf.types, flow_types);
+   /* Update the useful flow types */
+   rss_flow_conf.types = flow_types;
+
/* Set hash algorithm and flow types by the user's config */
return hns3_hw_rss_hash_set(hw, &rss_flow_conf);
 }
-- 
2.22.0

[PATCH V2 07/10] net/hns3: remove useless code when destroy valid RSS rule

[Dongdong Liu]

From: Huisong Li 

The hw::rss_info::conf::func was set to the macro RTE_ETH_HASH_FUNCTION_MAX
and hw::rss_info::conf::queue was set to NULL when all rules are flushed,
which indicates no flow rules is issued. See
commit eb158fc756a5 ("net/hns3: fix config when creating RSS rule after
flush").
Actually, the way determining whether there are rules has been changed by
walking the flow RSS list. See
commit 705a50800334 ("net/hns3: fix RSS filter restore").

In addition, the rte_flow_action_rss from user isn't saved to 'conf' in
hw->rss_info now. So this code can be removed.

Fixes: eb158fc756a5 ("net/hns3: fix config when creating RSS rule after flush")
Fixes: 705a50800334 ("net/hns3: fix RSS filter restore")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_flow.c | 26 ++
 1 file changed, 2 insertions(+), 24 deletions(-)

diff --git a/drivers/net/hns3/hns3_flow.c b/drivers/net/hns3/hns3_flow.c
index 303275ae93..7adde16cbc 100644
--- a/drivers/net/hns3/hns3_flow.c
+++ b/drivers/net/hns3/hns3_flow.c
@@ -1279,19 +1279,8 @@ hns3_action_rss_same(const struct rte_flow_action_rss 
*comp,
bool rss_key_is_same;
bool func_is_same;
 
-   /*
-* When user flush all RSS rule, RSS func is set invalid with
-* RTE_ETH_HASH_FUNCTION_MAX. Then the user create a flow after
-* flushed, any validate RSS func is different with it before
-* flushed. Others, when user create an action RSS with RSS func
-* specified RTE_ETH_HASH_FUNCTION_DEFAULT, the func is the same
-* between continuous RSS flow.
-*/
-   if (comp->func == RTE_ETH_HASH_FUNCTION_MAX)
-   func_is_same = false;
-   else
-   func_is_same = (with->func != RTE_ETH_HASH_FUNCTION_DEFAULT) ?
-   (comp->func == with->func) : true;
+   func_is_same = (with->func != RTE_ETH_HASH_FUNCTION_DEFAULT) ?
+   (comp->func == with->func) : true;
 
if (with->key_len == 0 || with->key == NULL)
rss_key_is_same = 1;
@@ -1533,7 +1522,6 @@ static int
 hns3_config_rss_filter(struct hns3_hw *hw,
   const struct hns3_rss_conf *conf, bool add)
 {
-   struct hns3_rss_conf *rss_info;
uint64_t flow_types;
uint16_t num;
int ret;
@@ -1560,7 +1548,6 @@ hns3_config_rss_filter(struct hns3_hw *hw,
/* Update the useful flow types */
rss_flow_conf.types = flow_types;
 
-   rss_info = &hw->rss_info;
if (!add) {
if (!conf->valid)
return 0;
@@ -1571,15 +1558,6 @@ hns3_config_rss_filter(struct hns3_hw *hw,
return ret;
}
 
-   if (rss_flow_conf.queue_num) {
-   /*
-* Due the content of queue pointer have been reset to
-* 0, the rss_info->conf.queue should be set to NULL
-*/
-   rss_info->conf.queue = NULL;
-   rss_info->conf.queue_num = 0;
-   }
-
return 0;
}
 
-- 
2.22.0

[PATCH V2 06/10] net/hns3: using RSS filter list to check duplicated rule

[Dongdong Liu]

From: Huisong Li 

All rules from user are saved in RSS filter list, so use RSS
filter list to check duplicated rule.

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_flow.c | 35 +--
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/net/hns3/hns3_flow.c b/drivers/net/hns3/hns3_flow.c
index c338eab049..303275ae93 100644
--- a/drivers/net/hns3/hns3_flow.c
+++ b/drivers/net/hns3/hns3_flow.c
@@ -1300,7 +1300,7 @@ hns3_action_rss_same(const struct rte_flow_action_rss 
*comp,
!memcmp(comp->key, with->key, with->key_len);
 
return (func_is_same && rss_key_is_same &&
-   comp->types == (with->types & HNS3_ETH_RSS_SUPPORT) &&
+   comp->types == with->types &&
comp->level == with->level &&
comp->queue_num == with->queue_num &&
!memcmp(comp->queue, with->queue,
@@ -1596,15 +1596,7 @@ hns3_config_rss_filter(struct hns3_hw *hw,
}
 
/* Set hash algorithm and flow types by the user's config */
-   ret = hns3_hw_rss_hash_set(hw, &rss_flow_conf);
-   if (ret)
-   return ret;
-
-   ret = hns3_rss_conf_copy(rss_info, &rss_flow_conf);
-   if (ret)
-   hns3_err(hw, "RSS config init fail(%d)", ret);
-
-   return ret;
+   return hns3_hw_rss_hash_set(hw, &rss_flow_conf);
 }
 
 static int
@@ -1676,17 +1668,32 @@ hns3_restore_filter(struct hns3_adapter *hns)
return hns3_restore_rss_filter(hw);
 }
 
+static bool
+hns3_rss_action_is_dup(struct hns3_hw *hw,
+  const struct rte_flow_action_rss *act)
+{
+   struct hns3_rss_conf_ele *filter;
+
+   TAILQ_FOREACH(filter, &hw->flow_rss_list, entries) {
+   if (!filter->filter_info.valid)
+   continue;
+
+   if (hns3_action_rss_same(&filter->filter_info.conf, act))
+   return true;
+   }
+
+   return false;
+}
+
 static int
 hns3_flow_parse_rss(struct rte_eth_dev *dev,
const struct hns3_rss_conf *conf, bool add)
 {
struct hns3_adapter *hns = dev->data->dev_private;
struct hns3_hw *hw = &hns->hw;
-   bool ret;
 
-   ret = hns3_action_rss_same(&hw->rss_info.conf, &conf->conf);
-   if (ret) {
-   hns3_err(hw, "Enter duplicate RSS configuration : %d", ret);
+   if (hns3_rss_action_is_dup(hw, &conf->conf)) {
+   hns3_err(hw, "duplicate RSS configuration");
return -EINVAL;
}
 
-- 
2.22.0

[PATCH V2 09/10] net/hns3: fix bad memory structure conversion

[Dongdong Liu]

From: Huisong Li 

When the type in 'struct rte_flow_action' is RTE_FLOW_ACTION_TYPE_RSS, the
'conf' pointer references the 'struct rte_flow_action_rss' instead of the
'struct hns3_rss_conf' in driver. But driver uses 'struct hns3_rss_conf' to
convert this 'conf' pointer to get RSS action configuration.

In addition, RSS filter configuration is directly cloned to RSS filter node
instead of coping it after successfully setting to hardware.

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_flow.c | 57 +---
 1 file changed, 20 insertions(+), 37 deletions(-)

diff --git a/drivers/net/hns3/hns3_flow.c b/drivers/net/hns3/hns3_flow.c
index fbc38dd3d4..307aba75a7 100644
--- a/drivers/net/hns3/hns3_flow.c
+++ b/drivers/net/hns3/hns3_flow.c
@@ -95,8 +95,8 @@ static const struct rte_flow_action *
 hns3_find_rss_general_action(const struct rte_flow_item pattern[],
 const struct rte_flow_action actions[])
 {
+   const struct rte_flow_action_rss *rss_act;
const struct rte_flow_action *act = NULL;
-   const struct hns3_rss_conf *rss;
bool have_eth = false;
 
for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
@@ -115,8 +115,8 @@ hns3_find_rss_general_action(const struct rte_flow_item 
pattern[],
}
}
 
-   rss = act->conf;
-   if (have_eth && rss->conf.queue_num) {
+   rss_act = act->conf;
+   if (have_eth && rss_act->queue_num) {
/*
 * Pattern have ETH and action's queue_num > 0, indicate this is
 * queue region configuration.
@@ -1296,30 +1296,6 @@ hns3_action_rss_same(const struct rte_flow_action_rss 
*comp,
sizeof(*with->queue) * with->queue_num));
 }
 
-static int
-hns3_rss_conf_copy(struct hns3_rss_conf *out,
-  const struct rte_flow_action_rss *in)
-{
-   if (in->key_len > RTE_DIM(out->key) ||
-   in->queue_num > RTE_DIM(out->queue))
-   return -EINVAL;
-   if (in->key == NULL && in->key_len)
-   return -EINVAL;
-   out->conf = (struct rte_flow_action_rss) {
-   .func = in->func,
-   .level = in->level,
-   .types = in->types,
-   .key_len = in->key_len,
-   .queue_num = in->queue_num,
-   };
-   out->conf.queue = memcpy(out->queue, in->queue,
-   sizeof(*in->queue) * in->queue_num);
-   if (in->key)
-   out->conf.key = memcpy(out->key, in->key, in->key_len);
-
-   return 0;
-}
-
 static bool
 hns3_rss_input_tuple_supported(struct hns3_hw *hw,
   const struct rte_flow_action_rss *rss)
@@ -1733,9 +1709,10 @@ hns3_flow_create_rss_rule(struct rte_eth_dev *dev,
  struct rte_flow *flow)
 {
struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   const struct rte_flow_action_rss *rss_act;
struct hns3_rss_conf_ele *rss_filter_ptr;
struct hns3_rss_conf_ele *filter_ptr;
-   const struct hns3_rss_conf *rss_conf;
+   struct hns3_rss_conf *new_conf;
int ret;
 
rss_filter_ptr = rte_zmalloc("hns3 rss filter",
@@ -1745,19 +1722,25 @@ hns3_flow_create_rss_rule(struct rte_eth_dev *dev,
return -ENOMEM;
}
 
-   /*
-* After all the preceding tasks are successfully configured, configure
-* rules to the hardware to simplify the rollback of rules in the
-* hardware.
-*/
-   rss_conf = (const struct hns3_rss_conf *)act->conf;
-   ret = hns3_flow_parse_rss(dev, rss_conf, true);
+   rss_act = (const struct rte_flow_action_rss *)act->conf;
+   new_conf = &rss_filter_ptr->filter_info;
+   memcpy(&new_conf->conf, rss_act, sizeof(*rss_act));
+   if (rss_act->queue_num > 0) {
+   memcpy(new_conf->queue, rss_act->queue,
+  rss_act->queue_num * sizeof(new_conf->queue[0]));
+   new_conf->conf.queue = new_conf->queue;
+   }
+   if (rss_act->key_len > 0) {
+   memcpy(new_conf->key, rss_act->key,
+  rss_act->key_len * sizeof(new_conf->key[0]));
+   new_conf->conf.key = new_conf->key;
+   }
+
+   ret = hns3_flow_parse_rss(dev, new_conf, true);
if (ret != 0) {
rte_free(rss_filter_ptr);
return ret;
}
-
-   hns3_rss_conf_copy(&rss_filter_ptr->filter_info, &rss_conf->conf);
rss_filter_ptr->filter_info.valid = true;
 
/*
-- 
2.22.0

[PATCH V2 10/10] net/hns3: fix incorrect check for duplicate RSS rule

[Dongdong Liu]

From: Huisong Li 

Currently, the interface for verifying duplicate RSS rules has
some problems:
1) If the value of 'func' in configuring RSS rule is default
   value, this rule is mistakenly considered as a duplicate rule.
2) If key length is zero or 'key' is NULL in configuring RSS rule
   this rule is also mistakenly considered as a duplicate rule.
3) If 'key' or 'queue' in struct rte_flow_action_rss being NULL
   is used to memcpy, which may cause segment fault.

Fixes: c37ca66f2b27 ("net/hns3: support RSS")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Dongdong Liu 
---
 drivers/net/hns3/hns3_flow.c | 63 +++-
 1 file changed, 47 insertions(+), 16 deletions(-)

diff --git a/drivers/net/hns3/hns3_flow.c b/drivers/net/hns3/hns3_flow.c
index 307aba75a7..8ff9d4ae66 100644
--- a/drivers/net/hns3/hns3_flow.c
+++ b/drivers/net/hns3/hns3_flow.c
@@ -1272,28 +1272,59 @@ hns3_filterlist_flush(struct rte_eth_dev *dev)
}
 }
 
+static bool
+hns3_flow_rule_key_same(const struct rte_flow_action_rss *comp,
+   const struct rte_flow_action_rss *with)
+{
+   if (comp->key_len != with->key_len)
+   return false;
+
+   if (with->key_len == 0)
+   return true;
+
+   if (comp->key == NULL && with->key == NULL)
+   return true;
+
+   if (!(comp->key != NULL && with->key != NULL))
+   return false;
+
+   return !memcmp(comp->key, with->key, with->key_len);
+}
+
+static bool
+hns3_flow_rule_queues_same(const struct rte_flow_action_rss *comp,
+  const struct rte_flow_action_rss *with)
+{
+   if (comp->queue_num != with->queue_num)
+   return false;
+
+   if (with->queue_num == 0)
+   return true;
+
+   if (comp->queue == NULL && with->queue == NULL)
+   return true;
+
+   if (!(comp->queue != NULL && with->queue != NULL))
+   return false;
+
+   return !memcmp(comp->queue, with->queue, with->queue_num);
+}
+
 static bool
 hns3_action_rss_same(const struct rte_flow_action_rss *comp,
 const struct rte_flow_action_rss *with)
 {
-   bool rss_key_is_same;
-   bool func_is_same;
+   bool same_level;
+   bool same_types;
+   bool same_func;
 
-   func_is_same = (with->func != RTE_ETH_HASH_FUNCTION_DEFAULT) ?
-   (comp->func == with->func) : true;
+   same_level = (comp->level == with->level);
+   same_types = (comp->types == with->types);
+   same_func = (comp->func == with->func);
 
-   if (with->key_len == 0 || with->key == NULL)
-   rss_key_is_same = 1;
-   else
-   rss_key_is_same = comp->key_len == with->key_len &&
-   !memcmp(comp->key, with->key, with->key_len);
-
-   return (func_is_same && rss_key_is_same &&
-   comp->types == with->types &&
-   comp->level == with->level &&
-   comp->queue_num == with->queue_num &&
-   !memcmp(comp->queue, with->queue,
-   sizeof(*with->queue) * with->queue_num));
+   return same_level && same_types && same_func &&
+   hns3_flow_rule_key_same(comp, with) &&
+   hns3_flow_rule_queues_same(comp, with);
 }
 
 static bool
-- 
2.22.0

Re: [PATCH v2 1/2] vhost: fix possible FDs leak

[Maxime Coquelin]

On 1/29/23 10:25, David Marchand wrote:

On Fri, Jan 27, 2023 at 5:55 PM Maxime Coquelin
 wrote:


On failure, read_vhost_message() only closed the message
FDs if the header size was unexpected, but there are other
cases where it is required. For exemple in the case the
payload size read from the header is greater than the
expected maximum payload size.

This patch fixes this by closing all messages FDs in all
error cases.

Fixes: bf472259dde6 ("vhost: fix possible denial of service by leaking FDs")
Cc: sta...@dpdk.org

Signed-off-by: Maxime Coquelin 


Reviewed-by: David Marchand 

We mentionned offlist that the request type can be logged to help with debug.
Do you intend to add this as a follow up patch?




Thinking about it, that's not that trivial because read_vhost_message()
is called for both master and slave channels, so we would need to
differentiate between both to print proper request name.

It is doable by comparing the file descriptor passed as parameter with
the slave one stored in struct virtio_net, but that's not super clean.

Any thoughts?

Maxime

Re: [RFC] config: customize max memzones configuration

[Bruce Richardson]

On Mon, Jan 30, 2023 at 11:23:02AM +0200, Ophir Munk wrote:
> In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard
> coded as 2560.  For applications requiring different values of this
> parameter – it is more convenient to set its value as part of the meson
> command line or to set the max value via an rte API - rather than
> changing the dpdk source code per application.
> 
> An example would be of an application that uses the DPDK mempool library
> which is based on DPDK memzone library.  The application may need to
> create a number of steering tables, each of which will require its own
> mempool allocation.  This RFC is not about how to optimize the
> application usage of mempool nor about how to improve the mempool
> implementation based on memzone.  It is about how to make the max
> memzone definition - build-time or run-time customized.
> 
> I would like to suggest three options.
> 
> Option 1
> 
> Add a Meson option in meson options.txt and remove the
> RTE_MAX_MEMZONE definition from config/rte_config.h
> 
> For example,
> 
>  config/meson.build
> 
>  # set other values pulled from the build options
>  dpdk_conf.set('RTE_MAX_LCORE', get_option('max_lcores'))
>  +dpdk_conf.set('RTE_MAX_MEMZONE', get_option('max_memzones'))
>  dpdk_conf.set('RTE_MAX_NUMA_NODES', get_option('max_numa_nodes'))
> 
>  meson_options.txt
> 
>  option('max_lcores', type: 'integer', value: 128,
> description: 'maximum number of cores/threads supported by EAL')
>  +option('max_memzones', type: 'integer', value: 2560,
>  +   description: 'maximum number of memory zones supported by EAL')
>  option('max_numa_nodes', type: 'integer', value: 32,
> description: 'maximum number of NUMA nodes supported by EAL')
> 
>  config/rte_config.h
> 
>  #define RTE_MAX_MEM_MB_PER_TYPE 65536
>  -#define RTE_MAX_MEMZONE 2560
>  #define RTE_MAX_TAILQ 32
> 
Of the 3 options, I think this first option would probably be my preferred one.

/Bruce

RE: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs

[Naga Harish K, S V]

> -Original Message-
> From: Jerin Jacob 
> Sent: Saturday, January 28, 2023 4:24 PM
> To: Naga Harish K, S V 
> Cc: jer...@marvell.com; Carrillo, Erik G ; Gujjar,
> Abhinandan S ; dev@dpdk.org;
> Jayatheerthan, Jay 
> Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> 
> On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
>  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Jerin Jacob 
> 
> > > > > >
> > > > > > > > +*/
> > > > > > > > +   uint32_t rsvd[15];
> > > > > > > > +   /**< Reserved fields for future use */
> > > > > > >
> > > > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to
> > > make
> > > > > > > sure rsvd is zero.
> > > > > > >
> > > > > >
> > > > > > The reserved fields are not used by the adapter or application.
> > > > > > Not sure Is it necessary to Introduce a new API to clear reserved
> fields.
> > > > >
> > > > > When adapter starts using new fileds(when we add new fieds in
> > > > > future), the old applicaiton which is not using
> > > > > rte_event_eth_rx_adapter_runtime_params_init() may have junk
> > > > > value and then adapter implementation will behave bad.
> > > > >
> > > > >
> > > >
> > > > does it mean, the application doesn't re-compile for the new DPDK?
> > >
> > > Yes. No need recompile if ABI not breaking.
> > >
> > > > When some of the reserved fields are used in the future, the
> > > > application
> > > also may need to be recompiled along with DPDK right?
> > > > As the application also may need to use the newly consumed
> > > > reserved
> > > fields?
> > >
> > > The problematic case is:
> > >
> > > Adapter implementation of 23.07(Assuming there is change params)
> > > field needs to work with application of 23.03.
> > > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> > >
> >
> > As rte_event_eth_rx_adapter_runtime_params_init() initializes only
> reserved fields to zero,  it may not solve the issue in this case.
> 
> rte_event_eth_rx_adapter_runtime_params_init() needs to zero all fields,
> not just reserved field.
> The application calling sequence  is
> 
> struct my_config c;
> rte_event_eth_rx_adapter_runtime_params_init(&c)
> c.interseted_filed_to_be_updated = val;
> 
Can it be done like 
struct my_config c = {0};
c.interseted_filed_to_be_updated = val;
and update Doxygen comments to recommend above usage to reset all fields?
This way,  rte_event_eth_rx_adapter_runtime_params_init() can be avoided.

> Let me share an example and you can tell where is the issue
> 
> 1)Assume parameter structure is 64B and for 22.03 8B are used.
> 2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B.
> 3)There is an application written based on 22.03 which using only 8B after
> calling rte_event_eth_rx_adapter_runtime_params_init()
> 4)Assume, in 22.07 another 8B added to structure.
> 5)Now, the application (3) needs to run on 22.07. Since the application is
> calling rte_event_eth_rx_adapter_runtime_params_init()
> and 9 to 15B are zero, the implementation will not go bad.
> 
> > The old application only tries to set/get previous valid fields and the 
> > newly
> used fields may still contain junk value.
> > If the application wants to make use of any the newly used params, the
> application changes are required anyway.
> 
> Yes. If application wants to make use of newly added features. No need to
> change if new features are not needed for old application.

Re: [RFC] config: customize max memzones configuration

[Dmitry Kozlyuk]

2023-01-30 11:23 (UTC+0200), Ophir Munk:
> In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard
> coded as 2560.  For applications requiring different values of this
> parameter – it is more convenient to set its value as part of the meson
> command line or to set the max value via an rte API - rather than
> changing the dpdk source code per application.
> 
> An example would be of an application that uses the DPDK mempool library
> which is based on DPDK memzone library.  The application may need to
> create a number of steering tables, each of which will require its own
> mempool allocation.  This RFC is not about how to optimize the
> application usage of mempool nor about how to improve the mempool
> implementation based on memzone.  It is about how to make the max
> memzone definition - build-time or run-time customized.
> 
> I would like to suggest three options.
> 
> Option 1
> 
> Add a Meson option in meson options.txt and remove the
> RTE_MAX_MEMZONE definition from config/rte_config.h
> 
[...]
> 
> Option 2
> 
> Use Meson setup -Dc_args="-DRTE_MAX_MEMZONE=XXX" and
> make RTE_MAX_MEMZONE conditional in config/rte_config.h
> 
> For example, see the code of this commit.
> 
> Option 3
> 
> Add a function which must be called before rte_eal_init():
> void rte_memzone_set_max(int max) {memzone_max = max;}
> If not called, the default memzone (RTE_MAX_MEMZONE) is used.
> 
> With this option there is no need to recompile DPDK and it allows
> using an in-box packaged DPDK.
[...]

Ideally, there should be no limitation at all.
I vote for some compile-time solution for now
with a plan to remove the restriction inside EAL later.
Option 2 does not expose a user-facing option that would be obsoleted anyway,
so it seems preferable to me, but Option 1 is also OK and consistent.

`RTE_MAX_MEMZONE` is needed currently, because `struct rte_memzone` are stored
in `rte_fbarray` (mapped file-backed array) with a fixed capacity.
Unlike e.g. `rte_eth_devices`, this is not used for efficient access by index
and is not even exposed to PMDs, so the storage can be changed painlessly.
In DPDK, only net/qede uses this constant and also for slow-path bookkeeping.

RE: [dpdk-dev] [RFC] testpmd: support user-id attribute

[Asaf Penso]

Hello Aman,
Can you clarify your intention? Like Eli mentioned, the group_id is less 
relevant for that purpose. Even with the same group_id we wish to have several 
different flows with different user-id.

All,
Do you have any other comments?
We would like to proceed with the process of sending v1, review, and integrate.

Regards,
Asaf Penso

>-Original Message-
>From: Eli Britstein 
>Sent: Sunday, 7 August 2022 10:01
>To: Singh, Aman Deep ; dev@dpdk.org
>Cc: Slava Ovsiienko ; Ori Kam ;
>Asaf Penso ; Matan Azrad ; Gaetan
>Rivet ; Nir Anteby ; Yuying
>Zhang ; Ferruh Yigit ;
>Andrew Rybchenko ; NBU-Contact-
>Thomas Monjalon (EXTERNAL) 
>Subject: RE: [dpdk-dev] [RFC] testpmd: support user-id attribute
>
>Hi Aman,
>
>No, the group attribute has its own meaning, so it cannot be used for this
>purpose, unless I misunderstood your meaning.
>
>Thanks,
>Eli
>
>>-Original Message-
>>From: Singh, Aman Deep 
>>Sent: Thursday, July 28, 2022 5:07 PM
>>To: dev@dpdk.org; Eli Britstein 
>>Cc: Slava Ovsiienko ; Ori Kam
>>; Asaf Penso ; Matan Azrad
>>; Gaetan Rivet ; Nir Anteby
>>; Yuying Zhang ; Ferruh
>>Yigit ; Andrew Rybchenko
>>; NBU-Contact- Thomas Monjalon
>>(EXTERNAL) 
>>Subject: Re: [dpdk-dev] [RFC] testpmd: support user-id attribute
>>
>>External email: Use caution opening links or attachments
>>
>>
>>Hi Eli,
>>
>>In RTE flow there is support for group_id attribute(u32).
>>Similar to the example you gave-
>>
>>testpmd> flow create 0 group 0x1234 ingress pattern eth / end actions
>>count / drop / end
>>
>>Please check if it fits the requirement.
>>
>>Regards
>>Aman
>>
>>
>>On 7/20/2022 2:14 AM, Thomas Monjalon wrote:
>>> +Cc ethdev and testpmd maintainers
>>>
>>> Any feedback about this need and solution?
>>>
>>>
>>> 04/07/2022 10:24, Eli Britstein:
 Upon creation of a flow, testpmd assigns it a flow ID. Later, the
 flow ID is used for flow operations (query, destroy, dump).

 The testpmd application allows to manage flow rules with its IDs.
 The flow ID is known only when the flow is created.
 In order to prepare a complete sequence of testpmd commands to
 copy/paste, the flow IDs must be predictable.

 The idea brought here is to allow providing some user-defined ID,
 chosen in advance of the effective flow creation.


 Example:

 testpmd> flow create 0 ingress user_id 0x1234 pattern eth / end
 testpmd> actions
 count / drop / end
 Flow rule #0 created, user-id 0x1234

 testpmd> flow destroy 0 user_id rule 0x1234
 Flow rule #0 destroyed, user-id 0x1234 Here, "user_id" is a flag
 that signifies the "rule" ID is the user-id.

 The motivation is from OVS. OVS dumps its "rte_flow_create" calls to
 the log in testpmd commands syntax. As the flow ID testpmd would
 assign is unkwon, it cannot log valid "flow destroy" commands.

 With the enhancement described above, valid testpmd commands can be
 created in a log to copy/paste to testpmd.
 The application's flows sequence can then be played back in testpmd,
 to enable enhanced dpdk debug capabilities of the applications's
 flows in a controlled environment of testpmd rather than a dynamic,
 more difficult to debug environment of the application.
>>>
>>>
>>>
>>>

RE: [PATCH v7] mem: telemetry support for memseg and element information

[Amit Prakash Shukla]

Ping.

> -Original Message-
> From: Amit Prakash Shukla
> Sent: Tuesday, December 6, 2022 5:17 PM
> To: david.march...@redhat.com
> Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> bruce.richard...@intel.com; ciara.po...@intel.com;
> dmitry.kozl...@gmail.com; Anatoly Burakov ;
> Amit Prakash Shukla 
> Subject: RE: [PATCH v7] mem: telemetry support for memseg and element
> information
> 
> Ping.
> 
> > -Original Message-
> > From: Amit Prakash Shukla 
> > Sent: Tuesday, October 25, 2022 6:32 PM
> > To: Anatoly Burakov 
> > Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ;
> > david.march...@redhat.com; bruce.richard...@intel.com;
> > ciara.po...@intel.com; dmitry.kozl...@gmail.com; Amit Prakash Shukla
> > 
> > Subject: [PATCH v7] mem: telemetry support for memseg and element
> > information
> >
> > Changes adds telemetry support to display memory occupancy in memseg
> > and the information of the elements allocated from a memseg based on
> > arguments provided by user. This patch adds following endpoints:
> >
> > 1. /eal/memseg_lists
> > The command displays the memseg list from which the memory has been
> > allocated.
> > Example:
> > --> /eal/memseg_lists
> > {"/eal/memseg_lists": [0, 1]}
> >
> > 2. /eal/memseg_list_info,
> > The command outputs the memsegs, from which the memory is allocated,
> > for the memseg_list given as input.
> > Example:
> > --> /eal/memseg_list_info,0
> > {"/eal/memseg_list_info": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, \
> > 12, 13, 14, 15]}
> >
> > 3. /eal/memseg_info,,
> > The command outputs the memseg information based on the memseg-list
> > and the memseg-id given as input.
> > Example:
> > --> /eal/memseg_info,0,10
> > {"/eal/memseg_info": {"Memseg_list_index": 0, \
> > "Memseg_index": 10, "Start_addr": "0x10160", \
> > "End_addr": "0x10180", "Size": 2097152, "Hugepage_size": 2097152,
> > \
> > "Socket_id": 0, "flags": 0}}
> >
> > --> /eal/memseg_info,0,15
> > {"/eal/memseg_info": {"Memseg_list_index": 0, "Memseg_index": 15, \
> > "Start_addr": "0x10200", "End_addr": "0x10220", \
> > "Size": 2097152, "Hugepage_size": 2097152, "Socket_id": 0, "flags":
> > 0}}
> >
> > 4. /eal/mem_element_list,,,
> > The command outputs number of elements in a memseg based on the
> heap-
> > id, memseg-list-id and memseg-id given as input.
> > Example:
> > --> /eal/mem_element_list,0,0,10
> > {"/eal/mem_element_list": {"Element_count": 52}}
> >
> > --> /eal/mem_element_list,0,1,15
> > {"/eal/mem_element_list": {"Element_count": 52}}
> >
> > 5. /eal/mem_element_info  \
> >,
> > The command outputs element information like element start address,
> > end address, to which memseg it belongs, element state, element size.
> > User can give a range of elements to be printed.
> > Example:
> > --> /eal/mem_element_info,0,0,15,1,2
> > {"/eal/mem_element_info": {"element_1": {"msl_id": 0, "ms_id": 15, \
> > "memseg_start_addr": "0x10200", "memseg_end_addr":
> > "0x10220", \
> > "element_start_addr": "0x102000b00", "element_end_addr":
> > "0x102003380", \
> > "element_size": 10368, "element_state": "Busy"}, "element_2": \
> > {"msl_id": 0, "ms_id": 15, "memseg_start_addr": "0x10200", \
> > "memseg_end_addr": "0x10220", "element_start_addr":
> > "0x102003380", \
> > "element_end_addr": "0x102005c00", "element_size": 10368, \
> > "element_state": "Busy"}, "Element_count": 2}}
> >
> > Signed-off-by: Amit Prakash Shukla 
> > ---
> > v2:
> > - Fixed compilation error related int-to-pointer-cast
> > - Changes for code review suggestions
> >
> > v3:
> > - Commit message changes
> > - Renaming end-points
> > - Changing input parameters to comma-seperated
> > - Reverting telemetry output buffer size
> >
> > v4:
> > - Patch-2 adds telemetry support to display system memory
> >
> > v5:
> > - Removed command help related changes
> >
> > v6:
> > - Changes for code review suggestions
> > - Dropped Patch-2 from the series
> >
> > v7:
> > - Fixed compilation error
> >
> >  lib/eal/common/eal_common_memory.c | 391
> > -
> >  1 file changed, 386 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/eal/common/eal_common_memory.c
> > b/lib/eal/common/eal_common_memory.c
> > index 688dc615d7..bce18046ce 100644
> > --- a/lib/eal/common/eal_common_memory.c
> > +++ b/lib/eal/common/eal_common_memory.c
> > @@ -3,6 +3,7 @@
> >   */
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -26,6 +27,7 @@
> >  #include "eal_memcfg.h"
> >  #include "eal_options.h"
> >  #include "malloc_heap.h"
> > +#include "malloc_elem.h"
> >
> >  /*
> >   * Try to mmap *size bytes in /dev/zero. If it is successful, return
> > the @@ -
> > 1113,11 +1115,17 @@ rte_eal_memory_init(void)  }
> >
> >  #ifndef RTE_EXEC_ENV_WINDOWS
> > -#define EAL_MEMZONE_LIST_REQ   "/eal/memzone_list"
> > -#define EAL_MEMZONE_INFO_REQ   "/eal/memzone_info"
> > -#define EAL_HEAP_LIST_REQ  "/eal/heap_list"
> > -#define EAL_HEAP_INFO_REQ  "/eal/heap_info"
> >

Expect slowness in CI during the week of Feb 5

[Raslan Darawsheh]

Hi Guys,

Because we are migrating our servers from MTR to MTL,
We need to have a shutdown for some of our services/servers in MTR which will 
affect our CI.

In general, the services should continue working, but with a slower resolution 
time.
One of our services (dpdk-tests) will be fully down (can’t be running per PR) 
during this time.
For that, we need your help to make sure you are running the cloud regression 
yourself on each PR you have. (follow this 
guideline)


Kindest regards,
Raslan Darawsheh

Re: [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API

[lihuisong (C)]

Kindly ping.

在 2023/1/16 20:06, lihuisong (C) 写道:

Hi Ferruh and Andrew,

This patch series optimizes some codes and bug.
Can you take a look at this patch series?
If there are no other questions, can it be merged?

Best,
Huisong

在 2022/12/19 15:06, Huisong Li 写道:

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.

---
  -v8: fix the coding style in patch 7/8
  -v7: replace sprintf with snprintf in patch 6/8
  -v6: fix code alignment to keep in line with codes in the file
  -v5:
 - drop a refactor patch.
 - no limit the bit width for xxx_uint_hex API.
  -v4:
 - remove 'u32' value type.merg
 - add padding zero for hexadecimal value
  -v3: fix a misspelling mistake in commit log.
  -v2:
 - fix ABI break warning.
 - introduce two APIs to store u32 and u64 values as hexadecimal
   encoded strings.

Huisong Li (8):
   telemetry: move to header to controllable range
   ethdev: fix possible data truncation and conversion error
   mempool: fix possible data truncation and conversion error
   cryptodev: fix possible data conversion error
   mem: possible data truncation and conversion error
   telemetry: support adding integer value as hexadecimal
   test: add test cases for adding hex integer value API
   ethdev: display capability values in hexadecimal format

  app/test/test_telemetry_data.c | 150 +
  lib/cryptodev/rte_cryptodev.c  |   2 +-
  lib/eal/common/eal_common_memory.c |  10 +-
  lib/ethdev/rte_ethdev.c    |  19 ++--
  lib/mempool/rte_mempool.c  |  24 ++---
  lib/telemetry/rte_telemetry.h  |  52 +-
  lib/telemetry/telemetry_data.c |  73 ++
  lib/telemetry/version.map  |   9 ++
  8 files changed, 309 insertions(+), 30 deletions(-)



.

RE: Expect slowness in CI during the week of Feb 5

[Raslan Darawsheh]

You can disregard this email! It was sent by mistake to the wrong mailing 
address.
Sorry for the spam!

Kindest regards,
Raslan Darawsheh

From: Raslan Darawsheh
Sent: Monday, January 30, 2023 12:34 PM
To: dpdk-team ; dpdk-dev ; 
shys-org 
Cc: Ali Alnubani ; Shy Shyman 
Subject: Expect slowness in CI during the week of Feb 5
Importance: High

Hi Guys,

Because we are migrating our servers from MTR to MTL,
We need to have a shutdown for some of our services/servers in MTR which will 
affect our CI.

In general, the services should continue working, but with a slower resolution 
time.
One of our services (dpdk-tests) will be fully down (can’t be running per PR) 
during this time.
For that, we need your help to make sure you are running the cloud regression 
yourself on each PR you have. (follow this 
guideline)


Kindest regards,
Raslan Darawsheh

[PATCH] test/crypto: fix typo in AES test

[Vikash Poddar]

Fix the spelling of scater to scatter in cryptodev AES test vector
header file

Fixes: 2692b02e03b2 ("test/crypto: add multi-segment out-of-place AES-XTS")
Cc: shi...@nvidia.com

Signed-off-by: Vikash Poddar 
---
 .mailmap   |  1 +
 app/test/test_cryptodev_aes_test_vectors.h | 16 
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/.mailmap b/.mailmap
index 75884b6fe2..c6650e32f6 100644
--- a/.mailmap
+++ b/.mailmap
@@ -1386,6 +1386,7 @@ Vijay Kumar Srivastava 
 Vijay Srivastava 
 Vikas Aggarwal 
 Vikas Gupta 
+Vikash Poddar 
 Vimal Chungath 
 Vincent Guo 
 Vincent Jardin 
diff --git a/app/test/test_cryptodev_aes_test_vectors.h 
b/app/test/test_cryptodev_aes_test_vectors.h
index ea7b21ce53..f3686beeb5 100644
--- a/app/test/test_cryptodev_aes_test_vectors.h
+++ b/app/test/test_cryptodev_aes_test_vectors.h
@@ -4969,7 +4969,7 @@ static const struct blockcipher_test_case 
aes_cipheronly_test_cases[] = {
},
{
.test_descr = "AES-256-XTS Encryption (512-byte plaintext"
- " Dataunit 512) Scater gather OOP",
+ " Dataunit 512) Scatter gather OOP",
.test_data = &aes_test_data_xts_wrapped_key_48_pt_512_du_512,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
.feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP |
@@ -4979,7 +4979,7 @@ static const struct blockcipher_test_case 
aes_cipheronly_test_cases[] = {
},
{
.test_descr = "AES-256-XTS Decryption (512-byte plaintext"
- " Dataunit 512) Scater gather OOP",
+ " Dataunit 512) Scatter gather OOP",
.test_data = &aes_test_data_xts_wrapped_key_48_pt_512_du_512,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
.feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP |
@@ -4989,7 +4989,7 @@ static const struct blockcipher_test_case 
aes_cipheronly_test_cases[] = {
},
{
.test_descr = "AES-256-XTS Encryption (512-byte plaintext"
- " Dataunit 0) Scater gather OOP",
+ " Dataunit 0) Scatter gather OOP",
.test_data = &aes_test_data_xts_wrapped_key_48_pt_512_du_0,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
.feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP |
@@ -4999,7 +4999,7 @@ static const struct blockcipher_test_case 
aes_cipheronly_test_cases[] = {
},
{
.test_descr = "AES-256-XTS Decryption (512-byte plaintext"
- " Dataunit 0) Scater gather OOP",
+ " Dataunit 0) Scatter gather OOP",
.test_data = &aes_test_data_xts_wrapped_key_48_pt_512_du_0,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
.feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP |
@@ -5009,7 +5009,7 @@ static const struct blockcipher_test_case 
aes_cipheronly_test_cases[] = {
},
{
.test_descr = "AES-256-XTS Encryption (4096-byte plaintext"
- " Dataunit 4096) Scater gather OOP",
+ " Dataunit 4096) Scatter gather OOP",
.test_data = &aes_test_data_xts_wrapped_key_48_pt_4096_du_4096,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
.feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP |
@@ -5019,7 +5019,7 @@ static const struct blockcipher_test_case 
aes_cipheronly_test_cases[] = {
},
{
.test_descr = "AES-256-XTS Decryption (4096-byte plaintext"
- " Dataunit 4096) Scater gather OOP",
+ " Dataunit 4096) Scatter gather OOP",
.test_data = &aes_test_data_xts_wrapped_key_48_pt_4096_du_4096,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
.feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP |
@@ -5029,7 +5029,7 @@ static const struct blockcipher_test_case 
aes_cipheronly_test_cases[] = {
},
{
.test_descr = "AES-256-XTS Encryption (4096-byte plaintext"
- " Dataunit 0) Scater gather OOP",
+ " Dataunit 0) Scatter gather OOP",
.test_data = &aes_test_data_xts_wrapped_key_48_pt_4096_du_0,
.op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
.feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP |
@@ -5039,7 +5039,7 @@ static const struct blockcipher_test_case 
aes_cipheronly_test_cases[] = {
},
{
.test_descr = "AES-256-XTS Decryption (4096-byte plaintext"
- " Dataunit 0) Scater gather OOP",
+ " Dataunit 0) Scatter gather OOP",
.test_data = &aes_test_data_xts_wrapped_key_48_pt_4096_du_0,
.op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,

[PATCH v3 00/11] add flex item support

[Rongwei Liu]

Support flex item matching and modify field in async flow.
Syntax follows sync flow exactly.

v3: enhance format, add flex_handle document.

Rongwei Liu (11):
  ethdev: add flex item modify field support
  app/testpmd: pass flex handle into matching mask
  net/mlx5: enable hws flex item create
  net/mlx5: add IPv6 protocol as flex item input
  net/mlx5: adopt new flex item prm definition
  net/mlx5/hws: add hws flex item matching support
  net/mlx5: add flex item modify field implementation
  net/mlx5: return error for sws modify field
  app/testpmd: raw encap with flex item support
  doc/mlx5: update mlx5 doc
  app/testpmd: adjust cleanup sequence when quitting

 app/test-pmd/cmdline_flow.c| 123 +---
 app/test-pmd/testpmd.c |   2 +-
 doc/guides/nics/mlx5.rst   |   1 +
 doc/guides/prog_guide/rte_flow.rst |  41 +++---
 doc/guides/rel_notes/release_23_03.rst |   4 +
 drivers/common/mlx5/mlx5_devx_cmds.c   |  14 +-
 drivers/common/mlx5/mlx5_devx_cmds.h   |   7 +-
 drivers/common/mlx5/mlx5_prm.h |  29 +++-
 drivers/net/mlx5/hws/mlx5dr_definer.c  |  83 +++
 drivers/net/mlx5/linux/mlx5_os.c   |  27 ++--
 drivers/net/mlx5/mlx5.c|  17 ++-
 drivers/net/mlx5/mlx5.h|   9 +-
 drivers/net/mlx5/mlx5_flow.h   |   4 +
 drivers/net/mlx5/mlx5_flow_dv.c| 186 ++---
 drivers/net/mlx5/mlx5_flow_flex.c  | 149 +---
 drivers/net/mlx5/mlx5_flow_hw.c|  64 -
 lib/ethdev/rte_flow.h  |   8 +-
 17 files changed, 664 insertions(+), 104 deletions(-)

-- 
2.27.0

[PATCH v3 01/11] ethdev: add flex item modify field support

[Rongwei Liu]

Add flex item as modify field destination.
Add "struct rte_flow_item_flex_handle *flex_handle" into
"struct rte_flow_action_modify_data" as union with existed
"level" member. This new member is dedicated for modifying
flex item.

Add flex item modify field cmdline support. Now user can use
testpmd cli to specify which flex item to be modified, either
source or destination.

Syntax is as below:
modify_field op set dst_type flex_item dst_level 0
dst_offset 16 src_type value src_value 0x123456781020 width 8

Signed-off-by: Rongwei Liu 
Acked-by: Ori Kam 
---
 app/test-pmd/cmdline_flow.c| 89 --
 doc/guides/prog_guide/rte_flow.rst | 41 +++-
 doc/guides/rel_notes/release_23_03.rst |  4 ++
 lib/ethdev/rte_flow.h  |  8 ++-
 4 files changed, 116 insertions(+), 26 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 88108498e0..7c12d63cbc 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -601,10 +601,12 @@ enum index {
ACTION_MODIFY_FIELD_DST_TYPE,
ACTION_MODIFY_FIELD_DST_TYPE_VALUE,
ACTION_MODIFY_FIELD_DST_LEVEL,
+   ACTION_MODIFY_FIELD_DST_LEVEL_VALUE,
ACTION_MODIFY_FIELD_DST_OFFSET,
ACTION_MODIFY_FIELD_SRC_TYPE,
ACTION_MODIFY_FIELD_SRC_TYPE_VALUE,
ACTION_MODIFY_FIELD_SRC_LEVEL,
+   ACTION_MODIFY_FIELD_SRC_LEVEL_VALUE,
ACTION_MODIFY_FIELD_SRC_OFFSET,
ACTION_MODIFY_FIELD_SRC_VALUE,
ACTION_MODIFY_FIELD_SRC_POINTER,
@@ -807,7 +809,8 @@ static const char *const modify_field_ids[] = {
"udp_port_src", "udp_port_dst",
"vxlan_vni", "geneve_vni", "gtp_teid",
"tag", "mark", "meta", "pointer", "value",
-   "ipv4_ecn", "ipv6_ecn", "gtp_psc_qfi", "meter_color", NULL
+   "ipv4_ecn", "ipv6_ecn", "gtp_psc_qfi", "meter_color",
+   "flex_item", NULL
 };
 
 static const char *const meter_colors[] = {
@@ -2282,6 +2285,10 @@ parse_vc_modify_field_id(struct context *ctx, const 
struct token *token,
const char *str, unsigned int len, void *buf,
unsigned int size);
 static int
+parse_vc_modify_field_level(struct context *ctx, const struct token *token,
+   const char *str, unsigned int len, void *buf,
+   unsigned int size);
+static int
 parse_vc_action_conntrack_update(struct context *ctx, const struct token 
*token,
 const char *str, unsigned int len, void *buf,
 unsigned int size);
@@ -5976,11 +5983,15 @@ static const struct token token_list[] = {
.name = "dst_level",
.help = "destination field level",
.next = NEXT(action_modify_field_dst,
-NEXT_ENTRY(COMMON_UNSIGNED)),
-   .args = ARGS(ARGS_ENTRY(struct rte_flow_action_modify_field,
-   dst.level)),
+NEXT_ENTRY(ACTION_MODIFY_FIELD_DST_LEVEL_VALUE)),
.call = parse_vc_conf,
},
+   [ACTION_MODIFY_FIELD_DST_LEVEL_VALUE] = {
+   .name = "{dst_level}",
+   .help = "destination field level value",
+   .call = parse_vc_modify_field_level,
+   .comp = comp_none,
+   },
[ACTION_MODIFY_FIELD_DST_OFFSET] = {
.name = "dst_offset",
.help = "destination field bit offset",
@@ -6007,11 +6018,15 @@ static const struct token token_list[] = {
.name = "src_level",
.help = "source field level",
.next = NEXT(action_modify_field_src,
-NEXT_ENTRY(COMMON_UNSIGNED)),
-   .args = ARGS(ARGS_ENTRY(struct rte_flow_action_modify_field,
-   src.level)),
+NEXT_ENTRY(ACTION_MODIFY_FIELD_SRC_LEVEL_VALUE)),
.call = parse_vc_conf,
},
+   [ACTION_MODIFY_FIELD_SRC_LEVEL_VALUE] = {
+   .name = "{src_level}",
+   .help = "source field level value",
+   .call = parse_vc_modify_field_level,
+   .comp = comp_none,
+   },
[ACTION_MODIFY_FIELD_SRC_OFFSET] = {
.name = "src_offset",
.help = "source field bit offset",
@@ -8477,6 +8492,66 @@ parse_vc_modify_field_id(struct context *ctx, const 
struct token *token,
return len;
 }
 
+/** Parse level for modify_field command. */
+static int
+parse_vc_modify_field_level(struct context *ctx, const struct token *token,
+const char *str, unsigned int len, void *buf,
+unsigned int size)
+{
+   struct rte_flow_action_modify_field *action;
+   struct flex_item *fp;
+   uint32_t val;
+   struct buffer *out = buf;
+   char *end;
+
+   (void)token;
+   (void)size;
+ 

[PATCH v3 03/11] net/mlx5: enable hws flex item create

[Rongwei Liu]

Enable flex item create and destroy with dv_flow_en=2

Signed-off-by: Rongwei Liu 
Acked-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/linux/mlx5_os.c | 27 +++
 drivers/net/mlx5/mlx5_flow_hw.c  |  2 ++
 2 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index a71474c90a..f5b3edea99 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -474,10 +474,20 @@ mlx5_alloc_shared_dr(struct mlx5_priv *priv)
err = mlx5_alloc_table_hash_list(priv);
if (err)
goto error;
-   if (priv->sh->config.dv_flow_en == 2)
-   return 0;
/* The resources below are only valid with DV support. */
 #ifdef HAVE_IBV_FLOW_DV_SUPPORT
+   /* Init shared flex parsers list, no need lcore_share */
+   snprintf(s, sizeof(s), "%s_flex_parsers_list", sh->ibdev_name);
+   sh->flex_parsers_dv = mlx5_list_create(s, sh, false,
+  mlx5_flex_parser_create_cb,
+  mlx5_flex_parser_match_cb,
+  mlx5_flex_parser_remove_cb,
+  mlx5_flex_parser_clone_cb,
+  mlx5_flex_parser_clone_free_cb);
+   if (!sh->flex_parsers_dv)
+   goto error;
+   if (priv->sh->config.dv_flow_en == 2)
+   return 0;
/* Init port id action list. */
snprintf(s, sizeof(s), "%s_port_id_action_list", sh->ibdev_name);
sh->port_id_action_list = mlx5_list_create(s, sh, true,
@@ -518,16 +528,9 @@ mlx5_alloc_shared_dr(struct mlx5_priv *priv)
  flow_dv_dest_array_clone_free_cb);
if (!sh->dest_array_list)
goto error;
-   /* Init shared flex parsers list, no need lcore_share */
-   snprintf(s, sizeof(s), "%s_flex_parsers_list", sh->ibdev_name);
-   sh->flex_parsers_dv = mlx5_list_create(s, sh, false,
-  mlx5_flex_parser_create_cb,
-  mlx5_flex_parser_match_cb,
-  mlx5_flex_parser_remove_cb,
-  mlx5_flex_parser_clone_cb,
-  mlx5_flex_parser_clone_free_cb);
-   if (!sh->flex_parsers_dv)
-   goto error;
+#else
+   if (priv->sh->config.dv_flow_en == 2)
+   return 0;
 #endif
 #ifdef HAVE_MLX5DV_DR
void *domain;
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 952247d3cf..9406360a10 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -8340,6 +8340,8 @@ const struct mlx5_flow_driver_ops mlx5_flow_hw_drv_ops = {
.query = flow_hw_query,
.get_aged_flows = flow_hw_get_aged_flows,
.get_q_aged_flows = flow_hw_get_q_aged_flows,
+   .item_create = flow_dv_item_create,
+   .item_release = flow_dv_item_release,
 };
 
 /**
-- 
2.27.0

[PATCH v3 02/11] app/testpmd: pass flex handle into matching mask

[Rongwei Liu]

In async flow create API, there is only mask information when
creating flow table but flex item handle is required to parse
the HW sample information.

Pass the flex item handle instead of UINT64/32_MAX to mask.

Signed-off-by: Rongwei Liu 
Acked-by: Ori Kam 
---
 app/test-pmd/cmdline_flow.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 7c12d63cbc..9037432cc8 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -10068,8 +10068,8 @@ parse_flex_handle(struct context *ctx, const struct 
token *token,
}
if (offset == offsetof(struct rte_flow_item_flex, handle)) {
const struct flex_item *fp;
-   struct rte_flow_item_flex *item_flex = ctx->object;
-   handle = (uint16_t)(uintptr_t)item_flex->handle;
+   spec = ctx->object;
+   handle = (uint16_t)(uintptr_t)spec->handle;
if (handle >= FLEX_MAX_PARSERS_NUM) {
printf("Bad flex item handle\n");
return -1;
@@ -10079,7 +10079,9 @@ parse_flex_handle(struct context *ctx, const struct 
token *token,
printf("Bad flex item handle\n");
return -1;
}
-   item_flex->handle = fp->flex_handle;
+   spec->handle = fp->flex_handle;
+   mask = spec + 2; /* spec, last, mask */
+   mask->handle = fp->flex_handle;
} else if (offset == offsetof(struct rte_flow_item_flex, pattern)) {
handle = (uint16_t)(uintptr_t)
((struct rte_flow_item_flex *)ctx->object)->pattern;
-- 
2.27.0

[PATCH v3 05/11] net/mlx5: adopt new flex item prm definition

[Rongwei Liu]

Per newest PRM definition, sample_id stands for 3 parts
of information instead of single uint32_t id: sample_id +
modify_filed_id + format_select_dw.

Also new FW capability bits have been introduces to identify
the new capability.

Signed-off-by: Rongwei Liu 
Acked-by: Viacheslav Ovsiienko 
---
 drivers/common/mlx5/mlx5_devx_cmds.c | 14 +++---
 drivers/common/mlx5/mlx5_devx_cmds.h |  7 ++-
 drivers/common/mlx5/mlx5_prm.h   | 28 ++--
 drivers/net/mlx5/mlx5.c  | 15 +++
 drivers/net/mlx5/mlx5.h  |  3 ++-
 drivers/net/mlx5/mlx5_flow_flex.c| 14 +++---
 6 files changed, 67 insertions(+), 14 deletions(-)

diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c 
b/drivers/common/mlx5/mlx5_devx_cmds.c
index e3a4927d0f..1f65ea7dcb 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.c
+++ b/drivers/common/mlx5/mlx5_devx_cmds.c
@@ -607,7 +607,8 @@ mlx5_devx_cmd_query_hca_vdpa_attr(void *ctx,
 
 int
 mlx5_devx_cmd_query_parse_samples(struct mlx5_devx_obj *flex_obj,
- uint32_t ids[], uint32_t num)
+ struct mlx5_ext_sample_id ids[],
+ uint32_t num, uint8_t *anchor)
 {
uint32_t in[MLX5_ST_SZ_DW(general_obj_in_cmd_hdr)] = {0};
uint32_t out[MLX5_ST_SZ_DW(create_flex_parser_out)] = {0};
@@ -636,6 +637,7 @@ mlx5_devx_cmd_query_parse_samples(struct mlx5_devx_obj 
*flex_obj,
(void *)flex_obj);
return -rte_errno;
}
+   *anchor = MLX5_GET(parse_graph_flex, flex, head_anchor_id);
for (i = 0; i < MLX5_GRAPH_NODE_SAMPLE_NUM; i++) {
void *s_off = (void *)((char *)sample + i *
  MLX5_ST_SZ_BYTES(parse_graph_flow_match_sample));
@@ -645,8 +647,8 @@ mlx5_devx_cmd_query_parse_samples(struct mlx5_devx_obj 
*flex_obj,
  flow_match_sample_en);
if (!en)
continue;
-   ids[idx++] = MLX5_GET(parse_graph_flow_match_sample, s_off,
- flow_match_sample_field_id);
+   ids[idx++].id = MLX5_GET(parse_graph_flow_match_sample, s_off,
+flow_match_sample_field_id);
}
if (num != idx) {
rte_errno = EINVAL;
@@ -794,6 +796,12 @@ mlx5_devx_cmd_query_hca_parse_graph_node_cap
 max_num_arc_out);
attr->max_num_sample = MLX5_GET(parse_graph_node_cap, hcattr,
max_num_sample);
+   attr->anchor_en = MLX5_GET(parse_graph_node_cap, hcattr, anchor_en);
+   attr->ext_sample_id = MLX5_GET(parse_graph_node_cap, hcattr, 
ext_sample_id);
+   attr->sample_tunnel_inner2 = MLX5_GET(parse_graph_node_cap, hcattr,
+ sample_tunnel_inner2);
+   attr->zero_size_supported = MLX5_GET(parse_graph_node_cap, hcattr,
+zero_size_supported);
attr->sample_id_in_out = MLX5_GET(parse_graph_node_cap, hcattr,
  sample_id_in_out);
attr->max_base_header_length = MLX5_GET(parse_graph_node_cap, hcattr,
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h 
b/drivers/common/mlx5/mlx5_devx_cmds.h
index c94b9eac06..5b33010155 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.h
+++ b/drivers/common/mlx5/mlx5_devx_cmds.h
@@ -114,6 +114,10 @@ struct mlx5_hca_flex_attr {
uint8_t  max_num_arc_out;
uint8_t  max_num_sample;
uint8_t  max_num_prog_sample:5; /* From HCA CAP 2 */
+   uint8_t  anchor_en:1;
+   uint8_t  ext_sample_id:1;
+   uint8_t  sample_tunnel_inner2:1;
+   uint8_t  zero_size_supported:1;
uint8_t  sample_id_in_out:1;
uint16_t max_base_header_length;
uint8_t  max_sample_base_offset;
@@ -706,7 +710,8 @@ int mlx5_devx_cmd_modify_tir(struct mlx5_devx_obj *tir,
 struct mlx5_devx_modify_tir_attr *tir_attr);
 __rte_internal
 int mlx5_devx_cmd_query_parse_samples(struct mlx5_devx_obj *flex_obj,
- uint32_t ids[], uint32_t num);
+ struct mlx5_ext_sample_id ids[],
+ uint32_t num, uint8_t *anchor);
 
 __rte_internal
 struct mlx5_devx_obj *
diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index 9294f65e24..b32dc735a1 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -1894,7 +1894,11 @@ struct mlx5_ifc_parse_graph_node_cap_bits {
u8 max_num_arc_in[0x08];
u8 max_num_arc_out[0x08];
u8 max_num_sample[0x08];
-   u8 reserved_at_78[0x07];
+   u8 reserved_at_78[0x03];
+   u8 anchor_en[0x1];
+   u8 ext_sample_id[0x1];
+   u8 sample_tunnel_inner2[0x1];
+   u8 zero_size_supported[0x1];
u8 s

[PATCH v3 04/11] net/mlx5: add IPv6 protocol as flex item input

[Rongwei Liu]

Support IPv6 protocol as new flex item input link.

Signed-off-by: Rongwei Liu 
Acked-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/mlx5_flow_flex.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_flow_flex.c 
b/drivers/net/mlx5/mlx5_flow_flex.c
index fb08910ddb..bec07b13c1 100644
--- a/drivers/net/mlx5/mlx5_flow_flex.c
+++ b/drivers/net/mlx5/mlx5_flow_flex.c
@@ -1043,6 +1043,22 @@ mlx5_flex_arc_in_udp(const struct rte_flow_item *item,
return rte_be_to_cpu_16(spec->hdr.dst_port);
 }
 
+static int
+mlx5_flex_arc_in_ipv6(const struct rte_flow_item *item,
+ struct rte_flow_error *error)
+{
+   const struct rte_flow_item_ipv6 *spec = item->spec;
+   const struct rte_flow_item_ipv6 *mask = item->mask;
+   struct rte_flow_item_ipv6 ip = { .hdr.proto = 0xff };
+
+   if (memcmp(mask, &ip, sizeof(struct rte_flow_item_ipv6))) {
+   return rte_flow_error_set
+   (error, EINVAL, RTE_FLOW_ERROR_TYPE_ITEM, item,
+"invalid ipv6 item mask, full mask is desired");
+   }
+   return spec->hdr.proto;
+}
+
 static int
 mlx5_flex_translate_arc_in(struct mlx5_hca_flex_attr *attr,
   const struct rte_flow_item_flex_conf *conf,
@@ -1089,6 +1105,9 @@ mlx5_flex_translate_arc_in(struct mlx5_hca_flex_attr 
*attr,
case RTE_FLOW_ITEM_TYPE_UDP:
ret = mlx5_flex_arc_in_udp(rte_item, error);
break;
+   case RTE_FLOW_ITEM_TYPE_IPV6:
+   ret = mlx5_flex_arc_in_ipv6(rte_item, error);
+   break;
default:
MLX5_ASSERT(false);
return rte_flow_error_set
-- 
2.27.0

[PATCH v3 06/11] net/mlx5/hws: add hws flex item matching support

[Rongwei Liu]

Support flex item matching in hws and syntax follows
sws exactly.

Flex item should be created in advance and follow current
json mapping logic.

Signed-off-by: Rongwei Liu 
Reviewed-by: Alex Vesker 
Acked-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/hws/mlx5dr_definer.c |  83 ++
 drivers/net/mlx5/mlx5.c   |   2 +-
 drivers/net/mlx5/mlx5.h   |   6 ++
 drivers/net/mlx5/mlx5_flow.h  |   1 +
 drivers/net/mlx5/mlx5_flow_dv.c   |   2 +-
 drivers/net/mlx5/mlx5_flow_flex.c | 116 ++
 drivers/net/mlx5/mlx5_flow_hw.c   |  48 ++-
 7 files changed, 239 insertions(+), 19 deletions(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c 
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index 6b98eb8c96..a6378afb10 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -293,6 +293,43 @@ mlx5dr_definer_integrity_set(struct mlx5dr_definer_fc *fc,
DR_SET(tag, ok1_bits, fc->byte_off, fc->bit_off, fc->bit_mask);
 }
 
+static void
+mlx5dr_definer_flex_parser_set(struct mlx5dr_definer_fc *fc,
+  const void *item,
+  uint8_t *tag, bool is_inner)
+{
+   const struct rte_flow_item_flex *flex = item;
+   uint32_t byte_off, val, idx;
+   int ret;
+
+   val = 0;
+   byte_off = MLX5_BYTE_OFF(definer_hl, flex_parser.flex_parser_0);
+   idx = fc->fname - MLX5DR_DEFINER_FNAME_FLEX_PARSER_0;
+   byte_off -= idx * sizeof(uint32_t);
+   ret = mlx5_flex_get_parser_value_per_byte_off(flex, flex->handle, 
byte_off,
+ false, is_inner, &val);
+   if (ret == -1 || !val)
+   return;
+
+   DR_SET(tag, val, fc->byte_off, 0, fc->bit_mask);
+}
+
+static void
+mlx5dr_definer_flex_parser_inner_set(struct mlx5dr_definer_fc *fc,
+const void *item,
+uint8_t *tag)
+{
+   mlx5dr_definer_flex_parser_set(fc, item, tag, true);
+}
+
+static void
+mlx5dr_definer_flex_parser_outer_set(struct mlx5dr_definer_fc *fc,
+const void *item,
+uint8_t *tag)
+{
+   mlx5dr_definer_flex_parser_set(fc, item, tag, false);
+}
+
 static void
 mlx5dr_definer_gre_key_set(struct mlx5dr_definer_fc *fc,
   const void *item_spec,
@@ -1465,6 +1502,47 @@ mlx5dr_definer_conv_item_meter_color(struct 
mlx5dr_definer_conv_data *cd,
return 0;
 }
 
+static int
+mlx5dr_definer_conv_item_flex_parser(struct mlx5dr_definer_conv_data *cd,
+struct rte_flow_item *item,
+int item_idx)
+{
+   uint32_t base_off = MLX5_BYTE_OFF(definer_hl, 
flex_parser.flex_parser_0);
+   const struct rte_flow_item_flex *v, *m;
+   enum mlx5dr_definer_fname fname;
+   struct mlx5dr_definer_fc *fc;
+   uint32_t i, mask, byte_off;
+   bool is_inner = cd->tunnel;
+   int ret;
+
+   m = item->mask;
+   v = item->spec;
+   mask = 0;
+   for (i = 0; i < MLX5_GRAPH_NODE_SAMPLE_NUM; i++) {
+   byte_off = base_off - i * sizeof(uint32_t);
+   ret = mlx5_flex_get_parser_value_per_byte_off(m, v->handle, 
byte_off,
+ true, is_inner, 
&mask);
+   if (ret == -1) {
+   rte_errno = EINVAL;
+   return rte_errno;
+   }
+
+   if (!mask)
+   continue;
+
+   fname = MLX5DR_DEFINER_FNAME_FLEX_PARSER_0;
+   fname += (enum mlx5dr_definer_fname)i;
+   fc = &cd->fc[fname];
+   fc->byte_off = byte_off;
+   fc->item_idx = item_idx;
+   fc->tag_set = cd->tunnel ? 
&mlx5dr_definer_flex_parser_inner_set :
+  
&mlx5dr_definer_flex_parser_outer_set;
+   fc->tag_mask_set = &mlx5dr_definer_ones_set;
+   fc->bit_mask = mask;
+   }
+   return 0;
+}
+
 static int
 mlx5dr_definer_conv_items_to_hl(struct mlx5dr_context *ctx,
struct mlx5dr_match_template *mt,
@@ -1581,6 +1659,11 @@ mlx5dr_definer_conv_items_to_hl(struct mlx5dr_context 
*ctx,
ret = mlx5dr_definer_conv_item_meter_color(&cd, items, 
i);
item_flags |= MLX5_FLOW_ITEM_METER_COLOR;
break;
+   case RTE_FLOW_ITEM_TYPE_FLEX:
+   ret = mlx5dr_definer_conv_item_flex_parser(&cd, items, 
i);
+   item_flags |= cd.tunnel ? MLX5_FLOW_ITEM_INNER_FLEX :
+ MLX5_FLOW_ITEM_OUTER_FLEX;
+   break;
default:
DR_LOG(ERR, "Unsupported item type %d", items->type);

[PATCH v3 07/11] net/mlx5: add flex item modify field implementation

[Rongwei Liu]

Add flex item modify field HWS implementation.
The minimum modify boundary is one byte.

Signed-off-by: Rongwei Liu 
Acked-by: Viacheslav Ovsiienko 
---
 drivers/common/mlx5/mlx5_prm.h  |   1 +
 drivers/net/mlx5/mlx5_flow.h|   3 +
 drivers/net/mlx5/mlx5_flow_dv.c | 165 +---
 drivers/net/mlx5/mlx5_flow_hw.c |  14 ++-
 4 files changed, 170 insertions(+), 13 deletions(-)

diff --git a/drivers/common/mlx5/mlx5_prm.h b/drivers/common/mlx5/mlx5_prm.h
index b32dc735a1..bb3452f74c 100644
--- a/drivers/common/mlx5/mlx5_prm.h
+++ b/drivers/common/mlx5/mlx5_prm.h
@@ -760,6 +760,7 @@ enum mlx5_modification_field {
MLX5_MODI_TUNNEL_HDR_DW_1 = 0x75,
MLX5_MODI_GTPU_FIRST_EXT_DW_0 = 0x76,
MLX5_MODI_HASH_RESULT = 0x81,
+   MLX5_MODI_INVALID = INT_MAX,
 };
 
 /* Total number of metadata reg_c's. */
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index c8761c4e5a..c71fa1c0ad 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1080,6 +1080,8 @@ struct field_modify_info {
uint32_t size; /* Size of field in protocol header, in bytes. */
uint32_t offset; /* Offset of field in protocol header, in bytes. */
enum mlx5_modification_field id;
+   uint32_t shift;
+   uint8_t is_flex; /* Temporary indicator for flex item modify filed WA. 
*/
 };
 
 /* HW steering flow attributes. */
@@ -1244,6 +1246,7 @@ struct rte_flow_actions_template {
uint16_t mhdr_off; /* Offset of DR modify header action. */
uint32_t refcnt; /* Reference counter. */
uint16_t rx_cpy_pos; /* Action position of Rx metadata to be copied. */
+   uint8_t flex_item; /* flex item index. */
 };
 
 /* Jump action struct. */
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 284f18da11..92a5914d4b 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -414,10 +414,15 @@ flow_dv_convert_modify_action(struct rte_flow_item *item,
++field;
continue;
}
-   /* Deduce actual data width in bits from mask value. */
-   off_b = rte_bsf32(mask) + carry_b;
-   size_b = sizeof(uint32_t) * CHAR_BIT -
-off_b - __builtin_clz(mask);
+   if (type == MLX5_MODIFICATION_TYPE_COPY && field->is_flex) {
+   off_b = 32 - field->shift + carry_b - field->size * 
CHAR_BIT;
+   size_b = field->size * CHAR_BIT - carry_b;
+   } else {
+   /* Deduce actual data width in bits from mask value. */
+   off_b = rte_bsf32(mask) + carry_b;
+   size_b = sizeof(uint32_t) * CHAR_BIT -
+off_b - __builtin_clz(mask);
+   }
MLX5_ASSERT(size_b);
actions[i] = (struct mlx5_modification_cmd) {
.action_type = type,
@@ -437,40 +442,46 @@ flow_dv_convert_modify_action(struct rte_flow_item *item,
 * Destination field overflow. Copy leftovers of
 * a source field to the next destination field.
 */
-   carry_b = 0;
if ((size_b > dcopy->size * CHAR_BIT - dcopy->offset) &&
dcopy->size != 0) {
actions[i].length =
dcopy->size * CHAR_BIT - dcopy->offset;
-   carry_b = actions[i].length;
+   carry_b += actions[i].length;
next_field = false;
+   } else {
+   carry_b = 0;
}
/*
 * Not enough bits in a source filed to fill a
 * destination field. Switch to the next source.
 */
if ((size_b < dcopy->size * CHAR_BIT - dcopy->offset) &&
-   (size_b == field->size * CHAR_BIT - off_b)) {
-   actions[i].length =
-   field->size * CHAR_BIT - off_b;
+   ((size_b == field->size * CHAR_BIT - off_b) ||
+field->is_flex)) {
+   actions[i].length = size_b;
dcopy->offset += actions[i].length;
next_dcopy = false;
}
-   if (next_dcopy)
-   ++dcopy;
} else {
MLX5_ASSERT(item->spec);
data = flow_dv_fetch_field((const uint8_t *)item->spec +
   field->offset, field->size);
 

[PATCH v3 08/11] net/mlx5: return error for sws modify field

[Rongwei Liu]

Return unsupported error message when application tries to
modify flex item field.

Validation of packet modifications actions for SW Steering checked
if either source or destination field of MODIFY_FIELD action
was a flex item.
When DEC_TTL action is used, DEC_TTL action does not have any
action configuration and dereferencing source or destination field
is invalid, so validation of source and destination field types
should be moved to MODIFY_FIELD specific validation function, then
field types are validated if and only if action type is MODIFY_FIELD.

Signed-off-by: Dariusz Sosnowski 
Signed-off-by: Rongwei Liu 
Acked-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/mlx5_flow_dv.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 92a5914d4b..a7c0d5bf17 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -4828,6 +4828,7 @@ flow_dv_validate_action_modify_hdr(const uint64_t 
action_flags,
return rte_flow_error_set(error, EINVAL,
  RTE_FLOW_ERROR_TYPE_ACTION_CONF,
  NULL, "action configuration not set");
+
if (action_flags & MLX5_FLOW_ACTION_ENCAP)
return rte_flow_error_set(error, EINVAL,
  RTE_FLOW_ERROR_TYPE_ACTION, NULL,
@@ -5153,17 +5154,21 @@ flow_dv_validate_action_modify_field(struct rte_eth_dev 
*dev,
struct mlx5_hca_attr *hca_attr = &priv->sh->cdev->config.hca_attr;
const struct rte_flow_action_modify_field *action_modify_field =
action->conf;
-   uint32_t dst_width = mlx5_flow_item_field_width(dev,
-   action_modify_field->dst.field,
-   -1, attr, error);
-   uint32_t src_width = mlx5_flow_item_field_width(dev,
-   action_modify_field->src.field,
-   dst_width, attr, error);
+   uint32_t dst_width, src_width;
 
ret = flow_dv_validate_action_modify_hdr(action_flags, action, error);
if (ret)
return ret;
-
+   if (action_modify_field->src.field == RTE_FLOW_FIELD_FLEX_ITEM ||
+   action_modify_field->dst.field == RTE_FLOW_FIELD_FLEX_ITEM)
+   return rte_flow_error_set(error, ENOTSUP,
+   RTE_FLOW_ERROR_TYPE_ACTION, action,
+   "flex item fields modification"
+   " is not supported");
+   dst_width = mlx5_flow_item_field_width(dev, 
action_modify_field->dst.field,
+  -1, attr, error);
+   src_width = mlx5_flow_item_field_width(dev, 
action_modify_field->src.field,
+  dst_width, attr, error);
if (action_modify_field->width == 0)
return rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_ACTION, action,
-- 
2.27.0

[PATCH v3 09/11] app/testpmd: raw encap with flex item support

[Rongwei Liu]

Application should retrieve raw_encap buffer from
spec->pattern if it is flex item.

Signed-off-by: Rongwei Liu 
Acked-by: Ori Kam 
---
 app/test-pmd/cmdline_flow.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 9037432cc8..3b2975ee83 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -11193,6 +11193,7 @@ cmd_set_raw_parsed(const struct buffer *in)
uint16_t proto = 0;
uint16_t idx = in->port; /* We borrow port field as index */
int gtp_psc = -1; /* GTP PSC option index. */
+   const void *src_spec;
 
if (in->command == SET_SAMPLE_ACTIONS)
return cmd_set_raw_parsed_sample(in);
@@ -11216,6 +11217,7 @@ cmd_set_raw_parsed(const struct buffer *in)
item = in->args.vc.pattern + i;
if (item->spec == NULL)
item->spec = flow_item_default_mask(item);
+   src_spec = item->spec;
switch (item->type) {
case RTE_FLOW_ITEM_TYPE_ETH:
size = sizeof(struct rte_ether_hdr);
@@ -11343,9 +11345,13 @@ cmd_set_raw_parsed(const struct buffer *in)
size = sizeof(struct rte_flow_item_pfcp);
break;
case RTE_FLOW_ITEM_TYPE_FLEX:
-   size = item->spec ?
-   ((const struct rte_flow_item_flex *)
-   item->spec)->length : 0;
+   if (item->spec != NULL) {
+   size = ((const struct rte_flow_item_flex 
*)item->spec)->length;
+   src_spec = ((const struct rte_flow_item_flex 
*)item->spec)->pattern;
+   } else {
+   size = 0;
+   src_spec = NULL;
+   }
break;
case RTE_FLOW_ITEM_TYPE_GRE_OPTION:
size = 0;
@@ -11378,12 +11384,14 @@ cmd_set_raw_parsed(const struct buffer *in)
fprintf(stderr, "Error - Not supported item\n");
goto error;
}
-   *total_size += size;
-   rte_memcpy(data_tail - (*total_size), item->spec, size);
-   /* update some fields which cannot be set by cmdline */
-   update_fields((data_tail - (*total_size)), item,
- upper_layer);
-   upper_layer = proto;
+   if (size) {
+   *total_size += size;
+   rte_memcpy(data_tail - (*total_size), src_spec, size);
+   /* update some fields which cannot be set by cmdline */
+   update_fields((data_tail - (*total_size)), item,
+ upper_layer);
+   upper_layer = proto;
+   }
}
if (verbose_level & 0x1)
printf("total data size is %zu\n", (*total_size));
-- 
2.27.0

[PATCH v3 10/11] doc/mlx5: update mlx5 doc

[Rongwei Liu]

Add flex item matching and modify field feature into
mlx5 documents.

Signed-off-by: Rongwei Liu 
Acked-by: Ori Kam 
---
 doc/guides/nics/mlx5.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index f137f156f9..aceeeb462c 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -106,6 +106,7 @@ Features
 - Sub-Function representors.
 - Sub-Function.
 - Matching on represented port.
+- Modify flex item field.
 
 
 Limitations
-- 
2.27.0

[PATCH v3 11/11] app/testpmd: adjust cleanup sequence when quitting

[Rongwei Liu]

If flex item is referenced in async flow either by
pattern template or action template, currently testpmd
complains "flex item has flow references". Flex items should
be flushed after async flow resources cleanup.

Signed-off-by: Rongwei Liu 
Acked-by: Ori Kam 
---
 app/test-pmd/testpmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 134d79a555..e35f7a0e7a 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -3298,10 +3298,10 @@ flush_port_owned_resources(portid_t pi)
 {
mcast_addr_pool_destroy(pi);
port_flow_flush(pi);
-   port_flex_item_flush(pi);
port_flow_template_table_flush(pi);
port_flow_pattern_template_flush(pi);
port_flow_actions_template_flush(pi);
+   port_flex_item_flush(pi);
port_action_handle_flush(pi);
 }
 
-- 
2.27.0

RE: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob

[Ankur Dwivedi]

>-Original Message-
>From: Ferruh Yigit 
>Sent: Wednesday, January 25, 2023 9:40 PM
>To: Ankur Dwivedi ; dev@dpdk.org
>Cc: tho...@monjalon.net; david.march...@redhat.com; m...@ashroe.eu;
>or...@nvidia.com; ch...@att.com; humi...@huawei.com;
>linvi...@tuxdriver.com; ciara.lof...@intel.com; qi.z.zh...@intel.com;
>m...@semihalf.com; m...@semihalf.com; shaib...@amazon.com;
>evge...@amazon.com; igo...@amazon.com; cha...@amd.com; Igor
>Russkikh ; shepard.sie...@atomicrules.com;
>ed.cz...@atomicrules.com; john.mil...@atomicrules.com;
>ajit.khapa...@broadcom.com; somnath.ko...@broadcom.com; Jerin Jacob
>Kollanukkaran ; Maciej Czekaj [C]
>; Shijith Thotton ;
>Srisivasubramanian Srinivasan ; Harman Kalra
>; rahul.lakkire...@chelsio.com; johnd...@cisco.com;
>hyon...@cisco.com; liudongdo...@huawei.com;
>yisen.zhu...@huawei.com; xuanziya...@huawei.com;
>cloud.wangxiao...@huawei.com; zhouguoy...@huawei.com;
>simei...@intel.com; wenjun1...@intel.com; qiming.y...@intel.com;
>yuying.zh...@intel.com; beilei.x...@intel.com; xiao.w.w...@intel.com;
>jingjing...@intel.com; junfeng@intel.com; rosen...@intel.com; Nithin
>Kumar Dabilpuram ; Kiran Kumar Kokkilagadda
>; Sunil Kumar Kori ; Satha
>Koteswara Rao Kottidi ; Liron Himi
>; z...@semihalf.com; Radha Chintakuntla
>; Veerasenareddy Burru ;
>Sathesh B Edara ; ma...@nvidia.com;
>viachesl...@nvidia.com; lon...@microsoft.com; spin...@cesnet.cz;
>chaoyong...@corigine.com; niklas.soderl...@corigine.com;
>hemant.agra...@nxp.com; sachin.sax...@oss.nxp.com; g.si...@nxp.com;
>apeksha.gu...@nxp.com; sachin.sax...@nxp.com; abo...@pensando.io;
>Rasesh Mody ; Shahed Shaikh
>; Devendra Singh Rawat
>; andrew.rybche...@oktetlabs.ru;
>jiawe...@trustnetic.com; jianw...@trustnetic.com;
>jbehr...@vmware.com; maxime.coque...@redhat.com;
>chenbo@intel.com; steven.webs...@windriver.com;
>matt.pet...@windriver.com; bruce.richard...@intel.com;
>mtetsu...@gmail.com; gr...@u256.net; jasvinder.si...@intel.com;
>cristian.dumitre...@intel.com; jgraj...@cisco.com;
>m...@smartsharesystems.com
>Subject: Re: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob
>
>On 1/25/2023 3:02 PM, Ankur Dwivedi wrote:
>>
>>>
>>> -
>>> - On 1/20/2023 8:40 AM, Ankur Dwivedi wrote:
 Adds a trace point emit function for capturing a blob. The blob
 captures the length passed by the application followed by the array.

 The maximum blob bytes which can be captured is bounded by
 RTE_TRACE_BLOB_LEN_MAX macro. The value for max blob length macro
>is
 64 bytes. If the length is less than 64 the remaining trailing bytes
 are set to zero.

 This patch also adds test case for emit blob tracepoint function.

 Signed-off-by: Ankur Dwivedi 
 ---
  app/test/test_trace.c  | 11 
  doc/guides/prog_guide/trace_lib.rst| 12 
  lib/eal/common/eal_common_trace_points.c   |  2 ++
  lib/eal/include/rte_eal_trace.h|  6 
  lib/eal/include/rte_trace_point.h  | 32 ++
  lib/eal/include/rte_trace_point_register.h |  9 ++
  lib/eal/version.map|  3 ++
  7 files changed, 75 insertions(+)

 diff --git a/app/test/test_trace.c b/app/test/test_trace.c index
 6bedf14024..ad4a394a29 100644
 --- a/app/test/test_trace.c
 +++ b/app/test/test_trace.c
 @@ -4,6 +4,7 @@

  #include 
  #include 
 +#include 
  #include 

  #include "test.h"
 @@ -177,7 +178,12 @@ test_fp_trace_points(void)  static int
  test_generic_trace_points(void)
  {
 +  uint8_t arr[RTE_TRACE_BLOB_LEN_MAX];
int tmp;
 +  int i;
 +
 +  for (i = 0; i < RTE_TRACE_BLOB_LEN_MAX; i++)
 +  arr[i] = i;

rte_eal_trace_generic_void();
rte_eal_trace_generic_u64(0x10);
 @@ -195,6 +201,11 @@ test_generic_trace_points(void)
rte_eal_trace_generic_ptr(&tmp);
rte_eal_trace_generic_str("my string");
rte_eal_trace_generic_size_t(sizeof(void *));
 +  rte_eal_trace_generic_blob(arr, 0);
 +  rte_eal_trace_generic_blob(arr, 17);
 +  rte_eal_trace_generic_blob(arr, RTE_TRACE_BLOB_LEN_MAX);
 +  rte_eal_trace_generic_blob(arr, rte_rand() %
 +  RTE_TRACE_BLOB_LEN_MAX);
RTE_EAL_TRACE_GENERIC_FUNC;

return TEST_SUCCESS;
 diff --git a/doc/guides/prog_guide/trace_lib.rst
 b/doc/guides/prog_guide/trace_lib.rst
 index 9a8f38073d..3e0ea5835c 100644
 --- a/doc/guides/prog_guide/trace_lib.rst
 +++ b/doc/guides/prog_guide/trace_lib.rst
 @@ -352,3 +352,15 @@ event ID.
  The ``packet.header`` and ``packet.context`` will be written in the
 slow path  at the time of trace memory creation. The
 ``trace.header`` and trace payload  will be emitted when the tracepoint
>function is invoked.
 +

Re: [PATCH v2 1/2] vhost: fix possible FDs leak

[David Marchand]

On Mon, Jan 30, 2023 at 10:46 AM Maxime Coquelin
 wrote:
>
>
>
> On 1/29/23 10:25, David Marchand wrote:
> > On Fri, Jan 27, 2023 at 5:55 PM Maxime Coquelin
> >  wrote:
> >>
> >> On failure, read_vhost_message() only closed the message
> >> FDs if the header size was unexpected, but there are other
> >> cases where it is required. For exemple in the case the
> >> payload size read from the header is greater than the
> >> expected maximum payload size.
> >>
> >> This patch fixes this by closing all messages FDs in all
> >> error cases.
> >>
> >> Fixes: bf472259dde6 ("vhost: fix possible denial of service by leaking 
> >> FDs")
> >> Cc: sta...@dpdk.org
> >>
> >> Signed-off-by: Maxime Coquelin 
> >
> > Reviewed-by: David Marchand 
> >
> > We mentionned offlist that the request type can be logged to help with 
> > debug.
> > Do you intend to add this as a follow up patch?
> >
> >
>
> Thinking about it, that's not that trivial because read_vhost_message()
> is called for both master and slave channels, so we would need to
> differentiate between both to print proper request name.
>
> It is doable by comparing the file descriptor passed as parameter with
> the slave one stored in struct virtio_net, but that's not super clean.

>From the 3 different callers of read_vhost_message, I think the only
one that could gain from this debug is vhost_user_msg_handler().

And here, we could look at the message content on read_vhost_message return.
Like this untested and ugly snippet:

diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c
index 943058725e..1556f21a58 100644
--- a/lib/vhost/vhost_user.c
+++ b/lib/vhost/vhost_user.c
@@ -2994,13 +2994,10 @@ vhost_user_msg_handler(int vid, int fd)
}
}

+   ctx.msg.request.master = VHOST_USER_NONE;
ret = read_vhost_message(dev, fd, &ctx);
-   if (ret <= 0) {
-   if (ret < 0)
-   VHOST_LOG_CONFIG(dev->ifname, ERR, "vhost read
message failed\n");
-   else
-   VHOST_LOG_CONFIG(dev->ifname, INFO, "vhost
peer closed\n");
-
+   if (ret == 0) {
+   VHOST_LOG_CONFIG(dev->ifname, INFO, "vhost peer closed\n");
return -1;
}

@@ -3010,6 +3007,14 @@ vhost_user_msg_handler(int vid, int fd)
else
msg_handler = NULL;

+   if (ret < 0) {
+   VHOST_LOG_CONFIG(dev->ifname, ERR, "vhost read message
%s%s%sfailed\n",
+   msg_handler != NULL ? "for " : "",
+   msg_handler != NULL ? msg_handler->description : "",
+   msg_handler != NULL ? " " : "");
+   return -1;
+   }
+
if (msg_handler != NULL && msg_handler->description != NULL) {
if (request != VHOST_USER_IOTLB_MSG)
VHOST_LOG_CONFIG(dev->ifname, INFO,


-- 
David Marchand

RE: [PATCH] test/crypto: fix typo in AES test

[Ji, Kai]

Acked-by: Kai Ji 

> -Original Message-
> From: Vikash Poddar 
> Sent: Monday, January 30, 2023 12:03 PM
> To: Thomas Monjalon ; Akhil Goyal
> ; Fan Zhang 
> Cc: dev@dpdk.org; Poddar, Vikash ChandraX
> ; shi...@nvidia.com
> Subject: [PATCH] test/crypto: fix typo in AES test
> 
> Fix the spelling of scater to scatter in cryptodev AES test vector
> header file
> 
> Fixes: 2692b02e03b2 ("test/crypto: add multi-segment out-of-place AES-
> XTS")
> Cc: shi...@nvidia.com
> 
> Signed-off-by: Vikash Poddar 
> ---
>  .mailmap   |  1 +
>  app/test/test_cryptodev_aes_test_vectors.h | 16 
>  2 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/.mailmap b/.mailmap
> index 75884b6fe2..c6650e32f6 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -1386,6 +1386,7 @@ Vijay Kumar Srivastava 
> Vijay Srivastava   Vikas Aggarwal
> 
>  Vikas Gupta 
> +Vikash Poddar 
>  Vimal Chungath 
>  Vincent Guo 
>  Vincent Jardin  diff --git
> a/app/test/test_cryptodev_aes_test_vectors.h
> b/app/test/test_cryptodev_aes_test_vectors.h
> index ea7b21ce53..f3686beeb5 100644
> --- a/app/test/test_cryptodev_aes_test_vectors.h
> +++ b/app/test/test_cryptodev_aes_test_vectors.h
> @@ -4969,7 +4969,7 @@ static const struct blockcipher_test_case
> aes_cipheronly_test_cases[] = {
>   },
>   {
>   .test_descr = "AES-256-XTS Encryption (512-byte plaintext"
> -   " Dataunit 512) Scater gather OOP",
> +   " Dataunit 512) Scatter gather OOP",
>   .test_data = &aes_test_data_xts_wrapped_key_48_pt_512_du_512,
>   .op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
>   .feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP | @@ -4979,7
> +4979,7 @@ static const struct blockcipher_test_case
> aes_cipheronly_test_cases[] = {
>   },
>   {
>   .test_descr = "AES-256-XTS Decryption (512-byte plaintext"
> -   " Dataunit 512) Scater gather OOP",
> +   " Dataunit 512) Scatter gather OOP",
>   .test_data = &aes_test_data_xts_wrapped_key_48_pt_512_du_512,
>   .op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
>   .feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP | @@ -4989,7
> +4989,7 @@ static const struct blockcipher_test_case
> aes_cipheronly_test_cases[] = {
>   },
>   {
>   .test_descr = "AES-256-XTS Encryption (512-byte plaintext"
> -   " Dataunit 0) Scater gather OOP",
> +   " Dataunit 0) Scatter gather OOP",
>   .test_data = &aes_test_data_xts_wrapped_key_48_pt_512_du_0,
>   .op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
>   .feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP | @@ -4999,7
> +4999,7 @@ static const struct blockcipher_test_case
> aes_cipheronly_test_cases[] = {
>   },
>   {
>   .test_descr = "AES-256-XTS Decryption (512-byte plaintext"
> -   " Dataunit 0) Scater gather OOP",
> +   " Dataunit 0) Scatter gather OOP",
>   .test_data = &aes_test_data_xts_wrapped_key_48_pt_512_du_0,
>   .op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
>   .feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP | @@ -5009,7
> +5009,7 @@ static const struct blockcipher_test_case
> aes_cipheronly_test_cases[] = {
>   },
>   {
>   .test_descr = "AES-256-XTS Encryption (4096-byte plaintext"
> -   " Dataunit 4096) Scater gather OOP",
> +   " Dataunit 4096) Scatter gather OOP",
>   .test_data =
> &aes_test_data_xts_wrapped_key_48_pt_4096_du_4096,
>   .op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
>   .feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP | @@ -5019,7
> +5019,7 @@ static const struct blockcipher_test_case
> aes_cipheronly_test_cases[] = {
>   },
>   {
>   .test_descr = "AES-256-XTS Decryption (4096-byte plaintext"
> -   " Dataunit 4096) Scater gather OOP",
> +   " Dataunit 4096) Scatter gather OOP",
>   .test_data =
> &aes_test_data_xts_wrapped_key_48_pt_4096_du_4096,
>   .op_mask = BLOCKCIPHER_TEST_OP_DECRYPT,
>   .feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP | @@ -5029,7
> +5029,7 @@ static const struct blockcipher_test_case
> aes_cipheronly_test_cases[] = {
>   },
>   {
>   .test_descr = "AES-256-XTS Encryption (4096-byte plaintext"
> -   " Dataunit 0) Scater gather OOP",
> +   " Dataunit 0) Scatter gather OOP",
>   .test_data = &aes_test_data_xts_wrapped_key_48_pt_4096_du_0,
>   .op_mask = BLOCKCIPHER_TEST_OP_ENCRYPT,
>   .feature_mask = BLOCKCIPHER_TEST_FEATURE_OOP | @@ -5039,7
> +5039,7 @@ static const struct blockcipher_test_case
> aes_cipheronly_test_cases[] = 

Re: [PATCH v2] eventdev: add trace points

[Jerin Jacob]

On Mon, Jan 30, 2023 at 3:44 PM Amit Prakash Shukla
 wrote:
>
> Add trace points for eventdev functions.
>
> Signed-off-by: Amit Prakash Shukla 
> ---

> diff --git a/lib/eventdev/version.map b/lib/eventdev/version.map
> index 4405cd38eb..f6ab242a3d 100644
> --- a/lib/eventdev/version.map
> +++ b/lib/eventdev/version.map
> @@ -121,6 +121,60 @@ EXPERIMENTAL {
>
> # added in 23.03
> rte_event_timer_remaining_ticks_get;

Following updates are not needed in version.map based on the
discussion happened ethdev trace thread as it is not required to
expose the symbol.

> +   __rte_eventdev_trace_eth_rx_adapter_caps_get;
> +   __rte_eventdev_trace_eth_tx_adapter_caps_get;
> +   __rte_eventdev_trace_timer_adapter_caps_get;
> +   __rte_eventdev_trace_crypto_adapter_caps_get;
> +   __rte_eventdev_trace_crypto_adapter_event_port_get;
> +   __rte_eventdev_trace_crypto_adapter_service_id_get;
> +   __rte_eventdev_trace_eth_rx_adapter_cb_register;
> +   __rte_eventdev_trace_eth_rx_adapter_create_with_params;
> +   __rte_eventdev_trace_eth_rx_adapter_queue_conf_get;
> +   __rte_eventdev_trace_eth_rx_adapter_service_id_get;
> +   __rte_eventdev_trace_eth_rx_adapter_vector_limits_get;
> +   __rte_eventdev_trace_eth_tx_adapter_event_port_get;
> +   __rte_eventdev_trace_eth_tx_adapter_service_id_get;
> +   __rte_eventdev_trace_port_attr_get;
> +   __rte_eventdev_trace_port_default_conf_get;
> +   __rte_eventdev_trace_port_links_get;
> +   __rte_eventdev_trace_port_quiesce;
> +   __rte_eventdev_trace_port_unlinks_in_progress;
> +   __rte_eventdev_trace_queue_attr_get;
> +   __rte_eventdev_trace_queue_attr_set;
> +   __rte_eventdev_trace_queue_default_conf_get;
> +   __rte_eventdev_trace_ring_create;
> +   __rte_eventdev_trace_ring_free;
> +   __rte_eventdev_trace_ring_init;
> +   __rte_eventdev_trace_ring_lookup;
> +   __rte_eventdev_trace_timer_adapter_get_info;
> +   __rte_eventdev_trace_timer_adapter_lookup;
> +   __rte_eventdev_trace_timer_adapter_service_id_get;
> +   __rte_eventdev_trace_attr_get;
> +   __rte_eventdev_trace_close;
> +   __rte_eventdev_trace_configure;
> +   __rte_eventdev_trace_dump;
> +   __rte_eventdev_trace_get_dev_id;
> +   __rte_eventdev_trace_info_get;
> +   __rte_eventdev_trace_selftest;
> +   __rte_eventdev_trace_service_id_get;
> +   __rte_eventdev_trace_socket_id;
> +   __rte_eventdev_trace_start;
> +   __rte_eventdev_trace_stop;
> +   __rte_eventdev_trace_stop_flush_callback_register;
> +   __rte_eventdev_trace_vector_pool_create;
> +   __rte_eventdev_trace_dequeue_timeout_ticks;
> +   __rte_eventdev_trace_crypto_adapter_stats_get;
> +   __rte_eventdev_trace_crypto_adapter_stats_reset;
> +   __rte_eventdev_trace_eth_rx_adapter_stats_get;
> +   __rte_eventdev_trace_crypto_adapter_vector_limits_get;
> +   __rte_eventdev_trace_eth_rx_adapter_queue_stats_get;
> +   __rte_eventdev_trace_eth_rx_adapter_stats_reset;
> +   __rte_eventdev_trace_eth_rx_adapter_queue_stats_reset;
> +   __rte_eventdev_trace_eth_rx_adapter_event_port_get;
> +   __rte_eventdev_trace_eth_rx_adapter_instance_get;
> +   __rte_eventdev_trace_eth_tx_adapter_stats_get;
> +   __rte_eventdev_trace_eth_tx_adapter_stats_reset;
> +   __rte_eventdev_trace_eth_tx_adapter_instance_get;
>  };
>
>  INTERNAL {
> --
> 2.25.1
>

Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs

[Jerin Jacob]

On Mon, Jan 30, 2023 at 3:26 PM Naga Harish K, S V
 wrote:
>
>
>
> > -Original Message-
> > From: Jerin Jacob 
> > Sent: Saturday, January 28, 2023 4:24 PM
> > To: Naga Harish K, S V 
> > Cc: jer...@marvell.com; Carrillo, Erik G ; 
> > Gujjar,
> > Abhinandan S ; dev@dpdk.org;
> > Jayatheerthan, Jay 
> > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
> >  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Jerin Jacob 
> >
> > > > > > >
> > > > > > > > > +*/
> > > > > > > > > +   uint32_t rsvd[15];
> > > > > > > > > +   /**< Reserved fields for future use */
> > > > > > > >
> > > > > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to
> > > > make
> > > > > > > > sure rsvd is zero.
> > > > > > > >
> > > > > > >
> > > > > > > The reserved fields are not used by the adapter or application.
> > > > > > > Not sure Is it necessary to Introduce a new API to clear reserved
> > fields.
> > > > > >
> > > > > > When adapter starts using new fileds(when we add new fieds in
> > > > > > future), the old applicaiton which is not using
> > > > > > rte_event_eth_rx_adapter_runtime_params_init() may have junk
> > > > > > value and then adapter implementation will behave bad.
> > > > > >
> > > > > >
> > > > >
> > > > > does it mean, the application doesn't re-compile for the new DPDK?
> > > >
> > > > Yes. No need recompile if ABI not breaking.
> > > >
> > > > > When some of the reserved fields are used in the future, the
> > > > > application
> > > > also may need to be recompiled along with DPDK right?
> > > > > As the application also may need to use the newly consumed
> > > > > reserved
> > > > fields?
> > > >
> > > > The problematic case is:
> > > >
> > > > Adapter implementation of 23.07(Assuming there is change params)
> > > > field needs to work with application of 23.03.
> > > > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> > > >
> > >
> > > As rte_event_eth_rx_adapter_runtime_params_init() initializes only
> > reserved fields to zero,  it may not solve the issue in this case.
> >
> > rte_event_eth_rx_adapter_runtime_params_init() needs to zero all fields,
> > not just reserved field.
> > The application calling sequence  is
> >
> > struct my_config c;
> > rte_event_eth_rx_adapter_runtime_params_init(&c)
> > c.interseted_filed_to_be_updated = val;
> >
> Can it be done like
> struct my_config c = {0};
> c.interseted_filed_to_be_updated = val;
> and update Doxygen comments to recommend above usage to reset all fields?
> This way,  rte_event_eth_rx_adapter_runtime_params_init() can be avoided.

Better to have a function for documentation clarity. Similar scheme
already there
in DPDK. See rte_eth_cman_config_init()


>
> > Let me share an example and you can tell where is the issue
> >
> > 1)Assume parameter structure is 64B and for 22.03 8B are used.
> > 2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B.
> > 3)There is an application written based on 22.03 which using only 8B after
> > calling rte_event_eth_rx_adapter_runtime_params_init()
> > 4)Assume, in 22.07 another 8B added to structure.
> > 5)Now, the application (3) needs to run on 22.07. Since the application is
> > calling rte_event_eth_rx_adapter_runtime_params_init()
> > and 9 to 15B are zero, the implementation will not go bad.
> >
> > > The old application only tries to set/get previous valid fields and the 
> > > newly
> > used fields may still contain junk value.
> > > If the application wants to make use of any the newly used params, the
> > application changes are required anyway.
> >
> > Yes. If application wants to make use of newly added features. No need to
> > change if new features are not needed for old application.

Re: [RFC] ethdev: add template table insertion and matching types

[Thomas Monjalon]

23/01/2023 23:02, Alexander Kozyrev:
> > 21/01/2023 00:06, Alexander Kozyrev:
> > > > 14/12/2022 03:21, Alexander Kozyrev:
> > > > > Bring more flexibility and control over both flow rule insertion
> > > > > and packet matching mechanisms. Introduce 2 new flow table types:
> > > > >
> > > > > 1. Allow a user to specify the insertion type used in template tables.
> > > > > The insertion type is responsible for choosing the appropriate key
> > > > > value used to map inserted flow rules into a template table.
> > > > >
> > > > > Flow rules can be inserted by calculating the hash value for
> > > > > the pattern or inserted by index via the new create_by_index() API.
> > > > > The idea of the index-based insertion is to avoid additional matches
> > > > > and simply execute predefined actions after jumping to the index.
> > > >
> > > > I don't understand the idea.
> > > > Why is it avoiding additional matches?
> > >
> > > If you jump directly to an index in a table, you don't need to match
> > anything.
> > > For the regular pattern-based table you must calculate the hash and match
> > on it.
> > 
> > I don't get it. I think it would be simpler with an example.
> 
> This is how the regular pattern-based table works:
> you calculate hash on 5-tuple, go to the table entry with the corresponding 
> hash,
> check if there is a collision and search for the proper entry if so, execute 
> actions.
> Index-based table:
> take an index value from a specified field, go to this index, and execute 
> actions.

OK, please make sure the explanation is clear in the patch.


> > > > > The insertion to an already existing index is undefined and
> > > >
> > > > Why is it undefined?
> > >
> > > The behavior is up to a PMD to decide. It is free to replace the rule or 
> > > throw
> > an error.
> > 
> > An undefined behavior of an API makes applications not portable.
> > Why not deciding of a behavior? You are not sure what is best?
> 
> We don't want to restrict a PMD behavior here. 
> Personally, I would prefer throwing an error in this case.
> Do you think returning EEXIST is better?

I don't know what is best.
At least you can define an error EEXIST if the PMD forbids it,
and no error if the PMD replaces the rule.

RE: [PATCH v7] ethdev: add special flags when creating async transfer table

[Rongwei Liu]

HI Ivan

BR
Rongwei

> -Original Message-
> From: Ivan Malov 
> Sent: Monday, January 30, 2023 15:40
> To: Rongwei Liu 
> Cc: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; NBU-Contact-
> Thomas Monjalon (EXTERNAL) ; Aman Singh
> ; Yuying Zhang ;
> Ferruh Yigit ; Andrew Rybchenko
> ; dev@dpdk.org; Raslan Darawsheh
> 
> Subject: RE: [PATCH v7] ethdev: add special flags when creating async transfer
> table
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Rongwei,
> 
> For my responses, PSB.
> 
> By the way, now you mention things like wasting memory and insertion
> optimisastions, are there any comparative figures to see the effect of this 
> hint
> on insertion performance / memory footprint?
> Some "before" / "after" examples would really be helpful.
> 
Good to hear we reach agreement almost.
First, the hint has nothing related to matching, only affects PMD resource 
management.
In my local test, it can save around 50% memory in the VxLAN encap/decap 
example case.
Insertion rate has very very few improvements.
> After all, I'm not objecting this patch. But I believe that other reviewers'
> concerns should nevertheless be addressed anyway.
Let me try to show the hint is useful.
> 
> On Mon, 30 Jan 2023, Rongwei Liu wrote:
> 
> > Hi Ivan,
> >
> > BR
> > Rongwei
> >
> >> -Original Message-
> >> From: Ivan Malov 
> >> Sent: Monday, January 30, 2023 08:00
> >> To: Rongwei Liu 
> >> Cc: Matan Azrad ; Slava Ovsiienko
> >> ; Ori Kam ; NBU-Contact-
> >> Thomas Monjalon (EXTERNAL) ; Aman Singh
> >> ; Yuying Zhang ;
> >> Ferruh Yigit ; Andrew Rybchenko
> >> ; dev@dpdk.org; Raslan Darawsheh
> >> 
> >> Subject: Re: [PATCH v7] ethdev: add special flags when creating async
> >> transfer table
> >>
> >> External email: Use caution opening links or attachments
> >>
> >>
> >> Hi Rongwei,
> >>
> >> Thanks for persevering. I have no strong opinion, but, at least, the
> >> fact that the new flags are no longer meant for use in rte_flow_attr,
> >> which is clearly not the right place for such, is an improvement.
> >>
> > Thanks for the suggestion, move it to rte_flow_table_attr now and it'
> dedicated to async API.
> >> However, let's take a closer look at the current patch, shall we?
> >>
> >> But, before we get to that, I'd like to kindly request that you
> >> provide a more concrete example of how this feature is supposed to be
> >> used. Are there some real-life application examples?
> >>
> > Sure.
> >> Also, to me, it's still unclear how an application can obtain the
> >> knowledge of this hint in the first instance. For example, can Open
> >> vSwitch somehow tell ethdevs representing physical ports from ones
> >> representing "vports" (host endpoints)?
> >> How does it know which attribute to specify?
> >>
> > Hint should be initiated by application and application knows it' traffic
> pattern which highly relates to deployment.
> > Let' use VxLAN encap/decap as an example:
> > 1. Traffic from wire should be VxLAN pattern and do the decap, then send to
> different vports.
> > flow pattern_template 0 create transfer relaxed no pattern_template_id
> > 4 template represented_port ethdev_port_id is 0 / eth / ipv4 / udp /
> > vxlan / tag index is 0 data is 0x33 / end flow actions_template 0
> > create transfer actions_template_id 4 template raw_decap index 0 /
> > represented_port ethdev_port_id 1 / end mask raw_decap index 0 /
> > represented_port ethdev_port_id 1 / end flow template_table 0 create
> > group 1 priority 0 transfer wire_orig table_id 4 rules_number 128
> > pattern_template 4 actions_template 4
> >
> > 2. Traffic from vports should be encap with different VxLAN header and send
> to wire.
> > flow actions_template 1 create transfer actions_template_id 5 template
> > raw_encap index 0 / represented_port ethdev_port_id 0 / end mask
> > raw_encap index 0 / represented_port ethdev_port_id 0 / end flow
> > template_table 0 create group 1 priority 0 transfer vport_orig
> > table_id 5 rules_number 128 pattern_template 4 actions_template 5
> >
> >> For the rest of my notes, PSB.
> >>
> >> On Mon, 14 Nov 2022, Rongwei Liu wrote:
> >>
> >>> In case flow rules match only one kind of traffic in a flow table,
> >>> then optimization can be done via allocation of this table.
> >>
> >> This wording might confuse readers. Consider rephrasing it, please:
> >> If multiple flow rules share a common set of match masks, then they
> >> might belong in a flow table which can be pre-allocated.
> >>
> >>> Such optimization is possible only if the application gives a hint
> >>> about its usage of the table during initial configuration.
> >>>
> >>> The transfer domain rules may process traffic from wire or vport,
> >>> which may correspond to two kinds of underlayer resources.
> >>
> >> Why name it a "vport"? Why not "host"?
> >>
> >> host = packets generated by any of the host's "vport"s wire = packets
> >> arriving at the NIC from the network
> > Vport is "virtual port" for short and contains "VF/SF" 

RE: [EXT] Re: [PATCH v2] eventdev: add trace points

[Amit Prakash Shukla]

Thanks Jerin for the review and feedback. Sure, I will send next version of the 
patch without symbols.

> -Original Message-
> From: Jerin Jacob 
> Sent: Monday, January 30, 2023 8:02 PM
> To: Amit Prakash Shukla 
> Cc: Jerin Jacob Kollanukkaran ; Abhinandan Gujjar
> ; Naga Harish K S V
> ; Erik Gabriel Carrillo
> ; dev@dpdk.org
> Subject: [EXT] Re: [PATCH v2] eventdev: add trace points
> 
> External Email
> 
> --
> On Mon, Jan 30, 2023 at 3:44 PM Amit Prakash Shukla
>  wrote:
> >
> > Add trace points for eventdev functions.
> >
> > Signed-off-by: Amit Prakash Shukla 
> > ---
> 
> > diff --git a/lib/eventdev/version.map b/lib/eventdev/version.map index
> > 4405cd38eb..f6ab242a3d 100644
> > --- a/lib/eventdev/version.map
> > +++ b/lib/eventdev/version.map
> > @@ -121,6 +121,60 @@ EXPERIMENTAL {
> >
> > # added in 23.03
> > rte_event_timer_remaining_ticks_get;
> 
> Following updates are not needed in version.map based on the discussion
> happened ethdev trace thread as it is not required to expose the symbol.
> 
> > +   __rte_eventdev_trace_eth_rx_adapter_caps_get;
> > +   __rte_eventdev_trace_eth_tx_adapter_caps_get;
> > +   __rte_eventdev_trace_timer_adapter_caps_get;
> > +   __rte_eventdev_trace_crypto_adapter_caps_get;
> > +   __rte_eventdev_trace_crypto_adapter_event_port_get;
> > +   __rte_eventdev_trace_crypto_adapter_service_id_get;
> > +   __rte_eventdev_trace_eth_rx_adapter_cb_register;
> > +   __rte_eventdev_trace_eth_rx_adapter_create_with_params;
> > +   __rte_eventdev_trace_eth_rx_adapter_queue_conf_get;
> > +   __rte_eventdev_trace_eth_rx_adapter_service_id_get;
> > +   __rte_eventdev_trace_eth_rx_adapter_vector_limits_get;
> > +   __rte_eventdev_trace_eth_tx_adapter_event_port_get;
> > +   __rte_eventdev_trace_eth_tx_adapter_service_id_get;
> > +   __rte_eventdev_trace_port_attr_get;
> > +   __rte_eventdev_trace_port_default_conf_get;
> > +   __rte_eventdev_trace_port_links_get;
> > +   __rte_eventdev_trace_port_quiesce;
> > +   __rte_eventdev_trace_port_unlinks_in_progress;
> > +   __rte_eventdev_trace_queue_attr_get;
> > +   __rte_eventdev_trace_queue_attr_set;
> > +   __rte_eventdev_trace_queue_default_conf_get;
> > +   __rte_eventdev_trace_ring_create;
> > +   __rte_eventdev_trace_ring_free;
> > +   __rte_eventdev_trace_ring_init;
> > +   __rte_eventdev_trace_ring_lookup;
> > +   __rte_eventdev_trace_timer_adapter_get_info;
> > +   __rte_eventdev_trace_timer_adapter_lookup;
> > +   __rte_eventdev_trace_timer_adapter_service_id_get;
> > +   __rte_eventdev_trace_attr_get;
> > +   __rte_eventdev_trace_close;
> > +   __rte_eventdev_trace_configure;
> > +   __rte_eventdev_trace_dump;
> > +   __rte_eventdev_trace_get_dev_id;
> > +   __rte_eventdev_trace_info_get;
> > +   __rte_eventdev_trace_selftest;
> > +   __rte_eventdev_trace_service_id_get;
> > +   __rte_eventdev_trace_socket_id;
> > +   __rte_eventdev_trace_start;
> > +   __rte_eventdev_trace_stop;
> > +   __rte_eventdev_trace_stop_flush_callback_register;
> > +   __rte_eventdev_trace_vector_pool_create;
> > +   __rte_eventdev_trace_dequeue_timeout_ticks;
> > +   __rte_eventdev_trace_crypto_adapter_stats_get;
> > +   __rte_eventdev_trace_crypto_adapter_stats_reset;
> > +   __rte_eventdev_trace_eth_rx_adapter_stats_get;
> > +   __rte_eventdev_trace_crypto_adapter_vector_limits_get;
> > +   __rte_eventdev_trace_eth_rx_adapter_queue_stats_get;
> > +   __rte_eventdev_trace_eth_rx_adapter_stats_reset;
> > +   __rte_eventdev_trace_eth_rx_adapter_queue_stats_reset;
> > +   __rte_eventdev_trace_eth_rx_adapter_event_port_get;
> > +   __rte_eventdev_trace_eth_rx_adapter_instance_get;
> > +   __rte_eventdev_trace_eth_tx_adapter_stats_get;
> > +   __rte_eventdev_trace_eth_tx_adapter_stats_reset;
> > +   __rte_eventdev_trace_eth_tx_adapter_instance_get;
> >  };
> >
> >  INTERNAL {
> > --
> > 2.25.1
> >

Re: [PATCH v10 4/4] eal: deprecation notice for rte thread setname API

[Thomas Monjalon]

Hi,

The title should start with a verb.
I suppose it can be fixed while merging with a title like:
doc: announce deprecation of thread naming function


24/01/2023 19:12, Tyler Retzlaff:
> Notify deprecation of rte_thread_setname API, it will be removed as it
> exposes platform-specific thread details. The functionality it provided
> is now available via the new rte_lcore_set_name API.
> 
> Signed-off-by: Tyler Retzlaff 
> Acked-by: Morten Brørup 
> Acked-by: David Marchand 
> ---
> +* eal: The function ``rte_thread_setname`` is planned to be deprecated
> +  starting with the 23.07 release subject to the replacement API
> +  rte_thread_set_name being marked as stable and planned to be removed
> +  by the 23.11 release.

Minor: it would be clearer if adding some commas after "release" and "stable".


For the series,
Acked-by: Thomas Monjalon 

RE: [EXT] Re: [PATCH v6 2/6] ethdev: add trace points for ethdev (part one)

[Ankur Dwivedi]

>-Original Message-
>From: Ferruh Yigit 
>Sent: Monday, January 23, 2023 10:59 PM
>To: Ankur Dwivedi ; dev@dpdk.org; David
>Marchand 
>Cc: tho...@monjalon.net; david.march...@redhat.com; m...@ashroe.eu;
>or...@nvidia.com; ch...@att.com; humi...@huawei.com;
>linvi...@tuxdriver.com; ciara.lof...@intel.com; qi.z.zh...@intel.com;
>m...@semihalf.com; m...@semihalf.com; shaib...@amazon.com;
>evge...@amazon.com; igo...@amazon.com; cha...@amd.com; Igor
>Russkikh ; shepard.sie...@atomicrules.com;
>ed.cz...@atomicrules.com; john.mil...@atomicrules.com;
>ajit.khapa...@broadcom.com; somnath.ko...@broadcom.com; Jerin Jacob
>Kollanukkaran ; Maciej Czekaj [C]
>; Shijith Thotton ;
>Srisivasubramanian Srinivasan ; Harman Kalra
>; rahul.lakkire...@chelsio.com; johnd...@cisco.com;
>hyon...@cisco.com; liudongdo...@huawei.com;
>yisen.zhu...@huawei.com; xuanziya...@huawei.com;
>cloud.wangxiao...@huawei.com; zhouguoy...@huawei.com;
>simei...@intel.com; wenjun1...@intel.com; qiming.y...@intel.com;
>yuying.zh...@intel.com; beilei.x...@intel.com; xiao.w.w...@intel.com;
>jingjing...@intel.com; junfeng@intel.com; rosen...@intel.com; Nithin
>Kumar Dabilpuram ; Kiran Kumar Kokkilagadda
>; Sunil Kumar Kori ; Satha
>Koteswara Rao Kottidi ; Liron Himi
>; z...@semihalf.com; Radha Chintakuntla
>; Veerasenareddy Burru ;
>Sathesh B Edara ; ma...@nvidia.com;
>viachesl...@nvidia.com; lon...@microsoft.com; spin...@cesnet.cz;
>chaoyong...@corigine.com; niklas.soderl...@corigine.com;
>hemant.agra...@nxp.com; sachin.sax...@oss.nxp.com; g.si...@nxp.com;
>apeksha.gu...@nxp.com; sachin.sax...@nxp.com; abo...@pensando.io;
>Rasesh Mody ; Shahed Shaikh
>; Devendra Singh Rawat
>; andrew.rybche...@oktetlabs.ru;
>jiawe...@trustnetic.com; jianw...@trustnetic.com;
>jbehr...@vmware.com; maxime.coque...@redhat.com;
>chenbo@intel.com; steven.webs...@windriver.com;
>matt.pet...@windriver.com; bruce.richard...@intel.com;
>mtetsu...@gmail.com; gr...@u256.net; jasvinder.si...@intel.com;
>cristian.dumitre...@intel.com; jgraj...@cisco.com;
>m...@smartsharesystems.com
>Subject: [EXT] Re: [PATCH v6 2/6] ethdev: add trace points for ethdev (part
>one)
>
>External Email
>
>--
>On 1/20/2023 8:40 AM, Ankur Dwivedi wrote:
>> Adds trace points for ethdev functions.
>> Moved the rte_ethdev_trace_rx_burst and rte_ethdev_trace_tx_burst to a
>> new file rte_ethdev_trace_fp_burst.h. This is needed to resolve cyclic
>> dependency between rte_ethdev.h and rte_ethdev_trace_fp.h.
>>
>> Signed-off-by: Ankur Dwivedi 
>
><...>
>
>> +RTE_TRACE_POINT_REGISTER(rte_eth_trace_rx_hairpin_queue_setup,
>> +lib.ethdev.rx.hairpin_queue_setup)
>> +
>
>s/rx.hairpin_queue_setup/rx_hairpin_queue_setup/ ?
>
>> +RTE_TRACE_POINT_REGISTER(rte_eth_trace_tx_hairpin_queue_setup,
>> +lib.ethdev.tx.hairpin_queue_setup)
>> +
>
>s/tx.hairpin_queue_setup/tx_hairpin_queue_setup/ ?

Ok.
>
><...>
>
>> diff --git a/lib/ethdev/meson.build b/lib/ethdev/meson.build index
>> 39250b5da1..f5c0865023 100644
>> --- a/lib/ethdev/meson.build
>> +++ b/lib/ethdev/meson.build
>> @@ -24,6 +24,7 @@ headers = files(
>>  'rte_ethdev.h',
>>  'rte_ethdev_trace.h',
>>  'rte_ethdev_trace_fp.h',
>> +'rte_ethdev_trace_fp_burst.h',
>
>Why these trace headers are public?
>Aren't trace points only used by the APIs, so I expect them to be internal, so
>applications shouldn't need them. Why they are expsed to user.
'rte_ethdev_trace.h' can be made as internal. Not sure about 
'rte_ethdev_trace_fp.h' and 'rte_ethdev_trace_fp_burst.h' as the tracepoints in 
fast path may be called from public inline functions.
>
>@David, what do you think?
>
><...>
>
>> @@ -258,6 +259,7 @@ rte_eth_iterator_init(struct rte_dev_iterator
>> *iter, const char *devargs_str)
>>
>>  end:
>>  iter->cls = rte_class_find_by_name("eth");
>> +rte_eth_trace_iterator_init(devargs_str);
>>  rte_devargs_reset(&devargs);
>>  return 0;
>
>Why not add trace call just before return, as a separate block, like:

Ok.
>``
>  end:
>   iter->cls = rte_class_find_by_name("eth");
>   rte_devargs_reset(&devargs);
>
>   rte_eth_trace_iterator_init(devargs_str);
>
>   return 0;
>``
>
>>
>> @@ -274,6 +276,8 @@ rte_eth_iterator_init(struct rte_dev_iterator
>> *iter, const char *devargs_str)  uint16_t
>> rte_eth_iterator_next(struct rte_dev_iterator *iter)  {
>> +uint16_t id;
>> +
>>  if (iter == NULL) {
>>  RTE_ETHDEV_LOG(ERR,
>>  "Cannot get next device from NULL iterator\n"); @@ -
>297,8 +301,11
>> @@ rte_eth_iterator_next(struct rte_dev_iterator *iter)
>>  /* A device is matching bus part, need to check ethdev part. */
>>  iter->class_device = iter->cls->dev_iterate(
>>  iter->class_device, iter->cls_str, iter);
>> -if (iter->class_device != NULL)
>> -return eth_dev_to_id(iter->class_device); /* match */
>> +

Re: [PATCH v10 4/4] eal: deprecation notice for rte thread setname API

[David Marchand]

On Mon, Jan 30, 2023 at 4:47 PM Thomas Monjalon  wrote:
>
> Hi,
>
> The title should start with a verb.
> I suppose it can be fixed while merging with a title like:
> doc: announce deprecation of thread naming function

Yes, I will handle it.

> 24/01/2023 19:12, Tyler Retzlaff:
> > Notify deprecation of rte_thread_setname API, it will be removed as it
> > exposes platform-specific thread details. The functionality it provided
> > is now available via the new rte_lcore_set_name API.
> >
> > Signed-off-by: Tyler Retzlaff 
> > Acked-by: Morten Brørup 
> > Acked-by: David Marchand 
> > ---
> > +* eal: The function ``rte_thread_setname`` is planned to be deprecated
> > +  starting with the 23.07 release subject to the replacement API
> > +  rte_thread_set_name being marked as stable and planned to be removed
> > +  by the 23.11 release.
>
> Minor: it would be clearer if adding some commas after "release" and "stable".

And this too.

>
>
> For the series,
> Acked-by: Thomas Monjalon 

Thanks.


-- 
David Marchand

Re: [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition

[Stephen Hemminger]

On Mon, 30 Jan 2023 05:59:33 +0200
Rongwei Liu  wrote:

> +static size_t
> +rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data)

> +{
> + struct rte_flow_item_ipv6_routing_ext *dst = buf;
> + const struct rte_flow_item_ipv6_routing_ext *src = data;
> + size_t len;
> +
> + if (src->hdr.hdr_len)
> + len = src->hdr.hdr_len << 3;
> + else
> + len = src->hdr.segments_left << 4;
> + if (dst == NULL)
> + return 0;
> + rte_memcpy((void *)((uintptr_t)(dst->hdr.segments)), src->hdr.segments, 
> len);
> + return len;

Why use rte_memcpy for such a small size? Please just use normal memcpy which
will cause more compiler and static scan checking.

That cast is unnecessary in C because "segments" is an array and any valid
pointer type can be passed as void *.

[PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue API

[Jiawei Wang]

For the multiple hardware ports connect to a single DPDK port (mhpsdp),
the previous patch introduces the new rte flow item to match the
phy affinity of the received packets.

This patch adds the tx_phy_affinity setting in Tx queue API, the affinity
value reflects packets be sent to which hardware port.
Value 0 is no affinity and traffic will be routed between different
physical ports, if 0 is disabled then try to match on phy_affinity 0
will result in an error.

Adds the new tx_phy_affinity field into the padding hole of rte_eth_txconf
structure, the size of rte_eth_txconf keeps the same. Adds a suppress
type for structure change in the ABI check file.

This patch adds the testpmd command line:
testpmd> port config (port_id) txq (queue_id) phy_affinity (value)

For example, there're two hardware ports 0 and 1 connected to
a single DPDK port (port id 0), and phy_affinity 1 stood for
hardware port 0 and phy_affinity 2 stood for hardware port 1,
used the below command to config tx phy affinity for per Tx Queue:
port config 0 txq 0 phy_affinity 1
port config 0 txq 1 phy_affinity 1
port config 0 txq 2 phy_affinity 2
port config 0 txq 3 phy_affinity 2

These commands config the TxQ index 0 and TxQ index 1 with phy affinity 1,
uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
hardware port 0, and similar with hardware port 1 if sending packets
with TxQ 2 or TxQ 3.

Signed-off-by: Jiawei Wang 
---
 app/test-pmd/cmdline.c  | 84 +
 devtools/libabigail.abignore|  5 ++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 
 lib/ethdev/rte_ethdev.h |  7 ++
 4 files changed, 109 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd4..768f35cb02 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -764,6 +764,10 @@ static void cmd_help_long_parsed(void *parsed_result,
 
"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
"Cleanup txq mbufs for a specific Tx queue\n\n"
+
+   "port config (port_id) txq (queue_id) phy_affinity 
(value)\n"
+   "Set the physical affinity value "
+   "on a specific Tx queue\n\n"
);
}
 
@@ -12621,6 +12625,85 @@ static cmdline_parse_inst_t 
cmd_show_port_flow_transfer_proxy = {
}
 };
 
+/* *** configure port txq phy_affinity value *** */
+struct cmd_config_tx_phy_affinity {
+   cmdline_fixed_string_t port;
+   cmdline_fixed_string_t config;
+   portid_t portid;
+   cmdline_fixed_string_t txq;
+   uint16_t qid;
+   cmdline_fixed_string_t phy_affinity;
+   uint16_t value;
+};
+
+static void
+cmd_config_tx_phy_affinity_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+   struct cmd_config_tx_phy_affinity *res = parsed_result;
+   struct rte_port *port;
+
+   if (port_id_is_invalid(res->portid, ENABLED_WARN))
+   return;
+
+   if (res->portid == (portid_t)RTE_PORT_ALL) {
+   printf("Invalid port id\n");
+   return;
+   }
+
+   port = &ports[res->portid];
+
+   if (strcmp(res->txq, "txq")) {
+   printf("Unknown parameter\n");
+   return;
+   }
+   if (tx_queue_id_is_invalid(res->qid))
+   return;
+
+   port->txq[res->qid].conf.tx_phy_affinity = res->value;
+
+   cmd_reconfig_device_queue(res->portid, 0, 1);
+}
+
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_port =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+port, "port");
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_config =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+config, "config");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_portid =
+   TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+portid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_txq =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+txq, "txq");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_qid =
+   TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_hwport =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+phy_affinity, "phy_affinity");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_value =
+   TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ value, RTE_UINT16);
+
+static cmdline_parse_inst_t cmd_config_tx_phy_affinity = {
+  

[PATCH v2 0/2] add new PHY affinity in the flow item and Tx queue API

[Jiawei Wang]

For the multiple hardware ports connect to a single DPDK port (mhpsdp),
currently, there is no information to indicate the packet belongs to
which hardware port.

This patch introduces a new phy affinity item in rte flow API, and
the phy affinity value reflects the physical phy affinity of the
received packets.

This patch adds the tx_phy_affinity setting in Tx queue API, the affinity value
reflects packets be sent to which hardware port.

While uses the phy affinity as a matching item in the flow, and sets the
same affinity on the tx queue, then the packet can be sent from the same
hardware port with received.

RFC: 
http://patches.dpdk.org/project/dpdk/cover/20221221102934.13822-1-jiaw...@nvidia.com/

The PMD patch will be sent soon.

Jiawei Wang (2):
  ethdev: add PHY affinity match item
  ethdev: introduce the PHY affinity field in Tx queue API

 app/test-pmd/cmdline.c  | 84 +
 app/test-pmd/cmdline_flow.c | 29 +++
 devtools/libabigail.abignore|  5 ++
 doc/guides/prog_guide/rte_flow.rst  |  8 ++
 doc/guides/rel_notes/release_23_03.rst  |  5 ++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 17 +
 lib/ethdev/rte_ethdev.h |  7 ++
 lib/ethdev/rte_flow.c   |  1 +
 lib/ethdev/rte_flow.h   | 28 +++
 9 files changed, 184 insertions(+)

-- 
2.18.1

[PATCH v2 1/2] ethdev: add PHY affinity match item

[Jiawei Wang]

For the multiple hardware ports connect to a single DPDK port (mhpsdp),
currently, there is no information to indicate the packet belongs to
which hardware port.

This patch introduces a new phy affinity item in rte flow API, and
the phy affinity value reflects the physical port of the received packets.

While uses the phy affinity as a matching item in the flow, and sets the
same phy_affinity value on the tx queue, then the packet can be sent from
the same hardware port with received.

This patch also adds the testpmd command line to match the new item:
flow create 0 ingress group 0 pattern phy_affinity affinity is 1 /
end actions queue index 0 / end

The above command means that creates a flow on a single DPDK port and
matches the packet from the first physical port (assume the phy affinity 1
stands for the first port) and redirects these packets into RxQ 0.

Signed-off-by: Jiawei Wang 
---
 app/test-pmd/cmdline_flow.c | 29 +
 doc/guides/prog_guide/rte_flow.rst  |  8 ++
 doc/guides/rel_notes/release_23_03.rst  |  5 
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  4 +++
 lib/ethdev/rte_flow.c   |  1 +
 lib/ethdev/rte_flow.h   | 28 
 6 files changed, 75 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 88108498e0..a6d4615038 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -465,6 +465,8 @@ enum index {
ITEM_METER,
ITEM_METER_COLOR,
ITEM_METER_COLOR_NAME,
+   ITEM_PHY_AFFINITY,
+   ITEM_PHY_AFFINITY_VALUE,
 
/* Validate/create actions. */
ACTIONS,
@@ -1355,6 +1357,7 @@ static const enum index next_item[] = {
ITEM_L2TPV2,
ITEM_PPP,
ITEM_METER,
+   ITEM_PHY_AFFINITY,
END_SET,
ZERO,
 };
@@ -1821,6 +1824,12 @@ static const enum index item_meter[] = {
ZERO,
 };
 
+static const enum index item_phy_affinity[] = {
+   ITEM_PHY_AFFINITY_VALUE,
+   ITEM_NEXT,
+   ZERO,
+};
+
 static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -6443,6 +6452,23 @@ static const struct token token_list[] = {
ARGS_ENTRY(struct buffer, port)),
.call = parse_mp,
},
+   [ITEM_PHY_AFFINITY] = {
+   .name = "phy_affinity",
+   .help = "match on the physical affinity of the"
+   " received packet.",
+   .priv = PRIV_ITEM(PHY_AFFINITY,
+ sizeof(struct rte_flow_item_phy_affinity)),
+   .next = NEXT(item_phy_affinity),
+   .call = parse_vc,
+   },
+   [ITEM_PHY_AFFINITY_VALUE] = {
+   .name = "affinity",
+   .help = "physical affinity value",
+   .next = NEXT(item_phy_affinity, NEXT_ENTRY(COMMON_UNSIGNED),
+item_param),
+   .args = ARGS(ARGS_ENTRY(struct rte_flow_item_phy_affinity,
+   affinity)),
+   },
 };
 
 /** Remove and return last entry from argument stack. */
@@ -10981,6 +11007,9 @@ flow_item_default_mask(const struct rte_flow_item *item)
case RTE_FLOW_ITEM_TYPE_METER_COLOR:
mask = &rte_flow_item_meter_color_mask;
break;
+   case RTE_FLOW_ITEM_TYPE_PHY_AFFINITY:
+   mask = &rte_flow_item_phy_affinity_mask;
+   break;
default:
break;
}
diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 3e6242803d..3b4e8923dc 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1544,6 +1544,14 @@ Matches Color Marker set by a Meter.
 
 - ``color``: Metering color marker.
 
+Item: ``PHY_AFFINITY``
+^^
+
+Matches on the physical affinity of the received packet, the physical port
+in the group of physical ports connected to a single DPDK port.
+
+- ``affinity``: Physical affinity.
+
 Actions
 ~~~
 
diff --git a/doc/guides/rel_notes/release_23_03.rst 
b/doc/guides/rel_notes/release_23_03.rst
index c15f6fbb9f..a1abd67771 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -69,6 +69,11 @@ New Features
 ``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
 required for eth_rx, eth_tx, crypto and timer eventdev adapters.
 
+* **Added rte_flow support for matching PHY Affinity fields.**
+
+  For the multiple hardware ports connect to a single DPDK port (mhpsdp),
+  Added ``phy_affinity`` item in rte_flow to support physical affinity of
+  the packets.
 
 Removed Items
 -
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 0037506a79..1853030e93 100644
--- a/doc/guides/testpmd_app_ug/testpmd_fu

Re: [PATCH v4 3/3] ethdev: add standby flags for live migration

[Jerin Jacob]

On Mon, Jan 30, 2023 at 8:17 AM Rongwei Liu  wrote:
>
> Hi Jerin
>
> BR
> Rongwei
>
> > -Original Message-
> > From: Jerin Jacob 
> > Sent: Monday, January 23, 2023 21:20
> > To: Rongwei Liu 
> > Cc: dev@dpdk.org; Matan Azrad ; Slava Ovsiienko
> > ; Ori Kam ; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) ;
> > step...@networkplumber.org; Raslan Darawsheh ;
> > Ferruh Yigit ; Andrew Rybchenko
> > 
> > Subject: Re: [PATCH v4 3/3] ethdev: add standby flags for live migration
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Jan 18, 2023 at 9:15 PM Rongwei Liu  wrote:
> > >
> > > Some flags are added to the process state API for live migration in
> > > order to change the behavior of the flow rules in a standby process.
> > >
> > > Signed-off-by: Rongwei Liu 
> > > ---
> > >  lib/ethdev/rte_ethdev.h | 21 +
> > >  1 file changed, 21 insertions(+)
> > >
> > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > > 1505396ced..9ae4f426a7 100644
> > > --- a/lib/ethdev/rte_ethdev.h
> > > +++ b/lib/ethdev/rte_ethdev.h
> > > @@ -2260,6 +2260,27 @@ int rte_eth_dev_owner_get(const uint16_t
> > > port_id,  __rte_experimental  int rte_eth_process_set_role(bool
> > > standby, uint32_t flags);
> > >
> > > +/**@{@name Process role flags
> > > + * used when migrating from an application to another one.
> > > + * @see rte_eth_process_set_active
> > > + */
> > > +/**
> > > + * When set on a standby process, ingress flow rules will be
> > > +effective
> > > + * in active and standby processes, so the ingress traffic may be 
> > > duplicated.
> > > + */
> > > +#define RTE_ETH_PROCESS_FLAG_STANDBY_DUP_FLOW_INGRESS
> > RTE_BIT32(0)
> >
> >
> > How to duplicate if action has statefull items for example,
> > rte_flow_action_security::security_session -> it store the live pointer
> > rte_flow_action_meter::mtr_id; -> MTR object ID created with
> > rte_mtr_create()
> I agree with you, not all actions can be supported in the active/standby 
> model.

IMO, Where ever rules are not standalone (like QUEUE, RSS) etc, It
will be architecturally is not possible to migrate with pointers.
That's where I have concern generalizing this feature for this ethdev.

Also, I don't believe there is any real HW support needed for this.
IMO, Having DPDK standard multiprocess can do this by keeping
secondary application can migrate, keeping all the SW logic in the
primary process by doing the housekeeping in the application. On plus
side,
it works with pointers too.

I am not sure how much housekeeping offload to _HW_ in your case. In
my view, it should be generic utils functions to track the flow
and installing the rules using rte_flow APIs and keep the scope only
for rte_flow.

That's just my view. I leave to ethdev maintainers for the rest of the
review and decision on this series.

> That' why we have return value checking and rollback.
> In Nvidia driver doc, we suggested user to start from 'rss/queue/jump' 
> actions.
> Meter is possible, at least per my view.
> Assume: "meter g_action queue 0 / y_action drop / r_action drop"
> Old application: create meter_id 'A' with pre-defined limitation.
> New application: create meter_id 'B' which has the same parameters with 'A'.
> 1. 1st possible approach:
> Hardware duplicates the traffic; old application use meter 'A' and 
> new application uses meter 'B' to control traffic throughputs.
> Since traffic is duplicated, so it can go to different meters.
> 2. 2nd possible approach:
>  Meter 'A' and 'B' point to the same hardware resource, and 
> traffic reaches this part first and if green, duplication happens.

RE: [RFC v2 7/9] net/gve: support basic stats for DQO

[Honnappa Nagarahalli]

Few comments inline

> -Original Message-
> From: Junfeng Guo 
> Sent: Monday, January 30, 2023 12:27 AM
> To: qi.z.zh...@intel.com; jingjing...@intel.com; ferruh.yi...@amd.com;
> beilei.x...@intel.com
> Cc: dev@dpdk.org; xiaoyun...@intel.com; helin.zh...@intel.com; Junfeng Guo
> ; Rushil Gupta ; Jordan
> Kimbrough ; Jeroen de Borst 
> Subject: [RFC v2 7/9] net/gve: support basic stats for DQO
> 
> Add basic stats support for DQO.
> 
> Signed-off-by: Junfeng Guo 
> Signed-off-by: Rushil Gupta 
> Signed-off-by: Jordan Kimbrough 
> Signed-off-by: Jeroen de Borst 
> ---
>  drivers/net/gve/gve_ethdev.c | 60 
>  drivers/net/gve/gve_ethdev.h | 11 +++  drivers/net/gve/gve_rx_dqo.c | 12
> +++-  drivers/net/gve/gve_tx_dqo.c |  6 
>  4 files changed, 88 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/gve/gve_ethdev.c b/drivers/net/gve/gve_ethdev.c index
> 89e3f09c37..fae00305f9 100644
> --- a/drivers/net/gve/gve_ethdev.c
> +++ b/drivers/net/gve/gve_ethdev.c
> @@ -369,6 +369,64 @@ gve_dev_info_get(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *dev_info)
>   return 0;
>  }
> 
> +static int
> +gve_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
> +{
> + uint16_t i;
> +
> + for (i = 0; i < dev->data->nb_tx_queues; i++) {
> + struct gve_tx_queue *txq = dev->data->tx_queues[i];
> + if (txq == NULL)
> + continue;
> +
> + stats->opackets += txq->packets;
> + stats->obytes += txq->bytes;
> + stats->oerrors += txq->errors;
> + }
> +
> + for (i = 0; i < dev->data->nb_rx_queues; i++) {
> + struct gve_rx_queue *rxq = dev->data->rx_queues[i];
> + if (rxq == NULL)
> + continue;
> +
> + stats->ipackets += rxq->packets;
> + stats->ibytes += rxq->bytes;
> + stats->ierrors += rxq->errors;
> + stats->rx_nombuf += rxq->no_mbufs;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +gve_dev_stats_reset(struct rte_eth_dev *dev) {
> + uint16_t i;
> +
> + for (i = 0; i < dev->data->nb_tx_queues; i++) {
> + struct gve_tx_queue *txq = dev->data->tx_queues[i];
> + if (txq == NULL)
> + continue;
> +
> + txq->packets  = 0;
> + txq->bytes = 0;
> + txq->errors = 0;
Do these (similar ones elsewhere) need to be atomic operations? These 
statistics are being accessed from PMD and the control plane threads.

> + }
> +
> + for (i = 0; i < dev->data->nb_rx_queues; i++) {
> + struct gve_rx_queue *rxq = dev->data->rx_queues[i];
> + if (rxq == NULL)
> + continue;
> +
> + rxq->packets  = 0;
> + rxq->bytes = 0;
> + rxq->errors = 0;
> + rxq->no_mbufs = 0;
> + }
> +
> + return 0;
> +}
> +
>  static int
>  gve_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)  { @@ -407,6 +465,8
> @@ static const struct eth_dev_ops gve_eth_dev_ops = {
>   .rx_queue_release = gve_rx_queue_release,
>   .tx_queue_release = gve_tx_queue_release,
>   .link_update  = gve_link_update,
> + .stats_get= gve_dev_stats_get,
> + .stats_reset  = gve_dev_stats_reset,
>   .mtu_set  = gve_dev_mtu_set,
>  };
> 
> diff --git a/drivers/net/gve/gve_ethdev.h b/drivers/net/gve/gve_ethdev.h index
> d434f9babe..2e0f96499d 100644
> --- a/drivers/net/gve/gve_ethdev.h
> +++ b/drivers/net/gve/gve_ethdev.h
> @@ -105,6 +105,11 @@ struct gve_tx_queue {
>   struct gve_queue_page_list *qpl;
>   struct gve_tx_iovec *iov_ring;
> 
> + /* stats items */
> + uint64_t packets;
> + uint64_t bytes;
> + uint64_t errors;
> +
>   uint16_t port_id;
>   uint16_t queue_id;
> 
> @@ -156,6 +161,12 @@ struct gve_rx_queue {
>   /* only valid for GQI_QPL queue format */
>   struct gve_queue_page_list *qpl;
> 
> + /* stats items */
> + uint64_t packets;
> + uint64_t bytes;
> + uint64_t errors;
> + uint64_t no_mbufs;
> +
>   struct gve_priv *hw;
>   const struct rte_memzone *qres_mz;
>   struct gve_queue_resources *qres;
> diff --git a/drivers/net/gve/gve_rx_dqo.c b/drivers/net/gve/gve_rx_dqo.c index
> 244517ce5d..41ead5bd98 100644
> --- a/drivers/net/gve/gve_rx_dqo.c
> +++ b/drivers/net/gve/gve_rx_dqo.c
> @@ -37,6 +37,7 @@ gve_rx_refill_dqo(struct gve_rx_queue *rxq)
>   next_avail = 0;
>   rxq->nb_rx_hold -= delta;
>   } else {
> + rxq->no_mbufs += nb_desc - next_avail;
>   dev = &rte_eth_devices[rxq->port_id];
>   dev->data->rx_mbuf_alloc_failed += nb_desc -
> next_avail;
>   PMD_DRV_LOG(DEBUG, "RX mbuf alloc failed
> port_id=%u queue_id=%u", @@ -57,6 +58,7 @@ gve_rx_refill_dqo(struc

RE: [RFC v2 6/9] net/gve: support basic Rx data path for DQO

[Honnappa Nagarahalli]

> -Original Message-
> From: Junfeng Guo 
> Sent: Monday, January 30, 2023 12:27 AM
> To: qi.z.zh...@intel.com; jingjing...@intel.com; ferruh.yi...@amd.com;
> beilei.x...@intel.com
> Cc: dev@dpdk.org; xiaoyun...@intel.com; helin.zh...@intel.com; Junfeng Guo
> ; Rushil Gupta ; Jordan
> Kimbrough ; Jeroen de Borst 
> Subject: [RFC v2 6/9] net/gve: support basic Rx data path for DQO
> 
> Add basic Rx data path support for DQO.
> 
> Signed-off-by: Junfeng Guo 
> Signed-off-by: Rushil Gupta 
> Signed-off-by: Jordan Kimbrough 
> Signed-off-by: Jeroen de Borst 
> ---
>  drivers/net/gve/gve_ethdev.c |   1 +
>  drivers/net/gve/gve_ethdev.h |   3 +
>  drivers/net/gve/gve_rx_dqo.c | 128 +++
>  3 files changed, 132 insertions(+)
> 
> diff --git a/drivers/net/gve/gve_ethdev.c b/drivers/net/gve/gve_ethdev.c index
> 512a038968..89e3f09c37 100644
> --- a/drivers/net/gve/gve_ethdev.c
> +++ b/drivers/net/gve/gve_ethdev.c
> @@ -703,6 +703,7 @@ gve_dev_init(struct rte_eth_dev *eth_dev)
>   } else {
>   /* override Tx/Rx setup/release eth_dev ops */
>   gve_eth_dev_ops_override(&gve_local_eth_dev_ops);
> + eth_dev->rx_pkt_burst = gve_rx_burst_dqo;
>   eth_dev->tx_pkt_burst = gve_tx_burst_dqo;
>   }
> 
> diff --git a/drivers/net/gve/gve_ethdev.h b/drivers/net/gve/gve_ethdev.h index
> ba657dd6c1..d434f9babe 100644
> --- a/drivers/net/gve/gve_ethdev.h
> +++ b/drivers/net/gve/gve_ethdev.h
> @@ -366,6 +366,9 @@ gve_stop_tx_queues_dqo(struct rte_eth_dev *dev);
> void  gve_stop_rx_queues_dqo(struct rte_eth_dev *dev);
> 
> +uint16_t
> +gve_rx_burst_dqo(void *rxq, struct rte_mbuf **rx_pkts, uint16_t
> +nb_pkts);
> +
>  uint16_t
>  gve_tx_burst_dqo(void *txq, struct rte_mbuf **tx_pkts, uint16_t nb_pkts);
> 
> diff --git a/drivers/net/gve/gve_rx_dqo.c b/drivers/net/gve/gve_rx_dqo.c index
> aca6f8ea2d..244517ce5d 100644
> --- a/drivers/net/gve/gve_rx_dqo.c
> +++ b/drivers/net/gve/gve_rx_dqo.c
> @@ -5,6 +5,134 @@
>  #include "gve_ethdev.h"
>  #include "base/gve_adminq.h"
> 
> +static inline void
> +gve_rx_refill_dqo(struct gve_rx_queue *rxq) {
> + volatile struct gve_rx_desc_dqo *rx_buf_ring;
> + volatile struct gve_rx_desc_dqo *rx_buf_desc;
> + struct rte_mbuf *nmb[rxq->free_thresh];
> + uint16_t nb_refill = rxq->free_thresh;
> + uint16_t nb_desc = rxq->nb_rx_desc;
> + uint16_t next_avail = rxq->bufq_tail;
> + struct rte_eth_dev *dev;
> + uint64_t dma_addr;
> + uint16_t delta;
> + int i;
> +
> + if (rxq->nb_rx_hold < rxq->free_thresh)
> + return;
> +
> + rx_buf_ring = rxq->rx_ring;
> + delta = nb_desc - next_avail;
> + if (unlikely(delta < nb_refill)) {
> + if (likely(rte_pktmbuf_alloc_bulk(rxq->mpool, nmb, delta) ==
> 0)) {
> + for (i = 0; i < delta; i++) {
> + rx_buf_desc = &rx_buf_ring[next_avail + i];
> + rxq->sw_ring[next_avail + i] = nmb[i];
> + dma_addr =
> rte_cpu_to_le_64(rte_mbuf_data_iova_default(nmb[i]));
> + rx_buf_desc->header_buf_addr = 0;
> + rx_buf_desc->buf_addr = dma_addr;
> + }
> + nb_refill -= delta;
> + next_avail = 0;
> + rxq->nb_rx_hold -= delta;
> + } else {
> + dev = &rte_eth_devices[rxq->port_id];
> + dev->data->rx_mbuf_alloc_failed += nb_desc -
> next_avail;
> + PMD_DRV_LOG(DEBUG, "RX mbuf alloc failed
> port_id=%u queue_id=%u",
> + rxq->port_id, rxq->queue_id);
> + return;
> + }
> + }
> +
> + if (nb_desc - next_avail >= nb_refill) {
> + if (likely(rte_pktmbuf_alloc_bulk(rxq->mpool, nmb, nb_refill)
> == 0)) {
> + for (i = 0; i < nb_refill; i++) {
> + rx_buf_desc = &rx_buf_ring[next_avail + i];
> + rxq->sw_ring[next_avail + i] = nmb[i];
> + dma_addr =
> rte_cpu_to_le_64(rte_mbuf_data_iova_default(nmb[i]));
> + rx_buf_desc->header_buf_addr = 0;
> + rx_buf_desc->buf_addr = dma_addr;
> + }
> + next_avail += nb_refill;
> + rxq->nb_rx_hold -= nb_refill;
> + } else {
> + dev = &rte_eth_devices[rxq->port_id];
> + dev->data->rx_mbuf_alloc_failed += nb_desc -
> next_avail;
> + PMD_DRV_LOG(DEBUG, "RX mbuf alloc failed
> port_id=%u queue_id=%u",
> + rxq->port_id, rxq->queue_id);
> + }
> + }
> +
> + rte_write32(next_avail, rxq->qrx_tail);
> +
> + rxq->bufq_tail = next_avail;
> +}
> +
> +uint16_t
> +gve_rx_burst_dqo(voi

RE: [EXT] [PATCH 1/4] compressdev: add LZ4 algorithm support

[Akhil Goyal]

> +/**
> + * Block checksum flag.
> + * If this flag is set, each data block will be followed by a 4-bytes 
> checksum,
> + * calculated by using the xxHash-32 algorithm on the raw (compressed) data
> + * block. The intention is to detect data corruption (storage or transmission
> + * errors) immediately, before decoding. Block checksum usage is optional.
> + */
> +#define RTE_COMP_LZ4_FLAG_BLOCK_CHECKSUM (1 << 4)
> +
> +/**
> + * Block Independence flag.
> + * If this flag is set to 1, blocks are independent.
> + * If this flag is set to 0, each block depends on previous ones (up to LZ4
> + * window size, which is 64 KB). In such case, it is necessary to decode all
> + * blocks in sequence.
> + * Block dependency improves compression ratio, especially for small blocks.
> On
> + * the other hand, it makes random access or multi-threaded decoding
> impossible.
> + */
> +#define RTE_COMP_LZ4_FLAG_BLOCK_INDEPENDENCE (1 << 5)

Why did you start with 4th and 5th bit of the flags? Why not first two bits?

++ more people for review.

RE: [EXT] [PATCH v2 1/4] crypto/ccp: remove some printf

[Akhil Goyal]

> A DPDK application must _not_ use printf.
> Use log framework.
> 
> Fixes: ef4b04f87fa6 ("crypto/ccp: support device init")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: David Marchand 
First 3 patches of the series applied to dpdk-next-crypto

Please submit the last patch again with the required changes.

Thanks.

Re: [PATCH v9] testpmd: cleanup cleanly from signal

[Ferruh Yigit]

On 1/25/2023 6:32 PM, Stephen Hemminger wrote:
> Do a clean shutdown of testpmd when a signal is received; instead of
> having testpmd kill itself.  This fixes the problem where a signal could
> be received in the middle of a PMD and then the signal handler would
> call PMD's close routine leading to locking problems.
> 
> An added benefit is it gets rid of some Windows specific code.
> 
> Fixes: d9a191a00e81 ("app/testpmd: fix quitting in container")
> Signed-off-by: Stephen Hemminger 

Patch looks good to me, but './devtools/test-null.sh' hangs with change.

It is possible the fix by updating './devtools/test-null.sh', but my
concern is if this behavior change hit more consumers other than this
internal tool, and I am for keeping previous behavior.

'./devtools/test-null.sh' sends 'stop' command to testpmd but that seems
not really what makes testpmd quit, because following change still works
with original testpmd code:
 -(sleep 1 && echo stop) |
 +(sleep 1 && echo help) |
Somehow testpmd gets Ctrl-D or equivalent with above command.

And it seems because of 'cmdline_interact()' and 'cmdline_poll()'
difference behavior changes with above command.

It is possible to add something like  'cmdline_interact_one()' (non loop
version of 'cmdline_interact()'), but not really sure that is correct
way to fix the issue.


> ---
> v9 - also handle the interactive case.
>  use cmdine_poll() rather than signals and atexit
> 
>  app/test-pmd/cmdline.c | 28 +--
>  app/test-pmd/testpmd.c | 77 --
>  app/test-pmd/testpmd.h |  1 +
>  3 files changed, 46 insertions(+), 60 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index b32dc8bfd445..fbe9ad694dee 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -65,7 +65,6 @@
>  #include "cmdline_tm.h"
>  #include "bpf_cmd.h"
>  
> -static struct cmdline *testpmd_cl;
>  static cmdline_parse_ctx_t *main_ctx;
>  static TAILQ_HEAD(, testpmd_driver_commands) driver_commands_head =
>   TAILQ_HEAD_INITIALIZER(driver_commands_head);
> @@ -12921,28 +12920,19 @@ cmdline_read_from_file(const char *filename)
>  void
>  prompt(void)
>  {
> - int ret;
> + struct cmdline *cl;
>  
> - testpmd_cl = cmdline_stdin_new(main_ctx, "testpmd> ");
> - if (testpmd_cl == NULL)
> + cl = cmdline_stdin_new(main_ctx, "testpmd> ");
> + if (cl == NULL)
>   return;
>  
> - ret = atexit(prompt_exit);
> - if (ret != 0)
> - fprintf(stderr, "Cannot set exit function for cmdline\n");
> -
> - cmdline_interact(testpmd_cl);
> - if (ret != 0)
> - cmdline_stdin_exit(testpmd_cl);
> -}
> -
> -void
> -prompt_exit(void)
> -{
> - if (testpmd_cl != NULL) {
> - cmdline_quit(testpmd_cl);
> - cmdline_stdin_exit(testpmd_cl);
> + while (f_quit == 0 && cl_quit == 0) {
> + if (cmdline_poll(cl) < 0)
> + break;
>   }
> +
> + cmdline_quit(cl);
> + cmdline_stdin_exit(cl);
>  }
>  
>  void
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 134d79a55547..d01b6105b7de 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -11,6 +11,7 @@
>  #include 
>  #ifndef RTE_EXEC_ENV_WINDOWS
>  #include 
> +#include 
>  #endif
>  #include 
>  #include 
> @@ -231,7 +232,7 @@ unsigned int xstats_display_num; /**< Size of extended 
> statistics to show */
>   * In container, it cannot terminate the process which running with 
> 'stats-period'
>   * option. Set flag to exit stats period loop after received SIGINT/SIGTERM.
>   */
> -static volatile uint8_t f_quit;
> +volatile uint8_t f_quit;
>  uint8_t cl_quit; /* Quit testpmd from cmdline. */
>  
>  /*
> @@ -4315,13 +4316,6 @@ init_port(void)
>   memset(txring_numa, NUMA_NO_CONFIG, RTE_MAX_ETHPORTS);
>  }
>  
> -static void
> -force_quit(void)
> -{
> - pmd_test_exit();
> - prompt_exit();
> -}
> -
>  static void
>  print_stats(void)
>  {
> @@ -4340,28 +4334,9 @@ print_stats(void)
>  }
>  
>  static void
> -signal_handler(int signum)
> +signal_handler(int signum __rte_unused)
>  {
> - if (signum == SIGINT || signum == SIGTERM) {
> - fprintf(stderr, "\nSignal %d received, preparing to exit...\n",
> - signum);
> -#ifdef RTE_LIB_PDUMP
> - /* uninitialize packet capture framework */
> - rte_pdump_uninit();
> -#endif
> -#ifdef RTE_LIB_LATENCYSTATS
> - if (latencystats_enabled != 0)
> - rte_latencystats_uninit();
> -#endif
> - force_quit();
> - /* Set flag to indicate the force termination. */
> - f_quit = 1;
> - /* exit with the expected status */
> -#ifndef RTE_EXEC_ENV_WINDOWS
> - signal(signum, SIG_DFL);
> - kill(getpid(), signum);
> -#endif
> - }
> + f_quit = 1;
>  }
>  
>  int
> @@ -4536,15 +4511,9 @@ main(int argc, char** argv)
> 

RE: [PATCH 3/4] cryptodev: introduce query API for error interrupt event

[Akhil Goyal]

> Subject: [PATCH 3/4] cryptodev: introduce query API for error interrupt event
> 
> An event RTE_CRYPTODEV_EVENT_ERROR gets fired when crypto PMD receives
> an error interrupt. This patch adds query function for the application,
> to get more info about the event.
> 
> Signed-off-by: Srujana Challa 
Acked-by: Akhil Goyal 

RE: [PATCH 4/4] crypto/cnxk: add error interrupt event query handler

[Akhil Goyal]

> Subject: [PATCH 4/4] crypto/cnxk: add error interrupt event query handler
> 
> Adds RTE_CRYPTODEV_EVENT_ERROR query handler for cn9k/cn10k PMD.
> The query handler finds the next queue pair ID with pending error
> interrupt event if any, starting from the given queue pair index,
> for the device.
> 
> Signed-off-by: Srujana Challa 
The patch description do not match with the API added.
Can you please update it?

Thanks.

RE: [PATCH v2 1/3] cryptodev: add SHAKE algorithm

[Akhil Goyal]

> -Original Message-
> From: Volodymyr Fialko 
> Sent: Thursday, January 12, 2023 4:18 PM
> To: dev@dpdk.org; Akhil Goyal ; Fan Zhang
> 
> Cc: Jerin Jacob Kollanukkaran ; Anoob Joseph
> ; Volodymyr Fialko 
> Subject: [PATCH v2 1/3] cryptodev: add SHAKE algorithm
> 
> Add SHAKE to enum of auth algorithms.
> 
> Signed-off-by: Volodymyr Fialko 
Acked-by: Akhil Goyal 

RE: [PATCH v2 2/3] app/test: add SHAKE test cases

[Akhil Goyal]

> Subject: [PATCH v2 2/3] app/test: add SHAKE test cases
> 
> Add test cases for SHAKE hash algorithm for Digest and Digest-Verify.
> 
> Signed-off-by: Volodymyr Fialko 
> ---
Acked-by: Akhil Goyal 

RE: [PATCH] test/crypto: add missing MAC-I to PDCP vectors

[Akhil Goyal]

> Subject: [PATCH] test/crypto: add missing MAC-I to PDCP vectors
> 
> Existing PDCP 12-bit C/U-plane output vectors with NULL encryption + NULL
> integrity do not contain the MAC-I (32-bit of all zeros according to the
> specification).
> Vectors for other SN length (5, 18 bits) have the MAC-I set.
> 
> Fixes: d883e6e7131b ("test/crypto: add PDCP C-Plane encap cases")
> Fixes: cca7d1f78524 ("test/crypto: add PDCP U-Plane encap with integrity
> cases")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Volodymyr Fialko 
Acked-by: Akhil Goyal 

RE: [EXT] [PATCH] compressdev: fix end of comp PMD list macro conflict

[Akhil Goyal]

> The "rte_compressdev_info_get()" function retrieves the contextual
> information of a device.
> The output structure "dev_info" contains a list of devices supported
> capabilities for each supported algorithm.
> 
> In this function description, it says the element after the last valid
> element has op field set to "RTE_COMP_ALGO_LIST_END".
> On the other hand, when this function used by
> "rte_compressdev_capability_get()" function, it uses
> "RTE_COMP_ALGO_UNSPECIFIED" as end of list as same as the
> "RTE_COMP_END_OF_CAPABILITIES_LIST()".
> 
> The mlx5 and qat PMDs use "RTE_COMP_ALGO_LIST_END" as the end of
> capabilities list. When "rte_compressdev_capability_get()" function is
> called with unsupported algorithm, it might read memory out of bound.
> 
> This patch change the "rte_compressdev_info_get()" function description
> to say using "RTE_COMP_ALGO_UNSPECIFIED" as the end of capabilities
> list.
> In addition, it moves both mlx5 and qat PMDs to use
> "RTE_COMP_ALGO_UNSPECIFIED" through
> "RTE_COMP_END_OF_CAPABILITIES_LIST()" macro.
> 
> Fixes: 5d432f364078 ("compressdev: add device capabilities")
> Fixes: 2d148597ce76 ("compress/qat: add gen-specific implementation")
> Fixes: 384bac8d6555 ("compress/mlx5: add supported capabilities")
> Cc: fiona.tr...@intel.com
> Cc: roy.fan.zh...@intel.com
> Cc: ma...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Michael Baum 
> 
> ---
> 
> After this change, I'm not sure about the purpose of
> "RTE_COMP_ALGO_LIST_END".
> There is no any other use of it in DPDK code, and it isn't represent the
> number of algorithms supported by the API since the
> "RTE_COMP_ALGO_UNSPECIFIED" is part of the enum.
> 
> Due to the compress API is experimental I think the
> "RTE_COMP_ALGO_LIST_END" can be removed.
> 
+1 to remove the list end enums. This will also help in avoiding ABI breakage
When we make this lib as stable.

[PATCH v10 0/2] testpmd: handle signals safely

[Stephen Hemminger]

Fixing the signal handling in testpmd requires also
fixing EOF handling in cmdline_poll()

Stephen Hemminger (2):
  cmdline: handle EOF in cmdline_poll
  testpmd: cleanup cleanly from signal

 app/test-pmd/cmdline.c | 30 ++--
 app/test-pmd/testpmd.c | 77 --
 app/test-pmd/testpmd.h |  1 +
 lib/cmdline/cmdline.c  |  2 +-
 4 files changed, 49 insertions(+), 61 deletions(-)

-- 
2.39.0

[PATCH v10 1/2] cmdline: handle EOF in cmdline_poll

[Stephen Hemminger]

If end of file is reached on input, then cmdline_read_char()
will return 0. The problem is that cmdline_poll() was not checking
for this and would continue and not return the status.

Fixes: 9251cd97a6be ("cmdline: add internal wrappers for character input")
Signed-off-by: Stephen Hemminger 
---
 lib/cmdline/cmdline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cmdline/cmdline.c b/lib/cmdline/cmdline.c
index e1009ba4c413..de41406d61e0 100644
--- a/lib/cmdline/cmdline.c
+++ b/lib/cmdline/cmdline.c
@@ -194,7 +194,7 @@ cmdline_poll(struct cmdline *cl)
else if (status > 0) {
c = -1;
read_status = cmdline_read_char(cl, &c);
-   if (read_status < 0)
+   if (read_status <= 0)
return read_status;
 
status = cmdline_in(cl, &c, 1);
-- 
2.39.0

[PATCH v10 2/2] testpmd: cleanup cleanly from signal

[Stephen Hemminger]

Do a clean shutdown of testpmd when a signal is received; instead of
having testpmd kill itself.  This fixes the problem where a signal could
be received in the middle of a PMD and then the signal handler would
call PMD's close routine leading to locking problems.

An added benefit is it gets rid of some Windows specific code.

Fixes: d9a191a00e81 ("app/testpmd: fix quitting in container")
Signed-off-by: Stephen Hemminger 
---
 app/test-pmd/cmdline.c | 30 ++--
 app/test-pmd/testpmd.c | 77 --
 app/test-pmd/testpmd.h |  1 +
 3 files changed, 48 insertions(+), 60 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd445..1f73056eb19a 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -65,7 +65,6 @@
 #include "cmdline_tm.h"
 #include "bpf_cmd.h"
 
-static struct cmdline *testpmd_cl;
 static cmdline_parse_ctx_t *main_ctx;
 static TAILQ_HEAD(, testpmd_driver_commands) driver_commands_head =
TAILQ_HEAD_INITIALIZER(driver_commands_head);
@@ -12921,28 +12920,21 @@ cmdline_read_from_file(const char *filename)
 void
 prompt(void)
 {
-   int ret;
+   struct cmdline *cl;
 
-   testpmd_cl = cmdline_stdin_new(main_ctx, "testpmd> ");
-   if (testpmd_cl == NULL)
+   cl = cmdline_stdin_new(main_ctx, "testpmd> ");
+   if (cl == NULL)
return;
 
-   ret = atexit(prompt_exit);
-   if (ret != 0)
-   fprintf(stderr, "Cannot set exit function for cmdline\n");
-
-   cmdline_interact(testpmd_cl);
-   if (ret != 0)
-   cmdline_stdin_exit(testpmd_cl);
-}
-
-void
-prompt_exit(void)
-{
-   if (testpmd_cl != NULL) {
-   cmdline_quit(testpmd_cl);
-   cmdline_stdin_exit(testpmd_cl);
+   /* loop until signal or quit command */
+   while (f_quit == 0 && cl_quit == 0) {
+   /* exit loop on eof or read error */
+   if (cmdline_poll(cl) <= 0)
+   break;
}
+
+   cmdline_quit(cl);
+   cmdline_stdin_exit(cl);
 }
 
 void
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 134d79a55547..d01b6105b7de 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -11,6 +11,7 @@
 #include 
 #ifndef RTE_EXEC_ENV_WINDOWS
 #include 
+#include 
 #endif
 #include 
 #include 
@@ -231,7 +232,7 @@ unsigned int xstats_display_num; /**< Size of extended 
statistics to show */
  * In container, it cannot terminate the process which running with 
'stats-period'
  * option. Set flag to exit stats period loop after received SIGINT/SIGTERM.
  */
-static volatile uint8_t f_quit;
+volatile uint8_t f_quit;
 uint8_t cl_quit; /* Quit testpmd from cmdline. */
 
 /*
@@ -4315,13 +4316,6 @@ init_port(void)
memset(txring_numa, NUMA_NO_CONFIG, RTE_MAX_ETHPORTS);
 }
 
-static void
-force_quit(void)
-{
-   pmd_test_exit();
-   prompt_exit();
-}
-
 static void
 print_stats(void)
 {
@@ -4340,28 +4334,9 @@ print_stats(void)
 }
 
 static void
-signal_handler(int signum)
+signal_handler(int signum __rte_unused)
 {
-   if (signum == SIGINT || signum == SIGTERM) {
-   fprintf(stderr, "\nSignal %d received, preparing to exit...\n",
-   signum);
-#ifdef RTE_LIB_PDUMP
-   /* uninitialize packet capture framework */
-   rte_pdump_uninit();
-#endif
-#ifdef RTE_LIB_LATENCYSTATS
-   if (latencystats_enabled != 0)
-   rte_latencystats_uninit();
-#endif
-   force_quit();
-   /* Set flag to indicate the force termination. */
-   f_quit = 1;
-   /* exit with the expected status */
-#ifndef RTE_EXEC_ENV_WINDOWS
-   signal(signum, SIG_DFL);
-   kill(getpid(), signum);
-#endif
-   }
+   f_quit = 1;
 }
 
 int
@@ -4536,15 +4511,9 @@ main(int argc, char** argv)
start_packet_forwarding(0);
}
prompt();
-   pmd_test_exit();
} else
 #endif
{
-   char c;
-   int rc;
-
-   f_quit = 0;
-
printf("No commandline core given, start packet forwarding\n");
start_packet_forwarding(tx_first);
if (stats_period != 0) {
@@ -4567,15 +4536,41 @@ main(int argc, char** argv)
prev_time = cur_time;
rte_delay_us_sleep(US_PER_S);
}
-   }
+   } else {
+   char c;
+   fd_set fds;
+
+   printf("Press enter to exit\n");
 
-   printf("Press enter to exit\n");
-   rc = read(0, &c, 1);
-   pmd_test_exit();
-   if (rc < 0)
-   return 1;
+   FD_ZERO(&fds);
+   FD_SET(0, &fds);
+
+   /* wait 

Re: [PATCH v9] testpmd: cleanup cleanly from signal

[Stephen Hemminger]

On Mon, 30 Jan 2023 18:48:25 +
Ferruh Yigit  wrote:

> On 1/25/2023 6:32 PM, Stephen Hemminger wrote:
> > Do a clean shutdown of testpmd when a signal is received; instead of
> > having testpmd kill itself.  This fixes the problem where a signal could
> > be received in the middle of a PMD and then the signal handler would
> > call PMD's close routine leading to locking problems.
> > 
> > An added benefit is it gets rid of some Windows specific code.
> > 
> > Fixes: d9a191a00e81 ("app/testpmd: fix quitting in container")
> > Signed-off-by: Stephen Hemminger   
> 
> Patch looks good to me, but './devtools/test-null.sh' hangs with change.
> 
> It is possible the fix by updating './devtools/test-null.sh', but my
> concern is if this behavior change hit more consumers other than this
> internal tool, and I am for keeping previous behavior.
> 
> './devtools/test-null.sh' sends 'stop' command to testpmd but that seems
> not really what makes testpmd quit, because following change still works
> with original testpmd code:
>  -(sleep 1 && echo stop) |
>  +(sleep 1 && echo help) |
> Somehow testpmd gets Ctrl-D or equivalent with above command.
> 
> And it seems because of 'cmdline_interact()' and 'cmdline_poll()'
> difference behavior changes with above command.
> 
> It is possible to add something like  'cmdline_interact_one()' (non loop
> version of 'cmdline_interact()'), but not really sure that is correct
> way to fix the issue.
> 

Thanks for the review.
Fixed the end-of-file handling in v10 of the patch.
The cmdline_poll() function doesn't handle EOF correctly.

The function cmdline_poll() documentation is problematic since it
references that the return value is an enum, but the enum is actually
private and not exported by the library!

Re: Commit broke 32-bit testpmd app

[Sampath Peechu (speechu)]

Hi Maxime,

Could you please let us know if you got a chance to look at the debugs logs I 
provided?

Thanks,
Sampath


From: Sampath Peechu (speechu) 
Date: Tuesday, December 6, 2022 at 1:08 PM
To: Maxime Coquelin , chenbo@intel.com 
, dev@dpdk.org 
Cc: Roger Melton (rmelton) 
Subject: Re: Commit broke 32-bit testpmd app
Hi Maxime,

Did you get a chance to look into this?

Please let me know if you need anything else.

Thanks,
Sampath

From: Sampath Peechu (speechu) 
Date: Wednesday, November 23, 2022 at 5:15 PM
To: Maxime Coquelin , chenbo@intel.com 
, dev@dpdk.org 
Cc: Roger Melton (rmelton) 
Subject: Re: Commit broke 32-bit testpmd app
Hi Maxime,

I’m attaching the following for reference.


  *   Instructions for Centos8 test setup
  *   Diffs between the working and non-working versions (working version has 
the problem commit backed out)
  *   Working logs (stats show that ping packets from neighbor VM can be seen 
with both 64-bit and 32-bit apps)
  *   Non-working logs (stats show that ping packets from neighbor VM are seen 
with 64-bit app but NOT seen with 32-bit app)




$ sudo ./usertools/dpdk-devbind.py --status

Network devices using DPDK-compatible driver

:07:00.0 'Virtio network device 1041' drv=igb_uio unused=
:08:00.0 'Virtio network device 1041' drv=igb_uio unused=

Network devices using kernel driver
===
:01:00.0 'Virtio network device 1041' if=enp1s0 drv=virtio-pci 
unused=igb_uio *Active*

…
===


Thanks,
Sampath



From: Maxime Coquelin 
Date: Tuesday, November 22, 2022 at 4:24 AM
To: Sampath Peechu (speechu) , chenbo@intel.com 
, dev@dpdk.org 
Cc: Roger Melton (rmelton) 
Subject: Re: Commit broke 32-bit testpmd app
Hi,

In my initial reply (see below), I also asked if you had logs to share.
And wondered whether it happens with Virtio PCI or Virtio-user?

Regards,
Maxime

On 11/16/22 00:30, Sampath Peechu (speechu) wrote:
> ++ dev@dpdk.org 
>
> *From: *Maxime Coquelin 
> *Date: *Tuesday, November 15, 2022 at 3:19 AM
> *To: *Sampath Peechu (speechu) , chenbo@intel.com
> 
> *Cc: *Roger Melton (rmelton) 
> *Subject: *Re: Commit broke 32-bit testpmd app
>
> Hi Sampath,
>
>
> Please add dev@dpdk.org, the upstream mailing list, if this is related
> to the upstream DPDK project.If it is using RHEL DPDK package, please
> use the appropriate support channels.
>
> On 11/14/22 23:55, Sampath Peechu (speechu) wrote:
>  > Hi Virtio Maintainers team,
>  >
>  > This email is regarding the following commit.
>  >
>  >
> https://github.com/DPDK/dpdk/commit/ba55c94a7ebc386d2288d6578ed57aad6cb92657 
> 
>  
>  >
>  >
>  > The above commit appears to have broken the 32-bit testpmd app (and
>  > consequently impacted one of our products that runs as a 32-bit DPDK
>  > app). The 64-bit testpmd app does not appear to be impacted though.
>
> We'll need some logs to understand what is going on.
> Does it happen with virtio-pci or virtio-user?
>
> Regards,
> Maxime
>
>  > With the commit in place, we didn’t see any packets going through at
>  > all. After backing out the commit and rebuilding the 32-bit testpmd app
>  > in our test setup, we were able to pass traffic as expected.
>  >
>  > Could you please let us know if this is a known issue? And if there is a
>  > fix available for it?
>  >
>  > Thank you,
>  >
>  > Sampath Peechu
>  >
>  > Cisco Systems
>  >
>

Re: [PATCH v10 4/4] eal: deprecation notice for rte thread setname API

[Tyler Retzlaff]

On Mon, Jan 30, 2023 at 05:19:20PM +0100, David Marchand wrote:
> On Mon, Jan 30, 2023 at 4:47 PM Thomas Monjalon  wrote:
> >
> > Hi,
> >
> > The title should start with a verb.
> > I suppose it can be fixed while merging with a title like:
> > doc: announce deprecation of thread naming function
> 
> Yes, I will handle it.
> 
> > 24/01/2023 19:12, Tyler Retzlaff:
> > > Notify deprecation of rte_thread_setname API, it will be removed as it
> > > exposes platform-specific thread details. The functionality it provided
> > > is now available via the new rte_lcore_set_name API.
> > >
> > > Signed-off-by: Tyler Retzlaff 
> > > Acked-by: Morten Brørup 
> > > Acked-by: David Marchand 
> > > ---
> > > +* eal: The function ``rte_thread_setname`` is planned to be deprecated
> > > +  starting with the 23.07 release subject to the replacement API
> > > +  rte_thread_set_name being marked as stable and planned to be removed
> > > +  by the 23.11 release.
> >
> > Minor: it would be clearer if adding some commas after "release" and 
> > "stable".
> 
> And this too.
> 
> >
> >
> > For the series,
> > Acked-by: Thomas Monjalon 
> 
> Thanks.

thank you both, i'll rebase the rte_ctrl_thread_create patch series once
this is merged to get it moving forward again.

RE: [EXT] [PATCH 1/4] compressdev: add LZ4 algorithm support

[Michael Baum]

On Mon, Jan 30, 2023 at 20:35 PM Akhil Goyal  wrote: 
> 
> > +/**
> > + * Block checksum flag.
> > + * If this flag is set, each data block will be followed by a 4-bytes 
> > checksum,
> > + * calculated by using the xxHash-32 algorithm on the raw (compressed) data
> > + * block. The intention is to detect data corruption (storage or 
> > transmission
> > + * errors) immediately, before decoding. Block checksum usage is optional.
> > + */
> > +#define RTE_COMP_LZ4_FLAG_BLOCK_CHECKSUM (1 << 4)
> > +
> > +/**
> > + * Block Independence flag.
> > + * If this flag is set to 1, blocks are independent.
> > + * If this flag is set to 0, each block depends on previous ones (up to LZ4
> > + * window size, which is 64 KB). In such case, it is necessary to decode 
> > all
> > + * blocks in sequence.
> > + * Block dependency improves compression ratio, especially for small 
> > blocks.
> > On
> > + * the other hand, it makes random access or multi-threaded decoding
> > impossible.
> > + */
> > +#define RTE_COMP_LZ4_FLAG_BLOCK_INDEPENDENCE (1 << 5)
> 
> Why did you start with 4th and 5th bit of the flags? Why not first two bits?

I didn't choose the values by myself, I took them from LZ4 standard:
https://github.com/lz4/lz4/blob/dev/doc/lz4_Frame_format.md#frame-descriptor

> 
> ++ more people for review.

Re: [PATCH v10 1/2] cmdline: handle EOF in cmdline_poll

[Ferruh Yigit]

On 1/30/2023 8:09 PM, Stephen Hemminger wrote:
> If end of file is reached on input, then cmdline_read_char()
> will return 0. The problem is that cmdline_poll() was not checking
> for this and would continue and not return the status.
> 
> Fixes: 9251cd97a6be ("cmdline: add internal wrappers for character input")
> Signed-off-by: Stephen Hemminger 
> ---
>  lib/cmdline/cmdline.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/cmdline/cmdline.c b/lib/cmdline/cmdline.c
> index e1009ba4c413..de41406d61e0 100644
> --- a/lib/cmdline/cmdline.c
> +++ b/lib/cmdline/cmdline.c
> @@ -194,7 +194,7 @@ cmdline_poll(struct cmdline *cl)
>   else if (status > 0) {
>   c = -1;
>   read_status = cmdline_read_char(cl, &c);
> - if (read_status < 0)
> + if (read_status <= 0)
>   return read_status;

According API doc it will be wrong to return '0', which imply 'RDLINE_INIT'.

But function may return any negative value on error, what about to get
eof as and error case:

if (read_status < 0)
return read_status;
else if (read_status == 0)
return -EIO;

With this 'cmdline_poll()' can be used in testpmd as it is used in v9 of
this patch:
while (f_quit == 0 && cl_quit == 0) {
if (cmdline_poll(cl) < 0)
break;
}



But still I guess this is an ABI break because of API behavior change.

Re: [PATCH v10 0/2] testpmd: handle signals safely

[Ferruh Yigit]

On 1/30/2023 8:09 PM, Stephen Hemminger wrote:
> Fixing the signal handling in testpmd requires also
> fixing EOF handling in cmdline_poll()
> 
> Stephen Hemminger (2):
>   cmdline: handle EOF in cmdline_poll
>   testpmd: cleanup cleanly from signal
> 

I confirm this solves the EOF issue, but please check comment on the
cmdline library patch (1/2).

RE: [PATCH v7] ethdev: add special flags when creating async transfer table

[Ivan Malov]

Hi Rongwei,

Thanks for the professional attitude.
Hope this discussion gets us on the
same page. Please see below.

On Mon, 30 Jan 2023, Rongwei Liu wrote:


HI Ivan

BR
Rongwei


-Original Message-
From: Ivan Malov 
Sent: Monday, January 30, 2023 15:40
To: Rongwei Liu 
Cc: Matan Azrad ; Slava Ovsiienko
; Ori Kam ; NBU-Contact-
Thomas Monjalon (EXTERNAL) ; Aman Singh
; Yuying Zhang ;
Ferruh Yigit ; Andrew Rybchenko
; dev@dpdk.org; Raslan Darawsheh

Subject: RE: [PATCH v7] ethdev: add special flags when creating async transfer
table

External email: Use caution opening links or attachments


Hi Rongwei,

For my responses, PSB.

By the way, now you mention things like wasting memory and insertion
optimisastions, are there any comparative figures to see the effect of this hint
on insertion performance / memory footprint?
Some "before" / "after" examples would really be helpful.


Good to hear we reach agreement almost.


Very well.

The key point here is that one may agree that some optimisations
are indeed needed, yes. I don't deny the fact that some vendors
might have issues with how the API maps to the HW capabilities.
Yes, some undesirable resource overhead shall be avoided, but
the high level hints for that have to be designed with care.


First, the hint has nothing related to matching, only affects PMD resource 
management.


You say "PMD resource management". For the flow management, that's mostly
vendor-specific, I take it. Let me explain. The application, for instance,
can control the number of Tx descriptors in the queue during setup stage.
Tx descriptors are a common type of HW resource, hence the explicit
control for it available to applications. For flow library, it's
not like that. Different vendors have different "underlayer"
representations, they may vary drastically.

I take it, in the case of the HW you're working with, this hint indeed
maps to something that is entirely resource-related and which does not
belong in this specific vendor's match criteria. I 100% understand
that, in your case, these are separate. But the point is that, on
the high-level programming level (vendor-neutral), such a hint
is in fact a match criterion. Because it tells the driver to
limit the scope of matching to just "from net"/"from vport",
the same way other metadata items do (represented_port).
The only difference is that it refers to a group of
unspecified ports which have something in common.

So, although I don't strongly object having some hints like this one
in the generic API, I nevertheless disagree with describing this as
just "resource-specific" and not being a match criterion. It's just
not always the case. It might not be valid for *all* NIC vendors.


In my local test, it can save around 50% memory in the VxLAN encap/decap 
example case.


Forgive me in case this has been already discussed; where's that memory?
I mean, is it some sort of general-purpose memory? Or some HW-specific
table capacity overhead? I'm trying to understand how the feature
will be useful to other vendors, or how common this problem is.


Insertion rate has very very few improvements.

After all, I'm not objecting this patch. But I believe that other reviewers'
concerns should nevertheless be addressed anyway.

Let me try to show the hint is useful.


On Mon, 30 Jan 2023, Rongwei Liu wrote:


Hi Ivan,

BR
Rongwei


-Original Message-
From: Ivan Malov 
Sent: Monday, January 30, 2023 08:00
To: Rongwei Liu 
Cc: Matan Azrad ; Slava Ovsiienko
; Ori Kam ; NBU-Contact-
Thomas Monjalon (EXTERNAL) ; Aman Singh
; Yuying Zhang ;
Ferruh Yigit ; Andrew Rybchenko
; dev@dpdk.org; Raslan Darawsheh

Subject: Re: [PATCH v7] ethdev: add special flags when creating async
transfer table

External email: Use caution opening links or attachments


Hi Rongwei,

Thanks for persevering. I have no strong opinion, but, at least, the
fact that the new flags are no longer meant for use in rte_flow_attr,
which is clearly not the right place for such, is an improvement.


Thanks for the suggestion, move it to rte_flow_table_attr now and it'

dedicated to async API.

However, let's take a closer look at the current patch, shall we?

But, before we get to that, I'd like to kindly request that you
provide a more concrete example of how this feature is supposed to be
used. Are there some real-life application examples?


Sure.

Also, to me, it's still unclear how an application can obtain the
knowledge of this hint in the first instance. For example, can Open
vSwitch somehow tell ethdevs representing physical ports from ones
representing "vports" (host endpoints)?
How does it know which attribute to specify?


Hint should be initiated by application and application knows it' traffic

pattern which highly relates to deployment.

Let' use VxLAN encap/decap as an example:
1. Traffic from wire should be VxLAN pattern and do the decap, then send to

different vports.

flow pattern_template 0 create transfer relaxed no pattern_template_id
4 template r

Re: [PATCH] net/gve: add support for basic stats

[Joshua Washington]

Hello,

I tested it out, and the updates to testpmd seem to work.

Before applying the second patch:
  -- Forward statistics for port 0
 --
  RX-packets: 0  RX-dropped: 0 RX-total: 0
  TX-packets: 43769238   TX-dropped: 62634 TX-total: 43831872



  -- Forward statistics for port 1
 --
  RX-packets: 0  RX-dropped: 0 RX-total: 0
  TX-packets: 43761119   TX-dropped: 70753 TX-total: 43831872



  +++ Accumulated forward statistics for all
ports+++
  RX-packets: 0  RX-dropped: 0 RX-total: 0
  TX-packets: 87530357   TX-dropped: 157302TX-total: 87687659



62634 + 70753 = 133387 != 157302

After applying the second patch:
  -- Forward statistics for port 0
 --
  RX-packets: 0  RX-dropped: 0 RX-total: 0
  TX-packets: 12590721   TX-dropped: 36638 TX-total: 12627359



  -- Forward statistics for port 1
 --
  RX-packets: 0  RX-dropped: 0 RX-total: 0
  TX-packets: 12596255   TX-dropped: 31746 TX-total: 12628001



  +++ Accumulated forward statistics for all
ports+++
  RX-packets: 0  RX-dropped: 0 RX-total: 0
  TX-packets: 25186976   TX-dropped: 68384 TX-total: 25255360



Thanks,
Josh

On Wed, Jan 18, 2023 at 8:22 AM Ferruh Yigit  wrote:

> On 12/19/2022 7:38 PM, Joshua Washington wrote:
> > Hello,
> >
> > As it turns out, this error actually propagates to the "total" stats as
> > well, which I assume is just calculated by adding TX-packets and
> > TX-dropped. Here are the full stats from the example that Rushil
> mentioned:
> >
> >   -- Forward statistics for port 0
> >  --
> >   RX-packets: 2453802RX-dropped: 0 RX-total: 2453802
> >   TX-packets: 34266881   TX-dropped: 447034TX-total: 34713915
> >
> >
> 
> >
> >   -- Forward statistics for port 1
> >  --
> >   RX-packets: 34713915   RX-dropped: 0 RX-total: 34713915
> >   TX-packets: 2453802TX-dropped: 0 TX-total: 2453802
> >
> >
> 
> >
> >   +++ Accumulated forward statistics for all
> > ports+++
> >   RX-packets: 37167717   RX-dropped: 0 RX-total: 37167717
> >   TX-packets: 36720683   TX-dropped: 807630TX-total: 37528313
> >
> >
> 
> >
> > It can be seen that the stats for the individual ports are consistent,
> > but the TX-total and TX-dropped are not consistent with the stats for
> > the individual ports, as I believe that the TX-total and RX-total
> > accumulated stats should be equal.
> >
>
> Hi Joshua, Rushil,
>
> As I checked for it, issue may be related to testpmd stats display,
>
> While displaying per port TX-dropped value, it only takes
> 'ports_stats[pt_id].tx_dropped' into account,
> but for accumulated TX-dropped results it takes both
> 'ports_stats[pt_id].tx_dropped' & 'stats.oerrors' into account.
>
> If you can reproduce it easily, can you please test with following change:
>
>  diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
>  index 134d79a55547..49322d07d7d6 100644
>  --- a/app/test-pmd/testpmd.c
>  +++ b/app/test-pmd/testpmd.c
>  @@ -2056,6 +2056,8 @@ fwd_stats_display(void)
>  fwd_cycles += fs->core_cycles;
>  }
>  for (i = 0; i < cur_fwd_config.nb_fwd_ports; i++) {
>  +   uint64_t tx_dropped = 0;
>  +
>  pt_id = fwd_ports_ids[i];
>  port = &ports[pt_id];
>
>  @@ -2077,8 +2079,9 @@ fwd_stats_display(void)
>  total_recv += stats.ipackets;
>  total_xmit += stats.opackets;
>  total_rx_dropped += stats.imissed;
>  -   total_tx_dropped += ports_stats[pt_id].tx_dropped;
>  -   total_tx_dropped += stats.oerrors;
>  +   tx_dropped += ports_stats[pt_id].tx_dropped;
>  +   tx_dropped += stats.oerrors;
>  +   total_tx_dropped += tx_dropped;
>  total_rx_

RE: [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition

[Rongwei Liu]

HI Stephen:

BR
Rongwei

> -Original Message-
> From: Stephen Hemminger 
> Sent: Tuesday, January 31, 2023 00:48
> To: Rongwei Liu 
> Cc: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; NBU-Contact-
> Thomas Monjalon (EXTERNAL) ; Aman Singh
> ; Yuying Zhang ;
> Ferruh Yigit ; Andrew Rybchenko
> ; Olivier Matz ;
> dev@dpdk.org; Raslan Darawsheh 
> Subject: Re: [PATCH v3 1/8] ethdev: add IPv6 routing extension header
> definition
> 
> External email: Use caution opening links or attachments
> 
> 
> On Mon, 30 Jan 2023 05:59:33 +0200
> Rongwei Liu  wrote:
> 
> >
> > +/**
> > + * IPv6 Routing Extension Header
> > + */
> > +struct rte_ipv6_routing_ext {
> > + uint8_t next_hdr;   /**< Protocol, next header. */
> > + uint8_t hdr_len;/**< Header length. */
> > + uint8_t type;   /**< Extension header type. */
> > + uint8_t segments_left;  /**< Valid segments number. */
> > + __extension__
> > + union {
> > + rte_be32_t flags;
> > + struct {
> > + uint8_t last_entry; /**< The last_entry field of 
> > SRH */
> > + uint8_t flag;   /**< Packet flag. */
> > + rte_be16_t tag; /**< Packet tag. */
> > + };
> > + };
> > + __extension__
> > + rte_be32_t segments[0]; /**< Each hop IPv6 address. */
> 
> Use flex array rather than zero size.
> Zero size arrays cause warnings with later compilers.
Sure. Thanks.

RE: [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition

[Rongwei Liu]

HI Stephen:

BR
Rongwei

> -Original Message-
> From: Stephen Hemminger 
> Sent: Tuesday, January 31, 2023 00:50
> To: Rongwei Liu 
> Cc: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; NBU-Contact-
> Thomas Monjalon (EXTERNAL) ; Aman Singh
> ; Yuying Zhang ;
> Ferruh Yigit ; Andrew Rybchenko
> ; Olivier Matz ;
> dev@dpdk.org; Raslan Darawsheh 
> Subject: Re: [PATCH v3 1/8] ethdev: add IPv6 routing extension header
> definition
> 
> External email: Use caution opening links or attachments
> 
> 
> On Mon, 30 Jan 2023 05:59:33 +0200
> Rongwei Liu  wrote:
> 
> > +static size_t
> > +rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data)
> 
> > +{
> > + struct rte_flow_item_ipv6_routing_ext *dst = buf;
> > + const struct rte_flow_item_ipv6_routing_ext *src = data;
> > + size_t len;
> > +
> > + if (src->hdr.hdr_len)
> > + len = src->hdr.hdr_len << 3;
> > + else
> > + len = src->hdr.segments_left << 4;
> > + if (dst == NULL)
> > + return 0;
> > + rte_memcpy((void *)((uintptr_t)(dst->hdr.segments)), 
> > src->hdr.segments,
> len);
> > + return len;
> 
> Why use rte_memcpy for such a small size? Please just use normal memcpy
> which will cause more compiler and static scan checking.
> 
Following existing routine, rte_flow_item_***_conv(). Change to memcpy() in the 
next version
> That cast is unnecessary in C because "segments" is an array and any valid
> pointer type can be passed as void *.
Sure

RE: [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition

[Rongwei Liu]

HI Stephen

BR
Rongwei

> -Original Message-
> From: Stephen Hemminger 
> Sent: Tuesday, January 31, 2023 00:48
> To: Rongwei Liu 
> Cc: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; NBU-Contact-
> Thomas Monjalon (EXTERNAL) ; Aman Singh
> ; Yuying Zhang ;
> Ferruh Yigit ; Andrew Rybchenko
> ; Olivier Matz ;
> dev@dpdk.org; Raslan Darawsheh 
> Subject: Re: [PATCH v3 1/8] ethdev: add IPv6 routing extension header
> definition
> 
> External email: Use caution opening links or attachments
> 
> 
> On Mon, 30 Jan 2023 05:59:33 +0200
> Rongwei Liu  wrote:
> 
> >
> > +/**
> > + * IPv6 Routing Extension Header
> > + */
> > +struct rte_ipv6_routing_ext {
> > + uint8_t next_hdr;   /**< Protocol, next header. */
> > + uint8_t hdr_len;/**< Header length. */
> > + uint8_t type;   /**< Extension header type. */
> > + uint8_t segments_left;  /**< Valid segments number. */
> > + __extension__
> > + union {
> > + rte_be32_t flags;
> > + struct {
> > + uint8_t last_entry; /**< The last_entry field of 
> > SRH */
> > + uint8_t flag;   /**< Packet flag. */
> > + rte_be16_t tag; /**< Packet tag. */
> > + };
> > + };
> > + __extension__
> > + rte_be32_t segments[0]; /**< Each hop IPv6 address. */
> 
> Use flex array rather than zero size.
> Zero size arrays cause warnings with later compilers.
Using flex array helps improve this network header definition but caused 
warning in the rte_flow_item_**
struct rte_flow_item_ipv6_routing_ext {
   struct rte_ipv6_routing_ext hdr; 


   
}; 
"invalid use of structure with flexible array member [-Werror=pedantic]"

[PATCH v3 0/2] add ring telemetry cmds

[Jie Hai]

This patch set supports telemetry list rings and dump info of a ring
by its name.

v1->v2:
1. Add space after "switch".
2. Fix wrong strlen parameter.

v2->v3:
1. Remove prefix "rte_" for static function.
2. Add Acked-by Konstantin Ananyev for PATCH 1.
3. Introduce functions to return strings instead copy strings.
4. Check pointer to memzone of ring.
5. Remove redundant variable.
6. Hold lock when access ring data.

Jie Hai (2):
  ring: add ring list telemetry cmd
  ring: add ring info telemetry cmd

 lib/ring/meson.build |   1 +
 lib/ring/rte_ring.c  | 123 +++
 2 files changed, 124 insertions(+)

-- 
2.33.0

[PATCH v3 1/2] ring: add ring list telemetry cmd

[Jie Hai]

This patch supports the list of rings with telemetry cmd.
An example using this command is shown below:

--> /ring/list
{
  "/ring/list": [
"HT_:7d:00.2",
"MP_mb_pool_0"
  ]
}

Signed-off-by: Jie Hai 
Acked-by: Konstantin Ananyev 
---
 lib/ring/meson.build |  1 +
 lib/ring/rte_ring.c  | 40 
 2 files changed, 41 insertions(+)

diff --git a/lib/ring/meson.build b/lib/ring/meson.build
index c20685c689ac..7fca958ed7fa 100644
--- a/lib/ring/meson.build
+++ b/lib/ring/meson.build
@@ -18,3 +18,4 @@ indirect_headers += files (
 'rte_ring_rts.h',
 'rte_ring_rts_elem_pvt.h',
 )
+deps += ['telemetry']
diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
index cddaf6b2876f..e6aac332d88f 100644
--- a/lib/ring/rte_ring.c
+++ b/lib/ring/rte_ring.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rte_ring.h"
 #include "rte_ring_elem.h"
@@ -419,3 +420,42 @@ rte_ring_lookup(const char *name)
 
return r;
 }
+
+static void
+ring_walk(void (*func)(struct rte_ring *, void *), void *arg)
+{
+   struct rte_ring_list *ring_list;
+   struct rte_tailq_entry *te;
+
+   ring_list = RTE_TAILQ_CAST(rte_ring_tailq.head, rte_ring_list);
+   rte_mcfg_tailq_read_lock();
+
+   TAILQ_FOREACH(te, ring_list, next) {
+   (*func)((struct rte_ring *) te->data, arg);
+   }
+
+   rte_mcfg_tailq_read_unlock();
+}
+
+static void
+ring_list_cb(struct rte_ring *r, void *arg)
+{
+   struct rte_tel_data *d = (struct rte_tel_data *)arg;
+
+   rte_tel_data_add_array_string(d, r->name);
+}
+
+static int
+ring_handle_list(const char *cmd __rte_unused,
+   const char *params __rte_unused, struct rte_tel_data *d)
+{
+   rte_tel_data_start_array(d, RTE_TEL_STRING_VAL);
+   ring_walk(ring_list_cb, d);
+   return 0;
+}
+
+RTE_INIT(ring_init_telemetry)
+{
+   rte_telemetry_register_cmd("/ring/list", ring_handle_list,
+   "Returns list of available ring. Takes no parameters");
+}
-- 
2.33.0

[PATCH v3 2/2] ring: add ring info telemetry cmd

[Jie Hai]

This patch supports dump of the info of ring by its name.
An example using this command is shown below:

--> /ring/info,MP_mb_pool_0
{
  "/ring/info": {
"name": "MP_mb_pool_0",
"socket": 0,
"flags": 0,
"producer_type": "MP",
"consumer_type": "MC",
"size": 262144,
"mask": 262143,
"capacity": 262143,
"used_count": 147173,
"consumer_tail": 8283,
"consumer_head": 8283,
"producer_tail": 155456,
"producer_head": 155456,
"mz_name": "RG_MP_mb_pool_0",
"mz_len": 2097920,
"mz_hugepage_sz": 1073741824,
"mz_socket_id": 0,
"mz_flags": 0
  }
}

Signed-off-by: Jie Hai 
---
 lib/ring/rte_ring.c | 83 +
 1 file changed, 83 insertions(+)

diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
index e6aac332d88f..2e57aa653339 100644
--- a/lib/ring/rte_ring.c
+++ b/lib/ring/rte_ring.c
@@ -454,8 +454,91 @@ ring_handle_list(const char *cmd __rte_unused,
return 0;
 }
 
+static const char *
+ring_prod_sync_type_to_name(struct rte_ring *r)
+{
+   switch (r->prod.sync_type) {
+   case RTE_RING_SYNC_MT:
+   return "MP";
+   case RTE_RING_SYNC_ST:
+   return "SP";
+   case RTE_RING_SYNC_MT_RTS:
+   return "MP_RTS";
+   case RTE_RING_SYNC_MT_HTS:
+   return "MP_HTS";
+   default:
+   return "Unknown";
+   }
+}
+
+static const char *
+ring_cons_sync_type_to_name(struct rte_ring *r)
+{
+   switch (r->cons.sync_type) {
+   case RTE_RING_SYNC_MT:
+   return "MC";
+   case RTE_RING_SYNC_ST:
+   return "SC";
+   case RTE_RING_SYNC_MT_RTS:
+   return "MC_RTS";
+   case RTE_RING_SYNC_MT_HTS:
+   return "MC_HTS";
+   default:
+   return "Unknown";
+   }
+}
+
+static int
+ring_handle_info(const char *cmd __rte_unused, const char *params,
+   struct rte_tel_data *d)
+{
+   const struct rte_memzone *mz;
+   struct rte_ring *r;
+
+   if (params == NULL || strlen(params) == 0 ||
+   strlen(params) >= RTE_RING_NAMESIZE)
+   return -EINVAL;
+
+   r = rte_ring_lookup(params);
+   if (r == NULL)
+   return -EINVAL;
+
+   rte_mcfg_tailq_read_lock();
+
+   rte_tel_data_start_dict(d);
+   rte_tel_data_add_dict_string(d, "name", r->name);
+   rte_tel_data_add_dict_int(d, "socket", r->memzone->socket_id);
+   rte_tel_data_add_dict_int(d, "flags", r->flags);
+   rte_tel_data_add_dict_string(d, "producer_type",
+   ring_prod_sync_type_to_name(r));
+   rte_tel_data_add_dict_string(d, "consumer_type",
+   ring_cons_sync_type_to_name(r));
+   rte_tel_data_add_dict_u64(d, "size", r->size);
+   rte_tel_data_add_dict_u64(d, "mask", r->mask);
+   rte_tel_data_add_dict_u64(d, "capacity", r->capacity);
+   rte_tel_data_add_dict_u64(d, "used_count", rte_ring_count(r));
+   rte_tel_data_add_dict_u64(d, "consumer_tail", r->cons.tail);
+   rte_tel_data_add_dict_u64(d, "consumer_head", r->cons.head);
+   rte_tel_data_add_dict_u64(d, "producer_tail", r->prod.tail);
+   rte_tel_data_add_dict_u64(d, "producer_head", r->prod.head);
+
+   mz = r->memzone;
+   if (mz == NULL)
+   return 0;
+   rte_tel_data_add_dict_string(d, "mz_name", mz->name);
+   rte_tel_data_add_dict_int(d, "mz_len", mz->len);
+   rte_tel_data_add_dict_int(d, "mz_hugepage_sz", mz->hugepage_sz);
+   rte_tel_data_add_dict_int(d, "mz_socket_id", mz->socket_id);
+   rte_tel_data_add_dict_int(d, "mz_flags", mz->flags);
+
+   rte_mcfg_tailq_read_unlock();
+   return 0;
+}
+
 RTE_INIT(ring_init_telemetry)
 {
rte_telemetry_register_cmd("/ring/list", ring_handle_list,
"Returns list of available ring. Takes no parameters");
+   rte_telemetry_register_cmd("/ring/info", ring_handle_info,
+   "Returns ring info. Parameters: ring_name.");
 }
-- 
2.33.0

[PATCH] test/mbuf: fix mbuf_autotest retest fail

[Jie Hai]

Retest "mbuf_autotest" will fail because the mbuf pool was
not freed after previous test successful done.
This patch fixes it.

Fixes: efc6f9104c80 ("mbuf: fix reset on mbuf free")
Cc: sta...@dpdk.org

Signed-off-by: Jie Hai 
---
 app/test/test_mbuf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 53fe898a384c..6cbb03b0afaa 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -2764,6 +2764,7 @@ test_nb_segs_and_next_reset(void)
m2->nb_segs != 1 || m2->next != NULL)
GOTO_FAIL("nb_segs or next was not reset properly");
 
+   rte_mempool_free(pool);
return 0;
 
 fail:
-- 
2.30.0

RE: [PATCH v4 3/3] ethdev: add standby flags for live migration

[Rongwei Liu]

HI Jerin:

BR
Rongwei

> -Original Message-
> From: Jerin Jacob 
> Sent: Tuesday, January 31, 2023 01:10
> To: Rongwei Liu 
> Cc: dev@dpdk.org; Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; NBU-Contact-
> Thomas Monjalon (EXTERNAL) ;
> step...@networkplumber.org; Raslan Darawsheh ;
> Ferruh Yigit ; Andrew Rybchenko
> 
> Subject: Re: [PATCH v4 3/3] ethdev: add standby flags for live migration
> 
> External email: Use caution opening links or attachments
> 
> 
> On Mon, Jan 30, 2023 at 8:17 AM Rongwei Liu  wrote:
> >
> > Hi Jerin
> >
> > BR
> > Rongwei
> >
> > > -Original Message-
> > > From: Jerin Jacob 
> > > Sent: Monday, January 23, 2023 21:20
> > > To: Rongwei Liu 
> > > Cc: dev@dpdk.org; Matan Azrad ; Slava Ovsiienko
> > > ; Ori Kam ; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) ;
> > > step...@networkplumber.org; Raslan Darawsheh ;
> > > Ferruh Yigit ; Andrew Rybchenko
> > > 
> > > Subject: Re: [PATCH v4 3/3] ethdev: add standby flags for live
> > > migration
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Jan 18, 2023 at 9:15 PM Rongwei Liu 
> wrote:
> > > >
> > > > Some flags are added to the process state API for live migration
> > > > in order to change the behavior of the flow rules in a standby process.
> > > >
> > > > Signed-off-by: Rongwei Liu 
> > > > ---
> > > >  lib/ethdev/rte_ethdev.h | 21 +
> > > >  1 file changed, 21 insertions(+)
> > > >
> > > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> > > > index
> > > > 1505396ced..9ae4f426a7 100644
> > > > --- a/lib/ethdev/rte_ethdev.h
> > > > +++ b/lib/ethdev/rte_ethdev.h
> > > > @@ -2260,6 +2260,27 @@ int rte_eth_dev_owner_get(const uint16_t
> > > > port_id,  __rte_experimental  int rte_eth_process_set_role(bool
> > > > standby, uint32_t flags);
> > > >
> > > > +/**@{@name Process role flags
> > > > + * used when migrating from an application to another one.
> > > > + * @see rte_eth_process_set_active  */
> > > > +/**
> > > > + * When set on a standby process, ingress flow rules will be
> > > > +effective
> > > > + * in active and standby processes, so the ingress traffic may be
> duplicated.
> > > > + */
> > > > +#define RTE_ETH_PROCESS_FLAG_STANDBY_DUP_FLOW_INGRESS
> > > RTE_BIT32(0)
> > >
> > >
> > > How to duplicate if action has statefull items for example,
> > > rte_flow_action_security::security_session -> it store the live
> > > pointer rte_flow_action_meter::mtr_id; -> MTR object ID created with
> > > rte_mtr_create()
> > I agree with you, not all actions can be supported in the active/standby
> model.
> 
> IMO, Where ever rules are not standalone (like QUEUE, RSS) etc, It will be
> architecturally is not possible to migrate with pointers.
> That's where I have concern generalizing this feature for this ethdev.
> 
Not sure I understand your concern correctly. What' the pointer concept here?
Queue RSS actions can be migrated per my local test. Active/Standby application 
have its fully own rxq/txq.
They are totally separated processes and like two members in pipeline. 2nd 
member can't be feed if 1st member alive and handle the traffic. 

> Also, I don't believe there is any real HW support needed for this.
> IMO, Having DPDK standard multiprocess can do this by keeping secondary
> application can migrate, keeping all the SW logic in the primary process by
> doing the housekeeping in the application. On plus side, it works with 
> pointers
> too.
IMO, in multiple process model, primary process usually owns the hardware 
resources via mmap/iomap/pci_map etc.
Secondary process is not able to run if primary quits no matter gracefully or 
crashing.
This patch wants to introduce a "backup to alive" model.
Assume user wants to upgrade from DPDK version 22.03 to 23.03, 22.03 is running 
and active role while 23.03 comes up in standby.
Both DPDK processes have its own resources and doesn't rely on each other. 
User can migrate the application following the steps in commit message with 
minimum traffic downtime. 
SW logic like flow rules can be done following iptables-save/iptables-restore 
approach.  
> 
> I am not sure how much housekeeping offload to _HW_ in your case. In my
> view, it should be generic utils functions to track the flow and installing 
> the
> rules using rte_flow APIs and keep the scope only for rte_flow.
For rules part, totally agree with you. Issue is there maybe millions of flow 
rules in field and each rule may take different steps to 
re-install per vendor' implementations.
This serial wants to propose a unified interface for upper layer application' 
easy use.  
> 
> That's just my view. I leave to ethdev maintainers for the rest of the review
> and decision on this series.
> 
> > That' why we have return value checking and rollback.
> > In Nvidia driver doc, we suggested user to start from 'rss/queue/jump'
> actions.
> > Meter is possible, at least per my view.
> > Assume: "meter g_action queue 0 / y_action drop / r_a

Re: [PATCH v10 1/2] cmdline: handle EOF in cmdline_poll

[Stephen Hemminger]

On Mon, 30 Jan 2023 22:12:42 +
Ferruh Yigit  wrote:

> On 1/30/2023 8:09 PM, Stephen Hemminger wrote:
> > If end of file is reached on input, then cmdline_read_char()
> > will return 0. The problem is that cmdline_poll() was not checking
> > for this and would continue and not return the status.
> > 
> > Fixes: 9251cd97a6be ("cmdline: add internal wrappers for character input")
> > Signed-off-by: Stephen Hemminger 
> > ---
> >  lib/cmdline/cmdline.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/cmdline/cmdline.c b/lib/cmdline/cmdline.c
> > index e1009ba4c413..de41406d61e0 100644
> > --- a/lib/cmdline/cmdline.c
> > +++ b/lib/cmdline/cmdline.c
> > @@ -194,7 +194,7 @@ cmdline_poll(struct cmdline *cl)
> > else if (status > 0) {
> > c = -1;
> > read_status = cmdline_read_char(cl, &c);
> > -   if (read_status < 0)
> > +   if (read_status <= 0)
> > return read_status;  
> 
> According API doc it will be wrong to return '0', which imply 'RDLINE_INIT'.

The API doc is a mess. It says function returns things enum that is only
defined in cmdline_private.h. Therefore no application could safely depend
on it.

End of File is not an error in most API's.

[PATCH] examples/l3fwd-power: support CPPC cpufreq

[Jie Hai]

Currently the l3fwd-power only supports ACPI cpufreq and Pstate
cpufreq, This patch adds CPPC cpufreq.

Signed-off-by: Jie Hai 
---
 examples/l3fwd-power/main.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index fd3ade330f82..5090d5598172 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -2453,9 +2453,10 @@ init_power_library(void)
/* we're not supporting the VM channel mode */
env = rte_power_get_env();
if (env != PM_ENV_ACPI_CPUFREQ &&
-   env != PM_ENV_PSTATE_CPUFREQ) {
+   env != PM_ENV_PSTATE_CPUFREQ &&
+   env != PM_ENV_CPPC_CPUFREQ) {
RTE_LOG(ERR, POWER,
-   "Only ACPI and PSTATE mode are supported\n");
+   "Only ACPI, PSTATE and CPPC mode are 
supported\n");
return -1;
}
}
@@ -2639,12 +2640,14 @@ autodetect_mode(void)
/*
 * Empty poll and telemetry modes have to be specifically requested to
 * be enabled, but we can auto-detect between interrupt mode with or
-* without frequency scaling. Both ACPI and pstate can be used.
+* without frequency scaling. Any of ACPI, pstate and CPPC can be used.
 */
if (rte_power_check_env_supported(PM_ENV_ACPI_CPUFREQ))
return APP_MODE_LEGACY;
if (rte_power_check_env_supported(PM_ENV_PSTATE_CPUFREQ))
return APP_MODE_LEGACY;
+   if (rte_power_check_env_supported(PM_ENV_CPPC_CPUFREQ))
+   return APP_MODE_LEGACY;
 
RTE_LOG(NOTICE, L3FWD_POWER, "Frequency scaling not supported, 
selecting interrupt-only mode\n");
 
-- 
2.30.0

Re: [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition

[Stephen Hemminger]

On Mon, 30 Jan 2023 05:59:33 +0200
Rongwei Liu  wrote:

> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
> + *
> + * Matches an IPv6 routing extension header.
> + */
> +struct rte_flow_item_ipv6_routing_ext {
> + struct rte_ipv6_routing_ext hdr;
> +};

The problem with nesting a variable length structure inside
another structure is not allowed.

The issue is that the applicaiton would have to pass a variable
length structure in for the flow definition. The flow item is
variable length for this type? all the others are fixed length.

One option would be to get rid of the wrapper structure.

RE: [PATCH v7] ethdev: add special flags when creating async transfer table

[Rongwei Liu]

HI Ivan

BR
Rongwei

> -Original Message-
> From: Ivan Malov 
> Sent: Tuesday, January 31, 2023 07:00
> To: Rongwei Liu 
> Cc: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; NBU-Contact-
> Thomas Monjalon (EXTERNAL) ; Aman Singh
> ; Yuying Zhang ;
> Ferruh Yigit ; Andrew Rybchenko
> ; dev@dpdk.org; Raslan Darawsheh
> 
> Subject: RE: [PATCH v7] ethdev: add special flags when creating async transfer
> table
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Rongwei,
> 
> Thanks for the professional attitude.
> Hope this discussion gets us on the
> same page. Please see below.
Thanks for the suggestion and comments. Hope everything goes well.
> 
> On Mon, 30 Jan 2023, Rongwei Liu wrote:
> 
> > HI Ivan
> >
> > BR
> > Rongwei
> >
> >> -Original Message-
> >> From: Ivan Malov 
> >> Sent: Monday, January 30, 2023 15:40
> >> To: Rongwei Liu 
> >> Cc: Matan Azrad ; Slava Ovsiienko
> >> ; Ori Kam ; NBU-Contact-
> >> Thomas Monjalon (EXTERNAL) ; Aman Singh
> >> ; Yuying Zhang ;
> >> Ferruh Yigit ; Andrew Rybchenko
> >> ; dev@dpdk.org; Raslan Darawsheh
> >> 
> >> Subject: RE: [PATCH v7] ethdev: add special flags when creating async
> >> transfer table
> >>
> >> External email: Use caution opening links or attachments
> >>
> >>
> >> Hi Rongwei,
> >>
> >> For my responses, PSB.
> >>
> >> By the way, now you mention things like wasting memory and insertion
> >> optimisastions, are there any comparative figures to see the effect
> >> of this hint on insertion performance / memory footprint?
> >> Some "before" / "after" examples would really be helpful.
> >>
> > Good to hear we reach agreement almost.
> 
> Very well.
> 
> The key point here is that one may agree that some optimisations are indeed
> needed, yes. I don't deny the fact that some vendors might have issues with
> how the API maps to the HW capabilities.
> Yes, some undesirable resource overhead shall be avoided, but the high level
> hints for that have to be designed with care.
> 
Totally agree. That' why we emphasize "optional for PMD" and "application 
should take care of hint"
> > First, the hint has nothing related to matching, only affects PMD resource
> management.
> 
> You say "PMD resource management". For the flow management, that's
> mostly vendor-specific, I take it. Let me explain. The application, for 
> instance,
> can control the number of Tx descriptors in the queue during setup stage.
> Tx descriptors are a common type of HW resource, hence the explicit control
> for it available to applications. For flow library, it's not like that. 
> Different
> vendors have different "underlayer"
> representations, they may vary drastically.
The resource I mentioned is about "steering logic" not SW datapath. 
With flow rules offloading, hardware should store the steering logic in its 
reachable memory no matter embedded in or mapping from host OS.
> 
> I take it, in the case of the HW you're working with, this hint indeed maps to
> something that is entirely resource-related and which does not belong in this
> specific vendor's match criteria. I 100% understand that, in your case, these
> are separate. But the point is that, on the high-level programming level
> (vendor-neutral), such a hint is in fact a match criterion. Because it tells 
> the
> driver to limit the scope of matching to just "from net"/"from vport", the 
> same
> way other metadata items do (represented_port).
> The only difference is that it refers to a group of unspecified ports which 
> have
> something in common.
>
" a group of unspecified ports" means dynamic and flexible, right. IMO it's 
valid and fits sync flow perfectly.
But in async, when allocating resources (table creation), the group info is 
still unknown. We don't want to scatter it into each rule insertion.
> So, although I don't strongly object having some hints like this one in the
> generic API, I nevertheless disagree with describing this as just "resource-
> specific" and not being a match criterion. It's just not always the case. It 
> might
> not be valid for *all* NIC vendors.
> 
Agree, not valid for *all* NIC vendors.
> > In my local test, it can save around 50% memory in the VxLAN encap/decap
> example case.
> 
> Forgive me in case this has been already discussed; where's that memory?
> I mean, is it some sort of general-purpose memory? Or some HW-specific
> table capacity overhead? I'm trying to understand how the feature will be
> useful to other vendors, or how common this problem is.
> 
See above. HW always needs memory to store offloaded rules no matter embedded 
in chip or borrowed from OS.
> > Insertion rate has very very few improvements.
> >> After all, I'm not objecting this patch. But I believe that other 
> >> reviewers'
> >> concerns should nevertheless be addressed anyway.
> > Let me try to show the hint is useful.
> >>
> >> On Mon, 30 Jan 2023, Rongwei Liu wrote:
> >>
> >>> Hi Ivan,
> >>>
> >>> BR
> >>> Rongwei
> >>>
>  -Original Message-
>  From: Iv

Re: [PATCH v2 1/2] ring: add ring list telemetry cmd

[Jie Hai]

On 2023/1/23 0:40, Konstantin Ananyev wrote:

Hi Jie,


This patch supports the list of rings with telemetry cmd.
An example using this command is shown below:

--> /ring/list
{
   "/ring/list": [
 "HT_:7d:00.2",
 "MP_mb_pool_0"
   ]
}

Signed-off-by: Jie Hai 
---
  lib/ring/meson.build |  1 +
  lib/ring/rte_ring.c  | 40 
  2 files changed, 41 insertions(+)

diff --git a/lib/ring/meson.build b/lib/ring/meson.build
index c20685c689ac..7fca958ed7fa 100644
--- a/lib/ring/meson.build
+++ b/lib/ring/meson.build
@@ -18,3 +18,4 @@ indirect_headers += files (
  'rte_ring_rts.h',
  'rte_ring_rts_elem_pvt.h',
  )
+deps += ['telemetry']
diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
index cddaf6b2876f..bb1dafd4d1ca 100644
--- a/lib/ring/rte_ring.c
+++ b/lib/ring/rte_ring.c
@@ -22,6 +22,7 @@
  #include 
  #include 
  #include 
+#include 
  #include "rte_ring.h"
  #include "rte_ring_elem.h"
@@ -419,3 +420,42 @@ rte_ring_lookup(const char *name)
  return r;
  }
+
+static void
+rte_ring_walk(void (*func)(struct rte_ring *, void *), void *arg)


As a nit: it is a static function, so I think we can skip 'rte_' prefix 
for it.

Apart from that:
Acked-by: Konstantin Ananyev 


Hi, Konstantin,

Thanks for your review. Accepted and fixed in v3.

Jie Hai

+{
+    struct rte_ring_list *ring_list;
+    struct rte_tailq_entry *te;
+
+    ring_list = RTE_TAILQ_CAST(rte_ring_tailq.head, rte_ring_list);
+    rte_mcfg_tailq_read_lock();
+
+    TAILQ_FOREACH(te, ring_list, next) {
+    (*func)((struct rte_ring *) te->data, arg);
+    }
+
+    rte_mcfg_tailq_read_unlock();
+}
+
+static void
+ring_list_cb(struct rte_ring *r, void *arg)
+{
+    struct rte_tel_data *d = (struct rte_tel_data *)arg;
+
+    rte_tel_data_add_array_string(d, r->name);
+}
+
+static int
+ring_handle_list(const char *cmd __rte_unused,
+    const char *params __rte_unused, struct rte_tel_data *d)
+{
+    rte_tel_data_start_array(d, RTE_TEL_STRING_VAL);
+    rte_ring_walk(ring_list_cb, d);
+    return 0;
+}
+
+RTE_INIT(ring_init_telemetry)
+{
+    rte_telemetry_register_cmd("/ring/list", ring_handle_list,
+    "Returns list of available ring. Takes no parameters");
+}


.

Re: [PATCH v2 2/2] ring: add ring info telemetry cmd

[Jie Hai]

Hi, Konstantin,

Thanks for your review. All accepted and fixed in v3.

Jie Hai

On 2023/1/23 1:49, Konstantin Ananyev wrote:



This patch supports dump of the info of ring by its name.
An example using this command is shown below:

--> /ring/info,MP_mb_pool_0
{
   "/ring/info": {
 "name": "MP_mb_pool_0",
 "socket": 0,
 "flags": 0,
 "producer_type": "MP",
 "consumer_type": "MC",
 "size": 262144,
 "mask": 262143,
 "capacity": 262143,
 "used_count": 147173,
 "consumer_tail": 8283,
 "consumer_head": 8283,
 "producer_tail": 155456,
 "producer_head": 155456,
 "mz_name": "RG_MP_mb_pool_0",
 "mz_len": 2097920,
 "mz_hugepage_sz": 1073741824,
 "mz_socket_id": 0,
 "mz_flags": 0
   }
}

Signed-off-by: Jie Hai 

RE: [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition

[Rongwei Liu]

HI Stephen

BR
Rongwei

> -Original Message-
> From: Stephen Hemminger 
> Sent: Tuesday, January 31, 2023 10:56
> To: Rongwei Liu 
> Cc: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; NBU-Contact-
> Thomas Monjalon (EXTERNAL) ; Aman Singh
> ; Yuying Zhang ;
> Ferruh Yigit ; Andrew Rybchenko
> ; Olivier Matz ;
> dev@dpdk.org; Raslan Darawsheh 
> Subject: Re: [PATCH v3 1/8] ethdev: add IPv6 routing extension header
> definition
> 
> External email: Use caution opening links or attachments
> 
> 
> On Tue, 31 Jan 2023 02:27:56 +
> Rongwei Liu  wrote:
> 
> > HI Stephen
> >
> > BR
> > Rongwei
> >
> > > -Original Message-
> > > From: Stephen Hemminger 
> > > Sent: Tuesday, January 31, 2023 00:48
> > > To: Rongwei Liu 
> > > Cc: Matan Azrad ; Slava Ovsiienko
> > > ; Ori Kam ; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) ; Aman Singh
> > > ; Yuying Zhang ;
> > > Ferruh Yigit ; Andrew Rybchenko
> > > ; Olivier Matz
> > > ; dev@dpdk.org; Raslan Darawsheh
> > > 
> > > Subject: Re: [PATCH v3 1/8] ethdev: add IPv6 routing extension
> > > header definition
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Mon, 30 Jan 2023 05:59:33 +0200
> > > Rongwei Liu  wrote:
> > >
> > > >
> > > > +/**
> > > > + * IPv6 Routing Extension Header
> > > > + */
> > > > +struct rte_ipv6_routing_ext {
> > > > + uint8_t next_hdr;   /**< Protocol, next 
> > > > header. */
> > > > + uint8_t hdr_len;/**< Header length. */
> > > > + uint8_t type;   /**< Extension header 
> > > > type. */
> > > > + uint8_t segments_left;  /**< Valid segments 
> > > > number. */
> > > > + __extension__
> > > > + union {
> > > > + rte_be32_t flags;
> > > > + struct {
> > > > + uint8_t last_entry; /**< The last_entry field 
> > > > of SRH */
> > > > + uint8_t flag;   /**< Packet flag. */
> > > > + rte_be16_t tag; /**< Packet tag. */
> > > > + };
> > > > + };
> > > > + __extension__
> > > > + rte_be32_t segments[0]; /**< Each hop IPv6 
> > > > address. */
> > >
> > > Use flex array rather than zero size.
> > > Zero size arrays cause warnings with later compilers.
> > Using flex array helps improve this network header definition but
> > caused warning in the rte_flow_item_** struct
> rte_flow_item_ipv6_routing_ext {
> >struct rte_ipv6_routing_ext hdr; }; "invalid use of structure
> > with flexible array member [-Werror=pedantic]"
> 
> Not sure, only Nvidia/Mellanox messes with pedantic
This is caused by failsafe driver.
In file included from ../drivers/net/failsafe/failsafe_ether.c:8:
../lib/ethdev/rte_flow.h:892:44: error: invalid use of structure with flexible 
array member [-Werror=pedantic]
  __extension__ struct rte_ipv6_routing_ext hdr;
^~~

RE: [PATCH v3] malloc: enhance NUMA affinity heuristic

[You, KaisenX]

> -Original Message-
> From: David Marchand 
> Sent: 2023年1月3日 21:32
> To: dev@dpdk.org
> Cc: Matz, Olivier ; ferruh.yi...@amd.com; You,
> KaisenX ; zhou...@loongson.cn; Burakov, Anatoly
> 
> Subject: [PATCH v3] malloc: enhance NUMA affinity heuristic
> 
> Trying to allocate memory on the first detected numa node has less chance
> to find some memory actually available rather than on the main lcore numa
> node (especially when the DPDK application is started only on one numa
> node).
> 
> Signed-off-by: David Marchand 
> ---
> Changes since v2:
> - add uncommitted local change and fix compilation,
> 
> Changes since v1:
> - accomodate for configurations with main lcore running on multiples
>   physical cores belonging to different numa,
> 
> ---
>  lib/eal/common/malloc_heap.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/eal/common/malloc_heap.c b/lib/eal/common/malloc_heap.c
> index d7c410b786..3ee19aee15 100644
> --- a/lib/eal/common/malloc_heap.c
> +++ b/lib/eal/common/malloc_heap.c
> @@ -717,6 +717,10 @@ malloc_get_numa_socket(void)
>   return socket_id;
>   }
> 
> + socket_id = rte_lcore_to_socket_id(rte_get_main_lcore());
> + if (socket_id != (unsigned int)SOCKET_ID_ANY)
> + return socket_id;
> +
>   return rte_socket_id_by_idx(0);
>  }
> 
Because the initial "socket_id" of the interrupt thread is not necessarily 
"SOCKET_ID_ANY"(-1), in malloc_get_numa_socket(void) function, It may 
be returned before the content modified by this patch, resulting in the 
subsequent search for memory being performed on the socket that initializes 
the unallocated memory. 

To avoid this, I will submit the V4 version to fix this problem.

> --
> 2.39.0

RE: [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition

[Rongwei Liu]

Hi Stephen

BR
Rongwei

> -Original Message-
> From: Stephen Hemminger 
> Sent: Tuesday, January 31, 2023 11:02
> To: Rongwei Liu 
> Cc: Matan Azrad ; Slava Ovsiienko
> ; Ori Kam ; NBU-Contact-
> Thomas Monjalon (EXTERNAL) ; Aman Singh
> ; Yuying Zhang ;
> Ferruh Yigit ; Andrew Rybchenko
> ; Olivier Matz ;
> dev@dpdk.org; Raslan Darawsheh 
> Subject: Re: [PATCH v3 1/8] ethdev: add IPv6 routing extension header
> definition
> 
> External email: Use caution opening links or attachments
> 
> 
> On Mon, 30 Jan 2023 05:59:33 +0200
> Rongwei Liu  wrote:
> 
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
> > + *
> > + * Matches an IPv6 routing extension header.
> > + */
> > +struct rte_flow_item_ipv6_routing_ext {
> > + struct rte_ipv6_routing_ext hdr; };
> 
> The problem with nesting a variable length structure inside another structure
> is not allowed.
> 
> The issue is that the applicaiton would have to pass a variable length 
> structure
> in for the flow definition. The flow item is variable length for this type? 
> all the
> others are fixed length.
> 
Yeah, segments_left is uint8 per definition. RFC doesn't set an upper 
limitation.
It stands for intermediate routing nodes between src and dst nodes.
> One option would be to get rid of the wrapper structure.
Yeah, it works. @Andrew Rybchenko  Can you share your preference here?

RE: [PATCH v2] net/i40e: support enabling/disabling source pruning

[Zhang, Ke1X]

> -Original Message-
> From: David Marchand 
> Sent: Monday, January 30, 2023 4:58 PM
> To: Zhang, Ke1X ; m...@smartsharesystems.com;
> tho...@monjalon.net; ferruh.yi...@amd.com
> Cc: dev@dpdk.org; Matz, Olivier ; Zhang, Yuying
> ; Xing, Beilei 
> Subject: Re: [PATCH v2] net/i40e: support enabling/disabling source pruning
> 
> On Mon, Jan 30, 2023 at 9:23 AM Ke Zhang  wrote:
> >
> > VRRP advertisement packets are dropped on i40e PF devices because
> when
> > a MAC address is added to a device, packets originating from that MAC
> > address are dropped.
> >
> > This patch adds a PMD specific API to enable/disable source pruning to
> > fix above issue.
> >
> > Bugzilla ID: 648
> >
> > Signed-off-by: Ke Zhang 
> > ---
> >  app/test-pmd/cmdline.c  | 84
> +
> >  drivers/net/i40e/i40e_ethdev.c  | 43 +
> > drivers/net/i40e/i40e_ethdev.h  |  1 +
> > drivers/net/i40e/rte_pmd_i40e.c | 20 
> > drivers/net/i40e/rte_pmd_i40e.h | 16 +++
> >  5 files changed, 164 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > cb8c174020..76a574affd 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -776,6 +776,9 @@ static void cmd_help_long_parsed(void
> > *parsed_result,
> >
> > "port cleanup (port_id) txq (queue_id) (free_cnt)\n"
> > "Cleanup txq mbufs for a specific Tx queue\n\n"
> > +
> > +   "port config (port_id|all) src_prune (on|off)\n"
> > +   "Set source prune on port_id, or all.\n\n"
> > );
> > }
> >
> 
> - This seems i40e specific, please move to drivers/net/i40e/i40e_testpmd.c.
> 
> - Besides, I would prefer that something in the command name clearly states
> this is driver (here, i40e) specific.
> Like "port config XX i40e_src_prune" or maybe the other way around, start
> with a "driver i40e" prefix.
> 
> Maybe others have an opinion.
> 
> 
> --
> David Marchand

Thanks for your comments, this command could be used for other Intel NIC like 
ice,
And It is only finished for i40e in this story: 
https://jira.devtools.intel.com/browse/DPDK-29564

[PATCH V5 0/5] app/testpmd: support multiple process attach and detach port

[Huisong Li]

This patchset fix some bugs and support attaching and detaching port
in primary and secondary.

---
 -v5: move 'ALLOCATED' state to the back of 'REMOVED' to avoid abi break.
 -v4: fix a misspelling. 
 -v3:
   #1 merge patch 1/6 and patch 2/6 into patch 1/5, and add modification
  for other bus type.
   #2 add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
  the probelm in patch 2/5. 
 -v2: resend due to CI unexplained failure.

Huisong Li (5):
  drivers/bus: restore driver assignment at front of probing
  ethdev: fix skip valid port in probing callback
  app/testpmd: check the validity of the port
  app/testpmd: add attach and detach port for multiple process
  app/testpmd: stop forwarding in new or destroy event

 app/test-pmd/testpmd.c   | 47 +++-
 app/test-pmd/testpmd.h   |  1 -
 drivers/bus/auxiliary/auxiliary_common.c |  9 -
 drivers/bus/dpaa/dpaa_bus.c  |  9 -
 drivers/bus/fslmc/fslmc_bus.c|  8 +++-
 drivers/bus/ifpga/ifpga_bus.c| 12 --
 drivers/bus/pci/pci_common.c |  9 -
 drivers/bus/vdev/vdev.c  | 10 -
 drivers/bus/vmbus/vmbus_common.c |  9 -
 drivers/net/bnxt/bnxt_ethdev.c   |  3 +-
 drivers/net/bonding/bonding_testpmd.c|  1 -
 drivers/net/mlx5/mlx5.c  |  2 +-
 lib/ethdev/ethdev_driver.c   | 13 +--
 lib/ethdev/ethdev_driver.h   | 12 ++
 lib/ethdev/ethdev_pci.h  |  2 +-
 lib/ethdev/rte_class_eth.c   |  2 +-
 lib/ethdev/rte_ethdev.c  |  4 +-
 lib/ethdev/rte_ethdev.h  |  4 +-
 lib/ethdev/version.map   |  1 +
 19 files changed, 114 insertions(+), 44 deletions(-)

-- 
2.22.0