[dpdk-dev] [PATCH] net/i40e: fix forward outer IPv6 VXLAN packets

[Jie Wang]

Testpmd forwards packets in checksum mode that it need to calculate
the checksum of each layer's protocol. Then it will fill flags and
header length into mbuf.

In process_outer_cksums, HW calculates the outer checksum if
tx_offloads contains outer UDP checksum otherwise SW calculates
the outer checksum.

When tx_offloads contains outer UDP checksum or outer IPv4 checksum,
mbuf will be filled with correct header length.

This patch added outer UDP checksum in tx_offload_capa and
I40E_TX_OFFLOAD_MASK, when we set csum hw outer-udp on that the
engine can forward outer IPv6 VXLAN packets.

Fixes: 399421100e08 ("net/i40e: fix missing mbuf fast free offload")
Cc: stat...@dpdk.org

Signed-off-by: Jie Wang 
---
 drivers/net/i40e/i40e_ethdev.c | 1 +
 drivers/net/i40e/i40e_rxtx.c   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 62e374d19e..faf6391350 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3746,6 +3746,7 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
RTE_ETH_TX_OFFLOAD_IPIP_TNL_TSO |
RTE_ETH_TX_OFFLOAD_GENEVE_TNL_TSO |
RTE_ETH_TX_OFFLOAD_MULTI_SEGS |
+   RTE_ETH_TX_OFFLOAD_OUTER_UDP_CKSUM |
dev_info->tx_queue_offload_capa;
dev_info->dev_capa =
RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP |
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 6ccb598677..41fe3bf481 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -65,6 +65,7 @@
RTE_MBUF_F_TX_QINQ |   \
RTE_MBUF_F_TX_VLAN |\
RTE_MBUF_F_TX_TUNNEL_MASK | \
+   RTE_MBUF_F_TX_OUTER_UDP_CKSUM | \
I40E_TX_IEEE1588_TMST)
 
 #define I40E_TX_OFFLOAD_NOTSUP_MASK \
-- 
2.25.1

[dpdk-dev] [PATCH v2] net/ice: fix order of flow filter parser list

[Yuying Zhang]

The order of flow filter parser list was not definite and
linked to the register order of parsers. It caused ACL filter
covered by switch filter in some cases.

This patch fixed order of parser list to guarantee the usage
of each filter. Below lists the order.
ACL filter > Switch filter > FDIR > Hash filter.

Fixes: e4a0a7599d97 ("net/ice: fix flow priority support in non-pipeline mode")
Cc: sta...@dpdk.org

Signed-off-by: Yuying Zhang 
---
v2:
* Fix the spelling mistake in commit log.
---
 drivers/net/ice/ice_generic_flow.c | 33 +-
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ice/ice_generic_flow.c 
b/drivers/net/ice/ice_generic_flow.c
index 02f854666a..8e3e2e04d6 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -1906,6 +1906,8 @@ ice_register_parser(struct ice_flow_parser *parser,
 {
struct ice_parser_list *list;
struct ice_flow_parser_node *parser_node;
+   struct ice_flow_parser_node *existing_node;
+   void *temp;
 
parser_node = rte_zmalloc("ice_parser", sizeof(*parser_node), 0);
if (parser_node == NULL) {
@@ -1921,16 +1923,37 @@ ice_register_parser(struct ice_flow_parser *parser,
if (ad->devargs.pipe_mode_support) {
TAILQ_INSERT_TAIL(list, parser_node, node);
} else {
-   if (parser->engine->type == ICE_FLOW_ENGINE_SWITCH ||
-   parser->engine->type == ICE_FLOW_ENGINE_HASH)
+   if (parser->engine->type == ICE_FLOW_ENGINE_SWITCH) {
+   RTE_TAILQ_FOREACH_SAFE(existing_node, list,
+  node, temp) {
+   if (existing_node->parser->engine->type ==
+   ICE_FLOW_ENGINE_ACL) {
+   TAILQ_INSERT_AFTER(list, existing_node,
+  parser_node, node);
+   goto DONE;
+   }
+   }
+   TAILQ_INSERT_HEAD(list, parser_node, node);
+   } else if (parser->engine->type == ICE_FLOW_ENGINE_FDIR) {
+   RTE_TAILQ_FOREACH_SAFE(existing_node, list,
+  node, temp) {
+   if (existing_node->parser->engine->type ==
+   ICE_FLOW_ENGINE_SWITCH) {
+   TAILQ_INSERT_AFTER(list, existing_node,
+  parser_node, node);
+   goto DONE;
+   }
+   }
TAILQ_INSERT_HEAD(list, parser_node, node);
-   else if (parser->engine->type == ICE_FLOW_ENGINE_FDIR)
+   } else if (parser->engine->type == ICE_FLOW_ENGINE_HASH) {
TAILQ_INSERT_TAIL(list, parser_node, node);
-   else if (parser->engine->type == ICE_FLOW_ENGINE_ACL)
+   } else if (parser->engine->type == ICE_FLOW_ENGINE_ACL) {
TAILQ_INSERT_HEAD(list, parser_node, node);
-   else
+   } else {
return -EINVAL;
+   }
}
+DONE:
return 0;
 }
 
-- 
2.25.1

[dpdk-dev] [PATCH] net/i40e: fix forward outer IPv6 VXLAN packets

[Jie Wang]

Testpmd forwards packets in checksum mode that it need to calculate
the checksum of each layer's protocol. Then it will fill flags and
header length into mbuf.

In process_outer_cksums, HW calculates the outer checksum if
tx_offloads contains outer UDP checksum otherwise SW calculates
the outer checksum.

When tx_offloads contains outer UDP checksum or outer IPv4 checksum,
mbuf will be filled with correct header length.

This patch added outer UDP checksum in tx_offload_capa and
I40E_TX_OFFLOAD_MASK, when we set csum hw outer-udp on that the
engine can forward outer IPv6 VXLAN packets.

Fixes: 399421100e08 ("net/i40e: fix missing mbuf fast free offload")
Cc: sta...@dpdk.org

Signed-off-by: Jie Wang 
---
 drivers/net/i40e/i40e_ethdev.c | 1 +
 drivers/net/i40e/i40e_rxtx.c   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 62e374d19e..faf6391350 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3746,6 +3746,7 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
RTE_ETH_TX_OFFLOAD_IPIP_TNL_TSO |
RTE_ETH_TX_OFFLOAD_GENEVE_TNL_TSO |
RTE_ETH_TX_OFFLOAD_MULTI_SEGS |
+   RTE_ETH_TX_OFFLOAD_OUTER_UDP_CKSUM |
dev_info->tx_queue_offload_capa;
dev_info->dev_capa =
RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP |
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 6ccb598677..41fe3bf481 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -65,6 +65,7 @@
RTE_MBUF_F_TX_QINQ |   \
RTE_MBUF_F_TX_VLAN |\
RTE_MBUF_F_TX_TUNNEL_MASK | \
+   RTE_MBUF_F_TX_OUTER_UDP_CKSUM | \
I40E_TX_IEEE1588_TMST)
 
 #define I40E_TX_OFFLOAD_NOTSUP_MASK \
-- 
2.25.1

Re: [dpdk-dev] [PATCH v3 03/10] vdpa/sfc: add support to get device and protocol features

[Xia, Chenbo]

> -Original Message-
> From: Vijay Srivastava 
> Sent: Friday, October 29, 2021 10:47 PM
> To: dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava 
> Subject: [PATCH v3 03/10] vdpa/sfc: add support to get device and protocol
> features
> 
> From: Vijay Kumar Srivastava 
> 
> Implement vDPA ops get_feature and get_protocol_features.
> This patch retrieves device supported features and enables
> protocol features.
> 
> Signed-off-by: Vijay Kumar Srivastava 
> Acked-by: Andrew Rybchenko 
> Reviewed-by: Maxime Coquelin 
> ---
>  doc/guides/vdpadevs/features/sfc.ini | 10 
>  drivers/common/sfc_efx/efsys.h   |  2 +-
>  drivers/common/sfc_efx/version.map   | 10 
>  drivers/vdpa/sfc/sfc_vdpa.c  | 20 
>  drivers/vdpa/sfc/sfc_vdpa.h  |  2 +
>  drivers/vdpa/sfc/sfc_vdpa_hw.c   | 13 ++
>  drivers/vdpa/sfc/sfc_vdpa_ops.c  | 91 ---
> -
>  drivers/vdpa/sfc/sfc_vdpa_ops.h  |  3 ++
>  8 files changed, 142 insertions(+), 9 deletions(-)
> 
> diff --git a/doc/guides/vdpadevs/features/sfc.ini
> b/doc/guides/vdpadevs/features/sfc.ini
> index 71b6158..700d061 100644
> --- a/doc/guides/vdpadevs/features/sfc.ini
> +++ b/doc/guides/vdpadevs/features/sfc.ini
> @@ -4,6 +4,16 @@
>  ; Refer to default.ini for the full list of available driver features.
>  ;
>  [Features]
> +csum = Y
> +guest csum   = Y
> +host tso4= Y
> +host tso6= Y
> +version 1= Y
> +mrg rxbuf= Y
> +any layout   = Y
> +in_order = Y
> +proto host notifier  = Y
> +IOMMU platform   = Y
>  Linux= Y
>  x86-64   = Y
>  Usage doc= Y
> diff --git a/drivers/common/sfc_efx/efsys.h b/drivers/common/sfc_efx/efsys.h
> index d133d61..37ec6b9 100644
> --- a/drivers/common/sfc_efx/efsys.h
> +++ b/drivers/common/sfc_efx/efsys.h
> @@ -187,7 +187,7 @@
> 
>  #define EFSYS_OPT_MAE 1
> 
> -#define EFSYS_OPT_VIRTIO 0
> +#define EFSYS_OPT_VIRTIO 1
> 
>  /* ID */
> 
> diff --git a/drivers/common/sfc_efx/version.map
> b/drivers/common/sfc_efx/version.map
> index 642a62e..ec86220 100644
> --- a/drivers/common/sfc_efx/version.map
> +++ b/drivers/common/sfc_efx/version.map
> @@ -247,6 +247,16 @@ INTERNAL {
>   efx_txq_nbufs;
>   efx_txq_size;
> 
> + efx_virtio_fini;
> + efx_virtio_get_doorbell_offset;
> + efx_virtio_get_features;
> + efx_virtio_init;
> + efx_virtio_qcreate;
> + efx_virtio_qdestroy;
> + efx_virtio_qstart;
> + efx_virtio_qstop;
> + efx_virtio_verify_features;
> +
>   sfc_efx_dev_class_get;
>   sfc_efx_family;
> 
> diff --git a/drivers/vdpa/sfc/sfc_vdpa.c b/drivers/vdpa/sfc/sfc_vdpa.c
> index b7eca56..ccbd243 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa.c
> +++ b/drivers/vdpa/sfc/sfc_vdpa.c
> @@ -43,6 +43,26 @@ struct sfc_vdpa_adapter *
>   return found ? sva : NULL;
>  }
> 
> +struct sfc_vdpa_ops_data *
> +sfc_vdpa_get_data_by_dev(struct rte_vdpa_device *vdpa_dev)
> +{
> + bool found = false;
> + struct sfc_vdpa_adapter *sva;
> +
> + pthread_mutex_lock(&sfc_vdpa_adapter_list_lock);
> +
> + TAILQ_FOREACH(sva, &sfc_vdpa_adapter_list, next) {
> + if (vdpa_dev == sva->ops_data->vdpa_dev) {
> + found = true;
> + break;
> + }
> + }
> +
> + pthread_mutex_unlock(&sfc_vdpa_adapter_list_lock);
> +
> + return found ? sva->ops_data : NULL;
> +}
> +
>  static int
>  sfc_vdpa_vfio_setup(struct sfc_vdpa_adapter *sva)
>  {
> diff --git a/drivers/vdpa/sfc/sfc_vdpa.h b/drivers/vdpa/sfc/sfc_vdpa.h
> index 046f25d..c10c3d3 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa.h
> +++ b/drivers/vdpa/sfc/sfc_vdpa.h
> @@ -60,6 +60,8 @@ struct sfc_vdpa_adapter {
> 
>  struct sfc_vdpa_adapter *
>  sfc_vdpa_get_adapter_by_dev(struct rte_pci_device *pdev);
> +struct sfc_vdpa_ops_data *
> +sfc_vdpa_get_data_by_dev(struct rte_vdpa_device *vdpa_dev);
> 
>  int
>  sfc_vdpa_hw_init(struct sfc_vdpa_adapter *sva);
> diff --git a/drivers/vdpa/sfc/sfc_vdpa_hw.c b/drivers/vdpa/sfc/sfc_vdpa_hw.c
> index 7c256ff..7a67bd8 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa_hw.c
> +++ b/drivers/vdpa/sfc/sfc_vdpa_hw.c
> @@ -278,10 +278,20 @@
>   if (rc != 0)
>   goto fail_estimate_rsrc_limits;
> 
> + sfc_vdpa_log_init(sva, "init virtio");
> + rc = efx_virtio_init(enp);
> + if (rc != 0) {
> + sfc_vdpa_err(sva, "virtio init failed: %s", rte_strerror(rc));
> + goto fail_virtio_init;
> + }
> +
>   sfc_vdpa_log_init(sva, "done");
> 
>   return 0;
> 
> +fail_virtio_init:
> + efx_nic_fini(enp);
> +
>  fail_estimate_rsrc_limits:
>  fail_nic_reset:
>   efx_nic_unprobe(enp);
> @@ -310,6 +320,9 @@
> 
>   sfc_vdpa_log_init(sva, "entry");
> 
> + sfc_vdpa_log_init(sva, "virtio fini");
> + efx_virtio_fini(enp);
> +
>   sf

Re: [dpdk-dev] [PATCH v3 05/10] vdpa/sfc: add support to get VFIO device fd

[Xia, Chenbo]

> -Original Message-
> From: Vijay Srivastava 
> Sent: Friday, October 29, 2021 10:47 PM
> To: dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava 
> Subject: [PATCH v3 05/10] vdpa/sfc: add support to get VFIO device fd
> 
> From: Vijay Kumar Srivastava 
> 
> Implement vDPA ops get_vfio_device_fd to get the VFIO device fd.
> 
> Signed-off-by: Vijay Kumar Srivastava 
> Acked-by: Andrew Rybchenko 
> Reviewed-by: Maxime Coquelin 
> ---
>  drivers/vdpa/sfc/sfc_vdpa_ops.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/vdpa/sfc/sfc_vdpa_ops.c b/drivers/vdpa/sfc/sfc_vdpa_ops.c
> index 6c702e1..5253adb 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa_ops.c
> +++ b/drivers/vdpa/sfc/sfc_vdpa_ops.c
> @@ -145,6 +145,29 @@
>   return -1;
>  }
> 
> +static int
> +sfc_vdpa_get_vfio_device_fd(int vid)
> +{
> + struct rte_vdpa_device *vdpa_dev;
> + struct sfc_vdpa_ops_data *ops_data;
> + int vfio_dev_fd;
> + void *dev;
> +
> + vdpa_dev = rte_vhost_get_vdpa_device(vid);
> +
> + ops_data = sfc_vdpa_get_data_by_dev(vdpa_dev);
> + if (ops_data == NULL)
> + return -1;
> +
> + dev = ops_data->dev_handle;
> + vfio_dev_fd = sfc_vdpa_adapter_by_dev_handle(dev)->vfio_dev_fd;
> +
> + sfc_vdpa_info(dev, "vDPA ops get_vfio_device_fd :: vfio fd : %d",
> +   vfio_dev_fd);
> +
> + return vfio_dev_fd;
> +}
> +
>  static struct rte_vdpa_dev_ops sfc_vdpa_ops = {
>   .get_queue_num = sfc_vdpa_get_queue_num,
>   .get_features = sfc_vdpa_get_features,
> @@ -153,6 +176,7 @@
>   .dev_close = sfc_vdpa_dev_close,
>   .set_vring_state = sfc_vdpa_set_vring_state,
>   .set_features = sfc_vdpa_set_features,
> + .get_vfio_device_fd = sfc_vdpa_get_vfio_device_fd,
>  };
> 
>  struct sfc_vdpa_ops_data *
> --
> 1.8.3.1

Reviewed-by: Chenbo Xia 

Re: [dpdk-dev] [PATCH v3 06/10] vdpa/sfc: add support for dev conf and dev close ops

[Xia, Chenbo]

Hi Vijay,

> -Original Message-
> From: Vijay Srivastava 
> Sent: Friday, October 29, 2021 10:47 PM
> To: dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava 
> Subject: [PATCH v3 06/10] vdpa/sfc: add support for dev conf and dev close ops
> 
> From: Vijay Kumar Srivastava 
> 
> Implement vDPA ops dev_conf and dev_close for DMA mapping,
> interrupt and virtqueue configurations.
> 
> Signed-off-by: Vijay Kumar Srivastava 
> Acked-by: Andrew Rybchenko 
> ---
> v2:
> * Removed redundant null check while calling free().
> * Added error handling for rte_vhost_get_vhost_vring().
> 
>  drivers/vdpa/sfc/sfc_vdpa.c |   6 +
>  drivers/vdpa/sfc/sfc_vdpa.h |  43 
>  drivers/vdpa/sfc/sfc_vdpa_hw.c  |  69 ++
>  drivers/vdpa/sfc/sfc_vdpa_ops.c | 530 ++-
> -
>  drivers/vdpa/sfc/sfc_vdpa_ops.h |  28 +++
>  5 files changed, 656 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/vdpa/sfc/sfc_vdpa.c b/drivers/vdpa/sfc/sfc_vdpa.c
> index ccbd243..b3c82e5 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa.c
> +++ b/drivers/vdpa/sfc/sfc_vdpa.c
> @@ -246,6 +246,8 @@ struct sfc_vdpa_ops_data *
> 
>   sfc_vdpa_log_init(sva, "entry");
> 
> + sfc_vdpa_adapter_lock_init(sva);
> +
>   sfc_vdpa_log_init(sva, "vfio init");
>   if (sfc_vdpa_vfio_setup(sva) < 0) {
>   sfc_vdpa_err(sva, "failed to setup device %s", pci_dev->name);
> @@ -280,6 +282,8 @@ struct sfc_vdpa_ops_data *
>   sfc_vdpa_vfio_teardown(sva);
> 
>  fail_vfio_setup:
> + sfc_vdpa_adapter_lock_fini(sva);
> +
>  fail_set_log_prefix:
>   rte_free(sva);
> 
> @@ -311,6 +315,8 @@ struct sfc_vdpa_ops_data *
> 
>   sfc_vdpa_vfio_teardown(sva);
> 
> + sfc_vdpa_adapter_lock_fini(sva);
> +
>   rte_free(sva);
> 
>   return 0;
> diff --git a/drivers/vdpa/sfc/sfc_vdpa.h b/drivers/vdpa/sfc/sfc_vdpa.h
> index c10c3d3..1bf96e7 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa.h
> +++ b/drivers/vdpa/sfc/sfc_vdpa.h
> @@ -80,10 +80,53 @@ struct sfc_vdpa_ops_data *
>  void
>  sfc_vdpa_dma_free(struct sfc_vdpa_adapter *sva, efsys_mem_t *esmp);
> 
> +int
> +sfc_vdpa_dma_map(struct sfc_vdpa_ops_data *vdpa_data, bool do_map);
> +
>  static inline struct sfc_vdpa_adapter *
>  sfc_vdpa_adapter_by_dev_handle(void *dev_handle)
>  {
>   return (struct sfc_vdpa_adapter *)dev_handle;
>  }
> 
> +/*
> + * Add wrapper functions to acquire/release lock to be able to remove or
> + * change the lock in one place.
> + */
> +static inline void
> +sfc_vdpa_adapter_lock_init(struct sfc_vdpa_adapter *sva)
> +{
> + rte_spinlock_init(&sva->lock);
> +}
> +
> +static inline int
> +sfc_vdpa_adapter_is_locked(struct sfc_vdpa_adapter *sva)
> +{
> + return rte_spinlock_is_locked(&sva->lock);
> +}
> +
> +static inline void
> +sfc_vdpa_adapter_lock(struct sfc_vdpa_adapter *sva)
> +{
> + rte_spinlock_lock(&sva->lock);
> +}
> +
> +static inline int
> +sfc_vdpa_adapter_trylock(struct sfc_vdpa_adapter *sva)
> +{
> + return rte_spinlock_trylock(&sva->lock);
> +}
> +
> +static inline void
> +sfc_vdpa_adapter_unlock(struct sfc_vdpa_adapter *sva)
> +{
> + rte_spinlock_unlock(&sva->lock);
> +}
> +
> +static inline void
> +sfc_vdpa_adapter_lock_fini(__rte_unused struct sfc_vdpa_adapter *sva)
> +{
> + /* Just for symmetry of the API */
> +}
> +
>  #endif  /* _SFC_VDPA_H */
> diff --git a/drivers/vdpa/sfc/sfc_vdpa_hw.c b/drivers/vdpa/sfc/sfc_vdpa_hw.c
> index 7a67bd8..b473708 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa_hw.c
> +++ b/drivers/vdpa/sfc/sfc_vdpa_hw.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "efx.h"
>  #include "sfc_vdpa.h"
> @@ -109,6 +110,74 @@
>   memset(esmp, 0, sizeof(*esmp));
>  }
> 
> +int
> +sfc_vdpa_dma_map(struct sfc_vdpa_ops_data *ops_data, bool do_map)
> +{
> + uint32_t i, j;
> + int rc;
> + struct rte_vhost_memory *vhost_mem = NULL;
> + struct rte_vhost_mem_region *mem_reg = NULL;
> + int vfio_container_fd;
> + void *dev;
> +
> + dev = ops_data->dev_handle;
> + vfio_container_fd =
> + sfc_vdpa_adapter_by_dev_handle(dev)->vfio_container_fd;
> +
> + rc = rte_vhost_get_mem_table(ops_data->vid, &vhost_mem);
> + if (rc < 0) {
> + sfc_vdpa_err(dev,
> +  "failed to get VM memory layout");
> + goto error;
> + }
> +
> + for (i = 0; i < vhost_mem->nregions; i++) {
> + mem_reg = &vhost_mem->regions[i];
> +
> + if (do_map) {
> + rc = rte_vfio_container_dma_map(vfio_container_fd,
> + mem_reg->host_user_addr,
> + mem_reg->guest_phys_addr,
> + mem_reg->size);
> + if (rc < 0) {
> + sfc_vdpa_err(dev,
> +  "DMA map failed : %s",
>

Re: [dpdk-dev] [PATCH v3 04/10] vdpa/sfc: get device supported max queue count

[Xia, Chenbo]

> -Original Message-
> From: Vijay Srivastava 
> Sent: Friday, October 29, 2021 10:47 PM
> To: dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava 
> Subject: [PATCH v3 04/10] vdpa/sfc: get device supported max queue count
> 
> From: Vijay Kumar Srivastava 
> 
> Implement vDPA ops get_queue_num to get the maximum number
> of queues supported by the device.
> 
> Signed-off-by: Vijay Kumar Srivastava 
> Acked-by: Andrew Rybchenko 
> Reviewed-by: Maxime Coquelin 
> ---
>  drivers/vdpa/sfc/sfc_vdpa_ops.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/vdpa/sfc/sfc_vdpa_ops.c b/drivers/vdpa/sfc/sfc_vdpa_ops.c
> index 5750944..6c702e1 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa_ops.c
> +++ b/drivers/vdpa/sfc/sfc_vdpa_ops.c
> @@ -31,10 +31,20 @@
>  static int
>  sfc_vdpa_get_queue_num(struct rte_vdpa_device *vdpa_dev, uint32_t *queue_num)
>  {
> - RTE_SET_USED(vdpa_dev);
> - RTE_SET_USED(queue_num);
> + struct sfc_vdpa_ops_data *ops_data;
> + void *dev;
> 
> - return -1;
> + ops_data = sfc_vdpa_get_data_by_dev(vdpa_dev);
> + if (ops_data == NULL)
> + return -1;
> +
> + dev = ops_data->dev_handle;
> + *queue_num = sfc_vdpa_adapter_by_dev_handle(dev)->max_queue_count;
> +
> + sfc_vdpa_info(dev, "vDPA ops get_queue_num :: supported queue num : %d",
> +   *queue_num);

%d -> %u

With this fixed:

Reviewed-by: Chenbo Xia 

> +
> + return 0;
>  }
> 
>  static int
> --
> 1.8.3.1

Re: [dpdk-dev] [PATCH v3 07/10] vdpa/sfc: add support to get queue notify area info

[Xia, Chenbo]

Hi Vijay,

> -Original Message-
> From: Vijay Srivastava 
> Sent: Friday, October 29, 2021 10:47 PM
> To: dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava 
> Subject: [PATCH v3 07/10] vdpa/sfc: add support to get queue notify area info
> 
> From: Vijay Kumar Srivastava 
> 
> Implement the vDPA ops get_notify_area to get the notify
> area info of the queue.
> 
> Signed-off-by: Vijay Kumar Srivastava 
> Acked-by: Andrew Rybchenko 
> ---
> v2:
> * Added error log in sfc_vdpa_get_notify_area.
> 
>  drivers/vdpa/sfc/sfc_vdpa_ops.c | 168 ++-
> -
>  drivers/vdpa/sfc/sfc_vdpa_ops.h |   2 +
>  2 files changed, 164 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/vdpa/sfc/sfc_vdpa_ops.c b/drivers/vdpa/sfc/sfc_vdpa_ops.c
> index de1c81a..774d73e 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa_ops.c
> +++ b/drivers/vdpa/sfc/sfc_vdpa_ops.c
> @@ -3,6 +3,8 @@
>   * Copyright(c) 2020-2021 Xilinx, Inc.
>   */
> 
> +#include 
> +#include 
>  #include 
> 
>  #include 
> @@ -537,6 +539,67 @@
>   return 0;
>  }
> 
> +static void *
> +sfc_vdpa_notify_ctrl(void *arg)
> +{
> + struct sfc_vdpa_ops_data *ops_data;
> + int vid;
> +
> + ops_data = arg;
> + if (ops_data == NULL)
> + return NULL;
> +
> + sfc_vdpa_adapter_lock(ops_data->dev_handle);
> +
> + vid = ops_data->vid;
> +
> + if (rte_vhost_host_notifier_ctrl(vid, RTE_VHOST_QUEUE_ALL, true) != 0)
> + sfc_vdpa_info(ops_data->dev_handle,
> +   "vDPA (%s): Notifier could not get configured",
> +   ops_data->vdpa_dev->device->name);
> +
> + sfc_vdpa_adapter_unlock(ops_data->dev_handle);
> +
> + return NULL;
> +}
> +
> +static int
> +sfc_vdpa_setup_notify_ctrl(int vid)
> +{
> + int ret;
> + struct rte_vdpa_device *vdpa_dev;
> + struct sfc_vdpa_ops_data *ops_data;
> +
> + vdpa_dev = rte_vhost_get_vdpa_device(vid);
> +
> + ops_data = sfc_vdpa_get_data_by_dev(vdpa_dev);
> + if (ops_data == NULL) {
> + sfc_vdpa_err(ops_data->dev_handle,
> +  "invalid vDPA device : %p, vid : %d",
> +  vdpa_dev, vid);
> + return -1;
> + }

Why not use struct sfc_vdpa_ops_data * as the input param rather
than vid, then use ops_data->vdpa_dev to get vdpa_dev?

As ops_data is checked as non-NULL before the func, it will make 
things easier.

Thanks,
Chenbo

> +
> + ops_data->is_notify_thread_started = false;
> +
> + /*
> +  * Use rte_vhost_host_notifier_ctrl in a thread to avoid
> +  * dead lock scenario when multiple VFs are used in single vdpa
> +  * application and multiple VFs are passed to a single VM.
> +  */
> + ret = pthread_create(&ops_data->notify_tid, NULL,
> +  sfc_vdpa_notify_ctrl, ops_data);
> + if (ret != 0) {
> + sfc_vdpa_err(ops_data->dev_handle,
> +  "failed to create notify_ctrl thread: %s",
> +  rte_strerror(ret));
> + return -1;
> + }
> + ops_data->is_notify_thread_started = true;
> +
> + return 0;
> +}
> +
>  static int
>  sfc_vdpa_dev_config(int vid)
>  {
> @@ -570,18 +633,19 @@
>   if (rc != 0)
>   goto fail_vdpa_start;
> 
> - sfc_vdpa_adapter_unlock(ops_data->dev_handle);
> + rc = sfc_vdpa_setup_notify_ctrl(vid);
> + if (rc != 0)
> + goto fail_vdpa_notify;
> 
> - sfc_vdpa_log_init(ops_data->dev_handle, "vhost notifier ctrl");
> - if (rte_vhost_host_notifier_ctrl(vid, RTE_VHOST_QUEUE_ALL, true) != 0)
> - sfc_vdpa_info(ops_data->dev_handle,
> -   "vDPA (%s): software relay for notify is used.",
> -   vdpa_dev->device->name);
> + sfc_vdpa_adapter_unlock(ops_data->dev_handle);
> 
>   sfc_vdpa_log_init(ops_data->dev_handle, "done");
> 
>   return 0;
> 
> +fail_vdpa_notify:
> + sfc_vdpa_stop(ops_data);
> +
>  fail_vdpa_start:
>   sfc_vdpa_close(ops_data);
> 
> @@ -594,6 +658,7 @@
>  static int
>  sfc_vdpa_dev_close(int vid)
>  {
> + int ret;
>   struct rte_vdpa_device *vdpa_dev;
>   struct sfc_vdpa_ops_data *ops_data;
> 
> @@ -608,6 +673,23 @@
>   }
> 
>   sfc_vdpa_adapter_lock(ops_data->dev_handle);
> + if (ops_data->is_notify_thread_started == true) {
> + void *status;
> + ret = pthread_cancel(ops_data->notify_tid);
> + if (ret != 0) {
> + sfc_vdpa_err(ops_data->dev_handle,
> +  "failed to cancel notify_ctrl thread: %s",
> +  rte_strerror(ret));
> + }
> +
> + ret = pthread_join(ops_data->notify_tid, &status);
> + if (ret != 0) {
> + sfc_vdpa_err(ops_data->dev_handle,
> +  "failed

Re: [dpdk-dev] [PATCH v3 02/10] vdpa/sfc: add support for device initialization

[Vijay Kumar Srivastava]

Hi Chenbo, 

>-Original Message-
>From: Xia, Chenbo 
>Sent: Monday, November 1, 2021 5:19 PM
>To: Vijay Kumar Srivastava ; dev@dpdk.org
>Cc: maxime.coque...@redhat.com; andrew.rybche...@oktetlabs.ru; Vijay
>Kumar Srivastava 
>Subject: RE: [PATCH v3 02/10] vdpa/sfc: add support for device initialization
>
>Hi Vijay,
>
>> -Original Message-
>> From: Vijay Srivastava 
>> Sent: Friday, October 29, 2021 10:47 PM
>> To: dev@dpdk.org
>> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
>> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava
>> 
>> Subject: [PATCH v3 02/10] vdpa/sfc: add support for device
>> initialization
>>
>> From: Vijay Kumar Srivastava 
>>
>> Add HW initialization and vDPA device registration support.
>>
>> Signed-off-by: Vijay Kumar Srivastava 
>> Acked-by: Andrew Rybchenko 
>> ---
[SNIP]
>> +sfc_vdpa_hw_init(struct sfc_vdpa_adapter *sva) {
>> +efx_bar_region_t mem_ebr;
>> +efx_nic_t *enp;
>> +int rc;
>> +
>> +sfc_vdpa_log_init(sva, "entry");
>> +
>> +sfc_vdpa_log_init(sva, "get family");
>> +rc = sfc_efx_family(sva->pdev, &mem_ebr, &sva->family);
>> +if (rc != 0)
>> +goto fail_family;
>> +sfc_vdpa_log_init(sva,
>> +  "family is %u, membar is %u,"
>> +  "function control window offset is %#" PRIx64,
>> +  sva->family, mem_ebr.ebr_index,
>mem_ebr.ebr_offset);
>
>If ebr_idx is int, then %u -> %d. But if it's a bar index, its type should be
>unsigned int and you should change the definition in sfc common code.
Yes. It’s BAR index. 
Thanks for the catch. I agree that usage of 'unsigned int' looks better
for BAR index, however it should result in more changes in similar
places. Is it OK if we use %d here right now to be consistent with
current type and address the review note in a follow up patches
for common/sfc_efx, net/sfc and vdpa/sfc?

Re: [dpdk-dev] [PATCH v3 02/10] vdpa/sfc: add support for device initialization

[Xia, Chenbo]

> -Original Message-
> From: Vijay Kumar Srivastava 
> Sent: Tuesday, November 2, 2021 3:43 PM
> To: Xia, Chenbo ; dev@dpdk.org
> Cc: maxime.coque...@redhat.com; andrew.rybche...@oktetlabs.ru; Praveen Kumar
> Jain ; Harpreet Singh Anand 
> Subject: RE: [PATCH v3 02/10] vdpa/sfc: add support for device initialization
> 
> Hi Chenbo,
> 
> >-Original Message-
> >From: Xia, Chenbo 
> >Sent: Monday, November 1, 2021 5:19 PM
> >To: Vijay Kumar Srivastava ; dev@dpdk.org
> >Cc: maxime.coque...@redhat.com; andrew.rybche...@oktetlabs.ru; Vijay
> >Kumar Srivastava 
> >Subject: RE: [PATCH v3 02/10] vdpa/sfc: add support for device initialization
> >
> >Hi Vijay,
> >
> >> -Original Message-
> >> From: Vijay Srivastava 
> >> Sent: Friday, October 29, 2021 10:47 PM
> >> To: dev@dpdk.org
> >> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
> >> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava
> >> 
> >> Subject: [PATCH v3 02/10] vdpa/sfc: add support for device
> >> initialization
> >>
> >> From: Vijay Kumar Srivastava 
> >>
> >> Add HW initialization and vDPA device registration support.
> >>
> >> Signed-off-by: Vijay Kumar Srivastava 
> >> Acked-by: Andrew Rybchenko 
> >> ---
> [SNIP]
> >> +sfc_vdpa_hw_init(struct sfc_vdpa_adapter *sva) {
> >> +  efx_bar_region_t mem_ebr;
> >> +  efx_nic_t *enp;
> >> +  int rc;
> >> +
> >> +  sfc_vdpa_log_init(sva, "entry");
> >> +
> >> +  sfc_vdpa_log_init(sva, "get family");
> >> +  rc = sfc_efx_family(sva->pdev, &mem_ebr, &sva->family);
> >> +  if (rc != 0)
> >> +  goto fail_family;
> >> +  sfc_vdpa_log_init(sva,
> >> +"family is %u, membar is %u,"
> >> +"function control window offset is %#" PRIx64,
> >> +sva->family, mem_ebr.ebr_index,
> >mem_ebr.ebr_offset);
> >
> >If ebr_idx is int, then %u -> %d. But if it's a bar index, its type should be
> >unsigned int and you should change the definition in sfc common code.
> Yes. It’s BAR index.
> Thanks for the catch. I agree that usage of 'unsigned int' looks better
> for BAR index, however it should result in more changes in similar
> places. Is it OK if we use %d here right now to be consistent with
> current type and address the review note in a follow up patches
> for common/sfc_efx, net/sfc and vdpa/sfc?

Sure. Ok for me.

/Chenbo

[dpdk-dev] [PATCH] eal: fix device hotplug

[David Marchand]

The device event interrupt handler was always freed.

Bugzilla ID: 845
Fixes: c2bd9367e18f ("lib: remove direct access to interrupt handle")

Signed-off-by: David Marchand 
---
 lib/eal/linux/eal_dev.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lib/eal/linux/eal_dev.c b/lib/eal/linux/eal_dev.c
index 06820a3666..925cdba553 100644
--- a/lib/eal/linux/eal_dev.c
+++ b/lib/eal/linux/eal_dev.c
@@ -317,10 +317,12 @@ rte_dev_event_monitor_start(void)
goto exit;
}
 
-   if (rte_intr_type_set(intr_handle, RTE_INTR_HANDLE_DEV_EVENT))
+   ret = rte_intr_type_set(intr_handle, RTE_INTR_HANDLE_DEV_EVENT);
+   if (ret)
goto exit;
 
-   if (rte_intr_fd_set(intr_handle, -1))
+   ret = rte_intr_fd_set(intr_handle, -1);
+   if (ret)
goto exit;
 
ret = dev_uev_socket_fd_create();
@@ -339,7 +341,10 @@ rte_dev_event_monitor_start(void)
monitor_refcount++;
 
 exit:
-   rte_intr_instance_free(intr_handle);
+   if (ret) {
+   rte_intr_instance_free(intr_handle);
+   intr_handle = NULL;
+   }
rte_rwlock_write_unlock(&monitor_lock);
return ret;
 }
@@ -370,6 +375,7 @@ rte_dev_event_monitor_stop(void)
 
close(rte_intr_fd_get(intr_handle));
rte_intr_instance_free(intr_handle);
+   intr_handle = NULL;
 
monitor_refcount--;
 
-- 
2.23.0

[dpdk-dev] [PATCH 1/2] net/txgbe: fix RxTx packet statistics

[Jiawen Wu]

Fix specific length packet statistics caused by wrong register addresses.

Fixes: 24a4c76aff4d ("net/txgbe: add error types and registers")
Cc: sta...@dpdk.org

Signed-off-by: Jiawen Wu 
---
 drivers/net/txgbe/base/txgbe_regs.h | 48 ++---
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/net/txgbe/base/txgbe_regs.h 
b/drivers/net/txgbe/base/txgbe_regs.h
index 48d9300a2e..144047ba62 100644
--- a/drivers/net/txgbe/base/txgbe_regs.h
+++ b/drivers/net/txgbe/base/txgbe_regs.h
@@ -1072,30 +1072,30 @@ enum txgbe_5tuple_protocol {
 #define TXGBE_MACRXERRCRCH   0x01192C
 #define TXGBE_MACRXERRLENL   0x011978
 #define TXGBE_MACRXERRLENH   0x01197C
-#define TXGBE_MACRX1TO64L0x001940
-#define TXGBE_MACRX1TO64H0x001944
-#define TXGBE_MACRX65TO127L  0x001948
-#define TXGBE_MACRX65TO127H  0x00194C
-#define TXGBE_MACRX128TO255L 0x001950
-#define TXGBE_MACRX128TO255H 0x001954
-#define TXGBE_MACRX256TO511L 0x001958
-#define TXGBE_MACRX256TO511H 0x00195C
-#define TXGBE_MACRX512TO1023L0x001960
-#define TXGBE_MACRX512TO1023H0x001964
-#define TXGBE_MACRX1024TOMAXL0x001968
-#define TXGBE_MACRX1024TOMAXH0x00196C
-#define TXGBE_MACTX1TO64L0x001834
-#define TXGBE_MACTX1TO64H0x001838
-#define TXGBE_MACTX65TO127L  0x00183C
-#define TXGBE_MACTX65TO127H  0x001840
-#define TXGBE_MACTX128TO255L 0x001844
-#define TXGBE_MACTX128TO255H 0x001848
-#define TXGBE_MACTX256TO511L 0x00184C
-#define TXGBE_MACTX256TO511H 0x001850
-#define TXGBE_MACTX512TO1023L0x001854
-#define TXGBE_MACTX512TO1023H0x001858
-#define TXGBE_MACTX1024TOMAXL0x00185C
-#define TXGBE_MACTX1024TOMAXH0x001860
+#define TXGBE_MACRX1TO64L0x011940
+#define TXGBE_MACRX1TO64H0x011944
+#define TXGBE_MACRX65TO127L  0x011948
+#define TXGBE_MACRX65TO127H  0x01194C
+#define TXGBE_MACRX128TO255L 0x011950
+#define TXGBE_MACRX128TO255H 0x011954
+#define TXGBE_MACRX256TO511L 0x011958
+#define TXGBE_MACRX256TO511H 0x01195C
+#define TXGBE_MACRX512TO1023L0x011960
+#define TXGBE_MACRX512TO1023H0x011964
+#define TXGBE_MACRX1024TOMAXL0x011968
+#define TXGBE_MACRX1024TOMAXH0x01196C
+#define TXGBE_MACTX1TO64L0x011834
+#define TXGBE_MACTX1TO64H0x011838
+#define TXGBE_MACTX65TO127L  0x01183C
+#define TXGBE_MACTX65TO127H  0x011840
+#define TXGBE_MACTX128TO255L 0x011844
+#define TXGBE_MACTX128TO255H 0x011848
+#define TXGBE_MACTX256TO511L 0x01184C
+#define TXGBE_MACTX256TO511H 0x011850
+#define TXGBE_MACTX512TO1023L0x011854
+#define TXGBE_MACTX512TO1023H0x011858
+#define TXGBE_MACTX1024TOMAXL0x01185C
+#define TXGBE_MACTX1024TOMAXH0x011860
 
 #define TXGBE_MACRXUNDERSIZE 0x011938
 #define TXGBE_MACRXOVERSIZE  0x01193C
-- 
2.21.0.windows.1

[dpdk-dev] [PATCH 2/2] net/txgbe: fix link process in KR mode

[Jiawen Wu]

Set the 'present' parameter to 0 by default. It is configured by hardware,
users can set it to 1 for manual configuration.

Fixes: f611dada1af8 ("net/txgbe: update link setup process of backplane NICs")
Cc: sta...@dpdk.org

Signed-off-by: Jiawen Wu 
---
 drivers/net/txgbe/base/txgbe_phy.c | 2 +-
 drivers/net/txgbe/txgbe_ethdev.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/txgbe/base/txgbe_phy.c 
b/drivers/net/txgbe/base/txgbe_phy.c
index 2db87ae0c5..3f5229ecc2 100644
--- a/drivers/net/txgbe/base/txgbe_phy.c
+++ b/drivers/net/txgbe/base/txgbe_phy.c
@@ -1456,7 +1456,7 @@ txgbe_set_link_to_kr(struct txgbe_hw *hw, bool autoneg)
wr32_epcs(hw, SR_AN_CTRL, 0);
wr32_epcs(hw, VR_AN_KR_MODE_CL, 0);
}
-   if (hw->devarg.present  == 1) {
+   if (hw->devarg.present == 1) {
value = rd32_epcs(hw, TXGBE_PHY_TX_EQ_CTL1);
value |= TXGBE_PHY_TX_EQ_CTL1_DEF;
wr32_epcs(hw, TXGBE_PHY_TX_EQ_CTL1, value);
diff --git a/drivers/net/txgbe/txgbe_ethdev.c b/drivers/net/txgbe/txgbe_ethdev.c
index 169272ded5..8628ce455f 100644
--- a/drivers/net/txgbe/txgbe_ethdev.c
+++ b/drivers/net/txgbe/txgbe_ethdev.c
@@ -495,7 +495,7 @@ txgbe_parse_devargs(struct txgbe_hw *hw, struct rte_devargs 
*devargs)
struct rte_kvargs *kvlist;
u16 auto_neg = 1;
u16 poll = 0;
-   u16 present = 1;
+   u16 present = 0;
u16 sgmii = 0;
u16 ffe_set = 0;
u16 ffe_main = 27;
-- 
2.21.0.windows.1

Re: [dpdk-dev] [PATCH v3 08/10] vdpa/sfc: add support for MAC filter config

[Xia, Chenbo]

Hi Vijay,

> -Original Message-
> From: Vijay Srivastava 
> Sent: Friday, October 29, 2021 10:47 PM
> To: dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava 
> Subject: [PATCH v3 08/10] vdpa/sfc: add support for MAC filter config
> 
> From: Vijay Kumar Srivastava 
> 
> Add support for unicast and broadcast MAC filter configuration.
> 
> Signed-off-by: Vijay Kumar Srivastava 
> Acked-by: Andrew Rybchenko 
> ---
>  doc/guides/vdpadevs/sfc.rst|   4 ++
>  drivers/vdpa/sfc/meson.build   |   1 +
>  drivers/vdpa/sfc/sfc_vdpa.c|  32 +
>  drivers/vdpa/sfc/sfc_vdpa.h|  30 
>  drivers/vdpa/sfc/sfc_vdpa_filter.c | 144
> +
>  drivers/vdpa/sfc/sfc_vdpa_hw.c |  10 +++
>  drivers/vdpa/sfc/sfc_vdpa_ops.c|  17 +
>  7 files changed, 238 insertions(+)
>  create mode 100644 drivers/vdpa/sfc/sfc_vdpa_filter.c
> 
> diff --git a/doc/guides/vdpadevs/sfc.rst b/doc/guides/vdpadevs/sfc.rst
> index d06c427..512f23e 100644
> --- a/doc/guides/vdpadevs/sfc.rst
> +++ b/doc/guides/vdpadevs/sfc.rst
> @@ -71,6 +71,10 @@ boolean parameters value.
>**vdpa** device will work as vdpa device and will be probed by vdpa/sfc
> driver.
>If this parameter is not specified then ef100 device will operate as
> network device.
> 
> +- ``mac`` [mac address]
> +
> +  Configures MAC address which would be used to setup MAC filters.
> +
> 
>  Dynamic Logging Parameters
>  ~~
> diff --git a/drivers/vdpa/sfc/meson.build b/drivers/vdpa/sfc/meson.build
> index dc333de..2ca33bc 100644
> --- a/drivers/vdpa/sfc/meson.build
> +++ b/drivers/vdpa/sfc/meson.build
> @@ -22,4 +22,5 @@ sources = files(
>   'sfc_vdpa_hw.c',
>   'sfc_vdpa_mcdi.c',
>   'sfc_vdpa_ops.c',
> + 'sfc_vdpa_filter.c',
>  )
> diff --git a/drivers/vdpa/sfc/sfc_vdpa.c b/drivers/vdpa/sfc/sfc_vdpa.c
> index b3c82e5..d18cd61 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa.c
> +++ b/drivers/vdpa/sfc/sfc_vdpa.c
> @@ -8,7 +8,9 @@
>  #include 
> 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -202,6 +204,31 @@ struct sfc_vdpa_ops_data *
>   return ret < 0 ? RTE_LOGTYPE_PMD : ret;
>  }
> 
> +static int
> +sfc_vdpa_kvargs_parse(struct sfc_vdpa_adapter *sva)
> +{
> + struct rte_pci_device *pci_dev = sva->pdev;
> + struct rte_devargs *devargs = pci_dev->device.devargs;
> + /*
> +  * To get the device class a mandatory param 'class' is being
> +  * used so included SFC_EFX_KVARG_DEV_CLASS in the param list.
> +  */
> + const char **params = (const char *[]){
> + RTE_DEVARGS_KEY_CLASS,
> + SFC_VDPA_MAC_ADDR,
> + NULL,
> + };
> +
> + if (devargs == NULL)
> + return 0;
> +
> + sva->kvargs = rte_kvargs_parse(devargs->args, params);
> + if (sva->kvargs == NULL)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
>  static struct rte_pci_id pci_id_sfc_vdpa_efx_map[] = {
>   { RTE_PCI_DEVICE(EFX_PCI_VENID_XILINX, EFX_PCI_DEVID_RIVERHEAD_VF) },
>   { .vendor_id = 0, /* sentinel */ },
> @@ -244,6 +271,10 @@ struct sfc_vdpa_ops_data *
>   if (ret != 0)
>   goto fail_set_log_prefix;
> 
> + ret = sfc_vdpa_kvargs_parse(sva);
> + if (ret != 0)
> + goto fail_kvargs_parse;
> +
>   sfc_vdpa_log_init(sva, "entry");
> 
>   sfc_vdpa_adapter_lock_init(sva);
> @@ -284,6 +315,7 @@ struct sfc_vdpa_ops_data *
>  fail_vfio_setup:
>   sfc_vdpa_adapter_lock_fini(sva);
> 
> +fail_kvargs_parse:
>  fail_set_log_prefix:
>   rte_free(sva);
> 
> diff --git a/drivers/vdpa/sfc/sfc_vdpa.h b/drivers/vdpa/sfc/sfc_vdpa.h
> index 1bf96e7..dbd099f 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa.h
> +++ b/drivers/vdpa/sfc/sfc_vdpa.h
> @@ -17,8 +17,29 @@
>  #include "sfc_vdpa_log.h"
>  #include "sfc_vdpa_ops.h"
> 
> +#define SFC_VDPA_MAC_ADDR"mac"
>  #define SFC_VDPA_DEFAULT_MCDI_IOVA   0x2000
> 
> +/* Broadcast & Unicast MAC filters are supported */
> +#define SFC_MAX_SUPPORTED_FILTERS2
> +
> +/*
> + * Get function-local index of the associated VI from the
> + * virtqueue number. Queue 0 is reserved for MCDI
> + */
> +#define SFC_VDPA_GET_VI_INDEX(vq_num) (((vq_num) / 2) + 1)
> +
> +enum sfc_vdpa_filter_type {
> + SFC_VDPA_BCAST_MAC_FILTER = 0,
> + SFC_VDPA_UCAST_MAC_FILTER = 1,
> + SFC_VDPA_FILTER_NTYPE
> +};
> +
> +typedef struct sfc_vdpa_filter_s {
> + int filter_cnt;
> + efx_filter_spec_t   spec[SFC_MAX_SUPPORTED_FILTERS];
> +} sfc_vdpa_filter_t;
> +
>  /* Adapter private data */
>  struct sfc_vdpa_adapter {
>   TAILQ_ENTRY(sfc_vdpa_adapter)   next;
> @@ -32,6 +53,8 @@ struct sfc_vdpa_adapter {
>   struct rte_pci_device   *pdev;
>   struct rte_pci_addr pci_addr;
> 
> + struct rte_kvargs   *k

Re: [dpdk-dev] [PATCH v3 09/10] vdpa/sfc: add support to set vring state

[Xia, Chenbo]

> -Original Message-
> From: Vijay Srivastava 
> Sent: Friday, October 29, 2021 10:47 PM
> To: dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava 
> Subject: [PATCH v3 09/10] vdpa/sfc: add support to set vring state
> 
> From: Vijay Kumar Srivastava 
> 
> Implements vDPA ops set_vring_state to configure vring state.
> 
> Signed-off-by: Vijay Kumar Srivastava 
> Acked-by: Andrew Rybchenko 
> Reviewed-by: Maxime Coquelin 
> ---
>  drivers/vdpa/sfc/sfc_vdpa_ops.c | 54 ++--
> -
>  1 file changed, 50 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/vdpa/sfc/sfc_vdpa_ops.c b/drivers/vdpa/sfc/sfc_vdpa_ops.c
> index 8551b65..3430643 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa_ops.c
> +++ b/drivers/vdpa/sfc/sfc_vdpa_ops.c
> @@ -719,11 +719,57 @@
>  static int
>  sfc_vdpa_set_vring_state(int vid, int vring, int state)
>  {
> - RTE_SET_USED(vid);
> - RTE_SET_USED(vring);
> - RTE_SET_USED(state);
> + struct sfc_vdpa_ops_data *ops_data;
> + struct rte_vdpa_device *vdpa_dev;
> + efx_rc_t rc;
> + int vring_max;
> + void *dev;
> 
> - return -1;
> + vdpa_dev = rte_vhost_get_vdpa_device(vid);
> +
> + ops_data = sfc_vdpa_get_data_by_dev(vdpa_dev);
> + if (ops_data == NULL)
> + return -1;
> +
> + dev = ops_data->dev_handle;
> +
> + sfc_vdpa_info(dev,
> +   "vDPA ops set_vring_state: vid: %d, vring: %d, state:%d",
> +   vid, vring, state);
> +
> + vring_max = (sfc_vdpa_adapter_by_dev_handle(dev)->max_queue_count * 2);
> +
> + if (vring < 0 || vring > vring_max) {
> + sfc_vdpa_err(dev, "received invalid vring id : %d to set state",
> +  vring);
> + return -1;
> + }
> +
> + /*
> +  * Skip if device is not yet started. virtqueues state can be
> +  * changed once it is created and other configurations are done.
> +  */
> + if (ops_data->state != SFC_VDPA_STATE_STARTED)
> + return 0;
> +
> + if (ops_data->vq_cxt[vring].enable == state)
> + return 0;
> +
> + if (state == 0) {
> + rc = sfc_vdpa_virtq_stop(ops_data, vring);
> + if (rc != 0) {
> + sfc_vdpa_err(dev, "virtqueue stop failed: %s",
> +  rte_strerror(rc));
> + }
> + } else {
> + rc = sfc_vdpa_virtq_start(ops_data, vring);
> + if (rc != 0) {
> + sfc_vdpa_err(dev, "virtqueue start failed: %s",
> +  rte_strerror(rc));
> + }
> + }
> +
> + return rc;
>  }
> 
>  static int
> --
> 1.8.3.1

Reviewed-by: Chenbo Xia 

Re: [dpdk-dev] [PATCH v3 10/10] vdpa/sfc: set a multicast filter during vDPA init

[Xia, Chenbo]

> -Original Message-
> From: Vijay Srivastava 
> Sent: Friday, October 29, 2021 10:47 PM
> To: dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava 
> Subject: [PATCH v3 10/10] vdpa/sfc: set a multicast filter during vDPA init
> 
> From: Vijay Kumar Srivastava 
> 
> Insert unknown multicast filter to allow IPv6 neighbor discovery
> 
> Signed-off-by: Vijay Kumar Srivastava 
> Acked-by: Andrew Rybchenko 
> ---
>  drivers/vdpa/sfc/sfc_vdpa.h|  3 ++-
>  drivers/vdpa/sfc/sfc_vdpa_filter.c | 19 +--
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/vdpa/sfc/sfc_vdpa.h b/drivers/vdpa/sfc/sfc_vdpa.h
> index dbd099f..bedc76c 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa.h
> +++ b/drivers/vdpa/sfc/sfc_vdpa.h
> @@ -21,7 +21,7 @@
>  #define SFC_VDPA_DEFAULT_MCDI_IOVA   0x2000
> 
>  /* Broadcast & Unicast MAC filters are supported */
> -#define SFC_MAX_SUPPORTED_FILTERS2
> +#define SFC_MAX_SUPPORTED_FILTERS3
> 
>  /*
>   * Get function-local index of the associated VI from the
> @@ -32,6 +32,7 @@
>  enum sfc_vdpa_filter_type {
>   SFC_VDPA_BCAST_MAC_FILTER = 0,
>   SFC_VDPA_UCAST_MAC_FILTER = 1,
> + SFC_VDPA_MCAST_DST_FILTER = 2,
>   SFC_VDPA_FILTER_NTYPE
>  };
> 
> diff --git a/drivers/vdpa/sfc/sfc_vdpa_filter.c
> b/drivers/vdpa/sfc/sfc_vdpa_filter.c
> index 03b6a5d..74204d3 100644
> --- a/drivers/vdpa/sfc/sfc_vdpa_filter.c
> +++ b/drivers/vdpa/sfc/sfc_vdpa_filter.c
> @@ -39,8 +39,12 @@
>   spec->efs_flags = EFX_FILTER_FLAG_RX;
>   spec->efs_dmaq_id = qid;
> 
> - rc = efx_filter_spec_set_eth_local(spec, EFX_FILTER_SPEC_VID_UNSPEC,
> -eth_addr);
> + if (eth_addr == NULL)
> + rc = efx_filter_spec_set_mc_def(spec);
> + else
> + rc = efx_filter_spec_set_eth_local(spec,
> +EFX_FILTER_SPEC_VID_UNSPEC,
> +eth_addr);
>   if (rc != 0)
>   return rc;
> 
> @@ -114,6 +118,17 @@ int sfc_vdpa_filter_config(struct sfc_vdpa_ops_data
> *ops_data)
>   else
>   sva->filters.filter_cnt++;
> 
> + sfc_vdpa_log_init(sva, "insert unknown mcast filter");
> + spec = &sva->filters.spec[SFC_VDPA_MCAST_DST_FILTER];
> +
> + rc = sfc_vdpa_set_mac_filter(nic, spec, qid, NULL);
> + if (rc != 0)
> + sfc_vdpa_err(sva,
> +  "mcast filter insertion failed: %s",
> +  rte_strerror(rc));

Can improve to use two lines.

With this fixed:

Reviewed-by: Chenbo Xia 

> + else
> + sva->filters.filter_cnt++;
> +
>   sfc_vdpa_log_init(sva, "done");
> 
>   return rc;
> --
> 1.8.3.1

Re: [dpdk-dev] [PATCH v2 1/6] dma/dpaa: introduce DPAA DMA driver

[fengchengwen]

On 2021/11/1 16:51, Gagandeep Singh wrote:
> The DPAA DMA  driver is an implementation of the dmadev APIs,
> that provide means to initiate a DMA transaction from CPU.
> The initiated DMA is performed without CPU being involved
> in the actual DMA transaction. This is achieved via using
> the QDMA controller of DPAA SoC.
> 
> Signed-off-by: Gagandeep Singh 

[snip]

> +DPDK_22 {
> +
> + local: *;
> +};
> diff --git a/drivers/dma/meson.build b/drivers/dma/meson.build
> index a69418ce9b..ab2733f7f6 100644
> --- a/drivers/dma/meson.build
> +++ b/drivers/dma/meson.build
> @@ -5,5 +5,6 @@ drivers = [
>  'idxd',
>  'ioat',
>  'skeleton',
> + 'dpaa',

suggest use space replace tab, and add dpaa before skeleton

>  ]
>  std_deps = ['dmadev']
> 

Re: [dpdk-dev] [PATCH v2] vhost: mark vDPA driver API as internal

[Maxime Coquelin]

On 11/1/21 07:50, Xia, Chenbo wrote:

-Original Message-
From: Maxime Coquelin 
Sent: Thursday, October 28, 2021 10:16 PM
To: dev@dpdk.org; techbo...@dpdk.org; Xia, Chenbo ;
xuemi...@nvidia.com; Wang, Xiao W ;
david.march...@redhat.com
Cc: Maxime Coquelin 
Subject: [PATCH v2] vhost: mark vDPA driver API as internal

This patch marks the vDPA driver APIs as internal and
rename the corresponding header file to vdpa_driver.h.

Signed-off-by: Maxime Coquelin 
---

Hi Techboard,

Please vote for an exception for this unannounced API
breakage.


More accurately, the four functions were announced :)


My bad, I forgot about it. Thanks for the reminder!


Reviewed-by: Chenbo Xia 


Maxime



Changes in v2:
==
- Alphabetical ordering in version.map (David)
- Rename header to vdpa_driver.h (David)
- Add Techboard in Cc to vote for API breakage exception

  drivers/vdpa/ifc/ifcvf_vdpa.c   |  2 +-
  drivers/vdpa/mlx5/mlx5_vdpa.h   |  2 +-
  lib/vhost/meson.build   |  4 +++-
  lib/vhost/vdpa.c|  2 +-
  lib/vhost/{rte_vdpa_dev.h => vdpa_driver.h} | 12 +---
  lib/vhost/version.map   | 13 +
  lib/vhost/vhost.h   |  2 +-
  7 files changed, 25 insertions(+), 12 deletions(-)
  rename lib/vhost/{rte_vdpa_dev.h => vdpa_driver.h} (95%)

Re: [dpdk-dev] [PATCH v2 2/6] dma/dpaa: add device probe and remove functionality

[fengchengwen]

On 2021/11/1 16:51, Gagandeep Singh wrote:
> This patch add device initialisation functionality.
> 
> Signed-off-by: Gagandeep Singh 

[snip]

> +
> +static void fsl_qdma_free_chan_resources(struct fsl_qdma_chan *fsl_chan)
> +{
> + struct fsl_qdma_queue *fsl_queue = fsl_chan->queue;
> + struct fsl_qdma_engine *fsl_qdma = fsl_chan->qdma;
> + struct fsl_qdma_comp *comp_temp, *_comp_temp;
> + int id;
> +
> + if (--fsl_queue->count)
> + goto finally;
> +
> + id = (fsl_qdma->block_base - fsl_queue->block_base) /
> +   fsl_qdma->block_offset;
> +
> + while (rte_atomic32_read(&wait_task[id]) == 1)
> + rte_delay_us(QDMA_DELAY);
> +
> + list_for_each_entry_safe(comp_temp, _comp_temp,
> +  &fsl_queue->comp_used, list) {
> + list_del(&comp_temp->list);
> + dma_pool_free(comp_temp->virt_addr);
> + dma_pool_free(comp_temp->desc_virt_addr);
> + rte_free(comp_temp);
> + }
> +
> + list_for_each_entry_safe(comp_temp, _comp_temp,
> +  &fsl_queue->comp_free, list) {
> + list_del(&comp_temp->list);
> + dma_pool_free(comp_temp->virt_addr);
> + dma_pool_free(comp_temp->desc_virt_addr);
> + rte_free(comp_temp);
> + }
> +
> +finally:
> + fsl_qdma->desc_allocated--;
> +}

add a blank line

> +static struct fsl_qdma_queue
> +*fsl_qdma_alloc_queue_resources(struct fsl_qdma_engine *fsl_qdma)
> +{
> + struct fsl_qdma_queue *queue_head, *queue_temp;
> + int len, i, j;
> + int queue_num;
> + int blocks;
> + unsigned int queue_size[FSL_QDMA_QUEUE_MAX];
> +
> + queue_num = fsl_qdma->n_queues;
> + blocks = fsl_qdma->num_blocks;
> +
> + len = sizeof(*queue_head) * queue_num * blocks;
> + queue_head = rte_zmalloc("qdma: queue head", len, 0);
> + if (!queue_head)
> + return NULL;
> +
> + for (i = 0; i < FSL_QDMA_QUEUE_MAX; i++)
> + queue_size[i] = QDMA_QUEUE_SIZE;
> +
> + for (j = 0; j < blocks; j++) {
> + for (i = 0; i < queue_num; i++) {
> + if (queue_size[i] > FSL_QDMA_CIRCULAR_DESC_SIZE_MAX ||
> + queue_size[i] < FSL_QDMA_CIRCULAR_DESC_SIZE_MIN) {
> + return NULL;
> + }
> + queue_temp = queue_head + i + (j * queue_num);
> +
> + queue_temp->cq =
> + dma_pool_alloc(sizeof(struct fsl_qdma_format) *
> +queue_size[i],
> +sizeof(struct fsl_qdma_format) *
> +queue_size[i], &queue_temp->bus_addr);
> +
> + memset(queue_temp->cq, 0x0, queue_size[i] *
> +sizeof(struct fsl_qdma_format));
> +

move memset after check queue_temp->cq validity.

> + if (!queue_temp->cq)

queue_head and previous queue_temp->cq need also freed.

> + return NULL;
> +
> + queue_temp->block_base = fsl_qdma->block_base +
> + FSL_QDMA_BLOCK_BASE_OFFSET(fsl_qdma, j);
> + queue_temp->n_cq = queue_size[i];
> + queue_temp->id = i;
> + queue_temp->count = 0;
> + queue_temp->virt_head = queue_temp->cq;
> +
> + }
> + }
> + return queue_head;
> +}
> +
> +static struct fsl_qdma_queue *fsl_qdma_prep_status_queue(void)
> +{
> + struct fsl_qdma_queue *status_head;
> + unsigned int status_size;
> +
> + status_size = QDMA_STATUS_SIZE;
> + if (status_size > FSL_QDMA_CIRCULAR_DESC_SIZE_MAX ||
> + status_size < FSL_QDMA_CIRCULAR_DESC_SIZE_MIN) {
> + return NULL;
> + }
> +
> + status_head = rte_zmalloc("qdma: status head", sizeof(*status_head), 0);
> + if (!status_head)
> + return NULL;
> +
> + /*
> +  * Buffer for queue command
> +  */
> + status_head->cq = dma_pool_alloc(sizeof(struct fsl_qdma_format) *
> +  status_size,
> +  sizeof(struct fsl_qdma_format) *
> +  status_size,
> +  &status_head->bus_addr);
> +
> + memset(status_head->cq, 0x0, status_size *
> +sizeof(struct fsl_qdma_format));

move memset after check queue_temp->cq validity.

> + if (!status_head->cq)

status_head also need free

> + return NULL;
> +
> + status_head->n_cq = status_size;
> + status_head->virt_head = status_head->cq;
> +
> + return status_head;
> +}
> +
> +static int fsl_qdma_halt(struct fsl_qdma_engine *fsl_qdma)
> +{
> + void *ctrl = fsl_qdma->ctrl_base;
> + void *block;
> + int i, count = RETRIES;
> + unsigned int j;
> + u32 reg

Re: [dpdk-dev] [PATCH v2 4/6] dma/dpaa: support basic operations

[fengchengwen]

On 2021/11/1 16:51, Gagandeep Singh wrote:
> This patch support basic DMA operations which includes
> device capability and channel setup.
> 
> Signed-off-by: Gagandeep Singh 
> ---
>  drivers/dma/dpaa/dpaa_qdma.c | 185 +++
>  drivers/dma/dpaa/dpaa_qdma.h |   6 ++
>  2 files changed, 191 insertions(+)
> 
> diff --git a/drivers/dma/dpaa/dpaa_qdma.c b/drivers/dma/dpaa/dpaa_qdma.c
> index 7808b3de7f..0240f40907 100644
> --- a/drivers/dma/dpaa/dpaa_qdma.c
> +++ b/drivers/dma/dpaa/dpaa_qdma.c
> @@ -8,6 +8,18 @@
>  #include "dpaa_qdma.h"
>  #include "dpaa_qdma_logs.h"
>  
> +static inline void
> +qdma_desc_addr_set64(struct fsl_qdma_format *ccdf, u64 addr)
> +{
> + ccdf->addr_hi = upper_32_bits(addr);
> + ccdf->addr_lo = rte_cpu_to_le_32(lower_32_bits(addr));
> +}
> +
> +static inline void qdma_csgf_set_len(struct fsl_qdma_format *csgf, int len)

staitc inline void stay one seperate line.

> +{
> + csgf->cfg = rte_cpu_to_le_32(len & QDMA_SG_LEN_MASK);
> +}
> +
>  static inline int ilog2(int x)
>  {
>   int log = 0;
> @@ -84,6 +96,64 @@ static void fsl_qdma_free_chan_resources(struct 
> fsl_qdma_chan *fsl_chan)
>  finally:
>   fsl_qdma->desc_allocated--;
>  }
> +
> +/*
> + * Pre-request command descriptor and compound S/G for enqueue.
> + */
> +static int fsl_qdma_pre_request_enqueue_comp_sd_desc(
> + struct fsl_qdma_queue *queue,
> + int size, int aligned)
> +{
> + struct fsl_qdma_comp *comp_temp;
> + struct fsl_qdma_sdf *sdf;
> + struct fsl_qdma_ddf *ddf;
> + struct fsl_qdma_format *csgf_desc;
> + int i;
> +
> + for (i = 0; i < (int)(queue->n_cq + COMMAND_QUEUE_OVERFLLOW); i++) {
> + comp_temp = rte_zmalloc("qdma: comp temp",
> + sizeof(*comp_temp), 0);
> + if (!comp_temp)
> + return -ENOMEM;
> +
> + comp_temp->virt_addr =
> + dma_pool_alloc(size, aligned, &comp_temp->bus_addr);
> + if (!comp_temp->virt_addr) {
> + rte_free(comp_temp);
> + return -ENOMEM;
> + }
> +
> + comp_temp->desc_virt_addr =
> + dma_pool_alloc(size, aligned, &comp_temp->desc_bus_addr);
> + if (!comp_temp->desc_virt_addr)

add free comp_temp_virt_addr and comp_temp

and also free pre queue resource when fail

> + return -ENOMEM;
> +
> + memset(comp_temp->virt_addr, 0, FSL_QDMA_COMMAND_BUFFER_SIZE);
> + memset(comp_temp->desc_virt_addr, 0,
> +FSL_QDMA_DESCRIPTOR_BUFFER_SIZE);
> +
> + csgf_desc = (struct fsl_qdma_format *)comp_temp->virt_addr + 1;
> + sdf = (struct fsl_qdma_sdf *)comp_temp->desc_virt_addr;
> + ddf = (struct fsl_qdma_ddf *)comp_temp->desc_virt_addr + 1;
> + /* Compound Command Descriptor(Frame List Table) */
> + qdma_desc_addr_set64(csgf_desc, comp_temp->desc_bus_addr);
> + /* It must be 32 as Compound S/G Descriptor */
> + qdma_csgf_set_len(csgf_desc, 32);
> + /* Descriptor Buffer */
> + sdf->cmd = rte_cpu_to_le_32(FSL_QDMA_CMD_RWTTYPE <<
> +FSL_QDMA_CMD_RWTTYPE_OFFSET);
> + ddf->cmd = rte_cpu_to_le_32(FSL_QDMA_CMD_RWTTYPE <<
> +FSL_QDMA_CMD_RWTTYPE_OFFSET);
> + ddf->cmd |= rte_cpu_to_le_32(FSL_QDMA_CMD_LWC <<
> + FSL_QDMA_CMD_LWC_OFFSET);
> +
> + list_add_tail(&comp_temp->list, &queue->comp_free);
> + }
> +
> + return 0;> +}
> +
> +
>  static struct fsl_qdma_queue
>  *fsl_qdma_alloc_queue_resources(struct fsl_qdma_engine *fsl_qdma)
>  {
> @@ -311,6 +381,79 @@ static int fsl_qdma_reg_init(struct fsl_qdma_engine 
> *fsl_qdma)
>   return 0;
>  }
>  
> +static int fsl_qdma_alloc_chan_resources(struct fsl_qdma_chan *fsl_chan)
> +{
> + struct fsl_qdma_queue *fsl_queue = fsl_chan->queue;
> + struct fsl_qdma_engine *fsl_qdma = fsl_chan->qdma;
> + int ret;
> +
> + if (fsl_queue->count++)
> + goto finally;
> +
> + INIT_LIST_HEAD(&fsl_queue->comp_free);
> + INIT_LIST_HEAD(&fsl_queue->comp_used);
> +
> + ret = fsl_qdma_pre_request_enqueue_comp_sd_desc(fsl_queue,
> + FSL_QDMA_COMMAND_BUFFER_SIZE, 64);
> + if (ret) {
> + DPAA_QDMA_ERR(
> + "failed to alloc dma buffer for comp descriptor\n");
> + goto exit;
> + }
> +
> +finally:
> + return fsl_qdma->desc_allocated++;
> +
> +exit:
> + return -ENOMEM;
> +}
> +
> +static int
> +dpaa_info_get(const struct rte_dma_dev *dev, struct rte_dma_info *dev_info,
> +   uint32_t info_sz)
> +{
> +#define DPAADMA_MAX_DESC64
> +#define DPAADMA_MIN_DESC64
> +
> + RTE_SET_USED(dev);
> + RTE_SET_USED(info_s

Re: [dpdk-dev] [PATCH v2 5/6] dma/dpaa: support DMA operations

[fengchengwen]

On 2021/11/1 16:51, Gagandeep Singh wrote:
> This patch support copy, submit, completed and
> completed status functionality of DMA driver.
> 
> Signed-off-by: Gagandeep Singh 

...

> +
> +static int fsl_qdma_enqueue_desc(struct fsl_qdma_chan *fsl_chan,
> +   struct fsl_qdma_comp *fsl_comp,
> +   uint64_t flags)
> +{
> + struct fsl_qdma_queue *fsl_queue = fsl_chan->queue;
> + void *block = fsl_queue->block_base;
> + struct fsl_qdma_format *ccdf;
> + u32 reg;
> +
> + /* retrieve and store the register value in big endian
> +  * to avoid bits swap
> +  */
> + reg = qdma_readl_be(block +
> +  FSL_QDMA_BCQSR(fsl_queue->id));
> + if (reg & (FSL_QDMA_BCQSR_QF_XOFF_BE))
> + return -1;
> +
> + /* filling descriptor  command table */
> + ccdf = (struct fsl_qdma_format *)fsl_queue->virt_head;
> + qdma_desc_addr_set64(ccdf, fsl_comp->bus_addr + 16);
> + qdma_ccdf_set_format(ccdf, qdma_ccdf_get_offset(fsl_comp->virt_addr));
> + qdma_ccdf_set_ser(ccdf, qdma_ccdf_get_status(fsl_comp->virt_addr));
> + fsl_comp->index = fsl_queue->virt_head - fsl_queue->cq;
> + fsl_queue->virt_head++;
> +
> + if (fsl_queue->virt_head == fsl_queue->cq + fsl_queue->n_cq)
> + fsl_queue->virt_head = fsl_queue->cq;
> +
> + list_add_tail(&fsl_comp->list, &fsl_queue->comp_used);
> +
> + if (flags == RTE_DMA_OP_FLAG_SUBMIT) {
> + reg = qdma_readl_be(block + FSL_QDMA_BCQMR(fsl_queue->id));
> + reg |= FSL_QDMA_BCQMR_EI_BE;
> + qdma_writel_be(reg, block + FSL_QDMA_BCQMR(fsl_queue->id));
> + }
> + return fsl_comp->index;

I can't catch the index real range? it should to be [0, 0x] from framework 
view.

> +}
> +
>  static int fsl_qdma_alloc_chan_resources(struct fsl_qdma_chan *fsl_chan)
>  {
>   struct fsl_qdma_queue *fsl_queue = fsl_chan->queue;
> @@ -492,6 +690,148 @@ dpaa_qdma_queue_setup(struct rte_dma_dev *dmadev,
>   return dpaa_get_channel(fsl_qdma, vchan);
>  }
>  
> +static int
> +dpaa_qdma_submit(void *dev_private, uint16_t vchan)
> +{
> + struct fsl_qdma_engine *fsl_qdma = (struct fsl_qdma_engine 
> *)dev_private;
> + struct fsl_qdma_chan *fsl_chan =
> + &fsl_qdma->chans[fsl_qdma->vchan_map[vchan]];
> + struct fsl_qdma_queue *fsl_queue = fsl_chan->queue;
> + void *block = fsl_queue->block_base;
> + u32 reg;
> +
> + reg = qdma_readl_be(block + FSL_QDMA_BCQMR(fsl_queue->id));
> + reg |= FSL_QDMA_BCQMR_EI_BE;
> + qdma_writel_be(reg, block + FSL_QDMA_BCQMR(fsl_queue->id));
> +
> + return 0;
> +}
> +

...

>  
> 

Re: [dpdk-dev] [PATCH] eal: fix device hotplug

[Jiang, YuX]

> -Original Message-
> From: David Marchand 
> Sent: Tuesday, November 2, 2021 3:53 PM
> To: dev@dpdk.org
> Cc: Jiang, YuX ; Harman Kalra 
> Subject: [PATCH] eal: fix device hotplug
> 
> The device event interrupt handler was always freed.
> 
> Bugzilla ID: 845
> Fixes: c2bd9367e18f ("lib: remove direct access to interrupt handle")
> 
> Signed-off-by: David Marchand 
> ---
>  lib/eal/linux/eal_dev.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/eal/linux/eal_dev.c b/lib/eal/linux/eal_dev.c index
> 06820a3666..925cdba553 100644
> --- a/lib/eal/linux/eal_dev.c
> +++ b/lib/eal/linux/eal_dev.c
> @@ -317,10 +317,12 @@ rte_dev_event_monitor_start(void)
>   goto exit;
>   }
> 
> - if (rte_intr_type_set(intr_handle, RTE_INTR_HANDLE_DEV_EVENT))
> + ret = rte_intr_type_set(intr_handle,
> RTE_INTR_HANDLE_DEV_EVENT);
> + if (ret)
>   goto exit;
> 
> - if (rte_intr_fd_set(intr_handle, -1))
> + ret = rte_intr_fd_set(intr_handle, -1);
> + if (ret)
>   goto exit;
> 
>   ret = dev_uev_socket_fd_create();
> @@ -339,7 +341,10 @@ rte_dev_event_monitor_start(void)
>   monitor_refcount++;
> 
>  exit:
> - rte_intr_instance_free(intr_handle);
> + if (ret) {
> + rte_intr_instance_free(intr_handle);
> + intr_handle = NULL;
> + }
>   rte_rwlock_write_unlock(&monitor_lock);
>   return ret;
>  }
> @@ -370,6 +375,7 @@ rte_dev_event_monitor_stop(void)
> 
>   close(rte_intr_fd_get(intr_handle));
>   rte_intr_instance_free(intr_handle);
> + intr_handle = NULL;
> 
>   monitor_refcount--;
> 
> --
> 2.23.0
Hi David,

The patch 
https://patchwork.dpdk.org/project/dpdk/patch/20211102075259.3392-1-david.march...@redhat.com/
   
failed to verify. 

after executing "device_del dev1" in the qemu window, the testpmd window hangs 
to death and output as following:
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)
EAL: Cannot find bus for device (:00:05.0)

Re: [dpdk-dev] [PATCH v3 07/10] vdpa/sfc: add support to get queue notify area info

[Vijay Kumar Srivastava]

Hi Chenbo, 

>-Original Message-
>From: Xia, Chenbo 
>Sent: Tuesday, November 2, 2021 1:05 PM
>To: Vijay Kumar Srivastava ; dev@dpdk.org
>Cc: maxime.coque...@redhat.com; andrew.rybche...@oktetlabs.ru; Vijay
>Kumar Srivastava 
>Subject: RE: [PATCH v3 07/10] vdpa/sfc: add support to get queue notify area
>info
>
>Hi Vijay,
>
>> -Original Message-
>> From: Vijay Srivastava 
>> Sent: Friday, October 29, 2021 10:47 PM
>> To: dev@dpdk.org
>> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
>> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava
>> 
>> Subject: [PATCH v3 07/10] vdpa/sfc: add support to get queue notify
>> area info
>>
>> From: Vijay Kumar Srivastava 
>>
>> Implement the vDPA ops get_notify_area to get the notify area info of
>> the queue.
>>
>> Signed-off-by: Vijay Kumar Srivastava 
>> Acked-by: Andrew Rybchenko 
>> ---
[SNIP]
>> +static int
>> +sfc_vdpa_setup_notify_ctrl(int vid)
>> +{
>> +int ret;
>> +struct rte_vdpa_device *vdpa_dev;
>> +struct sfc_vdpa_ops_data *ops_data;
>> +
>> +vdpa_dev = rte_vhost_get_vdpa_device(vid);
>> +
>> +ops_data = sfc_vdpa_get_data_by_dev(vdpa_dev);
>> +if (ops_data == NULL) {
>> +sfc_vdpa_err(ops_data->dev_handle,
>> + "invalid vDPA device : %p, vid : %d",
>> + vdpa_dev, vid);
>> +return -1;
>> +}
>
>Why not use struct sfc_vdpa_ops_data * as the input param rather than vid,
>then use ops_data->vdpa_dev to get vdpa_dev?
>
>As ops_data is checked as non-NULL before the func, it will make things easier.
>
Yes. ops_data can be used as input param. 
I will include this change.

Re: [dpdk-dev] [PATCH v3 02/10] vdpa/sfc: add support for device initialization

[Vijay Kumar Srivastava]

Hi Chenbo,

>-Original Message-
>From: Xia, Chenbo 
>Sent: Tuesday, November 2, 2021 10:47 AM
>To: Vijay Kumar Srivastava ; dev@dpdk.org
>Cc: maxime.coque...@redhat.com; andrew.rybche...@oktetlabs.ru; Praveen
>Kumar Jain 
>Subject: RE: [PATCH v3 02/10] vdpa/sfc: add support for device initialization
>
>> -Original Message-
>> From: Vijay Kumar Srivastava 
>> Sent: Tuesday, November 2, 2021 12:38 PM
>> To: Xia, Chenbo ; dev@dpdk.org
>> Cc: maxime.coque...@redhat.com; andrew.rybche...@oktetlabs.ru; Praveen
>> Kumar Jain 
>> Subject: RE: [PATCH v3 02/10] vdpa/sfc: add support for device
>> initialization
>>
>> Hi Chenbo,
>>
>> >-Original Message-
>> >From: Xia, Chenbo 
>> >Sent: Monday, November 1, 2021 5:19 PM
>> >To: Vijay Kumar Srivastava ; dev@dpdk.org
>> >Cc: maxime.coque...@redhat.com; andrew.rybche...@oktetlabs.ru; Vijay
>> >Kumar Srivastava 
>> >Subject: RE: [PATCH v3 02/10] vdpa/sfc: add support for device
>> >initialization
>> >
>> >Hi Vijay,
>> >
>> >> -Original Message-
>> >> From: Vijay Srivastava 
>> >> Sent: Friday, October 29, 2021 10:47 PM
>> >> To: dev@dpdk.org
>> >> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
>> >> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava
>> >> 
>> >> Subject: [PATCH v3 02/10] vdpa/sfc: add support for device
>> >> initialization
>> >>
>> >> From: Vijay Kumar Srivastava 
>> >>
>> >> Add HW initialization and vDPA device registration support.
>> >>
>> >> Signed-off-by: Vijay Kumar Srivastava 
>> >> Acked-by: Andrew Rybchenko 
>> >> ---
>> [SNIP]
>> >> +
>> >> + do {
>> >> + ret = rte_vfio_container_dma_map(sva->vfio_container_fd,
>> >> +  (uint64_t)mz->addr,
>> >mcdi_iova,
>> >> +  mcdi_buff_size);
>> >> + if (ret == 0)
>> >> + break;
>> >> +
>> >> + mcdi_iova = mcdi_iova >> 1;
>> >> + if (mcdi_iova < mcdi_buff_size) {
>> >> + sfc_vdpa_err(sva,
>> >> +  "DMA mapping failed for MCDI : %s",
>> >> +  rte_strerror(rte_errno));
>> >> + rte_memzone_free(mz);
>> >> + return ret;
>> >> + }
>> >> +
>> >> + } while (ret < 0);
>> >
>> >So when QEMU iova and mcdi_iova conflicts, you just let vdpa dev
>> >failed to configure, right?
>> >
>> >Why not use re-mapping mcdi dma region as the solution? Any side-effect?
>> >Or you just assume conflict can hardly happen?
>>
>> MCDI configuration is being done at the very early point of initialization.
>> Conflict would be detected later when rte_vhost_get_mem_table() would
>> be invoked in .dev_conf callback and then MCDI re-mapping can be done
>> in case of conflict,
>
>Agree. It should be done in dev_conf callback.
>
>> for this a patch is in
>> progress which would be submitted separately.
>
>OK for me, as the initial version, you can just let dev_conf fail if conflict
>happens.
Yes. In case of conflict dev_conf would fail. 

Regards,
Vijay

>> [SNIP]

[dpdk-dev] [PATCH v3] vhost: mark vDPA driver API as internal

[Maxime Coquelin]

This patch marks the vDPA driver APIs as internal and
rename the corresponding header file to vdpa_driver.h.

Signed-off-by: Maxime Coquelin 
Acked-by: Thomas Monjalon 
Reviewed-by: Chenbo Xia 
---
Changes in v3:
==
- Update deprecation notice and release note

Changes in v2:
=
- Alphabetical ordering in version.map (David)
- Rename header to vdpa_driver.h (David)
- Add Techboard in Cc to vote for API breakage exception

 doc/guides/rel_notes/deprecation.rst|  4 
 doc/guides/rel_notes/release_21_11.rst  |  4 
 drivers/vdpa/ifc/ifcvf_vdpa.c   |  2 +-
 drivers/vdpa/mlx5/mlx5_vdpa.h   |  2 +-
 lib/vhost/meson.build   |  4 +++-
 lib/vhost/vdpa.c|  2 +-
 lib/vhost/{rte_vdpa_dev.h => vdpa_driver.h} | 12 +---
 lib/vhost/version.map   | 13 +
 lib/vhost/vhost.h   |  2 +-
 9 files changed, 29 insertions(+), 16 deletions(-)
 rename lib/vhost/{rte_vdpa_dev.h => vdpa_driver.h} (95%)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 4366015b01..ce1b727e77 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -107,10 +107,6 @@ Deprecation Notices
   is deprecated as ambiguous with respect to the embedded switch. The use of
   these attributes will become invalid starting from DPDK 22.11.
 
-* vhost: ``rte_vdpa_register_device``, ``rte_vdpa_unregister_device``,
-  ``rte_vhost_host_notifier_ctrl`` and ``rte_vdpa_relay_vring_used`` vDPA
-  driver interface will be marked as internal in DPDK v21.11.
-
 * vhost: rename ``struct vhost_device_ops`` to ``struct rte_vhost_device_ops``
   in DPDK v21.11.
 
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index 98d50a160b..7c2c976d47 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -475,6 +475,10 @@ API Changes
 * eventdev: Moved memory used by timer adapters to hugepage. This will prevent
   TLB misses if any and aligns to memory structure of other subsystems.
 
+* vhost: ``rte_vdpa_register_device``, ``rte_vdpa_unregister_device``,
+  ``rte_vhost_host_notifier_ctrl`` and ``rte_vdpa_relay_vring_used`` vDPA
+  driver interface are marked as internal.
+
 
 ABI Changes
 ---
diff --git a/drivers/vdpa/ifc/ifcvf_vdpa.c b/drivers/vdpa/ifc/ifcvf_vdpa.c
index dd5251d382..3853c4cf7e 100644
--- a/drivers/vdpa/ifc/ifcvf_vdpa.c
+++ b/drivers/vdpa/ifc/ifcvf_vdpa.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/vdpa/mlx5/mlx5_vdpa.h b/drivers/vdpa/mlx5/mlx5_vdpa.h
index cf4f384fa4..a6c9404cb0 100644
--- a/drivers/vdpa/mlx5/mlx5_vdpa.h
+++ b/drivers/vdpa/mlx5/mlx5_vdpa.h
@@ -12,7 +12,7 @@
 #pragma GCC diagnostic ignored "-Wpedantic"
 #endif
 #include 
-#include 
+#include 
 #include 
 #ifdef PEDANTIC
 #pragma GCC diagnostic error "-Wpedantic"
diff --git a/lib/vhost/meson.build b/lib/vhost/meson.build
index 2d8fe0239f..cdb37a4814 100644
--- a/lib/vhost/meson.build
+++ b/lib/vhost/meson.build
@@ -29,9 +29,11 @@ sources = files(
 )
 headers = files(
 'rte_vdpa.h',
-'rte_vdpa_dev.h',
 'rte_vhost.h',
 'rte_vhost_async.h',
 'rte_vhost_crypto.h',
 )
+driver_sdk_headers = files(
+'vdpa_driver.h',
+)
 deps += ['ethdev', 'cryptodev', 'hash', 'pci']
diff --git a/lib/vhost/vdpa.c b/lib/vhost/vdpa.c
index 6dd91859ac..09ad5d866e 100644
--- a/lib/vhost/vdpa.c
+++ b/lib/vhost/vdpa.c
@@ -17,7 +17,7 @@
 #include 
 
 #include "rte_vdpa.h"
-#include "rte_vdpa_dev.h"
+#include "vdpa_driver.h"
 #include "vhost.h"
 
 /** Double linked list of vDPA devices. */
diff --git a/lib/vhost/rte_vdpa_dev.h b/lib/vhost/vdpa_driver.h
similarity index 95%
rename from lib/vhost/rte_vdpa_dev.h
rename to lib/vhost/vdpa_driver.h
index b0f494815f..fc2d6acedd 100644
--- a/lib/vhost/rte_vdpa_dev.h
+++ b/lib/vhost/vdpa_driver.h
@@ -2,11 +2,13 @@
  * Copyright(c) 2018 Intel Corporation
  */
 
-#ifndef _RTE_VDPA_H_DEV_
-#define _RTE_VDPA_H_DEV_
+#ifndef _VDPA_DRIVER_H_
+#define _VDPA_DRIVER_H_
 
 #include 
 
+#include 
+
 #include "rte_vhost.h"
 #include "rte_vdpa.h"
 
@@ -88,6 +90,7 @@ struct rte_vdpa_device {
  * @return
  *  vDPA device pointer on success, NULL on failure
  */
+__rte_internal
 struct rte_vdpa_device *
 rte_vdpa_register_device(struct rte_device *rte_dev,
struct rte_vdpa_dev_ops *ops);
@@ -100,6 +103,7 @@ rte_vdpa_register_device(struct rte_device *rte_dev,
  * @return
  *  device id on success, -1 on failure
  */
+__rte_internal
 int
 rte_vdpa_unregister_device(struct rte_vdpa_device *dev);
 
@@ -115,6 +119,7 @@ rte_vdpa_unregister_device(struct rte_vdpa_device *dev);
  * @return
  *  0 on success, -1 on failure
  */
+__rte_internal
 int
 rte_vhost_host_notifier_ctrl(int vid, uint16_t qid, bool enable);
 
@@ -132,7

Re: [dpdk-dev] [PATCH 2/2] devtools: disable fixes authors in get maintainers

[Ferruh Yigit]

On 11/1/2021 10:20 PM, Thomas Monjalon wrote:

01/11/2021 14:35, Ferruh Yigit:

'get_maintainer.pl' by default returns authors that has fixes in
relevant code, to reduce the output only maintainers from MAINTAINERS
file, disabling fixes authors, by making '--no-fixes' default.


Do you mean it is not Cc'ing people who have contributed to the file?
Is it keeping Cc of people having contributed to the commit being fixed?



It is adding both, people contributed to the file and contributed to the commit
it is fixing. More details from tool is below [1].

Intention to cc'ing the people who introduced the commit you are fixing
makes sense.
But as far as I can see it adds all xxx-by names from the fix commit, not
just author, that may add some unrelated people.

Let me give a sample:
Commit A: ("ethdev: add namespace")
  It updates bunch of drivers and it has acks from various
  driver maintainers.

Commit B: ("net/txgbe: fix link macro")
  Fixing Commit A for one driver (txgbe)

If --fixes is used on 'Commit B', the author of 'Commit A' and all people
acked 'Commit A' is added. But none of the acks were related to 'Commit B'.
So as a result unrelated people cc'ed for 'Commit B'.


If the commit and fix commit are more narrow scope, this make sense.
So we may prefer to keep '--fixes' if we are OK to some noises in some cases.



[1]
From 'get_maintainer.pl':
   --fixes => for patches, add signatures of commits with 'Fixes: ' 
(default: 1 (on))


And form commit log that adding the feature:
2f5bd343694e ("scripts/get_maintainer.pl: add signatures from Fixes:  
lines in commit message")

A Fixes: lines in a commit message generally indicate that a previous
commit was inadequate for whatever reason.

The signers of the previous inadequate commit should also be cc'd on

this new commit so update get_maintainer to find the old commit and add
the original signers.

Re: [dpdk-dev] [PATCH 2/2] devtools: disable fixes authors in get maintainers

[Ferruh Yigit]

On 11/1/2021 11:19 PM, Stephen Hemminger wrote:

On Mon,  1 Nov 2021 13:35:33 +
Ferruh Yigit  wrote:


'get_maintainer.pl' by default returns authors that has fixes in
relevant code, to reduce the output only maintainers from MAINTAINERS
file, disabling fixes authors, by making '--no-fixes' default.

Signed-off-by: Ferruh Yigit 


Isn't it better to send to more people on patches rather than less.
There could be cases where a patch reverts a change and the original
author never gets notified after this.

Could you give an example?



I already gave a sample on response to Thomas, can you please check there,
to not fork the same discussion.

Thanks,
ferruh

[dpdk-dev] [PATCH v3 0/3] Mempool fixes for FreeBSD

[Dmitry Kozlyuk]

mempool_autotest was failing on FreeBSD,
because rte_virt2iova() is not implemented.
After the test started using memzones,
it appeared that in --no-huge memzones have iova=RTE_BAD_IOVA,
which is unexpected and contradicts with selected IOVA-as-PA.
Intead of working around this in the unit test,
fix FreeBSD EAL to select IOVA-as-VA in --no-huge mode.

v3:
  * Fix IOVA mode logging (Bruce).
v2:
  * Add the EAL changes.
  * Fix a failure with --no-huge (Olivier).

Dmitry Kozlyuk (3):
  eal/freebsd: fix IOVA mode selection
  app/test: fix mempool test on FreeBSD
  app/test: fix mempool test in no-huge mode

 app/test/test_mempool.c | 62 ++---
 lib/eal/freebsd/eal.c   | 37 
 2 files changed, 58 insertions(+), 41 deletions(-)

-- 
2.25.1

[dpdk-dev] [PATCH v3 1/3] eal/freebsd: fix IOVA mode selection

[Dmitry Kozlyuk]

FreeBSD EAL selected IOVA mode PA even in --no-huge mode
where PA are not available. Memory zones were created with IOVA
equal to RTE_BAD_IOVA with no indication this field is not usable.

Change IOVA mode detection:
1. Always allow to force --iova-mode=va.
2. In --no-huge mode, disallow forcing --iova-mode=pa, and select VA.
3. Otherwise select IOVA mode according to bus requests, default to PA.
In case contigmem is inaccessible, memory initialization will fail
with a message indicating the cause.

Fixes: c2361bab70c5 ("eal: compute IOVA mode based on PA availability")
Cc: benjamin.wal...@intel.com
Cc: sta...@dpdk.org

Signed-off-by: Dmitry Kozlyuk 
Acked-by: Bruce Richardson 
---
 lib/eal/freebsd/eal.c | 37 +
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c
index 9935356ed4..2c2baaa691 100644
--- a/lib/eal/freebsd/eal.c
+++ b/lib/eal/freebsd/eal.c
@@ -677,6 +677,8 @@ rte_eal_init(int argc, char **argv)
const struct rte_config *config = rte_eal_get_configuration();
struct internal_config *internal_conf =
eal_get_internal_configuration();
+   bool has_phys_addr;
+   enum rte_iova_mode iova_mode;
 
/* checks if the machine is adequate */
if (!rte_cpu_is_supported()) {
@@ -777,19 +779,30 @@ rte_eal_init(int argc, char **argv)
return -1;
}
 
-   /* if no EAL option "--iova-mode=", use bus IOVA scheme */
-   if (internal_conf->iova_mode == RTE_IOVA_DC) {
-   /* autodetect the IOVA mapping mode (default is RTE_IOVA_PA) */
-   enum rte_iova_mode iova_mode = rte_bus_get_iommu_class();
-
-   if (iova_mode == RTE_IOVA_DC)
-   iova_mode = RTE_IOVA_PA;
-   rte_eal_get_configuration()->iova_mode = iova_mode;
-   } else {
-   rte_eal_get_configuration()->iova_mode =
-   internal_conf->iova_mode;
+   /*
+* PA are only available for hugepages via contigmem.
+* If contigmem is inaccessible, rte_eal_hugepage_init() will fail
+* with a message describing the cause.
+*/
+   has_phys_addr = internal_conf->no_hugetlbfs == 0;
+   iova_mode = internal_conf->iova_mode;
+   if (iova_mode == RTE_IOVA_PA && !has_phys_addr) {
+   rte_eal_init_alert("Cannot use IOVA as 'PA' since physical 
addresses are not available");
+   rte_errno = EINVAL;
+   return -1;
}
-
+   if (iova_mode == RTE_IOVA_DC) {
+   RTE_LOG(DEBUG, EAL, "Specific IOVA mode is not requested, 
autodetecting\n");
+   if (has_phys_addr) {
+   RTE_LOG(DEBUG, EAL, "Selecting IOVA mode according to 
bus requests\n");
+   iova_mode = rte_bus_get_iommu_class();
+   if (iova_mode == RTE_IOVA_DC)
+   iova_mode = RTE_IOVA_PA;
+   } else {
+   iova_mode = RTE_IOVA_VA;
+   }
+   }
+   rte_eal_get_configuration()->iova_mode = iova_mode;
RTE_LOG(INFO, EAL, "Selected IOVA mode '%s'\n",
rte_eal_iova_mode() == RTE_IOVA_PA ? "PA" : "VA");
 
-- 
2.25.1

[dpdk-dev] [PATCH v3 2/3] app/test: fix mempool test on FreeBSD

[Dmitry Kozlyuk]

FreeBSD EAL does not implement rte_mem_virt2iova() causing an error:

EAL: Test assert 
test_mempool_flag_non_io_unset_when_populated_with_valid_iova
line 781 failed: Cannot get IOVA
test failed at test_mempool():1030
Test Failed

Change unit test to use rte_memzone_reserve() to allocate memory,
which allows to obtain IOVA directly.

Bugzilla ID: 863
Fixes: 11541c5c81dd ("mempool: add non-IO flag")

Reported-by: Yu Jiang 
Signed-off-by: Dmitry Kozlyuk 
---
 app/test/test_mempool.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index 4b0f6b0e7f..ced20dcdc3 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -740,16 +740,17 @@ test_mempool_events_safety(void)
 static int
 test_mempool_flag_non_io_set_when_no_iova_contig_set(void)
 {
-   void *virt = NULL;
+   const struct rte_memzone *mz = NULL;
+   void *virt;
rte_iova_t iova;
size_t size = MEMPOOL_ELT_SIZE * 16;
struct rte_mempool *mp = NULL;
int ret;
 
-   virt = rte_malloc("test_mempool", size, rte_mem_page_size());
-   RTE_TEST_ASSERT_NOT_NULL(virt, "Cannot allocate memory");
-   iova = rte_mem_virt2iova(virt);
-   RTE_TEST_ASSERT_NOT_EQUAL(iova,  RTE_BAD_IOVA, "Cannot get IOVA");
+   mz = rte_memzone_reserve("test_mempool", size, SOCKET_ID_ANY, 0);
+   RTE_TEST_ASSERT_NOT_NULL(mz, "Cannot allocate memory");
+   virt = mz->addr;
+   iova = mz->iova;
mp = rte_mempool_create_empty("empty", MEMPOOL_SIZE,
  MEMPOOL_ELT_SIZE, 0, 0,
  SOCKET_ID_ANY, 
RTE_MEMPOOL_F_NO_IOVA_CONTIG);
@@ -772,14 +773,15 @@ test_mempool_flag_non_io_set_when_no_iova_contig_set(void)
ret = TEST_SUCCESS;
 exit:
rte_mempool_free(mp);
-   rte_free(virt);
+   rte_memzone_free(mz);
return ret;
 }
 
 static int
 test_mempool_flag_non_io_unset_when_populated_with_valid_iova(void)
 {
-   void *virt = NULL;
+   const struct rte_memzone *mz = NULL;
+   void *virt;
rte_iova_t iova;
size_t total_size = MEMPOOL_ELT_SIZE * MEMPOOL_SIZE;
size_t block_size = total_size / 3;
@@ -789,12 +791,12 @@ 
test_mempool_flag_non_io_unset_when_populated_with_valid_iova(void)
/*
 * Since objects from the pool are never used in the test,
 * we don't care for contiguous IOVA, on the other hand,
-* reiuring it could cause spurious test failures.
+* requiring it could cause spurious test failures.
 */
-   virt = rte_malloc("test_mempool", total_size, rte_mem_page_size());
-   RTE_TEST_ASSERT_NOT_NULL(virt, "Cannot allocate memory");
-   iova = rte_mem_virt2iova(virt);
-   RTE_TEST_ASSERT_NOT_EQUAL(iova,  RTE_BAD_IOVA, "Cannot get IOVA");
+   mz = rte_memzone_reserve("test_mempool", total_size, SOCKET_ID_ANY, 0);
+   RTE_TEST_ASSERT_NOT_NULL(mz, "Cannot allocate memory");
+   virt = mz->addr;
+   iova = mz->iova;
mp = rte_mempool_create_empty("empty", MEMPOOL_SIZE,
  MEMPOOL_ELT_SIZE, 0, 0,
  SOCKET_ID_ANY, 0);
@@ -827,7 +829,7 @@ 
test_mempool_flag_non_io_unset_when_populated_with_valid_iova(void)
 
 exit:
rte_mempool_free(mp);
-   rte_free(virt);
+   rte_memzone_free(mz);
return ret;
 }
 
-- 
2.25.1

[dpdk-dev] [PATCH v3 3/3] app/test: fix mempool test in no-huge mode

[Dmitry Kozlyuk]

Amount of locked memory for regular users is limited,
it is usually 64 KB by default.
Hitting this limit in rte_mempool_populate_anon()
resulted in not populating the mempool, and a test case failure:

EAL: Test assert test_mempool_events line 585 failed: Failed to populate 
mempool empty1: Success
test failed at test_mempool():1019
Test Failed

Decrease the amount of mapped anonymous memory to fit the limit.
While there, make all function-local constants lowercase.

Fixes: 11541c5c81dd ("mempool: add non-IO flag")

Reported-by: Olivier Matz 
Signed-off-by: Dmitry Kozlyuk 
---
 app/test/test_mempool.c | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index ced20dcdc3..a451608558 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -515,17 +515,19 @@ test_mempool_events(int (*populate)(struct rte_mempool 
*mp))
 #undef RTE_TEST_TRACE_FAILURE
 #define RTE_TEST_TRACE_FAILURE(...) do { goto fail; } while (0)
 
-   static const size_t CB_NUM = 3;
-   static const size_t MP_NUM = 2;
+   static const size_t callback_num = 3;
+   static const size_t mempool_num = 2;
+   static const unsigned int mempool_elt_size = 64;
+   static const unsigned int mempool_size = 64;
 
-   struct test_mempool_events_data data[CB_NUM];
-   struct rte_mempool *mp[MP_NUM], *freed;
+   struct test_mempool_events_data data[callback_num];
+   struct rte_mempool *mp[mempool_num], *freed;
char name[RTE_MEMPOOL_NAMESIZE];
size_t i, j;
int ret;
 
memset(mp, 0, sizeof(mp));
-   for (i = 0; i < CB_NUM; i++) {
+   for (i = 0; i < callback_num; i++) {
ret = rte_mempool_event_callback_register
(test_mempool_events_cb, &data[i]);
RTE_TEST_ASSERT_EQUAL(ret, 0, "Failed to register the callback 
%zu: %s",
@@ -541,12 +543,12 @@ test_mempool_events(int (*populate)(struct rte_mempool 
*mp))
/* Create mempool 0 that will be observed by all callbacks. */
memset(&data, 0, sizeof(data));
strcpy(name, "empty0");
-   mp[0] = rte_mempool_create_empty(name, MEMPOOL_SIZE,
-MEMPOOL_ELT_SIZE, 0, 0,
+   mp[0] = rte_mempool_create_empty(name, mempool_size,
+mempool_elt_size, 0, 0,
 SOCKET_ID_ANY, 0);
RTE_TEST_ASSERT_NOT_NULL(mp[0], "Cannot create mempool %s: %s",
 name, rte_strerror(rte_errno));
-   for (j = 0; j < CB_NUM; j++)
+   for (j = 0; j < callback_num; j++)
RTE_TEST_ASSERT_EQUAL(data[j].invoked, false,
  "Callback %zu invoked on %s mempool 
creation",
  j, name);
@@ -555,7 +557,7 @@ test_mempool_events(int (*populate)(struct rte_mempool *mp))
ret = populate(mp[0]);
RTE_TEST_ASSERT_EQUAL(ret, (int)mp[0]->size, "Failed to populate 
mempool %s: %s",
  name, rte_strerror(-ret));
-   for (j = 0; j < CB_NUM; j++) {
+   for (j = 0; j < callback_num; j++) {
RTE_TEST_ASSERT_EQUAL(data[j].invoked, true,
"Callback %zu not invoked on mempool %s 
population",
j, name);
@@ -574,8 +576,8 @@ test_mempool_events(int (*populate)(struct rte_mempool *mp))
  rte_strerror(rte_errno));
memset(&data, 0, sizeof(data));
strcpy(name, "empty1");
-   mp[1] = rte_mempool_create_empty(name, MEMPOOL_SIZE,
-MEMPOOL_ELT_SIZE, 0, 0,
+   mp[1] = rte_mempool_create_empty(name, mempool_size,
+mempool_elt_size, 0, 0,
 SOCKET_ID_ANY, 0);
RTE_TEST_ASSERT_NOT_NULL(mp[1], "Cannot create mempool %s: %s",
 name, rte_strerror(rte_errno));
@@ -587,7 +589,7 @@ test_mempool_events(int (*populate)(struct rte_mempool *mp))
  "Unregistered callback 0 invoked on %s mempool 
populaton",
  name);
 
-   for (i = 0; i < MP_NUM; i++) {
+   for (i = 0; i < mempool_num; i++) {
memset(&data, 0, sizeof(data));
sprintf(name, "empty%zu", i);
rte_mempool_free(mp[i]);
@@ -597,7 +599,7 @@ test_mempool_events(int (*populate)(struct rte_mempool *mp))
 */
freed = mp[i];
mp[i] = NULL;
-   for (j = 1; j < CB_NUM; j++) {
+   for (j = 1; j < callback_num; j++) {
RTE_TEST_ASSERT_EQUAL(data[j].invoked, true,
  "Callback %zu not invoked on 
mempool %s destruction",

Re: [dpdk-dev] [PATCH v1] ethdev: remove deprecation notice for shared Rx queue

[Ferruh Yigit]

On 11/2/2021 9:29 AM, Xueming Li wrote:

Shared Rx queue feature has been supported in commit[1], remove
deprecation notice.

[1]:
commit dd22740cc291 ("ethdev: introduce shared Rx queue")

Signed-off-by: Xueming Li 


Since it is too late to squash this patch, it will be a separate commit,
for that can you please make it as a fix patch?
In a way it is fixing the commit that is adding the feature?

[dpdk-dev] [PATCH] kni: allow configuring the kni thread granularity

[Tudor Cornea]

The Kni kthreads seem to be re-scheduled at a granularity of roughly
1 milisecond right now, which seems to be insufficient for performing tests
involving a lot of control plane traffic.

Even if KNI_KTHREAD_RESCHEDULE_INTERVAL is set to 5 microseconds, it
seems that the existing code cannot reschedule at the desired granularily,
due to precision constraints of schedule_timeout_interruptible().

In our use case, we leverage the Linux Kernel for control plane, and
it is not uncommon to have 60K - 100K pps for some signaling protocols.

Since we are in non-atomic context, the usleep_range() function seems to be
more appropriate for being able to introduce smaller controlled delays,
in the range of 5-10 microseconds. Upon reading the existing code, it would
seem that this was the original intent. Adding sub-milisecond delays,
seems unfeasible with a call to schedule_timeout_interruptible().

KNI_KTHREAD_RESCHEDULE_INTERVAL 5 /* us */
schedule_timeout_interruptible(
usecs_to_jiffies(KNI_KTHREAD_RESCHEDULE_INTERVAL));

Below, we attempted a brief comparison between the existing implementation,
which uses schedule_timeout_interruptible() and usleep_range().

insmod rte_kni.ko kthread_mode=single carrier=on

schedule_timeout_interruptible(usecs_to_jiffies(5))
kni_single CPU Usage: 2-4 %
[root@localhost ~]# ping 1.1.1.2 -I eth1
PING 1.1.1.2 (1.1.1.2) from 1.1.1.1 eth1: 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=2.70 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=1.00 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.99 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.985 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=1.00 ms

usleep_range(5, 10)
kni_single CPU usage: 50%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.338 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.150 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.123 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.139 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.159 ms

usleep_range(20, 50)
kni_single CPU usage: 24%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.202 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.170 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.171 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.248 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.185 ms

usleep_range(50, 100)
kni_single CPU usage: 13%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.537 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.257 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.231 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.143 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.200 ms

usleep_range(100, 200)
kni_single CPU usage: 7%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.716 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.167 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.459 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.455 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.252 ms

usleep_range(1000, 1100)
kni_single CPU usage: 2%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=2.22 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=1.17 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.17 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=1.17 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=1.15 ms

Upon testing, usleep_range(1000, 1100) seems roughly equivalent in
latency and cpu usage to the variant with schedule_timeout_interruptible(),
while usleep_range(100, 200) seems to give a decent tradeoff between
latency and cpu usage, while allowing users to tweak the limits for
improved precision if they have such use cases.

Disabling RTE_KNI_PREEMPT_DEFAULT, interestingly seems to lead to a
softlockup on my kernel.

Kernel panic - not syncing: softlockup: hung tasks
CPU: 0 PID: 1226 Comm: kni_single Tainted: GW  O 3.10 #1
   [] dump_stack+0x19/0x1b
 [] panic+0xcd/0x1e0
 [] watchdog_timer_fn+0x160/0x160
 [] __run_hrtimer.isra.4+0x42/0xd0
 [] hrtimer_interrupt+0xe7/0x1f0
 [] smp_apic_timer_interrupt+0x67/0xa0
 [] apic_timer_interrupt+0x6d/0x80

References:
[1] https://www.kernel.org/doc/Documentation/timers/timers-howto.txt

Signed-off-by: Tudor Cornea 
---
 doc/guides/prog_guide/kernel_nic_interface.rst | 33 +++
 kernel/linux/kni/kni_dev.h |  2 +-
 kernel/linux/kni/kni_misc.c| 36 +++---
 3 files changed, 66 insertions(+), 5 deletions(-)

diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst 
b/doc/guides/prog_guide/kernel_nic_interface.rst
index 1ce03ec..5d6d535 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -56,6 +56,10 @@ can be specified when the module is loaded to control its 
behavior:
 off   Interfaces will be created with carrier state set to 
off.
 onInterfaces will be created with carrier state set to 
on.
  (charp)
+parm:  

[dpdk-dev] [PATCH v2] app/flow-perf: added option to support flow priority

[psatheesh]

From: Satheesh Paul 

Added support to create flows with priority attribute set
randomly between 0 and a user supplied maximum value. This
is useful to measure performance on NICs which may have to
rearrange flows to honor flow priority.

Removed the lower limit of 10 flows per batch.

Signed-off-by: Satheesh Paul 
---
v2:
* Changed "--max-priority" to "--random-priority".
* Added support to take seed for pseudo-random number generator.
* Updated documentation for the above.

 app/test-flow-perf/flow_gen.c  |  6 ++--
 app/test-flow-perf/flow_gen.h  |  1 +
 app/test-flow-perf/main.c  | 56 +++---
 doc/guides/tools/flow-perf.rst |  4 +++
 4 files changed, 47 insertions(+), 20 deletions(-)

diff --git a/app/test-flow-perf/flow_gen.c b/app/test-flow-perf/flow_gen.c
index 51871dbfdc..4eea8fb7c5 100644
--- a/app/test-flow-perf/flow_gen.c
+++ b/app/test-flow-perf/flow_gen.c
@@ -18,7 +18,7 @@
 
 static void
 fill_attributes(struct rte_flow_attr *attr,
-   uint64_t *flow_attrs, uint16_t group)
+   uint64_t *flow_attrs, uint16_t group, uint8_t max_priority)
 {
uint8_t i;
for (i = 0; i < MAX_ATTRS_NUM; i++) {
@@ -32,6 +32,7 @@ fill_attributes(struct rte_flow_attr *attr,
attr->transfer = 1;
}
attr->group = group;
+   attr->priority = rte_rand_max(max_priority);
 }
 
 struct rte_flow *
@@ -48,6 +49,7 @@ generate_flow(uint16_t port_id,
uint8_t core_idx,
uint8_t rx_queues_count,
bool unique_data,
+   uint8_t max_priority,
struct rte_flow_error *error)
 {
struct rte_flow_attr attr;
@@ -59,7 +61,7 @@ generate_flow(uint16_t port_id,
memset(actions, 0, sizeof(actions));
memset(&attr, 0, sizeof(struct rte_flow_attr));
 
-   fill_attributes(&attr, flow_attrs, group);
+   fill_attributes(&attr, flow_attrs, group, max_priority);
 
fill_actions(actions, flow_actions,
outer_ip_src, next_table, hairpinq,
diff --git a/app/test-flow-perf/flow_gen.h b/app/test-flow-perf/flow_gen.h
index 1118a9fc14..40eeceae6e 100644
--- a/app/test-flow-perf/flow_gen.h
+++ b/app/test-flow-perf/flow_gen.h
@@ -37,6 +37,7 @@ generate_flow(uint16_t port_id,
uint8_t core_idx,
uint8_t rx_queues_count,
bool unique_data,
+   uint8_t max_priority,
struct rte_flow_error *error);
 
 #endif /* FLOW_PERF_FLOW_GEN */
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 3ebc025fb2..c49c5e44e6 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -77,6 +77,8 @@ static uint32_t rules_count;
 static uint32_t rules_batch;
 static uint32_t hairpin_queues_num; /* total hairpin q number - default: 0 */
 static uint32_t nb_lcores;
+static uint8_t max_priority;
+static uint32_t rand_seed;
 
 #define MAX_PKT_BURST32
 #define LCORE_MODE_PKT1
@@ -140,6 +142,8 @@ usage(char *progname)
printf("  --enable-fwd: To enable packets forwarding"
" after insertion\n");
printf("  --portmask=N: hexadecimal bitmask of ports used\n");
+   printf( "  --random-priority=N,S: Use random priority levels from 0 to"
+   "(N - 1) for flows and S as seed for pseudo-random number 
generator\n");
printf("  --unique-data: flag to set using unique data for all"
" actions that support data, such as header modify and encap 
actions\n");
 
@@ -238,8 +242,9 @@ usage(char *progname)
 static void
 args_parse(int argc, char **argv)
 {
-   uint64_t pm;
+   uint64_t pm, seed;
char **argvopt;
+   uint32_t prio;
char *token;
char *end;
int n, opt;
@@ -589,6 +594,7 @@ args_parse(int argc, char **argv)
{ "unique-data",0, 0, 0 },
{ "portmask",   1, 0, 0 },
{ "cores",  1, 0, 0 },
+   { "random-priority",1, 0, 0 },
{ "meter-profile-alg",  1, 0, 0 },
{ "rxq",1, 0, 0 },
{ "txq",1, 0, 0 },
@@ -767,25 +773,27 @@ args_parse(int argc, char **argv)
/* Control */
if (strcmp(lgopts[opt_idx].name,
"rules-batch") == 0) {
-   n = atoi(optarg);
-   if (n >= DEFAULT_RULES_BATCH)
-   rules_batch = n;
-   else {
-   rte_exit(EXIT_FAILURE,
-   "rules_batch should be >= %d\n",
-   DEFAULT_RULES_BATCH);
-   }
+   rules_batch = atoi(optarg);
}
if (strcmp(lgopts[opt_idx].name,
  

Re: [dpdk-dev] [PATCH] app/flow-perf: added option to support flow priority

[Satheesh Paul]

Hi,

Thanks for the review. Please find the reply inline.

-Original Message-
From: Wisam Monther  
Sent: 01 November 2021 02:37 PM
To: Satheesh Paul 
Cc: dev@dpdk.org; Asaf Penso 
Subject: [EXT] RE: [dpdk-dev] [PATCH] app/flow-perf: added option to support 
flow priority

External Email

--
Hi,

Please see my inline comments, thanks 😊 

> -Original Message-
> From: psathe...@marvell.com 
> Sent: Friday, October 29, 2021 7:09 AM
> To: Wisam Monther 
> Cc: dev@dpdk.org; Satheesh Paul 
> Subject: [dpdk-dev] [PATCH] app/flow-perf: added option to support 
> flow priority
> 
> From: Satheesh Paul 
> 
> Added support to specify maximum flow priority option. When this 
> option is given, each flow will be created with the priority attribute 
> and the priority will be random between
> 0 to max-flow-priority. This is useful to measure performance on NICs 
> which may have to rearrange flows to honor flow priority.
> 
> Removed the lower limit of 10 flows per batch.
> 
> Signed-off-by: Satheesh Paul 
> ---
>  app/test-flow-perf/flow_gen.c  |  7 --  
> app/test-flow-perf/flow_gen.h
> |  1 +
>  app/test-flow-perf/main.c  | 44 +-
>  doc/guides/tools/flow-perf.rst |  5 
>  4 files changed, 38 insertions(+), 19 deletions(-)
> 
> diff --git a/app/test-flow-perf/flow_gen.c 
> b/app/test-flow-perf/flow_gen.c index 51871dbfdc..414ec0bc5e 100644
> --- a/app/test-flow-perf/flow_gen.c
> +++ b/app/test-flow-perf/flow_gen.c
> @@ -18,7 +18,7 @@
> 
>  static void
>  fill_attributes(struct rte_flow_attr *attr,
> - uint64_t *flow_attrs, uint16_t group)
> + uint64_t *flow_attrs, uint16_t group, uint8_t max_priority)
>  {
>   uint8_t i;
>   for (i = 0; i < MAX_ATTRS_NUM; i++) { @@ -32,6 +32,8 @@ 
> fill_attributes(struct rte_flow_attr *attr,
>   attr->transfer = 1;
>   }
>   attr->group = group;
> + if (max_priority)
> + attr->priority = rte_rand_max(max_priority);

No need to do this, since it's static and default is zero you can always set it 
without the condition

Ack.

>  }
> 
>  struct rte_flow *
> @@ -48,6 +50,7 @@ generate_flow(uint16_t port_id,
>   uint8_t core_idx,
>   uint8_t rx_queues_count,
>   bool unique_data,
> + uint8_t max_priority,

--max-priority=N is good, but I think to reflect the exact usage of it we need 
something like:
--random-priority=lower_hand-upper_hand
That do random prio from lower to upper.

The spec says priority 0 must be supported. Since we have one side of the 
interval, it may not be useful to take "lower_hand" as input. 

>   struct rte_flow_error *error)
>  {
>   struct rte_flow_attr attr;
> @@ -59,7 +62,7 @@ generate_flow(uint16_t port_id,
>   memset(actions, 0, sizeof(actions));
>   memset(&attr, 0, sizeof(struct rte_flow_attr));
> 
> - fill_attributes(&attr, flow_attrs, group);
> + fill_attributes(&attr, flow_attrs, group, max_priority);
> 
>   fill_actions(actions, flow_actions,
>   outer_ip_src, next_table, hairpinq, diff --git 
> a/app/test-flow-perf/flow_gen.h b/app/test-flow-perf/flow_gen.h index 
> 1118a9fc14..40eeceae6e 100644
> --- a/app/test-flow-perf/flow_gen.h
> +++ b/app/test-flow-perf/flow_gen.h
> @@ -37,6 +37,7 @@ generate_flow(uint16_t port_id,
>   uint8_t core_idx,
>   uint8_t rx_queues_count,
>   bool unique_data,
> + uint8_t max_priority,
>   struct rte_flow_error *error);
> 
>  #endif /* FLOW_PERF_FLOW_GEN */
> diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c 
> index 3ebc025fb2..1d91f308fd 100644
> --- a/app/test-flow-perf/main.c
> +++ b/app/test-flow-perf/main.c
> @@ -77,6 +77,7 @@ static uint32_t rules_count;  static uint32_t 
> rules_batch; static uint32_t hairpin_queues_num; /* total hairpin q 
> number - default: 0 */ static uint32_t nb_lcores;
> +static uint8_t max_priority;
> 
>  #define MAX_PKT_BURST32
>  #define LCORE_MODE_PKT1
> @@ -140,6 +141,7 @@ usage(char *progname)
>   printf("  --enable-fwd: To enable packets forwarding"
>   " after insertion\n");
>   printf("  --portmask=N: hexadecimal bitmask of ports used\n");
> + printf("  --max-priority=N: Maximum priority level for flows\n");

It talks also about random values, you need to mention that it will do the 
random also.

Ack.

>   printf("  --unique-data: flag to set using unique data for all"
>   " actions that support data, such as header modify and encap 
> actions\n");
> 
> @@ -589,6 +591,7 @@ args_parse(int argc, char **argv)
>   { "unique-data",0, 0, 0 },
>   { "portmask",   1, 0, 0 },
>   { "cores",  1, 0, 0 },
> + { "max-priority",   1, 0, 0 },
>   { "meter-profile-alg",  1, 0, 0 },
>   { "rxq",1, 0, 0 }

Re: [dpdk-dev] [PATCH v2] test/crypto: refactor DOCSIS to show hidden cases

[Power, Ciara]

>-Original Message-
>From: Troy, Rebecca 
>Sent: Friday 29 October 2021 10:04
>To: dev@dpdk.org
>Cc: Power, Ciara ; Zhang, Roy Fan
>; Coyle, David ; Troy,
>Rebecca ; Akhil Goyal ;
>Doherty, Declan 
>Subject: [PATCH v2] test/crypto: refactor DOCSIS to show hidden cases
>
>In the current implementation, the DOCSIS test cases are running and being
>reported as one test, despite the fact that multiple test cases are hidden
>inside i.e. "test_DOCSIS_PROTO_all" runs
>52 test cases. Each DOCSIS test case should be reported individually instead.
>
>This commit achieves this by removing the use of the test_DOCSIS_PROTO_all
>function and statically listing the test cases to run when building the test 
>suite,
>which are then reported to the user by description.
>
>Signed-off-by: Rebecca Troy 
>
Acked-by: Ciara Power 

Re: [dpdk-dev] [PATCH v2] common/cnxk: support BPHY telemetry

[Ferruh Yigit]

On 11/2/2021 4:32 AM, Jerin Jacob wrote:

On Mon, Nov 1, 2021 at 8:32 PM Ferruh Yigit  wrote:


On 10/22/2021 12:56 PM, Tomasz Duszynski wrote:

Add initial support for baseband telemetry.

Signed-off-by: Tomasz Duszynski
---
v2:
- make bphy telemetry available only on platforms supporting baseband
- use platform types where possible
- remove unused header

   drivers/common/cnxk/cnxk_telemetry_bphy.c | 52 +++


Since the telemetry support is for 'raw/cnxk_bphy', why it is implemented
in common code, instead of driver?


It can be raw/cnxk_bphy, thought of keeping it in common due to
1) To reuse it for another common code consumer


Is it reusable, since the code is to get telemetry data from raw device?


2) roc_bphy_sso_pf_func_get() and roc_bphy_npa_pf_func_get() manged by
common code. aka there is no reverse dependency on the raw driver framework
in common code.


If telemetry code moved to raw driver, dependency will be from driver to
common code, which is correct dependency order I think.

It just looks wrong to have rawdev related telemetry function in the common
code, but I may be missing details, trying to understand.

thanks,
ferruh

Re: [dpdk-dev] [PATCH v2] test/crypto: refactor DOCSIS to show hidden cases

[Coyle, David]

> -Original Message-
> From: Troy, Rebecca 
> Sent: Friday, October 29, 2021 10:04 AM
> To: dev@dpdk.org
> Cc: Power, Ciara ; Zhang, Roy Fan
> ; Coyle, David ; Troy,
> Rebecca ; Akhil Goyal ;
> Doherty, Declan 
> Subject: [PATCH v2] test/crypto: refactor DOCSIS to show hidden cases
> 
> In the current implementation, the DOCSIS test cases are running and being
> reported as one test, despite the fact that multiple test cases are hidden
> inside i.e. "test_DOCSIS_PROTO_all" runs
> 52 test cases. Each DOCSIS test case should be reported individually instead.
> 
> This commit achieves this by removing the use of the
> test_DOCSIS_PROTO_all function and statically listing the test cases to run
> when building the test suite, which are then reported to the user by
> description.
> 
> Signed-off-by: Rebecca Troy 
>
Looks good Rebecca

Reviewed-by: David Coyle 
 

[dpdk-dev] [PATCH] vhost: rename driver callbacks struct

[Maxime Coquelin]

As previously announced, this patch renames struct
vhost_device_ops to struct rte_vhost_device_ops.

Signed-off-by: Maxime Coquelin 
---
 doc/guides/rel_notes/deprecation.rst   | 3 ---
 doc/guides/rel_notes/release_21_11.rst | 2 ++
 drivers/net/vhost/rte_eth_vhost.c  | 2 +-
 examples/vdpa/main.c   | 2 +-
 examples/vhost/main.c  | 2 +-
 examples/vhost_blk/vhost_blk.c | 2 +-
 examples/vhost_blk/vhost_blk.h | 2 +-
 examples/vhost_crypto/main.c   | 2 +-
 lib/vhost/rte_vhost.h  | 4 ++--
 lib/vhost/socket.c | 6 +++---
 lib/vhost/vhost.h  | 4 ++--
 11 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 4366015b01..a9e2433988 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -111,9 +111,6 @@ Deprecation Notices
   ``rte_vhost_host_notifier_ctrl`` and ``rte_vdpa_relay_vring_used`` vDPA
   driver interface will be marked as internal in DPDK v21.11.
 
-* vhost: rename ``struct vhost_device_ops`` to ``struct rte_vhost_device_ops``
-  in DPDK v21.11.
-
 * vhost: The experimental tags of ``rte_vhost_driver_get_protocol_features``,
   ``rte_vhost_driver_get_queue_num``, ``rte_vhost_crypto_create``,
   ``rte_vhost_crypto_free``, ``rte_vhost_crypto_fetch_requests``,
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index 98d50a160b..dea038e3ac 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -564,6 +564,8 @@ ABI Changes
 
 * eventdev: Re-arranged fields in ``rte_event_timer`` to remove holes.
 
+* vhost: rename ``struct vhost_device_ops`` to ``struct rte_vhost_device_ops``.
+
 
 Known Issues
 
diff --git a/drivers/net/vhost/rte_eth_vhost.c 
b/drivers/net/vhost/rte_eth_vhost.c
index 8bb3b27d01..070f0e6dfd 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -975,7 +975,7 @@ vring_state_changed(int vid, uint16_t vring, int enable)
return 0;
 }
 
-static struct vhost_device_ops vhost_ops = {
+static struct rte_vhost_device_ops vhost_ops = {
.new_device  = new_device,
.destroy_device  = destroy_device,
.vring_state_changed = vring_state_changed,
diff --git a/examples/vdpa/main.c b/examples/vdpa/main.c
index 097a267b8c..5ab07655ae 100644
--- a/examples/vdpa/main.c
+++ b/examples/vdpa/main.c
@@ -153,7 +153,7 @@ destroy_device(int vid)
}
 }
 
-static const struct vhost_device_ops vdpa_sample_devops = {
+static const struct rte_vhost_device_ops vdpa_sample_devops = {
.new_device = new_device,
.destroy_device = destroy_device,
 };
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 58e12aa710..8685dfd81b 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -1519,7 +1519,7 @@ vring_state_changed(int vid, uint16_t queue_id, int 
enable)
  * These callback allow devices to be added to the data core when configuration
  * has been fully complete.
  */
-static const struct vhost_device_ops virtio_net_device_ops =
+static const struct rte_vhost_device_ops virtio_net_device_ops =
 {
.new_device =  new_device,
.destroy_device = destroy_device,
diff --git a/examples/vhost_blk/vhost_blk.c b/examples/vhost_blk/vhost_blk.c
index fe2b4e4803..feadacc62e 100644
--- a/examples/vhost_blk/vhost_blk.c
+++ b/examples/vhost_blk/vhost_blk.c
@@ -753,7 +753,7 @@ new_connection(int vid)
return 0;
 }
 
-struct vhost_device_ops vhost_blk_device_ops = {
+struct rte_vhost_device_ops vhost_blk_device_ops = {
.new_device =  new_device,
.destroy_device = destroy_device,
.new_connection = new_connection,
diff --git a/examples/vhost_blk/vhost_blk.h b/examples/vhost_blk/vhost_blk.h
index 540998eb1b..975f0b4065 100644
--- a/examples/vhost_blk/vhost_blk.h
+++ b/examples/vhost_blk/vhost_blk.h
@@ -104,7 +104,7 @@ struct vhost_blk_task {
 };
 
 extern struct vhost_blk_ctrlr *g_vhost_ctrlr;
-extern struct vhost_device_ops vhost_blk_device_ops;
+extern struct rte_vhost_device_ops vhost_blk_device_ops;
 
 int vhost_bdev_process_blk_commands(struct vhost_block_dev *bdev,
 struct vhost_blk_task *task);
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index dea7dcbd07..7d75623a5e 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -363,7 +363,7 @@ destroy_device(int vid)
RTE_LOG(INFO, USER1, "Vhost Crypto Device %i Removed\n", vid);
 }
 
-static const struct vhost_device_ops virtio_crypto_device_ops = {
+static const struct rte_vhost_device_ops virtio_crypto_device_ops = {
.new_device =  new_device,
.destroy_device = destroy_device,
 };
diff --git a/lib/vhost/rte_vhost.h b/lib/vhost/rte_vhost.h
index 6f0915b98f..af0afbcf60 100644
--- a

[dpdk-dev] [PATCH v3] app/flow-perf: added option to support flow priority

[psatheesh]

From: Satheesh Paul 

Added support to create flows with priority attribute set
randomly between 0 and a user supplied maximum value. This
is useful to measure performance on NICs which may have to
rearrange flows to honor flow priority.

Removed the lower limit of 10 flows per batch.

Signed-off-by: Satheesh Paul 
---
v3:
* Fixed checkpatch errors

v2:
* Changed "--max-priority" to "--random-priority".
* Added support to take seed for pseudo-random number generator.
* Updated documentation for the above.

 app/test-flow-perf/flow_gen.c  |  6 ++--
 app/test-flow-perf/flow_gen.h  |  1 +
 app/test-flow-perf/main.c  | 58 +++---
 doc/guides/tools/flow-perf.rst |  4 +++
 4 files changed, 49 insertions(+), 20 deletions(-)

diff --git a/app/test-flow-perf/flow_gen.c b/app/test-flow-perf/flow_gen.c
index 51871dbfdc..4eea8fb7c5 100644
--- a/app/test-flow-perf/flow_gen.c
+++ b/app/test-flow-perf/flow_gen.c
@@ -18,7 +18,7 @@
 
 static void
 fill_attributes(struct rte_flow_attr *attr,
-   uint64_t *flow_attrs, uint16_t group)
+   uint64_t *flow_attrs, uint16_t group, uint8_t max_priority)
 {
uint8_t i;
for (i = 0; i < MAX_ATTRS_NUM; i++) {
@@ -32,6 +32,7 @@ fill_attributes(struct rte_flow_attr *attr,
attr->transfer = 1;
}
attr->group = group;
+   attr->priority = rte_rand_max(max_priority);
 }
 
 struct rte_flow *
@@ -48,6 +49,7 @@ generate_flow(uint16_t port_id,
uint8_t core_idx,
uint8_t rx_queues_count,
bool unique_data,
+   uint8_t max_priority,
struct rte_flow_error *error)
 {
struct rte_flow_attr attr;
@@ -59,7 +61,7 @@ generate_flow(uint16_t port_id,
memset(actions, 0, sizeof(actions));
memset(&attr, 0, sizeof(struct rte_flow_attr));
 
-   fill_attributes(&attr, flow_attrs, group);
+   fill_attributes(&attr, flow_attrs, group, max_priority);
 
fill_actions(actions, flow_actions,
outer_ip_src, next_table, hairpinq,
diff --git a/app/test-flow-perf/flow_gen.h b/app/test-flow-perf/flow_gen.h
index 1118a9fc14..40eeceae6e 100644
--- a/app/test-flow-perf/flow_gen.h
+++ b/app/test-flow-perf/flow_gen.h
@@ -37,6 +37,7 @@ generate_flow(uint16_t port_id,
uint8_t core_idx,
uint8_t rx_queues_count,
bool unique_data,
+   uint8_t max_priority,
struct rte_flow_error *error);
 
 #endif /* FLOW_PERF_FLOW_GEN */
diff --git a/app/test-flow-perf/main.c b/app/test-flow-perf/main.c
index 3ebc025fb2..abb9908306 100644
--- a/app/test-flow-perf/main.c
+++ b/app/test-flow-perf/main.c
@@ -77,6 +77,8 @@ static uint32_t rules_count;
 static uint32_t rules_batch;
 static uint32_t hairpin_queues_num; /* total hairpin q number - default: 0 */
 static uint32_t nb_lcores;
+static uint8_t max_priority;
+static uint32_t rand_seed;
 
 #define MAX_PKT_BURST32
 #define LCORE_MODE_PKT1
@@ -140,6 +142,9 @@ usage(char *progname)
printf("  --enable-fwd: To enable packets forwarding"
" after insertion\n");
printf("  --portmask=N: hexadecimal bitmask of ports used\n");
+   printf("  --random-priority=N,S: Use random priority levels from 0 to"
+   " (N - 1) for flows and S as seed for pseudo-random number"
+   " generator\n");
printf("  --unique-data: flag to set using unique data for all"
" actions that support data, such as header modify and encap 
actions\n");
 
@@ -238,8 +243,9 @@ usage(char *progname)
 static void
 args_parse(int argc, char **argv)
 {
-   uint64_t pm;
+   uint64_t pm, seed;
char **argvopt;
+   uint32_t prio;
char *token;
char *end;
int n, opt;
@@ -589,6 +595,7 @@ args_parse(int argc, char **argv)
{ "unique-data",0, 0, 0 },
{ "portmask",   1, 0, 0 },
{ "cores",  1, 0, 0 },
+   { "random-priority",1, 0, 0 },
{ "meter-profile-alg",  1, 0, 0 },
{ "rxq",1, 0, 0 },
{ "txq",1, 0, 0 },
@@ -767,25 +774,28 @@ args_parse(int argc, char **argv)
/* Control */
if (strcmp(lgopts[opt_idx].name,
"rules-batch") == 0) {
-   n = atoi(optarg);
-   if (n >= DEFAULT_RULES_BATCH)
-   rules_batch = n;
-   else {
-   rte_exit(EXIT_FAILURE,
-   "rules_batch should be >= %d\n",
-   DEFAULT_RULES_BATCH);
-   }
+   rules_batch = atoi(optarg);
}
if (strcmp

Re: [dpdk-dev] [PATCH v2 2/2] bpf: fix convert API can be undefined

[Ananyev, Konstantin]

> > rte_bpf_convert() implementation depends on libpcap.
> > Right now it is defined only when this library is installed and
> > RTE_PORT_PCAP is defined.
> > Fix that by providing for such case stub rte_bpf_convert()
> > implementation that will always return an error.
> > Also move stub for another function (rte_bpf_elf_load) into
> > the same place (bpf_stub.c).
> >
> > Fixes: 2eccf6afbea9 ("bpf: add function to convert classic BPF to DPDK BPF")
> >
> > Signed-off-by: Konstantin Ananyev 
> 
> Wouldn't it be better to fail compiling a program using unimplemented calls
> rather than forcing the user to see a failure later?

You mean to keep things as they are right now?
That way we'll have to put #ifdef RTE_PORT_PCAP around every call to 
bpf_convert().
Doesn't look like a good thing to me.
Also in other places we use similar approach: if HW/SW is not available provide
a dummy implementation that will report an error. 

Re: [dpdk-dev] [PATCH v3 1/3] eventdev/eth_rx: add queue stats get and reset APIs

[Jerin Jacob]

On Thu, Oct 28, 2021 at 4:22 PM Naga Harish K S V
 wrote:
>
> This patch adds new api ``rte_event_eth_rx_adapter_queue_stats_get`` to
> retrieve queue stats. The queue stats are in the format
> ``struct rte_event_eth_rx_adapter_queue_stats``.
>
> For resetting the queue stats,
> ``rte_event_eth_rx_adapter_queue_stats_reset`` api is added.
>
> The adapter stats_get and stats_reset apis are also updated to
> handle queue level event buffer use case.
>
> Signed-off-by: Naga Harish K S V 
> Acked-by: Jay Jayatheerthan 


Series applied to dpdk-next-net-eventdev/for-main. Thanks


> ---
> v2:
> * added pmd callback support for adapter queue_stats_get and
>   queue_stats_reset apis.
>
> v3:
> * addressed coding style review comments
> ---
>  .../prog_guide/event_ethernet_rx_adapter.rst  |  11 +
>  lib/eventdev/eventdev_pmd.h   |  52 
>  lib/eventdev/rte_event_eth_rx_adapter.c   | 268 +++---
>  lib/eventdev/rte_event_eth_rx_adapter.h   |  66 +
>  lib/eventdev/version.map  |   2 +
>  5 files changed, 356 insertions(+), 43 deletions(-)
>
> diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst 
> b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> index 8b58130fc5..67b11e1563 100644
> --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> @@ -166,6 +166,17 @@ flags for handling received packets, event queue 
> identifier, scheduler type,
>  event priority, polling frequency of the receive queue and flow identifier
>  in struct ``rte_event_eth_rx_adapter_queue_conf``.
>
> +Getting and resetting Adapter queue stats
> +~
> +
> +The ``rte_event_eth_rx_adapter_queue_stats_get()`` function reports
> +adapter queue counters defined in struct 
> ``rte_event_eth_rx_adapter_queue_stats``.
> +This function reports queue level stats only when queue level event buffer is
> +used otherwise it returns -EINVAL.
> +
> +The ``rte_event_eth_rx_adapter_queue_stats_reset`` function can be used to
> +reset queue level stats when queue level event buffer is in use.
> +
>  Interrupt Based Rx Queues
>  ~~
>
> diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
> index d009e24309..3ba49d1fd4 100644
> --- a/lib/eventdev/eventdev_pmd.h
> +++ b/lib/eventdev/eventdev_pmd.h
> @@ -749,6 +749,53 @@ typedef int (*eventdev_eth_rx_adapter_stats_get)
>  typedef int (*eventdev_eth_rx_adapter_stats_reset)
> (const struct rte_eventdev *dev,
> const struct rte_eth_dev *eth_dev);
> +
> +struct rte_event_eth_rx_adapter_queue_stats;
> +
> +/**
> + * Retrieve ethernet Rx adapter queue statistics.
> + *
> + * @param dev
> + *   Event device pointer
> + *
> + * @param eth_dev
> + *   Ethernet device pointer
> + *
> + * @param rx_queue_id
> + *  Ethernet device receive queue index.
> + *
> + * @param[out] q_stats
> + *   Pointer to queue stats structure
> + *
> + * @return
> + *   Return 0 on success.
> + */
> +typedef int (*eventdev_eth_rx_adapter_q_stats_get)
> +   (const struct rte_eventdev *dev,
> +const struct rte_eth_dev *eth_dev,
> +uint16_t rx_queue_id,
> +struct rte_event_eth_rx_adapter_queue_stats 
> *q_stats);
> +
> +/**
> + * Reset ethernet Rx adapter queue statistics.
> + *
> + * @param dev
> + *   Event device pointer
> + *
> + * @param eth_dev
> + *   Ethernet device pointer
> + *
> + * @param rx_queue_id
> + *  Ethernet device receive queue index.
> + *
> + * @return
> + *   Return 0 on success.
> + */
> +typedef int (*eventdev_eth_rx_adapter_q_stats_reset)
> +   (const struct rte_eventdev *dev,
> +const struct rte_eth_dev *eth_dev,
> +uint16_t rx_queue_id);
> +
>  /**
>   * Start eventdev selftest.
>   *
> @@ -1224,6 +1271,11 @@ struct eventdev_ops {
> eventdev_crypto_adapter_stats_reset crypto_adapter_stats_reset;
> /**< Reset crypto stats */
>
> +   eventdev_eth_rx_adapter_q_stats_get eth_rx_adapter_queue_stats_get;
> +   /**< Get ethernet Rx queue stats */
> +   eventdev_eth_rx_adapter_q_stats_reset 
> eth_rx_adapter_queue_stats_reset;
> +   /**< Reset ethernet Rx queue stats */
> +
> eventdev_eth_tx_adapter_caps_get_t eth_tx_adapter_caps_get;
> /**< Get ethernet Tx adapter capabilities */
>
> diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c 
> b/lib/eventdev/rte_event_eth_rx_adapter.c
> index a175c61551..3adec52eac 100644
> --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> @@ -245,6 +245,10 @@ struct eth_rx_queue_info {
> uint64_t event;
> struct eth_rx_vector_data vector_data;
> struct eth_event_enqueue_buffer *event_buf;
> +   /* use adapter stats struct for queue level stats,
> +* 

Re: [dpdk-dev] [PATCH] regex/octeontx2: use cnxk infrastructure

[Jerin Jacob]

On Thu, Oct 28, 2021 at 2:53 PM  wrote:
>
> From: Liron Himi 
>
> update driver to use the REE cnxk code
>
> Signed-off-by: Liron Himi 

Waiting for depending patch's v2 version to merge this.


> ---
>  drivers/regex/octeontx2/meson.build   |   6 +-
>  drivers/regex/octeontx2/otx2_regexdev.c   | 261 +---
>  drivers/regex/octeontx2/otx2_regexdev.h   |  75 +---
>  .../regex/octeontx2/otx2_regexdev_compiler.c  |   8 +-
>  .../regex/octeontx2/otx2_regexdev_hw_access.c | 167 
>  .../regex/octeontx2/otx2_regexdev_hw_access.h | 202 -
>  drivers/regex/octeontx2/otx2_regexdev_mbox.c  | 401 --
>  drivers/regex/octeontx2/otx2_regexdev_mbox.h  |  38 --
>  8 files changed, 111 insertions(+), 1047 deletions(-)
>  delete mode 100644 drivers/regex/octeontx2/otx2_regexdev_hw_access.c
>  delete mode 100644 drivers/regex/octeontx2/otx2_regexdev_hw_access.h
>  delete mode 100644 drivers/regex/octeontx2/otx2_regexdev_mbox.c
>  delete mode 100644 drivers/regex/octeontx2/otx2_regexdev_mbox.h
>
> diff --git a/drivers/regex/octeontx2/meson.build 
> b/drivers/regex/octeontx2/meson.build
> index 3f81add5bf..0e00867ec0 100644
> --- a/drivers/regex/octeontx2/meson.build
> +++ b/drivers/regex/octeontx2/meson.build
> @@ -18,10 +18,8 @@ endif
>  sources = files(
>  'otx2_regexdev.c',
>  'otx2_regexdev_compiler.c',
> -'otx2_regexdev_hw_access.c',
> -'otx2_regexdev_mbox.c',
>  )
>
> -deps += ['bus_pci', 'common_octeontx2', 'regexdev']
> +deps += ['bus_pci', 'regexdev']
> +deps += ['common_cnxk', 'mempool_cnxk']
>
> -includes += include_directories('../../common/octeontx2')
> diff --git a/drivers/regex/octeontx2/otx2_regexdev.c 
> b/drivers/regex/octeontx2/otx2_regexdev.c
> index b6e55853e9..8ae5001f70 100644
> --- a/drivers/regex/octeontx2/otx2_regexdev.c
> +++ b/drivers/regex/octeontx2/otx2_regexdev.c
> @@ -13,12 +13,8 @@
>
>
>  /* REE common headers */
> -#include "otx2_common.h"
> -#include "otx2_dev.h"
>  #include "otx2_regexdev.h"
>  #include "otx2_regexdev_compiler.h"
> -#include "otx2_regexdev_hw_access.h"
> -#include "otx2_regexdev_mbox.h"
>
>
>  /* HW matches are at offset 0x80 from RES_PTR_ADDR
> @@ -35,9 +31,6 @@
>  #define REE_MAX_RULES_PER_GROUP 0x
>  #define REE_MAX_GROUPS 0x
>
> -/* This is temporarily here */
> -#define REE0_PF19
> -#define REE1_PF20
>
>  #define REE_RULE_DB_VERSION2
>  #define REE_RULE_DB_REVISION   0
> @@ -61,29 +54,29 @@ qp_memzone_name_get(char *name, int size, int dev_id, int 
> qp_id)
> snprintf(name, size, "otx2_ree_lf_mem_%u:%u", dev_id, qp_id);
>  }
>
> -static struct otx2_ree_qp *
> +static struct roc_ree_qp *
>  ree_qp_create(const struct rte_regexdev *dev, uint16_t qp_id)
>  {
> struct otx2_ree_data *data = dev->data->dev_private;
> uint64_t pg_sz = sysconf(_SC_PAGESIZE);
> -   struct otx2_ree_vf *vf = &data->vf;
> +   struct roc_ree_vf *vf = &data->vf;
> const struct rte_memzone *lf_mem;
> uint32_t len, iq_len, size_div2;
> char name[RTE_MEMZONE_NAMESIZE];
> uint64_t used_len, iova;
> -   struct otx2_ree_qp *qp;
> +   struct roc_ree_qp *qp;
> uint8_t *va;
> int ret;
>
> /* Allocate queue pair */
> qp = rte_zmalloc("OCTEON TX2 Regex PMD Queue Pair", sizeof(*qp),
> -   OTX2_ALIGN);
> +   ROC_ALIGN);
> if (qp == NULL) {
> otx2_err("Could not allocate queue pair");
> return NULL;
> }
>
> -   iq_len = OTX2_REE_IQ_LEN;
> +   iq_len = REE_IQ_LEN;
>
> /*
>  * Queue size must be in units of 128B 2 * REE_INST_S (which is 64B),
> @@ -93,13 +86,13 @@ ree_qp_create(const struct rte_regexdev *dev, uint16_t 
> qp_id)
> size_div2 = iq_len >> 1;
>
> /* For pending queue */
> -   len = iq_len * RTE_ALIGN(sizeof(struct otx2_ree_rid), 8);
> +   len = iq_len * RTE_ALIGN(sizeof(struct roc_ree_rid), 8);
>
> /* So that instruction queues start as pg size aligned */
> len = RTE_ALIGN(len, pg_sz);
>
> /* For instruction queues */
> -   len += OTX2_REE_IQ_LEN * sizeof(union otx2_ree_inst);
> +   len += REE_IQ_LEN * sizeof(union roc_ree_inst);
>
> /* Waste after instruction queues */
> len = RTE_ALIGN(len, pg_sz);
> @@ -107,7 +100,7 @@ ree_qp_create(const struct rte_regexdev *dev, uint16_t 
> qp_id)
> qp_memzone_name_get(name, RTE_MEMZONE_NAMESIZE, dev->data->dev_id,
> qp_id);
>
> -   lf_mem = rte_memzone_reserve_aligned(name, len, vf->otx2_dev.node,
> +   lf_mem = rte_memzone_reserve_aligned(name, len, rte_socket_id(),
> RTE_MEMZONE_SIZE_HINT_ONLY | RTE_MEMZONE_256MB,
> RTE_CACHE_LINE_SIZE);
> if (lf_mem == NULL) {
> @@ -121,22 +114,22 @@ ree_qp_create(const struct rte_regexdev *dev, uint16_t 
> qp_id)
>  

Re: [dpdk-dev] [PATCH v2] common/cnxk: support BPHY telemetry

[Jerin Jacob]

On Tue, Nov 2, 2021 at 3:58 PM Ferruh Yigit  wrote:
>
> On 11/2/2021 4:32 AM, Jerin Jacob wrote:
> > On Mon, Nov 1, 2021 at 8:32 PM Ferruh Yigit  wrote:
> >>
> >> On 10/22/2021 12:56 PM, Tomasz Duszynski wrote:
> >>> Add initial support for baseband telemetry.
> >>>
> >>> Signed-off-by: Tomasz Duszynski
> >>> ---
> >>> v2:
> >>> - make bphy telemetry available only on platforms supporting baseband
> >>> - use platform types where possible
> >>> - remove unused header
> >>>
> >>>drivers/common/cnxk/cnxk_telemetry_bphy.c | 52 +++
> >>
> >> Since the telemetry support is for 'raw/cnxk_bphy', why it is implemented
> >> in common code, instead of driver?
> >
> > It can be raw/cnxk_bphy, thought of keeping it in common due to
> > 1) To reuse it for another common code consumer
>
> Is it reusable, since the code is to get telemetry data from raw device?

Yes. I meant, common code is reused on another library that has
telemetry support too.

>
> > 2) roc_bphy_sso_pf_func_get() and roc_bphy_npa_pf_func_get() manged by
> > common code. aka there is no reverse dependency on the raw driver framework
> > in common code.
>
> If telemetry code moved to raw driver, dependency will be from driver to
> common code, which is correct dependency order I think.
>
> It just looks wrong to have rawdev related telemetry function in the common
> code, but I may be missing details, trying to understand.

Currently, we are doing like this:
- implementing HW specific telemetry endpoints in driver/common/cnxk
- ethdev/mempool/eventdev/cryptodev driver-specific telemetry endpoint
in driver/.../cnxk.
The criteria for deciding what is the second category is, if it uses
any ethdev/mempool/eventdev/cryptodev/rawdev
symbols or if telemetry-related raw dev driver implementation details.
i.e common code does not have
any raw driver dependency.




>
> thanks,
> ferruh

Re: [dpdk-dev] [PATCH v1] test/crypto: fix: test vectors for zuc 256 bit key

[De Lara Guarch, Pablo]

Hi Sagar,

Yes, those vectors pass for us too.
>From our vectors, the ones for encryption (zuc256_test_case_cipher_1 and 
>zuc256_test_case_cipher_2) work for you, and only the authentication one 
>(zuc256_test_case_auth_1) doesn't?
Since verifying authentication is more difficult, we should try to cross check 
encryption, mainly check if we are generating the same keystream.
Could you change the plaintext of your encryption test vector 
(zuc_test_case_cipher_800b_key_256b ) to all 0s, and see which ciphertext you 
see
(will be the keystream generated by your device).
Our implementation actually matches with GmSSL library, so it looks like you 
might have some issue in yours, but let's see.

Thanks,
Pablo

From: Vidya Sagar Velumuri 
Sent: Tuesday, November 2, 2021 4:41 AM
To: De Lara Guarch, Pablo ; Ankur Dwivedi 
; Anoob Joseph ; Tejasree Kondoj 
; Nithin Kumar Dabilpuram ; 
Akhil Goyal ; Doherty, Declan 
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1] test/crypto: fix: test vectors for zuc 256 
bit key

Hi Pablo,

We verified vectors mentioned in below link in our platform and all the vectors 
passed (i.e: the digest matches with the doc).
http://www.is.cas.cn/ztzl2016/zouchongzhi/201801/W020180126529970733243.pdf
The ZUC-256 Stream 
Cipher
The ZUC-256 Stream Cipher 5 3. X 2 = s 7L ks 5H 4. X 3 = s 2L ks 0H, where s iH 
is the high 16 bits of the cell s i and s jL is the low 16 bits of the cell s 
j. F(X 0;X 1;X 2) 1. W = (X 0 R 1) R 2 2. W 1 = R 1 X 1 3. W 2 = R 2 X 2 4. R 1 
= S(L 1(W 1L kW 2H)) 5. R 2 = S(L 2(W 2L kW 1H)), where S = (S 0;S 1;S 0;S 1) 
is the 4 parallel S-boxes which are the same as those used in the previous ZUC 
...
www.is.cas.cn

Could you please check if these vectors work in your platform.

Regards
Sagar

From: Vidya Sagar Velumuri mailto:vvelum...@marvell.com>>
Sent: 01 November 2021 15:53
To: De Lara Guarch, Pablo 
mailto:pablo.de.lara.gua...@intel.com>>; Ankur 
Dwivedi mailto:adwiv...@marvell.com>>; Anoob Joseph 
mailto:ano...@marvell.com>>; Tejasree Kondoj 
mailto:ktejas...@marvell.com>>; Nithin Kumar Dabilpuram 
mailto:ndabilpu...@marvell.com>>; Akhil Goyal 
mailto:gak...@marvell.com>>; Doherty, Declan 
mailto:declan.dohe...@intel.com>>
Cc: dev@dpdk.org mailto:dev@dpdk.org>>
Subject: Re: [dpdk-dev] [PATCH v1] test/crypto: fix: test vectors for zuc 256 
bit key

Hi Pablo,

Verified with updated test vector.  the output did not change from previous 
output but also, it did not match the ouput present in the vector.

Regards
Sagar


From: De Lara Guarch, Pablo 
mailto:pablo.de.lara.gua...@intel.com>>
Sent: 01 November 2021 03:36
To: Vidya Sagar Velumuri mailto:vvelum...@marvell.com>>; 
Ankur Dwivedi mailto:adwiv...@marvell.com>>; Anoob Joseph 
mailto:ano...@marvell.com>>; Tejasree Kondoj 
mailto:ktejas...@marvell.com>>; Nithin Kumar Dabilpuram 
mailto:ndabilpu...@marvell.com>>; Akhil Goyal 
mailto:gak...@marvell.com>>; Doherty, Declan 
mailto:declan.dohe...@intel.com>>
Cc: dev@dpdk.org mailto:dev@dpdk.org>>
Subject: [EXT] RE: [dpdk-dev] [PATCH v1] test/crypto: fix: test vectors for zuc 
256 bit key

External Email


Hi Sagar,



Thanks for flagging this. I submitted a patch fixing the IV of the test vectors 
I pushed (it didn't change the output):

http://patches.dpdk.org/project/dpdk/patch/20211031220421.52181-1-pablo.de.lara.gua...@intel.com/



Could you check if they work for you?



Thanks,

Pablo



From: Vidya Sagar Velumuri mailto:vvelum...@marvell.com>>
Sent: Saturday, October 30, 2021 1:26 PM
To: De Lara Guarch, Pablo 
mailto:pablo.de.lara.gua...@intel.com>>; Ankur 
Dwivedi mailto:adwiv...@marvell.com>>; Anoob Joseph 
mailto:ano...@marvell.com>>; Tejasree Kondoj 
mailto:ktejas...@marvell.com>>; Nithin Kumar Dabilpuram 
mailto:ndabilpu...@marvell.com>>; Akhil Goyal 
mailto:gak...@marvell.com>>; Doherty, Declan 
mailto:declan.dohe...@intel.com>>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1] test/crypto: fix: test vectors for zuc 256 
bit key



Hi Pablo,



Tried the test vector zuc256_test_case_auth_1 and the digest did not match with 
the generated digest in our platform.



As per spec, IV[i] for i = 17 to 24 are 6-bit string occupying the 6 least 
signi cant bits of a byte.

But in the vectors, The values in the IV(byte -17 to 24) are > 0x3f.



Could you please elaborate how these bytes are considered for generation of 
digest.



Regards

Sagar



_

Re: [dpdk-dev] Overriding rte_config.h

[Ananyev, Konstantin]

> On Fri, Oct 29, 2021 at 09:48:30AM -0400, Ben Magistro wrote:
> > With the transition to meson, what is the best way to provide custom values
> > to parameters in rte_config.h?  When using makefiles, (from memory, I
> > think) we used common_base as a template that was copied in as a
> > replacement for defconfig_x86  Our current thinking is to apply a
> > locally maintained patch so that we can track custom values easier to the
> > rte_config.h file unless there is another way to pass in an overridden
> > value.  As an example, one of the values we are customizing is
> > IP_FRAG_MAX_FRAG.
> >
> > Cheers,
> >
> There is no one defined way for overriding values in rte_config with the
> meson build system, as values there are ones that should rarely need to be
> overridden. If it's the case that one does need tuning, we generally want
> to look to either change the default so it works for everyone, or
> alternatively look to replace it with a runtime option.
> 
> In the absense of that, a locally maintained patch may be reasonable. To
> what value do you want to change MAX_FRAG? Would it be worth considering as
> a newer default value in DPDK itself, since the current default is fairly
> low?

That might be an option, with IP_FRAG_MAX_FRAG==8 it should be able
to cover common jumbo frame size (9K) pretty easily.
As a drawback default reassembly table size will double. 
Even better would be to go a step further and rework lib/ip_frag
to make it configurable runtime parameter.

Re: [dpdk-dev] [PATCH v2] common/cnxk: support BPHY telemetry

[Ferruh Yigit]

On 11/2/2021 11:11 AM, Jerin Jacob wrote:

On Tue, Nov 2, 2021 at 3:58 PM Ferruh Yigit  wrote:


On 11/2/2021 4:32 AM, Jerin Jacob wrote:

On Mon, Nov 1, 2021 at 8:32 PM Ferruh Yigit  wrote:


On 10/22/2021 12:56 PM, Tomasz Duszynski wrote:

Add initial support for baseband telemetry.

Signed-off-by: Tomasz Duszynski
---
v2:
- make bphy telemetry available only on platforms supporting baseband
- use platform types where possible
- remove unused header

drivers/common/cnxk/cnxk_telemetry_bphy.c | 52 +++


Since the telemetry support is for 'raw/cnxk_bphy', why it is implemented
in common code, instead of driver?


It can be raw/cnxk_bphy, thought of keeping it in common due to
1) To reuse it for another common code consumer


Is it reusable, since the code is to get telemetry data from raw device?


Yes. I meant, common code is reused on another library that has
telemetry support too.




2) roc_bphy_sso_pf_func_get() and roc_bphy_npa_pf_func_get() manged by
common code. aka there is no reverse dependency on the raw driver framework
in common code.


If telemetry code moved to raw driver, dependency will be from driver to
common code, which is correct dependency order I think.

It just looks wrong to have rawdev related telemetry function in the common
code, but I may be missing details, trying to understand.


Currently, we are doing like this:
- implementing HW specific telemetry endpoints in driver/common/cnxk
- ethdev/mempool/eventdev/cryptodev driver-specific telemetry endpoint
in driver/.../cnxk.
The criteria for deciding what is the second category is, if it uses
any ethdev/mempool/eventdev/cryptodev/rawdev
symbols or if telemetry-related raw dev driver implementation details.
i.e common code does not have
any raw driver dependency.



Got it, so I am proceeding as it is.

Re: [dpdk-dev] [PATCH 2/2] devtools: disable fixes authors in get maintainers

[Thomas Monjalon]

02/11/2021 11:04, Ferruh Yigit:
> On 11/1/2021 10:20 PM, Thomas Monjalon wrote:
> > 01/11/2021 14:35, Ferruh Yigit:
> >> 'get_maintainer.pl' by default returns authors that has fixes in
> >> relevant code, to reduce the output only maintainers from MAINTAINERS
> >> file, disabling fixes authors, by making '--no-fixes' default.
> > 
> > Do you mean it is not Cc'ing people who have contributed to the file?
> > Is it keeping Cc of people having contributed to the commit being fixed?
> > 
> 
> It is adding both, people contributed to the file and contributed to the 
> commit
> it is fixing. More details from tool is below [1].
> 
> Intention to cc'ing the people who introduced the commit you are fixing
> makes sense.
> But as far as I can see it adds all xxx-by names from the fix commit, not
> just author, that may add some unrelated people.
> 
> Let me give a sample:
> Commit A: ("ethdev: add namespace")
>It updates bunch of drivers and it has acks from various
>driver maintainers.
> 
> Commit B: ("net/txgbe: fix link macro")
>Fixing Commit A for one driver (txgbe)
> 
> If --fixes is used on 'Commit B', the author of 'Commit A' and all people
> acked 'Commit A' is added. But none of the acks were related to 'Commit B'.
> So as a result unrelated people cc'ed for 'Commit B'.
> 
> 
> If the commit and fix commit are more narrow scope, this make sense.
> So we may prefer to keep '--fixes' if we are OK to some noises in some cases.

Yes I prefer Cc'ing everybody.
In case where the people are not needed for sure, I don't use the script.


> [1]
>  From 'get_maintainer.pl':
> --fixes => for patches, add signatures of commits with 'Fixes: ' 
> (default: 1 (on))
> 
> 
> And form commit log that adding the feature:
> 2f5bd343694e ("scripts/get_maintainer.pl: add signatures from Fixes: 
>  lines in commit message")
> 
>  A Fixes: lines in a commit message generally indicate that a previous
>  commit was inadequate for whatever reason.
>  
>  The signers of the previous inadequate commit should also be cc'd on
>  this new commit so update get_maintainer to find the old commit and add
>  the original signers.
> 

Re: [dpdk-dev] [PATCH v2 1/4] common/cnxk: add DPI DMA support

[fengchengwen]

On 2021/11/2 11:40, Radha Mohan Chintakuntla wrote:
> Add base support as ROC(Rest of Chip) API which will be used by PMD
> dmadev driver.
> 
> This patch adds routines to init, fini, configure the DPI DMA device
> found in Marvell's CN9k or CN10k SoC families.
> 
> Signed-off-by: Radha Mohan Chintakuntla 
> ---

...

> --- /dev/null
> +++ b/drivers/common/cnxk/hw/dpi.h
> @@ -0,0 +1,141 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2021 Marvell.
> + */
> +/**
> + * DPI device HW definitions.
> + */
> +#ifndef __DEV_DPI_HW_H__
> +#define __DEV_DPI_HW_H__

suggest remove __ to avoid conflict with gcc reserved symbol.

...

> +
> +int
> +roc_dpi_configure(struct roc_dpi *roc_dpi)
> +{
> + struct plt_pci_device *pci_dev;
> + const struct plt_memzone *dpi_mz;
> + dpi_mbox_msg_t mbox_msg;
> + struct npa_pool_s pool;
> + struct npa_aura_s aura;
> + int rc, count, buflen;
> + uint64_t aura_handle;
> + plt_iova_t iova;
> + char name[32];
> +
> + if (!roc_dpi) {
> + plt_err("roc_dpi is NULL");
> + return -EINVAL;
> + }
> +
> + pci_dev = roc_dpi->pci_dev;
> + memset(&pool, 0, sizeof(struct npa_pool_s));
> + pool.nat_align = 1;
> +
> + memset(&aura, 0, sizeof(aura));
> + rc = roc_npa_pool_create(&aura_handle, DPI_CMD_QUEUE_SIZE,
> +  DPI_CMD_QUEUE_BUFS, &aura, &pool);
> + if (rc) {
> + plt_err("Failed to create NPA pool, err %d\n", rc);
> + return rc;
> + }
> +
> + snprintf(name, sizeof(name), "dpimem%d", roc_dpi->vfid);
> + buflen = DPI_CMD_QUEUE_SIZE * DPI_CMD_QUEUE_BUFS;
> + dpi_mz = plt_memzone_reserve_aligned(name, buflen, 0,
> +  DPI_CMD_QUEUE_SIZE);
> + if (dpi_mz == NULL) {
> + plt_err("dpi memzone reserve failed");
> + rc = -ENOMEM;
> + goto err1;

currently, err1 will free dpi_mz which is NULL,
it should invoke roc_npa_pool_destroy instead.

> + }
> +
> + roc_dpi->mz = dpi_mz;
> + iova = dpi_mz->iova;
> + for (count = 0; count < DPI_CMD_QUEUE_BUFS; count++) {
> + roc_npa_aura_op_free(aura_handle, 0, iova);
> + iova += DPI_CMD_QUEUE_SIZE;
> + }
> +
> + roc_dpi->chunk_base = (void *)roc_npa_aura_op_alloc(aura_handle, 0);
> + if (!roc_dpi->chunk_base) {
> + plt_err("Failed to alloc buffer from NPA aura");
> + rc = -ENOMEM;
> + goto err2;
> + }
> +
> + roc_dpi->chunk_next = (void *)roc_npa_aura_op_alloc(aura_handle, 0);
> + if (!roc_dpi->chunk_next) {
> + plt_err("Failed to alloc buffer from NPA aura");
> + rc = -ENOMEM;
> + goto err2;
> + }
> +
> + roc_dpi->aura_handle = aura_handle;
> + /* subtract 2 as they have already been alloc'ed above */
> + roc_dpi->pool_size_m1 = (DPI_CMD_QUEUE_SIZE >> 3) - 2;
> +
> + plt_write64(0x0, roc_dpi->rbase + DPI_VDMA_REQQ_CTL);
> + plt_write64(((uint64_t)(roc_dpi->chunk_base) >> 7) << 7,
> + roc_dpi->rbase + DPI_VDMA_SADDR);
> + mbox_msg.u[0] = 0;
> + mbox_msg.u[1] = 0;
> + /* DPI PF driver expects vfid starts from index 0 */
> + mbox_msg.s.vfid = roc_dpi->vfid;
> + mbox_msg.s.cmd = DPI_QUEUE_OPEN;
> + mbox_msg.s.csize = DPI_CMD_QUEUE_SIZE;
> + mbox_msg.s.aura = roc_npa_aura_handle_to_aura(aura_handle);
> + mbox_msg.s.sso_pf_func = idev_sso_pffunc_get();
> + mbox_msg.s.npa_pf_func = idev_npa_pffunc_get();
> +
> + rc = send_msg_to_pf(&pci_dev->addr, (const char *)&mbox_msg,
> + sizeof(dpi_mbox_msg_t));
> + if (rc < 0) {
> + plt_err("Failed to send mbox message %d to DPI PF, err %d",
> + mbox_msg.s.cmd, rc);
> + goto err2;
> + }
> +
> + return rc;
> +
> +err2:
> + roc_npa_pool_destroy(aura_handle);
> +err1:
> + plt_memzone_free(dpi_mz);
> + return rc;
> +}
> +

...

> 

Re: [dpdk-dev] [PATCH v2 2/4] dma/cnxk: create and initialize dmadev on pci probe

[fengchengwen]

On 2021/11/2 11:40, Radha Mohan Chintakuntla wrote:
> This patch creates and initializes a dmadev device on pci probe.
> 
> Signed-off-by: Radha Mohan Chintakuntla 
> ---

...

> +RTE_PMD_REGISTER_PCI(cnxk_dmadev_pci_driver, cnxk_dmadev);
> +RTE_PMD_REGISTER_PCI_TABLE(cnxk_dmadev_pci_driver, cnxk_dma_pci_map);
> +RTE_PMD_REGISTER_KMOD_DEP(cnxk_dmadev_pci_driver, "vfio-pci");
> diff --git a/drivers/dma/cnxk/cnxk_dmadev.h b/drivers/dma/cnxk/cnxk_dmadev.h
> new file mode 100644
> index 00..9e0bb7b2ce
> --- /dev/null
> +++ b/drivers/dma/cnxk/cnxk_dmadev.h
> @@ -0,0 +1,11 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2021 Marvell International Ltd.
> + */
> +#ifndef _CNXK_DMADEV_H_
> +#define _CNXK_DMADEV_H_

suggest remove underline

> +
> +struct cnxk_dpi_vf_s {
> + struct roc_dpi rdpi;
> +};
> +
> +#endif
> diff --git a/drivers/dma/cnxk/meson.build b/drivers/dma/cnxk/meson.build
> new file mode 100644
> index 00..9489d6e6dc
> --- /dev/null
> +++ b/drivers/dma/cnxk/meson.build
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(C) 2021 Marvell International Ltd.
> +#
> +
> +deps += ['bus_pci', 'common_cnxk', 'dmadev']
> +sources = files('cnxk_dmadev.c')
> +headers = files('cnxk_dmadev.h')
> diff --git a/drivers/dma/meson.build b/drivers/dma/meson.build
> index a69418ce9b..c562c8b429 100644
> --- a/drivers/dma/meson.build
> +++ b/drivers/dma/meson.build
> @@ -2,6 +2,7 @@
>  # Copyright 2021 HiSilicon Limited
>  
>  drivers = [
> +'cnxk',
>  'idxd',
>  'ioat',
>  'skeleton',
> 

Acked-by: Chengwen Feng 

Re: [dpdk-dev] [PATCH v2 3/4] dma/cnxk: add dma channel operations

[fengchengwen]

On 2021/11/2 11:40, Radha Mohan Chintakuntla wrote:
> Add functions for the dmadev vchan setup and DMA operations.
> 
> Signed-off-by: Radha Mohan Chintakuntla 

...

>  
> +static int
> +cnxk_dmadev_info_get(const struct rte_dma_dev *dev,
> +  struct rte_dma_info *dev_info, uint32_t size)
> +{
> + RTE_SET_USED(dev);
> + RTE_SET_USED(size);
> +
> + dev_info->max_vchans = 1;
> + dev_info->nb_vchans = 1;
> + dev_info->dev_capa = RTE_DMA_CAPA_MEM_TO_MEM |
> + RTE_DMA_CAPA_MEM_TO_DEV | RTE_DMA_CAPA_DEV_TO_MEM |
> + RTE_DMA_CAPA_OPS_COPY;
> + dev_info->max_desc = DPI_MAX_DESC;
> + dev_info->min_desc = 1;
> + dev_info->max_sges = DPI_MAX_POINTER;
> +
> + return 0;
> +}
> +
> +static int
> +cnxk_dmadev_configure(struct rte_dma_dev *dev,
> +   const struct rte_dma_conf *conf, uint32_t conf_sz)
> +{
> + struct cnxk_dpi_vf_s *dpivf = NULL;
> + int rc = 0;
> +
> + RTE_SET_USED(conf);
> + RTE_SET_USED(conf);
> + RTE_SET_USED(conf_sz);
> + RTE_SET_USED(conf_sz);
> + dpivf = dev->fp_obj->dev_private;
> + rc = roc_dpi_configure(&dpivf->rdpi);
> + if (rc < 0)
> + plt_err("DMA configure failed err = %d", rc);
> +
> + return rc;
> +}
> +
> +static int
> +cnxk_dmadev_vchan_setup(struct rte_dma_dev *dev, uint16_t vchan,
> + const struct rte_dma_vchan_conf *conf,
> + uint32_t conf_sz)
> +{
> + struct cnxk_dpi_vf_s *dpivf = dev->fp_obj->dev_private;
> + struct cnxk_dpi_compl_s *comp_data;
> + union dpi_instr_hdr_s *header = &dpivf->conf.hdr;
> + int i;
> +
> + RTE_SET_USED(vchan);
> + RTE_SET_USED(conf_sz);
> +
> + header->s.pt = DPI_HDR_PT_ZBW_CA;
> +
> + switch (conf->direction) {
> + case RTE_DMA_DIR_DEV_TO_MEM:
> + header->s.xtype = DPI_XTYPE_INBOUND;
> + header->s.lport = conf->src_port.pcie.coreid;
> + header->s.fport = 0;
> + header->s.pvfe = 1;
> + break;
> + case RTE_DMA_DIR_MEM_TO_DEV:
> + header->s.xtype = DPI_XTYPE_OUTBOUND;
> + header->s.lport = 0;
> + header->s.fport = conf->dst_port.pcie.coreid;
> + header->s.pvfe = 1;
> + break;
> + case RTE_DMA_DIR_MEM_TO_MEM:
> + header->s.xtype = DPI_XTYPE_INTERNAL_ONLY;
> + header->s.lport = 0;
> + header->s.fport = 0;
> + header->s.pvfe = 0;
> + break;
> + case RTE_DMA_DIR_DEV_TO_DEV:
> + header->s.xtype = DPI_XTYPE_EXTERNAL_ONLY;
> + header->s.lport = conf->src_port.pcie.coreid;
> + header->s.fport = conf->dst_port.pcie.coreid;

capability don't declare support DEV_TO_DEV, and framework will ensure
not pass DEV_TO_DEV direction. so this code could remove...

> + };
> +
> + for (i = 0; i < conf->nb_desc; i++) {
> + comp_data = rte_zmalloc(NULL, sizeof(*comp_data), 0);

why not check comp_data's validation ?

> + dpivf->conf.c_desc.compl_ptr[i] = comp_data;
> + };
> + dpivf->conf.c_desc.max_cnt = DPI_MAX_DESC;
> + dpivf->conf.c_desc.head = 0;
> + dpivf->conf.c_desc.tail = 0;
> +
> + return 0;
> +}
> +
> +static int
> +cnxk_dmadev_start(struct rte_dma_dev *dev)
> +{
> + struct cnxk_dpi_vf_s *dpivf = dev->fp_obj->dev_private;
> +
> + roc_dpi_enable(&dpivf->rdpi);
> +
> + return 0;
> +}
> +
> +static int
> +cnxk_dmadev_stop(struct rte_dma_dev *dev)
> +{
> + struct cnxk_dpi_vf_s *dpivf = dev->fp_obj->dev_private;
> +
> + roc_dpi_disable(&dpivf->rdpi);
> +
> + return 0;
> +}
> +
> +static int
> +cnxk_dmadev_close(struct rte_dma_dev *dev)
> +{
> + struct cnxk_dpi_vf_s *dpivf = dev->fp_obj->dev_private;
> +
> + roc_dpi_disable(&dpivf->rdpi);
> + roc_dpi_dev_fini(&dpivf->rdpi);
> +
> + return 0;
> +}
> +
> +static inline int
> +__dpi_queue_write(struct roc_dpi *dpi, uint64_t *cmds, int cmd_count)
> +{
> + uint64_t *ptr = dpi->chunk_base;
> +
> + if ((cmd_count < DPI_MIN_CMD_SIZE) || (cmd_count > DPI_MAX_CMD_SIZE) ||
> + cmds == NULL)
> + return -EINVAL;
> +
> + /*
> +  * Normally there is plenty of room in the current buffer for the
> +  * command
> +  */
> + if (dpi->chunk_head + cmd_count < dpi->pool_size_m1) {
> + ptr += dpi->chunk_head;
> + dpi->chunk_head += cmd_count;
> + while (cmd_count--)
> + *ptr++ = *cmds++;
> + } else {
> + int count;
> + uint64_t *new_buff = dpi->chunk_next;
> +
> + dpi->chunk_next =
> + (void *)roc_npa_aura_op_alloc(dpi->aura_handle, 0);
> + if (!dpi->chunk_next) {
> + plt_err("Failed to alloc next buffer from NPA");
> + return -ENOMEM;
> + }
> +
> + /*
> +  * Figure out how 

Re: [dpdk-dev] [PATCH v2 4/4] dma/cnxk: add copy_sg function

[fengchengwen]

On 2021/11/2 11:40, Radha Mohan Chintakuntla wrote:
> Add the copy_sg function that will do the multiple DMA transfers of
> different sizes and different source/destination as well.
> 

...

>  
> +static int
> +cnxk_dmadev_copy_sg(void *dev_private, uint16_t vchan,
> + const struct rte_dma_sge *src,
> + const struct rte_dma_sge *dst,
> + uint16_t nb_src, uint16_t nb_dst, uint64_t flags)
> +{
> + struct cnxk_dpi_vf_s *dpivf = dev_private;
> + union dpi_instr_hdr_s *header = &dpivf->conf.hdr;
> + const struct rte_dma_sge *fptr, *lptr;
> + struct cnxk_dpi_compl_s *comp_ptr;
> + int num_words = 0;
> + int i, rc;
> +
> + RTE_SET_USED(vchan);
> +
> + comp_ptr = dpivf->conf.c_desc.compl_ptr[dpivf->conf.c_desc.tail];
> + comp_ptr->cdata = DPI_REQ_CDATA;
> + header->s.ptr = (uint64_t)comp_ptr;
> + STRM_INC(dpivf->conf.c_desc);
> +
> + /*
> +  * For inbound case, src pointers are last pointers.
> +  * For all other cases, src pointers are first pointers.
> +  */
> + if (header->s.xtype == DPI_XTYPE_INBOUND) {
> + header->s.nfst = nb_dst & 0xf;
> + header->s.nlst = nb_src & 0xf;
> + fptr = &dst[0];
> + lptr = &src[0];
> + } else {
> + header->s.nfst = nb_src & 0xf;
> + header->s.nlst = nb_dst & 0xf;
> + fptr = &src[0];
> + lptr = &dst[0];
> + }
> +
> + dpivf->cmd[0] = header->u[0];
> + dpivf->cmd[1] = header->u[1];
> + dpivf->cmd[2] = header->u[2];
> + num_words += 4;
> + for (i = 0; i < header->s.nfst; i++) {
> + dpivf->cmd[num_words++] = (uint64_t)fptr->length;
> + dpivf->cmd[num_words++] = fptr->addr;
> + fptr++;
> + }
> +
> + for (i = 0; i < header->s.nlst; i++) {
> + dpivf->cmd[num_words++] = (uint64_t)lptr->length;
> + dpivf->cmd[num_words++] = lptr->addr;
> + lptr++;
> + }
> +
> + rc = __dpi_queue_write(&dpivf->rdpi, dpivf->cmd, num_words);
> + if (!rc) {
> + if (flags & RTE_DMA_OP_FLAG_SUBMIT) {
> + rte_wmb();
> + plt_write64(num_words,
> + dpivf->rdpi.rbase + DPI_VDMA_DBELL);
> + }
> + dpivf->num_words = num_words;
> + }
> +
> + return rc;

should return ring index which in [0, 0x]

> +}
> +
>  static uint16_t
>  cnxk_dmadev_completed(void *dev_private, uint16_t vchan, const uint16_t 
> nb_cpls,
> uint16_t *last_idx, bool *has_error)
> @@ -369,6 +434,7 @@ cnxk_dmadev_probe(struct rte_pci_driver *pci_drv 
> __rte_unused,
>   dmadev->dev_ops = &cnxk_dmadev_ops;
>  
>   dmadev->fp_obj->copy = cnxk_dmadev_copy;
> + dmadev->fp_obj->copy_sg = cnxk_dmadev_copy_sg;
>   dmadev->fp_obj->submit = cnxk_dmadev_submit;
>   dmadev->fp_obj->completed = cnxk_dmadev_completed;
>   dmadev->fp_obj->completed_status = cnxk_dmadev_completed_status;
> 

Re: [dpdk-dev] Overriding rte_config.h

[Bruce Richardson]

On Tue, Nov 02, 2021 at 11:20:04AM +, Ananyev, Konstantin wrote:
> 
> > On Fri, Oct 29, 2021 at 09:48:30AM -0400, Ben Magistro wrote:
> > > With the transition to meson, what is the best way to provide custom 
> > > values
> > > to parameters in rte_config.h?  When using makefiles, (from memory, I
> > > think) we used common_base as a template that was copied in as a
> > > replacement for defconfig_x86  Our current thinking is to apply a
> > > locally maintained patch so that we can track custom values easier to the
> > > rte_config.h file unless there is another way to pass in an overridden
> > > value.  As an example, one of the values we are customizing is
> > > IP_FRAG_MAX_FRAG.
> > >
> > > Cheers,
> > >
> > There is no one defined way for overriding values in rte_config with the
> > meson build system, as values there are ones that should rarely need to be
> > overridden. If it's the case that one does need tuning, we generally want
> > to look to either change the default so it works for everyone, or
> > alternatively look to replace it with a runtime option.
> >
> > In the absense of that, a locally maintained patch may be reasonable. To
> > what value do you want to change MAX_FRAG? Would it be worth considering as
> > a newer default value in DPDK itself, since the current default is fairly
> > low?
> 
> That might be an option, with IP_FRAG_MAX_FRAG==8 it should be able
> to cover common jumbo frame size (9K) pretty easily.
> As a drawback default reassembly table size will double.

Maybe not. I'm not an expert in the library, but it seems the basic struct
used for tracking the packets and fragments is "struct ip_frag_pkt". Due to
the other data in the struct and the linked-list overheads, the actual size
increase when doubling MAX_FRAG from 4 to 8 is only 25%. According to gdb
on my debug build it goes from 192B to 256B.

> Even better would be to go a step further and rework lib/ip_frag
> to make it configurable runtime parameter.
>
Agree. However, that's not as quick a fix as just increasing the default
max segs value which could be done immediately if there is consensus on it.

/Bruce 

Re: [dpdk-dev] [PATCH 2/2] devtools: disable fixes authors in get maintainers

[Ferruh Yigit]

On 11/2/2021 11:28 AM, Thomas Monjalon wrote:

02/11/2021 11:04, Ferruh Yigit:

On 11/1/2021 10:20 PM, Thomas Monjalon wrote:

01/11/2021 14:35, Ferruh Yigit:

'get_maintainer.pl' by default returns authors that has fixes in
relevant code, to reduce the output only maintainers from MAINTAINERS
file, disabling fixes authors, by making '--no-fixes' default.


Do you mean it is not Cc'ing people who have contributed to the file?
Is it keeping Cc of people having contributed to the commit being fixed?



It is adding both, people contributed to the file and contributed to the commit
it is fixing. More details from tool is below [1].

Intention to cc'ing the people who introduced the commit you are fixing
makes sense.
But as far as I can see it adds all xxx-by names from the fix commit, not
just author, that may add some unrelated people.

Let me give a sample:
Commit A: ("ethdev: add namespace")
It updates bunch of drivers and it has acks from various
driver maintainers.

Commit B: ("net/txgbe: fix link macro")
Fixing Commit A for one driver (txgbe)

If --fixes is used on 'Commit B', the author of 'Commit A' and all people
acked 'Commit A' is added. But none of the acks were related to 'Commit B'.
So as a result unrelated people cc'ed for 'Commit B'.


If the commit and fix commit are more narrow scope, this make sense.
So we may prefer to keep '--fixes' if we are OK to some noises in some cases.


Yes I prefer Cc'ing everybody.
In case where the people are not needed for sure, I don't use the script.



OK to drop this patch, but I think good to have first one (1/2).




[1]
  From 'get_maintainer.pl':
 --fixes => for patches, add signatures of commits with 'Fixes: ' 
(default: 1 (on))


And form commit log that adding the feature:
2f5bd343694e ("scripts/get_maintainer.pl: add signatures from Fixes:  
lines in commit message")

  A Fixes: lines in a commit message generally indicate that a previous
  commit was inadequate for whatever reason.
  
  The signers of the previous inadequate commit should also be cc'd on

  this new commit so update get_maintainer to find the old commit and add
  the original signers.

Re: [dpdk-dev] Overriding rte_config.h

[Ananyev, Konstantin]

> > > On Fri, Oct 29, 2021 at 09:48:30AM -0400, Ben Magistro wrote:
> > > > With the transition to meson, what is the best way to provide custom 
> > > > values
> > > > to parameters in rte_config.h?  When using makefiles, (from memory, I
> > > > think) we used common_base as a template that was copied in as a
> > > > replacement for defconfig_x86  Our current thinking is to apply a
> > > > locally maintained patch so that we can track custom values easier to 
> > > > the
> > > > rte_config.h file unless there is another way to pass in an overridden
> > > > value.  As an example, one of the values we are customizing is
> > > > IP_FRAG_MAX_FRAG.
> > > >
> > > > Cheers,
> > > >
> > > There is no one defined way for overriding values in rte_config with the
> > > meson build system, as values there are ones that should rarely need to be
> > > overridden. If it's the case that one does need tuning, we generally want
> > > to look to either change the default so it works for everyone, or
> > > alternatively look to replace it with a runtime option.
> > >
> > > In the absense of that, a locally maintained patch may be reasonable. To
> > > what value do you want to change MAX_FRAG? Would it be worth considering 
> > > as
> > > a newer default value in DPDK itself, since the current default is fairly
> > > low?
> >
> > That might be an option, with IP_FRAG_MAX_FRAG==8 it should be able
> > to cover common jumbo frame size (9K) pretty easily.
> > As a drawback default reassembly table size will double.
> 
> Maybe not. I'm not an expert in the library, but it seems the basic struct
> used for tracking the packets and fragments is "struct ip_frag_pkt". Due to
> the other data in the struct and the linked-list overheads, the actual size
> increase when doubling MAX_FRAG from 4 to 8 is only 25%. According to gdb
> on my debug build it goes from 192B to 256B.

Ah yes, you right, struct ip_frag should fit into 16B, key seems the biggest 
one. 

> 
> > Even better would be to go a step further and rework lib/ip_frag
> > to make it configurable runtime parameter.
> >
> Agree. However, that's not as quick a fix as just increasing the default
> max segs value which could be done immediately if there is consensus on it.

You mean for 21.11?
I don't mind in principle, but would like to know other people thoughts here.
Another thing -  we didn't announce it in advance, and it is definitely an ABI 
change. 

[dpdk-dev] [PATCH v2 0/6] dma: add hisilicon DMA driver

[Chengwen Feng]

This patch set add hisilicon DMA driver.

Chengwen Feng (6):
  dma/hisilicon: add device probe and remove functions
  dma/hisilicon: add dmadev instances create and destroy
  dma/hisilicon: add control path functions
  dma/hisilicon: add data path functions
  dma/hisilicon: support multi-process
  devbind: add Kunpeng DMA to dmadev category

---
v2: fix compile error on non-Linux OS.

 MAINTAINERS|   5 +
 doc/guides/dmadevs/hisilicon.rst   |  41 ++
 doc/guides/dmadevs/index.rst   |   1 +
 doc/guides/rel_notes/release_21_11.rst |   4 +
 drivers/dma/hisilicon/hisi_dmadev.c| 925 +
 drivers/dma/hisilicon/hisi_dmadev.h| 236 +++
 drivers/dma/hisilicon/meson.build  |  19 +
 drivers/dma/hisilicon/version.map  |   3 +
 drivers/dma/meson.build|   1 +
 usertools/dpdk-devbind.py  |   6 +-
 10 files changed, 1240 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/dmadevs/hisilicon.rst
 create mode 100644 drivers/dma/hisilicon/hisi_dmadev.c
 create mode 100644 drivers/dma/hisilicon/hisi_dmadev.h
 create mode 100644 drivers/dma/hisilicon/meson.build
 create mode 100644 drivers/dma/hisilicon/version.map

-- 
2.33.0

[dpdk-dev] [PATCH v2 1/6] dma/hisilicon: add device probe and remove functions

[Chengwen Feng]

Add the basic device probe and remove functions and initial
documentation for new hisilicon DMA drivers. Maintainers update is also
included in this patch.

Signed-off-by: Chengwen Feng 
---
 MAINTAINERS|   5 ++
 doc/guides/dmadevs/hisilicon.rst   |  21 +
 doc/guides/dmadevs/index.rst   |   1 +
 doc/guides/rel_notes/release_21_11.rst |   4 +
 drivers/dma/hisilicon/hisi_dmadev.c| 119 +
 drivers/dma/hisilicon/hisi_dmadev.h|  24 +
 drivers/dma/hisilicon/meson.build  |  19 
 drivers/dma/hisilicon/version.map  |   3 +
 drivers/dma/meson.build|   1 +
 9 files changed, 197 insertions(+)
 create mode 100644 doc/guides/dmadevs/hisilicon.rst
 create mode 100644 drivers/dma/hisilicon/hisi_dmadev.c
 create mode 100644 drivers/dma/hisilicon/hisi_dmadev.h
 create mode 100644 drivers/dma/hisilicon/meson.build
 create mode 100644 drivers/dma/hisilicon/version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 0e5951f8f1..1567f7b695 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1206,6 +1206,11 @@ M: Conor Walsh 
 F: drivers/dma/ioat/
 F: doc/guides/dmadevs/ioat.rst
 
+Hisilicon DMA
+M: Chengwen Feng 
+F: drivers/dma/hisilicon
+F: doc/guides/dmadevs/hisilicon.rst
+
 
 RegEx Drivers
 -
diff --git a/doc/guides/dmadevs/hisilicon.rst b/doc/guides/dmadevs/hisilicon.rst
new file mode 100644
index 00..4cbaac4204
--- /dev/null
+++ b/doc/guides/dmadevs/hisilicon.rst
@@ -0,0 +1,21 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2021 HiSilicon Limited.
+
+HISILICON Kunpeng DMA Driver
+
+
+Kunpeng SoC has an internal DMA unit which can be used by application to
+accelerate data copies. The DMA PF function supports multiple DMA channels.
+
+
+Supported Kunpeng SoCs
+--
+
+* Kunpeng 920
+
+
+Device Setup
+-
+
+Kunpeng DMA devices will need to be bound to a suitable DPDK-supported
+user-space IO driver such as ``vfio-pci`` in order to be used by DPDK.
diff --git a/doc/guides/dmadevs/index.rst b/doc/guides/dmadevs/index.rst
index 20476039a5..6b04276524 100644
--- a/doc/guides/dmadevs/index.rst
+++ b/doc/guides/dmadevs/index.rst
@@ -13,3 +13,4 @@ an application through DMA API.
 
idxd
ioat
+   hisilicon
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index 502cc5ceb2..00a45475be 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -86,6 +86,10 @@ New Features
   driver for Intel IOAT devices such as Crystal Beach DMA (CBDMA) on Ice Lake,
   Skylake and Broadwell. This device driver can be used through the generic 
dmadev API.
 
+* **Added hisilicon dmadev driver implementation.**
+  The hisilicon dmadev driver provide device drivers for the Kunpeng's DMA 
devices.
+  This device driver can be used through the generic dmadev API.
+
 * **Added support to get all MAC addresses of a device.**
 
   Added ``rte_eth_macaddrs_get`` to allow user to retrieve all Ethernet
diff --git a/drivers/dma/hisilicon/hisi_dmadev.c 
b/drivers/dma/hisilicon/hisi_dmadev.c
new file mode 100644
index 00..e6fb8a0fc8
--- /dev/null
+++ b/drivers/dma/hisilicon/hisi_dmadev.c
@@ -0,0 +1,119 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2021 HiSilicon Limited
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hisi_dmadev.h"
+
+RTE_LOG_REGISTER_DEFAULT(hisi_dma_logtype, INFO);
+#define HISI_DMA_LOG(level, fmt, args...) \
+   rte_log(RTE_LOG_ ## level, hisi_dma_logtype, \
+   "%s(): " fmt "\n", __func__, ##args)
+#define HISI_DMA_LOG_RAW(hw, level, fmt, args...) \
+   rte_log(RTE_LOG_ ## level, hisi_dma_logtype, \
+   "%s %s(): " fmt "\n", (hw)->data->dev_name, \
+   __func__, ##args)
+#define HISI_DMA_DEBUG(hw, fmt, args...) \
+   HISI_DMA_LOG_RAW(hw, DEBUG, fmt, ## args)
+#define HISI_DMA_INFO(hw, fmt, args...) \
+   HISI_DMA_LOG_RAW(hw, INFO, fmt, ## args)
+#define HISI_DMA_WARN(hw, fmt, args...) \
+   HISI_DMA_LOG_RAW(hw, WARNING, fmt, ## args)
+#define HISI_DMA_ERR(hw, fmt, args...) \
+   HISI_DMA_LOG_RAW(hw, ERR, fmt, ## args)
+
+static uint8_t
+hisi_dma_reg_layout(uint8_t revision)
+{
+   if (revision == HISI_DMA_REVISION_HIP08B)
+   return HISI_DMA_REG_LAYOUT_HIP08;
+   else
+   return HISI_DMA_REG_LAYOUT_INVALID;
+}
+
+static void
+hisi_dma_gen_pci_device_name(const struct rte_pci_device *pci_dev,
+char *name, size_t size)
+{
+   memset(name, 0, size);
+   (void)snprintf(name, size, "%x:%x.%x",
+pci_dev->addr.bus, pci_dev->addr.devid,
+pci_dev->addr.function);
+}
+
+static int
+hisi_dma_check_revision(struct rte_pci_device *pci_dev, const char *name,
+   uint8_t *out_revis

[dpdk-dev] [PATCH v2 5/6] dma/hisilicon: support multi-process

[Chengwen Feng]

This patch add multi-process support for Kunpeng DMA devices.

Signed-off-by: Chengwen Feng 
---
 drivers/dma/hisilicon/hisi_dmadev.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/hisilicon/hisi_dmadev.c 
b/drivers/dma/hisilicon/hisi_dmadev.c
index d03967cae3..05066b4d0e 100644
--- a/drivers/dma/hisilicon/hisi_dmadev.c
+++ b/drivers/dma/hisilicon/hisi_dmadev.c
@@ -392,8 +392,10 @@ hisi_dma_stop(struct rte_dma_dev *dev)
 static int
 hisi_dma_close(struct rte_dma_dev *dev)
 {
-   /* The dmadev already stopped */
-   hisi_dma_free_iomem(dev->data->dev_private);
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   /* The dmadev already stopped */
+   hisi_dma_free_iomem(dev->data->dev_private);
+   }
return 0;
 }
 
@@ -815,11 +817,13 @@ hisi_dma_create(struct rte_pci_device *pci_dev, uint8_t 
queue_id,
hw->cq_head_reg = hisi_dma_queue_regaddr(hw,
 HISI_DMA_QUEUE_CQ_HEAD_REG);
 
-   ret = hisi_dma_reset_hw(hw);
-   if (ret) {
-   HISI_DMA_LOG(ERR, "%s init device fail!", name);
-   (void)rte_dma_pmd_release(name);
-   return -EIO;
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   ret = hisi_dma_reset_hw(hw);
+   if (ret) {
+   HISI_DMA_LOG(ERR, "%s init device fail!", name);
+   (void)rte_dma_pmd_release(name);
+   return -EIO;
+   }
}
 
dev->state = RTE_DMA_DEV_READY;
@@ -872,7 +876,8 @@ hisi_dma_probe(struct rte_pci_driver *pci_drv __rte_unused,
return ret;
HISI_DMA_LOG(DEBUG, "%s read PCI revision: 0x%x", name, revision);
 
-   hisi_dma_init_gbl(pci_dev->mem_resource[2].addr, revision);
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+   hisi_dma_init_gbl(pci_dev->mem_resource[2].addr, revision);
 
for (i = 0; i < HISI_DMA_MAX_HW_QUEUES; i++) {
ret = hisi_dma_create(pci_dev, i, revision);
-- 
2.33.0

[dpdk-dev] [PATCH v2 3/6] dma/hisilicon: add control path functions

[Chengwen Feng]

This patch add control path functions for Kunpeng DMA devices.

Signed-off-by: Chengwen Feng 
---
 doc/guides/dmadevs/hisilicon.rst|  10 +
 drivers/dma/hisilicon/hisi_dmadev.c | 385 
 drivers/dma/hisilicon/hisi_dmadev.h |  99 +++
 3 files changed, 494 insertions(+)

diff --git a/doc/guides/dmadevs/hisilicon.rst b/doc/guides/dmadevs/hisilicon.rst
index 65138a8365..24bae86bdc 100644
--- a/doc/guides/dmadevs/hisilicon.rst
+++ b/doc/guides/dmadevs/hisilicon.rst
@@ -29,3 +29,13 @@ accessed using API from the ``rte_dmadev`` library.
 The name of the ``dmadev`` created is like "B:D.F-chX", e.g. DMA :7b:00.0
 will create four ``dmadev``, the 1st ``dmadev`` name is "7b:00.0-ch0", and the
 2nd ``dmadev`` name is "7b:00.0-ch1".
+
+Device Configuration
+~
+
+Kunpeng DMA configuration requirements:
+
+* ``ring_size`` must be a power of two, between 32 and 8192.
+* Only one ``vchan`` is supported per ``dmadev``.
+* Silent mode is not supported.
+* The transfer direction must be set to ``RTE_DMA_DIR_MEM_TO_MEM``.
diff --git a/drivers/dma/hisilicon/hisi_dmadev.c 
b/drivers/dma/hisilicon/hisi_dmadev.c
index b8369e7e71..bcdcf4de4b 100644
--- a/drivers/dma/hisilicon/hisi_dmadev.c
+++ b/drivers/dma/hisilicon/hisi_dmadev.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -41,6 +43,14 @@ hisi_dma_queue_base(struct hisi_dma_dev *hw)
return 0;
 }
 
+static volatile void *
+hisi_dma_queue_regaddr(struct hisi_dma_dev *hw, uint32_t qoff)
+{
+   uint32_t off = hisi_dma_queue_base(hw) +
+   hw->queue_id * HISI_DMA_QUEUE_REGION_SIZE + qoff;
+   return (volatile void *)((char *)hw->io_base + off);
+}
+
 static void
 hisi_dma_write_reg(void *base, uint32_t off, uint32_t val)
 {
@@ -103,6 +113,15 @@ hisi_dma_update_queue_bit(struct hisi_dma_dev *hw, 
uint32_t qoff, uint32_t pos,
hisi_dma_write_queue(hw, qoff, tmp);
 }
 
+static void
+hisi_dma_update_queue_mbit(struct hisi_dma_dev *hw, uint32_t qoff,
+  uint32_t mask, bool set)
+{
+   uint32_t tmp = hisi_dma_read_queue(hw, qoff);
+   tmp = set ? tmp | mask : tmp & ~mask;
+   hisi_dma_write_queue(hw, qoff, tmp);
+}
+
 #define hisi_dma_poll_hw_state(hw, val, cond, sleep_us, timeout_us) ({ \
uint32_t timeout = 0; \
while (timeout++ <= (timeout_us)) { \
@@ -154,6 +173,45 @@ hisi_dma_reset_hw(struct hisi_dma_dev *hw)
return 0;
 }
 
+static void
+hisi_dma_init_hw(struct hisi_dma_dev *hw)
+{
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_SQ_BASE_L_REG,
+lower_32_bits(hw->sqe_iova));
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_SQ_BASE_H_REG,
+upper_32_bits(hw->sqe_iova));
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_CQ_BASE_L_REG,
+lower_32_bits(hw->cqe_iova));
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_CQ_BASE_H_REG,
+upper_32_bits(hw->cqe_iova));
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_SQ_DEPTH_REG,
+hw->sq_depth_mask);
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_CQ_DEPTH_REG, hw->cq_depth - 1);
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_SQ_TAIL_REG, 0);
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_CQ_HEAD_REG, 0);
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_ERR_INT_NUM0_REG, 0);
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_ERR_INT_NUM1_REG, 0);
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_ERR_INT_NUM2_REG, 0);
+
+   if (hw->reg_layout == HISI_DMA_REG_LAYOUT_HIP08) {
+   hisi_dma_write_queue(hw, HISI_DMA_HIP08_QUEUE_ERR_INT_NUM3_REG,
+0);
+   hisi_dma_write_queue(hw, HISI_DMA_HIP08_QUEUE_ERR_INT_NUM4_REG,
+0);
+   hisi_dma_write_queue(hw, HISI_DMA_HIP08_QUEUE_ERR_INT_NUM5_REG,
+0);
+   hisi_dma_write_queue(hw, HISI_DMA_HIP08_QUEUE_ERR_INT_NUM6_REG,
+0);
+   hisi_dma_update_queue_bit(hw, HISI_DMA_QUEUE_CTRL0_REG,
+   HISI_DMA_HIP08_QUEUE_CTRL0_ERR_ABORT_B, false);
+   hisi_dma_update_queue_mbit(hw, HISI_DMA_QUEUE_INT_STATUS_REG,
+   HISI_DMA_HIP08_QUEUE_INT_MASK_M, true);
+   hisi_dma_update_queue_mbit(hw,
+   HISI_DMA_HIP08_QUEUE_INT_MASK_REG,
+   HISI_DMA_HIP08_QUEUE_INT_MASK_M, true);
+   }
+}
+
 static void
 hisi_dma_init_gbl(void *pci_bar, uint8_t revision)
 {
@@ -176,6 +234,301 @@ hisi_dma_reg_layout(uint8_t revision)
return HISI_DMA_REG_LAYOUT_INVALID;
 }
 
+static void
+hisi_dma_zero_iomem(struct hisi_dma_dev *hw)
+{
+   memset(hw->iomz->addr, 0, hw->iomz_sz);
+}
+
+static int
+hisi_dma_alloc_iomem(struct hisi_dma_dev *hw, uint16

[dpdk-dev] [PATCH v2 4/6] dma/hisilicon: add data path functions

[Chengwen Feng]

This patch add data path functions for Kunpeng DMA devices.

Signed-off-by: Chengwen Feng 
---
 drivers/dma/hisilicon/hisi_dmadev.c | 206 
 drivers/dma/hisilicon/hisi_dmadev.h |  16 +++
 2 files changed, 222 insertions(+)

diff --git a/drivers/dma/hisilicon/hisi_dmadev.c 
b/drivers/dma/hisilicon/hisi_dmadev.c
index bcdcf4de4b..d03967cae3 100644
--- a/drivers/dma/hisilicon/hisi_dmadev.c
+++ b/drivers/dma/hisilicon/hisi_dmadev.c
@@ -529,6 +529,206 @@ hisi_dma_dump(const struct rte_dma_dev *dev, FILE *f)
return 0;
 }
 
+static int
+hisi_dma_copy(void *dev_private, uint16_t vchan,
+rte_iova_t src, rte_iova_t dst,
+uint32_t length, uint64_t flags)
+{
+   struct hisi_dma_dev *hw = dev_private;
+   struct hisi_dma_sqe *sqe = &hw->sqe[hw->sq_tail];
+
+   RTE_SET_USED(vchan);
+
+   if (((hw->sq_tail + 1) & hw->sq_depth_mask) == hw->sq_head)
+   return -ENOSPC;
+
+   sqe->dw0 = rte_cpu_to_le_32(SQE_OPCODE_M2M);
+   sqe->dw1 = 0;
+   sqe->dw2 = 0;
+   sqe->length = rte_cpu_to_le_32(length);
+   sqe->src_addr = rte_cpu_to_le_64(src);
+   sqe->dst_addr = rte_cpu_to_le_64(dst);
+   hw->sq_tail = (hw->sq_tail + 1) & hw->sq_depth_mask;
+   hw->submitted++;
+
+   if (flags & RTE_DMA_OP_FLAG_FENCE)
+   sqe->dw0 |= rte_cpu_to_le_32(SQE_FENCE_FLAG);
+   if (flags & RTE_DMA_OP_FLAG_SUBMIT)
+   rte_write32(rte_cpu_to_le_32(hw->sq_tail), hw->sq_tail_reg);
+
+   return hw->ridx++;
+}
+
+static int
+hisi_dma_submit(void *dev_private, uint16_t vchan)
+{
+   struct hisi_dma_dev *hw = dev_private;
+
+   RTE_SET_USED(vchan);
+   rte_write32(rte_cpu_to_le_32(hw->sq_tail), hw->sq_tail_reg);
+
+   return 0;
+}
+
+static inline void
+hisi_dma_scan_cq(struct hisi_dma_dev *hw)
+{
+   volatile struct hisi_dma_cqe *cqe;
+   uint16_t csq_head = hw->cq_sq_head;
+   uint16_t cq_head = hw->cq_head;
+   uint16_t count = 0;
+   uint64_t misc;
+
+   while (true) {
+   cqe = &hw->cqe[cq_head];
+   misc = cqe->misc;
+   misc = rte_le_to_cpu_64(misc);
+   if (FIELD_GET(CQE_VALID_B, misc) != hw->cqe_vld)
+   break;
+
+   csq_head = FIELD_GET(CQE_SQ_HEAD_MASK, misc);
+   if (unlikely(misc & CQE_STATUS_MASK))
+   hw->status[csq_head] = FIELD_GET(CQE_STATUS_MASK,
+misc);
+
+   count++;
+   cq_head++;
+   if (cq_head == hw->cq_depth) {
+   hw->cqe_vld = !hw->cqe_vld;
+   cq_head = 0;
+   }
+   }
+
+   if (count == 0)
+   return;
+
+   hw->cq_head = cq_head;
+   hw->cq_sq_head = (csq_head + 1) & hw->sq_depth_mask;
+   hw->cqs_completed += count;
+   if (hw->cqs_completed >= HISI_DMA_CQ_RESERVED) {
+   rte_write32(rte_cpu_to_le_32(cq_head), hw->cq_head_reg);
+   hw->cqs_completed = 0;
+   }
+}
+
+static inline uint16_t
+hisi_dma_calc_cpls(struct hisi_dma_dev *hw, const uint16_t nb_cpls)
+{
+   uint16_t cpl_num;
+
+   if (hw->cq_sq_head >= hw->sq_head)
+   cpl_num = hw->cq_sq_head - hw->sq_head;
+   else
+   cpl_num = hw->sq_depth_mask + 1 - hw->sq_head + hw->cq_sq_head;
+
+   if (cpl_num > nb_cpls)
+   cpl_num = nb_cpls;
+
+   return cpl_num;
+}
+
+static uint16_t
+hisi_dma_completed(void *dev_private,
+  uint16_t vchan, const uint16_t nb_cpls,
+  uint16_t *last_idx, bool *has_error)
+{
+   struct hisi_dma_dev *hw = dev_private;
+   uint16_t sq_head = hw->sq_head;
+   uint16_t cpl_num, i;
+
+   RTE_SET_USED(vchan);
+   hisi_dma_scan_cq(hw);
+
+   cpl_num = hisi_dma_calc_cpls(hw, nb_cpls);
+   for (i = 0; i < cpl_num; i++) {
+   if (hw->status[sq_head]) {
+   *has_error = true;
+   break;
+   }
+   sq_head = (sq_head + 1) & hw->sq_depth_mask;
+   }
+   if (i > 0) {
+   hw->cridx += i;
+   *last_idx = hw->cridx - 1;
+   hw->sq_head = sq_head;
+   }
+   hw->completed += i;
+
+   return i;
+}
+
+static enum rte_dma_status_code
+hisi_dma_convert_status(uint16_t status)
+{
+   switch (status) {
+   case HISI_DMA_STATUS_SUCCESS:
+   return RTE_DMA_STATUS_SUCCESSFUL;
+   case HISI_DMA_STATUS_INVALID_OPCODE:
+   return RTE_DMA_STATUS_INVALID_OPCODE;
+   case HISI_DMA_STATUS_INVALID_LENGTH:
+   return RTE_DMA_STATUS_INVALID_LENGTH;
+   case HISI_DMA_STATUS_USER_ABORT:
+   return RTE_DMA_STATUS_USER_ABORT;
+   case HISI_DMA_STATUS_REMOTE_READ_ERROR:
+   case HISI_DMA_STATUS_AXI_READ_ERROR:
+   return RTE_DMA_STATUS_BUS_READ_ER

[dpdk-dev] [PATCH v2 2/6] dma/hisilicon: add dmadev instances create and destroy

[Chengwen Feng]

This patch add dmadev instances create during the PCI probe, and
destroy them during the PCI remove. Internal structures and HW
definitions was also included.

Signed-off-by: Chengwen Feng 
---
 doc/guides/dmadevs/hisilicon.rst|  10 ++
 drivers/dma/hisilicon/hisi_dmadev.c | 212 +++-
 drivers/dma/hisilicon/hisi_dmadev.h |  97 +
 3 files changed, 318 insertions(+), 1 deletion(-)

diff --git a/doc/guides/dmadevs/hisilicon.rst b/doc/guides/dmadevs/hisilicon.rst
index 4cbaac4204..65138a8365 100644
--- a/doc/guides/dmadevs/hisilicon.rst
+++ b/doc/guides/dmadevs/hisilicon.rst
@@ -19,3 +19,13 @@ Device Setup
 
 Kunpeng DMA devices will need to be bound to a suitable DPDK-supported
 user-space IO driver such as ``vfio-pci`` in order to be used by DPDK.
+
+Device Probing and Initialization
+~
+
+Once probed successfully, the device will appear as four ``dmadev`` which can 
be
+accessed using API from the ``rte_dmadev`` library.
+
+The name of the ``dmadev`` created is like "B:D.F-chX", e.g. DMA :7b:00.0
+will create four ``dmadev``, the 1st ``dmadev`` name is "7b:00.0-ch0", and the
+2nd ``dmadev`` name is "7b:00.0-ch1".
diff --git a/drivers/dma/hisilicon/hisi_dmadev.c 
b/drivers/dma/hisilicon/hisi_dmadev.c
index e6fb8a0fc8..b8369e7e71 100644
--- a/drivers/dma/hisilicon/hisi_dmadev.c
+++ b/drivers/dma/hisilicon/hisi_dmadev.c
@@ -6,7 +6,9 @@
 #include 
 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +32,141 @@ RTE_LOG_REGISTER_DEFAULT(hisi_dma_logtype, INFO);
 #define HISI_DMA_ERR(hw, fmt, args...) \
HISI_DMA_LOG_RAW(hw, ERR, fmt, ## args)
 
+static uint32_t
+hisi_dma_queue_base(struct hisi_dma_dev *hw)
+{
+   if (hw->reg_layout == HISI_DMA_REG_LAYOUT_HIP08)
+   return HISI_DMA_HIP08_QUEUE_BASE;
+   else
+   return 0;
+}
+
+static void
+hisi_dma_write_reg(void *base, uint32_t off, uint32_t val)
+{
+   rte_write32(rte_cpu_to_le_32(val),
+   (volatile void *)((char *)base + off));
+}
+
+static void
+hisi_dma_write_dev(struct hisi_dma_dev *hw, uint32_t off, uint32_t val)
+{
+   hisi_dma_write_reg(hw->io_base, off, val);
+}
+
+static void
+hisi_dma_write_queue(struct hisi_dma_dev *hw, uint32_t qoff, uint32_t val)
+{
+   uint32_t off = hisi_dma_queue_base(hw) +
+   hw->queue_id * HISI_DMA_QUEUE_REGION_SIZE + qoff;
+   hisi_dma_write_dev(hw, off, val);
+}
+
+static uint32_t
+hisi_dma_read_reg(void *base, uint32_t off)
+{
+   uint32_t val = rte_read32((volatile void *)((char *)base + off));
+   return rte_le_to_cpu_32(val);
+}
+
+static uint32_t
+hisi_dma_read_dev(struct hisi_dma_dev *hw, uint32_t off)
+{
+   return hisi_dma_read_reg(hw->io_base, off);
+}
+
+static uint32_t
+hisi_dma_read_queue(struct hisi_dma_dev *hw, uint32_t qoff)
+{
+   uint32_t off = hisi_dma_queue_base(hw) +
+   hw->queue_id * HISI_DMA_QUEUE_REGION_SIZE + qoff;
+   return hisi_dma_read_dev(hw, off);
+}
+
+static void
+hisi_dma_update_bit(struct hisi_dma_dev *hw, uint32_t off, uint32_t pos,
+   bool set)
+{
+   uint32_t tmp = hisi_dma_read_dev(hw, off);
+   uint32_t mask = 1u << pos;
+   tmp = set ? tmp | mask : tmp & ~mask;
+   hisi_dma_write_dev(hw, off, tmp);
+}
+
+static void
+hisi_dma_update_queue_bit(struct hisi_dma_dev *hw, uint32_t qoff, uint32_t pos,
+ bool set)
+{
+   uint32_t tmp = hisi_dma_read_queue(hw, qoff);
+   uint32_t mask = 1u << pos;
+   tmp = set ? tmp | mask : tmp & ~mask;
+   hisi_dma_write_queue(hw, qoff, tmp);
+}
+
+#define hisi_dma_poll_hw_state(hw, val, cond, sleep_us, timeout_us) ({ \
+   uint32_t timeout = 0; \
+   while (timeout++ <= (timeout_us)) { \
+   (val) = hisi_dma_read_queue(hw, HISI_DMA_QUEUE_FSM_REG); \
+   if (cond) \
+   break; \
+   rte_delay_us(sleep_us); \
+   } \
+   (cond) ? 0 : -ETIME; \
+})
+
+static int
+hisi_dma_reset_hw(struct hisi_dma_dev *hw)
+{
+#define POLL_SLEEP_US  100
+#define POLL_TIMEOUT_US1
+
+   uint32_t tmp;
+   int ret;
+
+   hisi_dma_update_queue_bit(hw, HISI_DMA_QUEUE_CTRL0_REG,
+ HISI_DMA_QUEUE_CTRL0_PAUSE_B, true);
+   hisi_dma_update_queue_bit(hw, HISI_DMA_QUEUE_CTRL0_REG,
+ HISI_DMA_QUEUE_CTRL0_EN_B, false);
+
+   ret = hisi_dma_poll_hw_state(hw, tmp,
+   FIELD_GET(HISI_DMA_QUEUE_FSM_STS_M, tmp) != HISI_DMA_STATE_RUN,
+   POLL_SLEEP_US, POLL_TIMEOUT_US);
+   if (ret) {
+   HISI_DMA_ERR(hw, "disable dma timeout!");
+   return ret;
+   }
+
+   hisi_dma_update_queue_bit(hw, HISI_DMA_QUEUE_CTRL1_REG,
+ HISI_DMA_QUEUE_CTRL1_RESET_B, true);
+   hisi_dma_write_queue(hw, HISI_DMA_QUEUE_SQ_TAIL_REG, 0);
+   

[dpdk-dev] [PATCH v2 6/6] devbind: add Kunpeng DMA to dmadev category

[Chengwen Feng]

add Kunpeng DMA device ID to dmadev category.

Signed-off-by: Chengwen Feng 
---
 usertools/dpdk-devbind.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index bb00f43702..a74a68ed82 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -68,10 +68,14 @@
 intel_ntb_icx = {'Class': '06', 'Vendor': '8086', 'Device': '347e',
  'SVendor': None, 'SDevice': None}
 
+hisilicon_dma = {'Class': '08', 'Vendor': '19e5', 'Device': 'a122',
+ 'SVendor': None, 'SDevice': None}
+
 network_devices = [network_class, cavium_pkx, avp_vnic, ifpga_class]
 baseband_devices = [acceleration_class]
 crypto_devices = [encryption_class, intel_processor_class]
-dma_devices = [intel_idxd_spr, intel_ioat_bdw, intel_ioat_icx, intel_ioat_skx]
+dma_devices = [intel_idxd_spr, intel_ioat_bdw, intel_ioat_icx, intel_ioat_skx,
+   hisilicon_dma]
 eventdev_devices = [cavium_sso, cavium_tim, intel_dlb, octeontx2_sso]
 mempool_devices = [cavium_fpa, octeontx2_npa]
 compress_devices = [cavium_zip]
-- 
2.33.0

[dpdk-dev] [PATCH] doc: cleanup flow mark Rx offload deprecation notice

[Andrew Rybchenko]

The problem is solved using Rx metadata delivery negotiation API [1].

[1] commit f6d8a6d3fad7 ("ethdev: negotiate delivery of packet metadata from HW 
to PMD")

Signed-off-by: Andrew Rybchenko 
---
 doc/guides/rel_notes/deprecation.rst | 8 
 1 file changed, 8 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 4366015b01..ec5073908f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -69,14 +69,6 @@ Deprecation Notices
   and the related structures (``rte_fdir_*`` and ``rte_eth_fdir_*``),
   will be removed in DPDK 20.11.
 
-* ethdev: New offload flags ``RTE_ETH_RX_OFFLOAD_FLOW_MARK`` will be added in 
19.11.
-  This will allow application to enable or disable PMDs from updating
-  ``rte_mbuf::hash::fdir``.
-  This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx and
-  thereby improve Rx performance if application wishes do so.
-  In 19.11 PMDs will still update the field even when the offload is not
-  enabled.
-
 * ethdev: Announce moving from dedicated modify function for each field,
   to using the general ``rte_flow_modify_field`` action.
 
-- 
2.30.2

[dpdk-dev] [PATCH] net/sfc: merge Rx and Tx doorbell counters into one

[Andrew Rybchenko]

Datapath queue is either Rx or Tx, so just one counter is sufficient
for doorbells. It can count Tx doorbells in the case of Tx queue and
Rx doorbells in the case of Rx queue.

Signed-off-by: Andrew Rybchenko 
---
 drivers/net/sfc/sfc_dp.h   | 3 +--
 drivers/net/sfc/sfc_ef100_rx.c | 2 +-
 drivers/net/sfc/sfc_ef100_tx.c | 2 +-
 drivers/net/sfc/sfc_ef10_essb_rx.c | 2 +-
 drivers/net/sfc/sfc_ef10_rx.c  | 3 +--
 drivers/net/sfc/sfc_ef10_tx.c  | 2 +-
 drivers/net/sfc/sfc_rx.c   | 2 +-
 drivers/net/sfc/sfc_sw_stats.c | 4 ++--
 drivers/net/sfc/sfc_tx.c   | 2 +-
 9 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/net/sfc/sfc_dp.h b/drivers/net/sfc/sfc_dp.h
index 994116e480..c302a5cc13 100644
--- a/drivers/net/sfc/sfc_dp.h
+++ b/drivers/net/sfc/sfc_dp.h
@@ -51,8 +51,7 @@ struct sfc_dp_queue {
 * used on datapath or reap to have more chances to be cache-hot.
 */
union sfc_pkts_bytesstats;
-   uint32_trx_dbells;
-   uint32_ttx_dbells;
+   uint32_tdbells;
 
uint16_tport_id;
uint16_tqueue_id;
diff --git a/drivers/net/sfc/sfc_ef100_rx.c b/drivers/net/sfc/sfc_ef100_rx.c
index 83f5c1ec70..259290f14a 100644
--- a/drivers/net/sfc/sfc_ef100_rx.c
+++ b/drivers/net/sfc/sfc_ef100_rx.c
@@ -124,7 +124,7 @@ sfc_ef100_rx_qpush(struct sfc_ef100_rxq *rxq, unsigned int 
added)
 * operations that follow it (i.e. doorbell write).
 */
rte_write32(dword.ed_u32[0], rxq->doorbell);
-   rxq->dp.dpq.rx_dbells++;
+   rxq->dp.dpq.dbells++;
 
sfc_ef100_rx_debug(rxq, "RxQ pushed doorbell at pidx %u (added=%u)",
   EFX_DWORD_FIELD(dword, ERF_GZ_RX_RING_PIDX),
diff --git a/drivers/net/sfc/sfc_ef100_tx.c b/drivers/net/sfc/sfc_ef100_tx.c
index c0944df166..b41eddbcca 100644
--- a/drivers/net/sfc/sfc_ef100_tx.c
+++ b/drivers/net/sfc/sfc_ef100_tx.c
@@ -503,7 +503,7 @@ sfc_ef100_tx_qpush(struct sfc_ef100_txq *txq, unsigned int 
added)
 * operations that follow it (i.e. doorbell write).
 */
rte_write32(dword.ed_u32[0], txq->doorbell);
-   txq->dp.dpq.tx_dbells++;
+   txq->dp.dpq.dbells++;
 
sfc_ef100_tx_debug(txq, "TxQ pushed doorbell at pidx %u (added=%u)",
   EFX_DWORD_FIELD(dword, ERF_GZ_TX_RING_PIDX),
diff --git a/drivers/net/sfc/sfc_ef10_essb_rx.c 
b/drivers/net/sfc/sfc_ef10_essb_rx.c
index 67db837afd..4f7d712297 100644
--- a/drivers/net/sfc/sfc_ef10_essb_rx.c
+++ b/drivers/net/sfc/sfc_ef10_essb_rx.c
@@ -221,7 +221,7 @@ sfc_ef10_essb_rx_qrefill(struct sfc_ef10_essb_rxq *rxq)
SFC_ASSERT(rxq->added != added);
rxq->added = added;
sfc_ef10_rx_qpush(rxq->doorbell, added, rxq_ptr_mask,
- &rxq->dp.dpq.rx_dbells);
+ &rxq->dp.dpq.dbells);
 }
 
 static bool
diff --git a/drivers/net/sfc/sfc_ef10_rx.c b/drivers/net/sfc/sfc_ef10_rx.c
index 245f616bc2..8503c3c15f 100644
--- a/drivers/net/sfc/sfc_ef10_rx.c
+++ b/drivers/net/sfc/sfc_ef10_rx.c
@@ -171,8 +171,7 @@ sfc_ef10_rx_qrefill(struct sfc_ef10_rxq *rxq)
 
SFC_ASSERT(rxq->added != added);
rxq->added = added;
-   sfc_ef10_rx_qpush(rxq->doorbell, added, ptr_mask,
- &rxq->dp.dpq.rx_dbells);
+   sfc_ef10_rx_qpush(rxq->doorbell, added, ptr_mask, &rxq->dp.dpq.dbells);
 }
 
 static void
diff --git a/drivers/net/sfc/sfc_ef10_tx.c b/drivers/net/sfc/sfc_ef10_tx.c
index fc829a6f31..2463c1423a 100644
--- a/drivers/net/sfc/sfc_ef10_tx.c
+++ b/drivers/net/sfc/sfc_ef10_tx.c
@@ -248,7 +248,7 @@ sfc_ef10_tx_qpush(struct sfc_ef10_txq *txq, unsigned int 
added,
rte_io_wmb();
 
*(volatile efsys_uint128_t *)txq->doorbell = oword.eo_u128[0];
-   txq->dp.dpq.tx_dbells++;
+   txq->dp.dpq.dbells++;
 }
 
 static unsigned int
diff --git a/drivers/net/sfc/sfc_rx.c b/drivers/net/sfc/sfc_rx.c
index e2be84b275..17ff2aa67a 100644
--- a/drivers/net/sfc/sfc_rx.c
+++ b/drivers/net/sfc/sfc_rx.c
@@ -139,7 +139,7 @@ sfc_efx_rx_qrefill(struct sfc_efx_rxq *rxq)
SFC_ASSERT(added != rxq->added);
rxq->added = added;
efx_rx_qpush(rxq->common, added, &rxq->pushed);
-   rxq->dp.dpq.rx_dbells++;
+   rxq->dp.dpq.dbells++;
 }
 
 static uint64_t
diff --git a/drivers/net/sfc/sfc_sw_stats.c b/drivers/net/sfc/sfc_sw_stats.c
index 6b3a01b3c6..70259660c0 100644
--- a/drivers/net/sfc/sfc_sw_stats.c
+++ b/drivers/net/sfc/sfc_sw_stats.c
@@ -95,7 +95,7 @@ sfc_get_sw_stat_val_rx_dbells(struct sfc_adapter *sa, 
uint16_t qid,
SFC_ASSERT(values_count == 1);
rxq_info = sfc_rxq_info_by_ethdev_qid(sas, qid);
values[0] = rxq_info->state & SFC_RXQ_INITIALIZED ?
-   rxq_info->dp->dpq.rx_dbells : 0;
+   rxq_info->dp->dpq.dbells : 0;
 }
 
 static sfc_get_sw_stat_val_t sfc_get_sw_stat_

Re: [dpdk-dev] [PATCH v19 1/5] sched: add PIE based congestion management

[Liguzinski, WojciechX]

Sure, I will correct the name.
As I can see from a distance that some things could be resolved/corrected from 
the very beginning (like e.g. the name and its format).


-Original Message-
From: Thomas Monjalon  
Sent: Friday, October 29, 2021 3:44 PM
To: Liguzinski, WojciechX 
Cc: dev@dpdk.org; Singh, Jasvinder ; Dumitrescu, 
Cristian ; Ajmera, Megha 
; Mcnamara, John ; Yigit, 
Ferruh ; Richardson, Bruce 
Subject: Re: [dpdk-dev] [PATCH v19 1/5] sched: add PIE based congestion 
management

28/10/2021 12:17, Liguzinski, WojciechX:
> Implement PIE based congestion management based on rfc8033
> 
> Signed-off-by: Liguzinski, WojciechX 
> Acked-by: Cristian Dumitrescu 
> Acked-by: Jasvinder Singh 
> 
> --
> Changes in V19:
> - ACKs included in patches

Would be good to fix your own name as well.
I guess your first name is not WojciechX but Wojciech.
And we put first name first without a comma.

Also the related doc change should be in this patch.

It's OK that you don't have all knowledge of the process, I am just 
disappointed that you don't get more help from those adding your acks, so it 
falls on me to fix.

Re: [dpdk-dev] [PATCH] net/txgbe: fix link macro

[Ferruh Yigit]

On 11/2/2021 1:51 AM, Jiawen Wu wrote:

On November 1, 2021 9:20 PM, Ferruh Yigit wrote:

Macro is changed unintentionally while adding RTE_ prefix, fixing the

original

value.

Fixes: 295968d17407 ("ethdev: add namespace")

Signed-off-by: Ferruh Yigit 


Acked-by: Jiawen Wu 



Applied to dpdk-next-net/main, thanks.

Re: [dpdk-dev] [PATCH v2] ethdev: fix deprecation notice for shared Rx queue

[Ferruh Yigit]

On 11/2/2021 11:42 AM, Xueming Li wrote:

Shared Rx queue feature has been supported, remove deprecation notice.

Fixes: dd22740cc291 ("ethdev: introduce shared Rx queue")

Signed-off-by: Xueming Li 


Reviewed-by: Ferruh Yigit 

Applied to dpdk-next-net/main, thanks.

Re: [dpdk-dev] [PATCH] doc: cleanup flow mark Rx offload deprecation notice

[Ferruh Yigit]

On 11/2/2021 12:50 PM, Andrew Rybchenko wrote:

The problem is solved using Rx metadata delivery negotiation API [1].



Can this API replace RX_OFFLOAD_RSS_HASH too?


[1] commit f6d8a6d3fad7 ("ethdev: negotiate delivery of packet metadata from HW to 
PMD")

Signed-off-by: Andrew Rybchenko 
---
  doc/guides/rel_notes/deprecation.rst | 8 
  1 file changed, 8 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 4366015b01..ec5073908f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -69,14 +69,6 @@ Deprecation Notices
and the related structures (``rte_fdir_*`` and ``rte_eth_fdir_*``),
will be removed in DPDK 20.11.
  
-* ethdev: New offload flags ``RTE_ETH_RX_OFFLOAD_FLOW_MARK`` will be added in 19.11.

-  This will allow application to enable or disable PMDs from updating
-  ``rte_mbuf::hash::fdir``.
-  This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx and
-  thereby improve Rx performance if application wishes do so.
-  In 19.11 PMDs will still update the field even when the offload is not
-  enabled.
-
  * ethdev: Announce moving from dedicated modify function for each field,
to using the general ``rte_flow_modify_field`` action.
  

[dpdk-dev] [dpdk-dev v3 2/8] crypto/qat: qat driver sym op refactor

[Kai Ji]

This patch add-in refactored qat symmetirc build request function
implementation (qat_sym_refactor.c & qat_sym_refactor.h)
Add-in QAT sym build ops in auth, cipher, chain and aead operation for
QAT generation 1

Signed-off-by: Kai Ji 
---
 drivers/crypto/qat/dev/qat_crypto_pmd_gens.h | 1071 ++
 drivers/crypto/qat/dev/qat_sym_pmd_gen1.c|  895 +++
 drivers/crypto/qat/qat_sym.h |8 +
 drivers/crypto/qat/qat_sym_hw_dp.c   |8 -
 drivers/crypto/qat/qat_sym_refactor.c|  409 +++
 drivers/crypto/qat/qat_sym_refactor.h|  402 +++
 6 files changed, 2785 insertions(+), 8 deletions(-)
 create mode 100644 drivers/crypto/qat/qat_sym_refactor.c
 create mode 100644 drivers/crypto/qat/qat_sym_refactor.h

diff --git a/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h 
b/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
index 67a4d2cb2c..07020741bd 100644
--- a/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
+++ b/drivers/crypto/qat/dev/qat_crypto_pmd_gens.h
@@ -8,14 +8,1082 @@
 #include 
 #include "qat_crypto.h"
 #include "qat_sym_session.h"
+#include "qat_sym.h"
+
+#define QAT_BASE_GEN1_SYM_CAPABILITIES \
+   QAT_SYM_PLAIN_AUTH_CAP(SHA1, CAP_SET(block_size, 64), \
+   CAP_RNG(digest_size, 1, 20, 1)), \
+   QAT_SYM_AEAD_CAP(AES_GCM, CAP_SET(block_size, 16), \
+   CAP_RNG(key_size, 16, 32, 8), CAP_RNG(digest_size, 8, 16, 4), \
+   CAP_RNG(aad_size, 0, 240, 1), CAP_RNG(iv_size, 0, 12, 12)), \
+   QAT_SYM_AEAD_CAP(AES_CCM,  CAP_SET(block_size, 16), \
+   CAP_RNG(key_size, 16, 16, 0), CAP_RNG(digest_size, 4, 16, 2), \
+   CAP_RNG(aad_size, 0, 224, 1), CAP_RNG(iv_size, 7, 13, 1)), \
+   QAT_SYM_AUTH_CAP(AES_GMAC, CAP_SET(block_size, 16), \
+   CAP_RNG(key_size, 16, 32, 8), CAP_RNG(digest_size, 8, 16, 4), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG(iv_size, 0, 12, 12)), \
+   QAT_SYM_AUTH_CAP(AES_CMAC, CAP_SET(block_size, 16), \
+   CAP_RNG(key_size, 16, 16, 0), CAP_RNG(digest_size, 4, 16, 4), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(SHA224, CAP_SET(block_size, 64), \
+   CAP_RNG_ZERO(key_size), CAP_RNG(digest_size, 1, 28, 1), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(SHA256, CAP_SET(block_size, 64), \
+   CAP_RNG_ZERO(key_size), CAP_RNG(digest_size, 1, 32, 1), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(SHA384, CAP_SET(block_size, 128), \
+   CAP_RNG_ZERO(key_size), CAP_RNG(digest_size, 1, 48, 1), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(SHA512, CAP_SET(block_size, 128), \
+   CAP_RNG_ZERO(key_size), CAP_RNG(digest_size, 1, 64, 1), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(SHA1_HMAC, CAP_SET(block_size, 64), \
+   CAP_RNG(key_size, 1, 64, 1), CAP_RNG(digest_size, 1, 20, 1), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(SHA224_HMAC, CAP_SET(block_size, 64), \
+   CAP_RNG(key_size, 1, 64, 1), CAP_RNG(digest_size, 1, 28, 1), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(SHA256_HMAC, CAP_SET(block_size, 64), \
+   CAP_RNG(key_size, 1, 64, 1), CAP_RNG(digest_size, 1, 32, 1), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(SHA384_HMAC, CAP_SET(block_size, 128), \
+   CAP_RNG(key_size, 1, 128, 1), CAP_RNG(digest_size, 1, 48, 1), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(SHA512_HMAC, CAP_SET(block_size, 128), \
+   CAP_RNG(key_size, 1, 128, 1), CAP_RNG(digest_size, 1, 64, 1), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(MD5_HMAC, CAP_SET(block_size, 64), \
+   CAP_RNG(key_size, 1, 64, 1), CAP_RNG(digest_size, 1, 16, 1), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(AES_XCBC_MAC, CAP_SET(block_size, 16), \
+   CAP_RNG(key_size, 16, 16, 0), CAP_RNG(digest_size, 12, 12, 0), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(SNOW3G_UIA2, CAP_SET(block_size, 16), \
+   CAP_RNG(key_size, 16, 16, 0), CAP_RNG(digest_size, 4, 4, 0), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG(iv_size, 16, 16, 0)), \
+   QAT_SYM_AUTH_CAP(KASUMI_F9, CAP_SET(block_size, 8), \
+   CAP_RNG(key_size, 16, 16, 0), CAP_RNG(digest_size, 4, 4, 0), \
+   CAP_RNG_ZERO(aad_size), CAP_RNG_ZERO(iv_size)), \
+   QAT_SYM_AUTH_CAP(NULL, CAP_SET(block_size, 1), \
+   CAP_RNG_ZERO(key_size), CAP_RNG_ZERO(digest_size), \
+  

[dpdk-dev] [dpdk-dev v3 0/8] drivers/qat: QAT symmetric crypto datapatch rework

[Kai Ji]

This patch reworks QAT symmetric crypto datapatch implementation where each
generation request building separated and the crypto operation under the
raw datapath api implementation are unified.

In addtion this patchset also enables QAT OOP support in raw datapath api
implementation.

This patch depends on 
http://patchwork.dpdk.org/project/dpdk/cover/20211027155055.32264-1-kai...@intel.com/

v3:
- sperate a single patch 6 to two different patches

v2:
- review comments addressed

Kai Ji (8):
  crypro/qat: qat driver refactor skeleton
  crypto/qat: qat driver sym op refactor
  crypto/qat: qat driver asym op refactor
  crypto/qat: qat driver session method rework
  crypto/qat: qat driver datapath rework
  crypto/qat: support sgl oop operation
  app/test: cryptodev test fix
  crypto/qat: qat driver rework clean up

 app/test/test_cryptodev.c|  58 +-
 drivers/common/qat/meson.build   |   4 +-
 drivers/common/qat/qat_device.c  |   2 +-
 drivers/common/qat/qat_qp.c  |  40 +-
 drivers/common/qat/qat_qp.h  |  70 +-
 drivers/compress/qat/qat_comp_pmd.c  |  12 +-
 drivers/crypto/qat/dev/qat_asym_pmd_gen1.c   |   7 +
 drivers/crypto/qat/dev/qat_crypto_pmd_gen2.c |  90 ++
 drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c | 487 +
 drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c | 253 +
 drivers/crypto/qat/dev/qat_crypto_pmd_gens.h | 911 +
 drivers/crypto/qat/dev/qat_sym_pmd_gen1.c| 939 ++
 drivers/crypto/qat/qat_asym.c| 786 +--
 drivers/crypto/qat/qat_asym.h|  77 +-
 drivers/crypto/qat/qat_asym_pmd.c| 231 -
 drivers/crypto/qat/qat_asym_pmd.h|  54 -
 drivers/crypto/qat/qat_crypto.c  |   1 +
 drivers/crypto/qat/qat_crypto.h  |  14 +-
 drivers/crypto/qat/qat_sym.c | 978 ++
 drivers/crypto/qat/qat_sym.h | 141 ++-
 drivers/crypto/qat/qat_sym_hw_dp.c   | 983 ---
 drivers/crypto/qat/qat_sym_pmd.c | 251 -
 drivers/crypto/qat/qat_sym_pmd.h |  95 --
 drivers/crypto/qat/qat_sym_session.c | 114 +--
 drivers/crypto/qat/qat_sym_session.h |   8 +-
 25 files changed, 3861 insertions(+), 2745 deletions(-)
 delete mode 100644 drivers/crypto/qat/qat_asym_pmd.c
 delete mode 100644 drivers/crypto/qat/qat_asym_pmd.h
 delete mode 100644 drivers/crypto/qat/qat_sym_hw_dp.c
 delete mode 100644 drivers/crypto/qat/qat_sym_pmd.c
 delete mode 100644 drivers/crypto/qat/qat_sym_pmd.h

-- 
2.17.1

[dpdk-dev] [dpdk-dev v3 1/8] crypro/qat: qat driver refactor skeleton

[Kai Ji]

Add-in enqueue/dequeue op burst and build-request skeleton functions
for qat crypto driver refactor.

Signed-off-by: Kai Ji 
---
 drivers/common/qat/qat_qp.c  | 16 +
 drivers/common/qat/qat_qp.h  | 54 
 drivers/crypto/qat/qat_asym.c| 43 ++
 drivers/crypto/qat/qat_asym.h| 15 
 drivers/crypto/qat/qat_sym.c | 37 +++
 drivers/crypto/qat/qat_sym.h | 16 +
 drivers/crypto/qat/qat_sym_session.h |  6 
 7 files changed, 187 insertions(+)

diff --git a/drivers/common/qat/qat_qp.c b/drivers/common/qat/qat_qp.c
index cde421eb77..0fda890075 100644
--- a/drivers/common/qat/qat_qp.c
+++ b/drivers/common/qat/qat_qp.c
@@ -549,6 +549,22 @@ adf_modulo(uint32_t data, uint32_t modulo_mask)
return data & modulo_mask;
 }
 
+uint16_t
+refactor_qat_enqueue_op_burst(__rte_unused void *qp,
+   __rte_unused qat_op_build_request_t op_build_request,
+   __rte_unused void **ops, __rte_unused uint16_t nb_ops)
+{
+   return 0;
+}
+
+uint16_t
+refactor_qat_dequeue_op_burst(__rte_unused void *qp, __rte_unused void **ops,
+   __rte_unused qat_op_dequeue_t qat_dequeue_process_response,
+   __rte_unused uint16_t nb_ops)
+{
+   return 0;
+}
+
 uint16_t
 qat_enqueue_op_burst(void *qp, void **ops, uint16_t nb_ops)
 {
diff --git a/drivers/common/qat/qat_qp.h b/drivers/common/qat/qat_qp.h
index deafb407b3..b1350cdaf4 100644
--- a/drivers/common/qat/qat_qp.h
+++ b/drivers/common/qat/qat_qp.h
@@ -36,6 +36,51 @@ struct qat_queue {
/* number of responses processed since last CSR head write */
 };
 
+/**
+ * Type define qat_op_build_request_t function pointer, passed in as argument
+ * in enqueue op burst, where a build request assigned base on the type of
+ * crypto op.
+ *
+ * @param in_op
+ *An input op pointer
+ * @param out_msg
+ *out_meg pointer
+ * @param op_cookie
+ *op cookie pointer
+ * @param opaque
+ *an opaque data may be used to store context may be useful between
+ *2 enqueue operations.
+ * @param dev_gen
+ *qat device gen id
+ * @return
+ *   - 0 if the crypto request is build successfully,
+ *   - error code otherwise
+ **/
+typedef int (*qat_op_build_request_t)(void *in_op, uint8_t *out_msg,
+   void *op_cookie, uint64_t *opaque, enum qat_device_gen dev_gen);
+
+/**
+ * Type define qat_op_dequeue_t function pointer, passed in as argument
+ * in dequeue op burst, where a dequeue op assigned base on the type of
+ * crypto op.
+ *
+ * @param op
+ *An input op pointer
+ * @param resp
+ *qat response msg pointer
+ * @param op_cookie
+ *op cookie pointer
+ * @param dequeue_err_count
+ *dequeue error counter
+ * @return
+ *- 0 if dequeue OP is successful
+ *- error code otherwise
+ **/
+typedef int (*qat_op_dequeue_t)(void **op, uint8_t *resp, void *op_cookie,
+   uint64_t *dequeue_err_count __rte_unused);
+
+#define QAT_BUILD_REQUEST_MAX_OPAQUE_SIZE  2
+
 struct qat_qp {
void*mmap_bar_addr;
struct qat_queuetx_q;
@@ -44,6 +89,7 @@ struct qat_qp {
struct rte_mempool *op_cookie_pool;
void **op_cookies;
uint32_t nb_descriptors;
+   uint64_t opaque[QAT_BUILD_REQUEST_MAX_OPAQUE_SIZE];
enum qat_device_gen qat_dev_gen;
enum qat_service_type service_type;
struct qat_pci_device *qat_dev;
@@ -77,6 +123,14 @@ struct qat_qp_config {
const char *service_str;
 };
 
+uint16_t
+refactor_qat_enqueue_op_burst(void *qp, qat_op_build_request_t 
op_build_request,
+   void **ops, uint16_t nb_ops);
+
+uint16_t
+refactor_qat_dequeue_op_burst(void *qp, void **ops,
+   qat_op_dequeue_t qat_dequeue_process_response, uint16_t nb_ops);
+
 uint16_t
 qat_enqueue_op_burst(void *qp, void **ops, uint16_t nb_ops);
 
diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
index 85973812a8..c3bbdb6eb8 100644
--- a/drivers/crypto/qat/qat_asym.c
+++ b/drivers/crypto/qat/qat_asym.c
@@ -456,6 +456,49 @@ qat_asym_fill_arrays(struct rte_crypto_asym_op *asym_op,
return 0;
 }
 
+/*
+ * Asym build request refactor function template,
+ * will be removed in the later patchset.
+ */
+static __rte_always_inline int
+refactor_qat_asym_build_request(__rte_unused void *in_op,
+   __rte_unused uint8_t *out_msg, __rte_unused void *op_cookie,
+   __rte_unused uint64_t *opaque,
+   __rte_unused enum qat_device_gen dev_gen)
+{
+   return 0;
+}
+
+/*
+ * Asym process response refactor function template,
+ * will be removed in the later patchset.
+ */
+int
+refactor_qat_asym_process_response(__rte_unused void **op,
+   __rte_unused uint8_t *resp,
+   __rte_unused void *op_cookie,
+   __rte_unused uint64_t *dequeue_err_count)
+{
+   return 0;
+}
+
+uint16_t
+qat_asym_crypto_enqueue_op_burs

[dpdk-dev] [dpdk-dev v3 3/8] crypto/qat: qat driver asym op refactor

[Kai Ji]

This patch add-in refactored qat asymmetric build request
function implementation (qat_asym_refactor.c & qat_asym_refactor.h)

Signed-off-by: Kai Ji 
---
 drivers/crypto/qat/dev/qat_asym_pmd_gen1.c |   7 +
 drivers/crypto/qat/qat_asym_refactor.c | 994 +
 drivers/crypto/qat/qat_asym_refactor.h | 125 +++
 3 files changed, 1126 insertions(+)
 create mode 100644 drivers/crypto/qat/qat_asym_refactor.c
 create mode 100644 drivers/crypto/qat/qat_asym_refactor.h

diff --git a/drivers/crypto/qat/dev/qat_asym_pmd_gen1.c 
b/drivers/crypto/qat/dev/qat_asym_pmd_gen1.c
index 9ed1f21d9d..99d90fa56c 100644
--- a/drivers/crypto/qat/dev/qat_asym_pmd_gen1.c
+++ b/drivers/crypto/qat/dev/qat_asym_pmd_gen1.c
@@ -65,6 +65,13 @@ qat_asym_crypto_feature_flags_get_gen1(
return feature_flags;
 }
 
+int
+qat_asym_crypto_set_session_gen1(void *cdev __rte_unused,
+   void *session __rte_unused)
+{
+   return 0;
+}
+
 RTE_INIT(qat_asym_crypto_gen1_init)
 {
qat_asym_gen_dev_ops[QAT_GEN1].cryptodev_ops =
diff --git a/drivers/crypto/qat/qat_asym_refactor.c 
b/drivers/crypto/qat/qat_asym_refactor.c
new file mode 100644
index 00..8e789920cb
--- /dev/null
+++ b/drivers/crypto/qat/qat_asym_refactor.c
@@ -0,0 +1,994 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 - 2021 Intel Corporation
+ */
+
+
+#include 
+
+#include 
+
+#include "icp_qat_fw_pke.h"
+#include "icp_qat_fw.h"
+#include "qat_pke_functionality_arrays.h"
+
+#include "qat_device.h"
+
+#include "qat_logs.h"
+#include "qat_asym.h"
+
+uint8_t qat_asym_driver_id;
+
+struct qat_crypto_gen_dev_ops qat_asym_gen_dev_ops[QAT_N_GENS];
+
+void
+qat_asym_init_op_cookie(void *op_cookie)
+{
+   int j;
+   struct qat_asym_op_cookie *cookie = op_cookie;
+
+   cookie->input_addr = rte_mempool_virt2iova(cookie) +
+   offsetof(struct qat_asym_op_cookie,
+   input_params_ptrs);
+
+   cookie->output_addr = rte_mempool_virt2iova(cookie) +
+   offsetof(struct qat_asym_op_cookie,
+   output_params_ptrs);
+
+   for (j = 0; j < 8; j++) {
+   cookie->input_params_ptrs[j] =
+   rte_mempool_virt2iova(cookie) +
+   offsetof(struct qat_asym_op_cookie,
+   input_array[j]);
+   cookie->output_params_ptrs[j] =
+   rte_mempool_virt2iova(cookie) +
+   offsetof(struct qat_asym_op_cookie,
+   output_array[j]);
+   }
+}
+
+int
+qat_asym_session_configure(struct rte_cryptodev *dev,
+   struct rte_crypto_asym_xform *xform,
+   struct rte_cryptodev_asym_session *sess,
+   struct rte_mempool *mempool)
+{
+   int err = 0;
+   void *sess_private_data;
+   struct qat_asym_session *session;
+
+   if (rte_mempool_get(mempool, &sess_private_data)) {
+   QAT_LOG(ERR,
+   "Couldn't get object from session mempool");
+   return -ENOMEM;
+   }
+
+   session = sess_private_data;
+   if (xform->xform_type == RTE_CRYPTO_ASYM_XFORM_MODEX) {
+   if (xform->modex.exponent.length == 0 ||
+   xform->modex.modulus.length == 0) {
+   QAT_LOG(ERR, "Invalid mod exp input parameter");
+   err = -EINVAL;
+   goto error;
+   }
+   } else if (xform->xform_type == RTE_CRYPTO_ASYM_XFORM_MODINV) {
+   if (xform->modinv.modulus.length == 0) {
+   QAT_LOG(ERR, "Invalid mod inv input parameter");
+   err = -EINVAL;
+   goto error;
+   }
+   } else if (xform->xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
+   if (xform->rsa.n.length == 0) {
+   QAT_LOG(ERR, "Invalid rsa input parameter");
+   err = -EINVAL;
+   goto error;
+   }
+   } else if (xform->xform_type >= RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
+   || xform->xform_type <= RTE_CRYPTO_ASYM_XFORM_NONE) {
+   QAT_LOG(ERR, "Invalid asymmetric crypto xform");
+   err = -EINVAL;
+   goto error;
+   } else {
+   QAT_LOG(ERR, "Asymmetric crypto xform not implemented");
+   err = -EINVAL;
+   goto error;
+   }
+
+   session->xform = xform;
+   qat_asym_build_req_tmpl(sess_private_data);
+   set_asym_session_private_data(sess, dev->driver_id,
+   sess_private_data);
+
+   return 0;
+error:
+   rte_mempool_put(mempool, sess_private_data);
+   return err;
+}
+
+unsigned int
+qat_asym_session_get_private_size(
+   struct rte_cryptodev *dev __rt

[dpdk-dev] [dpdk-dev v3 4/8] crypto/qat: qat driver session method rework

[Kai Ji]

The patch introduce set_session & set_raw_dp_ctx methods to qat gen dev ops
Replace min_qat_dev_gen_id with dev_id, the session will be invalid if the
device generation id is not matching during init and ops

Signed-off-by: Kai Ji 
---
 drivers/crypto/qat/dev/qat_crypto_pmd_gen2.c |  90 
 drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c | 467 +++
 drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c | 243 ++
 drivers/crypto/qat/dev/qat_sym_pmd_gen1.c|   5 +
 drivers/crypto/qat/qat_crypto.c  |   1 +
 drivers/crypto/qat/qat_crypto.h  |   9 +
 drivers/crypto/qat/qat_sym.c |   8 +-
 drivers/crypto/qat/qat_sym_session.c | 106 +
 drivers/crypto/qat/qat_sym_session.h |   2 +-
 9 files changed, 831 insertions(+), 100 deletions(-)

diff --git a/drivers/crypto/qat/dev/qat_crypto_pmd_gen2.c 
b/drivers/crypto/qat/dev/qat_crypto_pmd_gen2.c
index b4ec440e05..72609703f9 100644
--- a/drivers/crypto/qat/dev/qat_crypto_pmd_gen2.c
+++ b/drivers/crypto/qat/dev/qat_crypto_pmd_gen2.c
@@ -166,6 +166,90 @@ qat_sym_crypto_qp_setup_gen2(struct rte_cryptodev *dev, 
uint16_t qp_id,
return 0;
 }
 
+void
+qat_sym_session_set_ext_hash_flags_gen2(struct qat_sym_session *session,
+   uint8_t hash_flag)
+{
+   struct icp_qat_fw_comn_req_hdr *header = &session->fw_req.comn_hdr;
+   struct icp_qat_fw_cipher_auth_cd_ctrl_hdr *cd_ctrl =
+   (struct icp_qat_fw_cipher_auth_cd_ctrl_hdr *)
+   session->fw_req.cd_ctrl.content_desc_ctrl_lw;
+
+   /* Set the Use Extended Protocol Flags bit in LW 1 */
+   QAT_FIELD_SET(header->comn_req_flags,
+   QAT_COMN_EXT_FLAGS_USED,
+   QAT_COMN_EXT_FLAGS_BITPOS,
+   QAT_COMN_EXT_FLAGS_MASK);
+
+   /* Set Hash Flags in LW 28 */
+   cd_ctrl->hash_flags |= hash_flag;
+
+   /* Set proto flags in LW 1 */
+   switch (session->qat_cipher_alg) {
+   case ICP_QAT_HW_CIPHER_ALGO_SNOW_3G_UEA2:
+   ICP_QAT_FW_LA_PROTO_SET(header->serv_specif_flags,
+   ICP_QAT_FW_LA_SNOW_3G_PROTO);
+   ICP_QAT_FW_LA_ZUC_3G_PROTO_FLAG_SET(
+   header->serv_specif_flags, 0);
+   break;
+   case ICP_QAT_HW_CIPHER_ALGO_ZUC_3G_128_EEA3:
+   ICP_QAT_FW_LA_PROTO_SET(header->serv_specif_flags,
+   ICP_QAT_FW_LA_NO_PROTO);
+   ICP_QAT_FW_LA_ZUC_3G_PROTO_FLAG_SET(
+   header->serv_specif_flags,
+   ICP_QAT_FW_LA_ZUC_3G_PROTO);
+   break;
+   default:
+   ICP_QAT_FW_LA_PROTO_SET(header->serv_specif_flags,
+   ICP_QAT_FW_LA_NO_PROTO);
+   ICP_QAT_FW_LA_ZUC_3G_PROTO_FLAG_SET(
+   header->serv_specif_flags, 0);
+   break;
+   }
+}
+
+static int
+qat_sym_crypto_set_session_gen2(void *cdev, void *session)
+{
+   struct rte_cryptodev *dev = cdev;
+   struct qat_sym_session *ctx = session;
+   const struct qat_cryptodev_private *qat_private =
+   dev->data->dev_private;
+   int ret;
+
+   ret = qat_sym_crypto_set_session_gen1(cdev, session);
+   if (ret == 0 || ret != -ENOTSUP)
+   return ret;
+
+   /* GEN1 returning -ENOTSUP as it cannot handle some mixed algo,
+* but some are not supported by GEN2, so checking here
+*/
+   if ((qat_private->internal_capabilities &
+   QAT_SYM_CAP_MIXED_CRYPTO) == 0)
+   return -ENOTSUP;
+
+   if (ctx->qat_hash_alg == ICP_QAT_HW_AUTH_ALGO_ZUC_3G_128_EIA3 &&
+   ctx->qat_cipher_alg !=
+   ICP_QAT_HW_CIPHER_ALGO_ZUC_3G_128_EEA3) {
+   qat_sym_session_set_ext_hash_flags_gen2(ctx,
+   1 << ICP_QAT_FW_AUTH_HDR_FLAG_ZUC_EIA3_BITPOS);
+   } else if (ctx->qat_hash_alg == ICP_QAT_HW_AUTH_ALGO_SNOW_3G_UIA2 &&
+   ctx->qat_cipher_alg !=
+   ICP_QAT_HW_CIPHER_ALGO_SNOW_3G_UEA2) {
+   qat_sym_session_set_ext_hash_flags_gen2(ctx,
+   1 << ICP_QAT_FW_AUTH_HDR_FLAG_SNOW3G_UIA2_BITPOS);
+   } else if ((ctx->aes_cmac ||
+   ctx->qat_hash_alg == ICP_QAT_HW_AUTH_ALGO_NULL) &&
+   (ctx->qat_cipher_alg ==
+   ICP_QAT_HW_CIPHER_ALGO_SNOW_3G_UEA2 ||
+   ctx->qat_cipher_alg ==
+   ICP_QAT_HW_CIPHER_ALGO_ZUC_3G_128_EEA3)) {
+   qat_sym_session_set_ext_hash_flags_gen2(ctx, 0);
+   }
+
+   return 0;
+}
+
 struct rte_cryptodev_ops qat_sym_crypto_ops_gen2 = {
 
/* Device related operations */
@@ -204,6 +288,10 @@ RTE_INIT(qat_sym_crypto_gen2_init)
qat_sym_gen_dev_ops[QAT_GEN2].cryptodev_ops = &qat_sym_crypto_ops_gen

[dpdk-dev] [dpdk-dev v3 5/8] crypto/qat: qat driver datapath rework

[Kai Ji]

This patch introduce op_build_request func in qat enqueue op
burst. Add-in qat_dequeue_process_response in qat dequeue op
burst. Enable session build request op based on crypto operation

Signed-off-by: Kai Ji 
---
 drivers/common/qat/meson.build   |  4 +-
 drivers/common/qat/qat_qp.c  | 60 +---
 drivers/common/qat/qat_qp.h  | 32 +++
 drivers/compress/qat/qat_comp_pmd.c  | 12 +++-
 drivers/crypto/qat/dev/qat_crypto_pmd_gen2.c |  4 +-
 drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c |  4 +-
 drivers/crypto/qat/dev/qat_sym_pmd_gen1.c|  2 +-
 drivers/crypto/qat/qat_asym_refactor.c   |  4 +-
 drivers/crypto/qat/qat_asym_refactor.h   |  2 +-
 drivers/crypto/qat/qat_sym_hw_dp.c   |  2 +-
 drivers/crypto/qat/qat_sym_refactor.c| 51 +
 drivers/crypto/qat/qat_sym_refactor.h|  2 +-
 12 files changed, 57 insertions(+), 122 deletions(-)

diff --git a/drivers/common/qat/meson.build b/drivers/common/qat/meson.build
index ce9959d103..b7b18b6c0f 100644
--- a/drivers/common/qat/meson.build
+++ b/drivers/common/qat/meson.build
@@ -70,8 +70,8 @@ if qat_compress
 endif
 
 if qat_crypto
-foreach f: ['qat_sym_pmd.c', 'qat_sym.c', 'qat_sym_session.c',
-'qat_sym_hw_dp.c', 'qat_asym_pmd.c', 'qat_asym.c', 'qat_crypto.c',
+foreach f: ['qat_sym_refactor.c', 'qat_sym_session.c',
+'qat_sym_hw_dp.c', 'qat_asym_refactor.c', 'qat_crypto.c',
'dev/qat_sym_pmd_gen1.c',
 'dev/qat_asym_pmd_gen1.c',
 'dev/qat_crypto_pmd_gen2.c',
diff --git a/drivers/common/qat/qat_qp.c b/drivers/common/qat/qat_qp.c
index 0fda890075..82adda0698 100644
--- a/drivers/common/qat/qat_qp.c
+++ b/drivers/common/qat/qat_qp.c
@@ -15,8 +15,8 @@
 #include "qat_logs.h"
 #include "qat_device.h"
 #include "qat_qp.h"
-#include "qat_sym.h"
-#include "qat_asym.h"
+#include "qat_sym_refactor.h"
+#include "qat_asym_refactor.h"
 #include "qat_comp.h"
 
 #define QAT_CQ_MAX_DEQ_RETRIES 10
@@ -550,23 +550,8 @@ adf_modulo(uint32_t data, uint32_t modulo_mask)
 }
 
 uint16_t
-refactor_qat_enqueue_op_burst(__rte_unused void *qp,
-   __rte_unused qat_op_build_request_t op_build_request,
-   __rte_unused void **ops, __rte_unused uint16_t nb_ops)
-{
-   return 0;
-}
-
-uint16_t
-refactor_qat_dequeue_op_burst(__rte_unused void *qp, __rte_unused void **ops,
-   __rte_unused qat_op_dequeue_t qat_dequeue_process_response,
-   __rte_unused uint16_t nb_ops)
-{
-   return 0;
-}
-
-uint16_t
-qat_enqueue_op_burst(void *qp, void **ops, uint16_t nb_ops)
+qat_enqueue_op_burst(void *qp, qat_op_build_request_t op_build_request,
+   void **ops, uint16_t nb_ops)
 {
register struct qat_queue *queue;
struct qat_qp *tmp_qp = (struct qat_qp *)qp;
@@ -616,29 +601,18 @@ qat_enqueue_op_burst(void *qp, void **ops, uint16_t 
nb_ops)
}
}
 
-#ifdef BUILD_QAT_SYM
+#ifdef RTE_LIB_SECURITY
if (tmp_qp->service_type == QAT_SERVICE_SYMMETRIC)
qat_sym_preprocess_requests(ops, nb_ops_possible);
 #endif
 
+   memset(tmp_qp->opaque, 0xff, sizeof(tmp_qp->opaque));
+
while (nb_ops_sent != nb_ops_possible) {
-   if (tmp_qp->service_type == QAT_SERVICE_SYMMETRIC) {
-#ifdef BUILD_QAT_SYM
-   ret = qat_sym_build_request(*ops, base_addr + tail,
-   tmp_qp->op_cookies[tail >> queue->trailz],
-   tmp_qp->qat_dev_gen);
-#endif
-   } else if (tmp_qp->service_type == QAT_SERVICE_COMPRESSION) {
-   ret = qat_comp_build_request(*ops, base_addr + tail,
-   tmp_qp->op_cookies[tail >> queue->trailz],
-   tmp_qp->qat_dev_gen);
-   } else if (tmp_qp->service_type == QAT_SERVICE_ASYMMETRIC) {
-#ifdef BUILD_QAT_ASYM
-   ret = qat_asym_build_request(*ops, base_addr + tail,
+   ret = op_build_request(*ops, base_addr + tail,
tmp_qp->op_cookies[tail >> queue->trailz],
-   tmp_qp->qat_dev_gen);
-#endif
-   }
+   tmp_qp->opaque, tmp_qp->qat_dev_gen);
+
if (ret != 0) {
tmp_qp->stats.enqueue_err_count++;
/* This message cannot be enqueued */
@@ -833,7 +807,8 @@ qat_enqueue_comp_op_burst(void *qp, void **ops, uint16_t 
nb_ops)
 }
 
 uint16_t
-qat_dequeue_op_burst(void *qp, void **ops, uint16_t nb_ops)
+qat_dequeue_op_burst(void *qp, void **ops,
+   qat_op_dequeue_t qat_dequeue_process_response, uint16_t nb_ops)
 {
struct qat_queue *rx_queue;
struct qat_qp *tmp_qp = (struct qat_qp *)qp;
@@ -851,19 +826,10 @@ qat_dequeue_op_burst(void *qp, void **ops, uint16_t 
nb_ops)
 
nb_fw_responses = 1;
 
-  

[dpdk-dev] [dpdk-dev v3 6/8] crypto/qat: support sgl oop operation

[Kai Ji]

This patch add-in sgl oop support in qat driver

Signed-off-by: Kai Ji 
---
 drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c | 28 --
 drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c | 14 -
 drivers/crypto/qat/dev/qat_sym_pmd_gen1.c| 55 +---
 3 files changed, 83 insertions(+), 14 deletions(-)

diff --git a/drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c 
b/drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c
index 6494019050..c59c25fe8f 100644
--- a/drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c
+++ b/drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c
@@ -467,8 +467,18 @@ qat_sym_dp_enqueue_aead_jobs_gen3(void *qp_data, uint8_t 
*drv_ctx,
(uint8_t *)tx_queue->base_addr + tail);
rte_mov128((uint8_t *)req, (const uint8_t *)&(ctx->fw_req));
 
-   data_len = qat_sym_build_req_set_data(req, user_data[i], cookie,
-   vec->src_sgl[i].vec, vec->src_sgl[i].num, NULL, 0);
+   if (vec->dest_sgl) {
+   data_len = qat_sym_build_req_set_data(req,
+   user_data[i], cookie,
+   vec->src_sgl[i].vec, vec->src_sgl[i].num,
+   vec->dest_sgl[i].vec, vec->dest_sgl[i].num);
+   } else {
+   data_len = qat_sym_build_req_set_data(req,
+   user_data[i], cookie,
+   vec->src_sgl[i].vec,
+   vec->src_sgl[i].num, NULL, 0);
+   }
+
if (unlikely(data_len < 0))
break;
 
@@ -564,8 +574,18 @@ qat_sym_dp_enqueue_auth_jobs_gen3(void *qp_data, uint8_t 
*drv_ctx,
(uint8_t *)tx_queue->base_addr + tail);
rte_mov128((uint8_t *)req, (const uint8_t *)&(ctx->fw_req));
 
-   data_len = qat_sym_build_req_set_data(req, user_data[i], cookie,
-   vec->src_sgl[i].vec, vec->src_sgl[i].num, NULL, 0);
+   if (vec->dest_sgl) {
+   data_len = qat_sym_build_req_set_data(req,
+   user_data[i], cookie,
+   vec->src_sgl[i].vec, vec->src_sgl[i].num,
+   vec->dest_sgl[i].vec, vec->dest_sgl[i].num);
+   } else {
+   data_len = qat_sym_build_req_set_data(req,
+   user_data[i], cookie,
+   vec->src_sgl[i].vec,
+   vec->src_sgl[i].num, NULL, 0);
+   }
+
if (unlikely(data_len < 0))
break;
enqueue_one_auth_job_gen3(ctx, cookie, req, &vec->digest[i],
diff --git a/drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c 
b/drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c
index 108e07ee7f..1b6cf10589 100644
--- a/drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c
+++ b/drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c
@@ -295,8 +295,18 @@ qat_sym_dp_enqueue_aead_jobs_gen4(void *qp_data, uint8_t 
*drv_ctx,
(uint8_t *)tx_queue->base_addr + tail);
rte_mov128((uint8_t *)req, (const uint8_t *)&(ctx->fw_req));
 
-   data_len = qat_sym_build_req_set_data(req, user_data[i], cookie,
-   vec->src_sgl[i].vec, vec->src_sgl[i].num, NULL, 0);
+   if (vec->dest_sgl) {
+   data_len = qat_sym_build_req_set_data(req,
+   user_data[i], cookie,
+   vec->src_sgl[i].vec, vec->src_sgl[i].num,
+   vec->dest_sgl[i].vec, vec->dest_sgl[i].num);
+   } else {
+   data_len = qat_sym_build_req_set_data(req,
+   user_data[i], cookie,
+   vec->src_sgl[i].vec,
+   vec->src_sgl[i].num, NULL, 0);
+   }
+
if (unlikely(data_len < 0))
break;
 
diff --git a/drivers/crypto/qat/dev/qat_sym_pmd_gen1.c 
b/drivers/crypto/qat/dev/qat_sym_pmd_gen1.c
index abd36c7f1c..9894757657 100644
--- a/drivers/crypto/qat/dev/qat_sym_pmd_gen1.c
+++ b/drivers/crypto/qat/dev/qat_sym_pmd_gen1.c
@@ -529,9 +529,18 @@ qat_sym_dp_enqueue_cipher_jobs_gen1(void *qp_data, uint8_t 
*drv_ctx,
(uint8_t *)tx_queue->base_addr + tail);
rte_mov128((uint8_t *)req, (const uint8_t *)&(ctx->fw_req));
 
-   data_len = qat_sym_build_req_set_data(req, user_data[i],
-   cookie, vec->src_sgl[i].vec,
+   if (vec->dest_sgl) {
+   data_len = qat_sym_build_req_set_data(req,
+   user_data[i], cookie,
+   vec->src_sgl[i].vec, vec->src_sgl[i].num,
+   vec->dest_sgl[i].vec, vec->dest_sgl[i].num);
+   } else {
+  

[dpdk-dev] [dpdk-dev v3 7/8] app/test: cryptodev test fix

[Kai Ji]

test_mixed_auth_cipher: ensure enough space allocate in ibuf & obuf
for mbuf to vec conversion
test_kasumi_decryption: cipher length update.

Fixes: 681f540da52b ("cryptodev: do not use AAD in wireless algorithms")
Cc: pablo.de.lara.gua...@intel.com

Fixes: e847fc512817 ("test/crypto: add encrypted digest case for AES-CTR-CMAC")
Cc: adamx.dybkow...@intel.com

Signed-off-by: Kai Ji 
---
 app/test/test_cryptodev.c | 58 +++
 1 file changed, 46 insertions(+), 12 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 814a0b401d..bfc6408eda 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -179,6 +179,10 @@ post_process_raw_dp_op(void *user_data,uint32_t index 
__rte_unused,
RTE_CRYPTO_OP_STATUS_ERROR;
 }
 
+static struct crypto_testsuite_params testsuite_params = { NULL };
+struct crypto_testsuite_params *p_testsuite_params = &testsuite_params;
+static struct crypto_unittest_params unittest_params;
+
 void
 process_sym_raw_dp_op(uint8_t dev_id, uint16_t qp_id,
struct rte_crypto_op *op, uint8_t is_cipher, uint8_t is_auth,
@@ -193,6 +197,7 @@ process_sym_raw_dp_op(uint8_t dev_id, uint16_t qp_id,
struct rte_crypto_sgl sgl, dest_sgl;
uint32_t max_len;
union rte_cryptodev_session_ctx sess;
+   uint64_t auth_end_iova;
uint32_t count = 0;
struct rte_crypto_raw_dp_ctx *ctx;
uint32_t cipher_offset = 0, cipher_len = 0, auth_offset = 0,
@@ -202,6 +207,9 @@ process_sym_raw_dp_op(uint8_t dev_id, uint16_t qp_id,
int ctx_service_size;
int32_t status = 0;
int enqueue_status, dequeue_status;
+   struct crypto_unittest_params *ut_params = &unittest_params;
+   int is_sgl = sop->m_src->nb_segs > 1;
+   int is_oop = 0;
 
ctx_service_size = rte_cryptodev_get_raw_dp_ctx_size(dev_id);
if (ctx_service_size < 0) {
@@ -240,6 +248,9 @@ process_sym_raw_dp_op(uint8_t dev_id, uint16_t qp_id,
 
ofs.raw = 0;
 
+   if ((sop->m_dst != NULL) && (sop->m_dst != sop->m_src))
+   is_oop = 1;
+
if (is_cipher && is_auth) {
cipher_offset = sop->cipher.data.offset;
cipher_len = sop->cipher.data.length;
@@ -267,6 +278,31 @@ process_sym_raw_dp_op(uint8_t dev_id, uint16_t qp_id,
digest.va = (void *)sop->auth.digest.data;
digest.iova = sop->auth.digest.phys_addr;
 
+   if (is_sgl) {
+   uint32_t remaining_off = auth_offset + auth_len;
+   struct rte_mbuf *sgl_buf = sop->m_src;
+   if (is_oop)
+   sgl_buf = sop->m_dst;
+
+   while (remaining_off >= rte_pktmbuf_data_len(sgl_buf)
+   && sgl_buf->next != NULL) {
+   remaining_off -= rte_pktmbuf_data_len(sgl_buf);
+   sgl_buf = sgl_buf->next;
+   }
+
+   auth_end_iova = (uint64_t)rte_pktmbuf_iova_offset(
+   sgl_buf, remaining_off);
+   } else {
+   auth_end_iova = rte_pktmbuf_iova(op->sym->m_src) +
+auth_offset + auth_len;
+   }
+   /* Then check if digest-encrypted conditions are met */
+   if ((auth_offset + auth_len < cipher_offset + cipher_len) &&
+   (digest.iova == auth_end_iova) && is_sgl)
+   max_len = RTE_MAX(max_len,
+   auth_offset + auth_len +
+   ut_params->auth_xform.auth.digest_length);
+
} else if (is_cipher) {
cipher_offset = sop->cipher.data.offset;
cipher_len = sop->cipher.data.length;
@@ -327,7 +363,7 @@ process_sym_raw_dp_op(uint8_t dev_id, uint16_t qp_id,
 
sgl.num = n;
/* Out of place */
-   if (sop->m_dst != NULL) {
+   if (is_oop) {
dest_sgl.vec = dest_data_vec;
vec.dest_sgl = &dest_sgl;
n = rte_crypto_mbuf_to_vec(sop->m_dst, 0, max_len,
@@ -503,10 +539,6 @@ process_crypto_request(uint8_t dev_id, struct 
rte_crypto_op *op)
return op;
 }
 
-static struct crypto_testsuite_params testsuite_params = { NULL };
-struct crypto_testsuite_params *p_testsuite_params = &testsuite_params;
-static struct crypto_unittest_params unittest_params;
-
 static int
 testsuite_setup(void)
 {
@@ -4077,9 +4109,9 @@ test_kasumi_decryption(const struct kasumi_test_data 
*tdata)
 
/* Create KASUMI operation */
retval = create_wireless_algo_cipher_operation(tdata->cipher_iv.data,
-   tdata->cipher_iv.len,
-   tdata->ciphertext.len,
-   tdata->vali

Re: [dpdk-dev] [PATCH v4 0/6] Flow entites behavior on port restart

[Ferruh Yigit]

On 10/21/2021 7:34 AM, Dmitry Kozlyuk wrote:

It is unspecified whether flow rules and indirect actions are kept
when a port is stopped, possibly reconfigured, and started again.
Vendors approach the topic differently, e.g. mlx5 and i40e PMD
disagree in whether flow rules can be kept, and mlx5 PMD would keep
indirect actions. In the end, applications are greatly affected
by whatever contract there is and need to know it.

Applications may wish to restart the port to reconfigure it,
e.g. switch offloads or even modify queues.
Keeping rte_flow entities enables application improvements:
1. Since keeping the rules across restart comes with the ability
to create rules before the device is started. This allows
to have all the rules created at the moment of start,
so that there is no time frame when traffic is coming already,
but the rules are not yet created (restored).
2. When a rule or an indirect action has some associated state,
such as a counter, application saves the need to keep
additional state in order to cope with information loss
if such an entity would be destroyed.

It is proposed to advertise capabilities of keeping flow rules
and indirect actions (as a special case of shared object)
using a combination of ethdev info and rte_flow calls.
Then a bug is fixed in mlx5 PMD that prevented indirect RSS action
from being kept, and the driver starts advertising the new capability.

Prior discussions:
1) http://inbox.dpdk.org/dev/20210727073121.895620-1-dkozl...@nvidia.com/
2) http://inbox.dpdk.org/dev/20210901085516.3647814-1-dkozl...@nvidia.com/

v4:  1. Fix rebase conflicts (CI).
  2. State rule behavior when a port is not started or stopped (Ori).
  3. Improve wording on rule features, add examples (Andrew).
  4. State that rules/actions that cannot be kept while other can be
 must be destroyed by the application (Andrew/Ori).
  5. Add rationale to the cover letter (Andrew).

Dmitry Kozlyuk (6):
   ethdev: add capability to keep flow rules on restart
   ethdev: add capability to keep shared objects on restart
   net: advertise no support for keeping flow rules
   net/mlx5: discover max flow priority using DevX
   net/mlx5: create drop queue using DevX
   net/mlx5: preserve indirect actions on restart



Hi Dmitry,

Can you please rebase this set on latest next-net?
There are some changes both in ethdev and mlx5.

[dpdk-dev] [PATCH v5 0/6] Flow entites behavior on port restart

[Dmitry Kozlyuk]

It is unspecified whether flow rules and indirect actions are kept
when a port is stopped, possibly reconfigured, and started again.
Vendors approach the topic differently, e.g. mlx5 and i40e PMD
disagree in whether flow rules can be kept, and mlx5 PMD would keep
indirect actions. In the end, applications are greatly affected
by whatever contract there is and need to know it.

Applications may wish to restart the port to reconfigure it,
e.g. switch offloads or even modify queues.
Keeping rte_flow entities enables application improvements:
1. Since keeping the rules across restart comes with the ability
   to create rules before the device is started. This allows
   to have all the rules created at the moment of start,
   so that there is no time frame when traffic is coming already,
   but the rules are not yet created (restored).
2. When a rule or an indirect action has some associated state,
   such as a counter, application saves the need to keep
   additional state in order to cope with information loss
   if such an entity would be destroyed.

It is proposed to advertise capabilities of keeping flow rules
and indirect actions (as a special case of shared object)
using a combination of ethdev info and rte_flow calls.
Then a bug is fixed in mlx5 PMD that prevented indirect RSS action
from being kept, and the driver starts advertising the new capability.

Prior discussions:
1) http://inbox.dpdk.org/dev/20210727073121.895620-1-dkozl...@nvidia.com/
2) http://inbox.dpdk.org/dev/20210901085516.3647814-1-dkozl...@nvidia.com/

v5:
 1. Fix rebase conflicts.
 2. Add warnings about experimental status (Andrew).

v4:  1. Fix rebase conflicts (CI).
 2. State rule behavior when a port is not started or stopped (Ori).
 3. Improve wording on rule features, add examples (Andrew).
 4. State that rules/actions that cannot be kept while other can be
must be destroyed by the application (Andrew/Ori).
 5. Add rationale to the cover letter (Andrew).

Dmitry Kozlyuk (6):
  ethdev: add capability to keep flow rules on restart
  ethdev: add capability to keep shared objects on restart
  net: advertise no support for keeping flow rules
  net/mlx5: discover max flow priority using DevX
  net/mlx5: create drop queue using DevX
  net/mlx5: preserve indirect actions on restart

 doc/guides/prog_guide/rte_flow.rst  |  67 ++
 drivers/net/bnxt/bnxt_ethdev.c  |   1 +
 drivers/net/bnxt/bnxt_reps.c|   1 +
 drivers/net/cnxk/cnxk_ethdev_ops.c  |   1 +
 drivers/net/cxgbe/cxgbe_ethdev.c|   2 +
 drivers/net/dpaa2/dpaa2_ethdev.c|   1 +
 drivers/net/e1000/em_ethdev.c   |   2 +
 drivers/net/e1000/igb_ethdev.c  |   1 +
 drivers/net/enic/enic_ethdev.c  |   1 +
 drivers/net/failsafe/failsafe_ops.c |   1 +
 drivers/net/hinic/hinic_pmd_ethdev.c|   2 +
 drivers/net/hns3/hns3_ethdev.c  |   1 +
 drivers/net/hns3/hns3_ethdev_vf.c   |   1 +
 drivers/net/i40e/i40e_ethdev.c  |   1 +
 drivers/net/i40e/i40e_vf_representor.c  |   2 +
 drivers/net/iavf/iavf_ethdev.c  |   1 +
 drivers/net/ice/ice_dcf_ethdev.c|   1 +
 drivers/net/igc/igc_ethdev.c|   1 +
 drivers/net/ipn3ke/ipn3ke_representor.c |   1 +
 drivers/net/mlx5/linux/mlx5_os.c|   5 -
 drivers/net/mlx5/mlx5_devx.c| 211 ++---
 drivers/net/mlx5/mlx5_ethdev.c  |   1 +
 drivers/net/mlx5/mlx5_flow.c| 292 ++--
 drivers/net/mlx5/mlx5_flow.h|   6 +
 drivers/net/mlx5/mlx5_flow_dv.c | 103 +
 drivers/net/mlx5/mlx5_flow_verbs.c  |  74 +-
 drivers/net/mlx5/mlx5_rx.h  |   4 +
 drivers/net/mlx5/mlx5_rxq.c |  99 +++-
 drivers/net/mlx5/mlx5_trigger.c |  10 +
 drivers/net/mvpp2/mrvl_ethdev.c |   2 +
 drivers/net/octeontx2/otx2_ethdev_ops.c |   1 +
 drivers/net/qede/qede_ethdev.c  |   1 +
 drivers/net/sfc/sfc_ethdev.c|   1 +
 drivers/net/softnic/rte_eth_softnic.c   |   1 +
 drivers/net/tap/rte_eth_tap.c   |   1 +
 drivers/net/txgbe/txgbe_ethdev.c|   1 +
 drivers/net/txgbe/txgbe_ethdev_vf.c |   1 +
 lib/ethdev/rte_ethdev.h |  10 +
 lib/ethdev/rte_flow.h   |   1 +
 39 files changed, 781 insertions(+), 133 deletions(-)

-- 
2.25.1

[dpdk-dev] [PATCH v5 1/6] ethdev: add capability to keep flow rules on restart

[Dmitry Kozlyuk]

Previously, it was not specified what happens to the flow rules
when the device is stopped, possibly reconfigured, then started.
If flow rules were kept, it could be convenient for application
developers, because they wouldn't need to save and restore them.
However, due to the number of flows and possible creation rate it is
impractical to save all flow rules in DPDK layer. This means that flow
rules persistence really depends on whether PMD and HW can implement it
efficiently. It can also be limited by the rule item and action types,
and its attributes transfer bit (a combination of an item/action type
and a value of the transfer bit is called a ruel feature).

Add a device capability bit for PMDs that can keep at least some
of the flow rules across restart. Without this capability behavior
is still unspecified and it is declared that the application must
flush the rules before stopping the device.
Allow the application to test for persistence of rules using
a particular feature by attempting to create a flow rule
using that feature when the device is stopped
and checking for the specific error.
This is logical because if the PMD can to create the flow rule
when the device is not started and use it after the start happens,
it is natural that it can move its internal flow rule object
to the same state when the device is stopped and restore the state
when the device is started.

Rule persistence across a reconfigurations is not required,
because tracking all the rules and configuration-dependent resources
they use may be infeasible. In case a PMD cannot keep the rules
across reconfiguration, it is allowed just to report an error.
Application must then flush the rules before attempting it.

Signed-off-by: Dmitry Kozlyuk 
Acked-by: Ori Kam 
Acked-by: Andrew Rybchenko 
---
 doc/guides/prog_guide/rte_flow.rst | 36 ++
 lib/ethdev/rte_ethdev.h|  7 ++
 lib/ethdev/rte_flow.h  |  1 +
 3 files changed, 44 insertions(+)

diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 2d2d87f1db..e01a079230 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -87,6 +87,42 @@ To avoid resource leaks on the PMD side, handles must be 
explicitly
 destroyed by the application before releasing associated resources such as
 queues and ports.
 
+.. warning::
+
+   The following description of rule persistence is an experimental behavior
+   that may change without a prior notice.
+
+When the device is stopped, its rules do not process the traffic.
+In particular, transfer rules created using some device
+stop affecting the traffic even if they refer to different ports.
+
+If ``RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP`` is not advertised,
+rules cannot be created until the device is started for the first time
+and cannot be kept when the device is stopped.
+However, PMD also does not flush them automatically on stop,
+so the application must call ``rte_flow_flush()`` or ``rte_flow_destroy()``
+before stopping the device to ensure no rules remain.
+
+If ``RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP`` is advertised, this means
+the PMD can keep at least some rules across the device stop and start.
+However, ``rte_eth_dev_configure()`` may fail if any rules remain,
+so the application must flush them before attempting a reconfiguration.
+Keeping may be unsupported for some types of rule items and actions,
+as well as depending on the value of flow attributes transfer bit.
+A combination of a single an item or action type
+and a value of the transfer bit is called a rule feature.
+For example: a COUNT action with the transfer bit set.
+To test if rules with a particular feature are kept, the application must try
+to create a valid rule using this feature when the device is not started
+(either before the first start or after a stop).
+If it fails with an error of type ``RTE_FLOW_ERROR_TYPE_STATE``,
+all rules using this feature must be flushed by the application
+before stopping the device.
+If it succeeds, such rules will be kept when the device is stopped,
+provided they do not use other features that are not supported.
+Rules that are created when the device is stopped, including the rules
+created for the test, will be kept after the device is started.
+
 The following sections cover:
 
 - **Attributes** (represented by ``struct rte_flow_attr``): properties of a
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 24f30b4b28..a18e6ab887 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -90,6 +90,11 @@
  * - flow director filtering mode (but not filtering rules)
  * - NIC queue statistics mappings
  *
+ * The following configuration may be retained or not
+ * depending on the device capabilities:
+ *
+ * - flow rules
+ *
  * Any other configuration will not be stored and will need to be re-entered
  * before a call to rte_eth_dev_start().
  *
@@ -1691,6 +1696,8 @@ struct rte_eth_c

[dpdk-dev] [PATCH v5 2/6] ethdev: add capability to keep shared objects on restart

[Dmitry Kozlyuk]

rte_flow_action_handle_create() did not mention what happens
with an indirect action when a device is stopped and started again.
It is natural for some indirect actions, like counter, to be persistent.
Keeping others at least saves application time and complexity.
However, not all PMDs can support it, or the support may be limited
by particular action kinds, that is, combinations of action type
and the value of the transfer bit in its configuration.

Add a device capability to indicate if at least some indirect actions
are kept across the above sequence. Without this capability the behavior
is still unspecified, and application is required to destroy
the indirect actions before stopping the device.
In the future, indirect actions may not be the only type of objects
shared between flow rules. The capability bit intends to cover all
possible types of such objects, hence its name.

Declare that the application can test for the persistence
of a particular indirect action kind by attempting to create
an indirect action of that kind when the device is stopped
and checking for the specific error type.
This is logical because if the PMD can to create an indirect action
when the device is not started and use it after the start happens,
it is natural that it can move its internal flow shared object
to the same state when the device is stopped and restore the state
when the device is started.

Indirect action persistence across a reconfigurations is not required.
In case a PMD cannot keep the indirect actions across reconfiguration,
it is allowed just to report an error.
Application must then flush the indirect actions before attempting it.

Signed-off-by: Dmitry Kozlyuk 
Acked-by: Ori Kam 
Acked-by: Andrew Rybchenko 
---
 doc/guides/prog_guide/rte_flow.rst | 31 ++
 lib/ethdev/rte_ethdev.h|  3 +++
 2 files changed, 34 insertions(+)

diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index e01a079230..77de8da973 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2995,6 +2995,37 @@ updated depend on the type of the ``action`` and 
different for every type.
 The indirect action specified data (e.g. counter) can be queried by
 ``rte_flow_action_handle_query()``.
 
+.. warning::
+
+   The following description of indirect action persistence
+   is an experimental behavior that may change without a prior notice.
+
+If ``RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP`` is not advertised,
+indirect actions cannot be created until the device is started for the first 
time
+and cannot be kept when the device is stopped.
+However, PMD also does not flush them automatically on stop,
+so the application must call ``rte_flow_action_handle_destroy()``
+before stopping the device to ensure no indirect actions remain.
+
+If ``RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP`` is advertised,
+this means that the PMD can keep at least some indirect actions
+across device stop and start.
+However, ``rte_eth_dev_configure()`` may fail if any indirect actions remain,
+so the application must destroy them before attempting a reconfiguration.
+Keeping may be only supported for certain kinds of indirect actions.
+A kind is a combination of an action type and a value of its transfer bit.
+For example: an indirect counter with the transfer bit reset.
+To test if a particular kind of indirect actions is kept,
+the application must try to create a valid indirect action of that kind
+when the device is not started (either before the first start of after a stop).
+If it fails with an error of type ``RTE_FLOW_ERROR_TYPE_STATE``,
+application must destroy all indirect actions of this kind
+before stopping the device.
+If it succeeds, all indirect actions of the same kind are kept
+when the device is stopped.
+Indirect actions of a kept kind that are created when the device is stopped,
+including the ones created for the test, will be kept after the device start.
+
 .. _table_rte_flow_action_handle:
 
 .. table:: INDIRECT
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index a18e6ab887..5f803ad1e6 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -94,6 +94,7 @@
  * depending on the device capabilities:
  *
  * - flow rules
+ * - flow-related shared objects, e.g. indirect actions
  *
  * Any other configuration will not be stored and will need to be re-entered
  * before a call to rte_eth_dev_start().
@@ -1698,6 +1699,8 @@ struct rte_eth_conf {
 #define RTE_ETH_DEV_CAPA_RXQ_SHARE  RTE_BIT64(2)
 /** Device supports keeping flow rules across restart. */
 #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3)
+/** Device supports keeping shared flow objects across restart. */
+#define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4)
 /**@}*/
 
 /*
-- 
2.25.1

[dpdk-dev] [PATCH v5 3/6] net: advertise no support for keeping flow rules

[Dmitry Kozlyuk]

When RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP capability bit is zero,
the specified behavior is the same as it had been before
this bit was introduced. Explicitly reset it in all PMDs
supporting rte_flow API in order to attract the attention
of maintainers, who should eventually choose to advertise
the new capability or not. It is already known that
mlx4 and mlx5 will not support this capability.

For RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP
similar action is not performed,
because no PMD except mlx5 supports indirect actions.
Any PMD that starts doing so will anyway have to consider
all relevant API, including this capability.

Suggested-by: Ferruh Yigit 
Signed-off-by: Dmitry Kozlyuk 
Acked-by: Ajit Khaparde 
Acked-by: Somnath Kotur 
Acked-by: Hyong Youb Kim 
---
 drivers/net/bnxt/bnxt_ethdev.c  | 1 +
 drivers/net/bnxt/bnxt_reps.c| 1 +
 drivers/net/cnxk/cnxk_ethdev_ops.c  | 1 +
 drivers/net/cxgbe/cxgbe_ethdev.c| 2 ++
 drivers/net/dpaa2/dpaa2_ethdev.c| 1 +
 drivers/net/e1000/em_ethdev.c   | 2 ++
 drivers/net/e1000/igb_ethdev.c  | 1 +
 drivers/net/enic/enic_ethdev.c  | 1 +
 drivers/net/failsafe/failsafe_ops.c | 1 +
 drivers/net/hinic/hinic_pmd_ethdev.c| 2 ++
 drivers/net/hns3/hns3_ethdev.c  | 1 +
 drivers/net/hns3/hns3_ethdev_vf.c   | 1 +
 drivers/net/i40e/i40e_ethdev.c  | 1 +
 drivers/net/i40e/i40e_vf_representor.c  | 2 ++
 drivers/net/iavf/iavf_ethdev.c  | 1 +
 drivers/net/ice/ice_dcf_ethdev.c| 1 +
 drivers/net/igc/igc_ethdev.c| 1 +
 drivers/net/ipn3ke/ipn3ke_representor.c | 1 +
 drivers/net/mvpp2/mrvl_ethdev.c | 2 ++
 drivers/net/octeontx2/otx2_ethdev_ops.c | 1 +
 drivers/net/qede/qede_ethdev.c  | 1 +
 drivers/net/sfc/sfc_ethdev.c| 1 +
 drivers/net/softnic/rte_eth_softnic.c   | 1 +
 drivers/net/tap/rte_eth_tap.c   | 1 +
 drivers/net/txgbe/txgbe_ethdev.c| 1 +
 drivers/net/txgbe/txgbe_ethdev_vf.c | 1 +
 26 files changed, 31 insertions(+)

diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 5a34bb96d0..7e3ee3d357 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1006,6 +1006,7 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev 
*eth_dev,
dev_info->speed_capa = bnxt_get_speed_capabilities(bp);
dev_info->dev_capa = RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP |
 RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP;
+   dev_info->dev_capa &= ~RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP;
 
dev_info->default_rxconf = (struct rte_eth_rxconf) {
.rx_thresh = {
diff --git a/drivers/net/bnxt/bnxt_reps.c b/drivers/net/bnxt/bnxt_reps.c
index 1c07db3ca9..01460a0846 100644
--- a/drivers/net/bnxt/bnxt_reps.c
+++ b/drivers/net/bnxt/bnxt_reps.c
@@ -526,6 +526,7 @@ int bnxt_rep_dev_info_get_op(struct rte_eth_dev *eth_dev,
dev_info->max_tx_queues = max_rx_rings;
dev_info->reta_size = bnxt_rss_hash_tbl_size(parent_bp);
dev_info->hash_key_size = 40;
+   dev_info->dev_capa &= ~RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP;
 
/* MTU specifics */
dev_info->min_mtu = RTE_ETHER_MIN_MTU;
diff --git a/drivers/net/cnxk/cnxk_ethdev_ops.c 
b/drivers/net/cnxk/cnxk_ethdev_ops.c
index 6746430265..62306b6cd6 100644
--- a/drivers/net/cnxk/cnxk_ethdev_ops.c
+++ b/drivers/net/cnxk/cnxk_ethdev_ops.c
@@ -68,6 +68,7 @@ cnxk_nix_info_get(struct rte_eth_dev *eth_dev, struct 
rte_eth_dev_info *devinfo)
devinfo->speed_capa = dev->speed_capa;
devinfo->dev_capa = RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP |
RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP;
+   devinfo->dev_capa &= ~RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP;
return 0;
 }
 
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 4758321778..e7ea76180f 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -131,6 +131,8 @@ int cxgbe_dev_info_get(struct rte_eth_dev *eth_dev,
device_info->max_vfs = adapter->params.arch.vfcount;
device_info->max_vmdq_pools = 0; /* XXX: For now no support for VMDQ */
 
+   device_info->dev_capa &= ~RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP;
+
device_info->rx_queue_offload_capa = 0UL;
device_info->rx_offload_capa = CXGBE_RX_OFFLOADS;
 
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index 73d17f7b3c..a3706439d5 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -254,6 +254,7 @@ dpaa2_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->speed_capa = RTE_ETH_LINK_SPEED_1G |
RTE_ETH_LINK_SPEED_2_5G |
RTE_ETH_LINK_SPEED_10G;
+   dev_info->dev_capa &= ~RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP;
 
dev_info->max_hash_mac_addrs = 0;
dev_info->max_vfs = 0;
diff --git a/drivers/net/e1000/em

[dpdk-dev] [PATCH v5 4/6] net/mlx5: discover max flow priority using DevX

[Dmitry Kozlyuk]

Maximum available flow priority was discovered using Verbs API
regardless of the selected flow engine. This required some Verbs
objects to be initialized in order to use DevX engine. Make priority
discovery an engine method and implement it for DevX using its API.

Cc: sta...@dpdk.org

Signed-off-by: Dmitry Kozlyuk 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/linux/mlx5_os.c   |   1 -
 drivers/net/mlx5/mlx5_flow.c   |  98 +++
 drivers/net/mlx5/mlx5_flow.h   |   4 ++
 drivers/net/mlx5/mlx5_flow_dv.c| 103 +
 drivers/net/mlx5/mlx5_flow_verbs.c |  74 +++--
 5 files changed, 216 insertions(+), 64 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index 72bbb665cf..34546635c4 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -1720,7 +1720,6 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
priv->drop_queue.hrxq = mlx5_drop_action_create(eth_dev);
if (!priv->drop_queue.hrxq)
goto error;
-   /* Supported Verbs flow priority number detection. */
err = mlx5_flow_discover_priorities(eth_dev);
if (err < 0) {
err = -err;
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 5d19ef1e82..850eb353fd 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -9570,3 +9570,101 @@ mlx5_flow_expand_rss_adjust_node(const struct 
rte_flow_item *pattern,
return node;
}
 }
+
+/* Map of Verbs to Flow priority with 8 Verbs priorities. */
+static const uint32_t priority_map_3[][MLX5_PRIORITY_MAP_MAX] = {
+   { 0, 1, 2 }, { 2, 3, 4 }, { 5, 6, 7 },
+};
+
+/* Map of Verbs to Flow priority with 16 Verbs priorities. */
+static const uint32_t priority_map_5[][MLX5_PRIORITY_MAP_MAX] = {
+   { 0, 1, 2 }, { 3, 4, 5 }, { 6, 7, 8 },
+   { 9, 10, 11 }, { 12, 13, 14 },
+};
+
+/**
+ * Discover the number of available flow priorities.
+ *
+ * @param dev
+ *   Ethernet device.
+ *
+ * @return
+ *   On success, number of available flow priorities.
+ *   On failure, a negative errno-style code and rte_errno is set.
+ */
+int
+mlx5_flow_discover_priorities(struct rte_eth_dev *dev)
+{
+   static const uint16_t vprio[] = {8, 16};
+   const struct mlx5_priv *priv = dev->data->dev_private;
+   const struct mlx5_flow_driver_ops *fops;
+   enum mlx5_flow_drv_type type;
+   int ret;
+
+   type = mlx5_flow_os_get_type();
+   if (type == MLX5_FLOW_TYPE_MAX) {
+   type = MLX5_FLOW_TYPE_VERBS;
+   if (priv->sh->devx && priv->config.dv_flow_en)
+   type = MLX5_FLOW_TYPE_DV;
+   }
+   fops = flow_get_drv_ops(type);
+   if (fops->discover_priorities == NULL) {
+   DRV_LOG(ERR, "Priority discovery not supported");
+   rte_errno = ENOTSUP;
+   return -rte_errno;
+   }
+   ret = fops->discover_priorities(dev, vprio, RTE_DIM(vprio));
+   if (ret < 0)
+   return ret;
+   switch (ret) {
+   case 8:
+   ret = RTE_DIM(priority_map_3);
+   break;
+   case 16:
+   ret = RTE_DIM(priority_map_5);
+   break;
+   default:
+   rte_errno = ENOTSUP;
+   DRV_LOG(ERR,
+   "port %u maximum priority: %d expected 8/16",
+   dev->data->port_id, ret);
+   return -rte_errno;
+   }
+   DRV_LOG(INFO, "port %u supported flow priorities:"
+   " 0-%d for ingress or egress root table,"
+   " 0-%d for non-root table or transfer root table.",
+   dev->data->port_id, ret - 2,
+   MLX5_NON_ROOT_FLOW_MAX_PRIO - 1);
+   return ret;
+}
+
+/**
+ * Adjust flow priority based on the highest layer and the request priority.
+ *
+ * @param[in] dev
+ *   Pointer to the Ethernet device structure.
+ * @param[in] priority
+ *   The rule base priority.
+ * @param[in] subpriority
+ *   The priority based on the items.
+ *
+ * @return
+ *   The new priority.
+ */
+uint32_t
+mlx5_flow_adjust_priority(struct rte_eth_dev *dev, int32_t priority,
+ uint32_t subpriority)
+{
+   uint32_t res = 0;
+   struct mlx5_priv *priv = dev->data->dev_private;
+
+   switch (priv->config.flow_prio) {
+   case RTE_DIM(priority_map_3):
+   res = priority_map_3[priority][subpriority];
+   break;
+   case RTE_DIM(priority_map_5):
+   res = priority_map_5[priority][subpriority];
+   break;
+   }
+   return  res;
+}
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index 4a16f30fb7..2c9d3759b8 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -1229,6 +1229,9 @@ typedef int (*mlx5_flow_create_def_policy_t)
(struct rte_eth_dev 

[dpdk-dev] [PATCH v5 5/6] net/mlx5: create drop queue using DevX

[Dmitry Kozlyuk]

Drop queue creation and destruction were not implemented for DevX
flow engine and Verbs engine methods were used as a workaround.
Implement these methods for DevX so that there is a valid queue ID
that can be used regardless of queue configuration via API.

Cc: sta...@dpdk.org

Signed-off-by: Dmitry Kozlyuk 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/linux/mlx5_os.c |   4 -
 drivers/net/mlx5/mlx5_devx.c | 211 ++-
 2 files changed, 180 insertions(+), 35 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index 34546635c4..091763b745 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -1685,10 +1685,6 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
}
if (sh->devx && config->dv_flow_en && config->dest_tir) {
priv->obj_ops = devx_obj_ops;
-   priv->obj_ops.drop_action_create =
-   ibv_obj_ops.drop_action_create;
-   priv->obj_ops.drop_action_destroy =
-   ibv_obj_ops.drop_action_destroy;
mlx5_queue_counter_id_prepare(eth_dev);
priv->obj_ops.lb_dummy_queue_create =
mlx5_rxq_ibv_obj_dummy_lb_create;
diff --git a/drivers/net/mlx5/mlx5_devx.c b/drivers/net/mlx5/mlx5_devx.c
index 7ed774e804..424f77be79 100644
--- a/drivers/net/mlx5/mlx5_devx.c
+++ b/drivers/net/mlx5/mlx5_devx.c
@@ -226,18 +226,18 @@ mlx5_rx_devx_get_event(struct mlx5_rxq_obj *rxq_obj)
  *
  * @param dev
  *   Pointer to Ethernet device.
- * @param idx
- *   Queue index in DPDK Rx queue array.
+ * @param rxq_data
+ *   RX queue data.
  *
  * @return
  *   0 on success, a negative errno value otherwise and rte_errno is set.
  */
 static int
-mlx5_rxq_create_devx_rq_resources(struct rte_eth_dev *dev, uint16_t idx)
+mlx5_rxq_create_devx_rq_resources(struct rte_eth_dev *dev,
+ struct mlx5_rxq_data *rxq_data)
 {
struct mlx5_priv *priv = dev->data->dev_private;
struct mlx5_common_device *cdev = priv->sh->cdev;
-   struct mlx5_rxq_data *rxq_data = (*priv->rxqs)[idx];
struct mlx5_rxq_ctrl *rxq_ctrl =
container_of(rxq_data, struct mlx5_rxq_ctrl, rxq);
struct mlx5_devx_create_rq_attr rq_attr = { 0 };
@@ -290,20 +290,20 @@ mlx5_rxq_create_devx_rq_resources(struct rte_eth_dev 
*dev, uint16_t idx)
  *
  * @param dev
  *   Pointer to Ethernet device.
- * @param idx
- *   Queue index in DPDK Rx queue array.
+ * @param rxq_data
+ *   RX queue data.
  *
  * @return
  *   0 on success, a negative errno value otherwise and rte_errno is set.
  */
 static int
-mlx5_rxq_create_devx_cq_resources(struct rte_eth_dev *dev, uint16_t idx)
+mlx5_rxq_create_devx_cq_resources(struct rte_eth_dev *dev,
+ struct mlx5_rxq_data *rxq_data)
 {
struct mlx5_devx_cq *cq_obj = 0;
struct mlx5_devx_cq_attr cq_attr = { 0 };
struct mlx5_priv *priv = dev->data->dev_private;
struct mlx5_dev_ctx_shared *sh = priv->sh;
-   struct mlx5_rxq_data *rxq_data = (*priv->rxqs)[idx];
struct mlx5_rxq_ctrl *rxq_ctrl =
container_of(rxq_data, struct mlx5_rxq_ctrl, rxq);
unsigned int cqe_n = mlx5_rxq_cqe_num(rxq_data);
@@ -498,13 +498,13 @@ mlx5_rxq_devx_obj_new(struct rte_eth_dev *dev, uint16_t 
idx)
tmpl->fd = mlx5_os_get_devx_channel_fd(tmpl->devx_channel);
}
/* Create CQ using DevX API. */
-   ret = mlx5_rxq_create_devx_cq_resources(dev, idx);
+   ret = mlx5_rxq_create_devx_cq_resources(dev, rxq_data);
if (ret) {
DRV_LOG(ERR, "Failed to create CQ.");
goto error;
}
/* Create RQ using DevX API. */
-   ret = mlx5_rxq_create_devx_rq_resources(dev, idx);
+   ret = mlx5_rxq_create_devx_rq_resources(dev, rxq_data);
if (ret) {
DRV_LOG(ERR, "Port %u Rx queue %u RQ creation failure.",
dev->data->port_id, idx);
@@ -537,6 +537,11 @@ mlx5_rxq_devx_obj_new(struct rte_eth_dev *dev, uint16_t 
idx)
  *   Pointer to Ethernet device.
  * @param log_n
  *   Log of number of queues in the array.
+ * @param queues
+ *   List of RX queue indices or NULL, in which case
+ *   the attribute will be filled by drop queue ID.
+ * @param queues_n
+ *   Size of @p queues array or 0 if it is NULL.
  * @param ind_tbl
  *   DevX indirection table object.
  *
@@ -564,6 +569,11 @@ mlx5_devx_ind_table_create_rqt_attr(struct rte_eth_dev 
*dev,
}
rqt_attr->rqt_max_size = priv->config.ind_table_max_size;
rqt_attr->rqt_actual_size = rqt_n;
+   if (queues == NULL) {
+   for (i = 0; i < rqt_n; i++)
+   rqt_attr->rq_list[i] = priv->drop_queue.rxq->rq->id;
+   return rqt_attr;
+   }
for (i = 0; i != queues_n; ++i) {
  

[dpdk-dev] [PATCH v5 6/6] net/mlx5: preserve indirect actions on restart

[Dmitry Kozlyuk]

MLX5 PMD uses reference counting to manage RX queue resources.
After port stop shared RSS actions kept references to RX queues,
preventing resource release. As a result, internal PMD mempool
for such queues had been exhausted after a number of port restarts.
Diagnostic message from rte_eth_dev_start():

Rx queue allocation failed: Cannot allocate memory

Dereference RX queues used by indirect actions on port stop (detach)
and restore references on port start (attach) in order to allow RX queue
resource release, but keep indirect RSS across the port restart.
Replace queue IDs in HW by drop queue ID on detach and restore actual
queue IDs on attach.

When the port is stopped, create indirect RSS in the detached state.
As a result, MLX5 PMD is able to keep all its indirect actions
across port restart. Advertise this capability.

Fixes: 4b61b8774be9 ("ethdev: introduce indirect flow action")
Cc: bi...@nvidia.com
Cc: sta...@dpdk.org

Signed-off-by: Dmitry Kozlyuk 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/mlx5_ethdev.c  |   1 +
 drivers/net/mlx5/mlx5_flow.c| 194 
 drivers/net/mlx5/mlx5_flow.h|   2 +
 drivers/net/mlx5/mlx5_rx.h  |   4 +
 drivers/net/mlx5/mlx5_rxq.c |  99 ++--
 drivers/net/mlx5/mlx5_trigger.c |  10 ++
 6 files changed, 276 insertions(+), 34 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index f2b78c3cc6..81fa8845bb 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -321,6 +321,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
info->rx_offload_capa = (mlx5_get_rx_port_offloads() |
 info->rx_queue_offload_capa);
info->tx_offload_capa = mlx5_get_tx_port_offloads(dev);
+   info->dev_capa = RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP;
info->if_index = mlx5_ifindex(dev);
info->reta_size = priv->reta_idx_n ?
priv->reta_idx_n : config->ind_table_max_size;
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 850eb353fd..671a5a34d9 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -1588,6 +1588,58 @@ mlx5_flow_validate_action_queue(const struct 
rte_flow_action *action,
return 0;
 }
 
+/**
+ * Validate queue numbers for device RSS.
+ *
+ * @param[in] dev
+ *   Configured device.
+ * @param[in] queues
+ *   Array of queue numbers.
+ * @param[in] queues_n
+ *   Size of the @p queues array.
+ * @param[out] error
+ *   On error, filled with a textual error description.
+ * @param[out] queue
+ *   On error, filled with an offending queue index in @p queues array.
+ *
+ * @return
+ *   0 on success, a negative errno code on error.
+ */
+static int
+mlx5_validate_rss_queues(const struct rte_eth_dev *dev,
+const uint16_t *queues, uint32_t queues_n,
+const char **error, uint32_t *queue_idx)
+{
+   const struct mlx5_priv *priv = dev->data->dev_private;
+   enum mlx5_rxq_type rxq_type = MLX5_RXQ_TYPE_UNDEFINED;
+   uint32_t i;
+
+   for (i = 0; i != queues_n; ++i) {
+   struct mlx5_rxq_ctrl *rxq_ctrl;
+
+   if (queues[i] >= priv->rxqs_n) {
+   *error = "queue index out of range";
+   *queue_idx = i;
+   return -EINVAL;
+   }
+   if (!(*priv->rxqs)[queues[i]]) {
+   *error =  "queue is not configured";
+   *queue_idx = i;
+   return -EINVAL;
+   }
+   rxq_ctrl = container_of((*priv->rxqs)[queues[i]],
+   struct mlx5_rxq_ctrl, rxq);
+   if (i == 0)
+   rxq_type = rxq_ctrl->type;
+   if (rxq_type != rxq_ctrl->type) {
+   *error = "combining hairpin and regular RSS queues is 
not supported";
+   *queue_idx = i;
+   return -ENOTSUP;
+   }
+   }
+   return 0;
+}
+
 /*
  * Validate the rss action.
  *
@@ -1608,8 +1660,9 @@ mlx5_validate_action_rss(struct rte_eth_dev *dev,
 {
struct mlx5_priv *priv = dev->data->dev_private;
const struct rte_flow_action_rss *rss = action->conf;
-   enum mlx5_rxq_type rxq_type = MLX5_RXQ_TYPE_UNDEFINED;
-   unsigned int i;
+   int ret;
+   const char *message;
+   uint32_t queue_idx;
 
if (rss->func != RTE_ETH_HASH_FUNCTION_DEFAULT &&
rss->func != RTE_ETH_HASH_FUNCTION_TOEPLITZ)
@@ -1673,27 +1726,12 @@ mlx5_validate_action_rss(struct rte_eth_dev *dev,
return rte_flow_error_set(error, EINVAL,
  RTE_FLOW_ERROR_TYPE_ACTION_CONF,
  NULL, "No queues configured");
-   for (i = 0; i != rss->queue_num; ++i) {
-   st

Re: [dpdk-dev] [PATCH] doc: cleanup flow mark Rx offload deprecation notice

[Andrew Rybchenko]

On 11/2/21 4:47 PM, Ferruh Yigit wrote:

On 11/2/2021 12:50 PM, Andrew Rybchenko wrote:

The problem is solved using Rx metadata delivery negotiation API [1].



Can this API replace RX_OFFLOAD_RSS_HASH too?


It can, but it should not. RSS hash is an offload since it is a
calculation of the hash in HW and delivery of the result to SW.
Like checksums: check in HW and delivery of the result to SW.



[1] commit f6d8a6d3fad7 ("ethdev: negotiate delivery of packet 
metadata from HW to PMD")


Signed-off-by: Andrew Rybchenko 
---
  doc/guides/rel_notes/deprecation.rst | 8 
  1 file changed, 8 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst

index 4366015b01..ec5073908f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -69,14 +69,6 @@ Deprecation Notices
    and the related structures (``rte_fdir_*`` and ``rte_eth_fdir_*``),
    will be removed in DPDK 20.11.
-* ethdev: New offload flags ``RTE_ETH_RX_OFFLOAD_FLOW_MARK`` will be 
added in 19.11.

-  This will allow application to enable or disable PMDs from updating
-  ``rte_mbuf::hash::fdir``.
-  This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields 
on Rx and

-  thereby improve Rx performance if application wishes do so.
-  In 19.11 PMDs will still update the field even when the offload is not
-  enabled.
-
  * ethdev: Announce moving from dedicated modify function for each 
field,

    to using the general ``rte_flow_modify_field`` action.

Re: [dpdk-dev] Overriding rte_config.h

[Bruce Richardson]

On Tue, Nov 02, 2021 at 12:24:43PM +, Ananyev, Konstantin wrote:
> 
> > > > On Fri, Oct 29, 2021 at 09:48:30AM -0400, Ben Magistro wrote:
> > > > > With the transition to meson, what is the best way to provide custom 
> > > > > values
> > > > > to parameters in rte_config.h?  When using makefiles, (from memory, I
> > > > > think) we used common_base as a template that was copied in as a
> > > > > replacement for defconfig_x86  Our current thinking is to apply a
> > > > > locally maintained patch so that we can track custom values easier to 
> > > > > the
> > > > > rte_config.h file unless there is another way to pass in an overridden
> > > > > value.  As an example, one of the values we are customizing is
> > > > > IP_FRAG_MAX_FRAG.
> > > > >
> > > > > Cheers,
> > > > >
> > > > There is no one defined way for overriding values in rte_config with the
> > > > meson build system, as values there are ones that should rarely need to 
> > > > be
> > > > overridden. If it's the case that one does need tuning, we generally 
> > > > want
> > > > to look to either change the default so it works for everyone, or
> > > > alternatively look to replace it with a runtime option.
> > > >
> > > > In the absense of that, a locally maintained patch may be reasonable. To
> > > > what value do you want to change MAX_FRAG? Would it be worth 
> > > > considering as
> > > > a newer default value in DPDK itself, since the current default is 
> > > > fairly
> > > > low?
> > >
> > > That might be an option, with IP_FRAG_MAX_FRAG==8 it should be able
> > > to cover common jumbo frame size (9K) pretty easily.
> > > As a drawback default reassembly table size will double.
> >
> > Maybe not. I'm not an expert in the library, but it seems the basic struct
> > used for tracking the packets and fragments is "struct ip_frag_pkt". Due to
> > the other data in the struct and the linked-list overheads, the actual size
> > increase when doubling MAX_FRAG from 4 to 8 is only 25%. According to gdb
> > on my debug build it goes from 192B to 256B.
> 
> Ah yes, you right, struct ip_frag should fit into 16B, key seems the biggest 
> one.
> 
> >
> > > Even better would be to go a step further and rework lib/ip_frag
> > > to make it configurable runtime parameter.
> > >
> > Agree. However, that's not as quick a fix as just increasing the default
> > max segs value which could be done immediately if there is consensus on it.
> 
> You mean for 21.11?
> I don't mind in principle, but would like to know other people thoughts here.
> Another thing -  we didn't announce it in advance, and it is definitely an 
> ABI change.

I notice from this patch you submitted that the main structure in question
is being hidden[1]. Will it still be an ABI change if that patch is merged
in? Alternatively, should a fragment count increase be considered as part of
that change?

/Bruce

[1] 
http://patches.dpdk.org/project/dpdk/patch/20211101124915.9640-1-konstantin.anan...@intel.com/

Re: [dpdk-dev] [PATCH v5 0/6] Flow entites behavior on port restart

[Ferruh Yigit]

On 11/2/2021 1:54 PM, Dmitry Kozlyuk wrote:

It is unspecified whether flow rules and indirect actions are kept
when a port is stopped, possibly reconfigured, and started again.
Vendors approach the topic differently, e.g. mlx5 and i40e PMD
disagree in whether flow rules can be kept, and mlx5 PMD would keep
indirect actions. In the end, applications are greatly affected
by whatever contract there is and need to know it.

Applications may wish to restart the port to reconfigure it,
e.g. switch offloads or even modify queues.
Keeping rte_flow entities enables application improvements:
1. Since keeping the rules across restart comes with the ability
to create rules before the device is started. This allows
to have all the rules created at the moment of start,
so that there is no time frame when traffic is coming already,
but the rules are not yet created (restored).
2. When a rule or an indirect action has some associated state,
such as a counter, application saves the need to keep
additional state in order to cope with information loss
if such an entity would be destroyed.

It is proposed to advertise capabilities of keeping flow rules
and indirect actions (as a special case of shared object)
using a combination of ethdev info and rte_flow calls.
Then a bug is fixed in mlx5 PMD that prevented indirect RSS action
from being kept, and the driver starts advertising the new capability.

Prior discussions:
1) http://inbox.dpdk.org/dev/20210727073121.895620-1-dkozl...@nvidia.com/
2) http://inbox.dpdk.org/dev/20210901085516.3647814-1-dkozl...@nvidia.com/

v5:
  1. Fix rebase conflicts.


I am still getting conflicts. Did you rebase it on top of next-net?

Re: [dpdk-dev] [PATCH] doc: cleanup flow mark Rx offload deprecation notice

[Ferruh Yigit]

On 11/2/2021 2:09 PM, Andrew Rybchenko wrote:

On 11/2/21 4:47 PM, Ferruh Yigit wrote:

On 11/2/2021 12:50 PM, Andrew Rybchenko wrote:

The problem is solved using Rx metadata delivery negotiation API [1].



Can this API replace RX_OFFLOAD_RSS_HASH too?


It can, but it should not. RSS hash is an offload since it is a
calculation of the hash in HW and delivery of the result to SW.
Like checksums: check in HW and delivery of the result to SW.



There is a slight difference, RSS hash is always calculated if RSS is enabled,
independent from RSS offload enabled or not.

That is why some PMDs always provides RSS hash and force enables this offload,
I would be happy to get rid of this quirk if possible.




[1] commit f6d8a6d3fad7 ("ethdev: negotiate delivery of packet metadata from HW to 
PMD")

Signed-off-by: Andrew Rybchenko 
---
  doc/guides/rel_notes/deprecation.rst | 8 
  1 file changed, 8 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 4366015b01..ec5073908f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -69,14 +69,6 @@ Deprecation Notices
    and the related structures (``rte_fdir_*`` and ``rte_eth_fdir_*``),
    will be removed in DPDK 20.11.
-* ethdev: New offload flags ``RTE_ETH_RX_OFFLOAD_FLOW_MARK`` will be added in 
19.11.
-  This will allow application to enable or disable PMDs from updating
-  ``rte_mbuf::hash::fdir``.
-  This scheme will allow PMDs to avoid writes to ``rte_mbuf`` fields on Rx and
-  thereby improve Rx performance if application wishes do so.
-  In 19.11 PMDs will still update the field even when the offload is not
-  enabled.
-
  * ethdev: Announce moving from dedicated modify function for each field,
    to using the general ``rte_flow_modify_field`` action.

[dpdk-dev] [v3] security: add telemetry endpoint for cryptodev security capabilities

[Gowrishankar Muthukrishnan]

Add telemetry endpoint for cryptodev security capabilities.

Signed-off-by: Gowrishankar Muthukrishnan 
---
v3:
 - secure cryptodev capability endpoint is added and endpoints
   renamed.

---
 doc/guides/prog_guide/rte_security.rst |  28 
 doc/guides/rel_notes/release_21_11.rst |   5 +
 lib/security/rte_security.c| 182 +
 3 files changed, 215 insertions(+)

diff --git a/doc/guides/prog_guide/rte_security.rst 
b/doc/guides/prog_guide/rte_security.rst
index 46c9b51d1b..72ca0bd330 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -728,3 +728,31 @@ it is only valid to have a single flow to map to that 
security session.
 +---++++-+
 |  Eth  | ->  ... -> |   ESP  | -> | END |
 +---++++-+
+
+
+Telemetry support
+-
+
+The Security library has support for displaying Crypto device information
+with respect to its Security capabilities. Telemetry commands that can be used
+are shown below.
+
+#. Get the list of available Crypto devices by ID, that supports Security 
features::
+
+ --> /security/cryptodev/list
+ {"/security/cryptodev/list": [0, 1, 2, 3]}
+
+#. Get the security capabilities of a Crypto device::
+
+ --> /security/cryptodev/sec_caps,0
+{"/security/cryptodev/sec_caps": {"sec_caps": [], "sec_caps_n": }}
+
+ #. Get the security crypto capabilities of a Crypto device::
+
+ --> /security/cryptodev/crypto_caps,0,0
+{"/security/cryptodev/crypto_caps": {"crypto_caps": [], "crypto_caps_n": }}
+
+For more information on how to use the Telemetry interface, see
+the :doc:`../howto/telemetry`.
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index 47cd67131e..df768bb1c8 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -197,6 +197,11 @@ New Features
   * Added port representors support on SN1000 SmartNICs
   * Added flow API transfer proxy support
 
+* **Added Telemetry callback to Security library.**
+
+  Added Telemetry callback functions to query security capabilities of
+  Crypto device.
+
 * **Updated Marvell cnxk crypto PMD.**
 
   * Added AES-CBC SHA1-HMAC support in lookaside protocol (IPsec) for CN10K.
diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
index fe81ed3e4c..e92dbf518f 100644
--- a/lib/security/rte_security.c
+++ b/lib/security/rte_security.c
@@ -4,8 +4,10 @@
  * Copyright (c) 2020 Samsung Electronics Co., Ltd All Rights Reserved
  */
 
+#include 
 #include 
 #include 
+#include 
 #include "rte_compat.h"
 #include "rte_security.h"
 #include "rte_security_driver.h"
@@ -203,3 +205,183 @@ rte_security_capability_get(struct rte_security_ctx 
*instance,
 
return NULL;
 }
+
+static int
+security_handle_cryptodev_list(const char *cmd __rte_unused,
+  const char *params __rte_unused,
+  struct rte_tel_data *d)
+{
+   int dev_id;
+
+   if (rte_cryptodev_count() < 1)
+   return -1;
+
+   rte_tel_data_start_array(d, RTE_TEL_INT_VAL);
+   for (dev_id = 0; dev_id < RTE_CRYPTO_MAX_DEVS; dev_id++)
+   if (rte_cryptodev_is_valid_dev(dev_id) &&
+   rte_cryptodev_get_sec_ctx(dev_id))
+   rte_tel_data_add_array_int(d, dev_id);
+
+   return 0;
+}
+
+#define CRYPTO_CAPS_SZ \
+   (RTE_ALIGN_CEIL(sizeof(struct rte_cryptodev_capabilities), \
+   sizeof(uint64_t)) / sizeof(uint64_t))
+
+static int
+crypto_caps_array(struct rte_tel_data *d,
+ const struct rte_cryptodev_capabilities *capabilities)
+{
+   const struct rte_cryptodev_capabilities *dev_caps;
+   uint64_t caps_val[CRYPTO_CAPS_SZ];
+   unsigned int i = 0, j;
+
+   rte_tel_data_start_array(d, RTE_TEL_U64_VAL);
+
+   while ((dev_caps = &capabilities[i++])->op !=
+  RTE_CRYPTO_OP_TYPE_UNDEFINED) {
+   memset(&caps_val, 0, CRYPTO_CAPS_SZ * sizeof(caps_val[0]));
+   rte_memcpy(caps_val, dev_caps, sizeof(capabilities[0]));
+   for (j = 0; j < CRYPTO_CAPS_SZ; j++)
+   rte_tel_data_add_array_u64(d, caps_val[j]);
+   }
+
+   return i;
+}
+
+#define SEC_CAPS_SZ\
+   (RTE_ALIGN_CEIL(sizeof(struct rte_security_capability), \
+   sizeof(uint64_t)) / sizeof(uint64_t))
+
+static int
+sec_caps_array(struct rte_tel_data *d,
+  const struct rte_security_capability *capabilities)
+{
+   const struct rte_security_capability *dev_caps;
+   uint64_t caps_val[SEC_CAPS_SZ];
+   unsigned int i = 0, j;
+
+   rte_tel_data_start_array(d, RTE_TEL_U64_VAL);
+
+   while ((dev_caps = &capabilities[i++])->action !=
+  RTE_SECURITY_

[dpdk-dev] [v4] security: add telemetry endpoint for cryptodev security capabilities

[Gowrishankar Muthukrishnan]

Add telemetry endpoint for cryptodev security capabilities.

Signed-off-by: Gowrishankar Muthukrishnan 
---
v4:
 - fixed typo in help.

---
 doc/guides/prog_guide/rte_security.rst |  28 
 doc/guides/rel_notes/release_21_11.rst |   5 +
 lib/security/rte_security.c| 182 +
 3 files changed, 215 insertions(+)

diff --git a/doc/guides/prog_guide/rte_security.rst 
b/doc/guides/prog_guide/rte_security.rst
index 46c9b51d1b..72ca0bd330 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -728,3 +728,31 @@ it is only valid to have a single flow to map to that 
security session.
 +---++++-+
 |  Eth  | ->  ... -> |   ESP  | -> | END |
 +---++++-+
+
+
+Telemetry support
+-
+
+The Security library has support for displaying Crypto device information
+with respect to its Security capabilities. Telemetry commands that can be used
+are shown below.
+
+#. Get the list of available Crypto devices by ID, that supports Security 
features::
+
+ --> /security/cryptodev/list
+ {"/security/cryptodev/list": [0, 1, 2, 3]}
+
+#. Get the security capabilities of a Crypto device::
+
+ --> /security/cryptodev/sec_caps,0
+{"/security/cryptodev/sec_caps": {"sec_caps": [], "sec_caps_n": }}
+
+ #. Get the security crypto capabilities of a Crypto device::
+
+ --> /security/cryptodev/crypto_caps,0,0
+{"/security/cryptodev/crypto_caps": {"crypto_caps": [], "crypto_caps_n": }}
+
+For more information on how to use the Telemetry interface, see
+the :doc:`../howto/telemetry`.
diff --git a/doc/guides/rel_notes/release_21_11.rst 
b/doc/guides/rel_notes/release_21_11.rst
index 47cd67131e..df768bb1c8 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -197,6 +197,11 @@ New Features
   * Added port representors support on SN1000 SmartNICs
   * Added flow API transfer proxy support
 
+* **Added Telemetry callback to Security library.**
+
+  Added Telemetry callback functions to query security capabilities of
+  Crypto device.
+
 * **Updated Marvell cnxk crypto PMD.**
 
   * Added AES-CBC SHA1-HMAC support in lookaside protocol (IPsec) for CN10K.
diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
index fe81ed3e4c..92aaf1bf76 100644
--- a/lib/security/rte_security.c
+++ b/lib/security/rte_security.c
@@ -4,8 +4,10 @@
  * Copyright (c) 2020 Samsung Electronics Co., Ltd All Rights Reserved
  */
 
+#include 
 #include 
 #include 
+#include 
 #include "rte_compat.h"
 #include "rte_security.h"
 #include "rte_security_driver.h"
@@ -203,3 +205,183 @@ rte_security_capability_get(struct rte_security_ctx 
*instance,
 
return NULL;
 }
+
+static int
+security_handle_cryptodev_list(const char *cmd __rte_unused,
+  const char *params __rte_unused,
+  struct rte_tel_data *d)
+{
+   int dev_id;
+
+   if (rte_cryptodev_count() < 1)
+   return -1;
+
+   rte_tel_data_start_array(d, RTE_TEL_INT_VAL);
+   for (dev_id = 0; dev_id < RTE_CRYPTO_MAX_DEVS; dev_id++)
+   if (rte_cryptodev_is_valid_dev(dev_id) &&
+   rte_cryptodev_get_sec_ctx(dev_id))
+   rte_tel_data_add_array_int(d, dev_id);
+
+   return 0;
+}
+
+#define CRYPTO_CAPS_SZ \
+   (RTE_ALIGN_CEIL(sizeof(struct rte_cryptodev_capabilities), \
+   sizeof(uint64_t)) / sizeof(uint64_t))
+
+static int
+crypto_caps_array(struct rte_tel_data *d,
+ const struct rte_cryptodev_capabilities *capabilities)
+{
+   const struct rte_cryptodev_capabilities *dev_caps;
+   uint64_t caps_val[CRYPTO_CAPS_SZ];
+   unsigned int i = 0, j;
+
+   rte_tel_data_start_array(d, RTE_TEL_U64_VAL);
+
+   while ((dev_caps = &capabilities[i++])->op !=
+  RTE_CRYPTO_OP_TYPE_UNDEFINED) {
+   memset(&caps_val, 0, CRYPTO_CAPS_SZ * sizeof(caps_val[0]));
+   rte_memcpy(caps_val, dev_caps, sizeof(capabilities[0]));
+   for (j = 0; j < CRYPTO_CAPS_SZ; j++)
+   rte_tel_data_add_array_u64(d, caps_val[j]);
+   }
+
+   return i;
+}
+
+#define SEC_CAPS_SZ\
+   (RTE_ALIGN_CEIL(sizeof(struct rte_security_capability), \
+   sizeof(uint64_t)) / sizeof(uint64_t))
+
+static int
+sec_caps_array(struct rte_tel_data *d,
+  const struct rte_security_capability *capabilities)
+{
+   const struct rte_security_capability *dev_caps;
+   uint64_t caps_val[SEC_CAPS_SZ];
+   unsigned int i = 0, j;
+
+   rte_tel_data_start_array(d, RTE_TEL_U64_VAL);
+
+   while ((dev_caps = &capabilities[i++])->action !=
+  RTE_SECURITY_ACTION_TYPE_NONE) {
+   memset(&caps_val

[dpdk-dev] [PATCH] config/x86: add support for AMD platform

[Aman Kumar]

-Dcpu_instruction_set=znverX meson option can be used
to build dpdk for AMD platforms. Supported options are
znver1, znver2 and znver3.

Signed-off-by: Aman Kumar 
---
 config/x86/meson.build  | 9 +
 doc/guides/linux_gsg/build_dpdk.rst | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 29f3dea181..21cda6fd33 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -72,3 +72,12 @@ endif
 dpdk_conf.set('RTE_CACHE_LINE_SIZE', 64)
 dpdk_conf.set('RTE_MAX_LCORE', 128)
 dpdk_conf.set('RTE_MAX_NUMA_NODES', 32)
+
+# AMD platform support
+if get_option('cpu_instruction_set') == 'znver1'
+dpdk_conf.set('RTE_MAX_LCORE', 256)
+elif get_option('cpu_instruction_set') == 'znver2'
+dpdk_conf.set('RTE_MAX_LCORE', 512)
+elif get_option('cpu_instruction_set') == 'znver3'
+dpdk_conf.set('RTE_MAX_LCORE', 512)
+endif
diff --git a/doc/guides/linux_gsg/build_dpdk.rst 
b/doc/guides/linux_gsg/build_dpdk.rst
index 0b08492ca2..e224a06cbd 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -111,7 +111,7 @@ The instruction set will be set automatically by default 
according to these rule
   a common minimal baseline needed for DPDK.
 
 To override what instruction set will be used, set the ``cpu_instruction_set``
-parameter to the instruction set of your choice (such as ``corei7``, 
``power8``, etc.).
+parameter to the instruction set of your choice (such as ``corei7``, 
``power8``, ``znver3``, etc.).
 
 ``cpu_instruction_set`` is not used in Arm builds, as setting the instruction 
set
 without other parameters leads to inferior builds. The way to tailor Arm builds
-- 
2.25.1

Re: [dpdk-dev] [PATCH v2 2/2] bpf: fix convert API can be undefined

[Stephen Hemminger]

On Tue, 2 Nov 2021 10:54:59 +
"Ananyev, Konstantin"  wrote:

> > > rte_bpf_convert() implementation depends on libpcap.
> > > Right now it is defined only when this library is installed and
> > > RTE_PORT_PCAP is defined.
> > > Fix that by providing for such case stub rte_bpf_convert()
> > > implementation that will always return an error.
> > > Also move stub for another function (rte_bpf_elf_load) into
> > > the same place (bpf_stub.c).
> > >
> > > Fixes: 2eccf6afbea9 ("bpf: add function to convert classic BPF to DPDK 
> > > BPF")
> > >
> > > Signed-off-by: Konstantin Ananyev   
> > 
> > Wouldn't it be better to fail compiling a program using unimplemented calls
> > rather than forcing the user to see a failure later?  
> 
> You mean to keep things as they are right now?
> That way we'll have to put #ifdef RTE_PORT_PCAP around every call to 
> bpf_convert().
> Doesn't look like a good thing to me.
> Also in other places we use similar approach: if HW/SW is not available 
> provide
> a dummy implementation that will report an error. 

Is there a way to do both, return an error and report a warning in the build?

Re: [dpdk-dev] Overriding rte_config.h

[Ananyev, Konstantin]

> > > > > On Fri, Oct 29, 2021 at 09:48:30AM -0400, Ben Magistro wrote:
> > > > > > With the transition to meson, what is the best way to provide 
> > > > > > custom values
> > > > > > to parameters in rte_config.h?  When using makefiles, (from memory, 
> > > > > > I
> > > > > > think) we used common_base as a template that was copied in as a
> > > > > > replacement for defconfig_x86  Our current thinking is to apply 
> > > > > > a
> > > > > > locally maintained patch so that we can track custom values easier 
> > > > > > to the
> > > > > > rte_config.h file unless there is another way to pass in an 
> > > > > > overridden
> > > > > > value.  As an example, one of the values we are customizing is
> > > > > > IP_FRAG_MAX_FRAG.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > There is no one defined way for overriding values in rte_config with 
> > > > > the
> > > > > meson build system, as values there are ones that should rarely need 
> > > > > to be
> > > > > overridden. If it's the case that one does need tuning, we generally 
> > > > > want
> > > > > to look to either change the default so it works for everyone, or
> > > > > alternatively look to replace it with a runtime option.
> > > > >
> > > > > In the absense of that, a locally maintained patch may be reasonable. 
> > > > > To
> > > > > what value do you want to change MAX_FRAG? Would it be worth 
> > > > > considering as
> > > > > a newer default value in DPDK itself, since the current default is 
> > > > > fairly
> > > > > low?
> > > >
> > > > That might be an option, with IP_FRAG_MAX_FRAG==8 it should be able
> > > > to cover common jumbo frame size (9K) pretty easily.
> > > > As a drawback default reassembly table size will double.
> > >
> > > Maybe not. I'm not an expert in the library, but it seems the basic struct
> > > used for tracking the packets and fragments is "struct ip_frag_pkt". Due 
> > > to
> > > the other data in the struct and the linked-list overheads, the actual 
> > > size
> > > increase when doubling MAX_FRAG from 4 to 8 is only 25%. According to gdb
> > > on my debug build it goes from 192B to 256B.
> >
> > Ah yes, you right, struct ip_frag should fit into 16B, key seems the 
> > biggest one.
> >
> > >
> > > > Even better would be to go a step further and rework lib/ip_frag
> > > > to make it configurable runtime parameter.
> > > >
> > > Agree. However, that's not as quick a fix as just increasing the default
> > > max segs value which could be done immediately if there is consensus on 
> > > it.
> >
> > You mean for 21.11?
> > I don't mind in principle, but would like to know other people thoughts 
> > here.
> > Another thing -  we didn't announce it in advance, and it is definitely an 
> > ABI change.
> 
> I notice from this patch you submitted that the main structure in question
> is being hidden[1]. Will it still be an ABI change if that patch is merged
> in?

Yes, it would unfortunately:
struct rte_ip_frag_death_row still remains public.

> Alternatively, should a fragment count increase be considered as part of
> that change?

I don't think they are really related.
This patch just hides some structs that are already marked as 'internal'
and not used by public API. It doesn't make any changes in the public structs 
layout.
But I suppose we can bring that question (increase of 
RTE_LIBRTE_IP_FRAG_MAX_FRAG) to
tomorrow TB meeting, and ask for approval.
 
> /Bruce
> 
> [1] 
> http://patches.dpdk.org/project/dpdk/patch/20211101124915.9640-1-konstantin.anan...@intel.com/

Re: [dpdk-dev] [PATCH] config/x86: add support for AMD platform

[Thomas Monjalon]

02/11/2021 15:52, Aman Kumar:
> -Dcpu_instruction_set=znverX meson option can be used
> to build dpdk for AMD platforms. Supported options are
> znver1, znver2 and znver3.
> 
> Signed-off-by: Aman Kumar 
> ---
> +# AMD platform support
> +if get_option('cpu_instruction_set') == 'znver1'
> +dpdk_conf.set('RTE_MAX_LCORE', 256)
> +elif get_option('cpu_instruction_set') == 'znver2'
> +dpdk_conf.set('RTE_MAX_LCORE', 512)
> +elif get_option('cpu_instruction_set') == 'znver3'
> +dpdk_conf.set('RTE_MAX_LCORE', 512)
> +endif

Ideally we should try getting rid of this config
and make all structs depending on max lcores allocated dynamically.
I think it may be an interesting target for next year 22.11 release.

About the patch itself, I am OK to merge it in 21.11-rc2.

Re: [dpdk-dev] [PATCH v2] net/af_packet: fix ignoring full ring on tx

[Tudor Cornea]

On Tue, 26 Oct 2021 at 17:41, Ferruh Yigit  wrote:

> Hi Tudor,
>
> I have used testpmd, 'txonly' forwarding. Tx recovers after interface up,
> but by adding some debug logs I can see 'poll()' returns with POLLOUT even
> there is no space in the buffer.
>
> According the logic in the PMD, when 'poll()' returns success, it expects
> to have some space in the Tx buffer.
>
> So I agree to add the check.
>
> Only have a question on the POLLERR, should we separate the POLLERR check
> to cover ifdown case, what do you think about following logic:
>
> if (!TP_STATUS_AVAILABLE) {
>  if (poll() < 0)
>  break;
>  if (pfd.revents & POLLERR)
>  break;
> }
>
> if (!TP_STATUS_AVAILABLE)
>  break;
>
>
Hi Ferruh,

Thanks for the suggestion.
I was thinking of adding this check, and intuitively, it seems correct. I
tried to do some further testing.

I tested with the POLLERR check, and I don't see the issue anymore.
However, if I remove the second if (!TP_STATUS_AVAILABLE), I seem to get
bursts of 2048 packets followed by periods of not sending anything when
toggling the interface link state.
Without the second if(!TP_STATUS_AVAILABLE) statement, the issue seems to
reproduce, regardless if I add the check for POLLERR or not.

RxB=0 RxP=0 TxB=0 TxP=0
RxB=0 RxP=0 TxB=0 TxP=0
RxB=0 RxP=0 TxB=0 TxP=0
RxB=0 RxP=0 TxB=0 TxP=0
RxB=0 RxP=0 TxB=0 TxP=0
RxB=0 RxP=0 TxB=0 TxP=0
RxB=0 RxP=0 TxB=0 TxP=0
RxB=0 RxP=0 TxB=606208 TxP=2048
RxB=0 RxP=0 TxB=0 TxP=0
RxB=0 RxP=0 TxB=0 TxP=0

I will send an updated version of the patch.

Thanks,
Tudor

Re: [dpdk-dev] [PATCH v2 2/2] bpf: fix convert API can be undefined

[Stephen Hemminger]

On Mon,  1 Nov 2021 16:10:13 +
Konstantin Ananyev  wrote:

> rte_bpf_convert() implementation depends on libpcap.
> Right now it is defined only when this library is installed and
> RTE_PORT_PCAP is defined.
> Fix that by providing for such case stub rte_bpf_convert()
> implementation that will always return an error.
> Also move stub for another function (rte_bpf_elf_load) into
> the same place (bpf_stub.c).
> 
> Fixes: 2eccf6afbea9 ("bpf: add function to convert classic BPF to DPDK BPF")
> 
> Signed-off-by: Konstantin Ananyev 

Should also change dumpcap to print more complete error?


diff --git a/app/dumpcap/main.c b/app/dumpcap/main.c
index baf9eee4..fff460eee518 100644
--- a/app/dumpcap/main.c
+++ b/app/dumpcap/main.c
@@ -285,7 +285,7 @@ static void compile_filter(void)
bpf_prm = rte_bpf_convert(&bf);
if (bpf_prm == NULL)
rte_exit(EXIT_FAILURE,
-"bpf convert failed\n");
+"bpf convert failed: %s\n", rte_strerror(rte_errno));
 
if (dump_bpf) {
printf("cBPF program (%u insns)\n", bf.bf_len);

Re: [dpdk-dev] [PATCH v2 1/6] dma/dpaa: introduce DPAA DMA driver

[Thomas Monjalon]

02/11/2021 09:51, fengchengwen:
> On 2021/11/1 16:51, Gagandeep Singh wrote:
> > The DPAA DMA  driver is an implementation of the dmadev APIs,
> > that provide means to initiate a DMA transaction from CPU.
> > The initiated DMA is performed without CPU being involved
> > in the actual DMA transaction. This is achieved via using
> > the QDMA controller of DPAA SoC.
> > 
> > Signed-off-by: Gagandeep Singh 
> 
> [snip]
> 
> > +DPDK_22 {
> > +
> > +   local: *;
> > +};
> > diff --git a/drivers/dma/meson.build b/drivers/dma/meson.build
> > index a69418ce9b..ab2733f7f6 100644
> > --- a/drivers/dma/meson.build
> > +++ b/drivers/dma/meson.build
> > @@ -5,5 +5,6 @@ drivers = [
> >  'idxd',
> >  'ioat',
> >  'skeleton',
> > +   'dpaa',
> 
> suggest use space replace tab, and add dpaa before skeleton

I think alphabetically sorted would be better?

Re: [dpdk-dev] [PATCH] ethdev: fine tune error reporting in pick transfer proxy API

[Thomas Monjalon]

01/11/2021 10:41, Andrew Rybchenko:
> On 10/27/21 12:00 PM, Ivan Malov wrote:
> > There are PMDs which do not support flow offloads at all.
> > In such cases, the API in question returns ENOTSUP. This
> > is too loud. Restructure the code to avoid spamming logs.
> > 
> > Fixes: 1179f05cc9a0 ("ethdev: query proxy port to manage transfer flows")
> > 
> > Signed-off-by: Ivan Malov 
> > ---
> >   lib/ethdev/rte_flow.c | 5 +
> >   1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
> > index d268784532..9d98d2d716 100644
> > --- a/lib/ethdev/rte_flow.c
> > +++ b/lib/ethdev/rte_flow.c
> > @@ -1335,10 +1335,7 @@ rte_flow_pick_transfer_proxy(uint16_t port_id, 
> > uint16_t *proxy_port_id,
> > const struct rte_flow_ops *ops = rte_flow_ops_get(port_id, error);
> > struct rte_eth_dev *dev;
> >   
> > -   if (unlikely(ops == NULL))
> > -   return -rte_errno;
> > -
> > -   if (ops->pick_transfer_proxy == NULL) {
> > +   if (ops == NULL || ops->pick_transfer_proxy == NULL) {
> 
> First of all I think that the patch is wrong and origin code is better.
> If flow API is not supported at all (ops == NULL), what's the point
> to return some proxy port?
> 
> > *proxy_port_id = port_id;
> > return 0;
> > }
> > 
> 
> IMHO, spamming of testpmd logs in described case should be fixed
> in testpmd itself to avoid logs in the case of ENOTSUP. That's it.

I think we should not call this API in testpmd
if not doing rte_flow transfer rule.

[dpdk-dev] [PATCH v3] net/af_packet: fix ignoring full ring on tx

[Tudor Cornea]

The poll call can return POLLERR which is ignored, or it can return
POLLOUT, even if there are no free frames in the mmap-ed area.

We can account for both of these cases by re-checking if the next
frame is empty before writing into it.

We have attempted to reproduce this issue with pktgen-dpdk, using the
following configuration.

pktgen -l 1-4 -n 4 --proc-type=primary --no-pci --no-telemetry \
--no-huge -m 512 \
--vdev=net_af_packet0,iface=eth1,blocksz=16384,framesz=8192, \
framecnt=2048,qpairs=1,qdisc_bypass=0 \
-- \
-P \
-T \
-m "3.0" \
-f themes/black-yellow.theme

We configure a low tx rate (~ 335 packets / second) and a small
packet size, of about 300 Bytes from the pktgen CLI.

set 0 size 300
set 0 rate 0.008
set 0 burst 1
start 0

After bringing the interface down, and up again, we seem to arrive
in a state in which the tx rate is inconsistent, and does not recover.

ifconfig eth1 down; sleep 7; ifconfig eth1 up

[1] http://code.dpdk.org/pktgen-dpdk/pktgen-20.11.2/source/INSTALL.md

Signed-off-by: Mihai Pogonaru 
Signed-off-by: Tudor Cornea 

---
v2:
* Added check for POLLERR
* Used tx_ring_status_available() for checking TP_STATUS_AVAILABLE
---
 drivers/net/af_packet/rte_eth_af_packet.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index 559f5a0..d3d3104 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -237,8 +237,30 @@ eth_af_packet_tx(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
}
 
/* point at the next incoming frame */
-   if (!tx_ring_status_available(ppd->tp_status) &&
-   poll(&pfd, 1, -1) < 0)
+   if (!tx_ring_status_available(ppd->tp_status)) {
+   if (poll(&pfd, 1, -1) < 0)
+   break;
+   if (pfd.revents & POLLERR)
+   break;
+   }
+
+   /*
+* Poll can return POLLERR if the interface is down
+*
+* It will almost always return POLLOUT, even if there
+* are no extra buffers available
+*
+* This happens, because packet_poll() calls datagram_poll()
+* which checks the space left in the socket buffer and,
+* in the case of packet_mmap, the default socket buffer length
+* doesn't match the requested size for the tx_ring.
+* As such, there is almost always space left in socket buffer,
+* which doesn't seem to be correlated to the requested size
+* for the tx_ring in packet_mmap.
+*
+* This results in poll() returning POLLOUT.
+*/
+   if (!tx_ring_status_available(ppd->tp_status))
break;
 
/* copy the tx frame data */
-- 
2.7.4

[dpdk-dev] [PATCH] meson.build: replace tabs with spaces

[Stephen Hemminger]

Per the meson recommendation the meson.build file
should be indented with spaces not tabs.
This patch is semi-automatically generated by running
all the meson.build files through expand command.

Signed-off-by: Stephen Hemminger 
---
Note: if users (like me) just editconfig setup in their
favorite editor, this would not be a problem.

Also, shouldn't checkpatch be made smarter to catch this?

 app/pdump/meson.build |  6 +--
 app/proc-info/meson.build |  6 +--
 app/test-acl/meson.build  |  6 +--
 app/test-bbdev/meson.build|  8 ++--
 app/test-cmdline/meson.build  |  6 +--
 app/test-compress-perf/meson.build|  6 +--
 app/test-crypto-perf/meson.build  |  6 +--
 app/test-eventdev/meson.build |  6 +--
 app/test-fib/meson.build  |  6 +--
 app/test-flow-perf/meson.build|  6 +--
 app/test-pipeline/meson.build |  6 +--
 app/test-regex/meson.build|  6 +--
 app/test-sad/meson.build  |  6 +--
 app/test/meson.build  |  6 +--
 config/meson.build| 60 +--
 drivers/compress/octeontx/meson.build |  6 +--
 drivers/crypto/cnxk/meson.build   |  6 +--
 drivers/crypto/ipsec_mb/meson.build   | 38 -
 drivers/crypto/qat/meson.build|  2 +-
 drivers/net/ice/meson.build   |  2 +-
 20 files changed, 100 insertions(+), 100 deletions(-)

diff --git a/app/pdump/meson.build b/app/pdump/meson.build
index db1fcadbfe2c..b8a507f4e190 100644
--- a/app/pdump/meson.build
+++ b/app/pdump/meson.build
@@ -2,9 +2,9 @@
 # Copyright(c) 2018 Intel Corporation
 
 if is_windows
-   build = false
-   reason = 'not supported on Windows'
-   subdir_done()
+build = false
+reason = 'not supported on Windows'
+subdir_done()
 endif
 
 sources = files('main.c')
diff --git a/app/proc-info/meson.build b/app/proc-info/meson.build
index 82ed05bb0b4e..6c6933ac78f2 100644
--- a/app/proc-info/meson.build
+++ b/app/proc-info/meson.build
@@ -2,9 +2,9 @@
 # Copyright(c) 2018 Intel Corporation
 
 if is_windows
-   build = false
-   reason = 'not supported on Windows'
-   subdir_done()
+build = false
+reason = 'not supported on Windows'
+subdir_done()
 endif
 
 sources = files('main.c')
diff --git a/app/test-acl/meson.build b/app/test-acl/meson.build
index 14d36b33e930..57ce1b18180e 100644
--- a/app/test-acl/meson.build
+++ b/app/test-acl/meson.build
@@ -2,9 +2,9 @@
 # Copyright(c) 2019 Intel Corporation
 
 if is_windows
-   build = false
-   reason = 'not supported on Windows'
-   subdir_done()
+build = false
+reason = 'not supported on Windows'
+subdir_done()
 endif
 
 sources = files('main.c')
diff --git a/app/test-bbdev/meson.build b/app/test-bbdev/meson.build
index a726a5b3fa2a..9a5bdcbd5725 100644
--- a/app/test-bbdev/meson.build
+++ b/app/test-bbdev/meson.build
@@ -2,9 +2,9 @@
 # Copyright(c) 2018 Intel Corporation
 
 if is_windows
-   build = false
-   reason = 'not supported on Windows'
-   subdir_done()
+build = false
+reason = 'not supported on Windows'
+subdir_done()
 endif
 
 sources = files(
@@ -24,5 +24,5 @@ if dpdk_conf.has('RTE_BASEBAND_ACC100')
 deps += ['baseband_acc100']
 endif
 if dpdk_conf.has('RTE_LIBRTE_PMD_BBDEV_LA12XX')
-   deps += ['baseband_la12xx']
+deps += ['baseband_la12xx']
 endif
diff --git a/app/test-cmdline/meson.build b/app/test-cmdline/meson.build
index 08988212000a..0e6c75accb9c 100644
--- a/app/test-cmdline/meson.build
+++ b/app/test-cmdline/meson.build
@@ -2,9 +2,9 @@
 # Copyright(c) 2019 Intel Corporation
 
 if is_windows
-   build = false
-   reason = 'not supported on Windows'
-   subdir_done()
+build = false
+reason = 'not supported on Windows'
+subdir_done()
 endif
 
 sources = files('commands.c', 'cmdline_test.c')
diff --git a/app/test-compress-perf/meson.build 
b/app/test-compress-perf/meson.build
index f29c6ee86390..52de7d0d103c 100644
--- a/app/test-compress-perf/meson.build
+++ b/app/test-compress-perf/meson.build
@@ -2,9 +2,9 @@
 # Copyright(c) 2018 Intel Corporation
 
 if is_windows
-   build = false
-   reason = 'not supported on Windows'
-   subdir_done()
+build = false
+reason = 'not supported on Windows'
+subdir_done()
 endif
 
 sources = files(
diff --git a/app/test-crypto-perf/meson.build b/app/test-crypto-perf/meson.build
index ef3582a87c86..6685aaf07775 100644
--- a/app/test-crypto-perf/meson.build
+++ b/app/test-crypto-perf/meson.build
@@ -2,9 +2,9 @@
 # Copyright(c) 2018 Intel Corporation
 
 if is_windows
-   build = false
-   reason = 'not supported on Windows'
-   subdir_done()
+build = false
+reason = 'not supported on Windows'
+subdir_done()
 endif
 
 sources = files(
diff --git a/app/test-eventdev/meson.build b/app/test-eventde