[dpdk-dev] [PATCH 1/2] net/ice: add dcf port representor infrastructure

[Qiming Yang]

Defines data structures and code to init/uninit
VF representors during pci_probe and pci_remove
respectively.
Most of the dev_ops for the VF representor are just
stubs for now and will be will be filled out in next patch

Signed-off-by: Qiming Yang 
---
 drivers/net/ice/Makefile |   1 +
 drivers/net/ice/ice_dcf_ethdev.c |  66 +-
 drivers/net/ice/ice_dcf_ethdev.h |  11 +
 drivers/net/ice/ice_dcf_vf_representor.c | 245 +++
 4 files changed, 321 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/ice/ice_dcf_vf_representor.c

diff --git a/drivers/net/ice/Makefile b/drivers/net/ice/Makefile
index 34cd4024b..f9eb34a87 100644
--- a/drivers/net/ice/Makefile
+++ b/drivers/net/ice/Makefile
@@ -88,6 +88,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_generic_flow.c
 
 SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_dcf.c
 SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_dcf_ethdev.c
+SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_dcf_vf_representor.c
 SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_dcf_parent.c
 
 # install this header file
diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index 2faed3cc7..73af87785 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -973,17 +973,79 @@ ice_dcf_cap_selected(struct rte_devargs *devargs)
 static int eth_ice_dcf_pci_probe(__rte_unused struct rte_pci_driver *pci_drv,
 struct rte_pci_device *pci_dev)
 {
+   struct rte_eth_devargs eth_da = { .nb_representor_ports = 0 };
+   char name[RTE_ETH_NAME_MAX_LEN];
+   int i, retval;
+
if (!ice_dcf_cap_selected(pci_dev->device.devargs))
return 1;
 
-   return rte_eth_dev_pci_generic_probe(pci_dev,
+   if (pci_dev->device.devargs) {
+   retval = rte_eth_devargs_parse(pci_dev->device.devargs->args,
+  ð_da);
+   if (retval)
+   return retval;
+   }
+
+   retval =  rte_eth_dev_pci_generic_probe(pci_dev,
 sizeof(struct ice_dcf_adapter),
 ice_dcf_dev_init);
+   if (retval)
+   return retval;
+
+   /* probe VF representor ports */
+   struct rte_eth_dev *dcf_ethdev =
+   rte_eth_dev_allocated(pci_dev->device.name);
+
+   if (dcf_ethdev == NULL) {
+   PMD_DRV_LOG(ERR, "failed to allocate ethdev.\n");
+   return -ENODEV;
+   }
+
+   for (i = 0; i < eth_da.nb_representor_ports; i++) {
+   if (eth_da.representor_ports[i] == 0) {
+   PMD_DRV_LOG(ERR, "vf 0 can't be a vf representor.\n");
+   continue;
+   }
+
+   struct ice_dcf_vf_representor representor = {
+   .vf_id = eth_da.representor_ports[i],
+   .switch_domain_id = 0,
+   .adapter = (struct ice_dcf_adapter *)
+  dcf_ethdev->data->dev_private
+   };
+
+   snprintf(name, sizeof(name), "net_%s_representor_%d",
+   pci_dev->device.name, eth_da.representor_ports[i]);
+
+   retval = rte_eth_dev_create(&pci_dev->device, name,
+   sizeof(struct ice_dcf_vf_representor),
+   NULL, NULL, ice_dcf_vf_representor_init,
+   &representor);
+
+   if (retval)
+   PMD_DRV_LOG(ERR,
+   "failed to create dcf vf representor %s.\n",
+   name);
+   }
+
+   return 0;
 }
 
 static int eth_ice_dcf_pci_remove(struct rte_pci_device *pci_dev)
 {
-   return rte_eth_dev_pci_generic_remove(pci_dev, ice_dcf_dev_uninit);
+   struct rte_eth_dev *ethdev;
+
+   ethdev = rte_eth_dev_allocated(pci_dev->device.name);
+   if (!ethdev)
+   return 0;
+
+   if (ethdev->data->dev_flags & RTE_ETH_DEV_REPRESENTOR)
+   return rte_eth_dev_pci_generic_remove(pci_dev,
+   ice_dcf_dev_uninit);
+   else
+   return rte_eth_dev_pci_generic_remove(pci_dev,
+   ice_dcf_vf_representor_uninit);
 }
 
 static const struct rte_pci_id pci_id_ice_dcf_map[] = {
diff --git a/drivers/net/ice/ice_dcf_ethdev.h b/drivers/net/ice/ice_dcf_ethdev.h
index b54528bea..bf6e6982f 100644
--- a/drivers/net/ice/ice_dcf_ethdev.h
+++ b/drivers/net/ice/ice_dcf_ethdev.h
@@ -22,9 +22,20 @@ struct ice_dcf_adapter {
struct ice_dcf_hw real_hw;
 };
 
+/**
+ * Struct to store private data for each VF representor instance
+ */
+struct ice_dcf_vf_representor {
+   struct ice_dcf_adapter *adapter;
+   uint16_t switch_domain_id;
+   uint16_t vf_id;
+};
+
 void ice_dcf_handle_pf_event_msg(struct ice_dcf_hw *dcf_

[dpdk-dev] [PATCH 2/2] net/ice: add VLAN config for DCF

[Qiming Yang]

This patch add support for VF VLAN offload, port VLAN id set and
VLAN ethertype set in DCF.

This patch depend on base code update.

Signed-off-by: Qiming Yang 
---
 drivers/net/ice/ice_dcf.h|   1 +
 drivers/net/ice/ice_dcf_vf_representor.c | 120 +++
 2 files changed, 121 insertions(+)

diff --git a/drivers/net/ice/ice_dcf.h b/drivers/net/ice/ice_dcf.h
index a44a01e90..b960cf7cf 100644
--- a/drivers/net/ice/ice_dcf.h
+++ b/drivers/net/ice/ice_dcf.h
@@ -59,6 +59,7 @@ struct ice_dcf_hw {
uint16_t nb_msix;
uint16_t rxq_map[16];
struct virtchnl_eth_stats eth_stats_offset;
+   struct virtchnl_dcf_vlan_offload vlan_config;
 };
 
 int ice_dcf_execute_virtchnl_cmd(struct ice_dcf_hw *hw,
diff --git a/drivers/net/ice/ice_dcf_vf_representor.c 
b/drivers/net/ice/ice_dcf_vf_representor.c
index ceb54ab15..53d0db85f 100644
--- a/drivers/net/ice/ice_dcf_vf_representor.c
+++ b/drivers/net/ice/ice_dcf_vf_representor.c
@@ -185,6 +185,123 @@ ice_dcf_representor_dev_info_get(struct rte_eth_dev *dev,
return 0;
 }
 
+static int
+ice_dcf_config_vlan_offload(struct ice_dcf_hw *hw,
+   struct virtchnl_dcf_vlan_offload *vlan_config)
+{
+   struct dcf_virtchnl_cmd args;
+   int err;
+
+   memset(&args, 0, sizeof(args));
+   args.v_op = VIRTCHNL_OP_DCF_VLAN_OFFLOAD;
+   args.req_msg = (uint8_t *)vlan_config;
+   args.req_msglen = sizeof(vlan_config);
+   err = ice_dcf_execute_virtchnl_cmd(hw, &args);
+   if (err)
+   PMD_DRV_LOG(ERR, "fail to execute command %s",
+"VIRTCHNL_OP_DCF_VLAN_OFFLOAD");
+   return err;
+}
+
+static int
+ice_dcf_representor_vlan_offload_set(struct rte_eth_dev *dev, int mask)
+{
+   struct ice_dcf_vf_representor *representor = dev->data->dev_private;
+   struct ice_dcf_hw *hw = &representor->adapter->real_hw;
+   struct virtchnl_dcf_vlan_offload vlan_config;
+   int ret = 0;
+
+   vlan_config.vf_id = representor->vf_id;
+
+   if (hw->vlan_config.tx_flags == VIRTCHNL_VLAN_TX_INSERT) {
+   PMD_DRV_LOG(ERR, "Please clear pvid before set vlan offload.");
+   return -EINVAL;
+   }
+
+   if (mask & ETH_VLAN_STRIP_MASK) {
+   if (hw->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN) {
+   vlan_config.type = VIRTCHNL_VLAN_OUTER_TYPE;
+   vlan_config.rx_flags = VIRTCHNL_VLAN_RX_STRIP_IN_DESC;
+   vlan_config.tx_flags = VIRTCHNL_VLAN_TX_INSERT_BY_DESC;
+   } else {
+   vlan_config.type = VIRTCHNL_VLAN_OUTER_TYPE;
+   vlan_config.rx_flags = VIRTCHNL_VLAN_RX_NO_STRIP;
+   vlan_config.tx_flags = VIRTCHNL_VLAN_TX_INSERT_BY_DESC;
+   }
+   ret = ice_dcf_config_vlan_offload(hw, &vlan_config);
+   if (ret < 0) {
+   PMD_DRV_LOG(ERR, "Failed to set vlan offload.");
+   return -EINVAL;
+   }
+   }
+
+   rte_memcpy(&hw->vlan_config, &vlan_config, sizeof(vlan_config));
+
+   return ret;
+}
+
+static int
+ice_dcf_representor_vlan_pvid_set(struct rte_eth_dev *dev,
+ uint16_t pvid, int on)
+{
+   struct ice_dcf_vf_representor *representor = dev->data->dev_private;
+   struct ice_dcf_hw *hw = &representor->adapter->real_hw;
+   struct virtchnl_dcf_vlan_offload vlan_config;
+   int ret;
+
+   vlan_config.vf_id = representor->vf_id;
+   vlan_config.type = VIRTCHNL_VLAN_OUTER_TYPE;
+   vlan_config.vlan_id = pvid;
+   if (on) {
+   vlan_config.rx_flags = VIRTCHNL_VLAN_RX_STRIP_ONLY;
+   vlan_config.tx_flags = VIRTCHNL_VLAN_TX_INSERT;
+   } else {
+   vlan_config.rx_flags = VIRTCHNL_VLAN_RX_NO_STRIP;
+   vlan_config.tx_flags = VIRTCHNL_VLAN_TX_INSERT_BY_DESC;
+   }
+
+   ret = ice_dcf_config_vlan_offload(hw, &vlan_config);
+   if (ret < 0) {
+   PMD_DRV_LOG(ERR, "Failed to set pvid.");
+   return -EINVAL;
+   }
+
+   rte_memcpy(&hw->vlan_config, &vlan_config, sizeof(vlan_config));
+
+   return 0;
+}
+
+static int
+ice_dcf_representor_vlan_tpid_set(struct rte_eth_dev *dev,
+ enum rte_vlan_type vlan_type,
+ uint16_t tpid)
+{
+   struct ice_dcf_vf_representor *representor = dev->data->dev_private;
+   struct ice_dcf_hw *hw = &representor->adapter->real_hw;
+   struct virtchnl_dcf_vlan_offload vlan_config;
+   int ret;
+
+   if (vlan_type != ETH_VLAN_TYPE_INNER &&
+   vlan_type != ETH_VLAN_TYPE_OUTER) {
+   PMD_DRV_LOG(ERR,
+   "Unsupported vlan type.");
+   return -EINVAL;
+   }
+
+   vlan_config.vf_id = representor->vf_id;
+   vlan_config.ether_type = tpid;
+   ret = ice_dc

Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add a field for rxq info structure

[Matan Azrad]

Hi Chengchang

From: Chengchang Tang
> Hi, Matan
> 
> On 2020/9/1 23:33, Matan Azrad wrote:
> >
> > Hi Chengchang
> >
> > Please see some question below.
> >
> > From: Chengchang Tang
> >> Add a field named rx_buf_size in rte_eth_rxq_info to indicate the
> >> buffer size used in receiving packets for HW.
> >>
> >> In this way, upper-layer users can get this information by calling
> >> rte_eth_rx_queue_info_get.
> >>
> >> Signed-off-by: Chengchang Tang 
> >> Reviewed-by: Wei Hu (Xavier) 
> >> Acked-by: Andrew Rybchenko 
> >> ---
> >>  lib/librte_ethdev/rte_ethdev.h | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/lib/librte_ethdev/rte_ethdev.h
> >> b/lib/librte_ethdev/rte_ethdev.h index 70295d7..9fed5cb 100644
> >> --- a/lib/librte_ethdev/rte_ethdev.h
> >> +++ b/lib/librte_ethdev/rte_ethdev.h
> >> @@ -1420,6 +1420,8 @@ struct rte_eth_rxq_info {
> >> struct rte_eth_rxconf conf; /**< queue config parameters. */
> >> uint8_t scattered_rx;   /**< scattered packets RX supported. */
> >> uint16_t nb_desc;   /**< configured number of RXDs. */
> >> +   /**< buffer size used for hardware when receive packets. */
> >> +   uint16_t rx_buf_size;
> >
> > Is it the maximum supported Rx buffer by the HW?
> > If yes, maybe max_rx_buf_size is better name?
> 
> No, it is the Rx buffer size currently used by HW.

Doesn't it defined by the user? Using Rx queue mem-pool mbuf room size?

And it may be different per Rx queue

> IMHO, the structure rte_eth_rxq_info and associated query API are mainly
> used to query HW configurations at runtime or after queue is
> configured/setup. Therefore, the content of this structure should be the
> current HW configuration.

It looks me more like capabilities...
The one which define the current configuration is the user by the configuration 
APIs(after reading the capabilities).

I don't think we have here all the current configurations, so what is special 
in this one?


> > Maybe document that 0 means - no limitation by HW?
> 
> Yes, there is no need to fill this filed for HW that has no restrictions on 
> it.
> I'll add it in v4.
> 
> > Must application read it in order to know if its datapath should handle
> multi-segment buffers?
> 
> I think it's more appropriate to use scattered_rx to determine if multi-
> segment buffers should be handled.
> 
> >
> > Maybe it will be good to force application to configure scatter when this
> field is valid and smaller than max_rx_pkt_len\max_lro.. (<= room size)...

Can you explain more what is the issue you came to solve?

> >
> >>  } __rte_cache_min_aligned;
> >>
> >>  /**
> 

Re: [dpdk-dev] [PATCH 0/2] fixes for bnxt driver

[Ajit Khaparde]

On Fri, Jul 31, 2020 at 5:09 AM wangyunjian  wrote:

> From: Yunjian Wang 
>
> This series include two fixes patches for bnxt driver.
>
> Yunjian Wang (2):
>   net/bnxt: fix memory leak when freeing vf_info
>   net/bnxt: add memory allocation check in vf_info init
>
Patchset applied to dpdk-next-net-brcm. Thanks


>
>  drivers/net/bnxt/bnxt_ethdev.c |  3 +--
>  drivers/net/bnxt/bnxt_hwrm.c   | 22 --
>  drivers/net/bnxt/bnxt_hwrm.h   |  1 +
>  3 files changed, 22 insertions(+), 4 deletions(-)
>
> --
> 2.23.0
>
>
>

Re: [dpdk-dev] [PATCH] net/bnxt: remove redundant null check in bnxt_validate_and_parse_flow_type

[Ajit Khaparde]

On Wed, Aug 5, 2020 at 8:52 PM Gaurav Singh  wrote:

> vxlan_spec cannot be NULL since its already being accessed
> before. Remove the redundant NULL check.
>
> Signed-off-by: Gaurav Singh 
>
Patch applied to dpdk-next-net-brcm. Thanks


> ---
>  drivers/net/bnxt/bnxt_flow.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/bnxt/bnxt_flow.c b/drivers/net/bnxt/bnxt_flow.c
> index 320b53d94..c1c59bbe5 100644
> --- a/drivers/net/bnxt/bnxt_flow.c
> +++ b/drivers/net/bnxt/bnxt_flow.c
> @@ -554,7 +554,7 @@ bnxt_validate_and_parse_flow_type(struct bnxt *bp,
> }
>
> /* Check if VNI is masked. */
> -   if (vxlan_spec && vxlan_mask) {
> +   if (vxlan_mask != NULL) {
> vni_masked =
> !!memcmp(vxlan_mask->vni, vni_mask,
>  RTE_DIM(vni_mask));
> --
> 2.17.1
>
>

[dpdk-dev] Broadcom DPDK 20.11 roadmap

[Ajit Khaparde]

The following is Broadcom's roadmap for DPDK 20.11:

* Crypto PMD for Smart NIC (Stingray)
* Vector mode performance improvements for x86 and ARM
* vSwitch acceleration support for Smart NIC (Stingray)
* SR-IOV support on PF PMD
* RSS level (outer versus inner) selection support
* VXLAN Decap offload support
* Mirroring support

[dpdk-dev] [PATCH v4] net/i40e: fix link status

[Guinan Sun]

If the PF driver supports the new speed reporting capabilities
then use link_event_adv instead of link_event to get the speed.

Fixes: 2a73125b7041 ("i40evf: fix link info update")
Cc: sta...@dpdk.org

Signed-off-by: Guinan Sun 
Tested-by: Shougang Wang 
---
v4:
* fix compilation issue in meson build
v3:
* request the capability for i40evf
v2:
* modify commit log
* add code comments
* delete useless code
---
 drivers/net/i40e/base/virtchnl.h  | 16 ++-
 drivers/net/i40e/i40e_ethdev_vf.c | 45 ---
 2 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/drivers/net/i40e/base/virtchnl.h b/drivers/net/i40e/base/virtchnl.h
index 4f498ca45..9c64fd469 100644
--- a/drivers/net/i40e/base/virtchnl.h
+++ b/drivers/net/i40e/base/virtchnl.h
@@ -240,7 +240,8 @@ VIRTCHNL_CHECK_STRUCT_LEN(16, virtchnl_vsi_resource);
 #define VIRTCHNL_VF_OFFLOAD_ENCAP  0X0010
 #define VIRTCHNL_VF_OFFLOAD_ENCAP_CSUM 0X0020
 #define VIRTCHNL_VF_OFFLOAD_RX_ENCAP_CSUM  0X0040
-
+/* Define below the capability flags that are not offloads */
+#define VIRTCHNL_VF_CAP_ADV_LINK_SPEED 0x0080
 #define VF_BASE_MODE_OFFLOADS (VIRTCHNL_VF_OFFLOAD_L2 | \
   VIRTCHNL_VF_OFFLOAD_VLAN | \
   VIRTCHNL_VF_OFFLOAD_RSS_PF)
@@ -536,10 +537,23 @@ enum virtchnl_event_codes {
 struct virtchnl_pf_event {
enum virtchnl_event_codes event;
union {
+   /* If the PF driver does not support the new speed reporting
+* capabilities then use link_event else use link_event_adv to
+* get the speed and link information. The ability to understand
+* new speeds is indicated by setting the capability flag
+* VIRTCHNL_VF_CAP_ADV_LINK_SPEED in vf_cap_flags parameter
+* in virtchnl_vf_resource struct and can be used to determine
+* which link event struct to use below.
+*/
struct {
enum virtchnl_link_speed link_speed;
bool link_status;
} link_event;
+   struct {
+   /* link_speed provided in Mbps */
+   u32 link_speed;
+   u8 link_status;
+   } link_event_adv;
} event_data;
 
int severity;
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 69cab8e73..664de5e5e 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -469,7 +469,8 @@ i40evf_get_vf_resource(struct rte_eth_dev *dev)
   VIRTCHNL_VF_OFFLOAD_RSS_AQ |
   VIRTCHNL_VF_OFFLOAD_RSS_REG |
   VIRTCHNL_VF_OFFLOAD_VLAN |
-  VIRTCHNL_VF_OFFLOAD_RX_POLLING;
+  VIRTCHNL_VF_OFFLOAD_RX_POLLING |
+  VIRTCHNL_VF_CAP_ADV_LINK_SPEED;
args.in_args = (uint8_t *)∩︀
args.in_args_size = sizeof(caps);
} else {
@@ -1386,8 +1387,46 @@ i40evf_handle_pf_event(struct rte_eth_dev *dev, uint8_t 
*msg,
break;
case VIRTCHNL_EVENT_LINK_CHANGE:
PMD_DRV_LOG(DEBUG, "VIRTCHNL_EVENT_LINK_CHANGE event");
-   vf->link_up = pf_msg->event_data.link_event.link_status;
-   vf->link_speed = pf_msg->event_data.link_event.link_speed;
+
+   if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_CAP_ADV_LINK_SPEED) {
+   vf->link_up =
+   pf_msg->event_data.link_event_adv.link_status;
+
+   switch (pf_msg->event_data.link_event_adv.link_speed) {
+   case ETH_SPEED_NUM_100M:
+   vf->link_speed = VIRTCHNL_LINK_SPEED_100MB;
+   break;
+   case ETH_SPEED_NUM_1G:
+   vf->link_speed = VIRTCHNL_LINK_SPEED_1GB;
+   break;
+   case ETH_SPEED_NUM_2_5G:
+   vf->link_speed = VIRTCHNL_LINK_SPEED_2_5GB;
+   break;
+   case ETH_SPEED_NUM_5G:
+   vf->link_speed = VIRTCHNL_LINK_SPEED_5GB;
+   break;
+   case ETH_SPEED_NUM_10G:
+   vf->link_speed = VIRTCHNL_LINK_SPEED_10GB;
+   break;
+   case ETH_SPEED_NUM_20G:
+   vf->link_speed = VIRTCHNL_LINK_SPEED_20GB;
+   break;
+   case ETH_SPEED_NUM_25G:
+   vf->link_speed = VIRTCHNL_LINK_SPEED_25GB;
+   break;
+   case ETH_SPEED_NUM_40G:
+   vf->link_speed = VIRT

Re: [dpdk-dev] [PATCH v4 2/2] Add l2reflect measurement application

[Thomas Monjalon]

02/09/2020 09:56, Henning Schild:
> Am Tue, 01 Sep 2020 17:07:38 +0200
> schrieb Thomas Monjalon :
> 
> > 28/08/2020 16:22, Henning Schild:
> > > Thomas,
> > > 
> > > what is the state on this one? Any more steps to take or people to
> > > involve?  
> > 
> > I can try adding some key people in Cc list,
> > while doing a quick review.
> >
> >
> > > I first showed that in action back in 2016 on FOSDEM.
> > > https://archive.fosdem.org/2016/schedule/event/virt_iaas_real_time_cloud/
> > > After my talk two devs from dpdk approached me because they liked
> > > the idea of a "network cyclictest". It took us some time to finally
> > > go upstream with it, unfortunately i do not recall names.  
> > 
> > I think I was one of them.
> > 
> > There will be some talks about latency in the next virtual DPDK event:
> > https://events.linuxfoundation.org/dpdk-userspace-summit/program/schedule/
> > (speakers are Cc'ed)
> 
> Thanks, that sure looks like we are not the only ones who are
> interested in latency and probably a way to measure it. From other
> doing it as well it would be nice to hear how they currently do that.
> 
> > > This application can potentially be integrated into the test-suite
> > > for QA, making sure no changes heavily increase the package
> > > transmission worst case timing.  
> > 
> > Good
> > 
> > 
> > > Felix Moessbauer  wrote:
> > >   
> > > > The l2reflect application implements a ping-pong benchmark to
> > > > measure the latency between two instances. For communication,
> > > > we use raw ethernet and send one packet at a time. The timing data
> > > > is collected locally and min/max/avg values are displayed in a
> > > > TUI. Finally, a histogram of the latencies is printed which can be
> > > > further processed with the jitterdebugger visualization scripts.  
> > 
> > Please can you show an example of script usage?

[...]
> > > > + * Copyright(c) 2020 Siemens AG
> > > > + *
> > > > + * authors:
> > > > + *   Felix Moessbauer 
> > > > + *   Henning Schild   
> > 
> > It is uncommon to mention authors in the file.
> > In general, git metadata covers this info.
> > Any special requirement?
> 
> That application has some history. Written by me and eventually
> improved for upstream by Felix. The idea here was to give credit to two
> people with just one author field in git. If that is really in the way,
> we can drop it and make Felix the sole author.

You are both marked as authors thanks to the sign-off:
Signed-off-by: Felix Moessbauer 
Signed-off-by: Henning Schild 

[...]
> > > > +__rte_format_printf(1, 0)
> > > > +static void
> > > > +trace_write(const char *fmt, ...)
> > > > +{
> > > > +   va_list ap;
> > > > +   char buf[256];
> > > > +   int n, err;
> > > > +
> > > > +   if (trace_fd == 0)
> > > > +   trace_fd =
> > > > open("/sys/kernel/debug/tracing/trace_marker",
> > > > +   O_WRONLY);  
> > 
> > Why not using rte_trace framework?
> 
> I am not sure where rte_trace ends up eventually. But the idea here is
> to have kernel traces when looking at latency peaks. You might just be
> looking at an incorrect host tuning when you see a spike i.e. higher
> prio threads on your possibly isolated core.
> It is not tracing dpdk, but more how it fits in the overall picture.

How Linux trace helps more than DPDK one? Because of scheduler context?
Anyway this is Linux-specific.

[...]
> > If I understand well, this requires a special cabling?
> > Would it be possible to measure latency of hardware NIC internal
> > loopback or software PMD loopback?
> 
> Not sure. We always want to see the full picture ... i.e would also
> want to see if a NIC is slow to put a packet on the "wire".
> For testing we do use multi-port NICs with cable-loops. The other setup
> is Qemus with the application inside and a dpdk-based vhost switch. But
> that virtual setup is also not trivial. In fact we usually do make that
> switch send the packets over the cable-loop to again cover the whole
> way the packets go "in reality".

That's why I wonder whether it should be located in DTS.

[...]
> > > > +cjson = dependency('libcjson', required: false)  
> > 
> > Some other parts require jansson:
> > jansson = dependency('jansson', required: false)
> > How libcjson is different? Would it be possible to unify dependency?
> > 
> > > > +if not is_linux
> > > > +build = false  
> > 
> > Why limiting to Linux?
> 
> Probably because of the RT stuff (sched param setting, mlock) and the
> tracing. I would propose it like that and hope that others might ifdef
> when enabling other OSs.

Yes that's reasonnable to support only Linux in the first version.

> Maintaining low latency requires quite a bit of host tuning. This can
> get especially tricky when consuming the whole CPU with polling, you
> can starve your OS. The application alone does not do that for you, not
> even on Linux. Like cyclictest or jitterdebugger i would see it as a
> tool that requi

[dpdk-dev] [PATCH] vdpa/mlx5: fix completion queue assertion

[Matan Azrad]

The CQ configuration enables the collapse feature in HW what cause HW to
write all the completions in the first CQE.
When this feature is enabled the HW doesn't switch the owner bit when it
starts a new cycle of the CQ, not like working without the collapse
feature.

The current SW CQ polling wrongly added an assertion to validate the
owner bit switch what causes a panic in debug mode.

Remove the aforementioned assertion.

Fixes: c5f714e50b0e ("vdpa/mlx5: optimize completion queue poll")
Cc: sta...@dpdk.org

Signed-off-by: Matan Azrad 
Acked-by: Xueming Li 
---
 drivers/vdpa/mlx5/mlx5_vdpa_event.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/vdpa/mlx5/mlx5_vdpa_event.c 
b/drivers/vdpa/mlx5/mlx5_vdpa_event.c
index 5a2d4fb..742ee62 100644
--- a/drivers/vdpa/mlx5/mlx5_vdpa_event.c
+++ b/drivers/vdpa/mlx5/mlx5_vdpa_event.c
@@ -205,8 +205,6 @@
comp = (cur_wqe_counter + 1u - next_wqe_counter) & cq_mask;
if (comp) {
cq->cq_ci += comp;
-   MLX5_ASSERT(!!(cq->cq_ci & cq_size) ==
-   MLX5_CQE_OWNER(last_word.op_own));
MLX5_ASSERT(MLX5_CQE_OPCODE(last_word.op_own) !=
MLX5_CQE_INVALID);
if (unlikely(!(MLX5_CQE_OPCODE(last_word.op_own) ==
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH] rte_log: make rte_logs private

[David Marchand]

On Fri, Aug 28, 2020 at 12:54 AM Stephen Hemminger
 wrote:
>
> As announced in earlier releases, rte_logs can now be made
> internal to eal_common_log.

I had prepared this cleanup before my PTO and was about to send it.
Just to avoid duplicate work, do you intend to work on other cleanups ?


Hiding this symbol is fine, but we must remove the experimental tag on
rte_log_get_stream since it becomes the only way to access the log
stream.

More comments below.
Thanks.


>
> Signed-off-by: Stephen Hemminger 
> ---
>  doc/guides/rel_notes/deprecation.rst   |  4 
>  doc/guides/rel_notes/release_20_11.rst |  2 ++
>  lib/librte_eal/common/eal_common_log.c | 11 ---
>  lib/librte_eal/include/rte_log.h   | 16 ++--
>  lib/librte_eal/rte_eal_version.map |  1 -
>  5 files changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index 345c38d5b630..5445a4f0a061 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -77,10 +77,6 @@ Deprecation Notices
>  * eal: The function ``rte_eal_remote_launch`` will return new error codes
>after read or write error on the pipe, instead of calling ``rte_panic``.
>
> -* eal: The ``rte_logs`` struct and global symbol will be made private to
> -  remove it from the externally visible ABI and allow it to be updated in the
> -  future.
> -
>  * eal: The ``rte_dev_event`` structure will be made private to the EAL as no
>public API makes use of it.
>
> diff --git a/doc/guides/rel_notes/release_20_11.rst 
> b/doc/guides/rel_notes/release_20_11.rst
> index df227a1773b8..e422ac790912 100644
> --- a/doc/guides/rel_notes/release_20_11.rst
> +++ b/doc/guides/rel_notes/release_20_11.rst
> @@ -84,6 +84,8 @@ API Changes
> Also, make sure to start the actual text at the margin.
> ===
>
> +* eal: The ``rte_logs`` struct and global symbol was made private
> +  and is no longer part of the API.

Missing double empty line.


>
>  ABI Changes
>  ---
> diff --git a/lib/librte_eal/common/eal_common_log.c 
> b/lib/librte_eal/common/eal_common_log.c
> index 8835c8fff897..a25766de181a 100644
> --- a/lib/librte_eal/common/eal_common_log.c
> +++ b/lib/librte_eal/common/eal_common_log.c
> @@ -17,11 +17,16 @@
>
>  #include "eal_private.h"
>
> -/* global log structure */
> -struct rte_logs rte_logs = {
> +/** The rte_log structure. */
> +static struct rte_logs {
> +   uint32_t type;  /**< Bitfield with enabled logs. */
> +   uint32_t level; /**< Log level. */
> +   FILE *file; /**< Output file set by rte_openlog_stream, or NULL. 
> */
> +   size_t dynamic_types_len;
> +   struct rte_log_dynamic_type *dynamic_types;
> +} rte_logs = {
> .type = ~0,
> .level = RTE_LOG_DEBUG,
> -   .file = NULL,
>  };
>
>  struct rte_eal_opt_loglevel {
> diff --git a/lib/librte_eal/include/rte_log.h 
> b/lib/librte_eal/include/rte_log.h
> index eaf66e4f61de..655c3b39c29e 100644
> --- a/lib/librte_eal/include/rte_log.h
> +++ b/lib/librte_eal/include/rte_log.h
> @@ -29,18 +29,6 @@ extern "C" {
>
>  struct rte_log_dynamic_type;

No need for rte_log_dynamic_type forward declaration anymore if you
simply move rte_logs or this type declaration in eal_common_log.c.


>
> -/** The rte_log structure. */
> -struct rte_logs {
> -   uint32_t type;  /**< Bitfield with enabled logs. */
> -   uint32_t level; /**< Log level. */
> -   FILE *file; /**< Output file set by rte_openlog_stream, or NULL. 
> */
> -   size_t dynamic_types_len;
> -   struct rte_log_dynamic_type *dynamic_types;
> -};
> -
> -/** Global log information */
> -extern struct rte_logs rte_logs;
> -
>  /* SDK log type */
>  #define RTE_LOGTYPE_EAL0 /**< Log related to eal. */
>  #define RTE_LOGTYPE_MALLOC 1 /**< Log related to malloc. */
> @@ -274,7 +262,7 @@ void rte_log_dump(FILE *f);
>   * to rte_openlog_stream().
>   *
>   * The level argument determines if the log should be displayed or
> - * not, depending on the global rte_logs variable.
> + * not, depending on the loglevel settings.
>   *
>   * The preferred alternative is the RTE_LOG() because it adds the
>   * level and type in the logged string.
> @@ -305,7 +293,7 @@ int rte_log(uint32_t level, uint32_t logtype, const char 
> *format, ...)
>   * to rte_openlog_stream().
>   *
>   * The level argument determines if the log should be displayed or
> - * not, depending on the global rte_logs variable. A trailing
> + * not, depending on the loglevel settings. A trailing
>   * newline may be added if needed.
>   *
>   * The preferred alternative is the RTE_LOG() because it adds the
> diff --git a/lib/librte_eal/rte_eal_version.map 
> b/lib/librte_eal/rte_eal_version.map
> index 0b18e2ef85f9..6b0dfdd9667c 100644
> --- a/lib/librte_eal/rte_eal_version.map
> +++ b/lib/librte_eal/rte_eal_version.map
> @@ -114,7 +114,6 @@ 

[dpdk-dev] [PATCH] net/iavf: support enhanced VLAN offload

[Qiming Yang]

This patch add VIRTCHNL_VF_OFFLOAD_VLAN_V2 series virtual channel
support, included get VLAN offload capability, support VLAN filter
and double VLAN strip.

Signed-off-by: Qiming Yang 
---
 drivers/net/iavf/iavf.h|  5 ++
 drivers/net/iavf/iavf_ethdev.c | 70 ---
 drivers/net/iavf/iavf_vchnl.c  | 87 ++
 3 files changed, 145 insertions(+), 17 deletions(-)

diff --git a/drivers/net/iavf/iavf.h b/drivers/net/iavf/iavf.h
index 9ad331ee9..8c10f7e59 100644
--- a/drivers/net/iavf/iavf.h
+++ b/drivers/net/iavf/iavf.h
@@ -149,6 +149,7 @@ struct iavf_info {
struct iavf_parser_list dist_parser_list;
 
struct iavf_fdir_info fdir; /* flow director info */
+   struct virtchnl_vlan_caps *vlan_cap;
 };
 
 #define IAVF_MAX_PKT_TYPE 1024
@@ -279,4 +280,8 @@ int iavf_add_del_rss_cfg(struct iavf_adapter *adapter,
 int iavf_add_del_mc_addr_list(struct iavf_adapter *adapter,
struct rte_ether_addr *mc_addrs,
uint32_t mc_addrs_num, bool add);
+int iavf_get_vlan_offload_capa(struct rte_eth_dev *dev);
+int iavf_add_del_vlan_v2(struct iavf_adapter *adapter, uint16_t vlanid,
+bool add, bool qinq);
+int iavf_switch_vlan_strip(struct iavf_adapter *adapter, bool qinq, bool on);
 #endif /* _IAVF_ETHDEV_H_ */
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index 28ca3fa8f..af9698009 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -807,14 +807,22 @@ iavf_dev_vlan_filter_set(struct rte_eth_dev *dev, 
uint16_t vlan_id, int on)
struct iavf_adapter *adapter =
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(adapter);
+   int qinq = dev->data->dev_conf.rxmode.offloads &
+  DEV_RX_OFFLOAD_VLAN_EXTEND;
int err;
 
-   if (!(vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN))
-   return -ENOTSUP;
+   if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN_V2) {
+   err = iavf_add_del_vlan_v2(adapter, vlan_id, on, qinq);
+   if (err)
+   return -EIO;
+   return 0;
+   }
 
-   err = iavf_add_del_vlan(adapter, vlan_id, on);
-   if (err)
-   return -EIO;
+   if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN) {
+   err = iavf_add_del_vlan(adapter, vlan_id, on);
+   if (err)
+   return -EIO;
+   }
return 0;
 }
 
@@ -825,22 +833,48 @@ iavf_dev_vlan_offload_set(struct rte_eth_dev *dev, int 
mask)
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(adapter);
struct rte_eth_conf *dev_conf = &dev->data->dev_conf;
+   int qinq = dev->data->dev_conf.rxmode.offloads &
+  DEV_RX_OFFLOAD_VLAN_EXTEND;
+   bool on;
int err;
 
-   if (!(vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN))
-   return -ENOTSUP;
-
-   /* Vlan stripping setting */
-   if (mask & ETH_VLAN_STRIP_MASK) {
-   /* Enable or disable VLAN stripping */
-   if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_VLAN_STRIP)
-   err = iavf_enable_vlan_strip(adapter);
-   else
-   err = iavf_disable_vlan_strip(adapter);
+   if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN_V2) {
+   /* Double vlan stripping setting */
+   if (mask & ETH_QINQ_STRIP_MASK) {
+   /* Enable or disable inner VLAN stripping */
+   on = dev_conf->rxmode.offloads &
+DEV_RX_OFFLOAD_QINQ_STRIP;
+   err = iavf_switch_vlan_strip(adapter, qinq, on);
+   if (err)
+   return -EIO;
+   }
+   /* Single vlan stripping setting */
+   if (mask & ETH_VLAN_STRIP_MASK) {
+   /* Enable or disable VLAN stripping */
+   on = dev_conf->rxmode.offloads &
+DEV_RX_OFFLOAD_VLAN_STRIP;
+   err = iavf_switch_vlan_strip(adapter, qinq, on);
+   if (err)
+   return -EIO;
+   }
+   return 0;
+   }
 
-   if (err)
-   return -EIO;
+   if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN) {
+   /* Vlan stripping setting */
+   if (mask & ETH_VLAN_STRIP_MASK) {
+   /* Enable or disable VLAN stripping */
+   if (dev_conf->rxmode.offloads &
+   DEV_RX_OFFLOAD_VLAN_STRIP)
+   err = iavf_enable_vlan_strip(adapter);
+   else
+   

Re: [dpdk-dev] [PATCH] net/ixgbe: fix fdir flows with RTE_FLOW_ITEM_TYPE_RAW

[Pawel Wodkowski]

On 31.08.2020 05:46, Zhang, Qi Z wrote:



-Original Message-
From: Pawel Wodkowski 
Sent: Tuesday, August 11, 2020 4:31 AM
To: dev@dpdk.org
Cc: Pawel Wodkowski ; Zhang, Qi Z
; Zhao1, Wei ; Guo, Jia

Subject: [PATCH] net/ixgbe: fix fdir flows with RTE_FLOW_ITEM_TYPE_RAW

Flows like IP4 / UDP / RAW are not working because after parsing
RTE_FLOW_ITEM_TYPE_RAW item pointer is not advanced. This make whole
parsing fail.

Fixes: f35fec63dde1 ("net/ixgbe: enable flex bytes for generic flow API")
Cc: qi.z.zh...@intel.com
Signed-off-by: Pawel Wodkowski 
---
  drivers/net/ixgbe/ixgbe_flow.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
index b2a2bfc02..a2cb599b1 100644
--- a/drivers/net/ixgbe/ixgbe_flow.c
+++ b/drivers/net/ixgbe/ixgbe_flow.c
@@ -2251,6 +2251,8 @@ ixgbe_parse_fdir_filter_normal(struct rte_eth_dev
*dev,
(((uint16_t)raw_spec->pattern[1]) << 8) |
raw_spec->pattern[0];
rule->flex_bytes_offset = raw_spec->offset;
+
+   item = next_no_fuzzy_pattern(pattern, item);

why we need to advance item pointer?
The next branch will advance it and compare with RTe_FLOW_ITEM_TYPE_END.
Can you double check if your pattern is IPv4/UDP/RAW/END ?


True, pls ignore this patch.




}

if (item->type != RTE_FLOW_ITEM_TYPE_END) {
--
2.17.1

[dpdk-dev] [PATCH v1 3/4] sched: add dynamic config of subport bandwidth profile

[Savinay Dharmappa]

This patch add public APIs to add new subport profile
and to configure them.

Signed-off-by: Savinay Dharmappa 
Signed-off-by: Jasvinder Singh 
---
 lib/librte_sched/rte_sched.c | 115 ++-
 lib/librte_sched/rte_sched.h |  45 +
 2 files changed, 158 insertions(+), 2 deletions(-)

diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index c1846d0..770c8bd 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -1212,8 +1212,8 @@ rte_sched_subport_config(struct rte_sched_port *port,
s->bmp = rte_bitmap_init(n_subport_pipe_queues, s->bmp_array,
bmp_mem_size);
if (s->bmp == NULL) {
-   RTE_LOG(ERR, SCHED,
-   "%s: Subport bitmap init error\n", __func__);
+   RTE_LOG(ERR, SCHED, "%s: "
+   "Subport bitmap init error\n", __func__);
 
rte_sched_free_memory(port, n_subports);
return -EINVAL;
@@ -1235,6 +1235,52 @@ rte_sched_subport_config(struct rte_sched_port *port,
return 0;
 }
 
+int
+rte_sched_subport_profile_config(struct rte_sched_port *port,
+   uint32_t subport_id,
+   uint32_t profile_id)
+{
+   int i;
+   struct rte_sched_subport_profile *params;
+   uint32_t n_subports = subport_id + 1;
+   struct rte_sched_subport *s;
+
+   if (port == NULL) {
+   RTE_LOG(ERR, SCHED, "%s: "
+   "Incorrect value for parameter port\n", __func__);
+   return -EINVAL;
+   }
+
+   if (subport_id >= port->n_subports_per_port) {
+   RTE_LOG(ERR, SCHED, "%s: "
+   "Incorrect value for parameter subport id\n", __func__);
+
+   rte_sched_free_memory(port, n_subports);
+   return -EINVAL;
+   }
+
+   params =  port->subport_profiles + profile_id;
+
+   s = port->subports[subport_id];
+
+   s->tb_credits = params->tb_size / 2;
+
+   s->tc_time = port->time + params->tc_period;
+
+   for (i = 0; i < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; i++)
+   if (s->qsize[i])
+   s->tc_credits[i] = params->tc_credits_per_period[i];
+   else
+   params->tc_credits_per_period[i] = 0;
+
+#ifdef RTE_SCHED_SUBPORT_TC_OV
+   s->tc_ov_wm_max = rte_sched_time_ms_to_bytes(params->tc_period,
+s->pipe_tc_be_rate_max);
+#endif
+   s->profile = profile_id;
+
+   rte_sched_port_log_subport_profile(port, profile_id);
+
return 0;
 }
 
@@ -1422,6 +1468,71 @@ rte_sched_subport_pipe_profile_add(struct rte_sched_port 
*port,
return 0;
 }
 
+int
+rte_sched_port_subport_profile_add(struct rte_sched_port *port,
+   struct rte_sched_subport_profile_params *params,
+   uint32_t *subport_profile_id)
+{
+   int status;
+   uint32_t i;
+   struct rte_sched_subport_profile *dst;
+
+   /* Port */
+   if (port == NULL) {
+   RTE_LOG(ERR, SCHED, "%s: "
+   "Incorrect value for parameter port\n", __func__);
+   return -EINVAL;
+   }
+
+   if (params == NULL) {
+   RTE_LOG(ERR, SCHED, "%s: "
+   "Incorrect value for parameter profile\n", __func__);
+   return -EINVAL;
+   }
+
+   if (subport_profile_id == NULL) {
+   RTE_LOG(ERR, SCHED, "%s: "
+   "Incorrect value for parametersubport_profile_id\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   dst = port->subport_profiles + port->n_subport_profiles;
+
+   /* Subport profiles exceeds the max limit */
+   if (port->n_subport_profiles >= port->n_max_subport_profiles) {
+   RTE_LOG(ERR, SCHED, "%s: "
+   "Number of subport profiles exceeds the max limit", __func__);
+   return -EINVAL;
+   }
+
+   status = subport_profile_check(params, port->rate);
+   if (status != 0) {
+   RTE_LOG(ERR, SCHED, "%s: "
+   "subport profile check failed(%d)\n", __func__, status);
+   return -EINVAL;
+   }
+
+   rte_sched_subport_profile_convert(params, dst, port->rate);
+
+   /* Subport profile should not exists */
+   for (i = 0; i < port->n_subport_profiles; i++)
+   if (memcmp(port->subport_profiles + i,
+   params, sizeof(*params)) == 0) {
+   RTE_LOG(ERR, SCHED,
+   "%s: subport profile exists\n", __func__);
+   return -EINVAL;
+   }
+
+   /* Subport profile commit */
+   *subport_profile_id = port->n_subport_profiles;
+   port->n_subport_profiles++;
+
+   rte_sched_port_log_subport_profile(port, *subport_profile_id);
+
+   return 0;
+}
+
 static inline uint32_t
 rte_sched_port_qindex(struct rte_sched_port *port,
uint32_t subp

[dpdk-dev] [PATCH v1 2/4] sched: add dynamic config of subport bandwidth profile

[Savinay Dharmappa]

This patch builds the subport profile table during port
configuration. Since the tb_period,tb_size,tc_period,
tb_credits_per_period and tc_credits_per_period are updated
in subport profile table, references to them are removed
from subport configuration.

Signed-off-by: Savinay Dharmappa 
Signed-off-by: Jasvinder Singh 
---
 lib/librte_sched/rte_sched.c | 154 +--
 1 file changed, 47 insertions(+), 107 deletions(-)

diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index c82e09c..c1846d0 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -438,6 +438,8 @@ subport_profile_check(struct 
rte_sched_subport_profile_params *params,
 static int
 rte_sched_port_check_params(struct rte_sched_port_params *params)
 {
+   uint32_t i;
+
if (params == NULL) {
RTE_LOG(ERR, SCHED,
"%s: Incorrect value for parameter params\n", __func__);
@@ -474,6 +476,29 @@ rte_sched_port_check_params(struct rte_sched_port_params 
*params)
return -EINVAL;
}
 
+   if (params->subport_profiles == NULL ||
+   params->n_subport_profiles == 0 ||
+   params->n_max_subport_profiles == 0 ||
+   params->n_subport_profiles > params->n_max_subport_profiles) {
+   RTE_LOG(ERR, SCHED,
+   "%s: Incorrect value for subport profiles\n", __func__);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < params->n_subport_profiles; i++) {
+   struct rte_sched_subport_profile_params *p =
+   params->subport_profiles + i;
+   int status;
+
+   status = subport_profile_check(p, params->rate);
+   if (status != 0) {
+   RTE_LOG(ERR, SCHED,
+   "%s: subport profile check failed(%d)\n",
+   __func__, status);
+   return -EINVAL;
+   }
+   }
+
/* n_pipes_per_subport: non-zero, power of 2 */
if (params->n_pipes_per_subport == 0 ||
!rte_is_power_of_2(params->n_pipes_per_subport)) {
@@ -807,18 +832,6 @@ rte_sched_subport_check_params(struct 
rte_sched_subport_params *params,
return -EINVAL;
}
 
-   if (params->tb_rate == 0 || params->tb_rate > rate) {
-   RTE_LOG(ERR, SCHED,
-   "%s: Incorrect value for tb rate\n", __func__);
-   return -EINVAL;
-   }
-
-   if (params->tb_size == 0) {
-   RTE_LOG(ERR, SCHED,
-   "%s: Incorrect value for tb size\n", __func__);
-   return -EINVAL;
-   }
-
/* qsize: if non-zero, power of 2,
 * no bigger than 32K (due to 16-bit read/write pointers)
 */
@@ -832,32 +845,12 @@ rte_sched_subport_check_params(struct 
rte_sched_subport_params *params,
}
}
 
-   for (i = 0; i < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; i++) {
-   uint64_t tc_rate = params->tc_rate[i];
-   uint16_t qsize = params->qsize[i];
-
-   if ((qsize == 0 && tc_rate != 0) ||
-   (qsize != 0 && tc_rate == 0) ||
-   (tc_rate > params->tb_rate)) {
-   RTE_LOG(ERR, SCHED,
-   "%s: Incorrect value for tc rate\n", __func__);
-   return -EINVAL;
-   }
-   }
-
-   if (params->qsize[RTE_SCHED_TRAFFIC_CLASS_BE] == 0 ||
-   params->tc_rate[RTE_SCHED_TRAFFIC_CLASS_BE] == 0) {
+   if (params->qsize[RTE_SCHED_TRAFFIC_CLASS_BE] == 0) {
RTE_LOG(ERR, SCHED,
"%s: Incorrect qsize or tc rate(best effort)\n", 
__func__);
return -EINVAL;
}
 
-   if (params->tc_period == 0) {
-   RTE_LOG(ERR, SCHED,
-   "%s: Incorrect value for tc period\n", __func__);
-   return -EINVAL;
-   }
-
/* n_pipes_per_subport: non-zero, power of 2 */
if (params->n_pipes_per_subport_enabled == 0 ||
params->n_pipes_per_subport_enabled > n_max_pipes_per_subport ||
@@ -939,7 +932,7 @@ struct rte_sched_port *
 rte_sched_port_config(struct rte_sched_port_params *params)
 {
struct rte_sched_port *port = NULL;
-   uint32_t size0, size1;
+   uint32_t size0, size1, size2;
uint32_t cycles_per_byte;
uint32_t i, j;
int status;
@@ -954,10 +947,21 @@ rte_sched_port_config(struct rte_sched_port_params 
*params)
 
size0 = sizeof(struct rte_sched_port);
size1 = params->n_subports_per_port * sizeof(struct rte_sched_subport 
*);
+   size2 = params->n_max_subport_profiles *
+   sizeof(struct rte_sched_subport_profile);
 
/* Allocate memory to store the data structures */
-   port = rte_zmalloc_socket("qos_params",

[dpdk-dev] [PATCH v1 4/4] sched: add dynamic config of subport bandwidth profile

[Savinay Dharmappa]

This patch modifies the way credits are updated. Credits
are updated by fetching parameters from subport profile
table.

Signed-off-by: Savinay Dharmappa 
Signed-off-by: Jasvinder Singh 
---
 lib/librte_sched/rte_sched.c   | 62 ++
 lib/librte_sched/rte_sched_version.map |  2 ++
 2 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 770c8bd..cfbcf5c 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -124,6 +124,7 @@ struct rte_sched_grinder {
uint32_t productive;
uint32_t pindex;
struct rte_sched_subport *subport;
+   struct rte_sched_subport_profile *subport_params;
struct rte_sched_pipe *pipe;
struct rte_sched_pipe_profile *pipe_params;
 
@@ -1291,6 +1292,7 @@ rte_sched_pipe_config(struct rte_sched_port *port,
int32_t pipe_profile)
 {
struct rte_sched_subport *s;
+   struct rte_sched_subport_profile *sp;
struct rte_sched_pipe *p;
struct rte_sched_pipe_profile *params;
uint32_t n_subports = subport_id + 1;
@@ -1331,14 +1333,16 @@ rte_sched_pipe_config(struct rte_sched_port *port,
return -EINVAL;
}
 
+   sp = port->subport_profiles + s->profile;
+
/* Handle the case when pipe already has a valid configuration */
p = s->pipe + pipe_id;
if (p->tb_time) {
params = s->pipe_profiles + p->profile;
 
double subport_tc_be_rate =
-   (double) 
s->tc_credits_per_period[RTE_SCHED_TRAFFIC_CLASS_BE]
-   / (double) s->tc_period;
+   (double) sp->tc_credits_per_period[RTE_SCHED_TRAFFIC_CLASS_BE]
+   / (double) sp->tc_period;
double pipe_tc_be_rate =
(double) 
params->tc_credits_per_period[RTE_SCHED_TRAFFIC_CLASS_BE]
/ (double) params->tc_period;
@@ -1380,8 +1384,8 @@ rte_sched_pipe_config(struct rte_sched_port *port,
{
/* Subport best effort tc oversubscription */
double subport_tc_be_rate =
-   (double) 
s->tc_credits_per_period[RTE_SCHED_TRAFFIC_CLASS_BE]
-   / (double) s->tc_period;
+   (double) sp->tc_credits_per_period[RTE_SCHED_TRAFFIC_CLASS_BE]
+   / (double) sp->tc_period;
double pipe_tc_be_rate =
(double) 
params->tc_credits_per_period[RTE_SCHED_TRAFFIC_CLASS_BE]
/ (double) params->tc_period;
@@ -1393,8 +1397,9 @@ rte_sched_pipe_config(struct rte_sched_port *port,
 
if (s->tc_ov != tc_be_ov) {
RTE_LOG(DEBUG, SCHED,
-   "Subport %u Best effort TC oversubscription is 
ON (%.4lf < %.4lf)\n",
-   subport_id, subport_tc_be_rate, s->tc_ov_rate);
+   "Subport %u Best effort TC oversubscription is ON "
+   "(%.4lf < %.4lf)\n",
+   subport_id, subport_tc_be_rate, s->tc_ov_rate);
}
p->tc_ov_period_id = s->tc_ov_period_id;
p->tc_ov_credits = s->tc_ov_wm;
@@ -2168,14 +2173,18 @@ grinder_credits_update(struct rte_sched_port *port,
struct rte_sched_grinder *grinder = subport->grinder + pos;
struct rte_sched_pipe *pipe = grinder->pipe;
struct rte_sched_pipe_profile *params = grinder->pipe_params;
+   struct rte_sched_subport_profile *subport_params =
+   grinder->subport_params;
uint64_t n_periods;
uint32_t i;
 
/* Subport TB */
-   n_periods = (port->time - subport->tb_time) / subport->tb_period;
-   subport->tb_credits += n_periods * subport->tb_credits_per_period;
-   subport->tb_credits = RTE_MIN(subport->tb_credits, subport->tb_size);
-   subport->tb_time += n_periods * subport->tb_period;
+   n_periods = (port->time - subport->tb_time) / subport_params->tb_period;
+   subport->tb_credits += n_periods *
+  subport_params->tb_credits_per_period;
+   subport->tb_credits = RTE_MIN(subport->tb_credits,
+ subport_params->tb_size);
+   subport->tb_time += n_periods * subport_params->tb_period;
 
/* Pipe TB */
n_periods = (port->time - pipe->tb_time) / params->tb_period;
@@ -2186,9 +2195,10 @@ grinder_credits_update(struct rte_sched_port *port,
/* Subport TCs */
if (unlikely(port->time >= subport->tc_time)) {
for (i = 0; i < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; i++)
-   subport->tc_credits[i] = 
subport->tc_credits_per_period[i];
+   subport->tc_credits[i] =
+   subport_params->tc_credits_per_period[i];
 
-

[dpdk-dev] [PATCH v1 1/4] sched: add dynamic config of subport bandwidth profile

[Savinay Dharmappa]

This patch modifies the subport level data structures
and add internal functions to create subport profile
table.

Signed-off-by: Savinay Dharmappa 
Signed-off-by: Jasvinder Singh 
---
 lib/librte_sched/rte_sched.c | 173 +++
 lib/librte_sched/rte_sched.h |  37 ++---
 2 files changed, 185 insertions(+), 25 deletions(-)

diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index c0983dd..c82e09c 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -2,6 +2,7 @@
  * Copyright(c) 2010-2014 Intel Corporation
  */
 
+#include 
 #include 
 #include 
 
@@ -101,6 +102,16 @@ enum grinder_state {
e_GRINDER_READ_MBUF
 };
 
+struct rte_sched_subport_profile {
+   /* Token bucket (TB) */
+   uint64_t tb_period;
+   uint64_t tb_credits_per_period;
+   uint64_t tb_size;
+
+   uint64_t tc_credits_per_period[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
+   uint64_t tc_period;
+};
+
 struct rte_sched_grinder {
/* Pipe cache */
uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
@@ -139,18 +150,13 @@ struct rte_sched_grinder {
 };
 
 struct rte_sched_subport {
-   /* Token bucket (TB) */
+
uint64_t tb_time; /* time of last update */
-   uint64_t tb_period;
-   uint64_t tb_credits_per_period;
-   uint64_t tb_size;
uint64_t tb_credits;
 
/* Traffic classes (TCs) */
uint64_t tc_time; /* time of next update */
-   uint64_t tc_credits_per_period[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
uint64_t tc_credits[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
-   uint64_t tc_period;
 
/* TC oversubscription */
uint64_t tc_ov_wm;
@@ -164,6 +170,8 @@ struct rte_sched_subport {
/* Statistics */
struct rte_sched_subport_stats stats __rte_cache_aligned;
 
+   /* subport profile flag */
+   uint32_t profile;
/* Subport pipes */
uint32_t n_pipes_per_subport_enabled;
uint32_t n_pipe_profiles;
@@ -212,6 +220,8 @@ struct rte_sched_port {
uint16_t pipe_queue[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
uint8_t pipe_tc[RTE_SCHED_QUEUES_PER_PIPE];
uint8_t tc_queue[RTE_SCHED_QUEUES_PER_PIPE];
+   uint32_t n_subport_profiles;
+   uint32_t n_max_subport_profiles;
uint64_t rate;
uint32_t mtu;
uint32_t frame_overhead;
@@ -229,6 +239,7 @@ struct rte_sched_port {
uint32_t subport_id;
 
/* Large data structures */
+   struct rte_sched_subport_profile *subport_profiles;
struct rte_sched_subport *subports[0] __rte_cache_aligned;
 } __rte_cache_aligned;
 
@@ -375,6 +386,56 @@ pipe_profile_check(struct rte_sched_pipe_params *params,
 }
 
 static int
+subport_profile_check(struct rte_sched_subport_profile_params *params,
+   uint64_t rate)
+{
+   uint32_t i;
+
+   /* Check user parameters */
+   if (params == NULL) {
+   RTE_LOG(ERR, SCHED,
+   "%s: Incorrect value for parameter params\n", __func__);
+   return -EINVAL;
+   }
+
+   if (params->tb_rate == 0 || params->tb_rate > rate) {
+   RTE_LOG(ERR, SCHED,
+   "%s: Incorrect value for tb rate\n", __func__);
+   return -EINVAL;
+   }
+
+   if (params->tb_size == 0) {
+   RTE_LOG(ERR, SCHED,
+   "%s: Incorrect value for tb size\n", __func__);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; i++) {
+   uint64_t tc_rate = params->tc_rate[i];
+
+   if (tc_rate == 0 || (tc_rate > params->tb_rate)) {
+   RTE_LOG(ERR, SCHED,
+   "%s: Incorrect value for tc rate\n", __func__);
+   return -EINVAL;
+   }
+   }
+
+   if (params->tc_rate[RTE_SCHED_TRAFFIC_CLASS_BE] == 0) {
+   RTE_LOG(ERR, SCHED,
+   "%s: Incorrect tc rate(best effort)\n", __func__);
+   return -EINVAL;
+   }
+
+   if (params->tc_period == 0) {
+   RTE_LOG(ERR, SCHED,
+   "%s: Incorrect value for tc period\n", __func__);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int
 rte_sched_port_check_params(struct rte_sched_port_params *params)
 {
if (params == NULL) {
@@ -517,13 +578,14 @@ rte_sched_port_log_pipe_profile(struct rte_sched_subport 
*subport, uint32_t i)
struct rte_sched_pipe_profile *p = subport->pipe_profiles + i;
 
RTE_LOG(DEBUG, SCHED, "Low level config for pipe profile %u:\n"
-   "   Token bucket: period = %"PRIu64", credits per period = 
%"PRIu64", size = %"PRIu64"\n"
-   "   Traffic classes: period = %"PRIu64",\n"
-   "   credits per period = [%"PRIu64", %"PRIu64", %"PRIu64", 
%"PRIu64
-   ", %"PRIu64", %"PRIu64", %"PRIu64"

[dpdk-dev] [PATCH v1 2/4] example/ip_pipeline: subport bandwidth dynmaic conf

[Savinay Dharmappa]

ip_pipeline application uses the new apis introduced as part of dynamic
configuration of subport bandwidth to configure the deafult subport
bandwidth profile while buidling the hirerachical scheduler

Signed-off-by: Savinay Dharmappa 
---
 examples/ip_pipeline/cli.c  | 10 ++
 examples/ip_pipeline/tmgr.c | 28 +---
 examples/ip_pipeline/tmgr.h |  3 ++-
 3 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/examples/ip_pipeline/cli.c b/examples/ip_pipeline/cli.c
index d79699e..e192275 100644
--- a/examples/ip_pipeline/cli.c
+++ b/examples/ip_pipeline/cli.c
@@ -406,7 +406,8 @@ cmd_tmgr_subport_profile(char **tokens,
char *out,
size_t out_size)
 {
-   struct rte_sched_subport_params p;
+   struct rte_sched_subport_params params;
+   struct rte_sched_subport_profile_params p;
int status, i;
 
if (n_tokens != 35) {
@@ -440,7 +441,8 @@ cmd_tmgr_subport_profile(char **tokens,
return;
}
 
-   if (parser_read_uint32(&p.n_pipes_per_subport_enabled, tokens[20]) != 
0) {
+   if (parser_read_uint32(¶ms.n_pipes_per_subport_enabled,
+   tokens[20]) != 0) {
snprintf(out, out_size, MSG_ARG_INVALID, "n_pipes_per_subport");
return;
}
@@ -451,12 +453,12 @@ cmd_tmgr_subport_profile(char **tokens,
}
 
for (i = 0; i < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; i++)
-   if (parser_read_uint16(&p.qsize[i], tokens[22 + i]) != 0) {
+   if (parser_read_uint16(¶ms.qsize[i], tokens[22 + i]) != 0) {
snprintf(out, out_size, MSG_ARG_INVALID, "qsize");
return;
}
 
-   status = tmgr_subport_profile_add(&p);
+   status = tmgr_subport_profile_add(&p, ¶ms);
if (status != 0) {
snprintf(out, out_size, MSG_CMD_FAIL, tokens[0]);
return;
diff --git a/examples/ip_pipeline/tmgr.c b/examples/ip_pipeline/tmgr.c
index 91ccbf6..c609102 100644
--- a/examples/ip_pipeline/tmgr.c
+++ b/examples/ip_pipeline/tmgr.c
@@ -11,6 +11,9 @@
 static struct rte_sched_subport_params
subport_profile[TMGR_SUBPORT_PROFILE_MAX];
 
+static struct rte_sched_subport_profile_params
+   profile_params[TMGR_SUBPORT_PROFILE_MAX];
+
 static uint32_t n_subport_profiles;
 
 static struct rte_sched_pipe_params
@@ -44,15 +47,20 @@ tmgr_port_find(const char *name)
 }
 
 int
-tmgr_subport_profile_add(struct rte_sched_subport_params *p)
+tmgr_subport_profile_add(struct rte_sched_subport_profile_params *p,
+struct rte_sched_subport_params *params)
 {
/* Check input params */
-   if (p == NULL ||
-   p->n_pipes_per_subport_enabled == 0)
+   if (p == NULL || params == NULL ||
+   params->n_pipes_per_subport_enabled == 0)
return -1;
 
/* Save profile */
memcpy(&subport_profile[n_subport_profiles],
+   params,
+   sizeof(*params));
+
+   memcpy(&profile_params[n_subport_profiles],
p,
sizeof(*p));
 
@@ -103,6 +111,9 @@ tmgr_port_create(const char *name, struct tmgr_port_params 
*params)
p.mtu = params->mtu;
p.frame_overhead = params->frame_overhead;
p.n_subports_per_port = params->n_subports_per_port;
+   p.n_subport_profiles = n_subport_profiles;
+   p.subport_profiles = profile_params;
+   p.n_max_subport_profiles = TMGR_SUBPORT_PROFILE_MAX;
p.n_pipes_per_subport = TMGR_PIPE_SUBPORT_MAX;
 
s = rte_sched_port_config(&p);
@@ -126,6 +137,13 @@ tmgr_port_create(const char *name, struct tmgr_port_params 
*params)
return NULL;
}
 
+   status = rte_sched_subport_profile_config(s, i, 0);
+
+   if (status) {
+   rte_sched_port_free(s);
+   return NULL;
+   }
+
for (j = 0; j < subport_profile[0].n_pipes_per_subport_enabled; 
j++) {
status = rte_sched_pipe_config(
s,
@@ -182,6 +200,10 @@ tmgr_subport_config(const char *port_name,
subport_id,
&subport_profile[subport_profile_id]);
 
+   if (!status)
+   status = rte_sched_subport_profile_config(port->s, subport_id,
+   subport_profile_id);
+
return status;
 }
 
diff --git a/examples/ip_pipeline/tmgr.h b/examples/ip_pipeline/tmgr.h
index ee50cf7..b19fb23 100644
--- a/examples/ip_pipeline/tmgr.h
+++ b/examples/ip_pipeline/tmgr.h
@@ -48,7 +48,8 @@ struct tmgr_port_params {
 };
 
 int
-tmgr_subport_profile_add(struct rte_sched_subport_params *p);
+tmgr_subport_profile_add(struct rte_sched_subport_profile_params *p,
+struct rte_sched_subport_params *params);
 
 int
 tmgr_pipe_profile_add(struct rte_sched_pipe_params

[dpdk-dev] [PATCH v1 4/4] app/test_sched: subport bandwidth profile config

[Savinay Dharmappa]

test_sched application uses the new apis introduced as part of dynamic
configuration of subport bandwidth to configure the deafult subport
bandwidth profile while buidling the hirerachical scheduler

Signed-off-by: Savinay Dharmappa 
---
 app/test/test_sched.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/app/test/test_sched.c b/app/test/test_sched.c
index fc31080..99d7f87 100644
--- a/app/test/test_sched.c
+++ b/app/test/test_sched.c
@@ -36,15 +36,20 @@ static struct rte_sched_pipe_params pipe_profile[] = {
},
 };
 
-static struct rte_sched_subport_params subport_param[] = {
+static struct rte_sched_subport_profile_params
+   subport_profile[] = {
{
.tb_rate = 125000,
.tb_size = 100,
-
.tc_rate = {125000, 125000, 125000, 125000,
125000, 125000, 125000, 125000, 
125000,
125000, 125000, 125000, 125000},
.tc_period = 10,
+   },
+};
+
+static struct rte_sched_subport_params subport_param[] = {
+   {
.n_pipes_per_subport_enabled = 1024,
.qsize = {32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32},
.pipe_profiles = pipe_profile,
@@ -59,6 +64,8 @@ static struct rte_sched_port_params port_param = {
.mtu = 1522,
.frame_overhead = RTE_SCHED_FRAME_OVERHEAD_DEFAULT,
.n_subports_per_port = 1,
+   .n_subport_profiles = 1,
+   .subport_profiles = subport_profile,
.n_pipes_per_subport = 1024,
 };
 
@@ -66,6 +73,7 @@ static struct rte_sched_port_params port_param = {
 #define MBUF_DATA_SZ (2048 + RTE_PKTMBUF_HEADROOM)
 #define MEMPOOL_CACHE_SZ 0
 #define SOCKET   0
+#define DEFAULT_PROFILE  0
 
 
 static struct rte_mempool *
@@ -141,6 +149,10 @@ test_sched(void)
err = rte_sched_subport_config(port, SUBPORT, subport_param);
TEST_ASSERT_SUCCESS(err, "Error config sched, err=%d\n", err);
 
+   err = rte_sched_subport_profile_config(port, SUBPORT,
+   DEFAULT_PROFILE);
+   TEST_ASSERT_SUCCESS(err, "Error config sched, err=%d\n", err);
+
for (pipe = 0; pipe < subport_param[0].n_pipes_per_subport_enabled; 
pipe++) {
err = rte_sched_pipe_config(port, SUBPORT, pipe, 0);
TEST_ASSERT_SUCCESS(err, "Error config sched pipe %u, 
err=%d\n", pipe, err);
-- 
2.7.4

[dpdk-dev] [PATCH v1 3/4] drivers/softnic: subport bandwidth profile config

[Savinay Dharmappa]

softnic driver uses the new apis introduced as part of dynamic
configuration of subport bandwidth to configure the deafult subport
bandwidth profile while buidling the hirerachical scheduler.

Signed-off-by: Savinay Dharmappa 
---
 drivers/net/softnic/rte_eth_softnic_internals.h |   9 +
 drivers/net/softnic/rte_eth_softnic_tm.c| 222 +++-
 2 files changed, 186 insertions(+), 45 deletions(-)

diff --git a/drivers/net/softnic/rte_eth_softnic_internals.h 
b/drivers/net/softnic/rte_eth_softnic_internals.h
index 6eec43b..cc50037 100644
--- a/drivers/net/softnic/rte_eth_softnic_internals.h
+++ b/drivers/net/softnic/rte_eth_softnic_internals.h
@@ -164,10 +164,19 @@ TAILQ_HEAD(softnic_link_list, softnic_link);
 #ifndef TM_MAX_PIPE_PROFILE
 #define TM_MAX_PIPE_PROFILE256
 #endif
+
+#ifndef TM_MAX_SUBPORT_PROFILE
+#define TM_MAX_SUBPORT_PROFILE 256
+#endif
+
 struct tm_params {
struct rte_sched_port_params port_params;
 
struct rte_sched_subport_params subport_params[TM_MAX_SUBPORTS];
+   struct rte_sched_subport_profile_params
+   subport_profiles[TM_MAX_SUBPORT_PROFILE];
+   uint32_t n_subport_profiles;
+   uint32_t subport_to_profile[TM_MAX_SUBPORT_PROFILE];
 
struct rte_sched_pipe_params pipe_profiles[TM_MAX_PIPE_PROFILE];
uint32_t n_pipe_profiles;
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c 
b/drivers/net/softnic/rte_eth_softnic_tm.c
index 80a470c..881f025 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -98,6 +98,13 @@ softnic_tmgr_port_create(struct pmd_internals *p,
return NULL;
}
 
+   status = rte_sched_subport_profile_config(sched,
+   subport_id, t->subport_to_profile[subport_id]);
+   if (status) {
+   rte_sched_port_free(sched);
+   return NULL;
+   }
+
/* Pipe */
for (pipe_id = 0; pipe_id < n_pipes_per_subport; pipe_id++) {
int pos = subport_id * TM_MAX_PIPES_PER_SUBPORT + 
pipe_id;
@@ -1043,6 +1050,25 @@ tm_shared_shaper_get_tc(struct rte_eth_dev *dev,
 }
 
 static int
+subport_profile_exists(struct rte_eth_dev *dev,
+   struct rte_sched_subport_profile_params *sp,
+   uint32_t *subport_profile_id)
+{
+   struct pmd_internals *p = dev->data->dev_private;
+   struct tm_params *t = &p->soft.tm.params;
+   uint32_t i;
+
+   for (i = 0; i < t->n_subport_profiles; i++)
+   if (memcmp(&t->subport_profiles[i], sp, sizeof(*sp)) == 0) {
+   if (subport_profile_id)
+   *subport_profile_id = i;
+   return 1;
+   }
+
+   return 0;
+}
+
+static int
 update_subport_tc_rate(struct rte_eth_dev *dev,
struct tm_node *nt,
struct tm_shared_shaper *ss,
@@ -1050,26 +1076,27 @@ update_subport_tc_rate(struct rte_eth_dev *dev,
 {
struct pmd_internals *p = dev->data->dev_private;
uint32_t tc_id = tm_node_tc_id(dev, nt);
-
struct tm_node *np = nt->parent_node;
-
struct tm_node *ns = np->parent_node;
uint32_t subport_id = tm_node_subport_id(dev, ns);
-
-   struct rte_sched_subport_params subport_params;
-
+   struct rte_sched_subport_profile_params subport_profile;
struct tm_shaper_profile *sp_old = tm_shaper_profile_search(dev,
ss->shaper_profile_id);
+   uint32_t subport_profile_id;
 
/* Derive new subport configuration. */
-   memcpy(&subport_params,
-   &p->soft.tm.params.subport_params[subport_id],
-   sizeof(subport_params));
-   subport_params.tc_rate[tc_id] = sp_new->params.peak.rate;
+   memcpy(&subport_profile,
+   &p->soft.tm.params.subport_profiles[subport_id],
+   sizeof(subport_profile));
+   subport_profile.tc_rate[tc_id] = sp_new->params.peak.rate;
+
+   if (subport_profile_exists(dev, &subport_profile,
+ &subport_profile_id) == 0)
+   return -1;
 
/* Update the subport configuration. */
-   if (rte_sched_subport_config(SCHED(p),
-   subport_id, &subport_params))
+   if (rte_sched_subport_profile_config(SCHED(p),
+   subport_id, subport_profile_id))
return -1;
 
/* Commit changes. */
@@ -1078,9 +1105,9 @@ update_subport_tc_rate(struct rte_eth_dev *dev,
ss->shaper_profile_id = sp_new->shaper_profile_id;
sp_new->n_users++;
 
-   memcpy(&p->soft.tm.params.subport_params[subport_id],
-   &subport_params,
-   sizeof(subport_params));
+   memcpy(&p->soft.tm.params.subport_profiles[subport_id],
+   &subport_profile,
+   sizeof(subport_profile));
 
retu

[dpdk-dev] [PATCH v1 1/4] example/qos_sched: subport bandwidth dynmaic conf

[Savinay Dharmappa]

qos sched application uses the new apis introduced as part of dynamic
configuration of subport bandwidth to configure the deafult subport
bandwidth profile while buidling the hirerachical scheduler.

Signed-off-by: Savinay Dharmappa 
---
 examples/qos_sched/cfg_file.c  | 158 -
 examples/qos_sched/cfg_file.h  |   4 ++
 examples/qos_sched/init.c  |  24 +--
 examples/qos_sched/main.h  |   1 +
 examples/qos_sched/profile.cfg |   3 +
 5 files changed, 120 insertions(+), 70 deletions(-)

diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c
index f078e4f..9e1341c 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -53,8 +53,11 @@ cfg_load_pipe(struct rte_cfgfile *cfg, struct 
rte_sched_pipe_params *pipe_params
if (!cfg || !pipe_params)
return -1;
 
-   profiles = rte_cfgfile_num_sections(cfg, "pipe profile", sizeof("pipe 
profile") - 1);
-   subport_params[0].n_pipe_profiles = profiles;
+   profiles = rte_cfgfile_num_sections(cfg, "pipe profile",
+   sizeof("pipe profile") - 1);
+   port_params.n_subport_profiles = profiles;
+
+   printf(" profiles = %d", profiles);
 
for (j = 0; j < profiles; j++) {
char pipe_name[32];
@@ -143,6 +146,93 @@ cfg_load_pipe(struct rte_cfgfile *cfg, struct 
rte_sched_pipe_params *pipe_params
 }
 
 int
+cfg_load_subport_profile(struct rte_cfgfile *cfg,
+   struct rte_sched_subport_profile_params *subport_profile)
+{
+   int i;
+   const char *entry;
+   int profiles;
+
+   if (!cfg || !subport_profile)
+   return -1;
+
+   profiles = rte_cfgfile_num_sections(cfg, "subport profile",
+  sizeof("subport profile") - 1);
+   subport_params[0].n_pipe_profiles = profiles;
+
+   for (i = 0; i < profiles; i++) {
+   char sec_name[32];
+   snprintf(sec_name, sizeof(sec_name), "subport profile %d", i);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tb rate");
+   if (entry)
+   subport_profile[i].tb_rate = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tb size");
+   if (entry)
+   subport_profile[i].tb_size = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc period");
+   if (entry)
+   subport_profile[i].tc_period = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 0 rate");
+   if (entry)
+   subport_profile[i].tc_rate[0] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 1 rate");
+   if (entry)
+   subport_profile[i].tc_rate[1] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 2 rate");
+   if (entry)
+   subport_profile[i].tc_rate[2] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 3 rate");
+   if (entry)
+   subport_profile[i].tc_rate[3] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 4 rate");
+   if (entry)
+   subport_profile[i].tc_rate[4] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 5 rate");
+   if (entry)
+   subport_profile[i].tc_rate[5] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 6 rate");
+   if (entry)
+   subport_profile[i].tc_rate[6] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 7 rate");
+   if (entry)
+   subport_profile[i].tc_rate[7] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 8 rate");
+   if (entry)
+   subport_profile[i].tc_rate[8] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 9 rate");
+   if (entry)
+   subport_profile[i].tc_rate[9] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 10 rate");
+   if (entry)
+   subport_profile[i].tc_rate[10] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 11 rate");
+   if (entry)
+   subport_profile[i].tc_rate[11] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 12 rate");
+   if (entry)
+   subport_profile[i].tc_rate[12] = (uint64_t)atoi(entry);
+   }
+
+

[dpdk-dev] [PATCH V3 0/2] gro: add UDP GRO and VXLAN UDP GRO support

[yang_y_yi]

From: Yi Yang 

In case that UFO or GSO is enabled, GRO is very necessary,
especially for UDP, it is more so. Many NICs can't support
VXLAN UDP UFO/USO and VLAN UFO/USO, so UDP performance
improvement depends on GSO and GRO to a great extent.

This patch series added VLAN UDP GRO and VXLAN UDP GRO
support.

Changelog
-
v2 -> v3: Remove UDP header length check

v1 -> v2: split into two patches

Yi Yang (2):
  gro: add UDP GRO support
  gro: add VXLAN UDP GRO support

 lib/librte_gro/Makefile |   2 +
 lib/librte_gro/gro_udp4.c   | 435 +++
 lib/librte_gro/gro_udp4.h   | 294 +
 lib/librte_gro/gro_vxlan_udp4.c | 556 
 lib/librte_gro/gro_vxlan_udp4.h | 152 +++
 lib/librte_gro/meson.build  |   2 +-
 lib/librte_gro/rte_gro.c| 192 +++---
 lib/librte_gro/rte_gro.h|   8 +-
 8 files changed, 1607 insertions(+), 34 deletions(-)
 create mode 100644 lib/librte_gro/gro_udp4.c
 create mode 100644 lib/librte_gro/gro_udp4.h
 create mode 100644 lib/librte_gro/gro_vxlan_udp4.c
 create mode 100644 lib/librte_gro/gro_vxlan_udp4.h

-- 
1.8.3.1

[dpdk-dev] [PATCH V3 1/2] gro: add UDP GRO support

[yang_y_yi]

From: Yi Yang 

UDP GRO can help improve VM-to-VM UDP performance when
VM is enabled UFO or GSO, GRO must be supported if GSO
or UFO is enabled, otherwise, performance gain will be
hurt.

With this enabled in DPDK, OVS DPDK can leverage it
to improve VM-to-VM UDP performance, this will make
sure IP fragments will be reassembled once it is
received from physical NIC. It is very helpful in OVS
DPDK VLAN TSO case.

Signed-off-by: Yi Yang 
---
 lib/librte_gro/Makefile|   1 +
 lib/librte_gro/gro_udp4.c  | 435 +
 lib/librte_gro/gro_udp4.h  | 294 ++
 lib/librte_gro/meson.build |   2 +-
 lib/librte_gro/rte_gro.c   | 129 ++
 lib/librte_gro/rte_gro.h   |   5 +-
 6 files changed, 832 insertions(+), 34 deletions(-)
 create mode 100644 lib/librte_gro/gro_udp4.c
 create mode 100644 lib/librte_gro/gro_udp4.h

diff --git a/lib/librte_gro/Makefile b/lib/librte_gro/Makefile
index e848687..41ec29e 100644
--- a/lib/librte_gro/Makefile
+++ b/lib/librte_gro/Makefile
@@ -15,6 +15,7 @@ EXPORT_MAP := rte_gro_version.map
 # source files
 SRCS-$(CONFIG_RTE_LIBRTE_GRO) += rte_gro.c
 SRCS-$(CONFIG_RTE_LIBRTE_GRO) += gro_tcp4.c
+SRCS-$(CONFIG_RTE_LIBRTE_GRO) += gro_udp4.c
 SRCS-$(CONFIG_RTE_LIBRTE_GRO) += gro_vxlan_tcp4.c
 
 # install this header file
diff --git a/lib/librte_gro/gro_udp4.c b/lib/librte_gro/gro_udp4.c
new file mode 100644
index 000..d6beece
--- /dev/null
+++ b/lib/librte_gro/gro_udp4.c
@@ -0,0 +1,435 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Inspur Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "gro_udp4.h"
+
+void *
+gro_udp4_tbl_create(uint16_t socket_id,
+   uint16_t max_flow_num,
+   uint16_t max_item_per_flow)
+{
+   struct gro_udp4_tbl *tbl;
+   size_t size;
+   uint32_t entries_num, i;
+
+   entries_num = max_flow_num * max_item_per_flow;
+   entries_num = RTE_MIN(entries_num, GRO_UDP4_TBL_MAX_ITEM_NUM);
+
+   if (entries_num == 0)
+   return NULL;
+
+   tbl = rte_zmalloc_socket(__func__,
+   sizeof(struct gro_udp4_tbl),
+   RTE_CACHE_LINE_SIZE,
+   socket_id);
+   if (tbl == NULL)
+   return NULL;
+
+   size = sizeof(struct gro_udp4_item) * entries_num;
+   tbl->items = rte_zmalloc_socket(__func__,
+   size,
+   RTE_CACHE_LINE_SIZE,
+   socket_id);
+   if (tbl->items == NULL) {
+   rte_free(tbl);
+   return NULL;
+   }
+   tbl->max_item_num = entries_num;
+
+   size = sizeof(struct gro_udp4_flow) * entries_num;
+   tbl->flows = rte_zmalloc_socket(__func__,
+   size,
+   RTE_CACHE_LINE_SIZE,
+   socket_id);
+   if (tbl->flows == NULL) {
+   rte_free(tbl->items);
+   rte_free(tbl);
+   return NULL;
+   }
+   /* INVALID_ARRAY_INDEX indicates an empty flow */
+   for (i = 0; i < entries_num; i++)
+   tbl->flows[i].start_index = INVALID_ARRAY_INDEX;
+   tbl->max_flow_num = entries_num;
+
+   return tbl;
+}
+
+void
+gro_udp4_tbl_destroy(void *tbl)
+{
+   struct gro_udp4_tbl *udp_tbl = tbl;
+
+   if (udp_tbl) {
+   rte_free(udp_tbl->items);
+   rte_free(udp_tbl->flows);
+   }
+   rte_free(udp_tbl);
+}
+
+static inline uint32_t
+find_an_empty_item(struct gro_udp4_tbl *tbl)
+{
+   uint32_t i;
+   uint32_t max_item_num = tbl->max_item_num;
+
+   for (i = 0; i < max_item_num; i++)
+   if (tbl->items[i].firstseg == NULL)
+   return i;
+   return INVALID_ARRAY_INDEX;
+}
+
+static inline uint32_t
+find_an_empty_flow(struct gro_udp4_tbl *tbl)
+{
+   uint32_t i;
+   uint32_t max_flow_num = tbl->max_flow_num;
+
+   for (i = 0; i < max_flow_num; i++)
+   if (tbl->flows[i].start_index == INVALID_ARRAY_INDEX)
+   return i;
+   return INVALID_ARRAY_INDEX;
+}
+
+static inline uint32_t
+insert_new_item(struct gro_udp4_tbl *tbl,
+   struct rte_mbuf *pkt,
+   uint64_t start_time,
+   uint32_t prev_idx,
+   uint16_t frag_offset,
+   uint8_t is_last_frag,
+   uint16_t ip_id)
+{
+   uint32_t item_idx;
+
+   item_idx = find_an_empty_item(tbl);
+   if (item_idx == INVALID_ARRAY_INDEX)
+   return INVALID_ARRAY_INDEX;
+
+   tbl->items[item_idx].firstseg = pkt;
+   tbl->items[item_idx].lastseg = rte_pktmbuf_lastseg(pkt);
+   tbl->items[item_idx].start_time = start_time;
+   tbl->items[item_idx].next_pkt_idx = INVALID_ARRAY_INDEX;
+   tbl->items[item_idx].frag_offset = frag_offset;
+   tbl->items[item_idx].is_last_frag = is_last_frag;
+   tbl->items[item_idx].ip_id = ip_i

[dpdk-dev] [PATCH V3 2/2] gro: add VXLAN UDP GRO support

[yang_y_yi]

From: Yi Yang 

VXLAN UDP GRO can help improve VM-to-VM UDP performance
when VM is enabled UFO or GSO, GRO must be supported if
GSO or UFO is enabled, otherwise, performance gain will
be hurt.

With this enabled in DPDK, OVS DPDK can leverage it to
improve VM-to-VM UDP performance, this will make sure
IP fragments will be reassembled once it is received
from physical NIC. It is very helpful in OVS DPDK VXLAN
TSO case.

Signed-off-by: Yi Yang 
---
 lib/librte_gro/Makefile |   1 +
 lib/librte_gro/gro_vxlan_udp4.c | 556 
 lib/librte_gro/gro_vxlan_udp4.h | 152 +++
 lib/librte_gro/meson.build  |   2 +-
 lib/librte_gro/rte_gro.c|  75 +-
 lib/librte_gro/rte_gro.h|   3 +
 6 files changed, 782 insertions(+), 7 deletions(-)
 create mode 100644 lib/librte_gro/gro_vxlan_udp4.c
 create mode 100644 lib/librte_gro/gro_vxlan_udp4.h

diff --git a/lib/librte_gro/Makefile b/lib/librte_gro/Makefile
index 41ec29e..30dd8c7 100644
--- a/lib/librte_gro/Makefile
+++ b/lib/librte_gro/Makefile
@@ -17,6 +17,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_GRO) += rte_gro.c
 SRCS-$(CONFIG_RTE_LIBRTE_GRO) += gro_tcp4.c
 SRCS-$(CONFIG_RTE_LIBRTE_GRO) += gro_udp4.c
 SRCS-$(CONFIG_RTE_LIBRTE_GRO) += gro_vxlan_tcp4.c
+SRCS-$(CONFIG_RTE_LIBRTE_GRO) += gro_vxlan_udp4.c
 
 # install this header file
 SYMLINK-$(CONFIG_RTE_LIBRTE_GRO)-include += rte_gro.h
diff --git a/lib/librte_gro/gro_vxlan_udp4.c b/lib/librte_gro/gro_vxlan_udp4.c
new file mode 100644
index 000..a66eaf0
--- /dev/null
+++ b/lib/librte_gro/gro_vxlan_udp4.c
@@ -0,0 +1,556 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2020 Inspur Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "gro_vxlan_udp4.h"
+
+void *
+gro_vxlan_udp4_tbl_create(uint16_t socket_id,
+   uint16_t max_flow_num,
+   uint16_t max_item_per_flow)
+{
+   struct gro_vxlan_udp4_tbl *tbl;
+   size_t size;
+   uint32_t entries_num, i;
+
+   entries_num = max_flow_num * max_item_per_flow;
+   entries_num = RTE_MIN(entries_num, GRO_VXLAN_UDP4_TBL_MAX_ITEM_NUM);
+
+   if (entries_num == 0)
+   return NULL;
+
+   tbl = rte_zmalloc_socket(__func__,
+   sizeof(struct gro_vxlan_udp4_tbl),
+   RTE_CACHE_LINE_SIZE,
+   socket_id);
+   if (tbl == NULL)
+   return NULL;
+
+   size = sizeof(struct gro_vxlan_udp4_item) * entries_num;
+   tbl->items = rte_zmalloc_socket(__func__,
+   size,
+   RTE_CACHE_LINE_SIZE,
+   socket_id);
+   if (tbl->items == NULL) {
+   rte_free(tbl);
+   return NULL;
+   }
+   tbl->max_item_num = entries_num;
+
+   size = sizeof(struct gro_vxlan_udp4_flow) * entries_num;
+   tbl->flows = rte_zmalloc_socket(__func__,
+   size,
+   RTE_CACHE_LINE_SIZE,
+   socket_id);
+   if (tbl->flows == NULL) {
+   rte_free(tbl->items);
+   rte_free(tbl);
+   return NULL;
+   }
+
+   for (i = 0; i < entries_num; i++)
+   tbl->flows[i].start_index = INVALID_ARRAY_INDEX;
+   tbl->max_flow_num = entries_num;
+
+   return tbl;
+}
+
+void
+gro_vxlan_udp4_tbl_destroy(void *tbl)
+{
+   struct gro_vxlan_udp4_tbl *vxlan_tbl = tbl;
+
+   if (vxlan_tbl) {
+   rte_free(vxlan_tbl->items);
+   rte_free(vxlan_tbl->flows);
+   }
+   rte_free(vxlan_tbl);
+}
+
+static inline uint32_t
+find_an_empty_item(struct gro_vxlan_udp4_tbl *tbl)
+{
+   uint32_t max_item_num = tbl->max_item_num, i;
+
+   for (i = 0; i < max_item_num; i++)
+   if (tbl->items[i].inner_item.firstseg == NULL)
+   return i;
+   return INVALID_ARRAY_INDEX;
+}
+
+static inline uint32_t
+find_an_empty_flow(struct gro_vxlan_udp4_tbl *tbl)
+{
+   uint32_t max_flow_num = tbl->max_flow_num, i;
+
+   for (i = 0; i < max_flow_num; i++)
+   if (tbl->flows[i].start_index == INVALID_ARRAY_INDEX)
+   return i;
+   return INVALID_ARRAY_INDEX;
+}
+
+static inline uint32_t
+insert_new_item(struct gro_vxlan_udp4_tbl *tbl,
+   struct rte_mbuf *pkt,
+   uint64_t start_time,
+   uint32_t prev_idx,
+   uint16_t frag_offset,
+   uint8_t is_last_frag,
+   uint16_t outer_ip_id,
+   uint16_t ip_id,
+   uint8_t outer_is_atomic)
+{
+   uint32_t item_idx;
+
+   item_idx = find_an_empty_item(tbl);
+   if (unlikely(item_idx == INVALID_ARRAY_INDEX))
+   return INVALID_ARRAY_INDEX;
+
+   tbl->items[item_idx].inner_item.firstseg = pkt;
+   tbl->items[item_idx].inner_item.lastseg = rte_pktmbuf_lastseg(pkt);
+   tbl->items[item_idx].inner_item.start_time = start_ti

Re: [dpdk-dev] [PATCH] gro: add UDP GRO and VXLAN UDP GRO support

[yang_y_yi]

Thanks Jiayu, I have removed it and sent out v3, please help ack if no more 
comments.


At 2020-09-02 14:26:37, "Hu, Jiayu"  wrote:

GRO lib requires users to provide correct mbuf->l2_len/packet_type etc..

This is for avoiding parsing packet headers. If we believe users give correct

packet_type, we also should believe l2_len/l4_len etc. are correct. Otherwise,

we need to get layer 4 header length from ipv4 header, rather than mbuf->l4_len.

 

rte_gro_rx_prepare() is a good way to do sanity check or prepare l2_len etc. 
fields,

but this function should be optional, IMO. Either user or rte_gro_rx_prepare() 
provides

correct l2_len etc. value.

 

Thanks,

Jiayu

From: yang_y_yi 
Sent: Wednesday, September 2, 2020 1:58 PM
To: Hu, Jiayu 
Cc: dev@dpdk.org; tho...@monjalon.net; yangy...@inspur.com
Subject: Re:RE: Re:Re: [dpdk-dev] [PATCH] gro: add UDP GRO and VXLAN UDP GRO 
support
Importance: High

 

Jiayu, TCP header length is variable if there is TCP option, it is usually 20 
if no TCP option, but correct value must be between 20 and 60 (including 20 and 
60), I think we can't assume l4 header length has been set correctly if 
packet_type is set correctly, this is my point. I think it will be better if we 
can add a rte_gro_rx_prepare as rte_eth_tx_prepare. GRO can't work normally 
only if one of all the related fields isn't set correctly. So I don't think 
such sanity check is a bad thing.

At 2020-09-02 13:44:56, "Hu, Jiayu"  wrote:

Yi,

 

Packet type is checked by mbuf->packet_type field, and input

packets should provide correct packet_type value. TCP GRO

only process TCP packets whose header length is between

20 and 60 bytes. So we check l4_len.

 

From: yang_y_yi 
Sent: Tuesday, September 1, 2020 4:43 PM
To: Hu, Jiayu 
Cc:dev@dpdk.org; tho...@monjalon.net; yangy...@inspur.com
Subject: Re:Re: [dpdk-dev] [PATCH] gro: add UDP GRO and VXLAN UDP GRO support

 

Jiayu, BTW, after I check it again, I think udp header length check is 
necessary, it is actually a sanity check io order to ensure it is indeed a udp 
packet, gro_tcp4.c did same thing.

At 2020-09-01 14:10:41, "yang_y_yi"  wrote:
>At 2020-09-01 12:27:29, "Hu, Jiayu"  wrote:
>>Hi Yi,
>> 
>>This patch supports UDP and VxLAN/UDP, but both are in one patch.
>>It's too large, and please split it into small patches.
> 
>Jiayu, thank you so much for your great review , I'll send v2 to split it into 
>two patches and fix your comments. Detailed replies for comments embedded, 
>please check them.
> 
>> 
>>Thanks,
>>Jiayu
>> 
>>> -Original Message-
>>> From: yang_y...@163.com 
>>> Sent: Wednesday, July 1, 2020 2:48 PM
>>> To: dev@dpdk.org
>>> Cc: Hu, Jiayu ; tho...@monjalon.net;
>>> yangy...@inspur.com; yang_y...@163.com
>>> Subject: [PATCH] gro: add UDP GRO and VXLAN UDP GRO support
>>> 
>>> From: Yi Yang 
>>> 
>>> UDP GRO and VXLAN UDP GRO can help improve VM-to-VM
>>> UDP performance when VM is enabled UFO or GSO, GRO
>>> must be supported if GSO, UFO or VXLAN UFO is enabled
>>> , otherwise, performance gain will be hurt.
>>> 
>>> With this enabled in DPDK, OVS DPDK can leverage it
>>> to improve VM-to-VM UDP performance, this will make
>>> sure IP fragments will be reassembled once it is
>>> received from physical NIC.
>>> 
>>> Signed-off-by: Yi Yang 
>>> ---
>>>  lib/librte_gro/Makefile |   2 +
>>>  lib/librte_gro/gro_udp4.c   | 443 
>>>  lib/librte_gro/gro_udp4.h   | 296 +
>>>  lib/librte_gro/gro_vxlan_udp4.c | 556
>>> 
>>>  lib/librte_gro/gro_vxlan_udp4.h | 152 +++
>>>  lib/librte_gro/meson.build  |   2 +-
>>>  lib/librte_gro/rte_gro.c| 192 +++---
>>>  lib/librte_gro/rte_gro.h|   8 +-
>>>  8 files changed, 1617 insertions(+), 34 deletions(-)
>>>  create mode 100644 lib/librte_gro/gro_udp4.c
>>>  create mode 100644 lib/librte_gro/gro_udp4.h
>>>  create mode 100644 lib/librte_gro/gro_vxlan_udp4.c
>>>  create mode 100644 lib/librte_gro/gro_vxlan_udp4.h
>>> +
>>> +
>>> +/*
>>> + * update the packet length for the flushed packet.
>>> + */
>>> +static inline void
>>> +update_header(struct gro_udp4_item *item)
>>> +{
>>> +  struct rte_ipv4_hdr *ipv4_hdr;
>>> +  struct rte_mbuf *pkt = item->firstseg;
>>> +  uint16_t frag_offset;
>>> +
>>> +  ipv4_hdr = (struct rte_ipv4_hdr *)(rte_pktmbuf_mtod(pkt, char *) +
>>> + pkt->l2_len);
>>> +  ipv4_hdr->total_length = rte_cpu_to_be_16(pkt->pkt_len -
>>> + pkt->l2_len);
>>> +
>>> +  /* Clear MF bit if it is last fragment */
>>> +  if (item->is_last_frag) {
>>> + frag_offset = rte_be_to_cpu_16(ipv4_hdr->fragment_offset);
>>> + ipv4_hdr->fragment_offset =
>>> + rte_cpu_to_be_16(frag_offset &
>>> ~RTE_IPV4_HDR_MF_FLAG);
>>> +  }
>> 
>>Need to clear MF bit for non-last fragments, and we also need to clear offset 
>>value.
> 
>For non-last fragment, MF (More Fragment) bit is necessary, why do you thin

[dpdk-dev] [PATCH v3 1/4] net/bnxt: configure loopback parif for egress flows

[Ajit Khaparde]

From: Kishore Padmanabha 

Configure loopback parif for full offload egress flows.
PARIF is handler to a partition of the physical port.
The full offload egress flows for the VF rep interface must
use loopback parif to offload missed flows. The miss
flow path for the VF rep interface has to be loopback interface
parif entry and for the non-VF rep interface it has to be the
interface's parif entry.

Fixes: fe82f3e02701 ("net/bnxt: support exact match templates")

Signed-off-by: Kishore Padmanabha 
Reviewed-by: Shahaji Bhosle 
Reviewed-by: Ajit Khaparde 
---
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.c  |  6 ++
 .../net/bnxt/tf_ulp/ulp_template_db_class.c   | 20 +--
 .../net/bnxt/tf_ulp/ulp_template_db_enum.h|  3 ++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c 
b/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c
index 861414da9..fcb7c4430 100644
--- a/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c
+++ b/drivers/net/bnxt/tf_ulp/ulp_rte_parser.c
@@ -211,6 +211,12 @@ bnxt_ulp_comp_fld_intf_update(struct ulp_rte_parser_params 
*params)
ULP_COMP_FLD_IDX_WR(params,
BNXT_ULP_CF_IDX_VF_FUNC_PARIF,
parif);
+
+   /* populate the loopback parif */
+   ULP_COMP_FLD_IDX_WR(params,
+   BNXT_ULP_CF_IDX_LOOPBACK_PARIF,
+   BNXT_ULP_SYM_VF_FUNC_PARIF);
+
} else {
/* Set DRV func PARIF */
if (ulp_port_db_parif_get(params->ulp_ctx, ifindex,
diff --git a/drivers/net/bnxt/tf_ulp/ulp_template_db_class.c 
b/drivers/net/bnxt/tf_ulp/ulp_template_db_class.c
index 94160a902..aaa552aeb 100644
--- a/drivers/net/bnxt/tf_ulp/ulp_template_db_class.c
+++ b/drivers/net/bnxt/tf_ulp/ulp_template_db_class.c
@@ -16731,8 +16731,8 @@ struct bnxt_ulp_mapper_result_field_info 
ulp_class_result_field_list[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
.result_operand_true = {
-   (BNXT_ULP_CF_IDX_VF_FUNC_PARIF >> 8) & 0xff,
-   BNXT_ULP_CF_IDX_VF_FUNC_PARIF & 0xff,
+   (BNXT_ULP_CF_IDX_LOOPBACK_PARIF >> 8) & 0xff,
+   BNXT_ULP_CF_IDX_LOOPBACK_PARIF & 0xff,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
.result_operand_false = {
@@ -16933,8 +16933,8 @@ struct bnxt_ulp_mapper_result_field_info 
ulp_class_result_field_list[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
.result_operand_true = {
-   (BNXT_ULP_CF_IDX_VF_FUNC_PARIF >> 8) & 0xff,
-   BNXT_ULP_CF_IDX_VF_FUNC_PARIF & 0xff,
+   (BNXT_ULP_CF_IDX_LOOPBACK_PARIF >> 8) & 0xff,
+   BNXT_ULP_CF_IDX_LOOPBACK_PARIF & 0xff,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
.result_operand_false = {
@@ -17135,8 +17135,8 @@ struct bnxt_ulp_mapper_result_field_info 
ulp_class_result_field_list[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
.result_operand_true = {
-   (BNXT_ULP_CF_IDX_VF_FUNC_PARIF >> 8) & 0xff,
-   BNXT_ULP_CF_IDX_VF_FUNC_PARIF & 0xff,
+   (BNXT_ULP_CF_IDX_LOOPBACK_PARIF >> 8) & 0xff,
+   BNXT_ULP_CF_IDX_LOOPBACK_PARIF & 0xff,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
.result_operand_false = {
@@ -17337,8 +17337,8 @@ struct bnxt_ulp_mapper_result_field_info 
ulp_class_result_field_list[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
.result_operand_true = {
-   (BNXT_ULP_CF_IDX_VF_FUNC_PARIF >> 8) & 0xff,
-   BNXT_ULP_CF_IDX_VF_FUNC_PARIF & 0xff,
+   (BNXT_ULP_CF_IDX_LOOPBACK_PARIF >> 8) & 0xff,
+   BNXT_ULP_CF_IDX_LOOPBACK_PARIF & 0xff,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
.result_operand_false = {
@@ -17530,8 +17530,8 @@ struct bnxt_ulp_mapper_result_field_info 
ulp_class_result_field_list[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
.result_operand_true = {
-   (BNXT_ULP_CF_IDX_VF_FUNC_PARIF >> 8) & 0xff,
-   BNXT_ULP_CF_IDX_VF_FUNC_PARIF & 0xff,
+   (BNXT_ULP_CF_IDX_LOOPBACK_PARIF >> 8) & 0xff,
+   BNXT_ULP_CF_IDX_LOOPBACK_PARIF & 0xff,
0x00

[dpdk-dev] [PATCH v3 3/4] net/bnxt: cleanups and checks ULP context allocation

[Ajit Khaparde]

From: Somnath Kotur 

Set ulp_ctx explicitly to NULL in ulp_ctx_deinit() so that representor
init is aborted if parent ulp context is not initialized.
Also check for the same before creation of port default rules.
Additional checks added in VF rep dev ops for proper parent dev
initialization, to avoid null pointer dereference.

Fixes: 322bd6e70272 ("net/bnxt: add port representor infrastructure")
Fixes: 313ac35ac701 ("net/bnxt: support ULP session manager init")

Signed-off-by: Somnath Kotur 
Reviewed-by: Venkat Duvvuru 
Reviewed-by: Ajit Khaparde 
---
 drivers/net/bnxt/bnxt_reps.c| 18 ++
 drivers/net/bnxt/tf_ulp/bnxt_ulp.c  |  2 ++
 drivers/net/bnxt/tf_ulp/ulp_def_rules.c |  2 +-
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/net/bnxt/bnxt_reps.c b/drivers/net/bnxt/bnxt_reps.c
index 6fa9a30d2..2941aff7b 100644
--- a/drivers/net/bnxt/bnxt_reps.c
+++ b/drivers/net/bnxt/bnxt_reps.c
@@ -319,6 +319,7 @@ static int bnxt_vfr_alloc(struct rte_eth_dev *vfr_ethdev)
 {
int rc = 0;
struct bnxt_vf_representor *vfr = vfr_ethdev->data->dev_private;
+   struct bnxt *parent_bp;
 
if (!vfr || !vfr->parent_dev) {
PMD_DRV_LOG(ERR,
@@ -326,6 +327,13 @@ static int bnxt_vfr_alloc(struct rte_eth_dev *vfr_ethdev)
return -ENOMEM;
}
 
+   parent_bp = vfr->parent_dev->data->dev_private;
+   if (parent_bp && !parent_bp->ulp_ctx) {
+   PMD_DRV_LOG(ERR,
+   "ulp context not allocated for parent\n");
+   return -EIO;
+   }
+
/* Check if representor has been already allocated in FW */
if (vfr->vfr_tx_cfa_action)
return 0;
@@ -534,6 +542,11 @@ int bnxt_vf_rep_rx_queue_setup_op(struct rte_eth_dev 
*eth_dev,
return -EINVAL;
}
 
+   if (!parent_bp->rx_queues) {
+   PMD_DRV_LOG(ERR, "Parent Rx qs not configured yet\n");
+   return -EINVAL;
+   }
+
parent_rxq = parent_bp->rx_queues[queue_idx];
if (!parent_rxq) {
PMD_DRV_LOG(ERR, "Parent RxQ has not been configured yet\n");
@@ -628,6 +641,11 @@ int bnxt_vf_rep_tx_queue_setup_op(struct rte_eth_dev 
*eth_dev,
return -EINVAL;
}
 
+   if (!parent_bp->tx_queues) {
+   PMD_DRV_LOG(ERR, "Parent Tx qs not configured yet\n");
+   return -EINVAL;
+   }
+
parent_txq = parent_bp->tx_queues[queue_idx];
if (!parent_txq) {
PMD_DRV_LOG(ERR, "Parent TxQ has not been configured yet\n");
diff --git a/drivers/net/bnxt/tf_ulp/bnxt_ulp.c 
b/drivers/net/bnxt/tf_ulp/bnxt_ulp.c
index 263040ee4..0d4a45513 100644
--- a/drivers/net/bnxt/tf_ulp/bnxt_ulp.c
+++ b/drivers/net/bnxt/tf_ulp/bnxt_ulp.c
@@ -884,6 +884,8 @@ bnxt_ulp_deinit(struct bnxt *bp)
ulp_session_deinit(session);
 
rte_free(bp->ulp_ctx);
+
+   bp->ulp_ctx = NULL;
 }
 
 /* Function to set the Mark DB into the context */
diff --git a/drivers/net/bnxt/tf_ulp/ulp_def_rules.c 
b/drivers/net/bnxt/tf_ulp/ulp_def_rules.c
index 9fb1a028f..46acc1d65 100644
--- a/drivers/net/bnxt/tf_ulp/ulp_def_rules.c
+++ b/drivers/net/bnxt/tf_ulp/ulp_def_rules.c
@@ -465,7 +465,7 @@ bnxt_ulp_create_df_rules(struct bnxt *bp)
int rc;
 
if (!BNXT_TRUFLOW_EN(bp) ||
-   BNXT_ETH_DEV_IS_REPRESENTOR(bp->eth_dev))
+   BNXT_ETH_DEV_IS_REPRESENTOR(bp->eth_dev) || !bp->ulp_ctx)
return 0;
 
port_id = bp->eth_dev->data->port_id;
-- 
2.21.1 (Apple Git-122.3)

[dpdk-dev] [PATCH v3 0/4] bnxt patches

[Ajit Khaparde]

fixes and cleanups in bnxt TRUFlow

v1->v2: updated signed-off tags in commit logs.
v2->v3: update commit logs based on review comments.

Kishore Padmanabha (2):
  net/bnxt: configure loopback parif for egress flows
  net/bnxt: lookup default action record parif

Somnath Kotur (1):
  net/bnxt: cleanups and checks ULP context allocation

Venkat Duvvuru (1):
  net/bnxt: fix VF representor port add

 drivers/net/bnxt/bnxt.h   |  21 ++
 drivers/net/bnxt/bnxt_cpr.c   |  51 +++
 drivers/net/bnxt/bnxt_ethdev.c|  12 +-
 drivers/net/bnxt/bnxt_hwrm.c  |   4 +
 drivers/net/bnxt/bnxt_hwrm.h  |   2 +
 drivers/net/bnxt/bnxt_reps.c  |  88 +++--
 drivers/net/bnxt/tf_ulp/bnxt_ulp.c|   2 +
 drivers/net/bnxt/tf_ulp/ulp_def_rules.c   |   2 +-
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.c  |   6 +
 .../net/bnxt/tf_ulp/ulp_template_db_class.c   | 314 +++---
 .../net/bnxt/tf_ulp/ulp_template_db_enum.h|   3 +-
 11 files changed, 356 insertions(+), 149 deletions(-)

-- 
2.21.1 (Apple Git-122.3)

[dpdk-dev] [PATCH v3 2/4] net/bnxt: lookup default action record parif

[Ajit Khaparde]

From: Kishore Padmanabha 

The lookup default action record parif table is updated to catch
the miss path for the entries in the exact match table.
PARIF is handler to a partition of the physical port. The lookup
parif table contains entries for each incoming interface the default
action for the miss entries that do not match the configured rules in
the exact match table. This fix configures those entries in that table.

Fixes: fe82f3e02701 ("net/bnxt: support exact match templates")

Signed-off-by: Kishore Padmanabha 
Reviewed-by: Shahaji Bhosle 
Reviewed-by: Mike Baucom 
Reviewed-by: Ajit Khaparde 
---
 .../net/bnxt/tf_ulp/ulp_template_db_class.c   | 294 +++---
 1 file changed, 177 insertions(+), 117 deletions(-)

diff --git a/drivers/net/bnxt/tf_ulp/ulp_template_db_class.c 
b/drivers/net/bnxt/tf_ulp/ulp_template_db_class.c
index aaa552aeb..1f650e0d7 100644
--- a/drivers/net/bnxt/tf_ulp/ulp_template_db_class.c
+++ b/drivers/net/bnxt/tf_ulp/ulp_template_db_class.c
@@ -3240,148 +3240,148 @@ struct bnxt_ulp_mapper_tbl_list_info 
ulp_class_tmpl_list[] = {
[((1 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
-   .num_tbls = 5,
+   .num_tbls = 6,
.start_tbl_idx = 0,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_DEFAULT
},
[((2 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
-   .num_tbls = 6,
-   .start_tbl_idx = 5,
+   .num_tbls = 7,
+   .start_tbl_idx = 6,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_DEFAULT
},
[((3 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
.num_tbls = 7,
-   .start_tbl_idx = 11,
+   .start_tbl_idx = 13,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_DEFAULT
},
[((4 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
-   .num_tbls = 6,
-   .start_tbl_idx = 18,
+   .num_tbls = 7,
+   .start_tbl_idx = 20,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_DEFAULT
},
[((5 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
.num_tbls = 1,
-   .start_tbl_idx = 24,
+   .start_tbl_idx = 27,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_DEFAULT
},
[((6 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
.num_tbls = 4,
-   .start_tbl_idx = 25,
+   .start_tbl_idx = 28,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_REGULAR
},
[((7 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
.num_tbls = 5,
-   .start_tbl_idx = 29,
+   .start_tbl_idx = 32,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_REGULAR
},
[((8 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
.num_tbls = 5,
-   .start_tbl_idx = 34,
+   .start_tbl_idx = 37,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_REGULAR
},
[((9 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
.num_tbls = 5,
-   .start_tbl_idx = 39,
+   .start_tbl_idx = 42,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_REGULAR
},
[((10 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
.num_tbls = 5,
-   .start_tbl_idx = 44,
+   .start_tbl_idx = 47,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_REGULAR
},
[((11 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
.num_tbls = 4,
-   .start_tbl_idx = 49,
+   .start_tbl_idx = 52,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_REGULAR
},
[((12 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
.num_tbls = 4,
-   .start_tbl_idx = 53,
+   .start_tbl_idx = 56,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_REGULAR
},
[((13 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_ULP_DEVICE_ID_WH_PLUS)] = {
.device_name = BNXT_ULP_DEVICE_ID_WH_PLUS,
.num_tbls = 4,
-   .start_tbl_idx = 57,
+   .start_tbl_idx = 60,
.flow_db_table_type = BNXT_ULP_FDB_TYPE_REGULAR
},
[((14 << BNXT_ULP_LOG2_MAX_NUM_DEV) |
BNXT_

[dpdk-dev] [PATCH v3 4/4] net/bnxt: fix VF representor port add

[Ajit Khaparde]

From: Venkat Duvvuru 

Fix VF representor port add when it's endpoint interface is down.
While adding vf representor port to a bridge, vnic & svif information of
vf representors endpoint(VF) would be needed to program default flow rules.
However, if the endpoint interface is down when vf representor port is
added, firmware will return invalid vnic & svif information.

This patch fixes the problem by registering to DEFAULT_VNIC_CHANGE
async event and once the async event is received, use the endpoint
information(VF's fid) to fetch it's vnic & svif information and
program the default flow rules.

Fixes: 322bd6e70272 ("net/bnxt: add port representor infrastructure")

Signed-off-by: Venkat Duvvuru 
Reviewed-by: Somnath Kotur 
Reviewed-by: Ajit Khaparde 
---
 drivers/net/bnxt/bnxt.h| 21 ++
 drivers/net/bnxt/bnxt_cpr.c| 51 +
 drivers/net/bnxt/bnxt_ethdev.c | 12 +-
 drivers/net/bnxt/bnxt_hwrm.c   |  4 ++
 drivers/net/bnxt/bnxt_hwrm.h   |  2 +
 drivers/net/bnxt/bnxt_reps.c   | 70 +-
 6 files changed, 140 insertions(+), 20 deletions(-)

diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index f4b2a3f92..74e2c9a70 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -147,6 +147,23 @@
 #define BNXT_CMPL_AGGR_DMA_TMR_DURING_INT  50
 #define BNXT_NUM_CMPL_DMA_AGGR_DURING_INT  12
 
+#defineBNXT_DEFAULT_VNIC_STATE_MASK\
+   
HWRM_ASYNC_EVENT_CMPL_DEFAULT_VNIC_CHANGE_EVENT_DATA1_DEF_VNIC_STATE_MASK
+#defineBNXT_DEFAULT_VNIC_STATE_SFT \
+   HWRM_ASYNC_EVENT_CMPL_DEFAULT_VNIC_CHANGE_EVENT_DATA1_DEF_VNIC_STATE_SFT
+#defineBNXT_DEFAULT_VNIC_ALLOC \
+   
HWRM_ASYNC_EVENT_CMPL_DEFAULT_VNIC_CHANGE_EVENT_DATA1_DEF_VNIC_STATE_DEF_VNIC_ALLOC
+#defineBNXT_DEFAULT_VNIC_FREE  \
+   
HWRM_ASYNC_EVENT_CMPL_DEFAULT_VNIC_CHANGE_EVENT_DATA1_DEF_VNIC_STATE_DEF_VNIC_FREE
+#defineBNXT_DEFAULT_VNIC_CHANGE_PF_ID_MASK \
+   HWRM_ASYNC_EVENT_CMPL_DEFAULT_VNIC_CHANGE_EVENT_DATA1_PF_ID_MASK
+#defineBNXT_DEFAULT_VNIC_CHANGE_PF_ID_SFT  \
+   HWRM_ASYNC_EVENT_CMPL_DEFAULT_VNIC_CHANGE_EVENT_DATA1_PF_ID_SFT
+#defineBNXT_DEFAULT_VNIC_CHANGE_VF_ID_MASK \
+   HWRM_ASYNC_EVENT_CMPL_DEFAULT_VNIC_CHANGE_EVENT_DATA1_VF_ID_MASK
+#defineBNXT_DEFAULT_VNIC_CHANGE_VF_ID_SFT  \
+   HWRM_ASYNC_EVENT_CMPL_DEFAULT_VNIC_CHANGE_EVENT_DATA1_VF_ID_SFT
+
 struct bnxt_led_info {
uint8_t  num_leds;
uint8_t  led_id;
@@ -498,6 +515,8 @@ struct bnxt_mark_info {
 struct bnxt_rep_info {
struct rte_eth_dev  *vfr_eth_dev;
pthread_mutex_t vfr_lock;
+   pthread_mutex_t vfr_start_lock;
+   boolconduit_valid;
 };
 
 /* address space location of register */
@@ -796,6 +815,7 @@ struct bnxt_vf_representor {
uint16_tswitch_domain_id;
uint16_tvf_id;
uint16_tfw_fid;
+#defineBNXT_DFLT_VNIC_ID_INVALID   0x
uint16_tdflt_vnic_id;
uint16_tsvif;
uint16_tvfr_tx_cfa_action;
@@ -884,6 +904,7 @@ uint16_t bnxt_get_phy_port_id(uint16_t port);
 uint16_t bnxt_get_vport(uint16_t port);
 enum bnxt_ulp_intf_type
 bnxt_get_interface_type(uint16_t port);
+int bnxt_vf_rep_dev_start_op(struct rte_eth_dev *eth_dev);
 
 void bnxt_cancel_fc_thread(struct bnxt *bp);
 void bnxt_flow_cnt_alarm_cb(void *arg);
diff --git a/drivers/net/bnxt/bnxt_cpr.c b/drivers/net/bnxt/bnxt_cpr.c
index 40e5350f6..464ca8b6f 100644
--- a/drivers/net/bnxt/bnxt_cpr.c
+++ b/drivers/net/bnxt/bnxt_cpr.c
@@ -46,6 +46,54 @@ void bnxt_wait_for_device_shutdown(struct bnxt *bp)
} while (timeout);
 }
 
+static void
+bnxt_process_default_vnic_change(struct bnxt *bp,
+struct hwrm_async_event_cmpl *async_cmp)
+{
+   uint16_t fid, vnic_state, parent_id, vf_fid, vf_id;
+   struct bnxt_vf_representor *vf_rep_bp;
+   struct rte_eth_dev *eth_dev;
+   bool vfr_found = false;
+   uint32_t event_data;
+
+   if (!BNXT_TRUFLOW_EN(bp))
+   return;
+
+   PMD_DRV_LOG(INFO, "Default vnic change async event received\n");
+   event_data = rte_le_to_cpu_32(async_cmp->event_data1);
+
+   vnic_state = (event_data & BNXT_DEFAULT_VNIC_STATE_MASK) >>
+   BNXT_DEFAULT_VNIC_STATE_SFT;
+   if (vnic_state != BNXT_DEFAULT_VNIC_ALLOC)
+   return;
+
+   parent_id = (event_data & BNXT_DEFAULT_VNIC_CHANGE_PF_ID_MASK) >>
+   BNXT_DEFAULT_VNIC_CHANGE_PF_ID_SFT;
+   fid = BNXT_PF(bp) ? bp->fw_fid : bp->parent->fid;
+   if (parent_id != fid || !bp->rep_info)
+   return;
+
+   vf_fid = (event_data & BNXT_DEFAULT_VNIC_CHANGE_VF_ID_MASK

Re: [dpdk-dev] [PATCH] usertools: add huge page setup script

[Ferruh Yigit]

On 9/1/2020 5:56 PM, Stephen Hemminger wrote:
> This is an improved version of the setup of huge pages
> bases on earlier DPDK setup. Differences are:
>* it autodetects NUMA vs non NUMA
>* it allows setting different page sizes
>  recent kernels support multiple sizes.
>* it accepts a parameter in bytes (not pages).
> 
> Signed-off-by: Stephen Hemminger 
> ---
> This is lightly tested, it still needs testing on multiple architectures
> etc.
> 

Thanks.
It can be useful to have options to display current hugepage settings and remove
the allocation.

Re: [dpdk-dev] [PATCH] usertools: add huge page setup script

[Bruce Richardson]

On Tue, Sep 01, 2020 at 09:56:43AM -0700, Stephen Hemminger wrote:
> This is an improved version of the setup of huge pages
> bases on earlier DPDK setup. Differences are:
>* it autodetects NUMA vs non NUMA
>* it allows setting different page sizes
>  recent kernels support multiple sizes.
>* it accepts a parameter in bytes (not pages).
> 
> Signed-off-by: Stephen Hemminger 
> ---
> This is lightly tested, it still needs testing on multiple architectures
> etc.
> 
>  usertools/hugepage-setup.sh | 169 
>  1 file changed, 169 insertions(+)
>  create mode 100755 usertools/hugepage-setup.sh
> 
> diff --git a/usertools/hugepage-setup.sh b/usertools/hugepage-setup.sh
> new file mode 100755
> index ..df132e2f8d64
> --- /dev/null
> +++ b/usertools/hugepage-setup.sh
> @@ -0,0 +1,169 @@
> +#! /bin/bash

Is there a good reason to limit this to bash rather than general "sh"?

Also, if we ever see this script being expanded to cover more, would it be
more extensible in python rather than shell?

[dpdk-dev] [PATCH] drivers/common: mark symbols as internal

[David Marchand]

Now that we have the internal tag, let's avoid confusion with exported
symbols in common drivers that were using the experimental tag as a
workaround.
There is also no need to put internal API symbols in the public stable
ABI.

Signed-off-by: David Marchand 
---
Note: I noticed a patch from Haiyue for iavf.
I am fine with reposting per driver, but it seems worth a tree-wide
change from my pov.

---
 drivers/common/cpt/cpt_pmd_ops_helper.h |  8 +---
 drivers/common/cpt/rte_common_cpt_version.map   | 13 +++--
 drivers/common/iavf/iavf_prototype.h|  8 
 drivers/common/iavf/rte_common_iavf_version.map |  2 +-
 drivers/common/mvep/rte_common_mvep_version.map |  2 +-
 drivers/common/mvep/rte_mvep_common.h   |  3 +++
 drivers/common/octeontx/octeontx_mbox.h |  5 +
 .../common/octeontx/rte_common_octeontx_version.map |  2 +-
 8 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/drivers/common/cpt/cpt_pmd_ops_helper.h 
b/drivers/common/cpt/cpt_pmd_ops_helper.h
index 716ae94c8e..413ca50edd 100644
--- a/drivers/common/cpt/cpt_pmd_ops_helper.h
+++ b/drivers/common/cpt/cpt_pmd_ops_helper.h
@@ -18,7 +18,7 @@
  * @return
  *   - length
  */
-
+__rte_internal
 int32_t
 cpt_pmd_ops_helper_get_mlen_direct_mode(void);
 
@@ -29,6 +29,7 @@ cpt_pmd_ops_helper_get_mlen_direct_mode(void);
  * @return
  *   - length
  */
+__rte_internal
 int
 cpt_pmd_ops_helper_get_mlen_sg_mode(void);
 
@@ -38,6 +39,7 @@ cpt_pmd_ops_helper_get_mlen_sg_mode(void);
  * @return
  *  - length
  */
+__rte_internal
 int
 cpt_pmd_ops_helper_asym_get_mlen(void);
 
@@ -50,13 +52,13 @@ cpt_pmd_ops_helper_asym_get_mlen(void);
  * @return
  *  - 0 on success, negative on error
  */
-__rte_experimental
+__rte_internal
 int cpt_fpm_init(uint64_t *fpm_table_iova);
 
 /*
  * Clear ECC FMUL precomputed table
  */
-__rte_experimental
+__rte_internal
 void cpt_fpm_clear(void);
 
 #endif /* _CPT_PMD_OPS_HELPER_H_ */
diff --git a/drivers/common/cpt/rte_common_cpt_version.map 
b/drivers/common/cpt/rte_common_cpt_version.map
index 4d85021a87..b4080e0f8c 100644
--- a/drivers/common/cpt/rte_common_cpt_version.map
+++ b/drivers/common/cpt/rte_common_cpt_version.map
@@ -1,18 +1,11 @@
-DPDK_21 {
+INTERNAL {
global:
 
+   cpt_fpm_clear;
+   cpt_fpm_init;
cpt_pmd_ops_helper_asym_get_mlen;
cpt_pmd_ops_helper_get_mlen_direct_mode;
cpt_pmd_ops_helper_get_mlen_sg_mode;
 
local: *;
 };
-
-EXPERIMENTAL {
-   global:
-
-   cpt_fpm_clear;
-   cpt_fpm_init;
-
-   local: *;
-};
diff --git a/drivers/common/iavf/iavf_prototype.h 
b/drivers/common/iavf/iavf_prototype.h
index 31ce2af494..1b72127092 100644
--- a/drivers/common/iavf/iavf_prototype.h
+++ b/drivers/common/iavf/iavf_prototype.h
@@ -5,6 +5,8 @@
 #ifndef _IAVF_PROTOTYPE_H_
 #define _IAVF_PROTOTYPE_H_
 
+#include 
+
 #include "iavf_type.h"
 #include "iavf_alloc.h"
 #include "virtchnl.h"
@@ -17,7 +19,9 @@
  */
 
 /* adminq functions */
+__rte_internal
 enum iavf_status iavf_init_adminq(struct iavf_hw *hw);
+__rte_internal
 enum iavf_status iavf_shutdown_adminq(struct iavf_hw *hw);
 enum iavf_status iavf_init_asq(struct iavf_hw *hw);
 enum iavf_status iavf_init_arq(struct iavf_hw *hw);
@@ -30,6 +34,7 @@ void iavf_free_adminq_asq(struct iavf_hw *hw);
 void iavf_free_adminq_arq(struct iavf_hw *hw);
 enum iavf_status iavf_validate_mac_addr(u8 *mac_addr);
 void iavf_adminq_init_ring_data(struct iavf_hw *hw);
+__rte_internal
 enum iavf_status iavf_clean_arq_element(struct iavf_hw *hw,
struct iavf_arq_event_info *e,
u16 *events_pending);
@@ -61,6 +66,7 @@ enum iavf_status iavf_aq_set_rss_key(struct iavf_hw *hw,
 const char *iavf_aq_str(struct iavf_hw *hw, enum iavf_admin_queue_err aq_err);
 const char *iavf_stat_str(struct iavf_hw *hw, enum iavf_status stat_err);
 
+__rte_internal
 enum iavf_status iavf_set_mac_type(struct iavf_hw *hw);
 
 extern struct iavf_rx_ptype_decoded iavf_ptype_lookup[];
@@ -76,9 +82,11 @@ void iavf_acquire_spinlock(struct iavf_spinlock *sp);
 void iavf_release_spinlock(struct iavf_spinlock *sp);
 void iavf_destroy_spinlock(struct iavf_spinlock *sp);
 
+__rte_internal
 void iavf_vf_parse_hw_config(struct iavf_hw *hw,
 struct virtchnl_vf_resource *msg);
 enum iavf_status iavf_vf_reset(struct iavf_hw *hw);
+__rte_internal
 enum iavf_status iavf_aq_send_msg_to_pf(struct iavf_hw *hw,
enum virtchnl_ops v_opcode,
enum iavf_status v_retval,
diff --git a/drivers/common/iavf/rte_common_iavf_version.map 
b/drivers/common/iavf/rte_common_iavf_version.map
index 44142499e0..e0f117197c 100644
--- a/drivers/common/iavf/rte_common_iavf_version.map
+++ b/drivers/common/iavf/rte_common_iavf_version.map
@@ -1,4 +1,4 @@
-DPDK_21 {
+INTERNAL {
global:
 
iavf_aq_send_msg_to_pf;
diff --git a/

Re: [dpdk-dev] [PATCH V1] testpmd: add eeprom/module eeprom display

[Ferruh Yigit]

On 9/1/2020 8:07 PM, David Liu wrote:
> Change display message.
> Add EEPROM dump command
>   "show port  eeprom"
> Add module EEPROM dump command
>  "show port  module_eeprom"
> Commands will dump the content of the 
> EEPROM/module EEPROM for the selected port.
> 
> Signed-off-by: David Liu 
> ---
>  app/test-pmd/cmdline.c  |  87 ++
>  app/test-pmd/config.c   | 126 
>  app/test-pmd/testpmd.h  |   2 +
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst |  14 +++
>  4 files changed, 229 insertions(+)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index a037a55c6..71c98dd96 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -166,6 +166,12 @@ static void cmd_help_long_parsed(void *parsed_result,
>   "show port 
> (info|stats|summary|xstats|fdir|stat_qmap|dcb_tc|cap) (port_id|all)\n"
>   "Display information for port_id, or all.\n\n"
>  
> + "show port (port_id) eeprom \n"
> + "Display the EEPROM infomation for given 
> port_id.\n\n"
> +
> + "show port (port_id) module_eeprom \n"
> + "Display the port moudle EEPROM infomation for 
> given port_id.\n\n"
> +
>   "show port X rss reta (size) (mask0,mask1,...)\n"
>   "Display the rss redirection table entry indicated"
>   " by masks on port X. size is used to indicate the"
> @@ -7594,6 +7600,85 @@ cmdline_parse_inst_t cmd_showdevice = {
>   NULL,
>   },
>  };
> +
> +/* ** SHOW EEPROM INFO *** */
> +struct cmd_showeeprom_result {
> +   cmdline_fixed_string_t show;
> +   cmdline_fixed_string_t port;
> +   cmdline_fixed_string_t type;
> +uint16_t portnum;
> +};
> +
> +static void cmd_showeeprom_parsed(void *parsed_result,
> +   __rte_unused struct cmdline *cl,
> +   __rte_unused void *data)
> +{
> +   struct cmd_showeeprom_result *res = parsed_result;
> +
> +   port_eeprom_display(res->portnum);
> +}
> +
> +cmdline_parse_token_string_t cmd_showeeprom_show =
> +   TOKEN_STRING_INITIALIZER(struct cmd_showeeprom_result, show, "show");
> +cmdline_parse_token_string_t cmd_showeeprom_port =
> +   TOKEN_STRING_INITIALIZER(struct cmd_showeeprom_result, port, "port");
> +cmdline_parse_token_num_t cmd_showeeprom_portnum =
> +   TOKEN_NUM_INITIALIZER(struct cmd_showeeprom_result, portnum, UINT16);
> +cmdline_parse_token_string_t cmd_showeeprom_type =
> +   TOKEN_STRING_INITIALIZER(struct cmd_showeeprom_result, type, 
> "eeprom");
> +
> +cmdline_parse_inst_t cmd_showeeprom = {
> +   .f = cmd_showeeprom_parsed,
> +   .data = NULL,
> +   .help_str = "show port  eeprom",
> +   .tokens = {
> +   (void *)&cmd_showeeprom_show,
> +   (void *)&cmd_showeeprom_port,
> +   (void *)&cmd_showeeprom_portnum,
> +   (void *)&cmd_showeeprom_type,
> +   NULL,
> +   },
> +};
> +
> +/* ** SHOW MODULE EEPROM INFO *** */
> +struct cmd_showmoduleeeprom_result {
> +   cmdline_fixed_string_t show;
> +   cmdline_fixed_string_t port;
> +   cmdline_fixed_string_t type;
> +uint16_t portnum;
> +};
> +
> +static void cmd_showmoduleeeprom_parsed(void *parsed_result,
> +   __rte_unused struct cmdline *cl,
> +   __rte_unused void *data)
> +{
> +   struct cmd_showmoduleeeprom_result *res = parsed_result;
> +
> +   port_module_eeprom_display(res->portnum);
> +}
> +
> +cmdline_parse_token_string_t cmd_showmoduleeeprom_show =
> +   TOKEN_STRING_INITIALIZER(struct cmd_showmoduleeeprom_result, show, 
> "show");
> +cmdline_parse_token_string_t cmd_showmoduleeeprom_port =
> +   TOKEN_STRING_INITIALIZER(struct cmd_showmoduleeeprom_result, port, 
> "port");
> +cmdline_parse_token_num_t cmd_showmoduleeeprom_portnum =
> + TOKEN_NUM_INITIALIZER(struct cmd_showmoduleeeprom_result, portnum, 
> UINT16);
> +cmdline_parse_token_string_t cmd_showmoduleeeprom_type =
> + TOKEN_STRING_INITIALIZER(struct cmd_showmoduleeeprom_result, type, 
> "module_eeprom");
> +
> +cmdline_parse_inst_t cmd_showmoduleeeprom = {
> + .f = cmd_showmoduleeeprom_parsed,
> + .data = NULL,
> + .help_str = "show port  module_eeprom",
> + .tokens = {
> + (void *)&cmd_showmoduleeeprom_show,
> + (void *)&cmd_showmoduleeeprom_port,
> + (void *)&cmd_showmoduleeeprom_portnum,
> + (void *)&cmd_showmoduleeeprom_type,
> + NULL,
> + },
> +};> +

Since both commands are simple and related, what do you think merging their
implementation? This reduces the clutter.
Please check '#' usage in the 'TOKEN_STRING_INITIALIZER', and "port
start|stop|close all" implementation can be sample.

Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add a field for rxq info structure

[Chengchang Tang]

Hi, Matan

On 2020/9/2 15:19, Matan Azrad wrote:
> 
> Hi Chengchang
> 
> From: Chengchang Tang
>> Hi, Matan
>>
>> On 2020/9/1 23:33, Matan Azrad wrote:
>>>
>>> Hi Chengchang
>>>
>>> Please see some question below.
>>>
>>> From: Chengchang Tang
 Add a field named rx_buf_size in rte_eth_rxq_info to indicate the
 buffer size used in receiving packets for HW.

 In this way, upper-layer users can get this information by calling
 rte_eth_rx_queue_info_get.

 Signed-off-by: Chengchang Tang 
 Reviewed-by: Wei Hu (Xavier) 
 Acked-by: Andrew Rybchenko 
 ---
  lib/librte_ethdev/rte_ethdev.h | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/lib/librte_ethdev/rte_ethdev.h
 b/lib/librte_ethdev/rte_ethdev.h index 70295d7..9fed5cb 100644
 --- a/lib/librte_ethdev/rte_ethdev.h
 +++ b/lib/librte_ethdev/rte_ethdev.h
 @@ -1420,6 +1420,8 @@ struct rte_eth_rxq_info {
 struct rte_eth_rxconf conf; /**< queue config parameters. */
 uint8_t scattered_rx;   /**< scattered packets RX supported. */
 uint16_t nb_desc;   /**< configured number of RXDs. */
 +   /**< buffer size used for hardware when receive packets. */
 +   uint16_t rx_buf_size;
>>>
>>> Is it the maximum supported Rx buffer by the HW?
>>> If yes, maybe max_rx_buf_size is better name?
>>
>> No, it is the Rx buffer size currently used by HW.
> 
> Doesn't it defined by the user? Using Rx queue mem-pool mbuf room size?
>
> And it may be different per Rx queue

Yes, it is defined by user using the Rx queue mem-pool mbuf room size.
When different queues are bound to different mempools, different queues may 
have different value.
> 
>> IMHO, the structure rte_eth_rxq_info and associated query API are mainly
>> used to query HW configurations at runtime or after queue is
>> configured/setup. Therefore, the content of this structure should be the
>> current HW configuration.
> 
> It looks me more like capabilities...
> The one which define the current configuration is the user by the 
> configuration APIs(after reading the capabilities).

I prefer to consider the structure rte_eth_dev_info as the capabilities. 
Because rxq_info and
associated APIs are not available until the queue is configured. And the max 
rx_buf_size is
already exists in dev_info.
>
> I don't think we have here all the current configurations, so what is special 
> in this one?

I think the structure is used to store the queue-related configuration, 
especially the final HW
configuration that may be different from user configuration and some 
configurations that are not
mandatory for the user(PMDs will use a default configuration). Such as the 
scatterred_rx and
rx_drop_en in rte_eth_rxconf, some PMDs will adjust it in some cases based on 
their HW constraints.

This configuration item meets the above criteria. The value range of 
rx_buf_size varies according
to HW. Some HW may require 1k-alignment, while others may require several fixed 
values. So, the PMDs
will configure it based on their HW constraints. This results in difference 
between the user
configuration and the actual configuration and this value affects the memory 
usage and performance.
I think there's a need for a way to expose that information.
> 
> 
>>> Maybe document that 0 means - no limitation by HW?
>>
>> Yes, there is no need to fill this filed for HW that has no restrictions on 
>> it.
>> I'll add it in v4.
>>
>>> Must application read it in order to know if its datapath should handle
>> multi-segment buffers?
>>
>> I think it's more appropriate to use scattered_rx to determine if multi-
>> segment buffers should be handled.
>>
>>>
>>> Maybe it will be good to force application to configure scatter when this
>> field is valid and smaller than max_rx_pkt_len\max_lro.. (<= room size)...
> 
> Can you explain more what is the issue you came to solve?

This HW information may be useful when there is some problems running a 
application. This structure
and related APIs can be used to expose it at run time.
> 
>>>
  } __rte_cache_min_aligned;

  /**
>>
> .
> 

Re: [dpdk-dev] [EXT] [PATCH] drivers/common: mark symbols as internal

[Anoob Joseph]

> --
> Now that we have the internal tag, let's avoid confusion with exported
> symbols in common drivers that were using the experimental tag as a
> workaround.
> There is also no need to put internal API symbols in the public stable ABI.
> 
> Signed-off-by: David Marchand 
> ---
> Note: I noticed a patch from Haiyue for iavf.
> I am fine with reposting per driver, but it seems worth a tree-wide change
> from my pov.
> 
Acked-by: Anoob Joseph 

[dpdk-dev] [PATCH] net/ice: enable QINQ filter in switch

[Qiming Yang]

This patch enabled QINQ filter in switch filter. This code
depend on base code update.

Signed-off-by: Wei Zhao 
Signed-off-by: Qiming Yang 
---
 drivers/net/ice/ice_generic_flow.c  |   8 +++
 drivers/net/ice/ice_generic_flow.h  |   1 +
 drivers/net/ice/ice_switch_filter.c | 106 +---
 3 files changed, 104 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ice/ice_generic_flow.c 
b/drivers/net/ice/ice_generic_flow.c
index 54b0316b9..9356bff72 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -1448,6 +1448,14 @@ enum rte_flow_item_type pattern_eth_vlan_pppoes_proto[] 
= {
RTE_FLOW_ITEM_TYPE_PPPOE_PROTO_ID,
RTE_FLOW_ITEM_TYPE_END,
 };
+enum rte_flow_item_type pattern_eth_qinq_pppoes_proto[] = {
+   RTE_FLOW_ITEM_TYPE_ETH,
+   RTE_FLOW_ITEM_TYPE_VLAN,
+   RTE_FLOW_ITEM_TYPE_VLAN,
+   RTE_FLOW_ITEM_TYPE_PPPOES,
+   RTE_FLOW_ITEM_TYPE_PPPOE_PROTO_ID,
+   RTE_FLOW_ITEM_TYPE_END,
+};
 enum rte_flow_item_type pattern_eth_qinq_pppoes[] = {
RTE_FLOW_ITEM_TYPE_ETH,
RTE_FLOW_ITEM_TYPE_VLAN,
diff --git a/drivers/net/ice/ice_generic_flow.h 
b/drivers/net/ice/ice_generic_flow.h
index 434d2f425..887531905 100644
--- a/drivers/net/ice/ice_generic_flow.h
+++ b/drivers/net/ice/ice_generic_flow.h
@@ -425,6 +425,7 @@ extern enum rte_flow_item_type pattern_eth_pppoes[];
 extern enum rte_flow_item_type pattern_eth_pppoes_proto[];
 extern enum rte_flow_item_type pattern_eth_vlan_pppoes[];
 extern enum rte_flow_item_type pattern_eth_vlan_pppoes_proto[];
+extern enum rte_flow_item_type pattern_eth_qinq_pppoes_proto[];
 extern enum rte_flow_item_type pattern_eth_qinq_pppoes[];
 extern enum rte_flow_item_type pattern_eth_pppoes_ipv4[];
 extern enum rte_flow_item_type pattern_eth_vlan_pppoes_ipv4[];
diff --git a/drivers/net/ice/ice_switch_filter.c 
b/drivers/net/ice/ice_switch_filter.c
index 24320ac7d..f9849bbf5 100644
--- a/drivers/net/ice/ice_switch_filter.c
+++ b/drivers/net/ice/ice_switch_filter.c
@@ -35,8 +35,8 @@
 #define ICE_SW_INSET_ETHER ( \
ICE_INSET_DMAC | ICE_INSET_SMAC | ICE_INSET_ETHERTYPE)
 #define ICE_SW_INSET_MAC_VLAN ( \
-   ICE_INSET_DMAC | ICE_INSET_SMAC | ICE_INSET_ETHERTYPE | \
-   ICE_INSET_VLAN_OUTER)
+   ICE_INSET_DMAC | ICE_INSET_SMAC | ICE_INSET_ETHERTYPE | \
+   ICE_INSET_VLAN_INNER)
 #define ICE_SW_INSET_MAC_IPV4 ( \
ICE_INSET_DMAC | ICE_INSET_IPV4_DST | ICE_INSET_IPV4_SRC | \
ICE_INSET_IPV4_PROTO | ICE_INSET_IPV4_TTL | ICE_INSET_IPV4_TOS)
@@ -130,6 +130,12 @@
 #define ICE_SW_INSET_MAC_IPV6_PFCP ( \
ICE_SW_INSET_MAC_IPV6 | \
ICE_INSET_PFCP_S_FIELD | ICE_INSET_PFCP_SEID)
+#define ICE_SW_INSET_MAC_QINQ  ( \
+   ICE_SW_INSET_MAC_VLAN | ICE_INSET_VLAN_OUTER)
+#define ICE_SW_INSET_MAC_IPV4_QINQ ( \
+   ICE_SW_INSET_MAC_QINQ | ICE_SW_INSET_MAC_IPV4)
+#define ICE_SW_INSET_MAC_IPV6_QINQ ( \
+   ICE_SW_INSET_MAC_QINQ | ICE_SW_INSET_MAC_IPV6)
 
 struct sw_meta {
struct ice_adv_lkup_elem *list;
@@ -225,6 +231,20 @@ ice_pattern_match_item ice_switch_pattern_dist_comms[] = {
ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_pfcp,
ICE_INSET_NONE, ICE_INSET_NONE},
+   {pattern_ethertype_qinq,
+   ICE_SW_INSET_MAC_QINQ, ICE_INSET_NONE},
+   {pattern_eth_qinq_ipv4,
+   ICE_SW_INSET_MAC_IPV4_QINQ, ICE_INSET_NONE},
+   {pattern_eth_qinq_ipv6,
+   ICE_SW_INSET_MAC_IPV6_QINQ, ICE_INSET_NONE},
+   {pattern_eth_qinq_pppoes,
+   ICE_SW_INSET_MAC_PPPOE, ICE_INSET_NONE},
+   {pattern_eth_qinq_pppoes_proto,
+   ICE_SW_INSET_MAC_PPPOE_PROTO, ICE_INSET_NONE},
+   {pattern_eth_qinq_pppoes_ipv4,
+   ICE_SW_INSET_MAC_PPPOE_IPV4, ICE_INSET_NONE},
+   {pattern_eth_qinq_pppoes_ipv6,
+   ICE_SW_INSET_MAC_PPPOE_IPV6, ICE_INSET_NONE},
 };
 
 static struct
@@ -345,6 +365,20 @@ ice_pattern_match_item ice_switch_pattern_perm[] = {
ICE_INSET_NONE, ICE_INSET_NONE},
{pattern_eth_ipv6_pfcp,
ICE_INSET_NONE, ICE_INSET_NONE},
+   {pattern_ethertype_qinq,
+   ICE_SW_INSET_MAC_QINQ, ICE_INSET_NONE},
+   {pattern_eth_qinq_ipv4,
+   ICE_SW_INSET_MAC_IPV4_QINQ, ICE_INSET_NONE},
+   {pattern_eth_qinq_ipv6,
+   ICE_SW_INSET_MAC_IPV6_QINQ, ICE_INSET_NONE},
+   {pattern_eth_qinq_pppoes,
+   ICE_SW_INSET_MAC_PPPOE, ICE_INSET_NONE},
+   {pattern_eth_qinq_pppoes_proto,
+   ICE_SW_INSET_MAC_PPPOE_PROTO, ICE_INSET_NONE},
+   {pattern_eth_qinq_pppoes_ipv4,
+   ICE_SW_INSET_MAC_PPPOE_IPV4, ICE_INSET_NONE},
+   {pattern_eth_qinq_pppoes_ipv6,
+   ICE_SW_INSET_MAC_PPPOE_IPV6, ICE_INSET_NONE},
 };
 
 static int
@@ -47

Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add a field for rxq info structure

[Matan Azrad]

Hi Chengchang

From: Chengchang Tang
> Hi, Matan
> 
> On 2020/9/2 15:19, Matan Azrad wrote:
> >
> > Hi Chengchang
> >
> > From: Chengchang Tang
> >> Hi, Matan
> >>
> >> On 2020/9/1 23:33, Matan Azrad wrote:
> >>>
> >>> Hi Chengchang
> >>>
> >>> Please see some question below.
> >>>
> >>> From: Chengchang Tang
>  Add a field named rx_buf_size in rte_eth_rxq_info to indicate the
>  buffer size used in receiving packets for HW.
> 
>  In this way, upper-layer users can get this information by calling
>  rte_eth_rx_queue_info_get.
> 
>  Signed-off-by: Chengchang Tang 
>  Reviewed-by: Wei Hu (Xavier) 
>  Acked-by: Andrew Rybchenko 
>  ---
>   lib/librte_ethdev/rte_ethdev.h | 2 ++
>   1 file changed, 2 insertions(+)
> 
>  diff --git a/lib/librte_ethdev/rte_ethdev.h
>  b/lib/librte_ethdev/rte_ethdev.h index 70295d7..9fed5cb 100644
>  --- a/lib/librte_ethdev/rte_ethdev.h
>  +++ b/lib/librte_ethdev/rte_ethdev.h
>  @@ -1420,6 +1420,8 @@ struct rte_eth_rxq_info {
>  struct rte_eth_rxconf conf; /**< queue config parameters. */
>  uint8_t scattered_rx;   /**< scattered packets RX supported. 
>  */
>  uint16_t nb_desc;   /**< configured number of RXDs. */
>  +   /**< buffer size used for hardware when receive packets. */
>  +   uint16_t rx_buf_size;
> >>>
> >>> Is it the maximum supported Rx buffer by the HW?
> >>> If yes, maybe max_rx_buf_size is better name?
> >>
> >> No, it is the Rx buffer size currently used by HW.

> > Doesn't it defined by the user? Using Rx queue mem-pool mbuf room size?
> >
> > And it may be different per Rx queue
> 
> Yes, it is defined by user using the Rx queue mem-pool mbuf room size.
> When different queues are bound to different mempools, different queues
> may have different value.
> >
> >> IMHO, the structure rte_eth_rxq_info and associated query API are
> >> mainly used to query HW configurations at runtime or after queue is
> >> configured/setup. Therefore, the content of this structure should be
> >> the current HW configuration.
> >
> > It looks me more like capabilities...
> > The one which define the current configuration is the user by the
> configuration APIs(after reading the capabilities).
> 
> I prefer to consider the structure rte_eth_dev_info as the capabilities.

Yes.

> Because rxq_info and associated APIs are not available until the queue is
> configured. And the max rx_buf_size is already exists in dev_info.
> >
> > I don't think we have here all the current configurations, so what is 
> > special
> in this one?
> 
> I think the structure is used to store the queue-related configuration,
> especially the final HW configuration that may be different from user
> configuration and some configurations that are not mandatory for the
> user(PMDs will use a default configuration). Such as the scatterred_rx and
> rx_drop_en in rte_eth_rxconf, some PMDs will adjust it in some cases based
> on their HW constraints.

Ok, this struct(struct rte_eth_rxq_info) is new for me.
Thanks for the explanation.
 
> This configuration item meets the above criteria. The value range of
> rx_buf_size varies according to HW. Some HW may require 1k-alignment,
> while others may require several fixed values. So, the PMDs will configure it
> based on their HW constraints. This results in difference between the user
> configuration and the actual configuration and this value affects the memory
> usage and performance.
> I think there's a need for a way to expose that information.

So the user can configure X and the driver will use Y!=X?

Should the application validate its own configurations after setting them 
successfully?

> >
> >>> Maybe document that 0 means - no limitation by HW?
> >>
> >> Yes, there is no need to fill this filed for HW that has no restrictions 
> >> on it.
> >> I'll add it in v4.
> >>
> >>> Must application read it in order to know if its datapath should
> >>> handle
> >> multi-segment buffers?
> >>
> >> I think it's more appropriate to use scattered_rx to determine if
> >> multi- segment buffers should be handled.
> >>
> >>>
> >>> Maybe it will be good to force application to configure scatter when
> >>> this
> >> field is valid and smaller than max_rx_pkt_len\max_lro.. (<= room size)...
> >
> > Can you explain more what is the issue you came to solve?
> 
> This HW information may be useful when there is some problems running a
> application. This structure and related APIs can be used to expose it at run
> time.
> >
OK

[dpdk-dev] [PATCH v1 2/4] arm: change cpuflag macros to compiler macros

[Radu Nicolau]

Replace use of RTE_MACHINE_CPUFLAG macros with regular compiler
macros.

Signed-off-by: Sean Morrissey 
Signed-off-by: Radu Nicolau 
---
 app/test-pmd/macswap.c |  2 +-
 config/arm/meson.build |  6 --
 drivers/net/ixgbe/ixgbe_ethdev.c   |  2 +-
 examples/l3fwd/l3fwd.h |  2 +-
 examples/l3fwd/l3fwd_em.c  | 12 ++--
 examples/l3fwd/l3fwd_em_hlm.h  |  2 +-
 examples/l3fwd/l3fwd_em_sequential.h   |  2 +-
 examples/l3fwd/l3fwd_lpm.c |  6 +++---
 lib/librte_eal/arm/include/rte_memcpy_32.h |  2 +-
 lib/librte_hash/Makefile   |  2 +-
 lib/librte_hash/rte_cuckoo_hash.c  |  2 +-
 lib/librte_hash/rte_hash_crc.h |  2 +-
 lib/librte_hash/rte_thash.h|  4 ++--
 lib/librte_member/rte_member.h |  2 +-
 lib/librte_net/rte_net_crc.c   |  2 +-
 lib/librte_node/ip4_lookup.c   |  2 +-
 lib/librte_sched/rte_sched.c   |  2 +-
 lib/librte_table/rte_lru_arm64.h   |  2 +-
 lib/librte_table/rte_table_hash_func.h |  2 +-
 19 files changed, 26 insertions(+), 32 deletions(-)

diff --git a/app/test-pmd/macswap.c b/app/test-pmd/macswap.c
index fbe8cb39e..c84e65000 100644
--- a/app/test-pmd/macswap.c
+++ b/app/test-pmd/macswap.c
@@ -39,7 +39,7 @@
 #include "testpmd.h"
 #if defined(RTE_ARCH_X86)
 #include "macswap_sse.h"
-#elif defined(RTE_MACHINE_CPUFLAG_NEON)
+#elif defined(__ARM__NEON)
 #include "macswap_neon.h"
 #else
 #include "macswap.h"
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 8728051d5..42c0c34a5 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -208,20 +208,14 @@ message(machine_args)
 
 if (cc.get_define('__ARM_NEON', args: machine_args) != '' or
 cc.get_define('__aarch64__', args: machine_args) != '')
-   dpdk_conf.set('RTE_MACHINE_CPUFLAG_NEON', 1)
compile_time_cpuflags += ['RTE_CPUFLAG_NEON']
 endif
 
 if cc.get_define('__ARM_FEATURE_CRC32', args: machine_args) != ''
-   dpdk_conf.set('RTE_MACHINE_CPUFLAG_CRC32', 1)
compile_time_cpuflags += ['RTE_CPUFLAG_CRC32']
 endif
 
 if cc.get_define('__ARM_FEATURE_CRYPTO', args: machine_args) != ''
-   dpdk_conf.set('RTE_MACHINE_CPUFLAG_AES', 1)
-   dpdk_conf.set('RTE_MACHINE_CPUFLAG_PMULL', 1)
-   dpdk_conf.set('RTE_MACHINE_CPUFLAG_SHA1', 1)
-   dpdk_conf.set('RTE_MACHINE_CPUFLAG_SHA2', 1)
compile_time_cpuflags += ['RTE_CPUFLAG_AES', 'RTE_CPUFLAG_PMULL',
'RTE_CPUFLAG_SHA1', 'RTE_CPUFLAG_SHA2']
 endif
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index fd0cb9b0e..f70012684 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3960,7 +3960,7 @@ ixgbe_dev_supported_ptypes_get(struct rte_eth_dev *dev)
dev->rx_pkt_burst == ixgbe_recv_pkts_bulk_alloc)
return ptypes;
 
-#if defined(RTE_ARCH_X86) || defined(RTE_MACHINE_CPUFLAG_NEON)
+#if defined(RTE_ARCH_X86) || defined(__ARM_NEON)
if (dev->rx_pkt_burst == ixgbe_recv_pkts_vec ||
dev->rx_pkt_burst == ixgbe_recv_scattered_pkts_vec)
return ptypes;
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 67055431f..2cf06099e 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -12,7 +12,7 @@
 
 #define RTE_LOGTYPE_L3FWD RTE_LOGTYPE_USER1
 
-#if !defined(NO_HASH_MULTI_LOOKUP) && defined(RTE_MACHINE_CPUFLAG_NEON)
+#if !defined(NO_HASH_MULTI_LOOKUP) && defined(__ARM_NEON)
 #define NO_HASH_MULTI_LOOKUP 1
 #endif
 
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 78181a640..c529dcd3e 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -28,7 +28,7 @@
 #include "l3fwd.h"
 #include "l3fwd_event.h"
 
-#if defined(RTE_ARCH_X86) || defined(RTE_MACHINE_CPUFLAG_CRC32)
+#if defined(RTE_ARCH_X86) || defined(__ARM_FEATURE_CRC32)
 #define EM_HASH_CRC 1
 #endif
 
@@ -223,7 +223,7 @@ em_mask_key(void *key, xmm_t mask)
 
return _mm_and_si128(data, mask);
 }
-#elif defined(RTE_MACHINE_CPUFLAG_NEON)
+#elif defined(__ARM_NEON)
 static inline xmm_t
 em_mask_key(void *key, xmm_t mask)
 {
@@ -303,7 +303,7 @@ em_get_ipv6_dst_port(void *ipv6_hdr, uint16_t portid, void 
*lookup_struct)
return (ret < 0) ? portid : ipv6_l3fwd_out_if[ret];
 }
 
-#if defined RTE_ARCH_X86 || defined RTE_MACHINE_CPUFLAG_NEON
+#if defined RTE_ARCH_X86 || defined __ARM_NEON
 #if defined(NO_HASH_MULTI_LOOKUP)
 #include "l3fwd_em_sequential.h"
 #else
@@ -685,7 +685,7 @@ em_main_loop(__rte_unused void *dummy)
if (nb_rx == 0)
continue;
 
-#if defined RTE_ARCH_X86 || defined RTE_MACHINE_CPUFLAG_NEON
+#if defined RTE_ARCH_X86 || defined __ARM_NEON
l3fwd_em_send_packets(nb_rx, pkts_burst,
portid, qconf);
 #else
@@ -723,7 +

[dpdk-dev] [PATCH v1 4/4] doc: remove reference to RTE_MACHINE_CPUFLAG

[Radu Nicolau]

RTE_MACHINE_CPUFLAG macros are replaced with predefined
compiler defines.

Signed-off-by: Sean Morrissey 
Signed-off-by: Radu Nicolau 
---
 doc/guides/prog_guide/writing_efficient_code.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/writing_efficient_code.rst 
b/doc/guides/prog_guide/writing_efficient_code.rst
index 2639ef7bf..c1f2d627a 100644
--- a/doc/guides/prog_guide/writing_efficient_code.rst
+++ b/doc/guides/prog_guide/writing_efficient_code.rst
@@ -273,5 +273,5 @@ main() function and checks if the current machine is 
suitable for running the bi
 Along with compiler optimizations,
 a set of preprocessor defines are automatically added to the build process 
(regardless of the compiler version).
 These defines correspond to the instruction sets that the target CPU should be 
able to support.
-For example, a binary compiled for any SSE4.2-capable processor will have 
RTE_MACHINE_CPUFLAG_SSE4_2 defined,
+For example, a binary compiled for any SSE4.2-capable processor will have a 
pre-defined compiler macro,
 thus enabling compile-time code path selection for different platforms.
-- 
2.17.1

[dpdk-dev] [PATCH v1 1/4] x86: change cpuflag macros to compiler macros

[Radu Nicolau]

Replace use of RTE_MACHINE_CPUFLAG macros with regular compiler
macros.

Signed-off-by: Sean Morrissey 
Signed-off-by: Radu Nicolau 
---
 app/test/test_memcpy_perf.c |  8 
 config/x86/meson.build  |  2 --
 drivers/net/enic/Makefile   |  2 +-
 drivers/net/enic/meson.build|  2 +-
 drivers/net/i40e/Makefile   |  2 +-
 drivers/net/i40e/meson.build|  2 +-
 drivers/net/iavf/Makefile   |  2 +-
 drivers/net/iavf/meson.build|  2 +-
 drivers/net/ice/Makefile|  2 +-
 drivers/net/ice/meson.build |  2 +-
 examples/l3fwd/l3fwd_em.c   |  4 ++--
 lib/librte_acl/Makefile |  2 +-
 lib/librte_acl/meson.build  |  2 +-
 lib/librte_eal/common/rte_random.c  |  4 ++--
 lib/librte_eal/x86/include/rte_memcpy.h |  8 
 lib/librte_efd/rte_efd_x86.h|  2 +-
 lib/librte_hash/rte_cuckoo_hash.c   |  2 +-
 lib/librte_member/rte_member_ht.c   | 10 +-
 lib/librte_member/rte_member_x86.h  |  2 +-
 lib/librte_net/rte_net_crc.c|  2 +-
 mk/rte.cpuflags.mk  |  1 -
 21 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/app/test/test_memcpy_perf.c b/app/test/test_memcpy_perf.c
index 00a2092b4..c711e36ba 100644
--- a/app/test/test_memcpy_perf.c
+++ b/app/test/test_memcpy_perf.c
@@ -51,13 +51,13 @@ static size_t buf_sizes[TEST_VALUE_RANGE];
 #define TEST_BATCH_SIZE 100
 
 /* Data is aligned on this many bytes (power of 2) */
-#ifdef RTE_MACHINE_CPUFLAG_AVX512F
+#ifdef __AVX512F__
 #define ALIGNMENT_UNIT  64
-#elif defined RTE_MACHINE_CPUFLAG_AVX2
+#elif defined __AVX2__
 #define ALIGNMENT_UNIT  32
-#else /* RTE_MACHINE_CPUFLAG */
+#else
 #define ALIGNMENT_UNIT  16
-#endif /* RTE_MACHINE_CPUFLAG */
+#endif
 
 /*
  * Pointers used in performance tests. The two large buffers are for uncached
diff --git a/config/x86/meson.build b/config/x86/meson.build
index 6ec020ef6..fea4d5403 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -18,7 +18,6 @@ endif
 
 base_flags = ['SSE', 'SSE2', 'SSE3','SSSE3', 'SSE4_1', 'SSE4_2']
 foreach f:base_flags
-   dpdk_conf.set('RTE_MACHINE_CPUFLAG_' + f, 1)
compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
 endforeach
 
@@ -32,7 +31,6 @@ foreach f:optional_flags
elif f == 'RDRND'
f = 'RDRAND'
endif
-   dpdk_conf.set('RTE_MACHINE_CPUFLAG_' + f, 1)
compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
endif
 endforeach
diff --git a/drivers/net/enic/Makefile b/drivers/net/enic/Makefile
index d098a474a..a6055983c 100644
--- a/drivers/net/enic/Makefile
+++ b/drivers/net/enic/Makefile
@@ -45,7 +45,7 @@ ifeq ($(CONFIG_RTE_ARCH_X86_64),y)
 # 'default' machine (corei7 which has no avx2) and run the binary on
 # newer CPUs that have avx2.
 # This part is verbatim from i40e makefile.
-ifeq ($(findstring 
RTE_MACHINE_CPUFLAG_AVX2,$(CFLAGS)),RTE_MACHINE_CPUFLAG_AVX2)
+ifneq ($(filter $(AUTO_CPUFLAGS),__AVX2__),)
CC_AVX2_SUPPORT=1
 else
CC_AVX2_SUPPORT=\
diff --git a/drivers/net/enic/meson.build b/drivers/net/enic/meson.build
index 1bd7cc7e1..896b224e4 100644
--- a/drivers/net/enic/meson.build
+++ b/drivers/net/enic/meson.build
@@ -19,7 +19,7 @@ deps += ['hash']
 includes += include_directories('base')
 
 # The current implementation assumes 64-bit pointers
-if dpdk_conf.has('RTE_MACHINE_CPUFLAG_AVX2') and dpdk_conf.get('RTE_ARCH_64')
+if cc.get_define('__AVX2__', args: machine_args) != '' and 
dpdk_conf.get('RTE_ARCH_64')
sources += files('enic_rxtx_vec_avx2.c')
 # Build the avx2 handler if the compiler supports it, even though 'machine'
 # does not. This is to support users who build for the min supported machine
diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 43f10941b..bb486b83c 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -85,7 +85,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_tm.c
 SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_vf_representor.c
 
 ifeq ($(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR),y)
-ifeq ($(findstring 
RTE_MACHINE_CPUFLAG_AVX2,$(CFLAGS)),RTE_MACHINE_CPUFLAG_AVX2)
+ifneq ($(filter $(AUTO_CPUFLAGS),__AVX2__),)
CC_AVX2_SUPPORT=1
 else
CC_AVX2_SUPPORT=\
diff --git a/drivers/net/i40e/meson.build b/drivers/net/i40e/meson.build
index 211d45d88..68f9895cd 100644
--- a/drivers/net/i40e/meson.build
+++ b/drivers/net/i40e/meson.build
@@ -31,7 +31,7 @@ if arch_subdir == 'x86'
# compile AVX2 version if either:
# a. we have AVX supported in minimum instruction set baseline
# b. it's not minimum instruction set, but supported by compiler
-   if dpdk_conf.has('RTE_MACHINE_CPUFLAG_AVX2')
+   if cc.get_define('__AVX2__', args: machine_args) != ''
cflags += ['-DCC_AVX2_SUPPORT']
sources += fi

[dpdk-dev] [PATCH v1 3/4] ppc: change cpuflag macros to compiler macros

[Radu Nicolau]

Replace use of RTE_MACHINE_CPUFLAG macros with regular compiler
macros.

Signed-off-by: Sean Morrissey 
Signed-off-by: Radu Nicolau 
---
 config/ppc/meson.build | 2 --
 1 file changed, 2 deletions(-)

diff --git a/config/ppc/meson.build b/config/ppc/meson.build
index aa7d73d11..0d8da87e6 100644
--- a/config/ppc/meson.build
+++ b/config/ppc/meson.build
@@ -21,5 +21,3 @@ endif
 dpdk_conf.set('RTE_MAX_LCORE', 1536)
 dpdk_conf.set('RTE_MAX_NUMA_NODES', 32)
 dpdk_conf.set('RTE_CACHE_LINE_SIZE', 128)
-dpdk_conf.set('RTE_MACHINE_CPUFLAG_ALTIVEC', 1)
-dpdk_conf.set('RTE_MACHINE_CPUFLAG_VSX', 1)
-- 
2.17.1

[dpdk-dev] [PATCH v1 0/4] Remove RTE_MACHINE_CPUFLAG_ macros

[Radu Nicolau]

Remove RTE_MACHINE_CPUFLAG_ macros from the build.
Deprecation notice sent, pasted here for reference:

  build macros: The macros defining RTE_MACHINE_CPUFLAG_* will be removed
  from the build. The information provided by these macros is available
  through standard compiler macros. For example, RTE_MACHINE_CPUFLAG_SSE3
  duplicates the compiler-provided macro __SSE3__.

Radu Nicolau (4):
  x86: change cpuflag macros to compiler macros
  arm: change cpuflag macros to compiler macros
  ppc: change cpuflag macros to compiler macros
  doc: remove reference to RTE_MACHINE_CPUFLAG

 app/test-pmd/macswap.c   |  2 +-
 app/test/test_memcpy_perf.c  |  8 
 config/arm/meson.build   |  6 --
 config/ppc/meson.build   |  2 --
 config/x86/meson.build   |  2 --
 doc/guides/prog_guide/writing_efficient_code.rst |  2 +-
 drivers/net/enic/Makefile|  2 +-
 drivers/net/enic/meson.build |  2 +-
 drivers/net/i40e/Makefile|  2 +-
 drivers/net/i40e/meson.build |  2 +-
 drivers/net/iavf/Makefile|  2 +-
 drivers/net/iavf/meson.build |  2 +-
 drivers/net/ice/Makefile |  2 +-
 drivers/net/ice/meson.build  |  2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c |  2 +-
 examples/l3fwd/l3fwd.h   |  2 +-
 examples/l3fwd/l3fwd_em.c| 16 
 examples/l3fwd/l3fwd_em_hlm.h|  2 +-
 examples/l3fwd/l3fwd_em_sequential.h |  2 +-
 examples/l3fwd/l3fwd_lpm.c   |  6 +++---
 lib/librte_acl/Makefile  |  2 +-
 lib/librte_acl/meson.build   |  2 +-
 lib/librte_eal/arm/include/rte_memcpy_32.h   |  2 +-
 lib/librte_eal/common/rte_random.c   |  4 ++--
 lib/librte_eal/x86/include/rte_memcpy.h  |  8 
 lib/librte_efd/rte_efd_x86.h |  2 +-
 lib/librte_hash/Makefile |  2 +-
 lib/librte_hash/rte_cuckoo_hash.c|  4 ++--
 lib/librte_hash/rte_hash_crc.h   |  2 +-
 lib/librte_hash/rte_thash.h  |  4 ++--
 lib/librte_member/rte_member.h   |  2 +-
 lib/librte_member/rte_member_ht.c| 10 +-
 lib/librte_member/rte_member_x86.h   |  2 +-
 lib/librte_net/rte_net_crc.c |  4 ++--
 lib/librte_node/ip4_lookup.c |  2 +-
 lib/librte_sched/rte_sched.c |  2 +-
 lib/librte_table/rte_lru_arm64.h |  2 +-
 lib/librte_table/rte_table_hash_func.h   |  2 +-
 mk/rte.cpuflags.mk   |  1 -
 39 files changed, 58 insertions(+), 69 deletions(-)

-- 
2.17.1

Re: [dpdk-dev] [PATCH v1 1/4] example/qos_sched: subport bandwidth dynmaic conf

[Dharmappa, Savinay]

Self NACK the patch. As I would like to merge the application series changes of 
patch with previous sent library changes patches series and have single patch 
series.

Regards
savinay

-Original Message-
From: Dharmappa, Savinay  
Sent: Wednesday, September 2, 2020 2:37 PM
To: Dumitrescu, Cristian ; Singh, Jasvinder 
; dev@dpdk.org
Cc: Dharmappa, Savinay 
Subject: [PATCH v1 1/4] example/qos_sched: subport bandwidth dynmaic conf

qos sched application uses the new apis introduced as part of dynamic 
configuration of subport bandwidth to configure the deafult subport bandwidth 
profile while buidling the hirerachical scheduler.

Signed-off-by: Savinay Dharmappa 
---
 examples/qos_sched/cfg_file.c  | 158 -
 examples/qos_sched/cfg_file.h  |   4 ++
 examples/qos_sched/init.c  |  24 +--
 examples/qos_sched/main.h  |   1 +
 examples/qos_sched/profile.cfg |   3 +
 5 files changed, 120 insertions(+), 70 deletions(-)

diff --git a/examples/qos_sched/cfg_file.c b/examples/qos_sched/cfg_file.c 
index f078e4f..9e1341c 100644
--- a/examples/qos_sched/cfg_file.c
+++ b/examples/qos_sched/cfg_file.c
@@ -53,8 +53,11 @@ cfg_load_pipe(struct rte_cfgfile *cfg, struct 
rte_sched_pipe_params *pipe_params
if (!cfg || !pipe_params)
return -1;
 
-   profiles = rte_cfgfile_num_sections(cfg, "pipe profile", sizeof("pipe 
profile") - 1);
-   subport_params[0].n_pipe_profiles = profiles;
+   profiles = rte_cfgfile_num_sections(cfg, "pipe profile",
+   sizeof("pipe profile") - 1);
+   port_params.n_subport_profiles = profiles;
+
+   printf(" profiles = %d", profiles);
 
for (j = 0; j < profiles; j++) {
char pipe_name[32];
@@ -143,6 +146,93 @@ cfg_load_pipe(struct rte_cfgfile *cfg, struct 
rte_sched_pipe_params *pipe_params  }
 
 int
+cfg_load_subport_profile(struct rte_cfgfile *cfg,
+   struct rte_sched_subport_profile_params *subport_profile) {
+   int i;
+   const char *entry;
+   int profiles;
+
+   if (!cfg || !subport_profile)
+   return -1;
+
+   profiles = rte_cfgfile_num_sections(cfg, "subport profile",
+  sizeof("subport profile") - 1);
+   subport_params[0].n_pipe_profiles = profiles;
+
+   for (i = 0; i < profiles; i++) {
+   char sec_name[32];
+   snprintf(sec_name, sizeof(sec_name), "subport profile %d", i);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tb rate");
+   if (entry)
+   subport_profile[i].tb_rate = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tb size");
+   if (entry)
+   subport_profile[i].tb_size = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc period");
+   if (entry)
+   subport_profile[i].tc_period = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 0 rate");
+   if (entry)
+   subport_profile[i].tc_rate[0] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 1 rate");
+   if (entry)
+   subport_profile[i].tc_rate[1] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 2 rate");
+   if (entry)
+   subport_profile[i].tc_rate[2] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 3 rate");
+   if (entry)
+   subport_profile[i].tc_rate[3] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 4 rate");
+   if (entry)
+   subport_profile[i].tc_rate[4] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 5 rate");
+   if (entry)
+   subport_profile[i].tc_rate[5] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 6 rate");
+   if (entry)
+   subport_profile[i].tc_rate[6] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 7 rate");
+   if (entry)
+   subport_profile[i].tc_rate[7] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 8 rate");
+   if (entry)
+   subport_profile[i].tc_rate[8] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 9 rate");
+   if (entry)
+   subport_profile[i].tc_rate[9] = (uint64_t)atoi(entry);
+
+   entry = rte_cfgfile_get_entry(cfg, sec_name, "tc 10 rate");
+   if (entry)
+  

Re: [dpdk-dev] [EXTERNAL] 19.11.4 patches review and test

[Luca Boccassi]

On Tue, 2020-09-01 at 18:04 +, Abhishek Marathe wrote:
> Hi Luca,
> 
> We have tested 19.11.4 and no issues found except known issues.
> 1. Issue with CX-3/MLX-4 driver with ibquery_pkey() failed.
> 2. Issue with hot-removal of VF driver.
> we are tracking both the issues.

Thank you!

Are these two issues new regressions since 19.11.3, or are they pre-
existing?
Should the release be held back until an initial assessment is done?

> Report:
> 
> DPDK 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.dpdk.org%2Fdpdk-stable%2Fsnapshot%2Fdpdk-stable-19.11.4-rc1.tar.gz&data=02%7C01%7CAbhishek.Marathe%40microsoft.com%7C13a3a60691b8456980f908d84d456776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637344307771913541&sdata=8oLAs5j%2BrEF%2BPHMBM036ZgPf2nlooe25daKwXT2YVvs%3D&reserved=0
>  was validated on Azure for RedHat RHEL 7.5 latest, Openlogic CentOS 7.5 
> latest, Ubuntu 18.04, Ubuntu 16.04.
> Tested with Mellanox and netvsc poll-mode drivers.
> The tests were executed using LISAv2 framework 
> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLIS%2FLISAv2&data=02%7C01%7CAbhishek.Marathe%40microsoft.com%7C13a3a60691b8456980f908d84d456776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637344307771913541&sdata=GNF1xf97D2LxyLYJYmDa%2BRoWNqGfItD3D3OjVhp6HRA%3D&reserved=0).
> 
> Test case description:
> 
> * VERIFY-DPDK-COMPLIANCE - verifies kernel is supported and that the build is 
> successful
> * VERIFY-DPDK-BUILD-AND-TESTPMD-TEST - verifies using testpmd that packets 
> can be sent from a VM to another VM
> * VERIFY-SRIOV-FAILSAFE-FOR-DPDK - disables/enables Accelerated Networking 
> for the NICs under test and makes sure DPDK works in both scenarios
> 
> * PERF-DPDK-FWD-PPS-DS15 - verifies DPDK forwarding performance using testpmd 
> on 2, 4, 8 cores, rx and io mode on size Standard_DS15_v2
> * PERF-DPDK-SINGLE-CORE-PPS-DS4 - verifies DPDK performance using testpmd on 
> 1 core, rx and io mode on size Standard_DS4_v2
> * PERF-DPDK-MULTICORE-PPS-DS15 - verifies DPDK performance using testpmd on 
> 2, 4, 8 cores, rx and io mode on size Standard_DS15_v2
> 
> * DPDK-RING-LATENCY - verifies DPDK CPU latency using 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshemminger%2Fdpdk-ring-ping.git&data=02%7C01%7CAbhishek.Marathe%40microsoft.com%7C13a3a60691b8456980f908d84d456776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637344307771913541&sdata=znhtFXLZiKaadAJKKLghm9NWvdRUvYZx2xLtIf0r15A%3D&reserved=0
> * VERIFY-DPDK-PRIMARY-SECONDARY-PROCESSES - verifies primary / secondary 
> processes support for DPDK. Runs only on RHEL and Ubuntu distros with Linux 
> kernel >= 4.20
> 
> * VERIFY-DPDK-OVS - builds OVS with DPDK support and tests if the OVS DPDK 
> ports can be created. Runs only on Ubuntu distro.
> * VERIFY-DPDK-VPP - builds VPP with DPDK support and tests if the VPP ports 
> are present. Runs only on RHEL and Ubuntu distros.
> * VERIFY-DPDK-NFF-GO - builds NFF-GO with DPDK support and runs the 
> functional tests from the NFF-GO repository. Runs only on Ubuntu distro.
> 
> Ubuntu 16.04: Pass
> Ubuntu 18.04: Pass
> RHEL 7.5: Pass
> CentOS 7.5: Pass
> 
> Regards,
> Abhishek
> -Original Message-
> From: Luca Boccassi  
> Sent: Tuesday, August 18, 2020 11:12 AM
> To: sta...@dpdk.org
> Cc: dev@dpdk.org; Abhishek Marathe ; Akhil 
> Goyal ; Ali Alnubani ; 
> benjamin.wal...@intel.com; David Christensen ; 
> Hemant Agrawal ; Ian Stokes ; 
> Jerin Jacob ; John McNamara ; 
> Ju-Hyoung Lee ; Kevin Traynor ; 
> Pei Zhang ; pingx...@intel.com; qian.q...@intel.com; 
> Raslan Darawsheh ; Thomas Monjalon 
> ; yuan.p...@intel.com; zhaoyan.c...@intel.com
> Subject: [EXTERNAL] 19.11.4 patches review and test
> 
> Hi all,
> 
> Here is a list of patches targeted for stable release 19.11.4.
> 
> The planned date for the final release is August 31st.
> 
> Please help with testing and validation of your use cases and report any 
> issues/results with reply-all to this mail. For the final release the fixes 
> and reported validations will be added to the release notes.
> 
> A release candidate tarball can be found at:
> 
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdpdk.org%2Fbrowse%2Fdpdk-stable%2Ftag%2F%3Fid%3Dv19.11.4-rc1&data=02%7C01%7CAbhishek.Marathe%40microsoft.com%7C5f6c5d506f3d439b1d1a08d843a24469%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333711526043405&sdata=LkqDTW1b6u1Q0S4ZJvRGzhG4XL2PG%2FSmikz7jR6iurI%3D&reserved=0
> 
> These patches are located at branch 19.11 of dpdk-stable repo:
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdpdk.org%2Fbrowse%2Fdpdk-stable%2F&data=02%7C01%7CAbhishek.Marathe%40microsoft.com%7C5f6c5d506f3d439b1d1a08d843a24469%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333711526053410&sdata=nLx7HUHx412XMexrqfAaIxUzK7ko%2BAq8OKakVglimEQ%3D&reserved=0
> 
> Thanks.
> 
> Luca Boccassi
> 
> ---
> Adam Dybkowski (7):
>   test/crypto: fix asymmet

Re: [dpdk-dev] [PATCH v2 17/17] net: add checks for max SIMD bitwidth

[Singh, Jasvinder]

> -Original Message-
> From: Power, Ciara 
> Sent: Thursday, August 27, 2020 5:13 PM
> To: dev@dpdk.org
> Cc: Power, Ciara ; Singh, Jasvinder
> ; Olivier Matz 
> Subject: [PATCH v2 17/17] net: add checks for max SIMD bitwidth
> 
> When choosing a vector path to take, an extra condition must be satisfied to
> ensure the max SIMD bitwidth allows for the CPU enabled path. This check is
> done just before the handler is called, it cannot be done when setting the
> handlers initially as the EAL max simd bitwidth value has not yet been set.
> 
> Cc: Jasvinder Singh 
> 
> Signed-off-by: Ciara Power 
> ---
>  lib/librte_net/rte_net_crc.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/lib/librte_net/rte_net_crc.c b/lib/librte_net/rte_net_crc.c index
> 9fd4794a9d..d3d3206919 100644
> --- a/lib/librte_net/rte_net_crc.c
> +++ b/lib/librte_net/rte_net_crc.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #if defined(RTE_ARCH_X86_64) &&
> defined(RTE_MACHINE_CPUFLAG_PCLMULQDQ)
>  #define X86_64_SSE42_PCLMULQDQ 1
> @@ -60,6 +61,8 @@ static rte_net_crc_handler handlers_neon[] = {  };
> #endif
> 
> +static uint16_t max_simd_bitwidth;
> +
>  /**
>   * Reflect the bits about the middle
>   *
> @@ -175,6 +178,11 @@ rte_net_crc_calc(const void *data,
>   uint32_t ret;
>   rte_net_crc_handler f_handle;
> 
> + if (max_simd_bitwidth == 0)
> + max_simd_bitwidth = rte_get_max_simd_bitwidth();
> + if (max_simd_bitwidth < RTE_MAX_128_SIMD &&
> + handlers != handlers_scalar)
> + rte_net_crc_set_alg(RTE_NET_CRC_SCALAR);


Above change doesn't seem right as rte_net_crc_set_alg () is invoked everytime 
when crc is computed. It potentially adds branches in runtime.  In my opinion,  
bit width should be checked inside rte_net_crc_set_alg () function which is 
supposed to be used during initialization stage after eal sets the max simd bit 
width. 

>   f_handle = handlers[type];
>   ret = f_handle(data, data_len);
> 
> --
> 2.17.1

Re: [dpdk-dev] [PATCH v2 35/37] doc: remove reference to make in tools guides

[Laatz, Kevin]

On 20/08/2020 13:41, Ciara Power wrote:

Make is no longer supported for compiling DPDK, references are now
removed in the documentation.

Signed-off-by: Ciara Power 
---
  doc/guides/tools/comp_perf.rst| 10 ++---
  doc/guides/tools/cryptoperf.rst   | 20 +++--
  doc/guides/tools/pdump.rst| 15 ++---
  doc/guides/tools/proc_info.rst|  2 +-
  doc/guides/tools/testbbdev.rst| 36 +--
  doc/guides/tools/testeventdev.rst | 21 --
  6 files changed, 31 insertions(+), 73 deletions(-)


Reviewed-by: Kevin Laatz 

Re: [dpdk-dev] [PATCH v2 36/37] doc: remove references to make in testpmd guides

[Laatz, Kevin]

On 20/08/2020 13:41, Ciara Power wrote:

Make is no longer supported for compiling DPDK, references are now
removed in the documentation.

Signed-off-by: Ciara Power 
---
  doc/guides/testpmd_app_ug/run_app.rst   | 6 +++---
  doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 +
  2 files changed, 4 insertions(+), 11 deletions(-)




diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 90cf252df5..f0d838321c 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -71,7 +71,7 @@ practical or possible testpmd supports alternative methods 
for executing command
  
  .. code-block:: console
  
-   ./testpmd -n4 -r2 ... -- -i --cmdline-file=/home/ubuntu/flow-create-commands.txt

+   ./dpdk-testpmd -n4 -r2 ... -- -i 
--cmdline-file=/home/ubuntu/flow-create-commands.txt
 Interactive-mode selected
 CLI commands to be read from /home/ubuntu/flow-create-commands.txt
 Configuring Port 0 (socket 0)
@@ -329,8 +329,6 @@ The available information categories are:
  
  * ``icmpecho``: Receives a burst of packets, lookup for ICMP echo requests and, if any, send back ICMP echo replies.
  
-* ``ieee1588``: Demonstrate L2 IEEE1588 V2 PTP timestamping for RX and TX. Requires ``CONFIG_RTE_LIBRTE_IEEE1588=y``.

-
The support for ieee1588 info is not being removed, this line should 
stay in the documentation. Just remove the "CONFIG..." part.

LGTM other than that.

Reviewed-by: Kevin Laatz 

Re: [dpdk-dev] [PATCH v2 37/37] doc: update quick build doc to remove make references

[Laatz, Kevin]

On 20/08/2020 13:41, Ciara Power wrote:

Make is no longer supported for compiling DPDK, references are now
removed in the documentation.

Signed-off-by: Ciara Power 
---
  doc/build-sdk-quick.txt | 55 -
  1 file changed, 21 insertions(+), 34 deletions(-)


Reviewed-by: Kevin Laatz 

Re: [dpdk-dev] [RFC] avoid libfdt checks adding full paths to pkg-config

[Christian Ehrhardt]

On Tue, Sep 1, 2020 at 6:16 PM Luca Boccassi  wrote:
>
> On Tue, 2020-09-01 at 17:58 +0200, Christian Ehrhardt wrote:
> > The checks for libfdt try dependency() first which would only work if
> > a pkg-config would be present but libfdt has none.
> > Then it probes for the lib path itself via cc.find_library.
> >
> > But later it adds the result of either probe to ext_deps which ends up
> > in build and also the resulting pkg-config to contain toolchain versioned
> > paths in Libs.private like:
> >   /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libfdt.so
> > which obviously breaks on toolchain updates.
> >
> > In general libs used multiple times - ipn3ke + ifpga in this case - are
> > checked centrally in config/meson.build so move it there and fix the
> > adding of dependencies to not use the full file path.
> >
> > The result is libfdt in pkg-config now showing up as:
> >   Libs.private: -pthread -lm -ldl -lnuma -lfdt -lpcap
> >
> > Signed-off-by: Christian Ehrhardt 
> > ---
> >  config/meson.build | 9 +
> >  drivers/net/ipn3ke/meson.build | 6 +-
> >  drivers/raw/ifpga/meson.build  | 7 +--
> >  3 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/config/meson.build b/config/meson.build
> > index cff8b33dd2..1c8317e750 100644
> > --- a/config/meson.build
> > +++ b/config/meson.build
> > @@ -150,6 +150,15 @@ if numa_dep.found() and cc.has_header('numaif.h')
> >   dpdk_extra_ldflags += '-lnuma'
> >  endif
> >
> > +has_libfdt = 0
> > +fdt_dep = cc.find_library('libfdt', required: false)
> > +if fdt_dep.found() and cc.has_header('fdt.h')
> > + dpdk_conf.set10('RTE_HAS_LIBFDT', true)
> > + has_libfdt = 1
> > + add_project_link_arguments('-lfdt', language: 'c')
> > + dpdk_extra_ldflags += '-lfdt'
> > +endif
> > +
> >  # check for libbsd
> >  libbsd = dependency('libbsd', required: false)
> >  if libbsd.found()
> > diff --git a/drivers/net/ipn3ke/meson.build b/drivers/net/ipn3ke/meson.build
> > index ec9cb7daf0..de6e03ca65 100644
> > --- a/drivers/net/ipn3ke/meson.build
> > +++ b/drivers/net/ipn3ke/meson.build
> > @@ -9,11 +9,7 @@
> >  #  rte_eth_switch_domain_free()
> >  #
> >
> > -dep = dependency('libfdt', required: false)
> > -if not dep.found()
> > - dep = cc.find_library('libfdt', required: false)
> > -endif
> > -if not dep.found()
> > +if has_libnuma == 0
> >   build = false
> >   reason = 'missing dependency, "libfdt"'
> >   subdir_done()
> > diff --git a/drivers/raw/ifpga/meson.build b/drivers/raw/ifpga/meson.build
> > index 05a1711b5d..d4a128d67e 100644
> > --- a/drivers/raw/ifpga/meson.build
> > +++ b/drivers/raw/ifpga/meson.build
> > @@ -1,11 +1,7 @@
> >  # SPDX-License-Identifier: BSD-3-Clause
> >  # Copyright(c) 2018 Intel Corporation
> >
> > -dep = dependency('libfdt', required: false)
> > -if not dep.found()
> > - dep = cc.find_library('libfdt', required: false)
> > -endif
> > -if not dep.found()
> > +if has_libnuma == 0
>
> if has_libfdt == 0 ? Same above
>
> >   build = false
> >   reason = 'missing dependency, "libfdt"'
> >   subdir_done()
> > @@ -16,7 +12,6 @@ objs = [base_objs]
> >
> >  deps += ['ethdev', 'rawdev', 'pci', 'bus_pci', 'kvargs',
> >   'bus_vdev', 'bus_ifpga', 'net', 'pmd_i40e', 'pmd_ipn3ke']
> > -ext_deps += dep
> >
> >  sources = files('ifpga_rawdev.c')
>
> With the above correction, LGTM.
>
> Reviewed-by: Luca Boccassi 

Fixed and thanks Luca!
CI pipeline (Debian) is happy now.

I added your Reviewed-by and added Thomas/Bruce on --to since they
last modified these files on various meson cleanups.
Will resend the patch as non-RFC with those changes any minute ...

> --
> Kind regards,
> Luca Boccassi



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

[dpdk-dev] [PATCH] avoid libfdt checks adding full paths to pkg-config

[Christian Ehrhardt]

The checks for libfdt try dependency() first which would only work if
a pkg-config would be present but libfdt has none.
Then it probes for the lib path itself via cc.find_library.

But later it adds the result of either probe to ext_deps which ends up
in build and also the resulting pkg-config to contain toolchain versioned
paths in Libs.private like:
  /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libfdt.so
which obviously breaks on toolchain updates.

In general libs used multiple times - ipn3ke + ifpga in this case - are
checked centrally in config/meson.build so move it there and fix the
adding of dependencies to not use the full file path.

The result is libfdt in pkg-config now showing up as:
  Libs.private: -pthread -lm -ldl -lnuma -lfdt -lpcap

Signed-off-by: Christian Ehrhardt 
Reviewed-by: Luca Boccassi 
---
 config/meson.build | 9 +
 drivers/net/ipn3ke/meson.build | 6 +-
 drivers/raw/ifpga/meson.build  | 7 +--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/config/meson.build b/config/meson.build
index cff8b33dd2..1c8317e750 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -150,6 +150,15 @@ if numa_dep.found() and cc.has_header('numaif.h')
dpdk_extra_ldflags += '-lnuma'
 endif
 
+has_libfdt = 0
+fdt_dep = cc.find_library('libfdt', required: false)
+if fdt_dep.found() and cc.has_header('fdt.h')
+   dpdk_conf.set10('RTE_HAS_LIBFDT', true)
+   has_libfdt = 1
+   add_project_link_arguments('-lfdt', language: 'c')
+   dpdk_extra_ldflags += '-lfdt'
+endif
+
 # check for libbsd
 libbsd = dependency('libbsd', required: false)
 if libbsd.found()
diff --git a/drivers/net/ipn3ke/meson.build b/drivers/net/ipn3ke/meson.build
index ec9cb7daf0..d5000d807c 100644
--- a/drivers/net/ipn3ke/meson.build
+++ b/drivers/net/ipn3ke/meson.build
@@ -9,11 +9,7 @@
 #  rte_eth_switch_domain_free()
 #
 
-dep = dependency('libfdt', required: false)
-if not dep.found()
-   dep = cc.find_library('libfdt', required: false)
-endif
-if not dep.found()
+if has_libfdt == 0
build = false
reason = 'missing dependency, "libfdt"'
subdir_done()
diff --git a/drivers/raw/ifpga/meson.build b/drivers/raw/ifpga/meson.build
index 05a1711b5d..da454b1942 100644
--- a/drivers/raw/ifpga/meson.build
+++ b/drivers/raw/ifpga/meson.build
@@ -1,11 +1,7 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2018 Intel Corporation
 
-dep = dependency('libfdt', required: false)
-if not dep.found()
-   dep = cc.find_library('libfdt', required: false)
-endif
-if not dep.found()
+if has_libfdt == 0
build = false
reason = 'missing dependency, "libfdt"'
subdir_done()
@@ -16,7 +12,6 @@ objs = [base_objs]
 
 deps += ['ethdev', 'rawdev', 'pci', 'bus_pci', 'kvargs',
'bus_vdev', 'bus_ifpga', 'net', 'pmd_i40e', 'pmd_ipn3ke']
-ext_deps += dep
 
 sources = files('ifpga_rawdev.c')
 
-- 
2.28.0

Re: [dpdk-dev] [PATCH v1 1/4] x86: change cpuflag macros to compiler macros

[Bruce Richardson]

On Wed, Sep 02, 2020 at 10:43:40AM +, Radu Nicolau wrote:
> Replace use of RTE_MACHINE_CPUFLAG macros with regular compiler
> macros.
> 

I think it's worth noting in the commit log that the set of macros provided
by the compilers are more complete than those provided by DPDK, and by not
having our own it allows new instruction sets to be leveraged without
having to do extra work to set them up in DPDK.

> Signed-off-by: Sean Morrissey 
> Signed-off-by: Radu Nicolau 
> ---
>  app/test/test_memcpy_perf.c |  8 
>  config/x86/meson.build  |  2 --
>  drivers/net/enic/Makefile   |  2 +-
>  drivers/net/enic/meson.build|  2 +-
>  drivers/net/i40e/Makefile   |  2 +-
>  drivers/net/i40e/meson.build|  2 +-
>  drivers/net/iavf/Makefile   |  2 +-
>  drivers/net/iavf/meson.build|  2 +-
>  drivers/net/ice/Makefile|  2 +-
>  drivers/net/ice/meson.build |  2 +-
>  examples/l3fwd/l3fwd_em.c   |  4 ++--
>  lib/librte_acl/Makefile |  2 +-
>  lib/librte_acl/meson.build  |  2 +-
>  lib/librte_eal/common/rte_random.c  |  4 ++--
>  lib/librte_eal/x86/include/rte_memcpy.h |  8 
>  lib/librte_efd/rte_efd_x86.h|  2 +-
>  lib/librte_hash/rte_cuckoo_hash.c   |  2 +-
>  lib/librte_member/rte_member_ht.c   | 10 +-
>  lib/librte_member/rte_member_x86.h  |  2 +-
>  lib/librte_net/rte_net_crc.c|  2 +-
>  mk/rte.cpuflags.mk  |  1 -
>  21 files changed, 31 insertions(+), 34 deletions(-)
> 

> @@ -231,7 +231,7 @@ em_mask_key(void *key, xmm_t mask)
>  
>   return vandq_s32(data, mask);
>  }
> -#elif defined(RTE_MACHINE_CPUFLAG_ALTIVEC)
> +#elif defined(__ALTIVEC__)

Not an x86 flag. Belongs in patch 3.

>  static inline xmm_t
>  em_mask_key(void *key, xmm_t mask)
>  {
> diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
> index f4332b044..3b591c2ed 100644
> --- a/lib/librte_acl/Makefile
> +++ b/lib/librte_acl/Makefile
> @@ -38,7 +38,7 @@ endif
>  #
>  
>  #check if flag for AVX2 is already on, if not set it up manually
> -ifeq ($(findstring 
> RTE_MACHINE_CPUFLAG_AVX2,$(CFLAGS)),RTE_MACHINE_CPUFLAG_AVX2)
> +ifneq ($(filter $(AUTO_CPUFLAGS),__AVX2__),)
>   CC_AVX2_SUPPORT=1
>  else
>   CC_AVX2_SUPPORT=\
> diff --git a/lib/librte_acl/meson.build b/lib/librte_acl/meson.build
> index d1e2c184c..b31a3f798 100644
> --- a/lib/librte_acl/meson.build
> +++ b/lib/librte_acl/meson.build
> @@ -15,7 +15,7 @@ if dpdk_conf.has('RTE_ARCH_X86')
>   # in former case, just add avx2 C file to files list
>   # in latter case, compile c file to static lib, using correct compiler
>   # flags, and then have the .o file from static lib linked into main lib.
> - if dpdk_conf.has('RTE_MACHINE_CPUFLAG_AVX2')
> + if cc.get_define('__AVX2__', args: machine_args) != ''

Since this is used in a number of places, we probably should just get the
result in a variable in config/x86/meson.build.

>   sources += files('acl_run_avx2.c')
>   cflags += '-DCC_AVX2_SUPPORT'
>   elif cc.has_argument('-mavx2')

Re: [dpdk-dev] [PATCH v2 0/7] Enhance rawdev APIs

[Nipun Gupta]

Series
Acked-by: Nipun Gupta 

> -Original Message-
> From: Bruce Richardson 
> Sent: Thursday, August 13, 2020 4:58 PM
> To: Nipun Gupta ; Hemant Agrawal
> 
> Cc: dev@dpdk.org; Bruce Richardson 
> Subject: [PATCH v2 0/7] Enhance rawdev APIs
> 
> This patchset proposes some internal and externally-visible changes to the
> rawdev API, the ABI change of which were previously announced.
> 
> The changes are in two main areas:
> * For any APIs which take a void * parameter for driver-specific structs,
>   add an additional parameter to provide the struct length. This allows
>   some runtime type-checking, as well as possible ABI-compatibility support
>   in the future as structure change generally involve a change in the size
>   of the structure.
> * Ensure all APIs which can return error values have int type, rather than
>   void. Since functions like info_get and queue_default_get can now do some
>   typechecking, they need to be modified to allow them to return error
>   codes on failure.
> 
> V2:
>   - add additional patch to make start/stop functions optional
>   - remove deprecation notice once changes applied
> 
> Bruce Richardson (7):
>   rawdev: add private data length parameter to info fn
>   rawdev: allow drivers to return error from info function
>   rawdev: add private data length parameter to config fn
>   rawdev: add private data length parameter to queue fns
>   rawdev: allow queue default config query to return error
>   rawdev: mark start and stop functions optional
>   doc: remove rawdev deprecation notice
> 
>  app/test/test_rawdev.c  |  2 +-
>  doc/guides/rawdevs/ioat.rst |  4 +-
>  doc/guides/rawdevs/octeontx2_dma.rst|  2 +-
>  doc/guides/rawdevs/octeontx2_ep.rst |  3 +-
>  doc/guides/rel_notes/deprecation.rst|  7 ---
>  doc/guides/sample_app_ug/ioat.rst   |  4 +-
>  drivers/bus/ifpga/ifpga_bus.c   |  2 +-
>  drivers/raw/ifpga/ifpga_rawdev.c| 23 +-
>  drivers/raw/ioat/ioat_rawdev.c  | 17 ---
>  drivers/raw/ioat/ioat_rawdev_test.c |  6 +--
>  drivers/raw/ntb/ntb.c   | 49 -
>  drivers/raw/octeontx2_dma/otx2_dpi_rawdev.c |  7 +--
>  drivers/raw/octeontx2_dma/otx2_dpi_test.c   |  3 +-
>  drivers/raw/octeontx2_ep/otx2_ep_rawdev.c   |  7 +--
>  drivers/raw/octeontx2_ep/otx2_ep_test.c |  2 +-
>  drivers/raw/skeleton/skeleton_rawdev.c  | 36 +--
>  drivers/raw/skeleton/skeleton_rawdev_test.c | 32 --
>  examples/ioat/ioatfwd.c |  4 +-
>  examples/ntb/ntb_fwd.c  |  7 +--
>  lib/librte_rawdev/rte_rawdev.c  | 47 +---
>  lib/librte_rawdev/rte_rawdev.h  | 27 ++--
>  lib/librte_rawdev/rte_rawdev_pmd.h  | 22 ++---
>  22 files changed, 201 insertions(+), 112 deletions(-)
> 
> --
> 2.25.1

Re: [dpdk-dev] [PATCH v1 4/4] doc: remove reference to RTE_MACHINE_CPUFLAG

[Bruce Richardson]

On Wed, Sep 02, 2020 at 10:43:43AM +, Radu Nicolau wrote:
> RTE_MACHINE_CPUFLAG macros are replaced with predefined
> compiler defines.
> 
> Signed-off-by: Sean Morrissey 
> Signed-off-by: Radu Nicolau 
> ---
>  doc/guides/prog_guide/writing_efficient_code.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/guides/prog_guide/writing_efficient_code.rst 
> b/doc/guides/prog_guide/writing_efficient_code.rst
> index 2639ef7bf..c1f2d627a 100644
> --- a/doc/guides/prog_guide/writing_efficient_code.rst
> +++ b/doc/guides/prog_guide/writing_efficient_code.rst
> @@ -273,5 +273,5 @@ main() function and checks if the current machine is 
> suitable for running the bi
>  Along with compiler optimizations,
>  a set of preprocessor defines are automatically added to the build process 
> (regardless of the compiler version).
>  These defines correspond to the instruction sets that the target CPU should 
> be able to support.
> -For example, a binary compiled for any SSE4.2-capable processor will have 
> RTE_MACHINE_CPUFLAG_SSE4_2 defined,
> +For example, a binary compiled for any SSE4.2-capable processor will have a 
> pre-defined compiler macro,
>  thus enabling compile-time code path selection for different platforms.
> -- 
Personally, I'd suggest just removing the whole section rather than part of
a single line.

Re: [dpdk-dev] [PATCH] avoid libfdt checks adding full paths to pkg-config

[Bruce Richardson]

On Wed, Sep 02, 2020 at 01:10:30PM +0200, Christian Ehrhardt wrote:
> The checks for libfdt try dependency() first which would only work if
> a pkg-config would be present but libfdt has none.
> Then it probes for the lib path itself via cc.find_library.
> 
> But later it adds the result of either probe to ext_deps which ends up
> in build and also the resulting pkg-config to contain toolchain versioned
> paths in Libs.private like:
>   /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libfdt.so
> which obviously breaks on toolchain updates.
> 
> In general libs used multiple times - ipn3ke + ifpga in this case - are
> checked centrally in config/meson.build so move it there and fix the
> adding of dependencies to not use the full file path.
> 
> The result is libfdt in pkg-config now showing up as:
>   Libs.private: -pthread -lm -ldl -lnuma -lfdt -lpcap
> 
> Signed-off-by: Christian Ehrhardt 
> Reviewed-by: Luca Boccassi 
> ---
>  config/meson.build | 9 +
>  drivers/net/ipn3ke/meson.build | 6 +-
>  drivers/raw/ifpga/meson.build  | 7 +--
>  3 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/config/meson.build b/config/meson.build
> index cff8b33dd2..1c8317e750 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -150,6 +150,15 @@ if numa_dep.found() and cc.has_header('numaif.h')
>   dpdk_extra_ldflags += '-lnuma'
>  endif
>  
> +has_libfdt = 0
> +fdt_dep = cc.find_library('libfdt', required: false)
> +if fdt_dep.found() and cc.has_header('fdt.h')
> + dpdk_conf.set10('RTE_HAS_LIBFDT', true)
> + has_libfdt = 1
> + add_project_link_arguments('-lfdt', language: 'c')
> + dpdk_extra_ldflags += '-lfdt'
> +endif
> +
>  # check for libbsd
>  libbsd = dependency('libbsd', required: false)
>  if libbsd.found()
> diff --git a/drivers/net/ipn3ke/meson.build b/drivers/net/ipn3ke/meson.build
> index ec9cb7daf0..d5000d807c 100644
> --- a/drivers/net/ipn3ke/meson.build
> +++ b/drivers/net/ipn3ke/meson.build
> @@ -9,11 +9,7 @@
>  #  rte_eth_switch_domain_free()
>  #
>  
> -dep = dependency('libfdt', required: false)
> -if not dep.found()
> - dep = cc.find_library('libfdt', required: false)
> -endif
> -if not dep.found()
> +if has_libfdt == 0

Minor nit, for readability, I'd suggest using "not has_libfdt", but what is
here can work too.

>   build = false
>   reason = 'missing dependency, "libfdt"'
>   subdir_done()
> diff --git a/drivers/raw/ifpga/meson.build b/drivers/raw/ifpga/meson.build
> index 05a1711b5d..da454b1942 100644
> --- a/drivers/raw/ifpga/meson.build
> +++ b/drivers/raw/ifpga/meson.build
> @@ -1,11 +1,7 @@
>  # SPDX-License-Identifier: BSD-3-Clause
>  # Copyright(c) 2018 Intel Corporation
>  
> -dep = dependency('libfdt', required: false)
> -if not dep.found()
> - dep = cc.find_library('libfdt', required: false)
> -endif
> -if not dep.found()
> +if has_libfdt == 0
>   build = false
>   reason = 'missing dependency, "libfdt"'
>   subdir_done()
> @@ -16,7 +12,6 @@ objs = [base_objs]
>  
>  deps += ['ethdev', 'rawdev', 'pci', 'bus_pci', 'kvargs',
>   'bus_vdev', 'bus_ifpga', 'net', 'pmd_i40e', 'pmd_ipn3ke']
> -ext_deps += dep
>  
>  sources = files('ifpga_rawdev.c')
>  
> -- 
Reviewed-by: Bruce Richardson 

[dpdk-dev] [PATCH v2] regex/mlx5: add teardown flow to fastpath buffers

[Yuval Avnery]

From: Yuval Avnery 

Added missing code to free Input/Output buffers and memory
registration.
Also added calls to this code in case of error in the qp setup
procedure.
The rollback code itself did not handle rollback properly
and did not check return value from the fastpath setup.

Signed-off-by: Yuval Avnery 
Acked-by: Ori Kam 
---
 drivers/regex/mlx5/mlx5_regex.h  |  2 ++
 drivers/regex/mlx5/mlx5_regex_control.c  | 20 ---
 drivers/regex/mlx5/mlx5_regex_fastpath.c | 33 +++-
 3 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/drivers/regex/mlx5/mlx5_regex.h b/drivers/regex/mlx5/mlx5_regex.h
index 6098fb1..fc0f362 100644
--- a/drivers/regex/mlx5/mlx5_regex.h
+++ b/drivers/regex/mlx5/mlx5_regex.h
@@ -109,6 +109,8 @@ int mlx5_regex_qp_setup(struct rte_regexdev *dev, uint16_t 
qp_ind,
 
 /* mlx5_regex_fastpath.c */
 int mlx5_regexdev_setup_fastpath(struct mlx5_regex_priv *priv, uint32_t qp_id);
+void mlx5_regexdev_teardown_fastpath(struct mlx5_regex_priv *priv,
+uint32_t qp_id);
 uint16_t mlx5_regexdev_enqueue(struct rte_regexdev *dev, uint16_t qp_id,
   struct rte_regex_ops **ops, uint16_t nb_ops);
 uint16_t mlx5_regexdev_dequeue(struct rte_regexdev *dev, uint16_t qp_id,
diff --git a/drivers/regex/mlx5/mlx5_regex_control.c 
b/drivers/regex/mlx5/mlx5_regex_control.c
index faafb76..187c3de 100644
--- a/drivers/regex/mlx5/mlx5_regex_control.c
+++ b/drivers/regex/mlx5/mlx5_regex_control.c
@@ -357,23 +357,29 @@
ret = regex_ctrl_create_cq(priv, &qp->cq);
if (ret) {
DRV_LOG(ERR, "Can't create cq.");
-   goto error;
+   goto err_cq;
}
for (i = 0; i < qp->nb_obj; i++) {
ret = regex_ctrl_create_sq(priv, qp, i, log_desc);
if (ret) {
DRV_LOG(ERR, "Can't create sq.");
-   goto error;
+   goto err_sq;
}
}
 
-   mlx5_regexdev_setup_fastpath(priv, qp_ind);
+   ret = mlx5_regexdev_setup_fastpath(priv, qp_ind);
+   if (ret) {
+   DRV_LOG(ERR, "Fail to setup fastpath.");
+   goto err_fp;
+   }
return 0;
 
-error:
-   regex_ctrl_destroy_cq(priv, &qp->cq);
+err_fp:
for (i = 0; i < qp->nb_obj; i++)
ret = regex_ctrl_destroy_sq(priv, qp, i);
-   return -rte_errno;
-
+err_sq:
+   regex_ctrl_destroy_cq(priv, &qp->cq);
+err_cq:
+   rte_free(qp->sqs);
+   return ret;
 }
diff --git a/drivers/regex/mlx5/mlx5_regex_fastpath.c 
b/drivers/regex/mlx5/mlx5_regex_fastpath.c
index 2c6c9e1..6fafcff 100644
--- a/drivers/regex/mlx5/mlx5_regex_fastpath.c
+++ b/drivers/regex/mlx5/mlx5_regex_fastpath.c
@@ -407,8 +407,39 @@ struct mlx5_regex_job {
if (!qp->jobs)
return -ENOMEM;
err = setup_buffers(qp, priv->pd);
-   if (err)
+   if (err) {
+   rte_free(qp->jobs);
return err;
+   }
setup_sqs(qp);
return 0;
 }
+
+static void
+free_buffers(struct mlx5_regex_qp *qp)
+{
+   if (qp->metadata) {
+   mlx5_glue->dereg_mr(qp->metadata);
+   rte_free(qp->metadata->addr);
+   }
+   if (qp->inputs) {
+   mlx5_glue->dereg_mr(qp->inputs);
+   rte_free(qp->inputs->addr);
+   }
+   if (qp->outputs) {
+   mlx5_glue->dereg_mr(qp->outputs);
+   rte_free(qp->outputs->addr);
+   }
+}
+
+void
+mlx5_regexdev_teardown_fastpath(struct mlx5_regex_priv *priv, uint32_t qp_id)
+{
+   struct mlx5_regex_qp *qp = &priv->qps[qp_id];
+
+   if (qp) {
+   free_buffers(qp);
+   if (qp->jobs)
+   rte_free(qp->jobs);
+   }
+}
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH] doc: update pdump documentation

[Pattan, Reshma]

> -Original Message-
> From: Pattan, Reshma 
> Sent: Monday, July 13, 2020 3:25 PM
> To: dev@dpdk.org
> Cc: Pattan, Reshma 
> Subject: [PATCH] doc: update pdump documentation
> 
> Update the pdump library programmers guide and Howto doc with the use of
> multi process channel replacing socket based communication.
> 
> Signed-off-by: Reshma Pattan 
> ---

Gentle remainder for review and ack on this .

[dpdk-dev] [PATCH] net/nfp: expand dev_infos_get callback function

[Heinrich Kuhn]

Report Rx and Tx descriptor related limitations in the nfp dev_info_get
callback function. This commit also adds NFP_ALIGN_RING_DESC to replace
a static integer value used during rx/tx queue setups to validate
descriptor alignment.

Cc: sta...@dpdk.org

Signed-off-by: Heinrich Kuhn 
Signed-off-by: Simon Horman 
---
 drivers/net/nfp/nfp_net.c | 30 --
 drivers/net/nfp/nfp_net_pmd.h |  6 ++
 2 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 99946279d..0dd594992 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1250,6 +1250,20 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.tx_rs_thresh = DEFAULT_TX_RSBIT_THRESH,
};
 
+   dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
+   .nb_max = NFP_NET_MAX_RX_DESC,
+   .nb_min = NFP_NET_MIN_RX_DESC,
+   .nb_align = NFP_ALIGN_RING_DESC,
+   };
+
+   dev_info->tx_desc_lim = (struct rte_eth_desc_lim) {
+   .nb_max = NFP_NET_MAX_TX_DESC,
+   .nb_min = NFP_NET_MIN_TX_DESC,
+   .nb_align = NFP_ALIGN_RING_DESC,
+   .nb_seg_max = NFP_TX_MAX_SEG,
+   .nb_mtu_seg_max = NFP_TX_MAX_MTU_SEG,
+   };
+
dev_info->flow_type_rss_offloads = ETH_RSS_IPV4 |
   ETH_RSS_NONFRAG_IPV4_TCP |
   ETH_RSS_NONFRAG_IPV4_UDP |
@@ -1513,15 +1527,17 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
const struct rte_memzone *tz;
struct nfp_net_rxq *rxq;
struct nfp_net_hw *hw;
+   uint32_t rx_desc_sz;
 
hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
 
PMD_INIT_FUNC_TRACE();
 
/* Validating number of descriptors */
-   if (((nb_desc * sizeof(struct nfp_net_rx_desc)) % 128) != 0 ||
-   (nb_desc > NFP_NET_MAX_RX_DESC) ||
-   (nb_desc < NFP_NET_MIN_RX_DESC)) {
+   rx_desc_sz = nb_desc * sizeof(struct nfp_net_rx_desc);
+   if (rx_desc_sz % NFP_ALIGN_RING_DESC != 0 ||
+   nb_desc > NFP_NET_MAX_RX_DESC ||
+   nb_desc < NFP_NET_MIN_RX_DESC) {
PMD_DRV_LOG(ERR, "Wrong nb_desc value");
return -EINVAL;
}
@@ -1660,15 +1676,17 @@ nfp_net_tx_queue_setup(struct rte_eth_dev *dev, 
uint16_t queue_idx,
struct nfp_net_txq *txq;
uint16_t tx_free_thresh;
struct nfp_net_hw *hw;
+   uint32_t tx_desc_sz;
 
hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
 
PMD_INIT_FUNC_TRACE();
 
/* Validating number of descriptors */
-   if (((nb_desc * sizeof(struct nfp_net_tx_desc)) % 128) != 0 ||
-   (nb_desc > NFP_NET_MAX_TX_DESC) ||
-   (nb_desc < NFP_NET_MIN_TX_DESC)) {
+   tx_desc_sz = nb_desc * sizeof(struct nfp_net_tx_desc);
+   if (tx_desc_sz % NFP_ALIGN_RING_DESC != 0 ||
+   nb_desc > NFP_NET_MAX_TX_DESC ||
+   nb_desc < NFP_NET_MIN_TX_DESC) {
PMD_DRV_LOG(ERR, "Wrong nb_desc value");
return -EINVAL;
}
diff --git a/drivers/net/nfp/nfp_net_pmd.h b/drivers/net/nfp/nfp_net_pmd.h
index cb2d19afe..1295c5959 100644
--- a/drivers/net/nfp/nfp_net_pmd.h
+++ b/drivers/net/nfp/nfp_net_pmd.h
@@ -33,6 +33,12 @@ struct nfp_net_adapter;
 #define NFP_NET_MAX_RX_DESC (32 * 1024)
 #define NFP_NET_MIN_RX_DESC 64
 
+/* Descriptor alignment */
+#define NFP_ALIGN_RING_DESC 128
+
+#define NFP_TX_MAX_SEG UINT8_MAX
+#define NFP_TX_MAX_MTU_SEG 8
+
 /* Bar allocation */
 #define NFP_NET_CRTL_BAR0
 #define NFP_NET_TX_BAR  2
-- 
2.26.2

[dpdk-dev] [PATCH v2] avoid libfdt checks adding full paths to pkg-config

[Christian Ehrhardt]

The checks for libfdt try dependency() first which would only work if
a pkg-config would be present but libfdt has none.
Then it probes for the lib path itself via cc.find_library.

But later it adds the result of either probe to ext_deps which ends up
in build and also the resulting pkg-config to contain toolchain versioned
paths in Libs.private like:
  /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libfdt.so
which obviously breaks on toolchain updates.

In general libs used multiple times - ipn3ke + ifpga in this case - are
checked centrally in config/meson.build so move it there and fix the
adding of dependencies to not use the full file path.

The result is libfdt in pkg-config now showing up as:
  Libs.private: -pthread -lm -ldl -lnuma -lfdt -lpcap

Signed-off-by: Christian Ehrhardt 
Reviewed-by: Luca Boccassi 
Reviewed-by: Bruce Richardson 
---
 config/meson.build | 9 +
 drivers/net/ipn3ke/meson.build | 6 +-
 drivers/raw/ifpga/meson.build  | 7 +--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/config/meson.build b/config/meson.build
index cff8b33dd2..1c8317e750 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -150,6 +150,15 @@ if numa_dep.found() and cc.has_header('numaif.h')
dpdk_extra_ldflags += '-lnuma'
 endif
 
+has_libfdt = 0
+fdt_dep = cc.find_library('libfdt', required: false)
+if fdt_dep.found() and cc.has_header('fdt.h')
+   dpdk_conf.set10('RTE_HAS_LIBFDT', true)
+   has_libfdt = 1
+   add_project_link_arguments('-lfdt', language: 'c')
+   dpdk_extra_ldflags += '-lfdt'
+endif
+
 # check for libbsd
 libbsd = dependency('libbsd', required: false)
 if libbsd.found()
diff --git a/drivers/net/ipn3ke/meson.build b/drivers/net/ipn3ke/meson.build
index ec9cb7daf0..83611cfead 100644
--- a/drivers/net/ipn3ke/meson.build
+++ b/drivers/net/ipn3ke/meson.build
@@ -9,11 +9,7 @@
 #  rte_eth_switch_domain_free()
 #
 
-dep = dependency('libfdt', required: false)
-if not dep.found()
-   dep = cc.find_library('libfdt', required: false)
-endif
-if not dep.found()
+if not has_libfdt
build = false
reason = 'missing dependency, "libfdt"'
subdir_done()
diff --git a/drivers/raw/ifpga/meson.build b/drivers/raw/ifpga/meson.build
index 05a1711b5d..8e705ac888 100644
--- a/drivers/raw/ifpga/meson.build
+++ b/drivers/raw/ifpga/meson.build
@@ -1,11 +1,7 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2018 Intel Corporation
 
-dep = dependency('libfdt', required: false)
-if not dep.found()
-   dep = cc.find_library('libfdt', required: false)
-endif
-if not dep.found()
+if not has_libfdt
build = false
reason = 'missing dependency, "libfdt"'
subdir_done()
@@ -16,7 +12,6 @@ objs = [base_objs]
 
 deps += ['ethdev', 'rawdev', 'pci', 'bus_pci', 'kvargs',
'bus_vdev', 'bus_ifpga', 'net', 'pmd_i40e', 'pmd_ipn3ke']
-ext_deps += dep
 
 sources = files('ifpga_rawdev.c')
 
-- 
2.28.0

Re: [dpdk-dev] [PATCH] avoid libfdt checks adding full paths to pkg-config

[Christian Ehrhardt]

On Wed, Sep 2, 2020 at 1:25 PM Bruce Richardson
 wrote:
>
> On Wed, Sep 02, 2020 at 01:10:30PM +0200, Christian Ehrhardt wrote:
> > The checks for libfdt try dependency() first which would only work if
> > a pkg-config would be present but libfdt has none.
> > Then it probes for the lib path itself via cc.find_library.
> >
> > But later it adds the result of either probe to ext_deps which ends up
> > in build and also the resulting pkg-config to contain toolchain versioned
> > paths in Libs.private like:
> >   /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libfdt.so
> > which obviously breaks on toolchain updates.
> >
> > In general libs used multiple times - ipn3ke + ifpga in this case - are
> > checked centrally in config/meson.build so move it there and fix the
> > adding of dependencies to not use the full file path.
> >
> > The result is libfdt in pkg-config now showing up as:
> >   Libs.private: -pthread -lm -ldl -lnuma -lfdt -lpcap
> >
> > Signed-off-by: Christian Ehrhardt 
> > Reviewed-by: Luca Boccassi 
> > ---
> >  config/meson.build | 9 +
> >  drivers/net/ipn3ke/meson.build | 6 +-
> >  drivers/raw/ifpga/meson.build  | 7 +--
> >  3 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/config/meson.build b/config/meson.build
> > index cff8b33dd2..1c8317e750 100644
> > --- a/config/meson.build
> > +++ b/config/meson.build
> > @@ -150,6 +150,15 @@ if numa_dep.found() and cc.has_header('numaif.h')
> >   dpdk_extra_ldflags += '-lnuma'
> >  endif
> >
> > +has_libfdt = 0
> > +fdt_dep = cc.find_library('libfdt', required: false)
> > +if fdt_dep.found() and cc.has_header('fdt.h')
> > + dpdk_conf.set10('RTE_HAS_LIBFDT', true)
> > + has_libfdt = 1
> > + add_project_link_arguments('-lfdt', language: 'c')
> > + dpdk_extra_ldflags += '-lfdt'
> > +endif
> > +
> >  # check for libbsd
> >  libbsd = dependency('libbsd', required: false)
> >  if libbsd.found()
> > diff --git a/drivers/net/ipn3ke/meson.build b/drivers/net/ipn3ke/meson.build
> > index ec9cb7daf0..d5000d807c 100644
> > --- a/drivers/net/ipn3ke/meson.build
> > +++ b/drivers/net/ipn3ke/meson.build
> > @@ -9,11 +9,7 @@
> >  #  rte_eth_switch_domain_free()
> >  #
> >
> > -dep = dependency('libfdt', required: false)
> > -if not dep.found()
> > - dep = cc.find_library('libfdt', required: false)
> > -endif
> > -if not dep.found()
> > +if has_libfdt == 0
>
> Minor nit, for readability, I'd suggest using "not has_libfdt", but what is
> here can work too.

Thanks, improved according to your suggestion, v2 submission inbound.

> >   build = false
> >   reason = 'missing dependency, "libfdt"'
> >   subdir_done()
> > diff --git a/drivers/raw/ifpga/meson.build b/drivers/raw/ifpga/meson.build
> > index 05a1711b5d..da454b1942 100644
> > --- a/drivers/raw/ifpga/meson.build
> > +++ b/drivers/raw/ifpga/meson.build
> > @@ -1,11 +1,7 @@
> >  # SPDX-License-Identifier: BSD-3-Clause
> >  # Copyright(c) 2018 Intel Corporation
> >
> > -dep = dependency('libfdt', required: false)
> > -if not dep.found()
> > - dep = cc.find_library('libfdt', required: false)
> > -endif
> > -if not dep.found()
> > +if has_libfdt == 0
> >   build = false
> >   reason = 'missing dependency, "libfdt"'
> >   subdir_done()
> > @@ -16,7 +12,6 @@ objs = [base_objs]
> >
> >  deps += ['ethdev', 'rawdev', 'pci', 'bus_pci', 'kvargs',
> >   'bus_vdev', 'bus_ifpga', 'net', 'pmd_i40e', 'pmd_ipn3ke']
> > -ext_deps += dep
> >
> >  sources = files('ifpga_rawdev.c')
> >
> > --
> Reviewed-by: Bruce Richardson 



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Re: [dpdk-dev] [PATCH v6 1/8] net/dpaa: add support for fmlib in dpdk

[Ferruh Yigit]

On 9/2/2020 6:15 AM, Hemant Agrawal wrote:
> Hi Ferruh,
> 
>> -Original Message-
>> From: Ferruh Yigit 
>> Sent: Tuesday, September 1, 2020 9:19 PM
>> To: Hemant Agrawal ; dev@dpdk.org
>> Subject: Re: [PATCH v6 1/8] net/dpaa: add support for fmlib in dpdk
>>
>> On 9/1/2020 1:36 PM, Hemant Agrawal wrote:
>>> DPAA platorm MAC interface is known as FMAN i.e. Frame Manager.
>>> There are two ways to control it.
>>> 1. Statically configure the queues and classification rules before the
>>> start of the application using FMC tool.
>>> 2. Dynamically configure it within application by making API calls of
>>> fmlib.
>>>
>>> The fmlib or Frame Manager library provides an API on top of the Frame
>>> Manager driver ioctl calls, that provides a user space application
>>> with a simple way to configure driver parameters and PCD (parse -
>>> classify - distribute) rules.
>>>
>>> This patch integrates the base fmlib so that various queue config, RSS
>>> and classification related features can be supported on DPAA platform.
>>>
>>> Signed-off-by: Sachin Saxena 
>>> Signed-off-by: Hemant Agrawal 
>>> ---
>>>  doc/guides/nics/dpaa.rst  |   52 +-
>>>  doc/guides/platform/dpaa.rst  |   21 +-
>>>  drivers/net/dpaa/fmlib/dpaa_integration.h |   50 +
>>>  drivers/net/dpaa/fmlib/fm_ext.h   |  463 ++
>>>  drivers/net/dpaa/fmlib/fm_lib.c   |  561 ++
>>>  drivers/net/dpaa/fmlib/fm_pcd_ext.h   | 5787
>> +
>>>  drivers/net/dpaa/fmlib/fm_port_ext.h  | 3350 
>>>  drivers/net/dpaa/fmlib/ncsw_ext.h |  158 +
>>>  drivers/net/dpaa/fmlib/net_ext.h  |  411 ++
>>>  drivers/net/dpaa/meson.build  |3 +-
>>>  10 files changed, 10849 insertions(+), 7 deletions(-)  create mode
>>> 100644 drivers/net/dpaa/fmlib/dpaa_integration.h
>>>  create mode 100644 drivers/net/dpaa/fmlib/fm_ext.h  create mode
>>> 100644 drivers/net/dpaa/fmlib/fm_lib.c  create mode 100644
>>> drivers/net/dpaa/fmlib/fm_pcd_ext.h
>>>  create mode 100644 drivers/net/dpaa/fmlib/fm_port_ext.h
>>>  create mode 100644 drivers/net/dpaa/fmlib/ncsw_ext.h  create mode
>>> 100644 drivers/net/dpaa/fmlib/net_ext.h
>>>
>>> diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst index
>>> 17839a920..7e6010471 100644
>>> --- a/doc/guides/nics/dpaa.rst
>>> +++ b/doc/guides/nics/dpaa.rst
>>> @@ -1,5 +1,5 @@
>>>  ..  SPDX-License-Identifier: BSD-3-Clause
>>> -Copyright 2017 NXP
>>> +Copyright 2017,2020 NXP
>>>
>>>
>>>  DPAA Poll Mode Driver
>>> @@ -21,6 +21,7 @@ Contents summary
>>>
>>>  - DPAA overview
>>>  - DPAA driver architecture overview
>>> +- FMAN configuration tools and library
>>>
>>>  .. _dpaa_overview:
>>>
>>> @@ -285,6 +286,55 @@ for details.
>>>Done
>>>testpmd>
>>>
>>> +FMAN Config
>>> +---
>>> +
>>> +Frame Manager is also responsible for parser, classify and distribute
>>> +functionality in the DPAA.
>>> +
>>> +   FMAN supports:
>>> +   Packet parsing at wire speed. It supports standard protocols parsing and
>>> +   identification by HW
>> (VLAN/IP/UDP/TCP/SCTP/PPPoE/PPP/MPLS/GRE/IPSec).
>>> +   It supports non-standard UDF header parsing for custom protocols.
>>> +   Classification / Distribution: Coarse classification based on Key
>> generation
>>> +   Hash and exact match lookup
>>> +
>>> +FMC - FMAN Configuration Tool
>>> +~
>>> +   This tool is available in User Space. The tool is used to configure FMAN
>>> +   Physical (MAC) or Ephemeral (OH)ports for Parse/Classify/distribute.
>>> +   The PCDs can be hash based where a set of fields are key input for hash
>>> +   generation within FMAN keygen. The hash value is used to generate a
>> FQID for
>>> +   frame. There is a provision to setup exact match lookup too where field
>>> +   values within a packet drives corresponding FQID.
>>> +   Currently it works on XML file inputs.
>>> +
>>> +   Limitations:
>>> +   1.For Dynamic Configuration change, currently no support is available.
>>> +   E.g. enable/disable a port, a operator (set of VLANs and associate 
>>> rules).
>>> +
>>> +   2.During FMC configuration, port for which policy is being configured is
>>> +   brought down and the policy is flushed on port before new policy is
>> updated
>>> +   for the port. Support is required to add/append/delete etc.
>>> +
>>> +   3.FMC, being a separate user-space application, needs to be invoked
>> from
>>> +   Shell.
>>> +
>>> +
>>> +   The details can be found in FMC Doc at:
>>> +   `Frame Mnager Configuration Tool
>> > w.nxp.com%2Fdocs%2Fen%2Fapplication-
>> note%2FAN4760.pdf&data=02%7C01%7Chemant.agrawal%40nxp.com%
>> 7Cdb7eda614491479976c508d84e8e8c42%7C686ea1d3bc2b4c6fa92cd99c5c30
>> 1635%7C0%7C1%7C637345721434145756&sdata=ynJeLWqw0hPTya5IRt
>> GviovNA7mAGIZ8k3XSFcZyLP4%3D&reserved=0>`_.
>>> +
>>> +FMLIB
>>> +~
>>> +   The Frame Manager library provides an API on top of the 

Re: [dpdk-dev] [PATCH v2] avoid libfdt checks adding full paths to pkg-config

[Luca Boccassi]

On Wed, 2020-09-02 at 14:39 +0200, Christian Ehrhardt wrote:
> The checks for libfdt try dependency() first which would only work if
> a pkg-config would be present but libfdt has none.
> Then it probes for the lib path itself via cc.find_library.
> 
> But later it adds the result of either probe to ext_deps which ends up
> in build and also the resulting pkg-config to contain toolchain versioned
> paths in Libs.private like:
>   /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libfdt.so
> which obviously breaks on toolchain updates.
> 
> In general libs used multiple times - ipn3ke + ifpga in this case - are
> checked centrally in config/meson.build so move it there and fix the
> adding of dependencies to not use the full file path.
> 
> The result is libfdt in pkg-config now showing up as:
>   Libs.private: -pthread -lm -ldl -lnuma -lfdt -lpcap
> 
> Signed-off-by: Christian Ehrhardt 
> Reviewed-by: Luca Boccassi 
> Reviewed-by: Bruce Richardson 
> ---
>  config/meson.build | 9 +
>  drivers/net/ipn3ke/meson.build | 6 +-
>  drivers/raw/ifpga/meson.build  | 7 +--
>  3 files changed, 11 insertions(+), 11 deletions(-)

Given this is low-risk and it fixes a build failure that is happening
right now in Debian/Ubuntu, I'll pick it up for 19.11.4 straight away.

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [PATCH v4 2/2] Add l2reflect measurement application

[Henning Schild]

Am Tue, 01 Sep 2020 17:07:38 +0200
schrieb Thomas Monjalon :

> 28/08/2020 16:22, Henning Schild:
> > Thomas,
> > 
> > what is the state on this one? Any more steps to take or people to
> > involve?  
> 
> I can try adding some key people in Cc list,
> while doing a quick review.
>
>
> > I first showed that in action back in 2016 on FOSDEM.
> > https://archive.fosdem.org/2016/schedule/event/virt_iaas_real_time_cloud/
> > After my talk two devs from dpdk approached me because they liked
> > the idea of a "network cyclictest". It took us some time to finally
> > go upstream with it, unfortunately i do not recall names.  
> 
> I think I was one of them.
> 
> There will be some talks about latency in the next virtual DPDK event:
> https://events.linuxfoundation.org/dpdk-userspace-summit/program/schedule/
> (speakers are Cc'ed)

Thanks, that sure looks like we are not the only ones who are
interested in latency and probably a way to measure it. From other
doing it as well it would be nice to hear how they currently do that.

> > This application can potentially be integrated into the test-suite
> > for QA, making sure no changes heavily increase the package
> > transmission worst case timing.  
> 
> Good
> 
> 
> > Felix Moessbauer  wrote:
> >   
> > > The l2reflect application implements a ping-pong benchmark to
> > > measure the latency between two instances. For communication,
> > > we use raw ethernet and send one packet at a time. The timing data
> > > is collected locally and min/max/avg values are displayed in a
> > > TUI. Finally, a histogram of the latencies is printed which can be
> > > further processed with the jitterdebugger visualization scripts.  
> 
> Please can you show an example of script usage?
> 
> > > To debug latency spikes, a max threshold can be defined.
> > > If it is hit, a trace point is created on both instances.
> > > 
> > > Signed-off-by: Felix Moessbauer 
> > > Signed-off-by: Henning Schild   
> [...]
> > > --- a/app/Makefile
> > > +++ b/app/Makefile  
> 
> No need to update Makefile, it will be removed.
> 
> > > --- /dev/null
> > > +++ b/app/l2reflect/l2reflect.h
> > > @@ -0,0 +1,62 @@
> > > +/*
> > > + * SPDX-License-Identifier: BSD-3-Clause  
> 
> SPDX should be the first line.
> 
> > > + * Copyright(c) 2020 Siemens AG
> > > + *
> > > + * authors:
> > > + *   Felix Moessbauer 
> > > + *   Henning Schild   
> 
> It is uncommon to mention authors in the file.
> In general, git metadata covers this info.
> Any special requirement?

That application has some history. Written by me and eventually
improved for upstream by Felix. The idea here was to give credit to two
people with just one author field in git. If that is really in the way,
we can drop it and make Felix the sole author.

> [...]
> > > +
> > > +/*
> > > + * Compares a packet destination MAC address to a device MAC
> > > address.
> > > + */
> > > +static __rte_always_inline int
> > > +ether_addr_cmp(struct rte_ether_addr *ea, struct rte_ether_addr
> > > *eb) +{
> > > + return ((*(uint64_t *)ea ^ *(uint64_t *)eb) &
> > > MAC_ADDR_CMP) == 0; +}  
> 
> Please use rte_is_same_ether_addr()
> 
> > > --- /dev/null
> > > +++ b/app/l2reflect/main.c
> > > @@ -0,0 +1,872 @@
> > > +/*
> > > + * SPDX-License-Identifier: BSD-3-Clause
> > > + * Copyright(c) 2020 Siemens AG
> > > + *
> > > + * authors:
> > > + *   Felix Moessbauer 
> > > + *   Henning Schild 
> > > + *
> > > + * launch (non-rt kernel): l2reflect --lcores 0@0,1@6 -n 1
> > > + * launch (rt kernel): l2reflect --lcores 0@0,1@6 -n 1 -- -P 50
> > > -r -l  
> 
> Would be better in a --help section or in the doc.
> 
> > > + *
> > > + * The l2reflect application implements a ping-pong benchmark to
> > > + * measure the latency between two instances. For communication,
> > > + * we use raw ethernet and send one packet at a time. The timing
> > > data
> > > + * is collected locally and min/max/avg values are displayed in a
> > > TUI.
> > > + * Finally, a histogram of the latencies is printed which can be
> > > + * further processed with the jitterdebugger visualization
> > > scripts.
> > > + * To debug latency spikes, a max threshold can be defined.
> > > + * If it is hit, a trace point is created on both instances.
> > > + */  
> [...]
> > > +__rte_format_printf(1, 0)
> > > +static void
> > > +trace_write(const char *fmt, ...)
> > > +{
> > > + va_list ap;
> > > + char buf[256];
> > > + int n, err;
> > > +
> > > + if (trace_fd == 0)
> > > + trace_fd =
> > > open("/sys/kernel/debug/tracing/trace_marker",
> > > + O_WRONLY);  
> 
> Why not using rte_trace framework?

I am not sure where rte_trace ends up eventually. But the idea here is
to have kernel traces when looking at latency peaks. You might just be
looking at an incorrect host tuning when you see a spike i.e. higher
prio threads on your possibly isolated core.
It is not tracing dpdk, but more how it fits in the overall picture.
 
> > > + if (trace_fd < 0)
> > > + return;
> > > +
> > > +

Re: [dpdk-dev] [PATCH v4 2/2] Add l2reflect measurement application

[Henning Schild]

Am Wed, 02 Sep 2020 10:30:22 +0200
schrieb Thomas Monjalon :

> 02/09/2020 09:56, Henning Schild:
> > Am Tue, 01 Sep 2020 17:07:38 +0200
> > schrieb Thomas Monjalon :
> >   
> > > 28/08/2020 16:22, Henning Schild:  
> > > > Thomas,
> > > > 
> > > > what is the state on this one? Any more steps to take or people
> > > > to involve?
> > > 
> > > I can try adding some key people in Cc list,
> > > while doing a quick review.
> > >
> > >  
> > > > I first showed that in action back in 2016 on FOSDEM.
> > > > https://archive.fosdem.org/2016/schedule/event/virt_iaas_real_time_cloud/
> > > > After my talk two devs from dpdk approached me because they
> > > > liked the idea of a "network cyclictest". It took us some time
> > > > to finally go upstream with it, unfortunately i do not recall
> > > > names.
> > > 
> > > I think I was one of them.
> > > 
> > > There will be some talks about latency in the next virtual DPDK
> > > event:
> > > https://events.linuxfoundation.org/dpdk-userspace-summit/program/schedule/
> > > (speakers are Cc'ed)  
> > 
> > Thanks, that sure looks like we are not the only ones who are
> > interested in latency and probably a way to measure it. From other
> > doing it as well it would be nice to hear how they currently do
> > that. 
> > > > This application can potentially be integrated into the
> > > > test-suite for QA, making sure no changes heavily increase the
> > > > package transmission worst case timing.
> > > 
> > > Good
> > > 
> > >   
> > > > Felix Moessbauer  wrote:
> > > > 
> > > > > The l2reflect application implements a ping-pong benchmark to
> > > > > measure the latency between two instances. For communication,
> > > > > we use raw ethernet and send one packet at a time. The timing
> > > > > data is collected locally and min/max/avg values are
> > > > > displayed in a TUI. Finally, a histogram of the latencies is
> > > > > printed which can be further processed with the
> > > > > jitterdebugger visualization scripts.
> > > 
> > > Please can you show an example of script usage?  
> 
> [...]
> > > > > + * Copyright(c) 2020 Siemens AG
> > > > > + *
> > > > > + * authors:
> > > > > + *   Felix Moessbauer 
> > > > > + *   Henning Schild 
> > > 
> > > It is uncommon to mention authors in the file.
> > > In general, git metadata covers this info.
> > > Any special requirement?  
> > 
> > That application has some history. Written by me and eventually
> > improved for upstream by Felix. The idea here was to give credit to
> > two people with just one author field in git. If that is really in
> > the way, we can drop it and make Felix the sole author.  
> 
> You are both marked as authors thanks to the sign-off:
>   Signed-off-by: Felix Moessbauer 
>   Signed-off-by: Henning Schild 
> 
> [...]
> > > > > +__rte_format_printf(1, 0)
> > > > > +static void
> > > > > +trace_write(const char *fmt, ...)
> > > > > +{
> > > > > + va_list ap;
> > > > > + char buf[256];
> > > > > + int n, err;
> > > > > +
> > > > > + if (trace_fd == 0)
> > > > > + trace_fd =
> > > > > open("/sys/kernel/debug/tracing/trace_marker",
> > > > > + O_WRONLY);
> > > 
> > > Why not using rte_trace framework?  
> > 
> > I am not sure where rte_trace ends up eventually. But the idea here
> > is to have kernel traces when looking at latency peaks. You might
> > just be looking at an incorrect host tuning when you see a spike
> > i.e. higher prio threads on your possibly isolated core.
> > It is not tracing dpdk, but more how it fits in the overall
> > picture.  
> 
> How Linux trace helps more than DPDK one? Because of scheduler
> context? Anyway this is Linux-specific.

The kernel trace gives you a system view. So you might see competing
threads with higher prio on your cpu, all kernel activity on your
behalf or on someone elses ... other device interrupts coming in on
your core. All information related to the system, not really the
application itself. You would be using this to make sure your setup is
correct. Once you are sure the spike must be coming from inside your
application you would go and trace that.
So i think there might be value for rte_trace once tracing the
application, here we care about the overall system. But i also do not
know rte_trace, its scope and features ... just guessing it is app+lib
only.

Henning

> [...]
> > > If I understand well, this requires a special cabling?
> > > Would it be possible to measure latency of hardware NIC internal
> > > loopback or software PMD loopback?  
> > 
> > Not sure. We always want to see the full picture ... i.e would also
> > want to see if a NIC is slow to put a packet on the "wire".
> > For testing we do use multi-port NICs with cable-loops. The other
> > setup is Qemus with the application inside and a dpdk-based vhost
> > switch. But that virtual setup is also not trivial. In fact we
> > usually do make that switch send the packets over the cable-loop to
> > again cov

Re: [dpdk-dev] [PATCH] drivers/common: mark symbols as internal

[Ferruh Yigit]

On 9/2/2020 10:59 AM, David Marchand wrote:
> Now that we have the internal tag, let's avoid confusion with exported
> symbols in common drivers that were using the experimental tag as a
> workaround.
> There is also no need to put internal API symbols in the public stable
> ABI.
> 
> Signed-off-by: David Marchand 
> ---
> Note: I noticed a patch from Haiyue for iavf.
> I am fine with reposting per driver, but it seems worth a tree-wide
> change from my pov.
> 
> ---
>  drivers/common/cpt/cpt_pmd_ops_helper.h |  8 +---
>  drivers/common/cpt/rte_common_cpt_version.map   | 13 +++--
>  drivers/common/iavf/iavf_prototype.h|  8 
>  drivers/common/iavf/rte_common_iavf_version.map |  2 +-

iavf one sent as separate patch [1] and applied to next-net [2].


[1]
https://patches.dpdk.org/patch/75564/

[2]
https://git.dpdk.org/next/dpdk-next-net/commit/?h=main&id=f59221bda2ad1f7aa118dc41d6bac4bd3a3d4654

>  drivers/common/mvep/rte_common_mvep_version.map |  2 +-
>  drivers/common/mvep/rte_mvep_common.h   |  3 +++
>  drivers/common/octeontx/octeontx_mbox.h |  5 +
>  .../common/octeontx/rte_common_octeontx_version.map |  2 +-
>  8 files changed, 27 insertions(+), 16 deletions(-)

<...>

Re: [dpdk-dev] [PATCH] rte_log: make rte_logs private

[Stephen Hemminger]

On Wed, 2 Sep 2020 10:40:19 +0200
David Marchand  wrote:

> On Fri, Aug 28, 2020 at 12:54 AM Stephen Hemminger
>  wrote:
> >
> > As announced in earlier releases, rte_logs can now be made
> > internal to eal_common_log.  
> 
> I had prepared this cleanup before my PTO and was about to send it.
> Just to avoid duplicate work, do you intend to work on other cleanups ?
> 
> 
> Hiding this symbol is fine, but we must remove the experimental tag on
> rte_log_get_stream since it becomes the only way to access the log
> stream.
> 
> More comments below.
> Thanks.

No intention on doing other cleanups, just saw this while implementing
a log stream provider.

Agree, the rte_log_get_stream() can be permanent API now.

Re: [dpdk-dev] [PATCH] usertools: add huge page setup script

[Stephen Hemminger]

On Wed, 2 Sep 2020 10:55:07 +0100
Bruce Richardson  wrote:

> On Tue, Sep 01, 2020 at 09:56:43AM -0700, Stephen Hemminger wrote:
> > This is an improved version of the setup of huge pages
> > bases on earlier DPDK setup. Differences are:
> >* it autodetects NUMA vs non NUMA
> >* it allows setting different page sizes
> >  recent kernels support multiple sizes.
> >* it accepts a parameter in bytes (not pages).
> > 
> > Signed-off-by: Stephen Hemminger 
> > ---
> > This is lightly tested, it still needs testing on multiple architectures
> > etc.
> > 
> >  usertools/hugepage-setup.sh | 169 
> >  1 file changed, 169 insertions(+)
> >  create mode 100755 usertools/hugepage-setup.sh
> > 
> > diff --git a/usertools/hugepage-setup.sh b/usertools/hugepage-setup.sh
> > new file mode 100755
> > index ..df132e2f8d64
> > --- /dev/null
> > +++ b/usertools/hugepage-setup.sh
> > @@ -0,0 +1,169 @@
> > +#! /bin/bash  
> 
> Is there a good reason to limit this to bash rather than general "sh"?
> 
> Also, if we ever see this script being expanded to cover more, would it be
> more extensible in python rather than shell?

Mainly because bash has arithmetic operations, and doing it with normal shell
requires using expr.

[dpdk-dev] [PATCH] cryptodev: remove crypto list end enumerators

[Arek Kusztal]

This patch removes enumerators RTE_CRYPTO_CIPHER_LIST_END,
RTE_CRYPTO_AUTH_LIST_END, RTE_CRYPTO_AEAD_LIST_END to prevent
some problems that may arise when adding new crypto algorithms.

Signed-off-by: Arek Kusztal 
---
 lib/librte_cryptodev/rte_crypto_sym.h | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/lib/librte_cryptodev/rte_crypto_sym.h 
b/lib/librte_cryptodev/rte_crypto_sym.h
index f29c98051..7a2556a9e 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -132,15 +132,12 @@ enum rte_crypto_cipher_algorithm {
 * for m_src and m_dst in the rte_crypto_sym_op must be NULL.
 */
 
-   RTE_CRYPTO_CIPHER_DES_DOCSISBPI,
+   RTE_CRYPTO_CIPHER_DES_DOCSISBPI
/**< DES algorithm using modes required by
 * DOCSIS Baseline Privacy Plus Spec.
 * Chained mbufs are not supported in this mode, i.e. rte_mbuf.next
 * for m_src and m_dst in the rte_crypto_sym_op must be NULL.
 */
-
-   RTE_CRYPTO_CIPHER_LIST_END
-
 };
 
 /** Cipher algorithm name strings */
@@ -312,10 +309,8 @@ enum rte_crypto_auth_algorithm {
/**< HMAC using 384 bit SHA3 algorithm. */
RTE_CRYPTO_AUTH_SHA3_512,
/**< 512 bit SHA3 algorithm. */
-   RTE_CRYPTO_AUTH_SHA3_512_HMAC,
+   RTE_CRYPTO_AUTH_SHA3_512_HMAC
/**< HMAC using 512 bit SHA3 algorithm. */
-
-   RTE_CRYPTO_AUTH_LIST_END
 };
 
 /** Authentication algorithm name strings */
@@ -412,9 +407,8 @@ enum rte_crypto_aead_algorithm {
/**< AES algorithm in CCM mode. */
RTE_CRYPTO_AEAD_AES_GCM,
/**< AES algorithm in GCM mode. */
-   RTE_CRYPTO_AEAD_CHACHA20_POLY1305,
+   RTE_CRYPTO_AEAD_CHACHA20_POLY1305
/**< Chacha20 cipher with poly1305 authenticator */
-   RTE_CRYPTO_AEAD_LIST_END
 };
 
 /** AEAD algorithm name strings */
-- 
2.17.1

Re: [dpdk-dev] [PATCH v2] avoid libfdt checks adding full paths to pkg-config

[David Marchand]

On Wed, Sep 2, 2020 at 2:39 PM Christian Ehrhardt
 wrote:
>
> The checks for libfdt try dependency() first which would only work if
> a pkg-config would be present but libfdt has none.
> Then it probes for the lib path itself via cc.find_library.
>
> But later it adds the result of either probe to ext_deps which ends up
> in build and also the resulting pkg-config to contain toolchain versioned
> paths in Libs.private like:
>   /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libfdt.so
> which obviously breaks on toolchain updates.
>
> In general libs used multiple times - ipn3ke + ifpga in this case - are
> checked centrally in config/meson.build so move it there and fix the
> adding of dependencies to not use the full file path.
>
> The result is libfdt in pkg-config now showing up as:
>   Libs.private: -pthread -lm -ldl -lnuma -lfdt -lpcap
>
> Signed-off-by: Christian Ehrhardt 
> Reviewed-by: Luca Boccassi 
> Reviewed-by: Bruce Richardson 
> ---
>  config/meson.build | 9 +
>  drivers/net/ipn3ke/meson.build | 6 +-
>  drivers/raw/ifpga/meson.build  | 7 +--
>  3 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/config/meson.build b/config/meson.build
> index cff8b33dd2..1c8317e750 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -150,6 +150,15 @@ if numa_dep.found() and cc.has_header('numaif.h')
> dpdk_extra_ldflags += '-lnuma'
>  endif
>
> +has_libfdt = 0
> +fdt_dep = cc.find_library('libfdt', required: false)
> +if fdt_dep.found() and cc.has_header('fdt.h')
> +   dpdk_conf.set10('RTE_HAS_LIBFDT', true)
> +   has_libfdt = 1
> +   add_project_link_arguments('-lfdt', language: 'c')
> +   dpdk_extra_ldflags += '-lfdt'
> +endif
> +
>  # check for libbsd
>  libbsd = dependency('libbsd', required: false)
>  if libbsd.found()
> diff --git a/drivers/net/ipn3ke/meson.build b/drivers/net/ipn3ke/meson.build
> index ec9cb7daf0..83611cfead 100644
> --- a/drivers/net/ipn3ke/meson.build
> +++ b/drivers/net/ipn3ke/meson.build
> @@ -9,11 +9,7 @@
>  #  rte_eth_switch_domain_free()
>  #
>
> -dep = dependency('libfdt', required: false)
> -if not dep.found()
> -   dep = cc.find_library('libfdt', required: false)
> -endif
> -if not dep.found()
> +if not has_libfdt

"not" expects a boolean, this can be seen in Travis and OBS builds for
Debian (at least 10 and Next).

OVS robot travis:
https://travis-ci.com/github/ovsrobot/dpdk/jobs/380310104#L721

My OBS:
[  143s] Compiler for C supports arguments -mavx2: YES (cached)
[  143s] Message: drivers/net/ice: Defining dependency "pmd_ice"
[  143s] Message: drivers/net/igc: Defining dependency "pmd_igc"
[  143s]
[  143s] ../drivers/net/ipn3ke/meson.build:12:7: ERROR: Argument to
"not" is not a boolean.
[  143s] dh_auto_configure: error: cd obj-x86_64-linux-gnu &&
LC_ALL=C.UTF-8 meson .. --wrap-mode=nodownload --buildtype=plain
--prefix=/usr --sysconfdir=/etc --localstatedir=/var
--libdir=lib/x86_64-linux-gnu --libexecdir=lib/x86_64-linux-gnu
--includedir=include/dpdk -Dper_library_versions=false
-Dinclude_subdir_arch=../x86_64-linux-gnu/dpdk -Dmachine=default
-Dkernel_dir=/lib/modules/5.7.0-3-amd64 -Denable_kmods=true returned
exit code 1
[  143s] make[2]: *** [debian/rules:114: override_dh_auto_configure] Error 25
[  143s] make[2]: Leaving directory '/usr/src/packages/BUILD'
[  143s] make[1]: *** [debian/rules:92: build] Error 2
[  143s] make[1]: Leaving directory '/usr/src/packages/BUILD'
[  143s] make: *** [debian/rules:96: binary] Error 2


-- 
David Marchand

Re: [dpdk-dev] [PATCH] cryptodev: remove crypto list end enumerators

[Trahe, Fiona]

> -Original Message-
> From: Kusztal, ArkadiuszX 
> Sent: Wednesday, September 2, 2020 4:02 PM
> To: dev@dpdk.org
> Cc: akhil.go...@nxp.com; Trahe, Fiona ; Kusztal, 
> ArkadiuszX
> 
> Subject: [PATCH] cryptodev: remove crypto list end enumerators
> 
> This patch removes enumerators RTE_CRYPTO_CIPHER_LIST_END,
> RTE_CRYPTO_AUTH_LIST_END, RTE_CRYPTO_AEAD_LIST_END to prevent
> some problems that may arise when adding new crypto algorithms.
> 
> Signed-off-by: Arek Kusztal 
Acked-by: Fiona Trahe 

Re: [dpdk-dev] [[PATCH v3 3/4] pdump: convert timestamp to nanoseconds on Rx path

[Pattan, Reshma]

> -Original Message-
> + rte_eth_read_clock(port, &start_cycles);
> + rte_eth_get_clock_freq(port, &hz);

Do you need to check return value of these calls to  handle -ENOTSUP? And avoid 
timestamping marking.
If -ENOTSUP, then hz value is 0 and using hz in function pdump_ts_to_ns() might 
be illegal.


> + gettimeofday(&now, NULL);

Same here, need to handle return value carefully?

Thanks,
Reshma

[dpdk-dev] [PATCH] app/testpmd: fix name of bitrate library in meson build

[Bruce Richardson]

The bitrate library in DPDK is actually in a "bitratestats" directory, so
that is used by meson for the macro and library name. Therefore, we need
to update references to RTE_LIBRTE_BITRATE to RTE_LIBRTE_BITRATESTATS in
testpmd to have it found. Rather than supporting both defines, since make
is being removed, we can just replace all instances of the former define
with the latter.

To ensure testpmd links ok when this is done, we also need to add
bitratestats to the list of library dependencies.

Fixes: 5b9656b157d3 ("lib: build with meson")
Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---

The exact commit to attribute the bug to is complicated, but I'm chosing
the above commit as the one where the issue of the different macro should
have been originally spotted.
---
 app/test-pmd/meson.build  |  3 +++
 app/test-pmd/parameters.c |  4 ++--
 app/test-pmd/testpmd.c| 12 ++--
 app/test-pmd/testpmd.h|  2 +-
 4 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/app/test-pmd/meson.build b/app/test-pmd/meson.build
index ea56e547bb..f52ab148f6 100644
--- a/app/test-pmd/meson.build
+++ b/app/test-pmd/meson.build
@@ -25,6 +25,9 @@ sources = files('5tswap.c',
'util.c')
 
 deps += ['ethdev', 'gro', 'gso', 'cmdline', 'metrics', 'meter', 'bus_pci']
+if dpdk_conf.has('RTE_LIBRTE_BITRATESTATS')
+   deps += 'bitratestats'
+endif
 if dpdk_conf.has('RTE_LIBRTE_PDUMP')
deps += 'pdump'
 endif
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 7cb0e3d6ec..9b0c0582d0 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -613,7 +613,7 @@ launch_args_parse(int argc, char** argv)
 #ifdef RTE_LIBRTE_LATENCY_STATS
{ "latencystats",   1, 0, 0 },
 #endif
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATSSTATS
{ "bitrate-stats",  1, 0, 0 },
 #endif
{ "disable-crc-strip",  0, 0, 0 },
@@ -986,7 +986,7 @@ launch_args_parse(int argc, char** argv)
 " must be >= 0\n", n);
}
 #endif
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
if (!strcmp(lgopts[opt_idx].name, "bitrate-stats")) {
n = atoi(optarg);
if (n >= 0) {
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 7842c3b781..d92c0ecc1f 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -54,7 +54,7 @@
 #endif
 #include 
 #include 
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
 #include 
 #endif
 #ifdef RTE_LIBRTE_LATENCY_STATS
@@ -478,7 +478,7 @@ uint8_t xstats_hide_zero;
 unsigned int num_sockets = 0;
 unsigned int socket_ids[RTE_MAX_NUMA_NODES];
 
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
 /* Bitrate statistics */
 struct rte_stats_bitrates *bitrate_data;
 lcoreid_t bitrate_lcore_id;
@@ -2063,7 +2063,7 @@ run_pkt_fwd_on_lcore(struct fwd_lcore *fc, packet_fwd_t 
pkt_fwd)
struct fwd_stream **fsm;
streamid_t nb_fs;
streamid_t sm_id;
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
uint64_t tics_per_1sec;
uint64_t tics_datum;
uint64_t tics_current;
@@ -2078,7 +2078,7 @@ run_pkt_fwd_on_lcore(struct fwd_lcore *fc, packet_fwd_t 
pkt_fwd)
do {
for (sm_id = 0; sm_id < nb_fs; sm_id++)
(*pkt_fwd)(fsm[sm_id]);
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
if (bitrate_enabled != 0 &&
bitrate_lcore_id == rte_lcore_id()) {
tics_current = rte_rdtsc();
@@ -3706,7 +3706,7 @@ main(int argc, char** argv)
 "Check the core mask argument\n");
 
/* Bitrate/latency stats disabled by default */
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
bitrate_enabled = 0;
 #endif
 #ifdef RTE_LIBRTE_LATENCY_STATS
@@ -3800,7 +3800,7 @@ main(int argc, char** argv)
 #endif
 
/* Setup bitrate stats */
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
if (bitrate_enabled != 0) {
bitrate_data = rte_stats_bitrate_create();
if (bitrate_data == NULL)
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 25a12b14f2..4fa9797f7e 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -407,7 +407,7 @@ extern uint8_t latencystats_enabled;
 extern lcoreid_t latencystats_lcore_id;
 #endif
 
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
 extern lcoreid_t bitrate_lcore_id;
 extern uint8_t bitrate_enabled;
 #endif
-- 
2.25.1

[dpdk-dev] [PATCH v2] app/testpmd: fix name of bitrate library in meson build

[Bruce Richardson]

The bitrate library in DPDK is actually in a "bitratestats" directory, so
that is used by meson for the macro and library name. Therefore, we need
to update references to RTE_LIBRTE_BITRATE to RTE_LIBRTE_BITRATESTATS in
testpmd to have it found. Rather than supporting both defines, since make
is being removed, we can just replace all instances of the former define
with the latter.

To ensure testpmd links ok when this is done, we also need to add
bitratestats to the list of library dependencies.

Fixes: 5b9656b157d3 ("lib: build with meson")
Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
v2: fixed search-replace fail, where I ended up with "BITRATESTATSSTATS".
Thanks to dmarchand for his eagle-eyes in spotting this quickly. :-)

The exact commit to attribute the bug to is complicated, but I'm chosing
the above commit as the one where the issue of the different macro should
have been originally spotted.
---
 app/test-pmd/meson.build  |  3 +++
 app/test-pmd/parameters.c |  4 ++--
 app/test-pmd/testpmd.c| 12 ++--
 app/test-pmd/testpmd.h|  2 +-
 4 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/app/test-pmd/meson.build b/app/test-pmd/meson.build
index ea56e547bb..f52ab148f6 100644
--- a/app/test-pmd/meson.build
+++ b/app/test-pmd/meson.build
@@ -25,6 +25,9 @@ sources = files('5tswap.c',
'util.c')
 
 deps += ['ethdev', 'gro', 'gso', 'cmdline', 'metrics', 'meter', 'bus_pci']
+if dpdk_conf.has('RTE_LIBRTE_BITRATESTATS')
+   deps += 'bitratestats'
+endif
 if dpdk_conf.has('RTE_LIBRTE_PDUMP')
deps += 'pdump'
 endif
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 7cb0e3d6ec..2a4cb6d2b7 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -613,7 +613,7 @@ launch_args_parse(int argc, char** argv)
 #ifdef RTE_LIBRTE_LATENCY_STATS
{ "latencystats",   1, 0, 0 },
 #endif
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
{ "bitrate-stats",  1, 0, 0 },
 #endif
{ "disable-crc-strip",  0, 0, 0 },
@@ -986,7 +986,7 @@ launch_args_parse(int argc, char** argv)
 " must be >= 0\n", n);
}
 #endif
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
if (!strcmp(lgopts[opt_idx].name, "bitrate-stats")) {
n = atoi(optarg);
if (n >= 0) {
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 7842c3b781..d92c0ecc1f 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -54,7 +54,7 @@
 #endif
 #include 
 #include 
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
 #include 
 #endif
 #ifdef RTE_LIBRTE_LATENCY_STATS
@@ -478,7 +478,7 @@ uint8_t xstats_hide_zero;
 unsigned int num_sockets = 0;
 unsigned int socket_ids[RTE_MAX_NUMA_NODES];
 
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
 /* Bitrate statistics */
 struct rte_stats_bitrates *bitrate_data;
 lcoreid_t bitrate_lcore_id;
@@ -2063,7 +2063,7 @@ run_pkt_fwd_on_lcore(struct fwd_lcore *fc, packet_fwd_t 
pkt_fwd)
struct fwd_stream **fsm;
streamid_t nb_fs;
streamid_t sm_id;
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
uint64_t tics_per_1sec;
uint64_t tics_datum;
uint64_t tics_current;
@@ -2078,7 +2078,7 @@ run_pkt_fwd_on_lcore(struct fwd_lcore *fc, packet_fwd_t 
pkt_fwd)
do {
for (sm_id = 0; sm_id < nb_fs; sm_id++)
(*pkt_fwd)(fsm[sm_id]);
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
if (bitrate_enabled != 0 &&
bitrate_lcore_id == rte_lcore_id()) {
tics_current = rte_rdtsc();
@@ -3706,7 +3706,7 @@ main(int argc, char** argv)
 "Check the core mask argument\n");
 
/* Bitrate/latency stats disabled by default */
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
bitrate_enabled = 0;
 #endif
 #ifdef RTE_LIBRTE_LATENCY_STATS
@@ -3800,7 +3800,7 @@ main(int argc, char** argv)
 #endif
 
/* Setup bitrate stats */
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
if (bitrate_enabled != 0) {
bitrate_data = rte_stats_bitrate_create();
if (bitrate_data == NULL)
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 25a12b14f2..4fa9797f7e 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -407,7 +407,7 @@ extern uint8_t latencystats_enabled;
 extern lcoreid_t latencystats_lcore_id;
 #endif
 
-#ifdef RTE_LIBRTE_BITRATE
+#ifdef RTE_LIBRTE_BITRATESTATS
 extern lcoreid_t bitrate_lcore_id;
 extern uint8_t bitrate_enabled;
 #endif
-- 
2.25.1

Re: [dpdk-dev] [PATCH v1 0/4] Remove RTE_MACHINE_CPUFLAG_ macros

[David Christensen]

On 9/2/20 3:43 AM, Radu Nicolau wrote:

Remove RTE_MACHINE_CPUFLAG_ macros from the build.
Deprecation notice sent, pasted here for reference:

   build macros: The macros defining RTE_MACHINE_CPUFLAG_* will be removed
   from the build. The information provided by these macros is available
   through standard compiler macros. For example, RTE_MACHINE_CPUFLAG_SSE3
   duplicates the compiler-provided macro __SSE3__.

Radu Nicolau (4):
   x86: change cpuflag macros to compiler macros
   arm: change cpuflag macros to compiler macros
   ppc: change cpuflag macros to compiler macros
   doc: remove reference to RTE_MACHINE_CPUFLAG


I'm not too familiar with clang and icc.  Do all compilers use the same 
macro definitions for the same CPU features?  I would have thought the 
RTE_* definitions were there because there are compiler or compiler 
version differences that need to be supported.


Dave

[dpdk-dev] [PATCH] net/vhost: fix xstats wrong after clearing stats

[David Christensen]

The PMD API allows stats and xstats values to be cleared separately.
This is a problem for the vhost PMD since some of the xstats values are
derived from existing stats values.  For example:

testpmd> show port xstats all
...
tx_unicast_packets: 17562959
...
testpmd> clear port stats all
...
show port xstats all
...
tx_unicast_packets: 18446744073709551615
...

Modify the driver so that stats and xstats values are stored, updated,
and cleared separately.

Signed-off-by: David Christensen 
---
 drivers/net/vhost/rte_eth_vhost.c | 54 ++-
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/drivers/net/vhost/rte_eth_vhost.c 
b/drivers/net/vhost/rte_eth_vhost.c
index e55278af6..4e72cc2ca 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -73,6 +73,9 @@ enum vhost_xstats_pkts {
VHOST_BROADCAST_PKT,
VHOST_MULTICAST_PKT,
VHOST_UNICAST_PKT,
+   VHOST_PKT,
+   VHOST_BYTE,
+   VHOST_MISSED_PKT,
VHOST_ERRORS_PKT,
VHOST_ERRORS_FRAGMENTED,
VHOST_ERRORS_JABBER,
@@ -149,11 +152,11 @@ struct vhost_xstats_name_off {
 /* [rx]_is prepended to the name string here */
 static const struct vhost_xstats_name_off vhost_rxport_stat_strings[] = {
{"good_packets",
-offsetof(struct vhost_queue, stats.pkts)},
+offsetof(struct vhost_queue, stats.xstats[VHOST_PKT])},
{"total_bytes",
-offsetof(struct vhost_queue, stats.bytes)},
+offsetof(struct vhost_queue, stats.xstats[VHOST_BYTE])},
{"missed_pkts",
-offsetof(struct vhost_queue, stats.missed_pkts)},
+offsetof(struct vhost_queue, stats.xstats[VHOST_MISSED_PKT])},
{"broadcast_packets",
 offsetof(struct vhost_queue, stats.xstats[VHOST_BROADCAST_PKT])},
{"multicast_packets",
@@ -189,11 +192,11 @@ static const struct vhost_xstats_name_off 
vhost_rxport_stat_strings[] = {
 /* [tx]_ is prepended to the name string here */
 static const struct vhost_xstats_name_off vhost_txport_stat_strings[] = {
{"good_packets",
-offsetof(struct vhost_queue, stats.pkts)},
+offsetof(struct vhost_queue, stats.xstats[VHOST_PKT])},
{"total_bytes",
-offsetof(struct vhost_queue, stats.bytes)},
+offsetof(struct vhost_queue, stats.xstats[VHOST_BYTE])},
{"missed_pkts",
-offsetof(struct vhost_queue, stats.missed_pkts)},
+offsetof(struct vhost_queue, stats.xstats[VHOST_MISSED_PKT])},
{"broadcast_packets",
 offsetof(struct vhost_queue, stats.xstats[VHOST_BROADCAST_PKT])},
{"multicast_packets",
@@ -291,18 +294,11 @@ vhost_dev_xstats_get(struct rte_eth_dev *dev, struct 
rte_eth_xstat *xstats,
vq = dev->data->rx_queues[i];
if (!vq)
continue;
-   vq->stats.xstats[VHOST_UNICAST_PKT] = vq->stats.pkts
-   - (vq->stats.xstats[VHOST_BROADCAST_PKT]
-   + vq->stats.xstats[VHOST_MULTICAST_PKT]);
}
for (i = 0; i < dev->data->nb_tx_queues; i++) {
vq = dev->data->tx_queues[i];
if (!vq)
continue;
-   vq->stats.xstats[VHOST_UNICAST_PKT] = vq->stats.pkts
-   + vq->stats.missed_pkts
-   - (vq->stats.xstats[VHOST_BROADCAST_PKT]
-   + vq->stats.xstats[VHOST_MULTICAST_PKT]);
}
for (t = 0; t < VHOST_NB_XSTATS_RXPORT; t++) {
xstats[count].value = 0;
@@ -346,20 +342,27 @@ vhost_count_multicast_broadcast(struct vhost_queue *vq,
pstats->xstats[VHOST_BROADCAST_PKT]++;
else
pstats->xstats[VHOST_MULTICAST_PKT]++;
+   } else {
+   pstats->xstats[VHOST_UNICAST_PKT]++;
}
 }
 
 static void
-vhost_update_packet_xstats(struct vhost_queue *vq,
-  struct rte_mbuf **bufs,
-  uint16_t count)
+vhost_update_packet_xstats(struct vhost_queue *vq, struct rte_mbuf **bufs,
+  uint16_t count, uint64_t nb_bytes,
+  uint64_t nb_missed)
 {
uint32_t pkt_len = 0;
uint64_t i = 0;
uint64_t index;
struct vhost_stats *pstats = &vq->stats;
 
+   pstats->xstats[VHOST_BYTE] += nb_bytes;
+   pstats->xstats[VHOST_MISSED_PKT] += nb_missed;
+   pstats->xstats[VHOST_UNICAST_PKT] += nb_missed;
+
for (i = 0; i < count ; i++) {
+   pstats->xstats[VHOST_PKT]++;
pkt_len = bufs[i]->pkt_len;
if (pkt_len == 64) {
pstats->xstats[VHOST_64_PKT]++;
@@ -385,6 +388,7 @@ eth_vhost_rx(void *q, struct rte_mbuf **bufs, uint16_t 
nb_bufs)
struct vhost_queue *r = q;
uint16_t i, nb_rx = 0;
uint16_t nb_receive = nb_bufs;
+   uint64_t nb_by

Re: [dpdk-dev] [PATCH] ethdev: fix RSS flow expansion in case of mismatch

[Ferruh Yigit]

On 7/27/2020 1:57 PM, Dekel Peled wrote:
> Function rte_flow_expand_rss() is used to expand a flow rule with
> partial pattern into several rules, to ensure all relevant packets
> are matched.
> It uses utility function rte_flow_expand_rss_item_complete(), to check
> if the last valid item in the flow rule pattern needs to be completed.
> For example the pattern "eth / ipv4 proto is 17 / end" will be completed
> with a "udp" item.

better to add the "actions rss types udp" part of the rule to clarify why the
original rule will be completed with 'udp'.

> This function returns "void" item in two cases:

Can you please clarify what does function returning 'void' mean, so people won't
need to dig the code to find out.

> 1) The last item has empty spec, for example "eth / ipv4 / end".
> 2) The last itme has spec that can't be expanded for RSS.
>For example the pattern "eth / ipv4 proto is 47 / end" ends with IPv4
>item that has next protocol GRE.
> 
> In both cases the flow rule may be expanded, but in the second case such
> expansion may create rules with invalid pattern.
> For example "eth / ipv4 proto is 47 / udp / end".
> In such a case the flow rule should not be expanded.

OK, got the problem.

> 
> This patch updates function rte_flow_expand_rss_item_complete().
> Return value RTE_FLOW_ITEM_TYPE_END is used to indicate the flow rule
> should not be expanded.

But there is only limited number of check in
'rte_flow_expand_rss_item_complete()', like for ipv4 it checks the proto
udp/tcp/ip. What if other proto is part of rule, won't sending END cause the
initial problem of missing pattern.

I mean, for following rule,
... pattern eth / ipv4 proto is 47 / end actions rss type gre end ...

With your update, rule is not expanded and the 'gre' pattern is not added, won't
this cause not matching the rule for rss?


I may be missing something here, or if not I am sure you can fix it,
BUT I am not sure if this is right way to proceed.

This expansion operation is complex, it is hard to verify it without debugging,
and I can see it has been fixed a few times already.
It is trying to construct the correct pattern by trying to understand the user's
intention.
Overall it has two problems I think,
1) It is hard to make it correct, and not sure if we can rely on the user input
to create *correct* patterns.
2) Only mlx is using this function  (and mlx developed and acked it), so other
vendors doesn't try to expand the rules, so same rule may work different for
different PMDs (assuming with same HW capabilities).
Like just giving 'ip' pattern and request 'udp' rss will fail on Intel but will
work on mlx because of this expansion.

What about other two alternatives:
a) If the rule doesn't work, return error. stop. user should fix it. Don't try
to expand or fix the rule implicitly.

b) If mlx is strong on having the expansion, what about moving it to the PMD. It
won't cause more defects for others, cleans the common code and highlights that
this behavior is unique to a vendor.
Unless there are any other vendor willing to use it. Or is it part of the
rte_flow contract already, @Ori, do you know if this expansion behavior
documented anywhere?


Thanks,
ferruh


> In such a case, rte_flow_expand_rss() will return with the original flow
> rule only, without any expansion.
> 
> Fixes: fc2dd8dd492f ("ethdev: fix expand RSS flows")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Dekel Peled 
> Acked-by: Xiaoyu Min 
> Acked-by: Viacheslav Ovsiienko 
> ---
>  lib/librte_ethdev/rte_flow.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
> index f8fdd68..59a386d 100644
> --- a/lib/librte_ethdev/rte_flow.c
> +++ b/lib/librte_ethdev/rte_flow.c
> @@ -247,6 +247,8 @@ struct rte_flow_desc_data {
>   ret = RTE_FLOW_ITEM_TYPE_IPV6;
>   else if (rte_be_to_cpu_16(ether_type) == RTE_ETHER_TYPE_VLAN)
>   ret = RTE_FLOW_ITEM_TYPE_VLAN;
> + else
> + ret = RTE_FLOW_ITEM_TYPE_END;
>   break;
>   case RTE_FLOW_ITEM_TYPE_VLAN:
>   if (item->mask)
> @@ -264,6 +266,8 @@ struct rte_flow_desc_data {
>   ret = RTE_FLOW_ITEM_TYPE_IPV6;
>   else if (rte_be_to_cpu_16(ether_type) == RTE_ETHER_TYPE_VLAN)
>   ret = RTE_FLOW_ITEM_TYPE_VLAN;
> + else
> + ret = RTE_FLOW_ITEM_TYPE_END;
>   break;
>   case RTE_FLOW_ITEM_TYPE_IPV4:
>   if (item->mask)
> @@ -284,6 +288,8 @@ struct rte_flow_desc_data {
>   ret = RTE_FLOW_ITEM_TYPE_IPV4;
>   else if (ip_next_proto == IPPROTO_IPV6)
>   ret = RTE_FLOW_ITEM_TYPE_IPV6;
> + else
> + ret = RTE_FLOW_ITEM_TYPE_END;
>   break;
>   case RTE_FLOW_ITEM_TYPE_IPV6:
>   if (item->mask)
> @@ -304,6 +310

Re: [dpdk-dev] [EXTERNAL] 19.11.4 patches review and test

[Abhishek Marathe]

Hi Luca,

We have tested 19.11.4 and no issues found except known issues.
1. Issue with CX-3/MLX-4 driver with ibquery_pkey() failed.
2. Issue with hot-removal of VF driver.
we are tracking both the issues.

Report:

DPDK 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.dpdk.org%2Fdpdk-stable%2Fsnapshot%2Fdpdk-stable-19.11.4-rc1.tar.gz&data=02%7C01%7CAbhishek.Marathe%40microsoft.com%7C13a3a60691b8456980f908d84d456776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637344307771913541&sdata=8oLAs5j%2BrEF%2BPHMBM036ZgPf2nlooe25daKwXT2YVvs%3D&reserved=0
 was validated on Azure for RedHat RHEL 7.5 latest, Openlogic CentOS 7.5 
latest, Ubuntu 18.04, Ubuntu 16.04.
Tested with Mellanox and netvsc poll-mode drivers.
The tests were executed using LISAv2 framework 
(https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLIS%2FLISAv2&data=02%7C01%7CAbhishek.Marathe%40microsoft.com%7C13a3a60691b8456980f908d84d456776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637344307771913541&sdata=GNF1xf97D2LxyLYJYmDa%2BRoWNqGfItD3D3OjVhp6HRA%3D&reserved=0).

Test case description:

* VERIFY-DPDK-COMPLIANCE - verifies kernel is supported and that the build is 
successful
* VERIFY-DPDK-BUILD-AND-TESTPMD-TEST - verifies using testpmd that packets can 
be sent from a VM to another VM
* VERIFY-SRIOV-FAILSAFE-FOR-DPDK - disables/enables Accelerated Networking for 
the NICs under test and makes sure DPDK works in both scenarios

* PERF-DPDK-FWD-PPS-DS15 - verifies DPDK forwarding performance using testpmd 
on 2, 4, 8 cores, rx and io mode on size Standard_DS15_v2
* PERF-DPDK-SINGLE-CORE-PPS-DS4 - verifies DPDK performance using testpmd on 1 
core, rx and io mode on size Standard_DS4_v2
* PERF-DPDK-MULTICORE-PPS-DS15 - verifies DPDK performance using testpmd on 2, 
4, 8 cores, rx and io mode on size Standard_DS15_v2

* DPDK-RING-LATENCY - verifies DPDK CPU latency using 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshemminger%2Fdpdk-ring-ping.git&data=02%7C01%7CAbhishek.Marathe%40microsoft.com%7C13a3a60691b8456980f908d84d456776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637344307771913541&sdata=znhtFXLZiKaadAJKKLghm9NWvdRUvYZx2xLtIf0r15A%3D&reserved=0
* VERIFY-DPDK-PRIMARY-SECONDARY-PROCESSES - verifies primary / secondary 
processes support for DPDK. Runs only on RHEL and Ubuntu distros with Linux 
kernel >= 4.20

* VERIFY-DPDK-OVS - builds OVS with DPDK support and tests if the OVS DPDK 
ports can be created. Runs only on Ubuntu distro.
* VERIFY-DPDK-VPP - builds VPP with DPDK support and tests if the VPP ports are 
present. Runs only on RHEL and Ubuntu distros.
* VERIFY-DPDK-NFF-GO - builds NFF-GO with DPDK support and runs the functional 
tests from the NFF-GO repository. Runs only on Ubuntu distro.

Ubuntu 16.04: Pass
Ubuntu 18.04: Pass
RHEL 7.5: Pass
CentOS 7.5: Pass

Regards,
Abhishek
-Original Message-
From: Luca Boccassi  
Sent: Tuesday, August 18, 2020 11:12 AM
To: sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe ; Akhil 
Goyal ; Ali Alnubani ; 
benjamin.wal...@intel.com; David Christensen ; Hemant 
Agrawal ; Ian Stokes ; Jerin 
Jacob ; John McNamara ; Ju-Hyoung 
Lee ; Kevin Traynor ; Pei Zhang 
; pingx...@intel.com; qian.q...@intel.com; Raslan Darawsheh 
; Thomas Monjalon ; 
yuan.p...@intel.com; zhaoyan.c...@intel.com
Subject: [EXTERNAL] 19.11.4 patches review and test

Hi all,

Here is a list of patches targeted for stable release 19.11.4.

The planned date for the final release is August 31st.

Please help with testing and validation of your use cases and report any 
issues/results with reply-all to this mail. For the final release the fixes and 
reported validations will be added to the release notes.

A release candidate tarball can be found at:


https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdpdk.org%2Fbrowse%2Fdpdk-stable%2Ftag%2F%3Fid%3Dv19.11.4-rc1&data=02%7C01%7CAbhishek.Marathe%40microsoft.com%7C5f6c5d506f3d439b1d1a08d843a24469%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333711526043405&sdata=LkqDTW1b6u1Q0S4ZJvRGzhG4XL2PG%2FSmikz7jR6iurI%3D&reserved=0

These patches are located at branch 19.11 of dpdk-stable repo:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdpdk.org%2Fbrowse%2Fdpdk-stable%2F&data=02%7C01%7CAbhishek.Marathe%40microsoft.com%7C5f6c5d506f3d439b1d1a08d843a24469%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333711526053410&sdata=nLx7HUHx412XMexrqfAaIxUzK7ko%2BAq8OKakVglimEQ%3D&reserved=0

Thanks.

Luca Boccassi

---
Adam Dybkowski (7):
  test/crypto: fix asymmetric session mempool creation
  crypto/qat: fix AES-XTS capabilities
  crypto/qat: handle mixed hash-cipher requests on GEN3
  test/crypto: add mixed encypted-digest
  common/qat: get firmware version
  crypto/qat: handle mixed hash-cipher on GEN2
  common/qat: fix uninitialized variable

Akhil Goyal (4):
  crypto/dpaax_sec: fix 18-bit PDCP cases with HFN override
  crypto

Re: [dpdk-dev] [RFC v1 0/2] Add device emulation support in DPDK

[Thomas Monjalon]

14/08/2020 21:16, Chenbo Xia:
> Background & Motivation
> ---
> In order to reduce the attack surface, QEMU community is disaggregating QEMU 
> by
> removing part of device emulation from it. The disaggregated/multi-process 
> QEMU
> is using VFIO-over-socket/vfio-user as the main transport mechanism to 
> disaggregate
> I/O services from QEMU[2]. Vfio-user essentially implements the VFIO device 
> model
> presented to the user process by a set of messages over a unix-domain socket. 
> The
> main difference between application using vfio-user and application using vfio
> kernel module is that device manipulation is based on socket messages for 
> vfio-user
> but system calls for vfio kernel module. The vfio-user devices consist of a 
> generic
> VFIO device type, living in QEMU, which is called the client[3], and the core 
> device
> implementation (emulated device), living outside of QEMU, which is called the 
> server.
> 
> With the introduction and support of vfio-user in QEMU, QEMU is explicitly 
> adding
> support for external emulated device and data path. We are trying to leverage 
> that
> and introducing vfio-user support in DPDK. By doing so, DPDK is enabled to be 
> an
> alternative I/O device emulation library of building virtualized devices 
> along with
> high-performance data path in separate processes outside QEMU. It will be 
> easy for
> hardware vendors to provide virtualized solutions of their hardware devices by
> implementing emulated device in DPDK.
> 
> Except for vfio-user introduced in DPDK, this series also introduces the first
> emulated device implementation. That is emulated AVF device (avf_emudev) 
> implemented
> by AVF emulation driver (avf_emudev driver). Emulated AVF device demos how 
> emulated
> device could be implemented in DPDK. SPDK is also investigating to implement 
> use case
> for NVMe. 

I am completely unaware of this change in QEMU.
I've found this presentation about Multi-process QEMU by Oracle:
https://static.sched.com/hosted_files/kvmforum2019/d2/kvm-mpqemu.pdf
and there is the wiki page you already referenced:
https://wiki.qemu.org/Features/MultiProcessQEMU

I guess virtio stays inside QEMU?
What is really moving out? e1000, ne2000 and vmxnet3?
Why emulated AVF is needed, compared to a simple VFIO passthrough?

Re: [dpdk-dev] [PATCH v3] net/mlx5: relaxed ordering for multi-packet RQ buffer refcnt

[Alexander Kozyrev]

> 
> 
> > >
> > > > > > > > > @@ -1790,9 +1792,9 @@ mlx5_rx_burst_mprq(void
> *dpdk_rxq,
> > > > > struct
> > > > > > > > > rte_mbuf **pkts, uint16_t pkts_n)  void *buf_addr;
> > > > > > > > >
> > > > > > > > >  /* Increment the refcnt of the whole chunk. */
> > > > > > > > > -rte_atomic16_add_return(&buf->refcnt, 1);
> > > > > > rte_atomic16_add_return includes a full barrier along with
> > > > > > atomic
> > > > > operation.
> > > > > > But is full barrier required here? For ex:
> > > > > > __atomic_add_fetch(&buf->refcnt, 1,
> > > > > > __ATOMIC_RELAXED) will offer atomicity, but no barrier. Would
> > > > > > that be enough?
> > > > > >
> > > > > > > > > -MLX5_ASSERT((uint16_t)rte_atomic16_read(&buf-
> > > > > > > > > >refcnt) <=
> > > > > > > > > -strd_n + 1);
> > > > > > > > > +__atomic_add_fetch(&buf->refcnt, 1,
> > > > > > > > > __ATOMIC_ACQUIRE);
> > > > >
> > > > > The atomic load in MLX5_ASSERT() accesses the same memory space
> > > > > as the previous __atomic_add_fetch() does.
> > > > > They will access this memory space in the program order when we
> > > > > enabled MLX5_PMD_DEBUG. So the ACQUIRE barrier in
> > > > > __atomic_add_fetch() becomes unnecessary.
> > > > >
> > > > > By changing it to RELAXED ordering, this patch got 7.6%
> > > > > performance improvement on N1 (making it generate A72 alike
> > instructions).
> > > > >
> > > > > Could you please also try it on your testbed, Alex?
> > > >
> > > > Situation got better with this modification, here are the results:
> > > >  - no patch: 3.0 Mpps CPU cycles/packet=51.52
> > > >  - original patch:2.1 Mpps CPU cycles/packet=71.05
> > > >  - modified patch: 2.9 Mpps CPU cycles/packet=52.79 Also, I found
> > > > that the degradation is there only in case I enable bursts stats.
> > >
> > >
> > > Great! So this patch will not hurt the normal datapath performance.
> > >
> > >
> > > > Could you please turn on the following config options and see if
> > > > you can reproduce this as well?
> > > > CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=y
> > > > CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=y
> > >
> > > Thanks, Alex. Some updates.
> > >
> > > Slightly (about 1%) throughput degradation was detected after we
> > > enabled these two config options on N1 SoC.
> > >
> > > If we look insight the perf stats results, with this patch, both
> > > mlx5_rx_burst and mlx5_tx_burst consume fewer CPU cycles than the
> > original code.
> > > However, __memcpy_generic takes more cycles. I think that might be
> > > the reason for CPU cycles per packet increment after applying this patch.
> > >
> > > Original code:
> > > 98.07%--pkt_burst_io_forward
> > > |
> > > |--44.53%--__memcpy_generic
> > > |
> > > |--35.85%--mlx5_rx_burst_mprq
> > > |
> > > |--15.94%--mlx5_tx_burst_none_empw
> > > |  |
> > > |  |--7.32%--mlx5_tx_handle_completion.isra.0
> > > |  |
> > > |   --0.50%--__memcpy_generic
> > > |
> > >  --1.14%--memcpy@plt
> > >
> > > Use C11 with RELAXED ordering:
> > > 99.36%--pkt_burst_io_forward
> > > |
> > > |--47.40%--__memcpy_generic
> > > |
> > > |--34.62%--mlx5_rx_burst_mprq
> > > |
> > > |--15.55%--mlx5_tx_burst_none_empw
> > > |  |
> > > |   --7.08%--mlx5_tx_handle_completion.isra.0
> > > |
> > >  --1.17%--memcpy@plt
> > >
> > > BTW, all the atomic operations in this patch are not the hotspot.
> >
> > Phil, we are seeing much worse degradation on our ARM platform
> > unfortunately.
> > I don't think that discrepancy in memcpy can explain this behavior.
> > Your patch is not touching this area of code. Let me collect some perf
> > stat on our side.
> Are you testing the patch as is or have you made the changes that were
> discussed in the thread?
> 

Yes, I made the changes you suggested. It really gets better with them.
Could you please respin the patch to make sure I got it right in my environment?

> >
> > >
> > > >
> > > > > >
> > > > > > Can you replace just the above line with the following lines and 
> > > > > > test
> it?
> > > > > >
> > > > > > __atomic_add_fetch(&buf->refcnt, 1, __ATOMIC_RELAXED);
> > > > > > __atomic_thread_fence(__ATOMIC_ACQ_REL);
> > > > > >
> > > > > > This should make the generated code same as before this patch.
> > > > > > Let me know if you would prefer us to re-spin the patch
> > > > > > instead (for
> > > testing).
> > > > > >
> > > > > > > > > +MLX5_ASSERT(__atomic_load_n(&buf->refcnt,
> > > > > > > > > +__ATOMIC_RELAXED) <= strd_n + 1);
> > > > > > > > >  buf_addr = RTE_PTR_SUB(addr,
> RTE_PKTMBUF_HEADROOM);
> > > > > > > > >  /*
> > > > > > > > >   * MLX5 device doesn't use iova but it is necessary in
> > > > > > > > > a
> > > > > > > > diff
> > > > > > > > > --git a/drivers/net/mlx5/mlx5_rxtx.h
> > > > > > > > > b/drivers/net/mlx5/mlx5_rxtx.h index 26621ff..0fc15f3
> > > > > > >

Re: [dpdk-dev] [PATCH 0/6] bnxt bug fixes

[Ajit Khaparde]

On Thu, Aug 27, 2020 at 9:46 PM Kalesh A P <
kalesh-anakkur.pura...@broadcom.com> wrote:

> From: Kalesh AP 
>
> This patchset contains bnxt bug fixes.
>
Patchset applied to dpdk-next-net-brcm. Thanks


>
> Kalesh AP (5):
>   net/bnxt: fix endianness while setting L4 destination port
>   net/bnxt: fix to initialize structure variable
>   net/bnxt: fix a possible segfault in vector mode Tx path
>   net/bnxt: fix L2 filter alloc
>   net/bnxt: fix speed setting on BCM957508-N2100 adapters
>
> Venkat Duvvuru (1):
>   net/bnxt: fix LRO configuration
>
>  drivers/net/bnxt/bnxt.h   |  4 
>  drivers/net/bnxt/bnxt_ethdev.c| 44
> +++
>  drivers/net/bnxt/bnxt_hwrm.c  | 15 
>  drivers/net/bnxt/bnxt_ring.c  |  1 +
>  drivers/net/bnxt/bnxt_rxr.c   |  3 +++
>  drivers/net/bnxt/bnxt_rxtx_vec_neon.c |  2 ++
>  drivers/net/bnxt/bnxt_rxtx_vec_sse.c  |  2 ++
>  drivers/net/bnxt/bnxt_txr.c   |  2 ++
>  8 files changed, 53 insertions(+), 20 deletions(-)
>
> --
> 2.10.1
>
>

Re: [dpdk-dev] [PATCH v3 0/4] bnxt patches

[Ajit Khaparde]

On Tue, Sep 1, 2020 at 10:31 PM Ajit Khaparde 
wrote:

> fixes and cleanups in bnxt TRUFlow
>
> v1->v2: updated signed-off tags in commit logs.
> v2->v3: update commit logs based on review comments.
>
Patchset applied to dpdk-next-net-brcm.


>
> Kishore Padmanabha (2):
>   net/bnxt: configure loopback parif for egress flows
>   net/bnxt: lookup default action record parif
>
> Somnath Kotur (1):
>   net/bnxt: cleanups and checks ULP context allocation
>
> Venkat Duvvuru (1):
>   net/bnxt: fix VF representor port add
>
>  drivers/net/bnxt/bnxt.h   |  21 ++
>  drivers/net/bnxt/bnxt_cpr.c   |  51 +++
>  drivers/net/bnxt/bnxt_ethdev.c|  12 +-
>  drivers/net/bnxt/bnxt_hwrm.c  |   4 +
>  drivers/net/bnxt/bnxt_hwrm.h  |   2 +
>  drivers/net/bnxt/bnxt_reps.c  |  88 +++--
>  drivers/net/bnxt/tf_ulp/bnxt_ulp.c|   2 +
>  drivers/net/bnxt/tf_ulp/ulp_def_rules.c   |   2 +-
>  drivers/net/bnxt/tf_ulp/ulp_rte_parser.c  |   6 +
>  .../net/bnxt/tf_ulp/ulp_template_db_class.c   | 314 +++---
>  .../net/bnxt/tf_ulp/ulp_template_db_enum.h|   3 +-
>  11 files changed, 356 insertions(+), 149 deletions(-)
>
> --
> 2.21.1 (Apple Git-122.3)
>
>

Re: [dpdk-dev] [PATCH 00/11] updates for hns3 PMD driver

[Wei Hu (Xavier)]

Hi, all

   Are there any comments?

Thanks

Xavier

On 2020/8/25 19:52, Wei Hu (Xavier) wrote:

This series are features and fixes for hns3 PMD driver.

Huisong Li (3):
   net/hns3: replace private macro with RTE MAX
   net/hns3: fix default MAC addr from firmware
   net/hns3: fix some incomplete command structures

Wei Hu (Xavier) (8):
   net/hns3: get device capability from firmware
   net/hns3: get dev specifications from firmware
   net/hns3: compatibility issues about Rx interrupts
   net/hns3: compatibility issues about Tx padding short frame
   net/hns3: add more hardware error types
   net/hns3: support a maximun 256 FDIR counter
   net/hns3: change the log level to INFO
   net/hns3: fix Rx/Tx queue offload capability

  drivers/net/hns3/hns3_cmd.c   |   36 +-
  drivers/net/hns3/hns3_cmd.h   |   94 ++-
  drivers/net/hns3/hns3_dcb.c   |1 -
  drivers/net/hns3/hns3_dcb.h   |   14 +-
  drivers/net/hns3/hns3_ethdev.c|  187 -
  drivers/net/hns3/hns3_ethdev.h|  138 +++-
  drivers/net/hns3/hns3_ethdev_vf.c |  124 ++-
  drivers/net/hns3/hns3_fdir.c  |5 +
  drivers/net/hns3/hns3_intr.c  | 1236 -
  drivers/net/hns3/hns3_intr.h  |   40 +-
  drivers/net/hns3/hns3_regs.h  |7 +
  drivers/net/hns3/hns3_rxtx.c  |   31 +-
  drivers/net/hns3/hns3_rxtx.h  |   11 +-
  drivers/net/hns3/hns3_stats.c |   78 +-
  drivers/net/hns3/hns3_stats.h |2 +
  15 files changed, 1666 insertions(+), 338 deletions(-)

Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add a field for rxq info structure

[Chengchang Tang]

Hi, Matan

On 2020/9/2 18:30, Matan Azrad wrote:
> Hi Chengchang
> 
> From: Chengchang Tang
>> Hi, Matan
>>
>> On 2020/9/2 15:19, Matan Azrad wrote:
>>>
>>> Hi Chengchang
>>>
>>> From: Chengchang Tang
 Hi, Matan

 On 2020/9/1 23:33, Matan Azrad wrote:
>
> Hi Chengchang
>
> Please see some question below.
>
> From: Chengchang Tang
>> Add a field named rx_buf_size in rte_eth_rxq_info to indicate the
>> buffer size used in receiving packets for HW.
>>
>> In this way, upper-layer users can get this information by calling
>> rte_eth_rx_queue_info_get.
>>
>> Signed-off-by: Chengchang Tang 
>> Reviewed-by: Wei Hu (Xavier) 
>> Acked-by: Andrew Rybchenko 
>> ---
>>  lib/librte_ethdev/rte_ethdev.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/lib/librte_ethdev/rte_ethdev.h
>> b/lib/librte_ethdev/rte_ethdev.h index 70295d7..9fed5cb 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -1420,6 +1420,8 @@ struct rte_eth_rxq_info {
>> struct rte_eth_rxconf conf; /**< queue config parameters. */
>> uint8_t scattered_rx;   /**< scattered packets RX supported. 
>> */
>> uint16_t nb_desc;   /**< configured number of RXDs. */
>> +   /**< buffer size used for hardware when receive packets. */
>> +   uint16_t rx_buf_size;
>
> Is it the maximum supported Rx buffer by the HW?
> If yes, maybe max_rx_buf_size is better name?

 No, it is the Rx buffer size currently used by HW.
> 
>>> Doesn't it defined by the user? Using Rx queue mem-pool mbuf room size?
>>>
>>> And it may be different per Rx queue
>>
>> Yes, it is defined by user using the Rx queue mem-pool mbuf room size.
>> When different queues are bound to different mempools, different queues
>> may have different value.
>>>
 IMHO, the structure rte_eth_rxq_info and associated query API are
 mainly used to query HW configurations at runtime or after queue is
 configured/setup. Therefore, the content of this structure should be
 the current HW configuration.
>>>
>>> It looks me more like capabilities...
>>> The one which define the current configuration is the user by the
>> configuration APIs(after reading the capabilities).
>>
>> I prefer to consider the structure rte_eth_dev_info as the capabilities.
> 
> Yes.
> 
>> Because rxq_info and associated APIs are not available until the queue is
>> configured. And the max rx_buf_size is already exists in dev_info.
>>>
>>> I don't think we have here all the current configurations, so what is 
>>> special
>> in this one?
>>
>> I think the structure is used to store the queue-related configuration,
>> especially the final HW configuration that may be different from user
>> configuration and some configurations that are not mandatory for the
>> user(PMDs will use a default configuration). Such as the scatterred_rx and
>> rx_drop_en in rte_eth_rxconf, some PMDs will adjust it in some cases based
>> on their HW constraints.
> 
> Ok, this struct(struct rte_eth_rxq_info) is new for me.
> Thanks for the explanation.
>  
>> This configuration item meets the above criteria. The value range of
>> rx_buf_size varies according to HW. Some HW may require 1k-alignment,
>> while others may require several fixed values. So, the PMDs will configure it
>> based on their HW constraints. This results in difference between the user
>> configuration and the actual configuration and this value affects the memory
>> usage and performance.
>> I think there's a need for a way to expose that information.
> 
> So the user can configure X and the driver will use Y!=X?

Yes, it depends on the HW. In the queue setup API, it just checks whether the 
input is greater
than the required minimum value. But HW usually has requirements for alignment 
and so on.
So when X does not meet these requirements, PMDs will calculate a new value Y 
that meets these
requirements to configure the hardware (Y <= X, to ensure no memory overflow 
occurs).
> 
> Should the application validate its own configurations after setting them 
> successfully?

It depends on their own needs. The application should not be forced to verify 
it to avoid affecting
the ease of use of PMDs. For some applications, they don't care about this 
value.
> 
>>>
> Maybe document that 0 means - no limitation by HW?

 Yes, there is no need to fill this filed for HW that has no restrictions 
 on it.
 I'll add it in v4.

> Must application read it in order to know if its datapath should
> handle
 multi-segment buffers?

 I think it's more appropriate to use scattered_rx to determine if
 multi- segment buffers should be handled.

>
> Maybe it will be good to force application to configure scatter when
> this
 field is valid and smaller than max_rx_pkt_len\max_lro.. (<= room size)..

Re: [dpdk-dev] [PATCH] net/iavf: fix mismatch command

[Yang, Qiming]

> -Original Message-
> From: Jiang, JunyuX 
> Sent: 2020年9月1日 16:15
> To: dev@dpdk.org
> Cc: Xing, Beilei ; Wu, Jingjing 
> ;
> Yang, Qiming ; Jiang, JunyuX
> ; sta...@dpdk.org
> Subject: [PATCH] net/iavf: fix mismatch command
> 
> The "command mismatch" warning shouldn't be triggered by
> VIRTCHNL_OP_EVENT opcode, because the VIRTCHNL_OP_EVENT opcode is
> used by PF notifies status change events to VF.
> This patch fixed the issue.
> 
> Fixes: 837c2ed86e4c ("net/iavf: return error if opcode is mismatched")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Junyu Jiang 
> ---
>  drivers/net/iavf/iavf_vchnl.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c 
> index
> 33acea54a..331018f14 100644
> --- a/drivers/net/iavf/iavf_vchnl.c
> +++ b/drivers/net/iavf/iavf_vchnl.c
> @@ -53,8 +53,11 @@ iavf_read_msg_from_pf(struct iavf_adapter *adapter,
> uint16_t buf_len,
>   opcode, vf->cmd_retval);
> 
>   if (opcode != vf->pend_cmd) {
> - PMD_DRV_LOG(WARNING, "command mismatch, expect %u,
> get %u",
> - vf->pend_cmd, opcode);
> + if (opcode != VIRTCHNL_OP_EVENT) {
> + PMD_DRV_LOG(WARNING,
> + "command mismatch, expect %u, get %u",
> + vf->pend_cmd, opcode);
> + }
>   return IAVF_ERR_OPCODE_MISMATCH;
>   }
> 
> --
> 2.17.1
Reviewed-by: Qiming Yang 

Re: [dpdk-dev] [PATCH v3 02/11] baseband/acc100: add register definition file

[Xu, Rosen]

Hi,

> -Original Message-
> From: Chautru, Nicolas 
> Sent: Sunday, August 30, 2020 1:40
> To: Xu, Rosen ; dev@dpdk.org; akhil.go...@nxp.com
> Cc: Richardson, Bruce 
> Subject: RE: [dpdk-dev] [PATCH v3 02/11] baseband/acc100: add register
> definition file
> 
> Hi Rosen,
> 
> > From: Xu, Rosen 
> >
> > Hi,
> >
> > > -Original Message-
> > > From: dev  On Behalf Of Nicolas Chautru
> > > Sent: Wednesday, August 19, 2020 8:25
> > > To: dev@dpdk.org; akhil.go...@nxp.com
> > > Cc: Richardson, Bruce ; Chautru, Nicolas
> > > 
> > > Subject: [dpdk-dev] [PATCH v3 02/11] baseband/acc100: add register
> > > definition file
> > >
> > > Add in the list of registers for the device and related
> > > HW specs definitions.
> > >
> > > Signed-off-by: Nicolas Chautru 
> > > ---
> > >  drivers/baseband/acc100/acc100_pf_enum.h | 1068
> > > ++
> > >  drivers/baseband/acc100/acc100_vf_enum.h |   73 ++
> > >  drivers/baseband/acc100/rte_acc100_pmd.h |  490 ++
> > >  3 files changed, 1631 insertions(+)
> > >  create mode 100644 drivers/baseband/acc100/acc100_pf_enum.h
> > >  create mode 100644 drivers/baseband/acc100/acc100_vf_enum.h
> > >
> > > diff --git a/drivers/baseband/acc100/acc100_pf_enum.h
> > > b/drivers/baseband/acc100/acc100_pf_enum.h
> > > new file mode 100644
> > > index 000..a1ee416
> > > --- /dev/null
> > > +++ b/drivers/baseband/acc100/acc100_pf_enum.h
> > > @@ -0,0 +1,1068 @@
> > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > + * Copyright(c) 2017 Intel Corporation
> > > + */
> > > +
> > > +#ifndef ACC100_PF_ENUM_H
> > > +#define ACC100_PF_ENUM_H
> > > +
> > > +/*
> > > + * ACC100 Register mapping on PF BAR0
> > > + * This is automatically generated from RDL, format may change with
> new
> > > RDL
> > > + * Release.
> > > + * Variable names are as is
> > > + */
> > > +enum {
> > > + HWPfQmgrEgressQueuesTemplate  =  0x0007FE00,
> > > + HWPfQmgrIngressAq =  0x0008,
> > > + HWPfQmgrArbQAvail =  0x00A00010,
> > > + HWPfQmgrArbQBlock =  0x00A00014,
> > > + HWPfQmgrAqueueDropNotifEn =  0x00A00024,
> > > + HWPfQmgrAqueueDisableNotifEn  =  0x00A00028,
> > > + HWPfQmgrSoftReset =  0x00A00038,
> > > + HWPfQmgrInitStatus=  0x00A0003C,
> > > + HWPfQmgrAramWatchdogCount =  0x00A00040,
> > > + HWPfQmgrAramWatchdogCounterEn =  0x00A00044,
> > > + HWPfQmgrAxiWatchdogCount  =  0x00A00048,
> > > + HWPfQmgrAxiWatchdogCounterEn  =  0x00A0004C,
> > > + HWPfQmgrProcessWatchdogCount  =  0x00A00050,
> > > + HWPfQmgrProcessWatchdogCounterEn  =  0x00A00054,
> > > + HWPfQmgrProcessUl4GWatchdogCounter=  0x00A00058,
> > > + HWPfQmgrProcessDl4GWatchdogCounter=  0x00A0005C,
> > > + HWPfQmgrProcessUl5GWatchdogCounter=  0x00A00060,
> > > + HWPfQmgrProcessDl5GWatchdogCounter=  0x00A00064,
> > > + HWPfQmgrProcessMldWatchdogCounter =  0x00A00068,
> > > + HWPfQmgrMsiOverflowUpperVf=  0x00A00070,
> > > + HWPfQmgrMsiOverflowLowerVf=  0x00A00074,
> > > + HWPfQmgrMsiWatchdogOverflow   =  0x00A00078,
> > > + HWPfQmgrMsiOverflowEnable =  0x00A0007C,
> > > + HWPfQmgrDebugAqPointerMemGrp  =  0x00A00100,
> > > + HWPfQmgrDebugOutputArbQFifoGrp=  0x00A00140,
> > > + HWPfQmgrDebugMsiFifoGrp   =  0x00A00180,
> > > + HWPfQmgrDebugAxiWdTimeoutMsiFifo  =  0x00A001C0,
> > > + HWPfQmgrDebugProcessWdTimeoutMsiFifo  =  0x00A001C4,
> > > + HWPfQmgrDepthLog2Grp  =  0x00A00200,
> > > + HWPfQmgrTholdGrp  =  0x00A00300,
> > > + HWPfQmgrGrpTmplateReg0Indx=  0x00A00600,
> > > + HWPfQmgrGrpTmplateReg1Indx=  0x00A00680,
> > > + HWPfQmgrGrpTmplateReg2indx=  0x00A00700,
> > > + HWPfQmgrGrpTmplateReg3Indx=  0x00A00780,
> > > + HWPfQmgrGrpTmplateReg4Indx=  0x00A00800,
> > > + HWPfQmgrVfBaseAddr=  0x00A01000,
> > > + HWPfQmgrUl4GWeightRrVf=  0x00A02000,
> > > + HWPfQmgrDl4GWeightRrVf=  0x00A02100,
> > > + HWPfQmgrUl5GWeightRrVf=  0x00A02200,
> > > + HWPfQmgrDl5GWeightRrVf=  0x00A02300,
> > > + HWPfQmgrMldWeightRrVf =  0x00A02400,
> > > + HWPfQmgrArbQDepthGrp  =  0x00A02F00,
> > > + HWPfQmgrGrpFunction0  =  0x00A02F40,
> > > + HWPfQmgrGrpFunction1  =  0x00A02F44,
> > > + HWPfQmgrGrpPriority   =  0x00A02F48,
> > > + HWPfQmgrWeightSync=  0x00A03000,
> > > + HWPfQmgrAqEnableVf=  0x00A1,
> > > + HWPfQmgrAqResetVf =  0x00A2,
> > > + HWPfQmgrRingSizeVf=  0x00A20004,
> > > + HWPfQmgrGrpDepthLog20Vf   =  0x00A20008,
> > > + HWPfQmgrGrpDepthLog21Vf   =  0x00A2000C,
> > > + HWPfQmgrGrpFunctio

Re: [dpdk-dev] [PATCH] net/ixgbe: fix vf reset hw error handling

[Yang, Qiming]

Hi,

> -Original Message-
> From: Yang, SteveX 
> Sent: 2020年9月2日 8:44
> To: dev@dpdk.org
> Cc: Zhao1, Wei ; Guo, Jia ; Yang,
> Qiming ; Yang, SteveX 
> Subject: [PATCH] net/ixgbe: fix vf reset hw error handling
> 
> The PF control message will interrupt the assigning MAC address for VF when
> PF physical link down, and the VF reset operation returns the
> IXGBE_ERR_INVALID_MAC_ADDR. In this case, reuses the MAC address from
> eth_ixgbevf_dev_init() directly, no need care of PF assignment.

Better do not use function name.
Reuse the MAC address when device initialization instead of waiting PF reassign.

> 
> Fixes: f69166c9a3c9 ("net/ixgbe: fix reset error handling")
> 
> Signed-off-by: SteveX Yang 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index fd0cb9b0e..c2fa59c73 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -5326,10 +5326,17 @@ ixgbevf_dev_start(struct rte_eth_dev *dev)
>   ixgbe_dev_wait_setup_link_complete(dev, 0);
> 
>   err = hw->mac.ops.reset_hw(hw);
> - if (err) {
> +
> + /*
> +  * The VF reset operation returns the
> IXGBE_ERR_INVALID_MAC_ADDR when
> +  * the underlying PF driver has not assigned a MAC address to the VF.
> +  * In this case, reuses the MAC address from eth_ixgbevf_dev_init().
> +  */
> + if (err != IXGBE_SUCCESS && err != IXGBE_ERR_INVALID_MAC_ADDR)

Is there any other cases will also caused IXGBE_ERR_INVALID_MAC_ADDR?

> {
>   PMD_INIT_LOG(ERR, "Unable to reset vf hardware (%d)", err);
>   return err;
>   }
> +
>   hw->mac.get_link_status = true;
> 
>   /* negotiate mailbox API version to use with the PF. */
> --
> 2.17.1

Re: [dpdk-dev] [PATCH v3 04/11] baseband/acc100: add queue configuration

[Xu, Rosen]

Hi,

> -Original Message-
> From: Chautru, Nicolas 
> Sent: Sunday, August 30, 2020 1:48
> To: Xu, Rosen ; dev@dpdk.org; akhil.go...@nxp.com
> Cc: Richardson, Bruce 
> Subject: RE: [dpdk-dev] [PATCH v3 04/11] baseband/acc100: add queue
> configuration
> 
> Hi,
> 
> > From: Xu, Rosen 
> >
> > Hi,
> >
> > > -Original Message-
> > > From: dev  On Behalf Of Nicolas Chautru
> > > Sent: Wednesday, August 19, 2020 8:25
> > > To: dev@dpdk.org; akhil.go...@nxp.com
> > > Cc: Richardson, Bruce ; Chautru, Nicolas
> > > 
> > > Subject: [dpdk-dev] [PATCH v3 04/11] baseband/acc100: add queue
> > > configuration
> > >
> > > Adding function to create and configure queues for the device. Still
> > > no capability.
> > >
> > > Signed-off-by: Nicolas Chautru 
> > > ---
> > >  drivers/baseband/acc100/rte_acc100_pmd.c | 420
> > > ++-
> > > drivers/baseband/acc100/rte_acc100_pmd.h |  45 
> > >  2 files changed, 464 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> > > b/drivers/baseband/acc100/rte_acc100_pmd.c
> > > index 7807a30..7a21c57 100644
> > > --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> > > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> > > @@ -26,6 +26,22 @@
> > >  RTE_LOG_REGISTER(acc100_logtype, pmd.bb.acc100, NOTICE);  #endif
> > >
> > > +/* Write to MMIO register address */ static inline void
> > > +mmio_write(void *addr, uint32_t value) {
> > > + *((volatile uint32_t *)(addr)) = rte_cpu_to_le_32(value); }
> > > +
> > > +/* Write a register of a ACC100 device */ static inline void
> > > +acc100_reg_write(struct acc100_device *d, uint32_t offset, uint32_t
> > > +payload) {
> > > + void *reg_addr = RTE_PTR_ADD(d->mmio_base, offset);
> > > + mmio_write(reg_addr, payload);
> > > + usleep(1000);
> > > +}
> > > +
> > >  /* Read a register of a ACC100 device */  static inline uint32_t
> > > acc100_reg_read(struct acc100_device *d, uint32_t offset) @@ -36,6
> > > +52,22 @@
> > >   return rte_le_to_cpu_32(ret);
> > >  }
> > >
> > > +/* Basic Implementation of Log2 for exact 2^N */ static inline
> > > +uint32_t log2_basic(uint32_t value) {
> > > + return (value == 0) ? 0 : __builtin_ctz(value); }
> > > +
> > > +/* Calculate memory alignment offset assuming alignment is 2^N */
> > > +static inline uint32_t calc_mem_alignment_offset(void
> > > +*unaligned_virt_mem, uint32_t alignment) {
> > > + rte_iova_t unaligned_phy_mem =
> > > rte_malloc_virt2iova(unaligned_virt_mem);
> > > + return (uint32_t)(alignment -
> > > + (unaligned_phy_mem & (alignment-1))); }
> > > +
> > >  /* Calculate the offset of the enqueue register */  static inline
> > > uint32_t queue_offset(bool pf_device, uint8_t vf_id, uint8_t
> > > qgrp_id, uint16_t aq_id) @@ -204,10 +236,393 @@
> > >   acc100_conf->q_dl_5g.aq_depth_log2);
> > >  }
> > >
> > > +static void
> > > +free_base_addresses(void **base_addrs, int size) {
> > > + int i;
> > > + for (i = 0; i < size; i++)
> > > + rte_free(base_addrs[i]);
> > > +}
> > > +
> > > +static inline uint32_t
> > > +get_desc_len(void)
> > > +{
> > > + return sizeof(union acc100_dma_desc); }
> > > +
> > > +/* Allocate the 2 * 64MB block for the sw rings */ static int
> > > +alloc_2x64mb_sw_rings_mem(struct rte_bbdev *dev, struct
> > > +acc100_device
> > > *d,
> > > + int socket)
> > > +{
> > > + uint32_t sw_ring_size = ACC100_SIZE_64MBYTE;
> > > + d->sw_rings_base = rte_zmalloc_socket(dev->device->driver-
> > > >name,
> > > + 2 * sw_ring_size, RTE_CACHE_LINE_SIZE, socket);
> > > + if (d->sw_rings_base == NULL) {
> > > + rte_bbdev_log(ERR, "Failed to allocate memory for %s:%u",
> > > + dev->device->driver->name,
> > > + dev->data->dev_id);
> > > + return -ENOMEM;
> > > + }
> > > + memset(d->sw_rings_base, 0, ACC100_SIZE_64MBYTE);
> > > + uint32_t next_64mb_align_offset = calc_mem_alignment_offset(
> > > + d->sw_rings_base, ACC100_SIZE_64MBYTE);
> > > + d->sw_rings = RTE_PTR_ADD(d->sw_rings_base,
> > > next_64mb_align_offset);
> > > + d->sw_rings_phys = rte_malloc_virt2iova(d->sw_rings_base) +
> > > + next_64mb_align_offset;
> > > + d->sw_ring_size = MAX_QUEUE_DEPTH * get_desc_len();
> > > + d->sw_ring_max_depth = d->sw_ring_size / get_desc_len();
> > > +
> > > + return 0;
> > > +}
> >
> > Why not a common alloc memory function but special function for
> > different memory size?
> 
> This is a bit convoluted but due to the fact the first attempt method which is
> optimal (minimum) may not always find aligned memory.

What's convoluted? Can you explain?
For packet processing, in most scenarios, aren't we aligned memory when we 
alloc memory?
> 
> >
> > > +/* Attempt to allocate minimised memory space for sw rings */
> > > +static void alloc_sw_rings_min_mem(struct rte_bbdev *dev, struct
> > > acc100_device
> > > +*d,
> > > + uint16_t num_queues, int socket)
> 

Re: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC processing functions

[Xu, Rosen]

Hi,

> -Original Message-
> From: Chautru, Nicolas 
> Sent: Sunday, August 30, 2020 2:01
> To: Xu, Rosen ; dev@dpdk.org; akhil.go...@nxp.com
> Cc: Richardson, Bruce 
> Subject: RE: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC
> processing functions
> 
> Hi Rosen,
> 
> > From: Xu, Rosen 
> >
> > Hi,
> >
> > > -Original Message-
> > > From: dev  On Behalf Of Nicolas Chautru
> > > Sent: Wednesday, August 19, 2020 8:25
> > > To: dev@dpdk.org; akhil.go...@nxp.com
> > > Cc: Richardson, Bruce ; Chautru, Nicolas
> > > 
> > > Subject: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC
> > > processing functions
> > >
> > > Adding LDPC decode and encode processing operations
> > >
> > > Signed-off-by: Nicolas Chautru 
> > > ---
> > >  drivers/baseband/acc100/rte_acc100_pmd.c | 1625
> > > +-
> > >  drivers/baseband/acc100/rte_acc100_pmd.h |3 +
> > >  2 files changed, 1626 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> > > b/drivers/baseband/acc100/rte_acc100_pmd.c
> > > index 7a21c57..5f32813 100644
> > > --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> > > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> > > @@ -15,6 +15,9 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#ifdef RTE_BBDEV_OFFLOAD_COST
> > > +#include 
> > > +#endif
> > >
> > >  #include 
> > >  #include 
> > > @@ -449,7 +452,6 @@
> > >   return 0;
> > >  }
> > >
> > > -
> > >  /**
> > >   * Report a ACC100 queue index which is free
> > >   * Return 0 to 16k for a valid queue_idx or -1 when no queue is
> > > available @@ -634,6 +636,46 @@
> > >   struct acc100_device *d = dev->data->dev_private;
> > >
> > >   static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
> > > + {
> > > + .type   = RTE_BBDEV_OP_LDPC_ENC,
> > > + .cap.ldpc_enc = {
> > > + .capability_flags =
> > > + RTE_BBDEV_LDPC_RATE_MATCH |
> > > + RTE_BBDEV_LDPC_CRC_24B_ATTACH
> > > |
> > > +
> > >   RTE_BBDEV_LDPC_INTERLEAVER_BYPASS,
> > > + .num_buffers_src =
> > > +
> > >   RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> > > + .num_buffers_dst =
> > > +
> > >   RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> > > + }
> > > + },
> > > + {
> > > + .type   = RTE_BBDEV_OP_LDPC_DEC,
> > > + .cap.ldpc_dec = {
> > > + .capability_flags =
> > > + RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
> > > + RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
> > > +
> > >   RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
> > > +
> > >   RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
> > > +#ifdef ACC100_EXT_MEM
> > > +
> > >   RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE |
> > > +
> > >   RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE |
> > > +#endif
> > > +
> > >   RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE |
> > > + RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS
> > > |
> > > + RTE_BBDEV_LDPC_DECODE_BYPASS |
> > > + RTE_BBDEV_LDPC_DEC_SCATTER_GATHER |
> > > +
> > >   RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION |
> > > + RTE_BBDEV_LDPC_LLR_COMPRESSION,
> > > + .llr_size = 8,
> > > + .llr_decimals = 1,
> > > + .num_buffers_src =
> > > +
> > >   RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> > > + .num_buffers_hard_out =
> > > +
> > >   RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> > > + .num_buffers_soft_out = 0,
> > > + }
> > > + },
> > >   RTE_BBDEV_END_OF_CAPABILITIES_LIST()
> > >   };
> > >
> > > @@ -669,9 +711,14 @@
> > >   dev_info->cpu_flag_reqs = NULL;
> > >   dev_info->min_alignment = 64;
> > >   dev_info->capabilities = bbdev_capabilities;
> > > +#ifdef ACC100_EXT_MEM
> > >   dev_info->harq_buffer_size = d->ddr_size;
> > > +#else
> > > + dev_info->harq_buffer_size = 0;
> > > +#endif
> > >  }
> > >
> > > +
> > >  static const struct rte_bbdev_ops acc100_bbdev_ops = {
> > >   .setup_queues = acc100_setup_queues,
> > >   .close = acc100_dev_close,
> > > @@ -696,6 +743,1577 @@
> > >   {.device_id = 0},
> > >  };
> > >
> > > +/* Read flag value 0/1 from bitmap */ static inline bool
> > > +check_bit(uint32_t bitmap, uint32_t bitmask) {
> > > + return bitmap & bitmask;
> > > +}
> > > +
> > > +static inline char *
> > > +mbuf_append(struct rte_mbuf *m_head, struct rte_mbuf *m, uint16_t
> > > +len) {
> > > + if (unlikely(len > rte_pktmbuf_tailroom(m)))
> > > + return NULL;
> > > +
> > > + char *tail = (char *)m->buf_addr + m->data_off + m->data_len;
> > > + m->data_len = (uint16_t)(m->data_len + len);
> > > + m_head->pkt_len  = (m_head->pkt_len + len);
> > > + return tail;
> > > +}
> >
> > Is it reasonable to direct add data_len of rte_mbuf?
> >
> 
> Do you suggest to add directly wi

[dpdk-dev] [PATCH v4] net/mlx5: relaxed ordering for multi-packet RQ buffer refcnt

[Phil Yang]

Use c11 atomics with RELAXED ordering instead of the rte_atomic ops
which enforce unnecessary barriers on aarch64.

Signed-off-by: Phil Yang 
---
v4:
Remove the unnecessary ACQUIRE barrier in rx burst path. (Honnappa)

v3:
Split from the patchset:
http://patchwork.dpdk.org/cover/68159/

 drivers/net/mlx5/mlx5_rxq.c  |  2 +-
 drivers/net/mlx5/mlx5_rxtx.c | 16 +---
 drivers/net/mlx5/mlx5_rxtx.h |  2 +-
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 79eb8f8..40e0239 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -2012,7 +2012,7 @@ mlx5_mprq_buf_init(struct rte_mempool *mp, void 
*opaque_arg,
 
memset(_m, 0, sizeof(*buf));
buf->mp = mp;
-   rte_atomic16_set(&buf->refcnt, 1);
+   __atomic_store_n(&buf->refcnt, 1, __ATOMIC_RELAXED);
for (j = 0; j != strd_n; ++j) {
shinfo = &buf->shinfos[j];
shinfo->free_cb = mlx5_mprq_buf_free_cb;
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 1b71e94..549477b 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -1626,10 +1626,11 @@ mlx5_mprq_buf_free_cb(void *addr __rte_unused, void 
*opaque)
 {
struct mlx5_mprq_buf *buf = opaque;
 
-   if (rte_atomic16_read(&buf->refcnt) == 1) {
+   if (__atomic_load_n(&buf->refcnt, __ATOMIC_RELAXED) == 1) {
rte_mempool_put(buf->mp, buf);
-   } else if (rte_atomic16_add_return(&buf->refcnt, -1) == 0) {
-   rte_atomic16_set(&buf->refcnt, 1);
+   } else if (unlikely(__atomic_sub_fetch(&buf->refcnt, 1,
+  __ATOMIC_RELAXED) == 0)) {
+   __atomic_store_n(&buf->refcnt, 1, __ATOMIC_RELAXED);
rte_mempool_put(buf->mp, buf);
}
 }
@@ -1709,7 +1710,8 @@ mlx5_rx_burst_mprq(void *dpdk_rxq, struct rte_mbuf 
**pkts, uint16_t pkts_n)
 
if (consumed_strd == strd_n) {
/* Replace WQE only if the buffer is still in use. */
-   if (rte_atomic16_read(&buf->refcnt) > 1) {
+   if (__atomic_load_n(&buf->refcnt,
+   __ATOMIC_RELAXED) > 1) {
mprq_buf_replace(rxq, rq_ci & wq_mask, strd_n);
/* Release the old buffer. */
mlx5_mprq_buf_free(buf);
@@ -1821,9 +1823,9 @@ mlx5_rx_burst_mprq(void *dpdk_rxq, struct rte_mbuf 
**pkts, uint16_t pkts_n)
void *buf_addr;
 
/* Increment the refcnt of the whole chunk. */
-   rte_atomic16_add_return(&buf->refcnt, 1);
-   MLX5_ASSERT((uint16_t)rte_atomic16_read(&buf->refcnt) <=
-   strd_n + 1);
+   __atomic_add_fetch(&buf->refcnt, 1, __ATOMIC_RELAXED);
+   MLX5_ASSERT(__atomic_load_n(&buf->refcnt,
+   __ATOMIC_RELAXED) <= strd_n + 1);
buf_addr = RTE_PTR_SUB(addr, RTE_PKTMBUF_HEADROOM);
/*
 * MLX5 device doesn't use iova but it is necessary in a
diff --git a/drivers/net/mlx5/mlx5_rxtx.h b/drivers/net/mlx5/mlx5_rxtx.h
index c02a007..467f31d 100644
--- a/drivers/net/mlx5/mlx5_rxtx.h
+++ b/drivers/net/mlx5/mlx5_rxtx.h
@@ -68,7 +68,7 @@ struct rxq_zip {
 /* Multi-Packet RQ buffer header. */
 struct mlx5_mprq_buf {
struct rte_mempool *mp;
-   rte_atomic16_t refcnt; /* Atomically accessed refcnt. */
+   uint16_t refcnt; /* Atomically accessed refcnt. */
uint8_t pad[RTE_PKTMBUF_HEADROOM]; /* Headroom for the first packet. */
struct rte_mbuf_ext_shared_info shinfos[];
/*
-- 
2.7.4

Re: [dpdk-dev] [PATCH v3] net/mlx5: relaxed ordering for multi-packet RQ buffer refcnt

[Phil Yang]

> >
> > > >
> > > > > > > > > > @@ -1790,9 +1792,9 @@ mlx5_rx_burst_mprq(void
> > *dpdk_rxq,
> > > > > > struct
> > > > > > > > > > rte_mbuf **pkts, uint16_t pkts_n)  void *buf_addr;
> > > > > > > > > >
> > > > > > > > > >  /* Increment the refcnt of the whole chunk. */
> > > > > > > > > > -rte_atomic16_add_return(&buf->refcnt, 1);
> > > > > > > rte_atomic16_add_return includes a full barrier along with
> > > > > > > atomic
> > > > > > operation.
> > > > > > > But is full barrier required here? For ex:
> > > > > > > __atomic_add_fetch(&buf->refcnt, 1,
> > > > > > > __ATOMIC_RELAXED) will offer atomicity, but no barrier. Would
> > > > > > > that be enough?
> > > > > > >
> > > > > > > > > > -MLX5_ASSERT((uint16_t)rte_atomic16_read(&buf-
> > > > > > > > > > >refcnt) <=
> > > > > > > > > > -strd_n + 1);
> > > > > > > > > > +__atomic_add_fetch(&buf->refcnt, 1,
> > > > > > > > > > __ATOMIC_ACQUIRE);
> > > > > >
> > > > > > The atomic load in MLX5_ASSERT() accesses the same memory
> space
> > > > > > as the previous __atomic_add_fetch() does.
> > > > > > They will access this memory space in the program order when we
> > > > > > enabled MLX5_PMD_DEBUG. So the ACQUIRE barrier in
> > > > > > __atomic_add_fetch() becomes unnecessary.
> > > > > >
> > > > > > By changing it to RELAXED ordering, this patch got 7.6%
> > > > > > performance improvement on N1 (making it generate A72 alike
> > > instructions).
> > > > > >
> > > > > > Could you please also try it on your testbed, Alex?
> > > > >
> > > > > Situation got better with this modification, here are the results:
> > > > >  - no patch: 3.0 Mpps CPU cycles/packet=51.52
> > > > >  - original patch:2.1 Mpps CPU cycles/packet=71.05
> > > > >  - modified patch: 2.9 Mpps CPU cycles/packet=52.79 Also, I found
> > > > > that the degradation is there only in case I enable bursts stats.
> > > >
> > > >
> > > > Great! So this patch will not hurt the normal datapath performance.
> > > >
> > > >
> > > > > Could you please turn on the following config options and see if
> > > > > you can reproduce this as well?
> > > > > CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=y
> > > > > CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=y
> > > >
> > > > Thanks, Alex. Some updates.
> > > >
> > > > Slightly (about 1%) throughput degradation was detected after we
> > > > enabled these two config options on N1 SoC.
> > > >
> > > > If we look insight the perf stats results, with this patch, both
> > > > mlx5_rx_burst and mlx5_tx_burst consume fewer CPU cycles than the
> > > original code.
> > > > However, __memcpy_generic takes more cycles. I think that might be
> > > > the reason for CPU cycles per packet increment after applying this
> patch.
> > > >
> > > > Original code:
> > > > 98.07%--pkt_burst_io_forward
> > > > |
> > > > |--44.53%--__memcpy_generic
> > > > |
> > > > |--35.85%--mlx5_rx_burst_mprq
> > > > |
> > > > |--15.94%--mlx5_tx_burst_none_empw
> > > > |  |
> > > > |  |--7.32%--mlx5_tx_handle_completion.isra.0
> > > > |  |
> > > > |   --0.50%--__memcpy_generic
> > > > |
> > > >  --1.14%--memcpy@plt
> > > >
> > > > Use C11 with RELAXED ordering:
> > > > 99.36%--pkt_burst_io_forward
> > > > |
> > > > |--47.40%--__memcpy_generic
> > > > |
> > > > |--34.62%--mlx5_rx_burst_mprq
> > > > |
> > > > |--15.55%--mlx5_tx_burst_none_empw
> > > > |  |
> > > > |   --7.08%--mlx5_tx_handle_completion.isra.0
> > > > |
> > > >  --1.17%--memcpy@plt
> > > >
> > > > BTW, all the atomic operations in this patch are not the hotspot.
> > >
> > > Phil, we are seeing much worse degradation on our ARM platform
> > > unfortunately.
> > > I don't think that discrepancy in memcpy can explain this behavior.
> > > Your patch is not touching this area of code. Let me collect some perf
> > > stat on our side.
> > Are you testing the patch as is or have you made the changes that were
> > discussed in the thread?
> >
> 
> Yes, I made the changes you suggested. It really gets better with them.
> Could you please respin the patch to make sure I got it right in my
> environment?

Thanks, Alex.
Please check the new version here.
http://patchwork.dpdk.org/patch/76335/


> 
> > >
> > > >
> > > > >
> > > > > > >
> > > > > > > Can you replace just the above line with the following lines and
> test
> > it?
> > > > > > >
> > > > > > > __atomic_add_fetch(&buf->refcnt, 1, __ATOMIC_RELAXED);
> > > > > > > __atomic_thread_fence(__ATOMIC_ACQ_REL);
> > > > > > >
> > > > > > > This should make the generated code same as before this patch.
> > > > > > > Let me know if you would prefer us to re-spin the patch
> > > > > > > instead (for
> > > > testing).
> > > > > > >
> > > > > > > > > > +MLX5_ASSERT(__atomic_load_n(&buf->refcnt,
> > > > > > > > > > +__ATOMIC_RELAXED) <= strd_n + 1);
> > > > > > > > > >  buf_add

Re: [dpdk-dev] [PATCH v6 0/2] update CPU flags for arm64 platform

[Wei Hu (Xavier)]

Hi, all

  Are there any other comments?

Thanks

Xavier


On 2020/8/19 18:56, Wei Hu (Xavier) wrote:

This series updates CPU flags for arm64 platform.

Wei Hu (Xavier) (2):
   eal/arm64: update CPU flags
   test/cpuflag: add new flags for ARM64 platform

  app/test/test_cpuflags.c | 39 
  lib/librte_eal/arm/include/rte_cpuflags_64.h | 13 +++
  lib/librte_eal/arm/rte_cpuflags.c| 13 +++
  3 files changed, 65 insertions(+)

Re: [dpdk-dev] [PATCH v2 0/4] minor fixes for testpmd

[Wei Hu (Xavier)]

Hi, all

  Are there any comment?

Thanks

Xavier

On 2020/8/20 9:42, Wei Hu (Xavier) wrote:

This series are minor fixes for testpmd application.

Chengchang Tang (3):
   app/testpmd: fix missing verification of port id
   app/testpmd: fix VLAN offload configuration when config fail
   app/testpmd: fix packet header in txonly mode

Huisong Li (1):
   app/testpmd: fix displaying Rx Tx queues information

  app/test-pmd/cmdline.c |  9 +
  app/test-pmd/config.c  | 80 +++---
  app/test-pmd/txonly.c  | 32 +
  3 files changed, 100 insertions(+), 21 deletions(-)

Re: [dpdk-dev] [PATCH v6 1/8] net/dpaa: add support for fmlib in dpdk

[Hemant Agrawal]

Hi Ferruh,

> -Original Message-
> From: Ferruh Yigit 
> Sent: Wednesday, September 2, 2020 7:02 PM
> >> On 9/1/2020 1:36 PM, Hemant Agrawal wrote:
> >>> DPAA platorm MAC interface is known as FMAN i.e. Frame Manager.
> >>> There are two ways to control it.
> >>> 1. Statically configure the queues and classification rules before
> >>> the start of the application using FMC tool.
> >>> 2. Dynamically configure it within application by making API calls
> >>> of fmlib.
> >>>
> >>> The fmlib or Frame Manager library provides an API on top of the
> >>> Frame Manager driver ioctl calls, that provides a user space
> >>> application with a simple way to configure driver parameters and PCD
> >>> (parse - classify - distribute) rules.
> >>>
> >>> This patch integrates the base fmlib so that various queue config,
> >>> RSS and classification related features can be supported on DPAA
> platform.
> >>>
> >>> Signed-off-by: Sachin Saxena 
> >>> Signed-off-by: Hemant Agrawal 
> >>> ---
> >>>  doc/guides/nics/dpaa.rst  |   52 +-
> >>>  doc/guides/platform/dpaa.rst  |   21 +-
> >>>  drivers/net/dpaa/fmlib/dpaa_integration.h |   50 +
> >>>  drivers/net/dpaa/fmlib/fm_ext.h   |  463 ++
> >>>  drivers/net/dpaa/fmlib/fm_lib.c   |  561 ++
> >>>  drivers/net/dpaa/fmlib/fm_pcd_ext.h   | 5787
> >> +
> >>>  drivers/net/dpaa/fmlib/fm_port_ext.h  | 3350 
> >>>  drivers/net/dpaa/fmlib/ncsw_ext.h |  158 +
> >>>  drivers/net/dpaa/fmlib/net_ext.h  |  411 ++
> >>>  drivers/net/dpaa/meson.build  |3 +-
> >>>  10 files changed, 10849 insertions(+), 7 deletions(-)  create mode
> >>> 100644 drivers/net/dpaa/fmlib/dpaa_integration.h
> >>>  create mode 100644 drivers/net/dpaa/fmlib/fm_ext.h  create mode
> >>> 100644 drivers/net/dpaa/fmlib/fm_lib.c  create mode 100644
> >>> drivers/net/dpaa/fmlib/fm_pcd_ext.h
> >>>  create mode 100644 drivers/net/dpaa/fmlib/fm_port_ext.h
> >>>  create mode 100644 drivers/net/dpaa/fmlib/ncsw_ext.h  create mode
> >>> 100644 drivers/net/dpaa/fmlib/net_ext.h
> >>>
> >>> diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
> >>> index
> >>> 17839a920..7e6010471 100644
> >>> --- a/doc/guides/nics/dpaa.rst
> >>> +++ b/doc/guides/nics/dpaa.rst
> >>> @@ -1,5 +1,5 @@
> >>>  ..  SPDX-License-Identifier: BSD-3-Clause
> >>> -Copyright 2017 NXP
> >>> +Copyright 2017,2020 NXP
> >>>
> >>>
> >>>  DPAA Poll Mode Driver
> >>> @@ -21,6 +21,7 @@ Contents summary
> >>>
> >>>  - DPAA overview
> >>>  - DPAA driver architecture overview
> >>> +- FMAN configuration tools and library
> >>>
> >>>  .. _dpaa_overview:
> >>>
> >>> @@ -285,6 +286,55 @@ for details.
> >>>Done
> >>>testpmd>
> >>>
> >>> +FMAN Config
> >>> +---
> >>> +
> >>> +Frame Manager is also responsible for parser, classify and
> >>> +distribute functionality in the DPAA.
> >>> +
> >>> +   FMAN supports:
> >>> +   Packet parsing at wire speed. It supports standard protocols parsing
> and
> >>> +   identification by HW
> >> (VLAN/IP/UDP/TCP/SCTP/PPPoE/PPP/MPLS/GRE/IPSec).
> >>> +   It supports non-standard UDF header parsing for custom protocols.
> >>> +   Classification / Distribution: Coarse classification based on
> >>> + Key
> >> generation
> >>> +   Hash and exact match lookup
> >>> +
> >>> +FMC - FMAN Configuration Tool
> >>> +~
> >>> +   This tool is available in User Space. The tool is used to configure 
> >>> FMAN
> >>> +   Physical (MAC) or Ephemeral (OH)ports for Parse/Classify/distribute.
> >>> +   The PCDs can be hash based where a set of fields are key input for
> hash
> >>> +   generation within FMAN keygen. The hash value is used to
> >>> +generate a
> >> FQID for
> >>> +   frame. There is a provision to setup exact match lookup too where
> field
> >>> +   values within a packet drives corresponding FQID.
> >>> +   Currently it works on XML file inputs.
> >>> +
> >>> +   Limitations:
> >>> +   1.For Dynamic Configuration change, currently no support is available.
> >>> +   E.g. enable/disable a port, a operator (set of VLANs and associate
> rules).
> >>> +
> >>> +   2.During FMC configuration, port for which policy is being configured
> is
> >>> +   brought down and the policy is flushed on port before new policy
> >>> + is
> >> updated
> >>> +   for the port. Support is required to add/append/delete etc.
> >>> +
> >>> +   3.FMC, being a separate user-space application, needs to be
> >>> + invoked
> >> from
> >>> +   Shell.
> >>> +
> >>> +
> >>> +   The details can be found in FMC Doc at:
> >>> +   `Frame Mnager Configuration Tool
> >>
>  >> w.nxp.com%2Fdocs%2Fen%2Fapplication-
> >>
> note%2FAN4760.pdf&data=02%7C01%7Chemant.agrawal%40nxp.com%
> >>
> 7Cdb7eda614491479976c508d84e8e8c42%7C686ea1d3bc2b4c6fa92cd99c5c30
> >>
> 1635%7C0%7C1%7C637345721434145756&sdata=ynJeLWqw0hPTya5IRt
> >> GviovNA7mAGIZ8k3

Re: [dpdk-dev] [PATCH v4 0/3] fixes for device event

[wangyunjian]

Hi, Ferruh Yigit & David Marchand

Could you please give any suggestion?

Thanks,
Yunjian

> -Original Message-
> From: wangyunjian
> Sent: Friday, July 3, 2020 5:44 PM
> To: dev@dpdk.org
> Cc: jia@intel.com; Lilijun (Jerry) ; xudingke
> ; wangyunjian 
> Subject: [dpdk-dev] [PATCH v4 0/3] fixes for device event
> 
> From: Yunjian Wang 
> 
> This series include three fixes patches for device event.
> 
> ---
> v4:
>  * add fix a wrong returned value
>  * remove redundant check suggested by David Marchand
> 
> v3:
>  * modified the format.
> 
> Yunjian Wang (3):
>   eal: fix memory leak when removing event_cb
>   eal: return error code when failure
>   eal: fix a wrong returned value when callback exists
> 
>  lib/librte_eal/common/eal_common_dev.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> --
> 1.8.3.1
> 

[dpdk-dev] [RFC] ethdev: make rte flow API thread safe

[Suanming Mou]

Currently, the rte flow functions are not defined as thread safety.
DPDK applications either call the functions in single thread or add
locks around the functions for the critical section.

For PMDs support the flow operations thread safe natively, the
redundant protection in application hurts the performance of the
rte flow operation functions.

And the restriction of thread safety not guaranteed for the rte
flow functions also limits the applications' expectation.

This feature is going to change the rte flow functions to be thread
safety. As different PMDs have different flow operations, some may
support thread safety already and others may not. For PMDs don't
support flow thread safe operation, a new lock is defined in ethdev
in order to protects thread unsafe PMDs from rte flow level.

A new RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE device flag is added to
determine whether the PMD supports thread safe flow operation or not.
For PMDs support thread safe flow operations, set the
RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE flag, rte flow level functions will
skip the thread safe helper lock for these PMDs. Again the rte flow
level thread safe lock only works when PMD operation functions are
not thread safety.

The change has no effect on the current DPDK applications. No change
is required for the current DPDK applications.

Signed-off-by: Suanming Mou 
---
 doc/guides/prog_guide/rte_flow.rst  |  7 ++--
 drivers/net/mlx5/linux/mlx5_os.c|  5 +++
 lib/librte_ethdev/rte_ethdev.c  |  2 +
 lib/librte_ethdev/rte_ethdev.h  |  2 +
 lib/librte_ethdev/rte_ethdev_core.h |  1 +
 lib/librte_ethdev/rte_flow.c| 84 -
 6 files changed, 78 insertions(+), 23 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 3e5cd1e..54b592c 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -3033,10 +3033,6 @@ Caveats
 - API operations are synchronous and blocking (``EAGAIN`` cannot be
   returned).
 
-- There is no provision for re-entrancy/multi-thread safety, although nothing
-  should prevent different devices from being configured at the same
-  time. PMDs may protect their control path functions accordingly.
-
 - Stopping the data path (TX/RX) should not be necessary when managing flow
   rules. If this cannot be achieved naturally or with workarounds (such as
   temporarily replacing the burst function pointers), an appropriate error
@@ -3088,6 +3084,9 @@ This interface additionally defines the following helper 
function:
 - ``rte_flow_ops_get()``: get generic flow operations structure from a
   port.
 
+If PMD interfaces do not support re-entrancy/multi-thread safety, rte flow
+level functions will do it by mutex.
+
 More will be added over time.
 
 Device compatibility
diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index 69123e1..872e868 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -1152,6 +1152,11 @@
eth_dev->data->dev_private = priv;
priv->dev_data = eth_dev->data;
eth_dev->data->mac_addrs = priv->mac;
+   /*
+* This is an example of how to configure PMD flow thread safe.
+* Currently, mlx5 PMD still doesn't support thread safety.
+*/
+   eth_dev->data->dev_flags = RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE;
eth_dev->device = dpdk_dev;
/* Configure the first MAC address by default. */
if (mlx5_get_mac(eth_dev, &mac.addr_bytes)) {
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 7858ad5..8256657 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -500,6 +500,7 @@ struct rte_eth_dev *
strlcpy(eth_dev->data->name, name, sizeof(eth_dev->data->name));
eth_dev->data->port_id = port_id;
eth_dev->data->mtu = RTE_ETHER_MTU;
+   pthread_mutex_init(ð_dev->data->fts_mutex, NULL);
 
 unlock:
rte_spinlock_unlock(&rte_eth_dev_shared_data->ownership_lock);
@@ -562,6 +563,7 @@ struct rte_eth_dev *
rte_free(eth_dev->data->mac_addrs);
rte_free(eth_dev->data->hash_mac_addrs);
rte_free(eth_dev->data->dev_private);
+   pthread_mutex_destroy(ð_dev->data->fts_mutex);
memset(eth_dev->data, 0, sizeof(struct rte_eth_dev_data));
}
 
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 70295d7..6ec2450 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1636,6 +1636,8 @@ struct rte_eth_dev_owner {
 #define RTE_ETH_DEV_REPRESENTOR  0x0010
 /** Device does not support MAC change after started */
 #define RTE_ETH_DEV_NOLIVE_MAC_ADDR  0x0020
+/** Device PMD supports thread safety flow operation */
+#define RTE_ETH_DEV_FLOW_OPS_THREAD_SAFE  0x0040
 
 /**
  * Iterates over valid ethdev ports owned by a specific owner.
diff --git a/lib/librte_e

[dpdk-dev] [PATCH v3 01/15] net/i40e/base: enable FEC on/off flag setting for X722

[Guinan Sun]

Starting with API version 1.10 firmware for X722 devices has ability
to change FEC settings in PHY. Code added in this patch
checks API version and sets appropriate capability flag.

Signed-off-by: Dawid Lukwinski 
Signed-off-by: Guinan Sun 
Acked-by: Jeff Guo 
---
 drivers/net/i40e/base/i40e_adminq.c | 6 ++
 drivers/net/i40e/base/i40e_adminq_cmd.h | 2 ++
 drivers/net/i40e/base/i40e_type.h   | 1 +
 3 files changed, 9 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_adminq.c 
b/drivers/net/i40e/base/i40e_adminq.c
index c89e1fb3f..0da45f03e 100644
--- a/drivers/net/i40e/base/i40e_adminq.c
+++ b/drivers/net/i40e/base/i40e_adminq.c
@@ -603,6 +603,12 @@ STATIC void i40e_set_hw_flags(struct i40e_hw *hw)
(aq->api_maj_ver == 1 &&
 aq->api_min_ver >= I40E_MINOR_VER_GET_LINK_INFO_X722))
hw->flags |= I40E_HW_FLAG_AQ_PHY_ACCESS_CAPABLE;
+
+   if (aq->api_maj_ver > 1 ||
+   (aq->api_maj_ver == 1 &&
+aq->api_min_ver >= I40E_MINOR_VER_FW_REQUEST_FEC_X722))
+   hw->flags |= I40E_HW_FLAG_X722_FEC_REQUEST_CAPABLE;
+
/* fall through */
default:
break;
diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h 
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index 1905167f5..f790183be 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -25,6 +25,8 @@
 #define I40E_MINOR_VER_GET_LINK_INFO_X722 0x0009
 /* API version 1.6 for X722 devices adds ability to stop FW LLDP agent */
 #define I40E_MINOR_VER_FW_LLDP_STOPPABLE_X722 0x0006
+/* API version 1.10 for X722 devices adds ability to request FEC encoding */
+#define I40E_MINOR_VER_FW_REQUEST_FEC_X722 0x000A
 
 struct i40e_aq_desc {
__le16 flags;
diff --git a/drivers/net/i40e/base/i40e_type.h 
b/drivers/net/i40e/base/i40e_type.h
index 014a4c132..b5b5b928d 100644
--- a/drivers/net/i40e/base/i40e_type.h
+++ b/drivers/net/i40e/base/i40e_type.h
@@ -745,6 +745,7 @@ struct i40e_hw {
 #define I40E_HW_FLAG_FW_LLDP_PERSISTENT BIT_ULL(5)
 #define I40E_HW_FLAG_AQ_PHY_ACCESS_EXTENDED BIT_ULL(6)
 #define I40E_HW_FLAG_DROP_MODE BIT_ULL(7)
+#define I40E_HW_FLAG_X722_FEC_REQUEST_CAPABLE BIT_ULL(8)
u64 flags;
 
/* Used in set switch config AQ command */
-- 
2.17.1

[dpdk-dev] [PATCH v3 00/15] update i40e base code

[Guinan Sun]

update i40e base code.

source code of i40e driver:
cid-i40e.2020.08.27.tar.gz dropped by the team which develop
basic drivers for any i40e NIC.

changelog in ND share repo:
>From fc99a1143d3f ("i40e-shared: FEC on/off support flag for X722")
To 1a82d59f0797 ("i40e-shared: Fix PHY configuration parameters when enabling 
EEE")

The following commits are ignored.
ea2cd04e5db1 ("i40e-shared: do AQ calls without sleeping by default")
4eec86f12992 ("i40e-shared: Fix undeclared i40e_asq_send_command() function")
9d60cec99eb7 ("i40e-shared: Send rx ctl write command in atomic context")
a204afdc1cad ("i40e-shared: Send uc/mc commands in atomic context")
d22f8cb2a111 ("i40e-shared: Send commands in atomic context")
136a7d931a45 ("i40e-shared: Fix improper preprocessor conditional")
5b7d5a698092 ("i40e-shared: use linux packing style")
f16fa495c503 ("i40e-shared: Fix compilation issue with __packed")

Guinan Sun (15):
  net/i40e/base: enable FEC on/off flag setting for X722
  net/i40e/base: add PTYPE definition
  net/i40e/base: add new custom cloud filter types
  net/i40e/base: update FW API version to 1.12
  net/i40e/base: fix possible uninitialized variable
  net/i40e/base: support unused ports disabling
  net/i40e/base: replace AQ command for NVM update
  net/i40e/base: add VLAN field for input set
  net/i40e/base: enable pipe monitor thresholds
  net/i40e/base: fix missing function header arguments
  net/i40e/base: add support for Minimum Rollback Revision
  net/i40e/base: fix Rx only mode for unicast promisc on VLAN
  net/i40e/base: add EEE LPI status check for X722 adapters
  net/i40e/base: fix PHY config param when enabling EEE
  net/i40e/base: update version

 drivers/net/i40e/base/README|   2 +-
 drivers/net/i40e/base/i40e_adminq.c |   6 +
 drivers/net/i40e/base/i40e_adminq_cmd.h |  41 ++-
 drivers/net/i40e/base/i40e_common.c | 143 ++--
 drivers/net/i40e/base/i40e_dcb.c|   4 +-
 drivers/net/i40e/base/i40e_prototype.h  |  10 +-
 drivers/net/i40e/base/i40e_register.h   |   3 +
 drivers/net/i40e/base/i40e_type.h   |   7 +-
 8 files changed, 172 insertions(+), 44 deletions(-)

-- 
2.17.1

[dpdk-dev] [PATCH v3 03/15] net/i40e/base: add new custom cloud filter types

[Guinan Sun]

This patch adds the new filter types needed for custom cloud filters.
These custom cloud filters will route traffic to VFs based on the
dst IP for both tunneled and non-tunneled packets.

Signed-off-by: Harshitha Ramamurthy 
Signed-off-by: Guinan Sun 
Acked-by: Jeff Guo 
---
 drivers/net/i40e/base/i40e_adminq_cmd.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h 
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index f790183be..21f544840 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -1406,6 +1406,8 @@ struct i40e_aqc_cloud_filters_element_data {
 #define I40E_AQC_ADD_CLOUD_FILTER_IMAC 0x000A
 #define I40E_AQC_ADD_CLOUD_FILTER_OMAC_TEN_ID_IMAC 0x000B
 #define I40E_AQC_ADD_CLOUD_FILTER_IIP  0x000C
+#define I40E_AQC_ADD_CLOUD_FILTER_OIP1 0x0010
+#define I40E_AQC_ADD_CLOUD_FILTER_OIP2 0x0012
 /* 0x000D reserved */
 /* 0x000E reserved */
 /* 0x000F reserved */
-- 
2.17.1

[dpdk-dev] [PATCH v3 02/15] net/i40e/base: add PTYPE definition

[Guinan Sun]

Add I40E_RX_PTYPE_PARSER_ABORTED definition, so i40e driver will know
opcode for parser aborted packets.
Without this definition driver would have to rely on magic numbers.

Signed-off-by: Przemyslaw Patynowski 
Signed-off-by: Guinan Sun 
Acked-by: Jeff Guo 
---
 drivers/net/i40e/base/i40e_type.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/base/i40e_type.h 
b/drivers/net/i40e/base/i40e_type.h
index b5b5b928d..0eeb55975 100644
--- a/drivers/net/i40e/base/i40e_type.h
+++ b/drivers/net/i40e/base/i40e_type.h
@@ -961,7 +961,8 @@ enum i40e_rx_l2_ptype {
I40E_RX_PTYPE_GRENAT4_MAC_PAY3  = 58,
I40E_RX_PTYPE_GRENAT4_MACVLAN_IPV6_ICMP_PAY4= 87,
I40E_RX_PTYPE_GRENAT6_MAC_PAY3  = 124,
-   I40E_RX_PTYPE_GRENAT6_MACVLAN_IPV6_ICMP_PAY4= 153
+   I40E_RX_PTYPE_GRENAT6_MACVLAN_IPV6_ICMP_PAY4= 153,
+   I40E_RX_PTYPE_PARSER_ABORTED= 255
 };
 
 struct i40e_rx_ptype_decoded {
-- 
2.17.1

[dpdk-dev] [PATCH v3 05/15] net/i40e/base: fix possible uninitialized variable

[Guinan Sun]

Fix possible uninitialized variable in i40e in the i40e_get_lpi_counters
function.

Fixes: 429bdc0cd967 ("net/i40e/base: add function to read LPI counters")
Cc: sta...@dpdk.org

Signed-off-by: Adam Ludkiewicz 
Signed-off-by: Guinan Sun 
Acked-by: Jeff Guo 
---
 drivers/net/i40e/base/i40e_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 46a0b7881..85c22849e 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -7097,7 +7097,7 @@ enum i40e_status_code i40e_get_lpi_counters(struct 
i40e_hw *hw,
I40E_AQ_RUN_PHY_ACT_DNL_OPCODE_GET_EEE_STAT,
&cmd_status, tx_counter, rx_counter, NULL);
 
-   if (cmd_status != I40E_AQ_RUN_PHY_ACT_CMD_STAT_SUCC)
+   if (!retval && cmd_status != I40E_AQ_RUN_PHY_ACT_CMD_STAT_SUCC)
retval = I40E_ERR_ADMIN_QUEUE_ERROR;
 
return retval;
-- 
2.17.1

[dpdk-dev] [PATCH v3 06/15] net/i40e/base: support unused ports disabling

[Guinan Sun]

This patch adds support for disabling unused ports.

Signed-off-by: Damian Milosek 
Signed-off-by: Guinan Sun 
Acked-by: Jeff Guo 
---
 drivers/net/i40e/base/i40e_adminq_cmd.h | 1 +
 drivers/net/i40e/base/i40e_common.c | 6 ++
 drivers/net/i40e/base/i40e_type.h   | 1 +
 3 files changed, 8 insertions(+)

diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h 
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index ba4b27f4d..439669ef9 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -440,6 +440,7 @@ struct i40e_aqc_list_capabilities_element_resp {
 #define I40E_AQ_CAP_ID_SDP 0x0062
 #define I40E_AQ_CAP_ID_MDIO0x0063
 #define I40E_AQ_CAP_ID_WSR_PROT0x0064
+#define I40E_AQ_CAP_ID_DIS_UNUSED_PORTS0x0067
 #define I40E_AQ_CAP_ID_NVM_MGMT0x0080
 #define I40E_AQ_CAP_ID_FLEX10  0x00F1
 #define I40E_AQ_CAP_ID_CEM 0x00F2
diff --git a/drivers/net/i40e/base/i40e_common.c 
b/drivers/net/i40e/base/i40e_common.c
index 85c22849e..65317f6c6 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -4021,6 +4021,12 @@ STATIC void i40e_parse_discover_capabilities(struct 
i40e_hw *hw, void *buff,
   "HW Capability: wr_csr_prot = 0x%llX\n\n",
   (p->wr_csr_prot & 0x));
break;
+   case I40E_AQ_CAP_ID_DIS_UNUSED_PORTS:
+   p->dis_unused_ports = (bool)number;
+   i40e_debug(hw, I40E_DEBUG_INIT,
+  "HW Capability: dis_unused_ports = %d\n\n",
+  p->dis_unused_ports);
+   break;
case I40E_AQ_CAP_ID_NVM_MGMT:
if (number & I40E_NVM_MGMT_SEC_REV_DISABLED)
p->sec_rev_disabled = true;
diff --git a/drivers/net/i40e/base/i40e_type.h 
b/drivers/net/i40e/base/i40e_type.h
index 0eeb55975..cf4134583 100644
--- a/drivers/net/i40e/base/i40e_type.h
+++ b/drivers/net/i40e/base/i40e_type.h
@@ -425,6 +425,7 @@ struct i40e_hw_capabilities {
u32 enabled_tcmap;
u32 maxtc;
u64 wr_csr_prot;
+   bool dis_unused_ports;
bool apm_wol_support;
enum i40e_acpi_programming_method acpi_prog_method;
bool proxy_support;
-- 
2.17.1