Re: [dpdk-dev] [PATCH] net/iavf: remove interrupt handler

[Zhang, Qi Z]

> -Original Message-
> From: Zhang, RobinX 
> Sent: Friday, July 23, 2021 3:47 PM
> To: dev@dpdk.org
> Cc: Wu, Jingjing ; Xing, Beilei 
> ;
> Zhang, Qi Z ; Guo, Junfeng ;
> Yang, SteveX ; Zhang, RobinX
> 
> Subject: [PATCH] net/iavf: remove interrupt handler

As you are not going to remove interrupt handler for all the cases, the title 
is misleading
Better replace it with "enable interrupt polling"

> 
> For VF hosted by Intel 700 series NICs, internal rx interrupt and adminq
> interrupt share the same source, that cause a lot cpu cycles be wasted on
> interrupt handler on rx path.
> 
> The patch disable pci interrupt and remove the interrupt handler, replace it
> with a low frequency(50ms) interrupt polling daemon which is implemtented by
> registering an alarm callback periodly.
> 
> The virtual channel capability bit VIRTCHNL_VF_OFFLOAD_WB_ON_ITR can be
> used to negotiate if iavf PMD needs to enable background alarm or not, so
> ideally this change will not impact the case hosted by Intel 800 series NICS.
> 
> Suggested-by: Jingjing Wu 
> Signed-off-by: Qi Zhang 

No need to add me as the author for this patch but, you can add a reference to 
the original i40e commit to explain you implement the same logic.

> Signed-off-by: Robin Zhang 
> ---
>  drivers/net/iavf/iavf.h|  3 +++
>  drivers/net/iavf/iavf_ethdev.c | 37 ++
>  drivers/net/iavf/iavf_vchnl.c  | 11 --
>  3 files changed, 22 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h index
> b3bd078111..771f3b79d7 100644
> --- a/drivers/net/iavf/iavf.h
> +++ b/drivers/net/iavf/iavf.h
> @@ -69,6 +69,8 @@
>  #define IAVF_QUEUE_ITR_INTERVAL_DEFAULT 32 /* 32 us */
>  #define IAVF_QUEUE_ITR_INTERVAL_MAX 8160 /* 8160 us */
> 
> +#define IAVF_ALARM_INTERVAL 5 /* us */
> +
>  /* The overhead from MTU to max frame size.
>   * Considering QinQ packet, the VLAN tag needs to be counted twice.
>   */
> @@ -372,6 +374,7 @@ int iavf_config_irq_map_lv(struct iavf_adapter
> *adapter, uint16_t num,  void iavf_add_del_all_mac_addr(struct iavf_adapter
> *adapter, bool add);  int iavf_dev_link_update(struct rte_eth_dev *dev,
>   __rte_unused int wait_to_complete);
> +void iavf_dev_alarm_handler(void *param);
>  int iavf_query_stats(struct iavf_adapter *adapter,
>   struct virtchnl_eth_stats **pstats);  int
> iavf_config_promisc(struct iavf_adapter *adapter, bool enable_unicast, diff
> --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c index
> 41382c6d66..bbe5b3ddb1 100644
> --- a/drivers/net/iavf/iavf_ethdev.c
> +++ b/drivers/net/iavf/iavf_ethdev.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -692,9 +693,9 @@ static int iavf_config_rx_queues_irqs(struct
> rte_eth_dev *dev,
>*/
>   vf->msix_base = IAVF_MISC_VEC_ID;
> 
> - /* set ITR to max */
> + /* set ITR to default */
>   interval = iavf_calc_itr_interval(
> - IAVF_QUEUE_ITR_INTERVAL_MAX);
> + IAVF_QUEUE_ITR_INTERVAL_DEFAULT);
>   IAVF_WRITE_REG(hw, IAVF_VFINT_DYN_CTL01,
>  IAVF_VFINT_DYN_CTL01_INTENA_MASK |
>  (IAVF_ITR_INDEX_DEFAULT <<
> @@ -853,9 +854,8 @@ iavf_dev_start(struct rte_eth_dev *dev)
>   PMD_DRV_LOG(ERR, "configure irq failed");
>   goto err_queue;
>   }
> - /* re-enable intr again, because efd assign may change */
> + /* only enable interrupt in rx interrupt mode */
>   if (dev->data->dev_conf.intr_conf.rxq != 0) {
> - rte_intr_disable(intr_handle);
>   rte_intr_enable(intr_handle);
>   }
> 
> @@ -889,6 +889,9 @@ iavf_dev_stop(struct rte_eth_dev *dev)
> 
>   PMD_INIT_FUNC_TRACE();
> 
> + if (dev->data->dev_conf.intr_conf.rxq != 0)
> + rte_intr_disable(intr_handle);
> +
>   if (adapter->stopped == 1)
>   return 0;
> 
> @@ -1669,8 +1672,6 @@ iavf_dev_rx_queue_intr_enable(struct rte_eth_dev
> *dev, uint16_t queue_id)
> 
>   IAVF_WRITE_FLUSH(hw);
> 
> - rte_intr_ack(&pci_dev->intr_handle);
> -
>   return 0;
>  }
> 
> @@ -2201,8 +2202,8 @@ iavf_disable_irq0(struct iavf_hw *hw)
>   IAVF_WRITE_FLUSH(hw);
>  }
> 
> -static void
> -iavf_dev_interrupt_handler(void *param)
> +void
> +iavf_dev_alarm_handler(void *param)
>  {
>   struct rte_eth_dev *dev = (struct rte_eth_dev *)param;
>   struct iavf_hw *hw =
> IAVF_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> @@ -2212,6 +2213,9 @@ iavf_dev_interrupt_handler(void *param)
>   iavf_handle_virtchnl_msg(dev);
> 
>   iavf_enable_irq0(hw);
> +
> + rte_eal_alarm_set(IAVF_ALARM_INTERVAL,
> +   iavf_dev_alarm_handler, d

[dpdk-dev] [PATCH] net/octeontx2: configure MTU value correctly

[Hanumanth Reddy Pothula]

Update MTU value based on PTP enable status and reserve eight
bytes in TX path to accommodate VLAN tags.

If PTP is enabled maximum allowed MTU is 9200 otherwise it's 9208.

Signed-off-by: Hanumanth Reddy Pothula 
---
 drivers/net/octeontx2/otx2_ethdev_ops.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/octeontx2/otx2_ethdev_ops.c 
b/drivers/net/octeontx2/otx2_ethdev_ops.c
index 5a4501208e..552e6bd43d 100644
--- a/drivers/net/octeontx2/otx2_ethdev_ops.c
+++ b/drivers/net/octeontx2/otx2_ethdev_ops.c
@@ -17,7 +17,8 @@ otx2_nix_mtu_set(struct rte_eth_dev *eth_dev, uint16_t mtu)
struct nix_frs_cfg *req;
int rc;
 
-   frame_size += NIX_TIMESYNC_RX_OFFSET * otx2_ethdev_is_ptp_en(dev);
+   if (dev->configured && otx2_ethdev_is_ptp_en(dev))
+   frame_size += NIX_TIMESYNC_RX_OFFSET;
 
/* Check if MTU is within the allowed range */
if (frame_size < NIX_MIN_FRS || frame_size > NIX_MAX_FRS)
@@ -547,6 +548,11 @@ otx2_nix_info_get(struct rte_eth_dev *eth_dev, struct 
rte_eth_dev_info *devinfo)
devinfo->max_vfs = pci_dev->max_vfs;
devinfo->max_mtu = devinfo->max_rx_pktlen - NIX_L2_OVERHEAD;
devinfo->min_mtu = devinfo->min_rx_bufsize - NIX_L2_OVERHEAD;
+   if (dev->configured && otx2_ethdev_is_ptp_en(dev)) {
+   devinfo->max_mtu -=  NIX_TIMESYNC_RX_OFFSET;
+   devinfo->min_mtu -=  NIX_TIMESYNC_RX_OFFSET;
+   devinfo->max_rx_pktlen -= NIX_TIMESYNC_RX_OFFSET;
+   }
 
devinfo->rx_offload_capa = dev->rx_offload_capa;
devinfo->tx_offload_capa = dev->tx_offload_capa;
-- 
2.25.1

Re: [dpdk-dev] [External] Re: [PATCH v2] app/testpmd: flowgen support ip and udp fields

[王志宏]

Hi Aman,

On Mon, Aug 9, 2021 at 8:21 PM Singh, Aman Deep
 wrote:
>
> Hi Wang,
>
> On 8/9/2021 12:22 PM, Zhihong Wang wrote:
>
> This patch aims to:
>  1. Add flexibility by supporting IP & UDP src/dst fields
>  2. Improve multi-core performance by using per-core vars
>
> v2: fix assigning ip header cksum
>
> Signed-off-by: Zhihong Wang 
> ---
>  
>
> From defination of flowgen as per the documentation-
>
> flowgen: Multi-flow generation mode. Originates a number of flows (with 
> varying destination IP addresses), and terminate receive traffic.
>
> So changing the src IP address may not fit the defination of a source 
> generating real traffic.
>
> I would like to check this part further.

Thanks for the review. The purpose of introducing them is to emulate
pkt generators behaviors.

Do you think keeping cfg_n_ip_src & cfg_n_udp_src while setting them =
1 by default makes sense? Or maybe update the documentation?

[dpdk-dev] [PATCH v3 0/2] Use macro to print MAC address

[Aman Singh]

Added macros to simplyfy print of MAC address.
The other method of first formatting mac address
into a string and string printed, is avoided.

Aman Singh (2):
  net: macro for MAC address print
  net: macro to extract MAC address bytes

 app/pdump/main.c  |  5 +---
 app/test-pmd/cmdline.c|  6 ++--
 app/test-pmd/config.c |  6 ++--
 app/test-pmd/testpmd.c|  9 ++
 app/test/test_event_eth_rx_adapter.c  |  5 +---
 app/test/test_event_eth_tx_adapter.c  |  5 +---
 drivers/bus/dpaa/base/fman/netcfg_layer.c |  9 ++
 drivers/common/mlx5/linux/mlx5_nl.c   |  6 ++--
 drivers/net/bnx2x/bnx2x.c |  4 +--
 drivers/net/bnx2x/bnx2x_vfpf.c| 10 ++-
 drivers/net/bnx2x/ecore_sp.c  | 14 -
 drivers/net/bnxt/bnxt_ethdev.c|  2 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c |  4 +--
 drivers/net/bonding/rte_eth_bond_pmd.c| 12 +++-
 drivers/net/dpaa/dpaa_ethdev.c| 10 ++-
 drivers/net/e1000/igb_ethdev.c|  9 ++
 drivers/net/enic/base/vnic_dev.c  |  4 +--
 drivers/net/enic/enic_res.c   |  2 +-
 drivers/net/failsafe/failsafe.c   |  6 ++--
 drivers/net/hinic/hinic_pmd_ethdev.c  |  6 ++--
 drivers/net/i40e/i40e_ethdev_vf.c | 21 --
 drivers/net/iavf/iavf_ethdev.c| 18 +++-
 drivers/net/iavf/iavf_vchnl.c | 15 +++---
 drivers/net/ice/ice_dcf.c |  6 ++--
 drivers/net/ixgbe/ixgbe_ethdev.c  | 29 ---
 drivers/net/mlx4/mlx4.c   |  7 ++---
 drivers/net/mlx5/linux/mlx5_os.c  |  7 ++---
 drivers/net/mlx5/windows/mlx5_os.c|  7 ++---
 drivers/net/mvpp2/mrvl_flow.c |  4 +--
 drivers/net/netvsc/hn_rndis.c |  2 +-
 drivers/net/nfp/nfp_net.c |  2 +-
 drivers/net/qede/base/ecore_mcp.c |  2 +-
 drivers/net/qede/base/ecore_sriov.c   |  2 +-
 drivers/net/qede/qede_ethdev.c|  9 ++
 drivers/net/thunderx/nicvf_ethdev.c   |  2 +-
 drivers/net/txgbe/txgbe_ethdev_vf.c   | 29 ---
 drivers/net/virtio/virtio_ethdev.c|  4 +--
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |  4 +--
 examples/bbdev_app/main.c |  9 ++
 examples/bond/main.c  |  3 +-
 examples/distributor/main.c   |  5 +---
 examples/ethtool/ethtool-app/ethapp.c | 10 ++-
 .../pipeline_worker_generic.c |  5 +---
 .../eventdev_pipeline/pipeline_worker_tx.c|  5 +---
 examples/flow_classify/flow_classify.c|  5 +---
 examples/ioat/ioatfwd.c   |  9 ++
 examples/ip_pipeline/cli.c| 11 ++-
 examples/l2fwd-cat/l2fwd-cat.c|  5 +---
 examples/l2fwd-crypto/main.c  | 11 ++-
 examples/l2fwd-event/l2fwd_common.c   |  9 ++
 examples/l2fwd-jobstats/main.c| 11 ++-
 examples/l2fwd-keepalive/main.c   |  9 ++
 examples/l2fwd/main.c | 11 ++-
 examples/link_status_interrupt/main.c |  9 ++
 examples/packet_ordering/main.c   |  5 +---
 examples/pipeline/cli.c   |  6 ++--
 examples/rxtx_callbacks/main.c|  4 +--
 examples/server_node_efd/server/main.c|  6 ++--
 examples/skeleton/basicfwd.c  |  5 +---
 examples/vhost/main.c | 17 +++
 examples/vm_power_manager/channel_monitor.c   |  4 +--
 .../guest_cli/vm_power_cli_guest.c|  5 +---
 examples/vm_power_manager/main.c  |  5 +---
 examples/vmdq/main.c  | 14 ++---
 examples/vmdq_dcb/main.c  | 14 ++---
 lib/net/rte_ether.h   | 14 +
 lib/vhost/vhost_user.c|  2 +-
 67 files changed, 155 insertions(+), 377 deletions(-)

-- 
2.17.1

[dpdk-dev] [PATCH v3 1/2] net: macro for MAC address print

[Aman Singh]

Added macro to print six bytes of MAC address.
The MAC addresses will be printed in lower case
hexdecimal format.
In case there is a specific check for upper case
MAC address, the user may need to make a change in
such test case after this patch.

Signed-off-by: Aman Singh 
---
 app/test-pmd/cmdline.c|  2 +-
 app/test-pmd/config.c |  2 +-
 app/test-pmd/testpmd.c|  2 +-
 drivers/bus/dpaa/base/fman/netcfg_layer.c |  2 +-
 drivers/common/mlx5/linux/mlx5_nl.c   |  2 +-
 drivers/net/bnx2x/bnx2x.c |  4 ++--
 drivers/net/bnx2x/bnx2x_vfpf.c|  3 ++-
 drivers/net/bnx2x/ecore_sp.c  | 14 +++---
 drivers/net/bnxt/bnxt_ethdev.c|  2 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c |  4 ++--
 drivers/net/bonding/rte_eth_bond_pmd.c|  4 ++--
 drivers/net/dpaa/dpaa_ethdev.c|  2 +-
 drivers/net/e1000/igb_ethdev.c|  2 +-
 drivers/net/enic/base/vnic_dev.c  |  4 ++--
 drivers/net/enic/enic_res.c   |  2 +-
 drivers/net/failsafe/failsafe.c   |  2 +-
 drivers/net/hinic/hinic_pmd_ethdev.c  |  2 +-
 drivers/net/i40e/i40e_ethdev_vf.c |  6 +++---
 drivers/net/iavf/iavf_ethdev.c|  4 ++--
 drivers/net/iavf/iavf_vchnl.c |  4 ++--
 drivers/net/ice/ice_dcf.c |  2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c  |  6 +++---
 drivers/net/mlx4/mlx4.c   |  2 +-
 drivers/net/mlx5/linux/mlx5_os.c  |  2 +-
 drivers/net/mlx5/windows/mlx5_os.c|  2 +-
 drivers/net/mvpp2/mrvl_flow.c |  4 ++--
 drivers/net/netvsc/hn_rndis.c |  2 +-
 drivers/net/nfp/nfp_net.c |  2 +-
 drivers/net/qede/base/ecore_mcp.c |  2 +-
 drivers/net/qede/base/ecore_sriov.c   |  2 +-
 drivers/net/qede/qede_ethdev.c|  2 +-
 drivers/net/thunderx/nicvf_ethdev.c   |  2 +-
 drivers/net/txgbe/txgbe_ethdev_vf.c   |  6 +++---
 drivers/net/virtio/virtio_ethdev.c|  4 ++--
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |  4 ++--
 examples/bbdev_app/main.c |  2 +-
 examples/ethtool/ethtool-app/ethapp.c |  2 +-
 examples/ioat/ioatfwd.c   |  2 +-
 examples/ip_pipeline/cli.c|  4 ++--
 examples/l2fwd-crypto/main.c  |  2 +-
 examples/l2fwd-event/l2fwd_common.c   |  2 +-
 examples/l2fwd-jobstats/main.c|  2 +-
 examples/l2fwd-keepalive/main.c   |  2 +-
 examples/l2fwd/main.c |  2 +-
 examples/link_status_interrupt/main.c |  2 +-
 examples/pipeline/cli.c   |  2 +-
 examples/server_node_efd/server/main.c|  2 +-
 examples/vhost/main.c |  2 +-
 examples/vmdq/main.c  |  2 +-
 examples/vmdq_dcb/main.c  |  2 +-
 lib/net/rte_ether.h   |  5 +
 lib/vhost/vhost_user.c|  2 +-
 52 files changed, 79 insertions(+), 73 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 82253bc751..d4186eb9b2 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -10899,7 +10899,7 @@ static void cmd_mcast_addr_parsed(void *parsed_result,
 
if (!rte_is_multicast_ether_addr(&res->mc_addr)) {
fprintf(stderr,
-   "Invalid multicast addr 
%02X:%02X:%02X:%02X:%02X:%02X\n",
+   "Invalid multicast addr " RTE_ETHER_ADDR_PRT_FMT "\n",
res->mc_addr.addr_bytes[0], res->mc_addr.addr_bytes[1],
res->mc_addr.addr_bytes[2], res->mc_addr.addr_bytes[3],
res->mc_addr.addr_bytes[4], res->mc_addr.addr_bytes[5]);
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 31d8ba1b91..21d5db5297 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -782,7 +782,7 @@ port_summary_display(portid_t port_id)
if (ret != 0)
return;
 
-   printf("%-4d %02X:%02X:%02X:%02X:%02X:%02X %-12s %-14s %-8s %s\n",
+   printf("%-4d " RTE_ETHER_ADDR_PRT_FMT " %-12s %-14s %-8s %s\n",
port_id, mac_addr.addr_bytes[0], mac_addr.addr_bytes[1],
mac_addr.addr_bytes[2], mac_addr.addr_bytes[3],
mac_addr.addr_bytes[4], mac_addr.addr_bytes[5], name,
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 6cbe9ba3c8..d0ede963ea 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2622,7 +2622,7 @@ start_port(portid_t pid)
pi);
 
if (eth_macaddr_get_print_err(pi, &port->eth_addr) == 0)
-   printf("Port %d: %02X:%02X:%02X:%02X:%02X:%02X\n", pi,
+   printf("Port %d: " RTE_ETHER_ADDR_PRT_FMT "\n", pi,
port->eth_addr.addr_bytes[0],
port->eth_addr.addr_bytes[1],
   

[dpdk-dev] [PATCH v3 2/2] net: macro to extract MAC address bytes

[Aman Singh]

Added macros to simplyfy print of MAC address.
The other method of first formatting mac address
into a string and string printed, is avoided.

Signed-off-by: Aman Singh 
---
The change in the document will be done in seperate patch.
To ensure document has direct reference of the code.

V2: Fix build issue in examples code
V3: Fix Windows compilation issue
---
 app/pdump/main.c  |  5 +---
 app/test-pmd/cmdline.c|  4 +---
 app/test-pmd/config.c |  4 +---
 app/test-pmd/testpmd.c|  7 +-
 app/test/test_event_eth_rx_adapter.c  |  5 +---
 app/test/test_event_eth_tx_adapter.c  |  5 +---
 drivers/bus/dpaa/base/fman/netcfg_layer.c |  7 +-
 drivers/common/mlx5/linux/mlx5_nl.c   |  4 +---
 drivers/net/bnx2x/bnx2x_vfpf.c|  7 +-
 drivers/net/bonding/rte_eth_bond_pmd.c|  8 ++-
 drivers/net/dpaa/dpaa_ethdev.c|  8 +--
 drivers/net/e1000/igb_ethdev.c|  7 +-
 drivers/net/failsafe/failsafe.c   |  4 +---
 drivers/net/hinic/hinic_pmd_ethdev.c  |  4 +---
 drivers/net/i40e/i40e_ethdev_vf.c | 15 +++-
 drivers/net/iavf/iavf_ethdev.c| 14 ++-
 drivers/net/iavf/iavf_vchnl.c | 11 ++---
 drivers/net/ice/ice_dcf.c |  4 +---
 drivers/net/ixgbe/ixgbe_ethdev.c  | 23 +++
 drivers/net/mlx4/mlx4.c   |  5 +---
 drivers/net/mlx5/linux/mlx5_os.c  |  5 +---
 drivers/net/mlx5/windows/mlx5_os.c|  5 +---
 drivers/net/qede/qede_ethdev.c|  7 +-
 drivers/net/txgbe/txgbe_ethdev_vf.c   | 23 +++
 examples/bbdev_app/main.c |  7 +-
 examples/bond/main.c  |  3 +--
 examples/distributor/main.c   |  5 +---
 examples/ethtool/ethtool-app/ethapp.c |  8 +--
 .../pipeline_worker_generic.c |  5 +---
 .../eventdev_pipeline/pipeline_worker_tx.c|  5 +---
 examples/flow_classify/flow_classify.c|  5 +---
 examples/ioat/ioatfwd.c   |  7 +-
 examples/ip_pipeline/cli.c|  9 ++--
 examples/l2fwd-cat/l2fwd-cat.c|  5 +---
 examples/l2fwd-crypto/main.c  |  9 ++--
 examples/l2fwd-event/l2fwd_common.c   |  7 +-
 examples/l2fwd-jobstats/main.c|  9 ++--
 examples/l2fwd-keepalive/main.c   |  7 +-
 examples/l2fwd/main.c |  9 ++--
 examples/link_status_interrupt/main.c |  7 +-
 examples/packet_ordering/main.c   |  5 +---
 examples/pipeline/cli.c   |  4 +---
 examples/rxtx_callbacks/main.c|  4 +---
 examples/server_node_efd/server/main.c|  4 +---
 examples/skeleton/basicfwd.c  |  5 +---
 examples/vhost/main.c | 15 +++-
 examples/vm_power_manager/channel_monitor.c   |  4 +---
 .../guest_cli/vm_power_cli_guest.c|  5 +---
 examples/vm_power_manager/main.c  |  5 +---
 examples/vmdq/main.c  | 12 ++
 examples/vmdq_dcb/main.c  | 12 ++
 lib/net/rte_ether.h   |  9 
 52 files changed, 77 insertions(+), 305 deletions(-)

diff --git a/app/pdump/main.c b/app/pdump/main.c
index 63bbe65cd8..46f9d25db0 100644
--- a/app/pdump/main.c
+++ b/app/pdump/main.c
@@ -612,10 +612,7 @@ configure_vdev(uint16_t port_id)
 
printf("Port %u MAC: %02"PRIx8" %02"PRIx8" %02"PRIx8
" %02"PRIx8" %02"PRIx8" %02"PRIx8"\n",
-   port_id,
-   addr.addr_bytes[0], addr.addr_bytes[1],
-   addr.addr_bytes[2], addr.addr_bytes[3],
-   addr.addr_bytes[4], addr.addr_bytes[5]);
+   port_id, RTE_ETHER_ADDR_BYTES(&addr));
 
ret = rte_eth_promiscuous_enable(port_id);
if (ret != 0) {
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d4186eb9b2..a5d6c20be1 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -10900,9 +10900,7 @@ static void cmd_mcast_addr_parsed(void *parsed_result,
if (!rte_is_multicast_ether_addr(&res->mc_addr)) {
fprintf(stderr,
"Invalid multicast addr " RTE_ETHER_ADDR_PRT_FMT "\n",
-   res->mc_addr.addr_bytes[0], res->mc_addr.addr_bytes[1],
-   res->mc_addr.addr_bytes[2], res->mc_addr.addr_bytes[3],
-   res->mc_addr.addr_bytes[4], res->mc_addr.addr_bytes[5]);
+   RTE_ETHER_ADDR_BYTES(&res->mc_addr));
return;
}
if (strcmp(res->what, "add") == 0)
diff --git a/app/test-pmd/config.c b/ap

Re: [dpdk-dev] [PATCH] net/iavf: support FDIR L3 fields for IP fragment packets

[Zhang, Qi Z]

> -Original Message-
> From: Wu, Wenjun1 
> Sent: Monday, August 2, 2021 3:58 PM
> To: dev@dpdk.org; Wu, Jingjing ; Xing, Beilei
> ; Zhang, Qi Z 
> Cc: Wu, Wenjun1 
> Subject: [PATCH] net/iavf: support FDIR L3 fields for IP fragment packets
> 
> Add support of FDIR L3 fields for both IPv4 and IPv6 fragment packets.
> 
> Signed-off-by: Wenjun Wu 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [dpdk-dev] [PATCH] net/bonding:fix balance-xor link down stack overflow

[Min Hu (Connor)]

Hi,
Your patch is OK, but the description is misleading and has
syntax errors. Please fix it ,thanks.

在 2021/8/10 14:43, jilei 写道:

When slave link down, deactivate_slave will internals->active_slaves
and internals->active_slave_count.Active_slave in bond_ethdev_rx_burst
may out of range in internals->active_slaves.It will get bond's port_id
cause stack overflow

Cc: sta...@dpdk.org
Signed-off-by: jilei 
---
  drivers/net/bonding/rte_eth_bond_pmd.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
b/drivers/net/bonding/rte_eth_bond_pmd.c
index a6755661c4..46f2c42d60 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -82,7 +82,7 @@ bond_ethdev_rx_burst(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
 bufs + num_rx_total, nb_pkts);
num_rx_total += num_rx_slave;
nb_pkts -= num_rx_slave;
-   if (++active_slave == slave_count)
+   if (++active_slave >= slave_count)
active_slave = 0;
}
  

Re: [dpdk-dev] [PATCH] net/i40e: fix clang warning on non-x86

[Zhang, Qi Z]

> -Original Message-
> From: Ruifeng Wang 
> Sent: Friday, July 30, 2021 5:33 PM
> To: Xing, Beilei ; Yu, DapengX
> ; Zhang, Qi Z 
> Cc: dev@dpdk.org; tho...@monjalon.net; david.march...@redhat.com;
> n...@arm.com; Ruifeng Wang 
> Subject: [PATCH] net/i40e: fix clang warning on non-x86
> 
> Build on aarch64 with clang-10 has warning:
> i40e_rxtx.c:3228:1: warning: unused function 'get_avx_supported'
> [-Wunused-function]
> 
> The function is used in x86 specific path. Moved it into ifdef to fix build on
> non-x86.
> 
> Fixes: c30751afc360 ("net/i40e: fix data path selection in secondary process")
> Cc: dapengx...@intel.com
> 
> Signed-off-by: Ruifeng Wang 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [dpdk-dev] [External] Re: [PATCH v2] app/testpmd: flowgen support ip and udp fields

[王志宏]

Thanks for the review Ferruh :)

On Mon, Aug 9, 2021 at 11:18 PM Ferruh Yigit  wrote:
>
> On 8/9/2021 7:52 AM, Zhihong Wang wrote:
> > This patch aims to:
> >  1. Add flexibility by supporting IP & UDP src/dst fields
>
> What is the reason/"use case" of this flexibility?

The purpose is to emulate pkt generator behaviors.

>
> >  2. Improve multi-core performance by using per-core vars>
>
> On multi core this also has syncronization problem, OK to make it per-core. Do
> you have any observed performance difference, if so how much is it?

Huge difference, one example: 8 core flowgen -> rxonly results: 43
Mpps (per-core) vs. 9.3 Mpps (shared), of course the numbers "varies
depending on system configuration".

>
> And can you please separate this to its own patch? This can be before ip/udp 
> update.

Will do.

>
> > v2: fix assigning ip header cksum
> >
>
> +1 to update, can you please make it as seperate patch?

Sure.

>
> So overall this can be a patchset with 4 patches:
> 1- Fix retry logic (nb_rx -> nb_pkt)
> 2- Use 'rte_ipv4_cksum()' API (instead of static 'ip_sum()')
> 3- User per-core varible (for 'next_flow')
> 4- Support ip/udp src/dst variaty of packets
>

Great summary. Thanks a lot.

> > Signed-off-by: Zhihong Wang 
> > ---
> >  app/test-pmd/flowgen.c | 137 
> > +++--
> >  1 file changed, 86 insertions(+), 51 deletions(-)
> >
>
> <...>
>
> > @@ -185,30 +193,57 @@ pkt_burst_flow_gen(struct fwd_stream *fs)
> >   }
> >   pkts_burst[nb_pkt] = pkt;
> >
> > - next_flow = (next_flow + 1) % cfg_n_flows;
> > + if (++next_udp_dst < cfg_n_udp_dst)
> > + continue;
> > + next_udp_dst = 0;
> > + if (++next_udp_src < cfg_n_udp_src)
> > + continue;
> > + next_udp_src = 0;
> > + if (++next_ip_dst < cfg_n_ip_dst)
> > + continue;
> > + next_ip_dst = 0;
> > + if (++next_ip_src < cfg_n_ip_src)
> > + continue;
> > + next_ip_src = 0;
>
> What is the logic here, can you please clarifiy the packet generation logic 
> both
> in a comment here and in the commit log?

It's round-robin field by field. Will add the comments.

>
> >   }
> >
> >   nb_tx = rte_eth_tx_burst(fs->tx_port, fs->tx_queue, pkts_burst, 
> > nb_pkt);
> >   /*
> >* Retry if necessary
> >*/
> > - if (unlikely(nb_tx < nb_rx) && fs->retry_enabled) {
> > + if (unlikely(nb_tx < nb_pkt) && fs->retry_enabled) {
> >   retry = 0;
> > - while (nb_tx < nb_rx && retry++ < burst_tx_retry_num) {
> > + while (nb_tx < nb_pkt && retry++ < burst_tx_retry_num) {
> >   rte_delay_us(burst_tx_delay_time);
> >   nb_tx += rte_eth_tx_burst(fs->tx_port, fs->tx_queue,
> > - &pkts_burst[nb_tx], nb_rx - nb_tx);
> > + &pkts_burst[nb_tx], nb_pkt - nb_tx);
> >   }
>
> +1 to this fix, thanks for it. But can you please make a seperate patch for
> this, with proper 'Fixes:' tag etc..

Ok.

>
> >   }
> > - fs->tx_packets += nb_tx;
> >
> >   inc_tx_burst_stats(fs, nb_tx);
> > - if (unlikely(nb_tx < nb_pkt)) {
> > - /* Back out the flow counter. */
> > - next_flow -= (nb_pkt - nb_tx);
> > - while (next_flow < 0)
> > - next_flow += cfg_n_flows;
> > + fs->tx_packets += nb_tx;
> > + /* Catch up flow idx by actual sent. */
> > + for (i = 0; i < nb_tx; ++i) {
> > + RTE_PER_LCORE(_next_udp_dst) = RTE_PER_LCORE(_next_udp_dst) + 
> > 1;
> > + if (RTE_PER_LCORE(_next_udp_dst) < cfg_n_udp_dst)
> > + continue;
> > + RTE_PER_LCORE(_next_udp_dst) = 0;
> > + RTE_PER_LCORE(_next_udp_src) = RTE_PER_LCORE(_next_udp_src) + 
> > 1;
> > + if (RTE_PER_LCORE(_next_udp_src) < cfg_n_udp_src)
> > + continue;
> > + RTE_PER_LCORE(_next_udp_src) = 0;
> > + RTE_PER_LCORE(_next_ip_dst) = RTE_PER_LCORE(_next_ip_dst) + 1;
> > + if (RTE_PER_LCORE(_next_ip_dst) < cfg_n_ip_dst)
> > + continue;
> > + RTE_PER_LCORE(_next_ip_dst) = 0;
> > + RTE_PER_LCORE(_next_ip_src) = RTE_PER_LCORE(_next_ip_src) + 1;
> > + if (RTE_PER_LCORE(_next_ip_src) < cfg_n_ip_src)
> > + continue;
> > + RTE_PER_LCORE(_next_ip_src) = 0;
> > + }
>
> Why per-core variables are not used in forward function, but local variables
> (like 'next_ip_src' etc..) used? Is it for the performance, if so what is the
> impact?
>
> And why not directly assign from local variables to per-core variables, but 
> have
> above catch up loop?
>
>

Local vars are for generating pkts, global ones catch up finally when
nb_tx is clea

[dpdk-dev] [Bug 786] dynamic memory model may cause potential DMA silent error

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=786

Bug ID: 786
   Summary: dynamic memory model may cause potential DMA silent
error
   Product: DPDK
   Version: unspecified
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: core
  Assignee: dev@dpdk.org
  Reporter: changpeng@intel.com
  Target Milestone: ---

We found that in some very rare situations the vfio dynamic memory model has an
issue which may result the DMA engine doesn't put the data to the right IO
buffer, here is the tests we do to identify the issue:

1. Start the application and call rte_zmalloc to allocate IO buffers.
Hotplug one NVMe drive, then DPDK will register existing memory region to
kernel vfio driver via dma_map ioctl, we added one trace before this ioctl:
DPDK dma_map vaddr: 0x2020, iova: 0x2020, size: 0x1420,
ret: 0

2. Then we call rte_free to free some memory buffers, and DPDK will call
dma_unmap to vfio driver and release related huge files:
DPDK dma_unmap iova: 0x2a40, size: 0x0, ret: 0

Here we saw that the return value is 0, which means success, but the unmap size
is 0, the kernel vfio driver didn't do the real unmap action, because the IOVA
range isn't same with the previous map one. The new DPDK version will print an
error for this case now.

3. Then we call rte_zmalloc again, DPDK will create new huge files and remap to
the previous virtual address, and then call dma_map to register to kernel vfio
driver:

DPDK dma_map vaddr: 0x2a40, iova: 0x2a40, size: 0x40,
ret=-1, errno was set to EEXIST

but DPDK will ignore this errno, so rte_zmalloc will return success.

Then if the new malloced memory was used as NVMe IO buffer, the DMA engine may
move data to the previous pinned pages, because the kernel vfio driver didn't
update the memory map, but all the IO stack will not print any warning log.

We can use static memory model as a workaround.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[dpdk-dev] request for upstreaming MTU changes

[Hanumanth Reddy Pothula]

Hello Team,

Please help in upstreaming the attached changes.
With this change, MTU will be configured correctly.

Regards,
Hanumanth

[dpdk-dev] [PATCH] net/bonding:fix balance-xor link down stack overflow

[jilei]

When slave link down, deactivate_slave will internals->active_slaves
and internals->active_slave_count.Active_slave in bond_ethdev_rx_burst
may out of range in internals->active_slaves.It will get bond's port_id
cause stack overflow

Cc: sta...@dpdk.org
Signed-off-by: jilei 
---
 drivers/net/bonding/rte_eth_bond_pmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
b/drivers/net/bonding/rte_eth_bond_pmd.c
index a6755661c4..46f2c42d60 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -82,7 +82,7 @@ bond_ethdev_rx_burst(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
 bufs + num_rx_total, nb_pkts);
num_rx_total += num_rx_slave;
nb_pkts -= num_rx_slave;
-   if (++active_slave == slave_count)
+   if (++active_slave >= slave_count)
active_slave = 0;
}
 
-- 
2.23.0

Re: [dpdk-dev] [RFC] ethdev: change queue release callback

[Ferruh Yigit]

On 8/10/2021 9:03 AM, Xueming(Steven) Li wrote:
> Hi Singh and Ferruh,
> 
>> -Original Message-
>> From: Ferruh Yigit 
>> Sent: Monday, August 9, 2021 11:31 PM
>> To: Singh, Aman Deep ; Andrew Rybchenko 
>> ; Xueming(Steven) Li
>> 
>> Cc: dev@dpdk.org; Slava Ovsiienko ; 
>> NBU-Contact-Thomas Monjalon 
>> Subject: Re: [dpdk-dev] [RFC] ethdev: change queue release callback
>>
>> On 8/9/2021 3:39 PM, Singh, Aman Deep wrote:
>>> Hi Xueming,
>>>
>>> On 7/28/2021 1:10 PM, Andrew Rybchenko wrote:
 On 7/27/21 6:41 AM, Xueming Li wrote:
> To align with other eth device queue configuration callbacks, change
> RX and TX queue release callback API parameter from queue object to
> device and queue index.
>
> Signed-off-by: Xueming Li 

 In fact, there is no strong reasons to do it, but I think it is a
 nice cleanup to use (dev + queue index) on control path.

 Hopefully it will not result in any regressions.
>>>
>>> Combined there are 100+ API's for Rx/Tx queue_release that need to be
>>> modified for it.
>>>
>>> I believe all regression possibilities here will be caught, in
>>> compilation phase itself.
>>>
>>
>> Same here, it is a good cleanup but there is no strong reason for it.
>>
>> Since it is all internal, there is no ABI restriction on the patch, and 
>> v21.11 will be full ABI break patches, to not cause conflicts with this
>> change, what would you think to have it on v22.02?
> 
> This patch is required by shared-rxq feature which ABI broken, target to 
> 21.11.

Why it is required?

> I'll do it carefully, fortunately, the change is straightforward.
> 

Re: [dpdk-dev] [External] Re: [PATCH v2] app/testpmd: flowgen support ip and udp fields

[Ferruh Yigit]

On 8/10/2021 8:57 AM, 王志宏 wrote:
> Thanks for the review Ferruh :)
> 
> On Mon, Aug 9, 2021 at 11:18 PM Ferruh Yigit  wrote:
>>
>> On 8/9/2021 7:52 AM, Zhihong Wang wrote:
>>> This patch aims to:
>>>  1. Add flexibility by supporting IP & UDP src/dst fields
>>
>> What is the reason/"use case" of this flexibility?
> 
> The purpose is to emulate pkt generator behaviors.
> 

'flowgen' forwarding is already to emulate pkt generator, but it was only
changing destination IP.

What additional benefit does changing udp ports of the packets brings? What is
your usecase for this change?

>>
>>>  2. Improve multi-core performance by using per-core vars>
>>
>> On multi core this also has syncronization problem, OK to make it per-core. 
>> Do
>> you have any observed performance difference, if so how much is it?
> 
> Huge difference, one example: 8 core flowgen -> rxonly results: 43
> Mpps (per-core) vs. 9.3 Mpps (shared), of course the numbers "varies
> depending on system configuration".
> 

Thanks for clarification.

>>
>> And can you please separate this to its own patch? This can be before ip/udp 
>> update.
> 
> Will do.
> 
>>
>>> v2: fix assigning ip header cksum
>>>
>>
>> +1 to update, can you please make it as seperate patch?
> 
> Sure.
> 
>>
>> So overall this can be a patchset with 4 patches:
>> 1- Fix retry logic (nb_rx -> nb_pkt)
>> 2- Use 'rte_ipv4_cksum()' API (instead of static 'ip_sum()')
>> 3- User per-core varible (for 'next_flow')
>> 4- Support ip/udp src/dst variaty of packets
>>
> 
> Great summary. Thanks a lot.
> 
>>> Signed-off-by: Zhihong Wang 
>>> ---
>>>  app/test-pmd/flowgen.c | 137 
>>> +++--
>>>  1 file changed, 86 insertions(+), 51 deletions(-)
>>>
>>
>> <...>
>>
>>> @@ -185,30 +193,57 @@ pkt_burst_flow_gen(struct fwd_stream *fs)
>>>   }
>>>   pkts_burst[nb_pkt] = pkt;
>>>
>>> - next_flow = (next_flow + 1) % cfg_n_flows;
>>> + if (++next_udp_dst < cfg_n_udp_dst)
>>> + continue;
>>> + next_udp_dst = 0;
>>> + if (++next_udp_src < cfg_n_udp_src)
>>> + continue;
>>> + next_udp_src = 0;
>>> + if (++next_ip_dst < cfg_n_ip_dst)
>>> + continue;
>>> + next_ip_dst = 0;
>>> + if (++next_ip_src < cfg_n_ip_src)
>>> + continue;
>>> + next_ip_src = 0;
>>
>> What is the logic here, can you please clarifiy the packet generation logic 
>> both
>> in a comment here and in the commit log?
> 
> It's round-robin field by field. Will add the comments.
> 

Thanks. If the receiving end is doing RSS based on IP address, dst address will
change in every 100 packets and src will change in every 1 packets. This is
a slight behavior change.

When it was only dst ip, it was simple to just increment it, not sure about it
in this case. I wonder if we should set all randomly for each packet. I don't
know what is the better logic here, we can discuss it more in the next version.

>>
>>>   }
>>>
>>>   nb_tx = rte_eth_tx_burst(fs->tx_port, fs->tx_queue, pkts_burst, 
>>> nb_pkt);
>>>   /*
>>>* Retry if necessary
>>>*/
>>> - if (unlikely(nb_tx < nb_rx) && fs->retry_enabled) {
>>> + if (unlikely(nb_tx < nb_pkt) && fs->retry_enabled) {
>>>   retry = 0;
>>> - while (nb_tx < nb_rx && retry++ < burst_tx_retry_num) {
>>> + while (nb_tx < nb_pkt && retry++ < burst_tx_retry_num) {
>>>   rte_delay_us(burst_tx_delay_time);
>>>   nb_tx += rte_eth_tx_burst(fs->tx_port, fs->tx_queue,
>>> - &pkts_burst[nb_tx], nb_rx - nb_tx);
>>> + &pkts_burst[nb_tx], nb_pkt - nb_tx);
>>>   }
>>
>> +1 to this fix, thanks for it. But can you please make a seperate patch for
>> this, with proper 'Fixes:' tag etc..
> 
> Ok.
> 
>>
>>>   }
>>> - fs->tx_packets += nb_tx;
>>>
>>>   inc_tx_burst_stats(fs, nb_tx);
>>> - if (unlikely(nb_tx < nb_pkt)) {
>>> - /* Back out the flow counter. */
>>> - next_flow -= (nb_pkt - nb_tx);
>>> - while (next_flow < 0)
>>> - next_flow += cfg_n_flows;
>>> + fs->tx_packets += nb_tx;
>>> + /* Catch up flow idx by actual sent. */
>>> + for (i = 0; i < nb_tx; ++i) {
>>> + RTE_PER_LCORE(_next_udp_dst) = RTE_PER_LCORE(_next_udp_dst) + 
>>> 1;
>>> + if (RTE_PER_LCORE(_next_udp_dst) < cfg_n_udp_dst)
>>> + continue;
>>> + RTE_PER_LCORE(_next_udp_dst) = 0;
>>> + RTE_PER_LCORE(_next_udp_src) = RTE_PER_LCORE(_next_udp_src) + 
>>> 1;
>>> + if (RTE_PER_LCORE(_next_udp_src) < cfg_n_udp_src)
>>> + continue;
>>> + RTE_PER_LCORE(_next_udp_src) = 0;
>>> + RTE_PER_LCORE(_next_ip_dst) = RTE_PER_LCORE(_

[dpdk-dev] [PATCH] net/bnxt: fix to reset Rx next consumer index

[Somnath Kotur]

In bnxt_init_one_rx_ring(), reset this variable internal to the driver
ring to 0, so that there is no mismatch with actual value in HW on
traffic resumption.

Fixes: 03c8f2fe111c ("net/bnxt: detect bad opaque in Rx completion")
Cc: sta...@dpdk.org

Signed-off-by: Somnath Kotur 
Reviewed-by: Kalesh AP 
Reviewed-by: Ajit Khaparde 
---
 drivers/net/bnxt/bnxt_rxr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/bnxt/bnxt_rxr.c b/drivers/net/bnxt/bnxt_rxr.c
index aea71703d1..73fbdd17d1 100644
--- a/drivers/net/bnxt/bnxt_rxr.c
+++ b/drivers/net/bnxt/bnxt_rxr.c
@@ -1379,6 +1379,9 @@ int bnxt_init_one_rx_ring(struct bnxt_rx_queue *rxq)
}
PMD_DRV_LOG(DEBUG, "TPA alloc Done!\n");
 
+   /* Explicitly reset this driver internal tracker on a ring init */
+   rxr->rx_next_cons = 0;
+
return 0;
 }
 
-- 
2.28.0.497.g54e85e7

Re: [dpdk-dev] [PATCH] net/mlx5: fix matching on eCPRI

[Matan Azrad]

From: Dmitry Kozlyuk
> When an ETH or VLAN flow item directly preceding ECPRI (i. e. a pattern for
> eCPRI over Ethernet) did not specify the eCPRI protocol, matches were not
> restricted to eCPRI traffic. For example, "eth / ecpri / end"
> pattern behaved as "eth / end". Implicitly add Ethernet type condition, so
> that "eth / ecpri / end" behaves as "eth type is 0xAEFE / end".
> 
> Fixes: daa38a8924a0 ("net/mlx5: add flow translation of eCPRI header")
> Cc: bi...@nvidia.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Dmitry Kozlyuk 
Acked-by: Matan Azrad 

[dpdk-dev] [PATCH v14 0/6] support dmadev

[Chengwen Feng]

This patch set contains six patch for new add dmadev.

Chengwen Feng (6):
  dmadev: introduce DMA device library public APIs
  dmadev: introduce DMA device library internal header
  dmadev: introduce DMA device library PMD header
  dmadev: introduce DMA device library implementation
  doc: add DMA device library guide
  maintainers: add for dmadev

---
v14:
* rte_dmadev_vchan_setup add vchan parameter.
* rename max_vchans to nb_vchans of struct rte_dmadev_conf.
* fix dmadev programming guide doxygen warning.
v13:
* add dmadev_i1.svg.
* delete one unnecessary comment line of rte_dmadev_info_get.
v12:
* add max_sges filed for struct rte_dmadev_info.
* add more descriptor of dmadev.rst.
* replace scatter with scatter gather in code comment.
* split to six patch.
* fix typo.
v11:
* rename RTE_DMA_STATUS_UNKNOWN to RTE_DMA_STATUS_ERROR_UNKNOWN.
* add RTE_DMA_STATUS_INVALID_ADDR marco.
* update release-note.
* add acked-by for 1/2 patch.
* add dmadev programming guide which is 2/2 patch.
v10:
* fix rte_dmadev_completed_status comment.

 MAINTAINERS  |5 +
 config/rte_config.h  |3 +
 doc/api/doxy-api-index.md|1 +
 doc/api/doxy-api.conf.in |1 +
 doc/guides/prog_guide/dmadev.rst |  126 
 doc/guides/prog_guide/img/dmadev.svg |  283 +
 doc/guides/prog_guide/index.rst  |1 +
 lib/dmadev/meson.build   |7 +
 lib/dmadev/rte_dmadev.c  |  567 ++
 lib/dmadev/rte_dmadev.h  | 1058 ++
 lib/dmadev/rte_dmadev_core.h |  182 ++
 lib/dmadev/rte_dmadev_pmd.h  |   72 +++
 lib/dmadev/version.map   |   36 ++
 lib/meson.build  |1 +
 14 files changed, 2343 insertions(+)
 create mode 100644 doc/guides/prog_guide/dmadev.rst
 create mode 100644 doc/guides/prog_guide/img/dmadev.svg
 create mode 100644 lib/dmadev/meson.build
 create mode 100644 lib/dmadev/rte_dmadev.c
 create mode 100644 lib/dmadev/rte_dmadev.h
 create mode 100644 lib/dmadev/rte_dmadev_core.h
 create mode 100644 lib/dmadev/rte_dmadev_pmd.h
 create mode 100644 lib/dmadev/version.map

-- 
2.8.1

[dpdk-dev] [PATCH v14 6/6] maintainers: add for dmadev

[Chengwen Feng]

This patch add Chengwen Feng as dmadev's maintainer.

Signed-off-by: Chengwen Feng 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 266f5ac..fd9feb1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -496,6 +496,11 @@ F: drivers/raw/skeleton/
 F: app/test/test_rawdev.c
 F: doc/guides/prog_guide/rawdev.rst
 
+DMA device API - EXPERIMENTAL
+M: Chengwen Feng 
+F: lib/dmadev/
+F: doc/guides/prog_guide/dmadev.rst
+
 
 Memory Pool Drivers
 ---
-- 
2.8.1

[dpdk-dev] [PATCH v14 2/6] dmadev: introduce DMA device library internal header

[Chengwen Feng]

This patch introduce DMA device library internal header, which contains
internal data types that are used by the DMA devices in order to expose
their ops to the class.

Signed-off-by: Chengwen Feng 
Acked-by: Bruce Richardson 
Acked-by: Morten Brørup 
---
 lib/dmadev/meson.build   |   1 +
 lib/dmadev/rte_dmadev_core.h | 180 +++
 2 files changed, 181 insertions(+)
 create mode 100644 lib/dmadev/rte_dmadev_core.h

diff --git a/lib/dmadev/meson.build b/lib/dmadev/meson.build
index 6d5bd85..f421ec1 100644
--- a/lib/dmadev/meson.build
+++ b/lib/dmadev/meson.build
@@ -2,3 +2,4 @@
 # Copyright(c) 2021 HiSilicon Limited.
 
 headers = files('rte_dmadev.h')
+indirect_headers += files('rte_dmadev_core.h')
diff --git a/lib/dmadev/rte_dmadev_core.h b/lib/dmadev/rte_dmadev_core.h
new file mode 100644
index 000..ff7b70a
--- /dev/null
+++ b/lib/dmadev/rte_dmadev_core.h
@@ -0,0 +1,180 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 HiSilicon Limited.
+ * Copyright(c) 2021 Intel Corporation.
+ */
+
+#ifndef _RTE_DMADEV_CORE_H_
+#define _RTE_DMADEV_CORE_H_
+
+/**
+ * @file
+ *
+ * RTE DMA Device internal header.
+ *
+ * This header contains internal data types, that are used by the DMA devices
+ * in order to expose their ops to the class.
+ *
+ * Applications should not use these API directly.
+ *
+ */
+
+struct rte_dmadev;
+
+typedef int (*rte_dmadev_info_get_t)(const struct rte_dmadev *dev,
+struct rte_dmadev_info *dev_info,
+uint32_t info_sz);
+/**< @internal Used to get device information of a device. */
+
+typedef int (*rte_dmadev_configure_t)(struct rte_dmadev *dev,
+ const struct rte_dmadev_conf *dev_conf);
+/**< @internal Used to configure a device. */
+
+typedef int (*rte_dmadev_start_t)(struct rte_dmadev *dev);
+/**< @internal Used to start a configured device. */
+
+typedef int (*rte_dmadev_stop_t)(struct rte_dmadev *dev);
+/**< @internal Used to stop a configured device. */
+
+typedef int (*rte_dmadev_close_t)(struct rte_dmadev *dev);
+/**< @internal Used to close a configured device. */
+
+typedef int (*rte_dmadev_vchan_setup_t)(struct rte_dmadev *dev, uint16_t vchan,
+   const struct rte_dmadev_vchan_conf *conf);
+/**< @internal Used to allocate and set up a virtual DMA channel. */
+
+typedef int (*rte_dmadev_stats_get_t)(const struct rte_dmadev *dev,
+   uint16_t vchan, struct rte_dmadev_stats *stats,
+   uint32_t stats_sz);
+/**< @internal Used to retrieve basic statistics. */
+
+typedef int (*rte_dmadev_stats_reset_t)(struct rte_dmadev *dev, uint16_t 
vchan);
+/**< @internal Used to reset basic statistics. */
+
+typedef int (*rte_dmadev_dump_t)(const struct rte_dmadev *dev, FILE *f);
+/**< @internal Used to dump internal information. */
+
+typedef int (*rte_dmadev_selftest_t)(uint16_t dev_id);
+/**< @internal Used to start dmadev selftest. */
+
+typedef int (*rte_dmadev_copy_t)(struct rte_dmadev *dev, uint16_t vchan,
+rte_iova_t src, rte_iova_t dst,
+uint32_t length, uint64_t flags);
+/**< @internal Used to enqueue a copy operation. */
+
+typedef int (*rte_dmadev_copy_sg_t)(struct rte_dmadev *dev, uint16_t vchan,
+   const struct rte_dmadev_sge *src,
+   const struct rte_dmadev_sge *dst,
+   uint16_t nb_src, uint16_t nb_dst,
+   uint64_t flags);
+/**< @internal Used to enqueue a scatter-gather list copy operation. */
+
+typedef int (*rte_dmadev_fill_t)(struct rte_dmadev *dev, uint16_t vchan,
+uint64_t pattern, rte_iova_t dst,
+uint32_t length, uint64_t flags);
+/**< @internal Used to enqueue a fill operation. */
+
+typedef int (*rte_dmadev_submit_t)(struct rte_dmadev *dev, uint16_t vchan);
+/**< @internal Used to trigger hardware to begin working. */
+
+typedef uint16_t (*rte_dmadev_completed_t)(struct rte_dmadev *dev,
+   uint16_t vchan, const uint16_t nb_cpls,
+   uint16_t *last_idx, bool *has_error);
+/**< @internal Used to return number of successful completed operations. */
+
+typedef uint16_t (*rte_dmadev_completed_status_t)(struct rte_dmadev *dev,
+   uint16_t vchan, const uint16_t nb_cpls,
+   uint16_t *last_idx, enum rte_dma_status_code *status);
+/**< @internal Used to return number of completed operations. */
+
+/**
+ * Possible states of a DMA device.
+ */
+enum rte_dmadev_state {
+   RTE_DMADEV_UNUSED = 0,
+   /**< Device is unused before being probed. */
+   RTE_DMADEV_ATTACHED,
+   /**< Device is attached when allocated in probing. */
+};
+
+/**
+ * DMA device operations function pointer table

[dpdk-dev] [PATCH v14 3/6] dmadev: introduce DMA device library PMD header

[Chengwen Feng]

This patch introduce DMA device library PMD header which was driver
facing APIs for a DMA device.

Signed-off-by: Chengwen Feng 
Acked-by: Bruce Richardson 
Acked-by: Morten Brørup 
---
 lib/dmadev/meson.build  |  1 +
 lib/dmadev/rte_dmadev.h |  2 ++
 lib/dmadev/rte_dmadev_pmd.h | 72 +
 lib/dmadev/version.map  | 10 +++
 4 files changed, 85 insertions(+)
 create mode 100644 lib/dmadev/rte_dmadev_pmd.h

diff --git a/lib/dmadev/meson.build b/lib/dmadev/meson.build
index f421ec1..833baf7 100644
--- a/lib/dmadev/meson.build
+++ b/lib/dmadev/meson.build
@@ -3,3 +3,4 @@
 
 headers = files('rte_dmadev.h')
 indirect_headers += files('rte_dmadev_core.h')
+driver_sdk_headers += files('rte_dmadev_pmd.h')
diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
index 3c72aa8..48803ae 100644
--- a/lib/dmadev/rte_dmadev.h
+++ b/lib/dmadev/rte_dmadev.h
@@ -743,6 +743,8 @@ struct rte_dmadev_sge {
uint32_t length; /**< The DMA operation length. */
 };
 
+#include "rte_dmadev_core.h"
+
 /* DMA flags to augment operation preparation. */
 #define RTE_DMA_OP_FLAG_FENCE  (1ull << 0)
 /**< DMA fence flag.
diff --git a/lib/dmadev/rte_dmadev_pmd.h b/lib/dmadev/rte_dmadev_pmd.h
new file mode 100644
index 000..45141f9
--- /dev/null
+++ b/lib/dmadev/rte_dmadev_pmd.h
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 HiSilicon Limited.
+ */
+
+#ifndef _RTE_DMADEV_PMD_H_
+#define _RTE_DMADEV_PMD_H_
+
+/**
+ * @file
+ *
+ * RTE DMA Device PMD APIs
+ *
+ * Driver facing APIs for a DMA device. These are not to be called directly by
+ * any application.
+ */
+
+#include "rte_dmadev.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @internal
+ * Allocates a new dmadev slot for an DMA device and returns the pointer
+ * to that slot for the driver to use.
+ *
+ * @param name
+ *   DMA device name.
+ *
+ * @return
+ *   A pointer to the DMA device slot case of success,
+ *   NULL otherwise.
+ */
+__rte_internal
+struct rte_dmadev *
+rte_dmadev_pmd_allocate(const char *name);
+
+/**
+ * @internal
+ * Release the specified dmadev.
+ *
+ * @param dev
+ *   Device to be released.
+ *
+ * @return
+ *   - 0 on success, negative on error
+ */
+__rte_internal
+int
+rte_dmadev_pmd_release(struct rte_dmadev *dev);
+
+/**
+ * @internal
+ * Return the DMA device based on the device name.
+ *
+ * @param name
+ *   DMA device name.
+ *
+ * @return
+ *   A pointer to the DMA device slot case of success,
+ *   NULL otherwise.
+ */
+__rte_internal
+struct rte_dmadev *
+rte_dmadev_get_device_by_name(const char *name);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_DMADEV_PMD_H_ */
diff --git a/lib/dmadev/version.map b/lib/dmadev/version.map
index 02fffe3..408b93c 100644
--- a/lib/dmadev/version.map
+++ b/lib/dmadev/version.map
@@ -23,3 +23,13 @@ EXPERIMENTAL {
 
local: *;
 };
+
+INTERNAL {
+global:
+
+   rte_dmadev_get_device_by_name;
+   rte_dmadev_pmd_allocate;
+   rte_dmadev_pmd_release;
+
+   local: *;
+};
-- 
2.8.1

[dpdk-dev] [PATCH v14 4/6] dmadev: introduce DMA device library implementation

[Chengwen Feng]

This patch introduce DMA device library implementation which includes
configuration and I/O with the DMA devices.

Signed-off-by: Chengwen Feng 
Acked-by: Bruce Richardson 
Acked-by: Morten Brørup 
---
 config/rte_config.h  |   3 +
 lib/dmadev/meson.build   |   1 +
 lib/dmadev/rte_dmadev.c  | 567 +++
 lib/dmadev/rte_dmadev.h  | 118 -
 lib/dmadev/rte_dmadev_core.h |   2 +
 lib/dmadev/version.map   |   1 +
 6 files changed, 680 insertions(+), 12 deletions(-)
 create mode 100644 lib/dmadev/rte_dmadev.c

diff --git a/config/rte_config.h b/config/rte_config.h
index 590903c..331a431 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -81,6 +81,9 @@
 /* rawdev defines */
 #define RTE_RAWDEV_MAX_DEVS 64
 
+/* dmadev defines */
+#define RTE_DMADEV_MAX_DEVS 64
+
 /* ip_fragmentation defines */
 #define RTE_LIBRTE_IP_FRAG_MAX_FRAG 4
 #undef RTE_LIBRTE_IP_FRAG_TBL_STAT
diff --git a/lib/dmadev/meson.build b/lib/dmadev/meson.build
index 833baf7..d2fc85e 100644
--- a/lib/dmadev/meson.build
+++ b/lib/dmadev/meson.build
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2021 HiSilicon Limited.
 
+sources = files('rte_dmadev.c')
 headers = files('rte_dmadev.h')
 indirect_headers += files('rte_dmadev_core.h')
 driver_sdk_headers += files('rte_dmadev_pmd.h')
diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
new file mode 100644
index 000..80be485
--- /dev/null
+++ b/lib/dmadev/rte_dmadev.c
@@ -0,0 +1,567 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 HiSilicon Limited.
+ * Copyright(c) 2021 Intel Corporation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rte_dmadev.h"
+#include "rte_dmadev_pmd.h"
+
+struct rte_dmadev rte_dmadevices[RTE_DMADEV_MAX_DEVS];
+
+static const char *mz_rte_dmadev_data = "rte_dmadev_data";
+/* Shared memory between primary and secondary processes. */
+static struct {
+   struct rte_dmadev_data data[RTE_DMADEV_MAX_DEVS];
+} *dmadev_shared_data;
+
+RTE_LOG_REGISTER_DEFAULT(rte_dmadev_logtype, INFO);
+#define RTE_DMADEV_LOG(level, ...) \
+   rte_log(RTE_LOG_ ## level, rte_dmadev_logtype, "" __VA_ARGS__)
+
+/* Macros to check for valid device id */
+#define RTE_DMADEV_VALID_DEV_ID_OR_ERR_RET(dev_id, retval) do { \
+   if (!rte_dmadev_is_valid_dev(dev_id)) { \
+   RTE_DMADEV_LOG(ERR, "Invalid dev_id=%u\n", dev_id); \
+   return retval; \
+   } \
+} while (0)
+
+static int
+dmadev_check_name(const char *name)
+{
+   size_t name_len;
+
+   if (name == NULL) {
+   RTE_DMADEV_LOG(ERR, "Name can't be NULL\n");
+   return -EINVAL;
+   }
+
+   name_len = strnlen(name, RTE_DMADEV_NAME_MAX_LEN);
+   if (name_len == 0) {
+   RTE_DMADEV_LOG(ERR, "Zero length DMA device name\n");
+   return -EINVAL;
+   }
+   if (name_len >= RTE_DMADEV_NAME_MAX_LEN) {
+   RTE_DMADEV_LOG(ERR, "DMA device name is too long\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static uint16_t
+dmadev_find_free_dev(void)
+{
+   uint16_t i;
+
+   for (i = 0; i < RTE_DMADEV_MAX_DEVS; i++) {
+   if (dmadev_shared_data->data[i].dev_name[0] == '\0')
+   return i;
+   }
+
+   return RTE_DMADEV_MAX_DEVS;
+}
+
+static struct rte_dmadev*
+dmadev_find(const char *name)
+{
+   uint16_t i;
+
+   for (i = 0; i < RTE_DMADEV_MAX_DEVS; i++) {
+   if ((rte_dmadevices[i].state == RTE_DMADEV_ATTACHED) &&
+   (!strcmp(name, rte_dmadevices[i].data->dev_name)))
+   return &rte_dmadevices[i];
+   }
+
+   return NULL;
+}
+
+static int
+dmadev_shared_data_prepare(void)
+{
+   const struct rte_memzone *mz;
+
+   if (dmadev_shared_data == NULL) {
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   /* Allocate port data and ownership shared memory. */
+   mz = rte_memzone_reserve(mz_rte_dmadev_data,
+sizeof(*dmadev_shared_data),
+rte_socket_id(), 0);
+   } else
+   mz = rte_memzone_lookup(mz_rte_dmadev_data);
+   if (mz == NULL)
+   return -ENOMEM;
+
+   dmadev_shared_data = mz->addr;
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+   memset(dmadev_shared_data->data, 0,
+  sizeof(dmadev_shared_data->data));
+   }
+
+   return 0;
+}
+
+static struct rte_dmadev *
+dmadev_allocate(const char *name)
+{
+   struct rte_dmadev *dev;
+   uint16_t dev_id;
+
+   dev = dmadev_find(name);
+   if (dev != NULL) {
+   RTE_D

[dpdk-dev] [PATCH v14 5/6] doc: add DMA device library guide

[Chengwen Feng]

This patch adds dmadev library guide.

Signed-off-by: Chengwen Feng 
---
 doc/guides/prog_guide/dmadev.rst | 126 
 doc/guides/prog_guide/img/dmadev.svg | 283 +++
 doc/guides/prog_guide/index.rst  |   1 +
 3 files changed, 410 insertions(+)
 create mode 100644 doc/guides/prog_guide/dmadev.rst
 create mode 100644 doc/guides/prog_guide/img/dmadev.svg

diff --git a/doc/guides/prog_guide/dmadev.rst b/doc/guides/prog_guide/dmadev.rst
new file mode 100644
index 000..6e8cce0
--- /dev/null
+++ b/doc/guides/prog_guide/dmadev.rst
@@ -0,0 +1,126 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+   Copyright 2021 HiSilicon Limited
+
+DMA Device Library
+
+
+The DMA library provides a DMA device framework for management and provisioning
+of hardware and software DMA poll mode drivers, defining generic APIs which
+support a number of different DMA operations.
+
+
+Design Principles
+-
+
+The DMA library follows the same basic principles as those used in DPDK's
+Ethernet Device framework and the RegEx framework. The DMA framework provides
+a generic DMA device framework which supports both physical (hardware)
+and virtual (software) DMA devices as well as a generic DMA API which allows
+DMA devices to be managed and configured and supports DMA operations to be
+provisioned on DMA poll mode driver.
+
+.. _figure_dmadev:
+
+.. figure:: img/dmadev.*
+
+The above figure shows the model on which the DMA framework is built on:
+
+ * The DMA controller could have multiple hardware DMA channels (aka. hardware
+   DMA queues), each hardware DMA channel should be represented by a dmadev.
+ * The dmadev could create multiple virtual DMA channels, each virtual DMA
+   channel represents a different transfer context. The DMA operation request
+   must be submitted to the virtual DMA channel. e.g. Application could create
+   virtual DMA channel 0 for memory-to-memory transfer scenario, and create
+   virtual DMA channel 1 for memory-to-device transfer scenario.
+
+
+Device Management
+-
+
+Device Creation
+~~~
+
+Physical DMA controller is discovered during the PCI probe/enumeration of the
+EAL function which is executed at DPDK initialization, based on their PCI
+device identifier, each unique PCI BDF (bus/bridge, device, function). Specific
+physical DMA controller, like other physical devices in DPDK can be listed 
using
+the EAL command line options.
+
+And then dmadevs are dynamically allocated by rte_dmadev_pmd_allocate() based 
on
+the number of hardware DMA channels.
+
+
+Device Identification
+~
+
+Each DMA device, whether physical or virtual is uniquely designated by two
+identifiers:
+
+- A unique device index used to designate the DMA device in all functions
+  exported by the DMA API.
+
+- A device name used to designate the DMA device in console messages, for
+  administration or debugging purposes.
+
+
+Device Configuration
+
+
+The rte_dmadev_configure API is used to configure a DMA device.
+
+.. code-block:: c
+
+   int rte_dmadev_configure(uint16_t dev_id,
+const struct rte_dmadev_conf *dev_conf);
+
+The ``rte_dmadev_conf`` structure is used to pass the configuration parameters
+for the DMA device for example the number of virtual DMA channels to set up,
+indication of whether to enable silent mode.
+
+
+Configuration of Virtual DMA Channels
+~
+
+The rte_dmadev_vchan_setup API is used to configure a virtual DMA channel.
+
+.. code-block:: c
+
+   int rte_dmadev_vchan_setup(uint16_t dev_id, uint16_t vchan,
+  const struct rte_dmadev_vchan_conf *conf);
+
+The ``rte_dmadev_vchan_conf`` structure is used to pass the configuration
+parameters for the virtual DMA channel for example transfer direction, number 
of
+descriptor for the virtual DMA channel, source device access port parameter,
+destination device access port parameter.
+
+
+Device Features and Capabilities
+
+
+DMA devices may support different feature set. In order to get the supported 
PMD
+features ``rte_dmadev_info_get`` API which returns the info of the device and
+it's supported features.
+
+A special device capability is silent mode which application don't required to
+invoke dequeue APIs.
+
+
+Enqueue / Dequeue APIs
+~~
+
+The enqueue APIs include like ``rte_dmadev_copy`` and ``rte_dmadev_fill``, if
+enqueue successful, an uint16_t ring_idx is returned. This ring_idx can be used
+by applications to track per-operation metadata in an application defined
+circular ring.
+
+The ``rte_dmadev_submit`` API was used to issue doorbell to hardware, and also
+there are flags (``RTE_DMA_OP_FLAG_SUBMIT``) parameter of the enqueue APIs
+could do the same work.
+
+There are two dequeue APIs (``rte_dmadev_completed`` and
+``rte_dmadev_completed_status``) could used to

[dpdk-dev] [PATCH v14 1/6] dmadev: introduce DMA device library public APIs

[Chengwen Feng]

The 'dmadevice' is a generic type of DMA device.

This patch introduce the 'dmadevice' public APIs which expose generic
operations that can enable configuration and I/O with the DMA devices.

Signed-off-by: Chengwen Feng 
Acked-by: Bruce Richardson 
Acked-by: Morten Brørup 
Acked-by: Jerin Jacob 
---
 doc/api/doxy-api-index.md |   1 +
 doc/api/doxy-api.conf.in  |   1 +
 lib/dmadev/meson.build|   4 +
 lib/dmadev/rte_dmadev.h   | 962 ++
 lib/dmadev/version.map|  25 ++
 lib/meson.build   |   1 +
 6 files changed, 994 insertions(+)
 create mode 100644 lib/dmadev/meson.build
 create mode 100644 lib/dmadev/rte_dmadev.h
 create mode 100644 lib/dmadev/version.map

diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 1992107..ce08250 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -27,6 +27,7 @@ The public API headers are grouped by topics:
   [event_timer_adapter](@ref rte_event_timer_adapter.h),
   [event_crypto_adapter]   (@ref rte_event_crypto_adapter.h),
   [rawdev] (@ref rte_rawdev.h),
+  [dmadev] (@ref rte_dmadev.h),
   [metrics](@ref rte_metrics.h),
   [bitrate](@ref rte_bitrate.h),
   [latency](@ref rte_latencystats.h),
diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
index 325a019..a44a92b 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -34,6 +34,7 @@ INPUT   = @TOPDIR@/doc/api/doxy-api-index.md \
   @TOPDIR@/lib/cmdline \
   @TOPDIR@/lib/compressdev \
   @TOPDIR@/lib/cryptodev \
+  @TOPDIR@/lib/dmadev \
   @TOPDIR@/lib/distributor \
   @TOPDIR@/lib/efd \
   @TOPDIR@/lib/ethdev \
diff --git a/lib/dmadev/meson.build b/lib/dmadev/meson.build
new file mode 100644
index 000..6d5bd85
--- /dev/null
+++ b/lib/dmadev/meson.build
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2021 HiSilicon Limited.
+
+headers = files('rte_dmadev.h')
diff --git a/lib/dmadev/rte_dmadev.h b/lib/dmadev/rte_dmadev.h
new file mode 100644
index 000..3c72aa8
--- /dev/null
+++ b/lib/dmadev/rte_dmadev.h
@@ -0,0 +1,962 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2021 HiSilicon Limited.
+ * Copyright(c) 2021 Intel Corporation.
+ * Copyright(c) 2021 Marvell International Ltd.
+ * Copyright(c) 2021 SmartShare Systems.
+ */
+
+#ifndef _RTE_DMADEV_H_
+#define _RTE_DMADEV_H_
+
+/**
+ * @file rte_dmadev.h
+ *
+ * RTE DMA (Direct Memory Access) device APIs.
+ *
+ * The DMA framework is built on the following model:
+ *
+ * ---   ---   ---
+ * | virtual DMA |   | virtual DMA |   | virtual DMA |
+ * | channel |   | channel |   | channel |
+ * ---   ---   ---
+ *||  |
+ *--  |
+ * |  |
+ *   
+ *   |  dmadev  ||  dmadev  |
+ *   
+ * |  |
+ *--   --
+ *| HW-DMA-channel |   | HW-DMA-channel |
+ *--   --
+ * |  |
+ * 
+ * |
+ *   -
+ *   | HW-DMA-Controller |
+ *   -
+ *
+ * The DMA controller could have multiple HW-DMA-channels (aka. HW-DMA-queues),
+ * each HW-DMA-channel should be represented by a dmadev.
+ *
+ * The dmadev could create multiple virtual DMA channels, each virtual DMA
+ * channel represents a different transfer context. The DMA operation request
+ * must be submitted to the virtual DMA channel. e.g. Application could create
+ * virtual DMA channel 0 for memory-to-memory transfer scenario, and create
+ * virtual DMA channel 1 for memory-to-device transfer scenario.
+ *
+ * The dmadev are dynamically allocated by rte_dmadev_pmd_allocate() during the
+ * PCI/SoC device probing phase performed at EAL initialization time. And could
+ * be released by rte_dmadev_pmd_release() during the PCI/SoC device removing
+ * phase.
+ *
+ * This framework uses 'uint16_t dev_id' as the device identifier of a dmadev,
+ * and 'uint16_t vchan' as the virtual DMA channel identifier in one dmadev.
+ *
+ * The functions exported by the dmadev API to setup a device designated by its
+ * device identifie

Re: [dpdk-dev] [RFC] ethdev: change queue release callback

[Xueming(Steven) Li]

Hi Singh and Ferruh,

> -Original Message-
> From: Ferruh Yigit 
> Sent: Monday, August 9, 2021 11:31 PM
> To: Singh, Aman Deep ; Andrew Rybchenko 
> ; Xueming(Steven) Li
> 
> Cc: dev@dpdk.org; Slava Ovsiienko ; 
> NBU-Contact-Thomas Monjalon 
> Subject: Re: [dpdk-dev] [RFC] ethdev: change queue release callback
> 
> On 8/9/2021 3:39 PM, Singh, Aman Deep wrote:
> > Hi Xueming,
> >
> > On 7/28/2021 1:10 PM, Andrew Rybchenko wrote:
> >> On 7/27/21 6:41 AM, Xueming Li wrote:
> >>> To align with other eth device queue configuration callbacks, change
> >>> RX and TX queue release callback API parameter from queue object to
> >>> device and queue index.
> >>>
> >>> Signed-off-by: Xueming Li 
> >>
> >> In fact, there is no strong reasons to do it, but I think it is a
> >> nice cleanup to use (dev + queue index) on control path.
> >>
> >> Hopefully it will not result in any regressions.
> >
> > Combined there are 100+ API's for Rx/Tx queue_release that need to be
> > modified for it.
> >
> > I believe all regression possibilities here will be caught, in
> > compilation phase itself.
> >
> 
> Same here, it is a good cleanup but there is no strong reason for it.
> 
> Since it is all internal, there is no ABI restriction on the patch, and 
> v21.11 will be full ABI break patches, to not cause conflicts with this
> change, what would you think to have it on v22.02?

This patch is required by shared-rxq feature which ABI broken, target to 21.11.
I'll do it carefully, fortunately, the change is straightforward.

Re: [dpdk-dev] [RFC] ethdev: change queue release callback

[Xueming(Steven) Li]

> -Original Message-
> From: Ferruh Yigit 
> Sent: Tuesday, August 10, 2021 4:54 PM
> To: Xueming(Steven) Li ; Singh, Aman Deep 
> ; Andrew Rybchenko
> 
> Cc: dev@dpdk.org; Slava Ovsiienko ; 
> NBU-Contact-Thomas Monjalon 
> Subject: Re: [dpdk-dev] [RFC] ethdev: change queue release callback
> 
> On 8/10/2021 9:03 AM, Xueming(Steven) Li wrote:
> > Hi Singh and Ferruh,
> >
> >> -Original Message-
> >> From: Ferruh Yigit 
> >> Sent: Monday, August 9, 2021 11:31 PM
> >> To: Singh, Aman Deep ; Andrew Rybchenko
> >> ; Xueming(Steven) Li
> >> 
> >> Cc: dev@dpdk.org; Slava Ovsiienko ;
> >> NBU-Contact-Thomas Monjalon 
> >> Subject: Re: [dpdk-dev] [RFC] ethdev: change queue release callback
> >>
> >> On 8/9/2021 3:39 PM, Singh, Aman Deep wrote:
> >>> Hi Xueming,
> >>>
> >>> On 7/28/2021 1:10 PM, Andrew Rybchenko wrote:
>  On 7/27/21 6:41 AM, Xueming Li wrote:
> > To align with other eth device queue configuration callbacks,
> > change RX and TX queue release callback API parameter from queue
> > object to device and queue index.
> >
> > Signed-off-by: Xueming Li 
> 
>  In fact, there is no strong reasons to do it, but I think it is a
>  nice cleanup to use (dev + queue index) on control path.
> 
>  Hopefully it will not result in any regressions.
> >>>
> >>> Combined there are 100+ API's for Rx/Tx queue_release that need to
> >>> be modified for it.
> >>>
> >>> I believe all regression possibilities here will be caught, in
> >>> compilation phase itself.
> >>>
> >>
> >> Same here, it is a good cleanup but there is no strong reason for it.
> >>
> >> Since it is all internal, there is no ABI restriction on the patch,
> >> and v21.11 will be full ABI break patches, to not cause conflicts with 
> >> this change, what would you think to have it on v22.02?
> >
> > This patch is required by shared-rxq feature which ABI broken, target to 
> > 21.11.
> 
> Why it is required?

In rx burst function, rxq object is used in data path. For best data 
performance, it's shared-rxq object in case of shared rxq enabled.
I think eth api defined rxq object for performance as well, specific on data 
plane. 
Hardware saves port info received packet descriptor for my case.
Can't tell which device's queue with this shared rxq object, control path can't 
use this shared rxq anymore, have to be specific on dev and queue id.

> 
> > I'll do it carefully, fortunately, the change is straightforward.
> >

Re: [dpdk-dev] [PATCH v1] doc: fix CI typo warnings

[Kinsella, Ray]

yah - I would oblige.

Ray K

On 09/08/2021 15:43, Aaron Conole wrote:
> Ray Kinsella  writes:
> 
>> Fix documentation typos that are generating spurious CI warnings.
>>
>> Signed-off-by: Ray Kinsella 
>> ---
> 
> Looks like there are still a few errors.  Ex:
> 
> ioat: end-before not used anywhere
> 
> deprecation.rst: 'inplace' should probably be 'in place'
> deprecation.rst: 'esn' -> probably needs a way to exempt this particular
> 'word' / line, because it is a function name.  I'm surprised it is even
> considered.
> 
> Is it possible to spin a v2 with these fixes?
> 
>>  doc/guides/sample_app_ug/ioat.rst| 2 +-
>>  doc/guides/sample_app_ug/vmdq_forwarding.rst | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/guides/sample_app_ug/ioat.rst 
>> b/doc/guides/sample_app_ug/ioat.rst
>> index ee0a627b06..b364be3b5d 100644
>> --- a/doc/guides/sample_app_ug/ioat.rst
>> +++ b/doc/guides/sample_app_ug/ioat.rst
>> @@ -236,7 +236,7 @@ function in order to start processing for each lcore:
>>  .. literalinclude:: ../../../examples/ioat/ioatfwd.c
>>  :language: c
>>  :start-after: Start processing for each lcore. 8<
>> -:end-before: >8 End of starting to processfor each lcore.
>> +:end-before: >8 End of starting to process for each lcore.
>>  :dedent: 0
>>  
>>  The function launches Rx/Tx processing functions on configured lcores
>> diff --git a/doc/guides/sample_app_ug/vmdq_forwarding.rst 
>> b/doc/guides/sample_app_ug/vmdq_forwarding.rst
>> index ae1b5660df..ed28525a15 100644
>> --- a/doc/guides/sample_app_ug/vmdq_forwarding.rst
>> +++ b/doc/guides/sample_app_ug/vmdq_forwarding.rst
>> @@ -103,7 +103,7 @@ the MAC of VMDq pool 2 on port 1 is 52:54:00:12:01:02.
>>  
>>  .. literalinclude:: ../../../examples/vmdq/main.c
>>  :language: c
>> -:start-after: Building correct configruration for vdmq. 8<
>> +:start-after: Building correct configuration for vdmq. 8<
>>  :end-before: >8 End of get_eth_conf.
>>  
>>  Once the network port has been initialized using the correct VMDq values,
> 

[dpdk-dev] [Bug 787] Vashikaran specialist near me

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=787

Bug ID: 787
   Summary: Vashikaran specialist near me
   Product: DPDK
   Version: 21.05
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: ethdev
  Assignee: dev@dpdk.org
  Reporter: swamiastrologyswam...@gmail.com
  Target Milestone: ---

When vashikaran is used then a person must understand that any problem of that
person can be solved. Situations always make a person dumb. Sometimes a
frustrating situation makes a person so disturb that they even stop the hope of
ending their problem. But when a person searches for Vashikaran specialist near
me they surely find out something good. A person can get the details of the
best vashikaran specialist. This could be the fine way for a person to make
their life good. It is the way the problems of a person can get solve and
things become better for them forever.

https://astrologyswami.com/vashikaran-specialist-near-me.php

-- 
You are receiving this mail because:
You are the assignee for the bug.

[dpdk-dev] [Bug 787] Vashikaran specialist near me

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=787

Ajit Khaparde (ajit.khapa...@broadcom.com) changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ajit.khapa...@broadcom.com
 Resolution|--- |INVALID

--- Comment #1 from Ajit Khaparde (ajit.khapa...@broadcom.com) ---
SPAM!!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[dpdk-dev] [PATCH v2] doc: fix CI typo warnings

[Ray Kinsella]

Fix documentation typos that are generating spurious CI warnings.

Signed-off-by: Ray Kinsella 
---
v2:
  * Fix some additional typos pointed out by Aaron Conole

 doc/guides/rel_notes/deprecation.rst | 4 ++--
 doc/guides/sample_app_ug/ioat.rst| 2 +-
 doc/guides/sample_app_ug/vmdq_forwarding.rst | 2 +-
 examples/ioat/ioatfwd.c  | 2 +-
 examples/vmdq/main.c | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 76a4abfd6b..65023e39d8 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -208,7 +208,7 @@ Deprecation Notices
 
 * cryptodev: The structure ``rte_crypto_sym_vec`` would be updated to add
   ``dest_sgl`` to support out of place processing.
-  This field will be null for inplace processing.
+  This field will be null for in place processing.
   This change is targeted for DPDK 21.11.
 
 * cryptodev: The structure ``rte_crypto_vec`` would be updated to add
@@ -233,7 +233,7 @@ Deprecation Notices
 * security: The IPsec configuration structure
   ``struct rte_security_ipsec_xform`` will be updated with new members to allow
   SA lifetime configuration. A new structure would be introduced to replace the
-  current member, ``esn_soft_limit``.
+  current member ``esn_soft_limit``.
 
 * security: The structure ``rte_security_ipsec_xform`` will be extended with
   multiple fields: source and destination port of UDP encapsulation,
diff --git a/doc/guides/sample_app_ug/ioat.rst 
b/doc/guides/sample_app_ug/ioat.rst
index ee0a627b06..b364be3b5d 100644
--- a/doc/guides/sample_app_ug/ioat.rst
+++ b/doc/guides/sample_app_ug/ioat.rst
@@ -236,7 +236,7 @@ function in order to start processing for each lcore:
 .. literalinclude:: ../../../examples/ioat/ioatfwd.c
 :language: c
 :start-after: Start processing for each lcore. 8<
-:end-before: >8 End of starting to processfor each lcore.
+:end-before: >8 End of starting to process for each lcore.
 :dedent: 0
 
 The function launches Rx/Tx processing functions on configured lcores
diff --git a/doc/guides/sample_app_ug/vmdq_forwarding.rst 
b/doc/guides/sample_app_ug/vmdq_forwarding.rst
index ae1b5660df..ed28525a15 100644
--- a/doc/guides/sample_app_ug/vmdq_forwarding.rst
+++ b/doc/guides/sample_app_ug/vmdq_forwarding.rst
@@ -103,7 +103,7 @@ the MAC of VMDq pool 2 on port 1 is 52:54:00:12:01:02.
 
 .. literalinclude:: ../../../examples/vmdq/main.c
 :language: c
-:start-after: Building correct configruration for vdmq. 8<
+:start-after: Building correct configuration for vdmq. 8<
 :end-before: >8 End of get_eth_conf.
 
 Once the network port has been initialized using the correct VMDq values,
diff --git a/examples/ioat/ioatfwd.c b/examples/ioat/ioatfwd.c
index 0c413180f8..c57a8b82f0 100644
--- a/examples/ioat/ioatfwd.c
+++ b/examples/ioat/ioatfwd.c
@@ -564,7 +564,7 @@ static void start_forwarding_cores(void)
lcore_id);
}
 }
-/* >8 End of starting to processfor each lcore. */
+/* >8 End of starting to process for each lcore. */
 
 /* Display usage */
 static void
diff --git a/examples/vmdq/main.c b/examples/vmdq/main.c
index d3bc19f78e..843cf0bf1e 100644
--- a/examples/vmdq/main.c
+++ b/examples/vmdq/main.c
@@ -136,7 +136,7 @@ static struct rte_ether_addr 
vmdq_ports_eth_addr[RTE_MAX_ETHPORTS];
  * valid pool number
  */
 
- /* Building correct configruration for vdmq. 8< */
+ /* Building correct configuration for vdmq. 8< */
 static inline int
 get_eth_conf(struct rte_eth_conf *eth_conf, uint32_t num_pools)
 {
-- 
2.26.2

Re: [dpdk-dev] [PATCH v14 5/6] doc: add DMA device library guide

[Walsh, Conor]

[snip]

Hi Chengwen,
I have included some feedback to improve the grammar and readability
of the docs inline.

> +Device Management
> +-
> +
> +Device Creation
> +~~~
> +
> +Physical DMA controller is discovered during the PCI probe/enumeration of

^ "controllers are" instead of "controller is"

> the
> +EAL function which is executed at DPDK initialization, based on their PCI
> +device identifier, each unique PCI BDF (bus/bridge, device, function).

Change after the first , to the following "this is based on their PCI BDF
(bus/bridge, device, function)."

> Specific
> +physical DMA controller, like other physical devices in DPDK can be listed
> using

^ "controllers" instead of "controller"

> +the EAL command line options.
> +
> +And then dmadevs are dynamically allocated by

^ Change "And then" to "After DPDK initialization".

> rte_dmadev_pmd_allocate() based on
> +the number of hardware DMA channels.

[snip]

> +Device Features and Capabilities
> +
> +
> +DMA devices may support different feature set. In order to get the
> supported PMD

^ missing "s" at the end of line: "DMA devices may support different feature 
sets."

> +features ``rte_dmadev_info_get`` API which returns the info of the device
> and
> +it's supported features.

Replace "In order to get the supported PMD features rte_dmadev_info_get API 
which
returns the info of the device and it's supported features." with:
The ``rte_dmadev_info_get`` API can be used to get a devices info and supported 
features.

> +
> +A special device capability is silent mode which application don't required 
> to
> +invoke dequeue APIs.

Replace the above sentence with:
"Silent mode is a special device capability which does not require the 
application
to invoke dequeue APIs."

> +
> +
> +Enqueue / Dequeue APIs
> +~~
> +
> +The enqueue APIs include like ``rte_dmadev_copy`` and ``rte_dmadev_fill``,
> if
> +enqueue successful, an uint16_t ring_idx is returned. This ring_idx can be
> used
> +by applications to track per-operation metadata in an application defined
> +circular ring.

Replace the enqueue paragraph with the following:
"Enqueue APIs such as ``rte_dmadev_copy`` and ``rte_dmadev_fill`` can be used
to enqueue operations to hardware. If an enqueue is successful, a ``ring_idx``
is returned. This ``ring_idx`` can be used by applications to track 
per-operation metadata
in an application-defined circular ring."

> +
> +The ``rte_dmadev_submit`` API was used to issue doorbell to hardware,
> and also
> +there are flags (``RTE_DMA_OP_FLAG_SUBMIT``) parameter of the
> enqueue APIs
> +could do the same work.

Replace submit line with this:
"The ``rte_dmadev_submit`` API is used to issue the doorbell to hardware.
Alternatively the ``RTE_DMA_OP_FLAG_SUBMIT`` flag can be passed to the
enqueue APIs to also issue the doorbell to hardware."

> +
> +There are two dequeue APIs (``rte_dmadev_completed`` and
> +``rte_dmadev_completed_status``) could used to obtain the result of
> request.

Replace the above sentence with:
"There are two dequeue APIs ``rte_dmadev_completed`` and
``rte_dmadev_completed_status``, these are used to obtain the
results of the enqueue requests."

> +The first API returns the number of operation requests completed
> successfully,
> +the second API returns the number of operation requests completed which
> may
> +successfully or failed and also with meaningful status code.

Replace above line with the following:
"``rte_dmadev_completed`` will return the number of successfully completed 
operations.
``rte_dmadev_completed_status`` will return the total number of completed 
operations
along with the status of each operation (filled into the ``status`` array 
passed by user)."

> Also these two
> +APIs could return the last completed operation's ring_idx which will help to
> +track application-defined circular ring.

Replace the last line with this:
"These two APIs can also return the last completed operations ``ring_idx`` which
could help developers track operations within their own application-defined 
rings."

With the improvements suggested above,
Acked-by: Conor Walsh 

Thanks,
Conor.

[dpdk-dev] [Bug 788] i40e: 16BYTE_RX_DESC build broken on FreeBSD-13

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=788

Bug ID: 788
   Summary: i40e: 16BYTE_RX_DESC build broken on FreeBSD-13
   Product: DPDK
   Version: 21.08
  Hardware: x86
OS: FreeBSD
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: ethdev
  Assignee: dev@dpdk.org
  Reporter: brian90...@gmail.com
  Target Milestone: ---

Hello,

I just tried compiling DPDK 21.08 and found my configuration no longer builds
on FreeBSD-13.0. With version 21.05, I defined RTE_LIBRTE_I40E_16BYTE_RX_DESC
in rte_config.h as described in section "Use 16 Bytes RX Descriptor Size" of
the current i40e PMD documentation. I also defined a similar variable
RTE_LIBRTE_ICE_16BYTE_RX_DESC in rte_config.h for the ice PMD.

This morning I brought in version 21.08 and watched it compile on FreeBSD-12.2
(clang version 10.0.1) running on an 'Intel(R) Xeon(R) CPU E5-2637 v3'. Then I
tried building it on FreeBSD-13.0 (clang version 11.0.1) on a 'AMD Ryzen
Threadripper 3990X 64-Core Processor' but the build died with a number of
compilation errors related to avx512f features enabled in functions compiled
without support for avx512f.

Below I have an edited build log from the FreeBSD-12.2 system that works
followed by the log from the FreeBSD-13.0 system that fails. Looking at the
12.2 log, there is a warning “Binutils error with AVX512 assembly, disabling
AVX512 support” that might be hiding this issue? Neither system has hardware
support for AVX-512 but it appears that the compiler does. Thank you for your
help!



*** FreeBSD-12.2 build that works ***
The Meson build system
Version: 0.58.1
Build type: native build
Program cat found: YES (/bin/cat)
Project name: DPDK
Project version: 21.08.0
C compiler for the host machine: cc (clang 10.0.1 "FreeBSD clang version 10.0.1
(g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)")
C linker for the host machine: cc ld.lld 10.0.1
Host machine cpu family: x86_64
Host machine cpu: x86_64

Compiler for C supports arguments -mno-avx512f: YES 
config/x86/meson.build:9: WARNING: Binutils error with AVX512 assembly,
disabling AVX512 support
Compiler for C supports arguments -mavx512f: YES 
Checking if "AVX512 checking" compiles: YES 
Fetching value of define "__SSE4_2__" : 1 
Fetching value of define "__AES__" : 1 
Fetching value of define "__AVX__" : 1 
Fetching value of define "__AVX2__" : 1 
Fetching value of define "__AVX512BW__" :  
Fetching value of define "__AVX512CD__" :  
Fetching value of define "__AVX512DQ__" :  
Fetching value of define "__AVX512F__" :  
Fetching value of define "__AVX512VL__" :  
Fetching value of define "__PCLMUL__" : 1 
Fetching value of define "__RDRND__" : 1 
Fetching value of define "__RDSEED__" :  
Fetching value of define "__VPCLMULQDQ__" :  

Compiler for C supports arguments -mpclmul: YES 
Compiler for C supports arguments -maes: YES 



*** FreeBSD-13.0 system that does not build ***
The Meson build system
Version: 0.58.1
Build type: native build
Program cat found: YES (/bin/cat)
Project name: DPDK
Project version: 21.08.0
C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang version 11.0.1
(g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)")
C linker for the host machine: cc ld.lld 11.0.1
Host machine cpu family: x86_64
Host machine cpu: x86_64

Compiler for C supports arguments -mavx512f: YES 
Checking if "AVX512 checking" compiles: YES 
Fetching value of define "__SSE4_2__" : 1 
Fetching value of define "__AES__" : 1 
Fetching value of define "__AVX__" : 1 
Fetching value of define "__AVX2__" : 1 
Fetching value of define "__AVX512BW__" :  
Fetching value of define "__AVX512CD__" :  
Fetching value of define "__AVX512DQ__" :  
Fetching value of define "__AVX512F__" :  
Fetching value of define "__AVX512VL__" :  
Fetching value of define "__PCLMUL__" : 1 
Fetching value of define "__RDRND__" : 1 
Fetching value of define "__RDSEED__" : 1 
Fetching value of define "__VPCLMULQDQ__" :  

Compiler for C supports arguments -mpclmul: YES 
Compiler for C supports arguments -maes: YES 
Compiler for C supports arguments -mavx512f: YES (cached)
Compiler for C supports arguments -mavx512bw: YES 
Compiler for C supports arguments -mavx512dq: YES 
Compiler for C supports arguments -mavx512vl: YES 
Compiler for C supports arguments -mvpclmulqdq: YES 
Compiler for C supports arguments -mavx2: YES 
Compiler for C supports arguments -mavx: YES 

Compiler for C supports arguments -mavx512f -mavx512vl -mavx512cd -mavx512bw:
YES 
Compiler for C supports arguments -mavx512f -mavx512dq: YES 



FAILED: drivers/libtmp_rte_net_i40e.a.p/net_i40e_i40e_rxtx_vec_avx2.c.o 
cc -Idrivers/libtmp_rte_net_i40e.a.p -Idrivers -I../drivers -Idrivers/net/i40e
-I../drivers/net/i40e -Idrivers/net/i40e/base -I../drivers/net/i40e/base
-Ilib/ethdev -I../lib/ethdev -I. -I.. -Iconfig -I../config -Ilib/eal/include
-I../lib/eal/include -Ilib/eal

[dpdk-dev] [PATCH v2 0/4] cryptodev: expose driver interface as internal

[Akhil Goyal]

rte_cryptodev_pmd.* files are meant to be used for
DPDK internal usage only, but it was used illegally by
applications.
There is one API which can be used by applications to
check if the dev_id has a valid device or not.
This API is exposed and modified as rte_cryptodev_is_valid_dev()
from rte_cryptodev_pmd_is_valid_dev().

changes in v2:
rebase over 21.08 release tag.

Akhil Goyal (4):
  test/crypto: remove illegal header include
  cryptodev: change valid dev API
  examples/fips_validation: remove illegal usage of APIs
  cryptodev: expose driver interface as internal

 app/test/test_cryptodev.c |  1 -
 app/test/test_cryptodev_asym.c|  1 -
 app/test/test_cryptodev_blockcipher.c |  1 -
 app/test/test_cryptodev_security_pdcp.c   |  1 -
 app/test/test_ipsec.c |  1 -
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c  |  2 +-
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c  |  2 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c|  2 +-
 .../crypto/aesni_mb/rte_aesni_mb_pmd_ops.c|  2 +-
 drivers/crypto/armv8/rte_armv8_pmd.c  |  2 +-
 drivers/crypto/armv8/rte_armv8_pmd_ops.c  |  2 +-
 drivers/crypto/bcmfs/bcmfs_sym_pmd.c  |  2 +-
 drivers/crypto/bcmfs/bcmfs_sym_session.h  |  2 +-
 drivers/crypto/caam_jr/caam_jr.c  |  2 +-
 drivers/crypto/ccp/ccp_crypto.c   |  2 +-
 drivers/crypto/ccp/ccp_pmd_ops.c  |  2 +-
 drivers/crypto/ccp/rte_ccp_pmd.c  |  2 +-
 drivers/crypto/cnxk/cn10k_cryptodev.c |  2 +-
 drivers/crypto/cnxk/cn10k_cryptodev_ops.c |  2 +-
 drivers/crypto/cnxk/cn10k_cryptodev_ops.h |  2 +-
 drivers/crypto/cnxk/cn9k_cryptodev.c  |  2 +-
 drivers/crypto/cnxk/cn9k_cryptodev_ops.c  |  2 +-
 drivers/crypto/cnxk/cn9k_cryptodev_ops.h  |  2 +-
 drivers/crypto/cnxk/cnxk_cryptodev_ops.c  |  2 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c   |  2 +-
 drivers/crypto/dpaa_sec/dpaa_sec.c|  2 +-
 drivers/crypto/kasumi/rte_kasumi_pmd.c|  2 +-
 drivers/crypto/kasumi/rte_kasumi_pmd_ops.c|  2 +-
 drivers/crypto/mlx5/mlx5_crypto.h |  2 +-
 drivers/crypto/mvsam/rte_mrvl_pmd.c   |  2 +-
 drivers/crypto/mvsam/rte_mrvl_pmd_ops.c   |  2 +-
 drivers/crypto/nitrox/nitrox_sym.c|  2 +-
 drivers/crypto/null/null_crypto_pmd.c |  2 +-
 drivers/crypto/null/null_crypto_pmd_ops.c |  2 +-
 drivers/crypto/octeontx/otx_cryptodev.c   |  2 +-
 drivers/crypto/octeontx/otx_cryptodev_ops.c   |  2 +-
 drivers/crypto/octeontx2/otx2_cryptodev.c |  2 +-
 drivers/crypto/octeontx2/otx2_cryptodev_ops.c |  2 +-
 drivers/crypto/octeontx2/otx2_cryptodev_ops.h |  2 +-
 drivers/crypto/openssl/rte_openssl_pmd.c  |  2 +-
 drivers/crypto/openssl/rte_openssl_pmd_ops.c  |  2 +-
 drivers/crypto/qat/qat_asym.h |  2 +-
 drivers/crypto/qat/qat_asym_pmd.c |  2 +-
 drivers/crypto/qat/qat_sym.h  |  2 +-
 drivers/crypto/qat/qat_sym_hw_dp.c|  2 +-
 drivers/crypto/qat/qat_sym_pmd.c  |  2 +-
 drivers/crypto/qat/qat_sym_session.h  |  2 +-
 .../scheduler/rte_cryptodev_scheduler.c   |  2 +-
 drivers/crypto/scheduler/scheduler_pmd.c  |  2 +-
 drivers/crypto/scheduler/scheduler_pmd_ops.c  |  2 +-
 drivers/crypto/snow3g/rte_snow3g_pmd.c|  2 +-
 drivers/crypto/snow3g/rte_snow3g_pmd_ops.c|  2 +-
 drivers/crypto/virtio/virtio_cryptodev.c  |  2 +-
 drivers/crypto/virtio/virtio_rxtx.c   |  2 +-
 drivers/crypto/zuc/rte_zuc_pmd.c  |  2 +-
 drivers/crypto/zuc/rte_zuc_pmd_ops.c  |  2 +-
 .../octeontx2/otx2_evdev_crypto_adptr_rx.h|  2 +-
 .../octeontx2/otx2_evdev_crypto_adptr_tx.h|  2 +-
 .../net/softnic/rte_eth_softnic_cryptodev.c   |  4 +-
 examples/fips_validation/fips_dev_self_test.c | 19 +--
 examples/fips_validation/main.c   |  9 ++--
 examples/ip_pipeline/cryptodev.c  |  3 +-
 .../{rte_cryptodev_pmd.c => cryptodev_pmd.c}  |  2 +-
 .../{rte_cryptodev_pmd.h => cryptodev_pmd.h}  | 27 +-
 lib/cryptodev/meson.build | 18 +--
 lib/cryptodev/rte_cryptodev.c | 52 +--
 lib/cryptodev/rte_cryptodev.h | 11 
 lib/cryptodev/version.map | 27 ++
 lib/eventdev/rte_event_crypto_adapter.c   |  6 +--
 lib/eventdev/rte_eventdev.c   |  4 +-
 lib/pipeline/rte_table_action.c   |  4 +-
 71 files changed, 149 insertions(+), 148 deletions(-)
 rename lib/cryptodev/{rte_cryptodev_pmd.c => cryptodev_pmd.c} (99%)
 rename lib/cryptodev/{rte_cryptodev_pmd.h => cryptodev_pmd.h} (97%)

-- 
2.25.1

[dpdk-dev] [PATCH v2 1/4] test/crypto: remove illegal header include

[Akhil Goyal]

rte_cryptodev_pmd.h is an interface between
driver and library and it is mentioned in the
file that application cannot use it directly.
Hence, removing the include.

Signed-off-by: Akhil Goyal 
---
 app/test/test_cryptodev.c   | 1 -
 app/test/test_cryptodev_asym.c  | 1 -
 app/test/test_cryptodev_blockcipher.c   | 1 -
 app/test/test_cryptodev_security_pdcp.c | 1 -
 app/test/test_ipsec.c   | 1 -
 5 files changed, 5 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 9ad0b37473..e8d63b2bc3 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -16,7 +16,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #ifdef RTE_CRYPTO_SCHEDULER
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 847b074a4f..9d19a6d6d9 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -12,7 +12,6 @@
 #include 
 
 #include 
-#include 
 #include 
 
 #include "test_cryptodev.h"
diff --git a/app/test/test_cryptodev_blockcipher.c 
b/app/test/test_cryptodev_blockcipher.c
index 53fd4718af..1c948eb008 100644
--- a/app/test/test_cryptodev_blockcipher.c
+++ b/app/test/test_cryptodev_blockcipher.c
@@ -11,7 +11,6 @@
 
 #include 
 #include 
-#include 
 
 #include "test.h"
 #include "test_cryptodev.h"
diff --git a/app/test/test_cryptodev_security_pdcp.c 
b/app/test/test_cryptodev_security_pdcp.c
index 30f3eb892c..a7641bab7a 100644
--- a/app/test/test_cryptodev_security_pdcp.c
+++ b/app/test/test_cryptodev_security_pdcp.c
@@ -17,7 +17,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
index fb90130ae2..c6d6b88d6d 100644
--- a/app/test/test_ipsec.c
+++ b/app/test/test_ipsec.c
@@ -15,7 +15,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.25.1

[dpdk-dev] [PATCH v2 2/4] cryptodev: change valid dev API

[Akhil Goyal]

The API rte_cryptodev_pmd_is_valid_dev, can be used
by the application as well as PMD to check whether
the device is valid or not. Hence, _pmd is removed
from the API.
The applications and drivers which use this API are
also updated.

Signed-off-by: Akhil Goyal 
---
 .../net/softnic/rte_eth_softnic_cryptodev.c   |  2 +-
 examples/fips_validation/main.c   |  2 +-
 examples/ip_pipeline/cryptodev.c  |  3 +-
 lib/cryptodev/rte_cryptodev.c | 50 +--
 lib/cryptodev/rte_cryptodev.h | 11 
 lib/cryptodev/rte_cryptodev_pmd.h | 11 
 lib/cryptodev/version.map |  2 +-
 lib/eventdev/rte_event_crypto_adapter.c   |  4 +-
 lib/eventdev/rte_eventdev.c   |  2 +-
 lib/pipeline/rte_table_action.c   |  2 +-
 10 files changed, 44 insertions(+), 45 deletions(-)

diff --git a/drivers/net/softnic/rte_eth_softnic_cryptodev.c 
b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
index a1a4ca5650..8e278801c5 100644
--- a/drivers/net/softnic/rte_eth_softnic_cryptodev.c
+++ b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
@@ -82,7 +82,7 @@ softnic_cryptodev_create(struct pmd_internals *p,
 
dev_id = (uint32_t)status;
} else {
-   if (rte_cryptodev_pmd_is_valid_dev(params->dev_id) == 0)
+   if (rte_cryptodev_is_valid_dev(params->dev_id) == 0)
return NULL;
 
dev_id = params->dev_id;
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index c175fe6ac2..e892078f0e 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -196,7 +196,7 @@ parse_cryptodev_id_arg(char *arg)
}
 
 
-   if (!rte_cryptodev_pmd_is_valid_dev(cryptodev_id)) {
+   if (!rte_cryptodev_is_valid_dev(cryptodev_id)) {
RTE_LOG(ERR, USER1, "Error %i: invalid cryptodev id %s\n",
cryptodev_id, arg);
return -1;
diff --git a/examples/ip_pipeline/cryptodev.c b/examples/ip_pipeline/cryptodev.c
index b0d9f3d217..9997d97456 100644
--- a/examples/ip_pipeline/cryptodev.c
+++ b/examples/ip_pipeline/cryptodev.c
@@ -6,7 +6,6 @@
 #include 
 
 #include 
-#include 
 #include 
 
 #include "cryptodev.h"
@@ -74,7 +73,7 @@ cryptodev_create(const char *name, struct cryptodev_params 
*params)
 
dev_id = (uint32_t)status;
} else {
-   if (rte_cryptodev_pmd_is_valid_dev(params->dev_id) == 0)
+   if (rte_cryptodev_is_valid_dev(params->dev_id) == 0)
return NULL;
 
dev_id = params->dev_id;
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 447aa9d519..37502b9b3c 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -663,7 +663,7 @@ rte_cryptodev_is_valid_device_data(uint8_t dev_id)
 }
 
 unsigned int
-rte_cryptodev_pmd_is_valid_dev(uint8_t dev_id)
+rte_cryptodev_is_valid_dev(uint8_t dev_id)
 {
struct rte_cryptodev *dev = NULL;
 
@@ -761,7 +761,7 @@ rte_cryptodev_socket_id(uint8_t dev_id)
 {
struct rte_cryptodev *dev;
 
-   if (!rte_cryptodev_pmd_is_valid_dev(dev_id))
+   if (!rte_cryptodev_is_valid_dev(dev_id))
return -1;
 
dev = rte_cryptodev_pmd_get_dev(dev_id);
@@ -1032,7 +1032,7 @@ rte_cryptodev_configure(uint8_t dev_id, struct 
rte_cryptodev_config *config)
struct rte_cryptodev *dev;
int diag;
 
-   if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+   if (!rte_cryptodev_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
return -EINVAL;
}
@@ -1080,7 +1080,7 @@ rte_cryptodev_start(uint8_t dev_id)
 
CDEV_LOG_DEBUG("Start dev_id=%" PRIu8, dev_id);
 
-   if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+   if (!rte_cryptodev_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
return -EINVAL;
}
@@ -1110,7 +1110,7 @@ rte_cryptodev_stop(uint8_t dev_id)
 {
struct rte_cryptodev *dev;
 
-   if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+   if (!rte_cryptodev_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
return;
}
@@ -1136,7 +1136,7 @@ rte_cryptodev_close(uint8_t dev_id)
struct rte_cryptodev *dev;
int retval;
 
-   if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+   if (!rte_cryptodev_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
return -1;
}
@@ -1176,7 +1176,7 @@ rte_cryptodev_get_qp_status(uint8_t dev_id, uint16_t 
queue_pair_id)
 {
struct rte_cryptodev *dev;
 
-   if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+   if (!rte_cryptodev_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
 

[dpdk-dev] [PATCH v2 3/4] examples/fips_validation: remove illegal usage of APIs

[Akhil Goyal]

Some of the cryptodev APIs are not allowed to be used
by application directly. Hence removing the usage of
1. queue_pair_release: it is not required, as configure
   of queue pair release the previous queue pairs and the
   dev is not directly exposed to application, hence cannot
   use its ops from app.
2. rte_cryptodev_stop: it can be used directly without
   checking if the device is started or not.
3. rte_cryptodev_pmd_destroy: application should use
   rte_cryptodev_close instead.

Signed-off-by: Akhil Goyal 
---
 examples/fips_validation/fips_dev_self_test.c | 19 ++-
 examples/fips_validation/main.c   |  7 ++-
 2 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/examples/fips_validation/fips_dev_self_test.c 
b/examples/fips_validation/fips_dev_self_test.c
index 17e85973c0..b4eab05a98 100644
--- a/examples/fips_validation/fips_dev_self_test.c
+++ b/examples/fips_validation/fips_dev_self_test.c
@@ -3,7 +3,7 @@
  */
 
 #include 
-#include 
+#include 
 
 #include "fips_dev_self_test.h"
 
@@ -1523,12 +1523,6 @@ static void
 fips_dev_auto_test_uninit(uint8_t dev_id,
struct fips_dev_auto_test_env *env)
 {
-   struct rte_cryptodev *dev = rte_cryptodev_pmd_get_dev(dev_id);
-   uint32_t i;
-
-   if (!dev)
-   return;
-
if (env->mbuf)
rte_pktmbuf_free(env->mbuf);
if (env->op)
@@ -1542,16 +1536,7 @@ fips_dev_auto_test_uninit(uint8_t dev_id,
if (env->sess_priv_pool)
rte_mempool_free(env->sess_priv_pool);
 
-   if (dev->data->dev_started)
-   rte_cryptodev_stop(dev_id);
-
-   if (dev->data->nb_queue_pairs) {
-   for (i = 0; i < dev->data->nb_queue_pairs; i++)
-   (*dev->dev_ops->queue_pair_release)(dev, i);
-   dev->data->nb_queue_pairs = 0;
-   rte_free(dev->data->queue_pairs);
-   dev->data->queue_pairs = NULL;
-   }
+   rte_cryptodev_stop(dev_id);
 }
 
 static int
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index e892078f0e..a8daad1f48 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -7,7 +7,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -73,10 +73,7 @@ cryptodev_fips_validate_app_int(void)
if (env.self_test) {
ret = fips_dev_self_test(env.dev_id, env.broken_test_config);
if (ret < 0) {
-   struct rte_cryptodev *cryptodev =
-   rte_cryptodev_pmd_get_dev(env.dev_id);
-
-   rte_cryptodev_pmd_destroy(cryptodev);
+   rte_cryptodev_close(env.dev_id);
 
return ret;
}
-- 
2.25.1

[dpdk-dev] [PATCH v2 4/4] cryptodev: expose driver interface as internal

[Akhil Goyal]

The rte_cryptodev_pmd.* files are for drivers only and should be
private to DPDK, and not installed for app use.

Signed-off-by: Akhil Goyal 
---
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c  |  2 +-
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c  |  2 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c|  2 +-
 .../crypto/aesni_mb/rte_aesni_mb_pmd_ops.c|  2 +-
 drivers/crypto/armv8/rte_armv8_pmd.c  |  2 +-
 drivers/crypto/armv8/rte_armv8_pmd_ops.c  |  2 +-
 drivers/crypto/bcmfs/bcmfs_sym_pmd.c  |  2 +-
 drivers/crypto/bcmfs/bcmfs_sym_session.h  |  2 +-
 drivers/crypto/caam_jr/caam_jr.c  |  2 +-
 drivers/crypto/ccp/ccp_crypto.c   |  2 +-
 drivers/crypto/ccp/ccp_pmd_ops.c  |  2 +-
 drivers/crypto/ccp/rte_ccp_pmd.c  |  2 +-
 drivers/crypto/cnxk/cn10k_cryptodev.c |  2 +-
 drivers/crypto/cnxk/cn10k_cryptodev_ops.c |  2 +-
 drivers/crypto/cnxk/cn10k_cryptodev_ops.h |  2 +-
 drivers/crypto/cnxk/cn9k_cryptodev.c  |  2 +-
 drivers/crypto/cnxk/cn9k_cryptodev_ops.c  |  2 +-
 drivers/crypto/cnxk/cn9k_cryptodev_ops.h  |  2 +-
 drivers/crypto/cnxk/cnxk_cryptodev_ops.c  |  2 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c   |  2 +-
 drivers/crypto/dpaa_sec/dpaa_sec.c|  2 +-
 drivers/crypto/kasumi/rte_kasumi_pmd.c|  2 +-
 drivers/crypto/kasumi/rte_kasumi_pmd_ops.c|  2 +-
 drivers/crypto/mlx5/mlx5_crypto.h |  2 +-
 drivers/crypto/mvsam/rte_mrvl_pmd.c   |  2 +-
 drivers/crypto/mvsam/rte_mrvl_pmd_ops.c   |  2 +-
 drivers/crypto/nitrox/nitrox_sym.c|  2 +-
 drivers/crypto/null/null_crypto_pmd.c |  2 +-
 drivers/crypto/null/null_crypto_pmd_ops.c |  2 +-
 drivers/crypto/octeontx/otx_cryptodev.c   |  2 +-
 drivers/crypto/octeontx/otx_cryptodev_ops.c   |  2 +-
 drivers/crypto/octeontx2/otx2_cryptodev.c |  2 +-
 drivers/crypto/octeontx2/otx2_cryptodev_ops.c |  2 +-
 drivers/crypto/octeontx2/otx2_cryptodev_ops.h |  2 +-
 drivers/crypto/openssl/rte_openssl_pmd.c  |  2 +-
 drivers/crypto/openssl/rte_openssl_pmd_ops.c  |  2 +-
 drivers/crypto/qat/qat_asym.h |  2 +-
 drivers/crypto/qat/qat_asym_pmd.c |  2 +-
 drivers/crypto/qat/qat_sym.h  |  2 +-
 drivers/crypto/qat/qat_sym_hw_dp.c|  2 +-
 drivers/crypto/qat/qat_sym_pmd.c  |  2 +-
 drivers/crypto/qat/qat_sym_session.h  |  2 +-
 .../scheduler/rte_cryptodev_scheduler.c   |  2 +-
 drivers/crypto/scheduler/scheduler_pmd.c  |  2 +-
 drivers/crypto/scheduler/scheduler_pmd_ops.c  |  2 +-
 drivers/crypto/snow3g/rte_snow3g_pmd.c|  2 +-
 drivers/crypto/snow3g/rte_snow3g_pmd_ops.c|  2 +-
 drivers/crypto/virtio/virtio_cryptodev.c  |  2 +-
 drivers/crypto/virtio/virtio_rxtx.c   |  2 +-
 drivers/crypto/zuc/rte_zuc_pmd.c  |  2 +-
 drivers/crypto/zuc/rte_zuc_pmd_ops.c  |  2 +-
 .../octeontx2/otx2_evdev_crypto_adptr_rx.h|  2 +-
 .../octeontx2/otx2_evdev_crypto_adptr_tx.h|  2 +-
 .../net/softnic/rte_eth_softnic_cryptodev.c   |  2 +-
 .../{rte_cryptodev_pmd.c => cryptodev_pmd.c}  |  2 +-
 .../{rte_cryptodev_pmd.h => cryptodev_pmd.h}  | 16 +---
 lib/cryptodev/meson.build | 18 ++---
 lib/cryptodev/rte_cryptodev.c |  2 +-
 lib/cryptodev/version.map | 25 +++
 lib/eventdev/rte_event_crypto_adapter.c   |  2 +-
 lib/eventdev/rte_eventdev.c   |  2 +-
 lib/pipeline/rte_table_action.c   |  2 +-
 62 files changed, 101 insertions(+), 76 deletions(-)
 rename lib/cryptodev/{rte_cryptodev_pmd.c => cryptodev_pmd.c} (99%)
 rename lib/cryptodev/{rte_cryptodev_pmd.h => cryptodev_pmd.h} (98%)

diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 886e2a5aaa..330aad8157 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -5,7 +5,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index 18dbc4c18c..edb7275e76 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -6,7 +6,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include "aesni_gcm_pmd_private.h"
 
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index a01c826a3c..60963a8208 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -7,7 +7,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
index fc7fdfec8e..48a8f91868 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_o

Re: [dpdk-dev] [PATCH] eal/windows: add sys/queue.h.

[Nick Connolly]

diff --git a/lib/eal/windows/include/meson.build 
b/lib/eal/windows/include/meson.build
index b3534b025f..875cc1cf0d 100644
--- a/lib/eal/windows/include/meson.build
+++ b/lib/eal/windows/include/meson.build
@@ -8,3 +8,7 @@ headers += files(
  'rte_virt2phys.h',
  'rte_windows.h',
  )
+
+sys_headers = []
+subdir('sys')
+install_headers(sys_headers, subdir: 'sys')
diff --git a/lib/eal/windows/include/sys/meson.build 
b/lib/eal/windows/include/sys/meson.build
new file mode 100644
index 00..6896cbf678
--- /dev/null
+++ b/lib/eal/windows/include/sys/meson.build
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2021 VMware, Inc
+
+sys_headers += files(
+'queue.h',
+)


Hi William,

If I've understood this change correctly it will create a sys/queue.h 
header in the build/include folder.
This seems like a reasonable approach to handle missing functionality, 
but unfortunately it is problematic.


An application that links against DPDK is likely to be dealing with 
similar issues with missing functionality
and providing a definition in the DPDK includes can conflict with the 
approach taken by the application
(in this instance there could be two versions of sys/queue.h in the 
include paths leading to ambiguity).


After discussion, the approach adopted by the DPDK community is that:

 * DPDK should depend only on the C library and not require POSIX
   functionality from the underlying
   system (headers, definitions etc). Missing functionality should be
   implemented within the DPDK
   code.
 * DPDK should not export POSIX functionality into the environment
   (symbols, macros, headers etc)
   to avoid these definitions clashing with the application.

In this instance, it seems that rte_log.h depends upon the system having 
sys/queue.h which is not
a standard C dependency. The appropriate response here (based on the 
above approach) is to remove
the sys/queue.h dependency from rte_log.h and ensure that it only 
depends upon rte_* definitions

contained within the DPDK.

Regards,
Nick

Re: [dpdk-dev] [PATCH] eal/windows: add sys/queue.h.

[Dmitry Kozlyuk]

2021-08-10 22:05 (UTC+0100), Nick Connolly:
> > diff --git a/lib/eal/windows/include/meson.build 
> > b/lib/eal/windows/include/meson.build
> > index b3534b025f..875cc1cf0d 100644
> > --- a/lib/eal/windows/include/meson.build
> > +++ b/lib/eal/windows/include/meson.build
> > @@ -8,3 +8,7 @@ headers += files(
> >   'rte_virt2phys.h',
> >   'rte_windows.h',
> >   )
> > +
> > +sys_headers = []
> > +subdir('sys')
> > +install_headers(sys_headers, subdir: 'sys')
> > diff --git a/lib/eal/windows/include/sys/meson.build 
> > b/lib/eal/windows/include/sys/meson.build
> > new file mode 100644
> > index 00..6896cbf678
> > --- /dev/null
> > +++ b/lib/eal/windows/include/sys/meson.build
> > @@ -0,0 +1,6 @@
> > +# SPDX-License-Identifier: BSD-3-Clause
> > +# Copyright 2021 VMware, Inc
> > +
> > +sys_headers += files(
> > +'queue.h',
> > +)  
> 
> Hi William,
> 
> If I've understood this change correctly it will create a sys/queue.h 
> header in the build/include folder.
> This seems like a reasonable approach to handle missing functionality, 
> but unfortunately it is problematic.
> 
> An application that links against DPDK is likely to be dealing with 
> similar issues with missing functionality
> and providing a definition in the DPDK includes can conflict with the 
> approach taken by the application
> (in this instance there could be two versions of sys/queue.h in the 
> include paths leading to ambiguity).
> 
> After discussion, the approach adopted by the DPDK community is that:
> 
>   * DPDK should depend only on the C library and not require POSIX
> functionality from the underlying
> system (headers, definitions etc). Missing functionality should be
> implemented within the DPDK
> code.
>   * DPDK should not export POSIX functionality into the environment
> (symbols, macros, headers etc)
> to avoid these definitions clashing with the application.
> 
> In this instance, it seems that rte_log.h depends upon the system having 
> sys/queue.h which is not
> a standard C dependency. The appropriate response here (based on the 
> above approach) is to remove
> the sys/queue.h dependency from rte_log.h and ensure that it only 
> depends upon rte_* definitions
> contained within the DPDK.

Hi William and Nick,

rte_log.h doesn't need sys/queue.h include at all.
Unfortunately, other public headers need it.
Worse, they use TAILQ_ENTRY in structures and TAILQ_FOREACH in macros.
We discussed this offline with Tyler and he approved installing ,
but it is right that doing so would be against the policy.

What we can do:

1. Introduce `rte_queue.h` (name can be better) that is env-specific:

   1.1. For Linux and FreeBSD it just includes 
and renames a few macros that are used in headers to RTE_xxx.
   1.2. For Windows it defines the same RTE_xxx macros in a way
compatible with the  version used to build DPDK.

2. Add #include  in :
   Linux and FreeBSD will include a system header,
   Windows will use the bundled one.

This way application are not exposed to non-RTE symbols,
at the same time RTE_xxx are binary-compatible with what DPDK
implementation expects (and outside of Windows there is no change in fact).

[dpdk-dev] [PATCH] build: fix install from arbitrary directory for meson 0.55

[Dmitry Kozlyuk]

Install command for meson >= 0.55.0 referenced the script by a plain
string, assuming the build directory to be directly under the source
tree root. This resulted in an error when the assumption did not hold:

c:\python\python.exe: can't open file
'../buildtools/symlink-drivers-solibs.py':
[Errno 2] No such file or directory

Use files() to make a valid script path for any build directory.

Fixes: cd27047dbee1 ("build: support drivers symlink on Windows")
Cc: nick.conno...@mayadata.io
Cc: sta...@dpdk.org

Signed-off-by: Dmitry Kozlyuk 
---
Note: this is not limited to Windows, it just happens that Windows
requires newer meson and the error example is from Windows build.

 config/meson.build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/config/meson.build b/config/meson.build
index e80421003b..3b5966ec2f 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -61,7 +61,8 @@ if not is_windows
 get_option('libdir'), pmd_subdir_opt)
 elif meson.version().version_compare('>=0.55.0')
 # 0.55.0 is required to use external program with add_install_script
-meson.add_install_script(py3, '../buildtools/symlink-drivers-solibs.py',
+meson.add_install_script(py3,
+files('../buildtools/symlink-drivers-solibs.py'),
 get_option('libdir'), pmd_subdir_opt, get_option('bindir'))
 endif
 
-- 
2.29.3

Re: [dpdk-dev] [PATCH v14 5/6] doc: add DMA device library guide

[fengchengwen]

Many thanks, will fix in v15

On 2021/8/10 23:27, Walsh, Conor wrote:
> [snip]
> 
> Hi Chengwen,
> I have included some feedback to improve the grammar and readability
> of the docs inline.
> 

[snip]

Re: [dpdk-dev] [PATCH 00/28] ice: base code update

[Zhang, Qi Z]

> -Original Message-
> From: Zhang, Qi Z 
> Sent: Tuesday, August 10, 2021 10:51 AM
> To: Yang, Qiming 
> Cc: Guo, Junfeng ; dev@dpdk.org; Zhang, Qi Z
> 
> Subject: [PATCH 00/28] ice: base code update
> 
> Summary:
> 
> 1. Add new module to support 1588 timesync / PTP.
> 2. Couple FDIR / RSS enhancement to support GRE tunnel and GTPU 3. Support
> l3/ l4 checksum RSS
> 
> Qi Zhang (28):
>   net/ice/base: add 1588 capability probe
>   net/ice/base: add low level functions for device clock control
>   net/ice/base: add ethertype IPv6 check for dummy packet
>   net/ice/base: change dummy packets with VLAN
>   net/ice/base: add timestamp masks
>   net/ice/base: add clock initialization function
>   net/ice/base: add accessors to get/set the time reference
>   net/ice/base: print human-friendly PHY types
>   net/ice/base: implement Vernier calibration logic for E822 devices
>   net/ice/base: clarify comments on checking PFC mode
>   net/ice/base: add support for starting PHY in bypass mode
>   net/ice/base: add E810T check function
>   net/ice/base: implement firmware debug dump
>   net/ice/base: add new AQ description
>   net/ice/base: refine MAC rule adding
>   net/ice/base: support TC nodes PIR configuration
>   net/ice/base: support FDIR for GRE tunnel packet
>   net/ice/base: support RSS for GRE tunnel packet
>   net/ice/base: support FDIR for GTPU EH inner IPv6
>   net/ice/base: support RSS for GTPoGRE
>   net/ice/base: enable NVM update reset capabilities
>   net/ice/base: support FDIR for GTPoGRE
>   net/ice/base: add RSS support for IPv4/L4 checksum
>   net/ice/base: enable jumbo frame support during HW init
>   net/ice/base: support FDIR for GTPU UL/DL with QFI fields
>   net/ice/base: rename and add a setter function
>   net/ice/base: correct spellling of word data
>   net/ice/base: update Max TCAM/PTG Per Profile
> 
>  drivers/net/ice/base/ice_adminq_cmd.h|   28 +
>  drivers/net/ice/base/ice_cgu_regs.h  |  117 +
>  drivers/net/ice/base/ice_common.c|  513 +++-
>  drivers/net/ice/base/ice_common.h|   21 +
>  drivers/net/ice/base/ice_controlq.c  |   52 +-
>  drivers/net/ice/base/ice_controlq.h  |2 +
>  drivers/net/ice/base/ice_dcb.c   |9 +-
>  drivers/net/ice/base/ice_devids.h|1 +
>  drivers/net/ice/base/ice_fdir.c  | 2387 ++-
>  drivers/net/ice/base/ice_fdir.h  |   14 +
>  drivers/net/ice/base/ice_flex_pipe.c |6 +
>  drivers/net/ice/base/ice_flex_type.h |   52 +-
>  drivers/net/ice/base/ice_flow.c  |  231 +-
>  drivers/net/ice/base/ice_flow.h  |   10 +
>  drivers/net/ice/base/ice_lan_tx_rx.h |8 +
>  drivers/net/ice/base/ice_protocol_type.h |4 +-
>  drivers/net/ice/base/ice_ptp_consts.h|  376 +++
>  drivers/net/ice/base/ice_ptp_hw.c| 3452 ++
>  drivers/net/ice/base/ice_ptp_hw.h|  473 +++
>  drivers/net/ice/base/ice_sched.c |3 +
>  drivers/net/ice/base/ice_switch.c|  172 +-
>  drivers/net/ice/base/ice_type.h  |  231 +-
>  drivers/net/ice/base/meson.build |1 +
>  23 files changed, 7892 insertions(+), 271 deletions(-)  create mode 100644
> drivers/net/ice/base/ice_cgu_regs.h
>  create mode 100644 drivers/net/ice/base/ice_ptp_consts.h
>  create mode 100644 drivers/net/ice/base/ice_ptp_hw.c  create mode
> 100644 drivers/net/ice/base/ice_ptp_hw.h
> 
> --
> 2.26.2

Applied to dpdk-next-net-intel.

Thanks
Qi

Re: [dpdk-dev] [PATCH 01/10] vdpa/sfc: introduce Xilinx vDPA driver

[Xia, Chenbo]

Hi Vijay,

> -Original Message-
> From: Vijay Srivastava 
> Sent: Wednesday, July 7, 2021 12:44 AM
> To: dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Xia, Chenbo ;
> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava 
> Subject: [PATCH 01/10] vdpa/sfc: introduce Xilinx vDPA driver
> 
> From: Vijay Kumar Srivastava 
> 
> Add new vDPA PMD to support vDPA operation by Xilinx devices.

vDPA operations of Xilinx devices

> This patch implements probe and remove functions.
> 
> Signed-off-by: Vijay Kumar Srivastava 
> ---
>  MAINTAINERS|   6 +
>  doc/guides/rel_notes/release_21_08.rst |   5 +
>  doc/guides/vdpadevs/features/sfc.ini   |   9 ++
>  doc/guides/vdpadevs/sfc.rst|  97 +++
>  drivers/vdpa/meson.build   |   1 +
>  drivers/vdpa/sfc/meson.build   |  33 
>  drivers/vdpa/sfc/sfc_vdpa.c| 286
> +
>  drivers/vdpa/sfc/sfc_vdpa.h|  40 +
>  drivers/vdpa/sfc/sfc_vdpa_log.h|  77 +
>  drivers/vdpa/sfc/version.map   |   3 +
>  10 files changed, 557 insertions(+)
>  create mode 100644 doc/guides/vdpadevs/features/sfc.ini
>  create mode 100644 doc/guides/vdpadevs/sfc.rst
>  create mode 100644 drivers/vdpa/sfc/meson.build
>  create mode 100644 drivers/vdpa/sfc/sfc_vdpa.c
>  create mode 100644 drivers/vdpa/sfc/sfc_vdpa.h
>  create mode 100644 drivers/vdpa/sfc/sfc_vdpa_log.h
>  create mode 100644 drivers/vdpa/sfc/version.map
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5877a16..ccc0a2a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1197,6 +1197,12 @@ F: drivers/vdpa/mlx5/
>  F: doc/guides/vdpadevs/mlx5.rst
>  F: doc/guides/vdpadevs/features/mlx5.ini
> 
> +Xilinx sfc vDPA
> +M: Vijay Kumar Srivastava 
> +F: drivers/vdpa/sfc/
> +F: doc/guides/vdpadevs/sfc.rst
> +F: doc/guides/vdpadevs/features/sfc.ini
> +
> 
>  Eventdev Drivers
>  
> diff --git a/doc/guides/rel_notes/release_21_08.rst
> b/doc/guides/rel_notes/release_21_08.rst
> index a6ecfdf..bb9aa83 100644
> --- a/doc/guides/rel_notes/release_21_08.rst
> +++ b/doc/guides/rel_notes/release_21_08.rst
> @@ -55,6 +55,11 @@ New Features
>   Also, make sure to start the actual text at the margin.
>   ===
> 
> +* **Add new vDPA PMD based on Xilinx devices.**
> +
> +  Added a new Xilinx vDPA  (``sfc_vdpa``) PMD.
> +  See the :doc:`../vdpadevs/sfc` guide for more details on this driver.
> +
> 
>  Removed Items
>  -
> diff --git a/doc/guides/vdpadevs/features/sfc.ini
> b/doc/guides/vdpadevs/features/sfc.ini
> new file mode 100644
> index 000..71b6158
> --- /dev/null
> +++ b/doc/guides/vdpadevs/features/sfc.ini
> @@ -0,0 +1,9 @@
> +;
> +; Supported features of the 'sfc' vDPA driver.
> +;
> +; Refer to default.ini for the full list of available driver features.
> +;
> +[Features]
> +Linux= Y
> +x86-64   = Y
> +Usage doc= Y
> diff --git a/doc/guides/vdpadevs/sfc.rst b/doc/guides/vdpadevs/sfc.rst
> new file mode 100644
> index 000..59f990b
> --- /dev/null
> +++ b/doc/guides/vdpadevs/sfc.rst
> @@ -0,0 +1,97 @@
> +..  SPDX-License-Identifier: BSD-3-Clause
> +Copyright(c) 2021 Xilinx Corporation.
> +
> +Xilinx vDPA driver
> +==
> +
> +The Xilinx vDPA (vhost data path acceleration) driver
> (**librte_pmd_sfc_vdpa**)
> +provides support for the Xilinx SN1022 SmartNICs family of 10/25/40/50/100
> Gbps
> +adapters has support for latest Linux and FreeBSD operating systems.

Adapters that have support for XXX?

> +
> +More information can be found at Xilinx website https://www.xilinx.com.
> +
> +
> +Xilinx vDPA implementation
> +--
> +
> +ef100 device can be configured in the net device or vDPA mode.
> +Adding "class=vdpa" parameter helps to specify that this
> +device is to be used in vDPA mode. If this parameter is not specified, device
> +will be probed by net/sfc driver and will used as a net device.
> +
> +This PMD uses libefx (common/sfc_efx) code to access the device firmware.
> +
> +
> +Supported NICs
> +--
> +
> +- Xilinx SN1022 SmartNICs
> +
> +
> +Features
> +
> +
> +Features of the Xilinx vDPA driver are:
> +
> +- Compatibility with virtio 0.95 and 1.0
> +
> +
> +Non-supported Features
> +--
> +
> +- Control Queue
> +- Multi queue
> +- Live Migration
> +
> +
> +Prerequisites
> +-
> +
> +Requires firmware version: v1.0.7.0 or higher
> +
> +Visit `Xilinx Support Downloads `_
> +to get Xilinx Utilities with the latest firmware.
> +Follow instructions from Alveo SN1000 SmartNICs User Guide to
> +update firmware and configure the adapter.
> +
> +
> +Per-Device Parameters
> +~
> +
> +The following per-device parameters can be passed via EAL PCI device
> +whitelist option like "-w 02:00.0,arg1=value1,...".

The 

Re: [dpdk-dev] [External] Re: [PATCH v2] app/testpmd: flowgen support ip and udp fields

[王志宏]

On Tue, Aug 10, 2021 at 5:12 PM Ferruh Yigit  wrote:
>
> On 8/10/2021 8:57 AM, 王志宏 wrote:
> > Thanks for the review Ferruh :)
> >
> > On Mon, Aug 9, 2021 at 11:18 PM Ferruh Yigit  wrote:
> >>
> >> On 8/9/2021 7:52 AM, Zhihong Wang wrote:
> >>> This patch aims to:
> >>>  1. Add flexibility by supporting IP & UDP src/dst fields
> >>
> >> What is the reason/"use case" of this flexibility?
> >
> > The purpose is to emulate pkt generator behaviors.
> >
>
> 'flowgen' forwarding is already to emulate pkt generator, but it was only
> changing destination IP.
>
> What additional benefit does changing udp ports of the packets brings? What is
> your usecase for this change?

Pkt generators like pktgen/trex/ixia/spirent can change various fields
including ip/udp src/dst.

Keeping the cfg_n_* while setting cfg_n_ip_dst = 1024 and others = 1
makes the default behavior exactly unchanged. Do you think it makes
sense?

>
> >>
> >>>  2. Improve multi-core performance by using per-core vars>
> >>
> >> On multi core this also has syncronization problem, OK to make it 
> >> per-core. Do
> >> you have any observed performance difference, if so how much is it?
> >
> > Huge difference, one example: 8 core flowgen -> rxonly results: 43
> > Mpps (per-core) vs. 9.3 Mpps (shared), of course the numbers "varies
> > depending on system configuration".
> >
>
> Thanks for clarification.
>
> >>
> >> And can you please separate this to its own patch? This can be before 
> >> ip/udp update.
> >
> > Will do.
> >
> >>
> >>> v2: fix assigning ip header cksum
> >>>
> >>
> >> +1 to update, can you please make it as seperate patch?
> >
> > Sure.
> >
> >>
> >> So overall this can be a patchset with 4 patches:
> >> 1- Fix retry logic (nb_rx -> nb_pkt)
> >> 2- Use 'rte_ipv4_cksum()' API (instead of static 'ip_sum()')
> >> 3- User per-core varible (for 'next_flow')
> >> 4- Support ip/udp src/dst variaty of packets
> >>
> >
> > Great summary. Thanks a lot.
> >
> >>> Signed-off-by: Zhihong Wang 
> >>> ---
> >>>  app/test-pmd/flowgen.c | 137 
> >>> +++--
> >>>  1 file changed, 86 insertions(+), 51 deletions(-)
> >>>
> >>
> >> <...>
> >>
> >>> @@ -185,30 +193,57 @@ pkt_burst_flow_gen(struct fwd_stream *fs)
> >>>   }
> >>>   pkts_burst[nb_pkt] = pkt;
> >>>
> >>> - next_flow = (next_flow + 1) % cfg_n_flows;
> >>> + if (++next_udp_dst < cfg_n_udp_dst)
> >>> + continue;
> >>> + next_udp_dst = 0;
> >>> + if (++next_udp_src < cfg_n_udp_src)
> >>> + continue;
> >>> + next_udp_src = 0;
> >>> + if (++next_ip_dst < cfg_n_ip_dst)
> >>> + continue;
> >>> + next_ip_dst = 0;
> >>> + if (++next_ip_src < cfg_n_ip_src)
> >>> + continue;
> >>> + next_ip_src = 0;
> >>
> >> What is the logic here, can you please clarifiy the packet generation 
> >> logic both
> >> in a comment here and in the commit log?
> >
> > It's round-robin field by field. Will add the comments.
> >
>
> Thanks. If the receiving end is doing RSS based on IP address, dst address 
> will
> change in every 100 packets and src will change in every 1 packets. This 
> is
> a slight behavior change.
>
> When it was only dst ip, it was simple to just increment it, not sure about it
> in this case. I wonder if we should set all randomly for each packet. I don't
> know what is the better logic here, we can discuss it more in the next 
> version.

A more sophisticated pkt generator provides various options among
"step-by-step" / "random" / etc.

But supporting multiple fields naturally brings this implicitly. It
won't be a problem as it can be configured by setting the cfg_n_* as
we discussed above.

I think rte_rand() is a good option, anyway this can be tweaked easily
once the framework becomes shaped.

>
> >>
> >>>   }
> >>>
> >>>   nb_tx = rte_eth_tx_burst(fs->tx_port, fs->tx_queue, pkts_burst, 
> >>> nb_pkt);
> >>>   /*
> >>>* Retry if necessary
> >>>*/
> >>> - if (unlikely(nb_tx < nb_rx) && fs->retry_enabled) {
> >>> + if (unlikely(nb_tx < nb_pkt) && fs->retry_enabled) {
> >>>   retry = 0;
> >>> - while (nb_tx < nb_rx && retry++ < burst_tx_retry_num) {
> >>> + while (nb_tx < nb_pkt && retry++ < burst_tx_retry_num) {
> >>>   rte_delay_us(burst_tx_delay_time);
> >>>   nb_tx += rte_eth_tx_burst(fs->tx_port, fs->tx_queue,
> >>> - &pkts_burst[nb_tx], nb_rx - nb_tx);
> >>> + &pkts_burst[nb_tx], nb_pkt - nb_tx);
> >>>   }
> >>
> >> +1 to this fix, thanks for it. But can you please make a seperate patch for
> >> this, with proper 'Fixes:' tag etc..
> >
> > Ok.
> >
> >>
> >>>   }
> >>> - fs->tx_packets += nb_tx;
> >>>
> >>>   inc_tx_burst_stats(fs, nb_tx);
>

[dpdk-dev] 回复: [PATCH v1 2/2] devtools: use absolute path for the build directory

[Feifei Wang]

Hi, Thomas

Thanks for your reviewing.

I agree with your comment. 
As your concern, this patch is simple but may have some negative effects.
Thus I will drop it from series in the next version.

Best Regards
Feifei

> -邮件原件-
> 发件人: Thomas Monjalon 
> 发送时间: Friday, August 6, 2021 11:43 PM
> 收件人: Phil Yang ; Feifei Wang
> 
> 抄送: Bruce Richardson ; dev@dpdk.org; nd
> ; Juraj Linkeš ; Ruifeng Wang
> ; david.march...@redhat.com
> 主题: Re: [dpdk-dev] [PATCH v1 2/2] devtools: use absolute path for the
> build directory
> 
> 01/06/2021 03:56, Feifei Wang:
> > From: Phil Yang 
> >
> > To make the code easier to maintain, use the absolute path for the
> > default build_dir to avoid repeatedly calling of readlink.
> [...]
> > --- a/devtools/test-meson-builds.sh
> > +++ b/devtools/test-meson-builds.sh
> > -builds_dir=${DPDK_BUILD_TEST_DIR:-.}
> > +builds_dir=$(readlink -f ${DPDK_BUILD_TEST_DIR:-.})
> 
> It means that all uses of builds_dir will get the absolute path.
> It may have consequences on meson configuration, and will make outputs
> and logs longer.
> 
> I'm not sure this change is desirable.
> 

[dpdk-dev] DTS Workgroup: MoM 08/03/2021

[Honnappa Nagarahalli]

Attendees:
Aaron Conole
Brandon Lo
Honnappa Nagarahalli
Juraj Linkes
Lijuan Tu
Owen Hilyard

The meeting announcements are sent to dev@dpdk.org.

Minutes:
1) Move DTS to follow standard python practices of organizing the project. This 
will be done after the 21.08 release. A write-up would be sent out to the 
community describing the change to ensure everyone is aware and can raise 
issues.
2) The work item related discussions are captured in [1]

Action Items:
1) Write a script that will output the testcases based on the files that are 
modified in the patch - Owen
2) Identify a set of test cases (based on the HW setup at Intel lab) to run for 
every patch - Lijuan
The union of the test cases from above two action items will run as DTS CI.
3) Possibility of hosting the DTS CI at UNH - Owen and Lincoln
4a) Send out a write up to the community to move DTS to follow standard python 
project format - Owen
4b) Create a patch once there is conclusion in the community on Owen's proposal 
- Juraj

[1] 
https://docs.google.com/document/d/1c5S0_mZzFvzZfYkqyORLT2-qNvUb-fBdjA6DGusy4yM/edit?usp=sharing

[dpdk-dev] [PATCH v2 0/1] relative path support for ABI compatibility check

[Feifei Wang]

Add relative path support for ABI compatibility check.

v2: 
1. delete the code simplification patch due to negative effects (Thomas)

Phil Yang (1):
  devtools: add relative path support for ABI compatibility check

 devtools/test-meson-builds.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.25.1

[dpdk-dev] [PATCH v2 1/1] devtools: add relative path support for ABI compatibility check

[Feifei Wang]

From: Phil Yang 

Because dpdk guide does not limit the relative path for ABI
compatibility check, users maybe set 'DPDK_ABI_REF_DIR' as a relative
path:

~/dpdk/devtools$ DPDK_ABI_REF_VERSION=v19.11 DPDK_ABI_REF_DIR=build-gcc-shared
./test-meson-builds.sh

And if the DESTDIR is not an absolute path, ninja complains:
+ install_target build-gcc-shared/v19.11/build 
build-gcc-shared/v19.11/build-gcc-shared
+ rm -rf build-gcc-shared/v19.11/build-gcc-shared
+ echo 'DESTDIR=build-gcc-shared/v19.11/build-gcc-shared ninja -C 
build-gcc-shared/v19.11/build install'
+ DESTDIR=build-gcc-shared/v19.11/build-gcc-shared
+ ninja -C build-gcc-shared/v19.11/build install
...
ValueError: dst_dir must be absolute, got 
build-gcc-shared/v19.11/build-gcc-shared/usr/local/share/dpdk/
examples/bbdev_app
...
Error: install directory 'build-gcc-shared/v19.11/build-gcc-shared' does not 
exist.

To fix this, add relative path support using 'readlink -f'.

Signed-off-by: Phil Yang 
Signed-off-by: Feifei Wang 
Reviewed-by: Juraj Linkeš 
Reviewed-by: Ruifeng Wang 
Acked-by: Bruce Richardson 
---
 devtools/test-meson-builds.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 9ec8e2bc7e..8ddde95276 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -168,7 +168,8 @@ build () #
[meson options]
config $srcdir $builds_dir/$targetdir $cross --werror $*
compile $builds_dir/$targetdir
if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
-   abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
+   abirefdir=$(readlink -f \
+   ${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION)
if [ ! -d $abirefdir/$targetdir ]; then
# clone current sources
if [ ! -d $abirefdir/src ]; then
-- 
2.25.1