Re: [dpdk-dev] [PATCH v3 2/5] net/virtio: use simple path for Tx even if Rx mergeable

[Tiwei Bie]

On Thu, Jun 07, 2018 at 11:26:13AM +0200, Maxime Coquelin wrote:
> Having Rx mergeable buffers feature enabled should not be
> a reason to not use Tx simple path.
> 
> Signed-off-by: Maxime Coquelin 

Reviewed-by: Tiwei Bie 

> ---
>  drivers/net/virtio/virtio_ethdev.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/net/virtio/virtio_ethdev.c 
> b/drivers/net/virtio/virtio_ethdev.c
> index 052dd056a..c6087d9b1 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1948,10 +1948,8 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>   hw->use_simple_tx = 0;
>   }
>  #endif
> - if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
> + if (vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF))
>   hw->use_simple_rx = 0;
> - hw->use_simple_tx = 0;
> - }
>  
>   if (rx_offloads & (DEV_RX_OFFLOAD_UDP_CKSUM |
>  DEV_RX_OFFLOAD_TCP_CKSUM))
> -- 
> 2.14.3
> 

[dpdk-dev] [PATCH] crypto/aesni_mb: add dynamic logging to aesni_mb

[Naga Suresh Somarowthu]

From: Naga Suresh Somarowthu  

1.added new logtype for aesni_mb driver.
2.registered new logtype.
3.MB_LOG_ERR and CDEV_LOG_ERR are
replaced with new logtype name AESNI_MB_PMD_LOG.

Signed-off-by: Naga Suresh Somarowthu 
Reviewed-by: Reshma Pattan 
---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 43 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 12 +++---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 27 --
 3 files changed, 39 insertions(+), 43 deletions(-)

diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index bb35c66ab..dbe8b2546 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -108,7 +108,7 @@ aesni_mb_set_session_auth_parameters(const struct 
aesni_mb_op_fns *mb_ops,
}
 
if (xform->type != RTE_CRYPTO_SYM_XFORM_AUTH) {
-   MB_LOG_ERR("Crypto xform struct not of type auth");
+   AESNI_MB_PMD_LOG(ERR, "Crypto xform struct not of type auth");
return -1;
}
 
@@ -161,7 +161,7 @@ aesni_mb_set_session_auth_parameters(const struct 
aesni_mb_op_fns *mb_ops,
hash_oneblock_fn = mb_ops->aux.one_block.sha512;
break;
default:
-   MB_LOG_ERR("Unsupported authentication algorithm selection");
+   AESNI_MB_PMD_LOG(ERR, "Unsupported authentication algorithm 
selection");
return -ENOTSUP;
}
 
@@ -190,7 +190,7 @@ aesni_mb_set_session_cipher_parameters(const struct 
aesni_mb_op_fns *mb_ops,
}
 
if (xform->type != RTE_CRYPTO_SYM_XFORM_CIPHER) {
-   MB_LOG_ERR("Crypto xform struct not of type cipher");
+   AESNI_MB_PMD_LOG(ERR, "Crypto xform struct not of type cipher");
return -EINVAL;
}
 
@@ -203,7 +203,7 @@ aesni_mb_set_session_cipher_parameters(const struct 
aesni_mb_op_fns *mb_ops,
sess->cipher.direction = DECRYPT;
break;
default:
-   MB_LOG_ERR("Invalid cipher operation parameter");
+   AESNI_MB_PMD_LOG(ERR, "Invalid cipher operation parameter");
return -EINVAL;
}
 
@@ -228,7 +228,7 @@ aesni_mb_set_session_cipher_parameters(const struct 
aesni_mb_op_fns *mb_ops,
sess->cipher.mode = DOCSIS_DES;
break;
default:
-   MB_LOG_ERR("Unsupported cipher mode parameter");
+   AESNI_MB_PMD_LOG(ERR, "Unsupported cipher mode parameter");
return -ENOTSUP;
}
 
@@ -252,7 +252,7 @@ aesni_mb_set_session_cipher_parameters(const struct 
aesni_mb_op_fns *mb_ops,
aes_keyexp_fn = mb_ops->aux.keyexp.aes256;
break;
default:
-   MB_LOG_ERR("Invalid cipher key length");
+   AESNI_MB_PMD_LOG(ERR, "Invalid cipher key length");
return -EINVAL;
}
 
@@ -263,7 +263,7 @@ aesni_mb_set_session_cipher_parameters(const struct 
aesni_mb_op_fns *mb_ops,
 
} else {
if (xform->cipher.key.length != 8) {
-   MB_LOG_ERR("Invalid cipher key length");
+   AESNI_MB_PMD_LOG(ERR, "Invalid cipher key length");
return -EINVAL;
}
sess->cipher.key_length_in_bytes = 8;
@@ -294,7 +294,7 @@ aesni_mb_set_session_aead_parameters(const struct 
aesni_mb_op_fns *mb_ops,
sess->auth.operation = RTE_CRYPTO_AUTH_OP_VERIFY;
break;
default:
-   MB_LOG_ERR("Invalid aead operation parameter");
+   AESNI_MB_PMD_LOG(ERR, "Invalid aead operation parameter");
return -EINVAL;
}
 
@@ -304,7 +304,7 @@ aesni_mb_set_session_aead_parameters(const struct 
aesni_mb_op_fns *mb_ops,
sess->auth.algo = AES_CCM;
break;
default:
-   MB_LOG_ERR("Unsupported aead mode parameter");
+   AESNI_MB_PMD_LOG(ERR, "Unsupported aead mode parameter");
return -ENOTSUP;
}
 
@@ -320,7 +320,7 @@ aesni_mb_set_session_aead_parameters(const struct 
aesni_mb_op_fns *mb_ops,
aes_keyexp_fn = mb_ops->aux.keyexp.aes128;
break;
default:
-   MB_LOG_ERR("Invalid cipher key length");
+   AESNI_MB_PMD_LOG(ERR, "Invalid cipher key length");
return -EINVAL;
}
 
@@ -391,7 +391,7 @@ aesni_mb_set_session_parameters(const struct 
aesni_mb_op_fns *mb_ops,
break;
case AESNI_MB_OP_NOT_SUPPORTED:
default:
-   MB_LOG_ERR("Unsupported operation chain order parameter");
+   AESNI_MB_PMD_LOG(ERR, "Unsupported operation chain order 
parameter");
return -ENOTSUP;
}
 
@@ -400,14 +400,14 @@ aesni_mb_set_

Re: [dpdk-dev] I40evf VLAN stripping disable

[Xing, Beilei]

Hi Souvik,

Yes, if adding vlan filter, the packet will be received with vlan stripped even 
if the vlan_strip is disabled. It’s i40e HW limitation, different from ixgbe.

Best Regards,
Beilei

From: Dey, Souvik [mailto:so...@rbbn.com]
Sent: Tuesday, June 12, 2018 12:26 AM
To: Xing, Beilei ; Wu, Jingjing ; 
dev@dpdk.org
Cc: us...@dpdk.org
Subject: RE: I40evf VLAN stripping disable

Hi Xing,
Do we need to do i40evf_add_vlan() to get the vlan packets up 
to the VM like we had in ixgbe_vf?  I see that if I have the vlan added through 
i40evf_add_vlan(), then the packet is received with the vlan stripped even if 
the vlan_strip is disabled in the PF. If I just do vlan_strip disabled and then 
send vlan packets it is all coming up to the VM. But is that not security issue 
as all VLANs even if not configured will be coming up to the VM, which never 
happened in the ixgbe case. I only have rte_eth_allmulticast_enable in my app , 
so expect that unicast/broadcast promisc mode is disabled by default.

--
Regard,
Souvik

From: Xing, Beilei [mailto:beilei.x...@intel.com]
Sent: Monday, June 11, 2018 3:58 AM
To: Dey, Souvik mailto:so...@rbbn.com>>; Wu, Jingjing 
mailto:jingjing...@intel.com>>; 
dev@dpdk.org
Cc: us...@dpdk.org
Subject: RE: I40evf VLAN stripping disable


NOTICE: This email was received from an EXTERNAL sender


Hi Souvik,

Could you try with kernel driver (version 2.4.3) first? In my environment, 
disable vlan strip in DPDK works with kernel driver version 2.4.3.

My test steps with testpmd:
>set fwd rxonly
>set verbose 1
>set promisc 0 off
>vlan set strip off 0
Then send a vlan packet with VF mac address.

Best Regards,
Beilei Xing

From: Dey, Souvik [mailto:so...@rbbn.com]
Sent: Friday, June 8, 2018 11:22 PM
To: Xing, Beilei mailto:beilei.x...@intel.com>>; Wu, 
Jingjing mailto:jingjing...@intel.com>>; 
dev@dpdk.org
Cc: us...@dpdk.org
Subject: I40evf VLAN stripping disable

Hi i40e/i40evf maintainers,

I was testing VLANs with i40evf pmd and is hitting the below issue.

I have the following configuration:
- host runs with Linux pf i40e driver(version 2.4.6)
- guest runs with DPDK 17.11.2 vf i40e driver

When I am sending a vlan packet from the outside to the guest, on the guest, I 
receive the packet which has the PKT_RX_VLAN_STRIPPED flag set although I'm not 
asking for it.
Even though my DPDK app has the rte_eth_conf.rxmode.hw_vlan_strip set to 0 and 
also verified that the 
i40evf_disable_vlan_strip(VIRTCHNL_OP_DISABLE_VLAN_STRIPPING) function is 
getting called and not returning any error from the linux pf driver.
Is this the default behavior that the VLAN will be always stripped by the PF 
irrespective of the setting ? Should the DPDK version take care of the 
re-adding the tag back to the packet in case hw_vlan_strip is disabled ? What 
should be best way of handling it ? Is it a bug in DPDK or I am missing 
something here.

I do see in the linux i40evf driver we are insert vlan header in the received 
packets in some cases.

--
Regards,
Souvik

Re: [dpdk-dev] [PATCH v3 1/5] net/virtio: forbid simple Tx path by default

[Tiwei Bie]

On Thu, Jun 07, 2018 at 11:26:12AM +0200, Maxime Coquelin wrote:
> Simple Tx path is not compliant with the Virtio specification,
> as it assumes the device will use the descriptors in order.
> 
> VIRTIO_F_IN_ORDER feature has been introduced recently, but the
> simple Tx path is not compliant with it as VIRTIO_F_IN_ORDER
> requires that chained descriptors are used sequentially, which
> is not the case in simple Tx path.
> 
> This patch introduces 'simple_tx_support' devarg to unlock
> Tx simple path selection.
> 
> Reported-by: Tiwei Bie 
> Signed-off-by: Maxime Coquelin 
> ---
>  doc/guides/nics/virtio.rst |  9 +
>  drivers/net/virtio/virtio_ethdev.c | 73 
> +-
>  drivers/net/virtio/virtio_pci.h|  1 +
>  3 files changed, 82 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst
> index 8922f9c0b..53ce1c12a 100644
> --- a/doc/guides/nics/virtio.rst
> +++ b/doc/guides/nics/virtio.rst
> @@ -222,6 +222,9 @@ Tx callbacks:
>  
>  #. ``virtio_xmit_pkts_simple``:
> Vector version fixes the available ring indexes to optimize performance.
> +   This implementation does not comply with the Virtio specification, and so
> +   is not selectable by default. "simple_tx_support=1" devarg must be passed
> +   to unlock it.
>  
>  
>  By default, the non-vector callbacks are used:
> @@ -331,3 +334,9 @@ The user can specify below argument in devargs.
>  driver, and works as a HW vhost backend. This argument is used to specify
>  a virtio device needs to work in vDPA mode.
>  (Default: 0 (disabled))
> +
> +#.  ``simple_tx_support``:
> +
> +This argument enables support for the simple Tx path, which is not
> +compliant with the Virtio specification.
> +(Default: 0 (disabled))

I tried this patch on my server. Virtio-user will
fail to probe when simple_tx_support is specified
dues to the check in virtio_user_pmd_probe():

PMD: Error parsing device, invalid key 
virtio_user_pmd_probe(): error when parsing param
vdev_probe(): failed to initialize virtio_user0 device
EAL: Bus (vdev) probe failed.


> diff --git a/drivers/net/virtio/virtio_ethdev.c 
> b/drivers/net/virtio/virtio_ethdev.c
> index 5833dad73..052dd056a 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1331,6 +1331,8 @@ set_rxtx_funcs(struct rte_eth_dev *eth_dev)
>   if (hw->use_simple_tx) {
>   PMD_INIT_LOG(INFO, "virtio: using simple Tx path on port %u",
>   eth_dev->data->port_id);
> + PMD_INIT_LOG(WARNING,
> + "virtio: simple Tx path does not comply with 
> Virtio spec");
>   eth_dev->tx_pkt_burst = virtio_xmit_pkts_simple;
>   } else {
>   PMD_INIT_LOG(INFO, "virtio: using standard Tx path on port %u",
> @@ -1790,6 +1792,66 @@ rte_virtio_pmd_init(void)
>   rte_pci_register(&rte_virtio_pmd);
>  }
>  
> +#define VIRTIO_SIMPLE_TX_SUPPORT "simple_tx_support"
> +
> +static int virtio_dev_args_check(const char *key, const char *val,
> + void *opaque)
> +{
> + struct rte_eth_dev *dev = opaque;
> + struct virtio_hw *hw = dev->data->dev_private;
> + unsigned long tmp;
> + int ret = 0;
> +
> + errno = 0;
> + tmp = strtoul(val, NULL, 0);
> + if (errno) {
> + PMD_INIT_LOG(INFO,
> + "%s: \"%s\" is not a valid integer", key, val);
> + return errno;
> + }
> +
> + if (strcmp(VIRTIO_SIMPLE_TX_SUPPORT, key) == 0)
> + hw->support_simple_tx = !!tmp;
> +
> + return ret;
> +}
> +
> +static int
> +virtio_dev_args(struct rte_eth_dev *dev)
> +{
> + struct rte_kvargs *kvlist;
> + struct rte_devargs *devargs;
> + const char *valid_args[] = {
> + VIRTIO_SIMPLE_TX_SUPPORT,
> + NULL,
> + };

checkpatch is complaining about above definition:

WARNING:STATIC_CONST_CHAR_ARRAY: char * array declaration might be
better as static const
#96: FILE: drivers/net/virtio/virtio_ethdev.c:1824:
+   const char *valid_args[] = {

Best regards,
Tiwei Bie

[dpdk-dev] [PATCH] lib/cryptodev: remove RTE_LIBRTE_CRYPTODEV_DEBUG

[Jananee Parthasarathy]

For librte_cryptodev dynamic logging,
conditional compilation of debug logs would not be required anymore.

Signed-off-by: Jananee Parthasarathy 
Reviewed-by: Reshma Pattan 
---
 lib/librte_cryptodev/rte_cryptodev.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index 92ce6d49a..229712ebf 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -65,7 +65,6 @@ extern const char **rte_cyptodev_names;
RTE_FMT(RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
RTE_FMT_TAIL(__VA_ARGS__,)))
 
-#ifdef RTE_LIBRTE_CRYPTODEV_DEBUG
 #define CDEV_LOG_DEBUG(...) \
RTE_LOG(DEBUG, CRYPTODEV, \
RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
@@ -76,13 +75,6 @@ extern const char **rte_cyptodev_names;
RTE_FMT("[%s] %s: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
dev, __func__, RTE_FMT_TAIL(__VA_ARGS__,)))
 
-#else
-#define CDEV_LOG_DEBUG(...) (void)0
-#define CDEV_PMD_TRACE(...) (void)0
-#endif
-
-
-
 /**
  * A macro that points to an offset from the start
  * of the crypto operation structure (rte_crypto_op)
-- 
2.13.6

Re: [dpdk-dev] [PATCH] vhost: use SMP memory barrier before kicking guest

[Tiwei Bie]

On Thu, Jun 07, 2018 at 04:38:26PM +0200, Maxime Coquelin wrote:
> vhost_vring_call() used rte_mb(), which translates into
> mfence instruction on x86.
> 
> This patch changes to use rte_smp_mb(), which changed recently
> to translate into a locked ADD instruction for performance
> reason.
> 
> The measured gain is up to 3% with the testpmd benchmarks.
> 
> Signed-off-by: Maxime Coquelin 
> ---
>  lib/librte_vhost/vhost.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> index 58c425a5c..1bc99ed3c 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -591,7 +591,7 @@ static __rte_always_inline void
>  vhost_vring_call(struct virtio_net *dev, struct vhost_virtqueue *vq)
>  {
>   /* Flush used->idx update before we read avail->flags. */
> - rte_mb();
> + rte_smp_mb();
>  
>   /* Don't kick guest if we don't reach index specified by guest. */
>   if (dev->features & (1ULL << VIRTIO_RING_F_EVENT_IDX)) {
> -- 
> 2.14.3
> 

Reviewed-by: Tiwei Bie 

Re: [dpdk-dev] [PATCH 6/7] net/mlx5: probe all port representors

[Xueming(Steven) Li]

Hi Adrien,

> -Original Message-
> From: dev  On Behalf Of Adrien Mazarguil
> Sent: Saturday, May 26, 2018 12:35 AM
> To: Shahaf Shuler 
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 6/7] net/mlx5: probe all port representors
> 
> Probe existing port representors in addition to their master device and 
> associate them automatically.
> 
> To avoid name collision between Ethernet devices, their names use the same 
> convention as ixgbe and
> i40e PMDs, that is, instead of only a PCI address in DBDF notation:
> 
> - "net_{DBDF}_0" for master/switch devices.
> - "net_{DBDF}_representor_{rep}" with "rep" starting from 0 for port
>   representors.
> 
> Both optionally suffixed with "_port_{num}" instead of " port {num}" for 
> devices that expose several
> Verbs ports (note this is never the case on mlx5, but kept for historical 
> reasons for the time being).
> 
> (Patch based on prior work from Yuanhan Liu)
> 
> Signed-off-by: Adrien Mazarguil 
> ---
>  drivers/net/mlx5/mlx5.c| 119 -
>  drivers/net/mlx5/mlx5.h|   8 +-
>  drivers/net/mlx5/mlx5_ethdev.c | 145 
>  drivers/net/mlx5/mlx5_mac.c|   2 +-
>  drivers/net/mlx5/mlx5_stats.c  |   6 +-
>  5 files changed, 226 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c index 
> d3a298332..09afca63c 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -301,6 +301,9 @@ mlx5_dev_close(struct rte_eth_dev *dev)
>   if (ret)
>   DRV_LOG(WARNING, "port %u some flows still remain",
>   dev->data->port_id);
> + if (!priv->representor &&
> + priv->domain_id != RTE_ETH_DEV_SWITCH_DOMAIN_ID_INVALID)
> + claim_zero(rte_eth_switch_domain_free(priv->domain_id));
>   memset(priv, 0, sizeof(*priv));
>  }
> 
> @@ -645,6 +648,10 @@ mlx5_uar_init_secondary(struct rte_eth_dev *dev)
>   *   Verbs device attributes.
>   * @param port
>   *   Verbs port to use (indexed from 1).
> + * @param master
> + *   Master device in case @p ibv_dev is a port representor.
> + * @param rep_id
> + *   Representor identifier when @p master is non-NULL.
>   *
>   * @return
>   *   A valid Ethernet device object on success, NULL otherwise and rte_errno
> @@ -655,7 +662,9 @@ mlx5_dev_spawn_one(struct rte_device *dpdk_dev,
>  struct ibv_device *ibv_dev,
>  int vf,
>  const struct ibv_device_attr_ex *attr,
> -unsigned int port)
> +unsigned int port,
> +struct rte_eth_dev *master,
> +unsigned int rep_id)
>  {
>   struct ibv_context *ctx;
>   struct ibv_port_attr port_attr;
> @@ -799,11 +808,14 @@ mlx5_dev_spawn_one(struct rte_device *dpdk_dev,
>   " old OFED/rdma-core version or firmware configuration");  
> #endif
>   config.mpls_en = mpls_en;
> - if (attr->orig_attr.phys_port_cnt > 1)
> - snprintf(name, sizeof(name), "%s", dpdk_dev->name);
> + if (!master)
> + snprintf(name, sizeof(name), "net_%s_0", dpdk_dev->name);
>   else
> - snprintf(name, sizeof(name), "%s port %u",
> -  dpdk_dev->name, port);
> + snprintf(name, sizeof(name), "net_%s_representor_%u",
> +  dpdk_dev->name, rep_id);
> + if (attr->orig_attr.phys_port_cnt > 1)
> + snprintf(name, sizeof(name), "%s_port_%u", name, port);
> + DRV_LOG(DEBUG, "naming Ethernet device \"%s\"", name);
>   if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
>   eth_dev = rte_eth_dev_attach_secondary(name);
>   if (eth_dev == NULL) {
> @@ -880,6 +892,27 @@ mlx5_dev_spawn_one(struct rte_device *dpdk_dev,
>   priv->port = port;
>   priv->pd = pd;
>   priv->mtu = ETHER_MTU;
> + /*
> +  * Allocate a switch domain for master devices and share it with
> +  * port representors.
> +  */
> + if (!master) {
> + priv->representor = 0;
> + priv->domain_id = RTE_ETH_DEV_SWITCH_DOMAIN_ID_INVALID;
> + priv->rep_id = 0;
> + err = rte_eth_switch_domain_alloc(&priv->domain_id);

So domain_id is used to identify relation between PF and representor port?

> + if (err) {
> + err = rte_errno;
> + DRV_LOG(ERR, "unable to allocate switch domain: %s",
> + strerror(rte_errno));
> + goto error;
> + }
> + } else {
> + priv->representor = 1;
> + priv->domain_id =
> + ((struct priv *)master->data->dev_private)->domain_id;
> + priv->rep_id = rep_id;
> + }
>   err = mlx5_args(&config, dpdk_dev->devargs);
>   if (err) {
>   err = rte_errno;
> @@ -1067,8 +1100,12 @@ mlx5_dev_spawn_one(struct rte_device *dpdk_dev,
>   rte_r

[dpdk-dev] [PATCH] crypto/aesni_gcm: add dynamic logging to aesni_gcm

[Naga Suresh Somarowthu]

From: tchaitax 

1.added new logtype for aesni_gcm driver.
2.registered new logtype.
3.GCM_LOG_ERR and CDEV_LOG_ERR are replaced with
  new logtype name AESNI_GCM_PMD_LOG.

Signed-off-by: Talluri Chaitanya 
Reviewed-by: Reshma Pattan 
---
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 29 
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 15 ++--
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h | 25 +---
 3 files changed, 32 insertions(+), 37 deletions(-)

diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 80360dd9c..999e61b5f 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -31,8 +31,8 @@ aesni_gcm_set_session_parameters(const struct aesni_gcm_ops 
*gcm_ops,
if (xform->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
auth_xform = xform;
if (auth_xform->auth.algo != RTE_CRYPTO_AUTH_AES_GMAC) {
-   GCM_LOG_ERR("Only AES GMAC is supported as an "
-   "authentication only algorithm");
+   AESNI_GCM_PMD_LOG(ERR, "Only AES GMAC is supported as 
an "
+   "authentication only algorithm");
return -ENOTSUP;
}
/* Set IV parameters */
@@ -54,7 +54,7 @@ aesni_gcm_set_session_parameters(const struct aesni_gcm_ops 
*gcm_ops,
aead_xform = xform;
 
if (aead_xform->aead.algo != RTE_CRYPTO_AEAD_AES_GCM) {
-   GCM_LOG_ERR("The only combined operation "
+   AESNI_GCM_PMD_LOG(ERR, "The only combined operation "
"supported is AES GCM");
return -ENOTSUP;
}
@@ -75,7 +75,7 @@ aesni_gcm_set_session_parameters(const struct aesni_gcm_ops 
*gcm_ops,
sess->aad_length = aead_xform->aead.aad_length;
digest_length = aead_xform->aead.digest_length;
} else {
-   GCM_LOG_ERR("Wrong xform type, has to be AEAD or 
authentication");
+   AESNI_GCM_PMD_LOG(ERR, "Wrong xform type, has to be AEAD or 
authentication");
return -ENOTSUP;
}
 
@@ -83,7 +83,7 @@ aesni_gcm_set_session_parameters(const struct aesni_gcm_ops 
*gcm_ops,
/* IV check */
if (sess->iv.length != 16 && sess->iv.length != 12 &&
sess->iv.length != 0) {
-   GCM_LOG_ERR("Wrong IV length");
+   AESNI_GCM_PMD_LOG(ERR, "Wrong IV length");
return -EINVAL;
}
 
@@ -99,7 +99,7 @@ aesni_gcm_set_session_parameters(const struct aesni_gcm_ops 
*gcm_ops,
sess->key = AESNI_GCM_KEY_256;
break;
default:
-   GCM_LOG_ERR("Invalid key length");
+   AESNI_GCM_PMD_LOG(ERR, "Invalid key length");
return -EINVAL;
}
 
@@ -109,7 +109,7 @@ aesni_gcm_set_session_parameters(const struct aesni_gcm_ops 
*gcm_ops,
if (digest_length != 16 &&
digest_length != 12 &&
digest_length != 8) {
-   GCM_LOG_ERR("digest");
+   AESNI_GCM_PMD_LOG(ERR, "Invalid digest length");
return -EINVAL;
}
sess->digest_length = digest_length;
@@ -464,13 +464,13 @@ aesni_gcm_create(const char *name,
 
/* Check CPU for support for AES instruction set */
if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_AES)) {
-   GCM_LOG_ERR("AES instructions not supported by CPU");
+   AESNI_GCM_PMD_LOG(ERR, "AES instructions not supported by CPU");
return -EFAULT;
}
-
dev = rte_cryptodev_pmd_create(name, &vdev->device, init_params);
if (dev == NULL) {
-   GCM_LOG_ERR("driver %s: create failed", init_params->name);
+   AESNI_GCM_PMD_LOG(ERR, "driver %s: create failed",
+   init_params->name);
return -ENODEV;
}
 
@@ -572,3 +572,12 @@ RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_AESNI_GCM_PMD,
"socket_id=");
 RTE_PMD_REGISTER_CRYPTO_DRIVER(aesni_gcm_crypto_drv, aesni_gcm_pmd_drv.driver,
cryptodev_driver_id);
+
+
+RTE_INIT(aesni_gcm_init_log);
+static void
+aesni_gcm_init_log(void)
+{
+   aesni_gcm_logtype_driver = rte_log_register("pmd.crypto.aesni_gcm");
+
+}
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index 6f542137c..817f99b28 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -183,12 +183,11 @@ aesni_gcm_pmd_qp_create_processed_pkts_ring(struct 
aesni_gcm_qp *qp,
r = rte_ring_lookup(qp->name);
if (r) {
if (rte_ring_get_size(r) >= ring_size) {
-   GC

Re: [dpdk-dev] [RFC] ethdev: support tunnel encapsulation action

[Ori Kam]

Hi

No you shouldn't understand this.
I still think that the [1] proposal is the correct 
approach, but due to a very short time frame for this
release I suggest this as intermediate solution.

I want to get comments and open discussion regarding
the proposal and in worst case add it to next release.

Ori

> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Monday, June 11, 2018 9:53 AM
> To: Ori Kam 
> Cc: ferruh.yi...@intel.com; declan.dohe...@intel.com; dev@dpdk.org;
> Adrien Mazarguil 
> Subject: Re: [RFC] ethdev: support tunnel encapsulation action
> 
> Hi Ori,
> 
> Should we understand this proposal is nacked by [1] you have also
> proposed?
> 
> If yes, answer to this one with a self-nack to make it clear.
> 
> Thanks,
> 
> On Tue, Jun 05, 2018 at 06:48:28PM +0300, Ori Kam wrote:
> > This RFC contain proposal to add generic support for tunnel
> > encapsulation/decapsulation.
> >
> > Due to the fact that there are many possible tunnel types
> > and each tunnel type has number of header variations, there
> > is a need for some generic command.
> >
> > example for tunnel headers in case of MPLSoGRE:
> > ETH / VLAN / IPV4 / GRE / MPLS / ETH / IP / L4-L7
> > ETH / VLAN / IPV6 / GRE / MPLS / ETH / IP / L4-L7
> > ETH / IPV4 / GRE / MPLS / ETH / IP / L4-L7
> > ETH / IPV6 / GRE / MPLS / ETH / IP / L4-L7
> > ETH / VLAN / IPV4 / GRE / MPLS / IP / L4-L7
> > ETH / VLAN / IPV6 / GRE / MPLS / IP / L4-L7
> > ETH / IPV4 / GRE / MPLS / IP / L4-L7
> > ETH / IPV6 / GRE / MPLS / IP / L4-L7
> >
> > As can be seen from the examples some of the encapsulation
> > is done by overwriting the inner L2 packet spec.
> >
> > To support all of those configuration it is much
> > easer if we create 2 encap functions one that
> > is used to encap L2 packet and one that is used
> > to encap L3 packet by removing the L2 and applying
> > the encapsulation header.
> >
> > The use of void * buffer will enable the
> > insertion of any valid encapsulation header.
> > the use of such a buffer will also simplify the processing
> > needed to validate and apply vs the use of rte_flow_items.
> > The use of a buffer will also will be easer
> > for some applications (for example vrouter)
> >
> > For decap we will also have 2 actions
> > one for decaping a packet with inner L2
> > and one for decaping a packet with inner L3.
> > when decaping L3 packet the user should
> > supplay the L2 data which should be added to the inner packet.
> >
> > Signed-off-by: Ori Kam 
> > ---
> >  doc/guides/prog_guide/rte_flow.rst |  141 ++
> -
> >  lib/librte_ethdev/rte_flow.h   |  165 +---
> ---
> >  2 files changed, 161 insertions(+), 145 deletions(-)
> >
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> > index b305a72..7417833 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -1969,112 +1969,95 @@ Implements ``OFPAT_PUSH_MPLS`` ("push a
> new MPLS tag") as defined by the
> > | ``ethertype`` | EtherType |
> > +---+---+
> >
> > -Action: ``VXLAN_ENCAP``
> > -^^^
> > -
> > -Performs a VXLAN encapsulation action by encapsulating the matched
> flow in the
> > -VXLAN tunnel as defined in the``rte_flow_action_vxlan_encap`` flow
> items
> > -definition.
> > +Action: ``TUNNEL_ENCAP``
> > +
> >
> > -This action modifies the payload of matched flows. The flow definition
> specified
> > -in the ``rte_flow_action_tunnel_encap`` action structure must define a
> valid
> > -VLXAN network overlay which conforms with RFC 7348 (Virtual eXtensible
> Local
> > -Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2
> Networks
> > -over Layer 3 Networks). The pattern must be terminated with the
> > -RTE_FLOW_ITEM_TYPE_END item type.
> > +Perform a tunnel encapsulation action by encapsulating the matched flow
> with
> > +the given buffer.
> >
> > -.. _table_rte_flow_action_vxlan_encap:
> > +This action modifies the payload of the matched flows.
> > +The buffer must hold a valid tunnel encapsulation header.
> >
> > -.. table:: VXLAN_ENCAP
> > +.. _table_rte_flow_action_tunnel_encap:
> >
> > +.. table:: TUNNEL_ENCAP
> > +
> > ++-+
> > | Field  | Value   |
> >
> ++=+
> > -   | ``definition`` | Tunnel end-point overlay definition |
> > +   | ``type``   | Encapsulation tunnel type.  |
> > +   ++-+
> > +   | ``buf``| The encapsulation header.   |
> > +   ++-+
> > +   | ``len``| Buf len.|
> > ++-+
> >
> > -.. _table_rte_flow_action_vxlan_encap_

Re: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA machine

[Jerin Jacob]

-Original Message-
> Date: Mon, 11 Jun 2018 04:05:26 +
> From: Sachin Saxena 
> To: Jerin Jacob , Hemant Agrawal
>  
> CC: "dev@dpdk.org" 
> Subject: RE: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA
>  machine
> 
> 
> > -Original Message-
> > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > Sent: Sunday, June 10, 2018 4:37 PM
> > To: Hemant Agrawal 
> > Cc: dev@dpdk.org; Sachin Saxena 
> > Subject: Re: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA
> > machine
> > 
> > -Original Message-
> > > Date: Tue,  5 Jun 2018 12:03:45 +0530
> > > From: Hemant Agrawal 
> > > To: dev@dpdk.org
> > > CC: Sachin Saxena 
> > > Subject: [dpdk-dev] [PATCH] mk: change TLS model for ARMv8 and DPAA
> > > machine
> > > X-Mailer: git-send-email 2.7.4
> > >
> > > From: Sachin Saxena 
> > >
> > > Random corruptions observed on ARM platfoms with using the dpdk
> > > library in shared mode with VPP software (plugin).
> > >
> > > sing traditional TLS scheme resolved the issue.
> > >
> > > Tested with VPP with DPDK as a plugin.
> > >
> > > Signed-off-by: Sachin Saxena 
> > > ---
> > >  mk/machine/armv8a/rte.vars.mk | 3 +++
> > >  mk/machine/dpaa/rte.vars.mk   | 3 +++
> > >  mk/machine/dpaa2/rte.vars.mk  | 3 +++
> > >  3 files changed, 9 insertions(+)
> > >
> > > diff --git a/mk/machine/armv8a/rte.vars.mk
> > > b/mk/machine/armv8a/rte.vars.mk index 8252efb..6897cd6 100644
> > > --- a/mk/machine/armv8a/rte.vars.mk
> > > +++ b/mk/machine/armv8a/rte.vars.mk
> > > @@ -29,3 +29,6 @@
> > >  # CPU_ASFLAGS =
> > >
> > >  MACHINE_CFLAGS += -march=armv8-a+crc+crypto
> > > +
> > > +# To avoid TLS corruption issue.
> > > +MACHINE_CFLAGS += -mtls-dialect=trad
> > 
> > This issue is not reproducible on Cavium ARMv8 platforms. Just wondering,
> > Do we need to change default ARMv8 config?
> [Sachin Saxena]  The issue is currently visible On NXP platforms with 
> VPP-dpdk solution only. Similar behavior like random crashes or 
> initialization failures have been seen by Cavium guys on VPP but they are 
> still investigating whether the issues are related to TLS corruption.

I checked with Cavium-VPP team. According to them, they are not facing any
issue related to TLS

> Also, issue will not be there with statically linked dpdk applications
> 
> > 
> > The GNU (descriptor) dialect for TLS is the default has been since for a 
> > while
> > on aarch64.
> [Sachin Saxena] I agree but this model only applies to Shared mode 
> compilation. As per my knowledge, the "initial-exec" model is default for 
> static compilation or when -fPIC is not used. For shared dpdk or when -fPIC 
> is used, the default is "global-dynamics" and tls-dialect=desc.

But shared mode compilation is important too. Right? We are concerned
about performance and stability aspects of "changing default" with out
any proper root cause.


> 
> > 
> > I think, it will be mostly a glibc issue with your SDK based toolchain.
> > Are you able to reproduce this issue with Linaro toolchain + standard OS
> > distribution environments? if so, could you please share more details.
> [Sachin Saxena] Yes, issue is happening with both SDK & Linaro 7.2 toolchain.

We tested and it works with gcc version 5.4.0 20160609 (Ubuntu/Linaro 
5.4.0-6ubuntu1~16.04.9).
If it is bug from Linaro on the latest toolchain, lets report and try
to have this fix based on runtime attributes.

> > 
> > I am only concerned about, any performance issue with traditional tls 
> > dialect
> > model vs descriptor dialect.
> [Sachin Saxena] No performance impact is expected for statically build dpdk. 
> For shared mode, minor impact is expected but performance analysis is yet to 
> be done. The Fix is suggested because right now it is functionally broken 
> with VPP.

Is it possible to check with "gcc version 5.4.0 20160609 (Ubuntu/Linaro 
5.4.0-6ubuntu1~16.04.9)"? so that we can identity it is an toolchain issue or 
not?

> > 
> > I think, we have two options,
> > 1) If you can identify if it is due a specific glibc version then we could 
> > detect
> > at runtime
> > 2) In a worst case, it can be a conditional compilation option.
> > 
> > /Jerin
> 

Re: [dpdk-dev] [RFC] ethdev: support tunnel encapsulation action

[Nélio Laranjeiro]

On Mon, Jun 11, 2018 at 07:27:22AM +, Ori Kam wrote:
> Hi
> 
> No you shouldn't understand this.
> I still think that the [1] proposal is the correct 
> approach, but due to a very short time frame for this
> release I suggest this as intermediate solution.
>
> I want to get comments and open discussion regarding
> the proposal and in worst case add it to next release.

Do you mean this API is proposed for 18.11 and the new one is for 18.08
[1] ?

Please clarify your intention.  It is clear both will not make part of
the same release.

> Ori
> 
> > -Original Message-
> > From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> > Sent: Monday, June 11, 2018 9:53 AM
> > To: Ori Kam 
> > Cc: ferruh.yi...@intel.com; declan.dohe...@intel.com; dev@dpdk.org;
> > Adrien Mazarguil 
> > Subject: Re: [RFC] ethdev: support tunnel encapsulation action
> > 
> > Hi Ori,
> > 
> > Should we understand this proposal is nacked by [1] you have also
> > proposed?
> > 
> > If yes, answer to this one with a self-nack to make it clear.
> > 
> > Thanks,
> > 
> > On Tue, Jun 05, 2018 at 06:48:28PM +0300, Ori Kam wrote:
> > > This RFC contain proposal to add generic support for tunnel
> > > encapsulation/decapsulation.
> > >
> > > Due to the fact that there are many possible tunnel types
> > > and each tunnel type has number of header variations, there
> > > is a need for some generic command.
> > >
> > > example for tunnel headers in case of MPLSoGRE:
> > > ETH / VLAN / IPV4 / GRE / MPLS / ETH / IP / L4-L7
> > > ETH / VLAN / IPV6 / GRE / MPLS / ETH / IP / L4-L7
> > > ETH / IPV4 / GRE / MPLS / ETH / IP / L4-L7
> > > ETH / IPV6 / GRE / MPLS / ETH / IP / L4-L7
> > > ETH / VLAN / IPV4 / GRE / MPLS / IP / L4-L7
> > > ETH / VLAN / IPV6 / GRE / MPLS / IP / L4-L7
> > > ETH / IPV4 / GRE / MPLS / IP / L4-L7
> > > ETH / IPV6 / GRE / MPLS / IP / L4-L7
> > >
> > > As can be seen from the examples some of the encapsulation
> > > is done by overwriting the inner L2 packet spec.
> > >
> > > To support all of those configuration it is much
> > > easer if we create 2 encap functions one that
> > > is used to encap L2 packet and one that is used
> > > to encap L3 packet by removing the L2 and applying
> > > the encapsulation header.
> > >
> > > The use of void * buffer will enable the
> > > insertion of any valid encapsulation header.
> > > the use of such a buffer will also simplify the processing
> > > needed to validate and apply vs the use of rte_flow_items.
> > > The use of a buffer will also will be easer
> > > for some applications (for example vrouter)
> > >
> > > For decap we will also have 2 actions
> > > one for decaping a packet with inner L2
> > > and one for decaping a packet with inner L3.
> > > when decaping L3 packet the user should
> > > supplay the L2 data which should be added to the inner packet.
> > >
> > > Signed-off-by: Ori Kam 
> > > ---
> > >  doc/guides/prog_guide/rte_flow.rst |  141 ++
> > -
> > >  lib/librte_ethdev/rte_flow.h   |  165 
> > > +---
> > ---
> > >  2 files changed, 161 insertions(+), 145 deletions(-)
> > >
> > > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > > index b305a72..7417833 100644
> > > --- a/doc/guides/prog_guide/rte_flow.rst
> > > +++ b/doc/guides/prog_guide/rte_flow.rst
> > > @@ -1969,112 +1969,95 @@ Implements ``OFPAT_PUSH_MPLS`` ("push a
> > new MPLS tag") as defined by the
> > > | ``ethertype`` | EtherType |
> > > +---+---+
> > >
> > > -Action: ``VXLAN_ENCAP``
> > > -^^^
> > > -
> > > -Performs a VXLAN encapsulation action by encapsulating the matched
> > flow in the
> > > -VXLAN tunnel as defined in the``rte_flow_action_vxlan_encap`` flow
> > items
> > > -definition.
> > > +Action: ``TUNNEL_ENCAP``
> > > +
> > >
> > > -This action modifies the payload of matched flows. The flow definition
> > specified
> > > -in the ``rte_flow_action_tunnel_encap`` action structure must define a
> > valid
> > > -VLXAN network overlay which conforms with RFC 7348 (Virtual eXtensible
> > Local
> > > -Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2
> > Networks
> > > -over Layer 3 Networks). The pattern must be terminated with the
> > > -RTE_FLOW_ITEM_TYPE_END item type.
> > > +Perform a tunnel encapsulation action by encapsulating the matched flow
> > with
> > > +the given buffer.
> > >
> > > -.. _table_rte_flow_action_vxlan_encap:
> > > +This action modifies the payload of the matched flows.
> > > +The buffer must hold a valid tunnel encapsulation header.
> > >
> > > -.. table:: VXLAN_ENCAP
> > > +.. _table_rte_flow_action_tunnel_encap:
> > >
> > > +.. table:: TUNNEL_ENCAP
> > > +
> > > ++-+
> > > | Field  | Value   |
> > >
> > ++=+
> > > -   | ``definiti

Re: [dpdk-dev] I40evf VLAN stripping disable

[Xing, Beilei]

Hi Souvik,

Could you try with kernel driver (version 2.4.3) first? In my environment, 
disable vlan strip in DPDK works with kernel driver version 2.4.3.

My test steps with testpmd:
>set fwd rxonly
>set verbose 1
>set promisc 0 off
>vlan set strip off 0
Then send a vlan packet with VF mac address.

Best Regards,
Beilei Xing

From: Dey, Souvik [mailto:so...@rbbn.com]
Sent: Friday, June 8, 2018 11:22 PM
To: Xing, Beilei ; Wu, Jingjing ; 
dev@dpdk.org
Cc: us...@dpdk.org
Subject: I40evf VLAN stripping disable

Hi i40e/i40evf maintainers,

I was testing VLANs with i40evf pmd and is hitting the below issue.

I have the following configuration:
- host runs with Linux pf i40e driver(version 2.4.6)
- guest runs with DPDK 17.11.2 vf i40e driver

When I am sending a vlan packet from the outside to the guest, on the guest, I 
receive the packet which has the PKT_RX_VLAN_STRIPPED flag set although I'm not 
asking for it.
Even though my DPDK app has the rte_eth_conf.rxmode.hw_vlan_strip set to 0 and 
also verified that the 
i40evf_disable_vlan_strip(VIRTCHNL_OP_DISABLE_VLAN_STRIPPING) function is 
getting called and not returning any error from the linux pf driver.
Is this the default behavior that the VLAN will be always stripped by the PF 
irrespective of the setting ? Should the DPDK version take care of the 
re-adding the tag back to the packet in case hw_vlan_strip is disabled ? What 
should be best way of handling it ? Is it a bug in DPDK or I am missing 
something here.

I do see in the linux i40evf driver we are insert vlan header in the received 
packets in some cases.

--
Regards,
Souvik

Re: [dpdk-dev] [PATCH v3 27/27] net/ena: set link speed as none

[Michał Krawczyk]

2018-06-10 3:35 GMT+02:00 Chas Williams <3ch...@gmail.com>:
>
>
> On Fri, Jun 8, 2018 at 3:37 PM Ferruh Yigit  wrote:
>>
>> On 6/7/2018 10:43 AM, Michal Krawczyk wrote:
>> > From: Rafal Kozik 
>> >
>> > Link speed should is not limited to 10Gb/s and it shouldn't be
>> > hardcoded.
>> >
>> > They link speed is set to none instead and the applications shouldn't
>> > rely on this value when using ENA PMD.
>>
>> Why not able to set link speed?
>>
>> And what is the link_autoneg, ETH_LINK_FIXED? What is the point of setting
>> link
>> speed FIXED and later speed value NONE?
>
>
> The link speed is part of the spanning tree path computation.  I don't think
> picking 0 (or undefined)
> is the appropriate choice.  For virtual interfaces link speed is a
> troublesome quantity but advertising
> undefined seems worse then just use some constant value.
>

Setting constant value is not making much sense in the virtualized
environment (ENA can be only used in the cloud). Link speed can be
very flexible in that case and that's why ENA isn't providing it. If
we will use constant value, what it should be? It may lead to
confusion or can result in the performance issues because some
applications are relying on this number to send max traffic.
Applications should not make assumption that the link speed is always
giving valid value and if it is not, they should try to configure rate
dynamically, instead of statically.

>>
>>
>> >
>> > Fixes: 1173fca ("ena: add polling-mode driver")
>>
>> For next time can you please use git alias to have consistent Fixes format
>>
>> >
>> > Signed-off-by: Rafal Kozik 
>> > Acked-by: Michal Krawczyk 
>> > ---
>> >  drivers/net/ena/ena_ethdev.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
>> > index 5c3b6494f..9ae73e331 100644
>> > --- a/drivers/net/ena/ena_ethdev.c
>> > +++ b/drivers/net/ena/ena_ethdev.c
>> > @@ -848,7 +848,7 @@ static int ena_link_update(struct rte_eth_dev *dev,
>> >   adapter = (struct ena_adapter *)(dev->data->dev_private);
>> >
>> >   link->link_status = adapter->link_status ? ETH_LINK_UP :
>> > ETH_LINK_DOWN;
>> > - link->link_speed = ETH_SPEED_NUM_10G;
>> > + link->link_speed = ETH_SPEED_NUM_NONE;
>> >   link->link_duplex = ETH_LINK_FULL_DUPLEX;
>> >
>> >   return 0;
>> >
>>
>

Re: [dpdk-dev] [PATCH 00/20] add eventmode helper functions

[Jerin Jacob]

-Original Message-
> Date: Fri,  8 Jun 2018 22:53:59 +0530
> From: Anoob Joseph 
> To: Bruce Richardson , Jerin Jacob
>  , Pablo de Lara
>  
> Cc: Anoob Joseph , Hemant Agrawal
>  , Narayana Prasad
>  , Nikhil Rao
>  , Pavan Nikhilesh ,
>  Sunil Kumar Kori , dev@dpdk.org
> Subject: [PATCH 00/20] add eventmode helper functions
> X-Mailer: git-send-email 2.7.4
> 
> This patchset adds common initialization code required for using
> applications in event mode. The APIs exposed, abstracts the complex
> configuration options exposed by eventdev, ethdev & eth rx adapter.
> Also, this enables the usage of multiple workers fine tuned for the
> features of the underlying hardware.
> 
> With these APIs, existing poll mode applications can be made event
> driven easily, and the applications can better leverage the event
> mode's capabilities.
> 
> L2fwd application has been made event-driven to demonstrate the usage
> of helper APIs. Tested with nicvf eth PMD and event_octeontx event
> PMD on Cavium's CN83XX platform.
> 
> Parts of this patchset is inspired by an RFC send by
> Sunil Kumar Kori 

Hi Anoob,

There is bit overlap with Nikhil's TX adapter patches and this series.
I prefer to have Nikhil's Tx adapter gets in first(as he sent the RFC
first) and then rework this series to adapt Tx adapter patches. I think,
this will enable
- application code will be even much cleaner with Tx adapter.
- zero overlap
- no major rework

Nikhil,

When you are planning to send the first version of Tx adapter patch so
we all can review it and give time for Anoob to rework this series
based on Tx adapter APIs'

All,

Is there any concern on overall rte_eventmode_helper.h approach to 
avoid code duplication for Rx and Tx adapter configuration codes
across all the applications?

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/nfp: fix unused header reference

[Alejandro Lucero]

Sure. I will send another version adding that syntax.

Thanks

On Fri, Jun 8, 2018 at 8:49 PM, Ferruh Yigit  wrote:

> On 6/8/2018 11:40 AM, Alejandro Lucero wrote:
> > Apart from not being used, this is causing problem when compiling
> > DPDK with the musl library as reported by bugzilla.
>
> If this is fixing a bugzilla issue, can you please use defined syntax to
> document it:
>
> Bugzilla ID: ###
> Fixes:  ("")
> Cc: sta...@dpdk.org --> [optional if needs to go in stable tree]
>
> >
> > Fixes: c7e9729da6b5 ("net/nfp: support CPP")
> >
> > Signed-off-by: Alejandro Lucero 
> > ---
> >  drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
> b/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
> > index b8541c5..d46574b 100644
> > --- a/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
> > +++ b/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
> > @@ -13,7 +13,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> >
>
>

Re: [dpdk-dev] [PATCH v3 01/27] net/ena: change version number to 1.1.0

[Michał Krawczyk]

2018-06-08 21:45 GMT+02:00 Ferruh Yigit :
> On 6/7/2018 10:42 AM, Michal Krawczyk wrote:
>> The upcoming patches for the ENA PMD are part of 1.1.0 update of the PMD
>> and the version number is updated accordingly.
>
> Does it make sense to add a release notes update to announce driver update?

Is it possible to move the patch at the end of the uploaded patches,
so there won't be need to reupload everything?
The new commit message could be:


net/ena: change version number to 1.1.0

ENA PMD version 1.1.0 introduces:
* Update of the ena_com to the newer version
* Remove support of legacy LLQ
* Watchdog and device reset
* LSC interrupt
* Rx out of order completion
* Linearization of mbufs with too many fragments
* Information about maximum number of Tx and Rx descriptors
* Validation of requested id on Tx (for Tx OOO completion)
* Likely/unlikely statements
* Link speed is now set as none
* Other minor bug fixes and changes
>
>>
>> Signed-off-by: Michal Krawczyk 
> <...>

[dpdk-dev] [PATCH] cryptodev: convert to SPDX license tag

[Pablo de Lara]

Converted the license header of the files
that still have the old full header.

Signed-off-by: Pablo de Lara 
---
 lib/librte_cryptodev/rte_cryptodev.h | 31 ++--
 lib/librte_cryptodev/rte_cryptodev_pmd.h | 31 ++--
 2 files changed, 4 insertions(+), 58 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index bfb52e7f2..a28d08b7e 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -1,32 +1,5 @@
-/*-
- *
- *   Copyright(c) 2015-2017 Intel Corporation. All rights reserved.
- *
- *   Redistribution and use in source and binary forms, with or without
- *   modification, are permitted provided that the following conditions
- *   are met:
- *
- * * Redistributions of source code must retain the above copyright
- *   notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- *   notice, this list of conditions and the following disclaimer in
- *   the documentation and/or other materials provided with the
- *   distribution.
- * * Neither the name of Intel Corporation nor the names of its
- *   contributors may be used to endorse or promote products derived
- *   from this software without specific prior written permission.
- *
- *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2015-2017 Intel Corporation.
  */
 
 #ifndef _RTE_CRYPTODEV_H_
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index b47730eaf..641dd1369 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -1,32 +1,5 @@
-/*-
- *
- *   Copyright(c) 2015-2016 Intel Corporation. All rights reserved.
- *
- *   Redistribution and use in source and binary forms, with or without
- *   modification, are permitted provided that the following conditions
- *   are met:
- *
- * * Redistributions of source code must retain the above copyright
- *   notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- *   notice, this list of conditions and the following disclaimer in
- *   the documentation and/or other materials provided with the
- *   distribution.
- * * Neither the name of Intel Corporation nor the names of its
- *   contributors may be used to endorse or promote products derived
- *   from this software without specific prior written permission.
- *
- *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2015-2016 Intel Corporation.
  */
 
 #ifndef _RTE_CRYPTODEV_PMD_H_
-- 
2.17.0

Re: [dpdk-dev] [RFC] ethdev: remove all offload API

[Ferruh Yigit]

On 6/9/2018 9:04 AM, Andrew Rybchenko wrote:
> On 06/09/2018 01:41 AM, Ferruh Yigit wrote:
>> Cc: Shahaf Shuler 
>>
>> Signed-off-by: Ferruh Yigit 
>> ---
> 
> <...>
> 
>> diff --git a/app/test-eventdev/test_perf_common.c 
>> b/app/test-eventdev/test_perf_common.c
>> index d00f91802..9fe042ffe 100644
>> --- a/app/test-eventdev/test_perf_common.c
>> +++ b/app/test-eventdev/test_perf_common.c
>> @@ -680,13 +680,7 @@ perf_ethdev_setup(struct evt_test *test, struct 
>> evt_options *opt)
>>  .mq_mode = ETH_MQ_RX_RSS,
>>  .max_rx_pkt_len = ETHER_MAX_LEN,
>>  .split_hdr_size = 0,
>> -.header_split   = 0,
>> -.hw_ip_checksum = 0,
>> -.hw_vlan_filter = 0,
>> -.hw_vlan_strip  = 0,
>> -.hw_vlan_extend = 0,
>>  .jumbo_frame= 0,
>> -.hw_strip_crc   = 1,
> 

Hi Andrew,

> I have 2 questions here:
>  1. Why is jumbo_frame kept? There is DEV_RX_OFFLOAD_JUMBO_FRAME.

Because there are still some usage of this flag in PMDs, they need to be
clarified before removing the flag. I am for removing the flag in final version,
but for this RFC I am not able to find enough time to work on PMDs for it.

>  2. Why is hw_strip_crc=1 discarded? Yes, I remember plans to make it
>      default behaviour and introduce flag to keep CRC, but right now the
>  patch looks like mixture of two changes which is not good.

Yes it is wrong, app should replace "".hw_strip_crc=1 with KEEP_CRC offload.
Since both are RFC, kind of hard to maintain, but I think good to create a
dependency from this patch to KEEP_CRC one.

> 
> There are more cases in the patch where hw_strip_crc=1 is simply discarded.
> 
> <...>
> 
>> diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
>> index 1b6499f85..ee8ae5b9f 100644
>> --- a/drivers/net/sfc/sfc_ethdev.c
>> +++ b/drivers/net/sfc/sfc_ethdev.c
>> @@ -1089,7 +1089,6 @@ sfc_tx_queue_info_get(struct rte_eth_dev *dev, 
>> uint16_t tx_queue_id,
>>  
>>  memset(qinfo, 0, sizeof(*qinfo));
>>  
>> -qinfo->conf.txq_flags = txq_info->txq->flags;
>>  qinfo->conf.offloads = txq_info->txq->offloads;
>>  qinfo->conf.tx_free_thresh = txq_info->txq->free_thresh;
>>  qinfo->conf.tx_deferred_start = txq_info->deferred_start;
>> diff --git a/drivers/net/sfc/sfc_rx.c b/drivers/net/sfc/sfc_rx.c
>> index cc76a5b15..58a0df583 100644
>> --- a/drivers/net/sfc/sfc_rx.c
>> +++ b/drivers/net/sfc/sfc_rx.c
>> @@ -1446,7 +1446,6 @@ sfc_rx_check_mode(struct sfc_adapter *sa, struct 
>> rte_eth_rxmode *rxmode)
>>  if (~rxmode->offloads & DEV_RX_OFFLOAD_CRC_STRIP) {
>>  sfc_warn(sa, "FCS stripping cannot be disabled - always on");
>>  rxmode->offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
>> -rxmode->hw_strip_crc = 1;
>>  }
>>  
>>  return rc;
>> diff --git a/drivers/net/sfc/sfc_tx.c b/drivers/net/sfc/sfc_tx.c
>> index 1bcc2c697..6d42a1a65 100644
>> --- a/drivers/net/sfc/sfc_tx.c
>> +++ b/drivers/net/sfc/sfc_tx.c
>> @@ -171,7 +171,6 @@ sfc_tx_qinit(struct sfc_adapter *sa, unsigned int 
>> sw_index,
>>  txq->free_thresh =
>>  (tx_conf->tx_free_thresh) ? tx_conf->tx_free_thresh :
>>  SFC_TX_DEFAULT_FREE_THRESH;
>> -txq->flags = tx_conf->txq_flags;
>>  txq->offloads = offloads;
>>  
>>  rc = sfc_dma_alloc(sa, "txq", sw_index, EFX_TXQ_SIZE(txq_info->entries),
>> @@ -182,7 +181,6 @@ sfc_tx_qinit(struct sfc_adapter *sa, unsigned int 
>> sw_index,
>>  memset(&info, 0, sizeof(info));
>>  info.max_fill_level = txq_max_fill_level;
>>  info.free_thresh = txq->free_thresh;
>> -info.flags = tx_conf->txq_flags;
>>  info.offloads = offloads;
>>  info.txq_entries = txq_info->entries;
>>  info.dma_desc_size_max = encp->enc_tx_dma_desc_size_max;
>> @@ -431,18 +429,10 @@ sfc_tx_qstart(struct sfc_adapter *sa, unsigned int 
>> sw_index)
>>  if (rc != 0)
>>  goto fail_ev_qstart;
>>  
>> -/*
>> - * The absence of ETH_TXQ_FLAGS_IGNORE is associated with a legacy
>> - * application which expects that IPv4 checksum offload is enabled
>> - * all the time as there is no legacy flag to turn off the offload.
>> - */
>> -if ((txq->offloads & DEV_TX_OFFLOAD_IPV4_CKSUM) ||
>> -(~txq->flags & ETH_TXQ_FLAGS_IGNORE))
>> +if (txq->offloads & DEV_TX_OFFLOAD_IPV4_CKSUM)
>>  flags |= EFX_TXQ_CKSUM_IPV4;
>>  
>> -if ((txq->offloads & DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM) ||
>> -((~txq->flags & ETH_TXQ_FLAGS_IGNORE) &&
>> - (offloads_supported & DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM)))
>> +if (txq->offloads & DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM)
>>  flags |= EFX_TXQ_CKSUM_INNER_IPV4;
>>  
>>  if ((txq->offloads & DEV_TX_OFFLOAD_TCP_CKSUM) ||
>> @@ -453,16 +443,7 @@ sfc_tx_qstart(struct sfc_adapter *sa, unsigned int 
>> sw_index)
>>  fla

Re: [dpdk-dev] [RFC] ethdev: add new offload flag to keep CRC

[Ferruh Yigit]

On 6/9/2018 11:11 AM, Andrew Rybchenko wrote:
> On 06/09/2018 01:57 AM, Ferruh Yigit wrote:
>> DEV_RX_OFFLOAD_KEEP_CRC offload flag added.
>>
>> DEV_RX_OFFLOAD_CRC_STRIP flag will remain one more release
>> default behavior in PMDs is to keep the CRC until this flag removed
>>
>> Until DEV_RX_OFFLOAD_CRC_STRIP flag is removed:
>> - Setting both KEEP_CRC & CRC_STRIP is INVALID
> 
> ethdev layer should enforce it.

OK, will add this check.

> 
>> - Setting only CRC_STRIP PMD should strip the CRC
>> - Setting only KEEP_CRC PMD should keep the CRC
>> - Not setting both PMD should keep the CRC
>>
>> Signed-off-by: Ferruh Yigit 
> 
> - rte_rx_offload_names should be updated as well
> - testpmd should be updated
> 
> I'm not sure that I understand the transition plan. I think PMDs which support
> KEEP_CRC should be updated by the patch to advertise the offload. Otherwise,
> generic checks in ethdev will not allow to enable it. 

Right, PMDs should be updated to advertise this offload, will do it.

> Other option is to simply
> drop it on ethdev layer (since basically it changes nothing for PMD now) and
> encourage PMD maintainers to advertise and take it into account if the feature
> is supported (however, if the bit is dropped on ethdev layer, the code would
> be unused/dead regardless application request). Too complicated. I guess
> there are not so many PMDs which support KEEP_CRC. Better to update them

> The patch should encourage applications which would like to keep CRC to
> use the offload since the next release will drop CRC_STRIP and it will
> change behaviour (no KEEP_CRC => strip it)

+1, will check apps.

Re: [dpdk-dev] [PATCH v3 01/27] net/ena: change version number to 1.1.0

[Ferruh Yigit]

On 6/11/2018 9:45 AM, Michał Krawczyk wrote:
> 2018-06-08 21:45 GMT+02:00 Ferruh Yigit :
>> On 6/7/2018 10:42 AM, Michal Krawczyk wrote:
>>> The upcoming patches for the ENA PMD are part of 1.1.0 update of the PMD
>>> and the version number is updated accordingly.
>>
>> Does it make sense to add a release notes update to announce driver update?
> 
> Is it possible to move the patch at the end of the uploaded patches,
> so there won't be need to reupload everything?

Yes release notes update can separate patch, to prevent a new version of all
set, if you are asking this.
Or is there any existing documentation patch I am missing?

> The new commit message could be:
> 
> 
> net/ena: change version number to 1.1.0
> 
> ENA PMD version 1.1.0 introduces:
> * Update of the ena_com to the newer version
> * Remove support of legacy LLQ
> * Watchdog and device reset
> * LSC interrupt
> * Rx out of order completion
> * Linearization of mbufs with too many fragments
> * Information about maximum number of Tx and Rx descriptors
> * Validation of requested id on Tx (for Tx OOO completion)
> * Likely/unlikely statements
> * Link speed is now set as none
> * Other minor bug fixes and changes
>>
>>>
>>> Signed-off-by: Michal Krawczyk 
>> <...>

Re: [dpdk-dev] [PATCH 0/4] support for write combining

[Rafał Kozik]

Hello Thomas,

I have a question about support for write combining patch set.
It got ack from Bruce Richardson more then month ago.
Also no one has any further comments about it.
What is the next step to commit them to DPDK source?

Best regards,
Rafal Kozik

Re: [dpdk-dev] [PATCH v3] doc/event: improve eventdev library documentation

[Jerin Jacob]

-Original Message-
> Date: Wed, 6 Jun 2018 15:30:01 -0500
> From: Honnappa Nagarahalli 
> To: jerin.ja...@caviumnetworks.com, harry.van.haa...@intel.com,
>  honnappa.nagaraha...@arm.com
> CC: dev@dpdk.org
> Subject: [PATCH v3] doc/event: improve eventdev library documentation
> X-Mailer: git-send-email 2.7.4
> 
> Add small amount of additional code, use consistent variable names
> across code blocks, change the image to represent queues and
> CPU cores intuitively. These help improve the eventdev library
> documentation.
> 
> Signed-off-by: Honnappa Nagarahalli 
> Reviewed-by: Gavin Hu 
> Acked-by: Jerin Jacob 
> Acked-by: Harry van Haaren 

Applied to dpdk-next-eventdev/master. Thanks.

Re: [dpdk-dev] [PATCH v3 01/27] net/ena: change version number to 1.1.0

[Michał Krawczyk]

2018-06-11 11:26 GMT+02:00 Ferruh Yigit :
> On 6/11/2018 9:45 AM, Michał Krawczyk wrote:
>> 2018-06-08 21:45 GMT+02:00 Ferruh Yigit :
>>> On 6/7/2018 10:42 AM, Michal Krawczyk wrote:
 The upcoming patches for the ENA PMD are part of 1.1.0 update of the PMD
 and the version number is updated accordingly.
>>>
>>> Does it make sense to add a release notes update to announce driver update?
>>
>> Is it possible to move the patch at the end of the uploaded patches,
>> so there won't be need to reupload everything?
>
> Yes release notes update can separate patch, to prevent a new version of all
> set, if you are asking this.

That would be great, thanks.

> Or is there any existing documentation patch I am missing?

No, there was no documentation patch.

>
>> The new commit message could be:
>>
>>
>> net/ena: change version number to 1.1.0
>>
>> ENA PMD version 1.1.0 introduces:
>> * Update of the ena_com to the newer version
>> * Remove support of legacy LLQ
>> * Watchdog and device reset
>> * LSC interrupt
>> * Rx out of order completion
>> * Linearization of mbufs with too many fragments
>> * Information about maximum number of Tx and Rx descriptors
>> * Validation of requested id on Tx (for Tx OOO completion)
>> * Likely/unlikely statements
>> * Link speed is now set as none
>> * Other minor bug fixes and changes
>>>

 Signed-off-by: Michal Krawczyk 
>>> <...>
>

Re: [dpdk-dev] [PATCH v3 01/27] net/ena: change version number to 1.1.0

[Ferruh Yigit]

On 6/11/2018 10:33 AM, Michał Krawczyk wrote:
> 2018-06-11 11:26 GMT+02:00 Ferruh Yigit :
>> On 6/11/2018 9:45 AM, Michał Krawczyk wrote:
>>> 2018-06-08 21:45 GMT+02:00 Ferruh Yigit :
 On 6/7/2018 10:42 AM, Michal Krawczyk wrote:
> The upcoming patches for the ENA PMD are part of 1.1.0 update of the PMD
> and the version number is updated accordingly.

 Does it make sense to add a release notes update to announce driver update?
>>>
>>> Is it possible to move the patch at the end of the uploaded patches,
>>> so there won't be need to reupload everything?
>>
>> Yes release notes update can separate patch, to prevent a new version of all
>> set, if you are asking this.
> 
> That would be great, thanks.

Just recognized that you will already need to send a new version of the set,
please check the build error on 2/27.

If you confirm you are OK with it, I can fix it while applying via:
s/(u64)/(unsigned long long)

> 
>> Or is there any existing documentation patch I am missing?
> 
> No, there was no documentation patch.
> 
>>
>>> The new commit message could be:
>>>
>>>
>>> net/ena: change version number to 1.1.0
>>>
>>> ENA PMD version 1.1.0 introduces:
>>> * Update of the ena_com to the newer version
>>> * Remove support of legacy LLQ
>>> * Watchdog and device reset
>>> * LSC interrupt
>>> * Rx out of order completion
>>> * Linearization of mbufs with too many fragments
>>> * Information about maximum number of Tx and Rx descriptors
>>> * Validation of requested id on Tx (for Tx OOO completion)
>>> * Likely/unlikely statements
>>> * Link speed is now set as none
>>> * Other minor bug fixes and changes

>
> Signed-off-by: Michal Krawczyk 
 <...>
>>

[dpdk-dev] [PATCH] net/nfp: fix field initialization in TX descriptor

[Alejandro Lucero]

TX descriptor eop_offset field is not initialized and it could
contain garbage. This patch fixes the potential problem setting
EOP as the only subfield. The other subfield, data offset, is
not used by now.

Fixes: b812daadad0d ("nfp: add Rx and Tx")

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfp_net.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index faad1ee..3658696 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2253,11 +2253,15 @@ uint32_t nfp_net_txq_full(struct nfp_net_txq *txq)
txq->wr_p = 0;
 
pkt_size -= dma_size;
-   if (!pkt_size)
-   /* End of packet */
-   txds->offset_eop |= PCIE_DESC_TX_EOP;
+
+   /*
+* Making the EOP, packets with just one segment
+* the priority
+*/
+   if (likely(!pkt_size))
+   txds->offset_eop = PCIE_DESC_TX_EOP;
else
-   txds->offset_eop &= PCIE_DESC_TX_OFFSET_MASK;
+   txds->offset_eop = 0;
 
pkt = pkt->next;
/* Referencing next free TX descriptor */
-- 
1.9.1

Re: [dpdk-dev] [PATCH v3 01/27] net/ena: change version number to 1.1.0

[Michał Krawczyk]

2018-06-11 11:50 GMT+02:00 Ferruh Yigit :
> On 6/11/2018 10:33 AM, Michał Krawczyk wrote:
>> 2018-06-11 11:26 GMT+02:00 Ferruh Yigit :
>>> On 6/11/2018 9:45 AM, Michał Krawczyk wrote:
 2018-06-08 21:45 GMT+02:00 Ferruh Yigit :
> On 6/7/2018 10:42 AM, Michal Krawczyk wrote:
>> The upcoming patches for the ENA PMD are part of 1.1.0 update of the PMD
>> and the version number is updated accordingly.
>
> Does it make sense to add a release notes update to announce driver 
> update?

 Is it possible to move the patch at the end of the uploaded patches,
 so there won't be need to reupload everything?
>>>
>>> Yes release notes update can separate patch, to prevent a new version of all
>>> set, if you are asking this.
>>
>> That would be great, thanks.
>
> Just recognized that you will already need to send a new version of the set,
> please check the build error on 2/27.
>
> If you confirm you are OK with it, I can fix it while applying via:
> s/(u64)/(unsigned long long)

I just prepared patch for this issue and I will send it right away.

>
>>
>>> Or is there any existing documentation patch I am missing?
>>
>> No, there was no documentation patch.
>>
>>>
 The new commit message could be:


 net/ena: change version number to 1.1.0

 ENA PMD version 1.1.0 introduces:
 * Update of the ena_com to the newer version
 * Remove support of legacy LLQ
 * Watchdog and device reset
 * LSC interrupt
 * Rx out of order completion
 * Linearization of mbufs with too many fragments
 * Information about maximum number of Tx and Rx descriptors
 * Validation of requested id on Tx (for Tx OOO completion)
 * Likely/unlikely statements
 * Link speed is now set as none
 * Other minor bug fixes and changes
>
>>
>> Signed-off-by: Michal Krawczyk 
> <...>
>>>
>

[dpdk-dev] [PATCH v4 0/27] net/ena: new features and fixes

[Michal Krawczyk]

The ENA driver was updated with the new features and few fixes and minor
changes are introduced.
First of all, the communication layer which is delivered by vendor was
updated - the version in the HEAD is a bit outdated now. ENA is able to
communicate with the driver through Admin queue by using admin interrupts
instead of polling.
Admin interrupts are also used for handling AENQ events, which are used for
the following new features:
  - LSC handlers
  - watchdog and device rest
  - monitoring the admin queue
  - handling ENA notifications (getting hints from device)
For the watchdog and admin queue monitoring, the timers had to be used, so
the makefile was modified to do not cut out the librte_timer.

>From other fixes and changes:
  - legacy LLQ was removed which is now deprecated API
  - Rx out of order completion was added to enable cleaning up packets out
of order
  - Tx mbufs are now linearized if they exceed supported number of segments
  - pass information about maximum number of Tx and Rx descriptors
  - the IO queue number is now taking into consideration maximum number of
sq and cq
  - Tx id requested for sending is now being validated and the reset is
being triggered if it is invalid
  - branch predictioning was added for better performance
  - error checking and returned values were fixed
  - macros for allocating memory in communication layer were fixed
  - information about numa mode is now being passed to the NIC

---
v4:
* Fix ena_com build error with debug enabled

v3:
* Change version of the ENA PMD to 1.1.0
* Fix icc compile errors
* Remove patch adding librte_timer as --whole-archive (it is already in)
* Add lrte-timer dependency to ENA to resolve error when building DPDK
  as shared library

v2:
* Rebased on top of dpdk-next-net
* Added link speed patch
* Added fix when allocating coherent memory in the PMD

Michal Krawczyk (2):
  net/ena: change version number to 1.1.0
  net/ena: update ena_com to the newer version

 drivers/net/ena/base/ena_com.c  |  710 +++---
 drivers/net/ena/base/ena_com.h  |  112 +--
 drivers/net/ena/base/ena_defs/ena_admin_defs.h  | 1164 +++
 drivers/net/ena/base/ena_defs/ena_common_defs.h |8 +-
 drivers/net/ena/base/ena_defs/ena_eth_io_defs.h |  758 +--
 drivers/net/ena/base/ena_defs/ena_gen_info.h|4 +-
 drivers/net/ena/base/ena_defs/ena_includes.h|2 -
 drivers/net/ena/base/ena_defs/ena_regs_defs.h   |   36 +
 drivers/net/ena/base/ena_eth_com.c  |   78 +-
 drivers/net/ena/base/ena_eth_com.h  |   10 +-
 drivers/net/ena/base/ena_plat.h |2 -
 drivers/net/ena/base/ena_plat_dpdk.h|   39 +-
 drivers/net/ena/ena_ethdev.c|   56 +-
 13 files changed, 1115 insertions(+), 1864 deletions(-)

-- 
2.14.1

[dpdk-dev] [PATCH] net/nfp: fix unused header reference

[Alejandro Lucero]

Apart from not being used, this is causing problem when compiling
DPDK with the musl library as reported by bugzilla.

Bugzilla ID: 40
Fixes: c7e9729da6b5 ("net/nfp: support CPP")

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h 
b/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
index b8541c5..d46574b 100644
--- a/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
+++ b/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.9.1

Re: [dpdk-dev] [PATCH] net/nfp: fix unused header reference

[Alejandro Lucero]

I forgot to add the V2.

I will send it again.

Apologies.

On Mon, Jun 11, 2018 at 10:55 AM, Alejandro Lucero <
alejandro.luc...@netronome.com> wrote:

> Apart from not being used, this is causing problem when compiling
> DPDK with the musl library as reported by bugzilla.
>
> Bugzilla ID: 40
> Fixes: c7e9729da6b5 ("net/nfp: support CPP")
>
> Signed-off-by: Alejandro Lucero 
> ---
>  drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
> b/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
> index b8541c5..d46574b 100644
> --- a/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
> +++ b/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> --
> 1.9.1
>
>

Re: [dpdk-dev] [PATCH] doc: fix octeontx selftest vdev argument

[Jerin Jacob]

-Original Message-
> Date: Fri, 8 Jun 2018 14:03:38 +0530
> From: Pavan Nikhilesh 
> To: Jerin Jacob , sta...@dpdk.org,
>  dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: fix octeontx selftest vdev argument
> User-Agent: Mutt/1.10.0 (2018-05-17)
> 
> On Fri, Jun 08, 2018 at 09:02:27AM +0530, Jerin Jacob wrote:
> > Fixes: 3516327e00fd ("event/octeontx: add selftest to device arguments")
> >
> > Cc: pbhagavat...@caviumnetworks.com
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Jerin Jacob 
> 
> Acked-by: Pavan Nikhilesh 

Applied to dpdk-next-eventdev/master. Thanks.

> 
> > ---
> >  doc/guides/eventdevs/octeontx.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/eventdevs/octeontx.rst 
> > b/doc/guides/eventdevs/octeontx.rst
> > index 3dcf6afbd..18cfc7a9a 100644
> > --- a/doc/guides/eventdevs/octeontx.rst
> > +++ b/doc/guides/eventdevs/octeontx.rst
> > @@ -96,7 +96,7 @@ The tests are run once the vdev creation is successfully 
> > complete.
> >
> >  .. code-block:: console
> >
> > ---vdev="event_octeontx,self_test=1"
> > +--vdev="event_octeontx,selftest=1"
> >
> >
> >  Enable TIMvf stats
> > --
> > 2.17.1
> >

[dpdk-dev] [PATCH v2 1/3] power: add get capabilities API

[Radu Nicolau]

New API added, rte_power_get_capabilities(), that allows the
application to query the power and performance capabilities
of the CPU cores.

Signed-off-by: Radu Nicolau 
---
v2: fixed coding style errors, split test into separate patch

 lib/librte_power/power_acpi_cpufreq.c  | 21 +
 lib/librte_power/power_acpi_cpufreq.h  | 17 +
 lib/librte_power/power_kvm_vm.c|  8 
 lib/librte_power/power_kvm_vm.h| 17 +
 lib/librte_power/rte_power.c   |  3 +++
 lib/librte_power/rte_power.h   | 33 +
 lib/librte_power/rte_power_version.map |  7 +++
 7 files changed, 106 insertions(+)

diff --git a/lib/librte_power/power_acpi_cpufreq.c 
b/lib/librte_power/power_acpi_cpufreq.c
index bce933e..cd5978d 100644
--- a/lib/librte_power/power_acpi_cpufreq.c
+++ b/lib/librte_power/power_acpi_cpufreq.c
@@ -623,3 +623,24 @@ power_acpi_disable_turbo(unsigned int lcore_id)
 
return 0;
 }
+
+int power_acpi_get_capabilities(unsigned int lcore_id,
+   struct rte_power_core_capabilities *caps)
+{
+   struct rte_power_info *pi;
+
+   if (lcore_id >= RTE_MAX_LCORE) {
+   RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+   return -1;
+   }
+   if (caps == NULL) {
+   RTE_LOG(ERR, POWER, "Invalid argument\n");
+   return -1;
+   }
+
+   pi = &lcore_power_info[lcore_id];
+   caps->capabilities = 0;
+   caps->turbo = !!(pi->turbo_available);
+
+   return 0;
+}
diff --git a/lib/librte_power/power_acpi_cpufreq.h 
b/lib/librte_power/power_acpi_cpufreq.h
index edeeb27..77701a9 100644
--- a/lib/librte_power/power_acpi_cpufreq.h
+++ b/lib/librte_power/power_acpi_cpufreq.h
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include "rte_power.h"
 
 #ifdef __cplusplus
 extern "C" {
@@ -196,6 +197,22 @@ int power_acpi_enable_turbo(unsigned int lcore_id);
  */
 int power_acpi_disable_turbo(unsigned int lcore_id);
 
+/**
+ * Returns power capabilities for a specific lcore.
+ *
+ * @param lcore_id
+ *  lcore id.
+ * @param caps
+ *  pointer to rte_power_core_capabilities object.
+ *
+ * @return
+ *  - 0 on success.
+ *  - Negative on error.
+ */
+int power_acpi_get_capabilities(unsigned int lcore_id,
+   struct rte_power_core_capabilities *caps);
+
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_power/power_kvm_vm.c b/lib/librte_power/power_kvm_vm.c
index 38e9066..20659b7 100644
--- a/lib/librte_power/power_kvm_vm.c
+++ b/lib/librte_power/power_kvm_vm.c
@@ -124,3 +124,11 @@ power_kvm_vm_disable_turbo(unsigned int lcore_id)
 {
return send_msg(lcore_id, CPU_POWER_DISABLE_TURBO);
 }
+
+struct rte_power_core_capabilities;
+int power_kvm_vm_get_capabilities(__rte_unused unsigned int lcore_id,
+   __rte_unused struct rte_power_core_capabilities *caps)
+{
+   RTE_LOG(ERR, POWER, "rte_power_get_capabilities is not implemented for 
Virtual Machine Power Management\n");
+   return -ENOTSUP;
+}
diff --git a/lib/librte_power/power_kvm_vm.h b/lib/librte_power/power_kvm_vm.h
index 446d699..94d4aa1 100644
--- a/lib/librte_power/power_kvm_vm.h
+++ b/lib/librte_power/power_kvm_vm.h
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include "rte_power.h"
 
 #ifdef __cplusplus
 extern "C" {
@@ -177,6 +178,22 @@ int power_kvm_vm_enable_turbo(unsigned int lcore_id);
  *  - Negative on error.
  */
 int power_kvm_vm_disable_turbo(unsigned int lcore_id);
+
+/**
+ * Returns power capabilities for a specific lcore.
+ *
+ * @param lcore_id
+ *  lcore id.
+ * @param caps
+ *  pointer to rte_power_core_capabilities object.
+ *
+ * @return
+ *  - 0 on success.
+ *  - Negative on error.
+ */
+int power_kvm_vm_get_capabilities(unsigned int lcore_id,
+   struct rte_power_core_capabilities *caps);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index 6c8fb40..208b791 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -24,6 +24,7 @@ rte_power_freq_change_t rte_power_freq_min = NULL;
 rte_power_freq_change_t rte_power_turbo_status;
 rte_power_freq_change_t rte_power_freq_enable_turbo;
 rte_power_freq_change_t rte_power_freq_disable_turbo;
+rte_power_get_capabilities_t rte_power_get_capabilities;
 
 int
 rte_power_set_env(enum power_management_env env)
@@ -42,6 +43,7 @@ rte_power_set_env(enum power_management_env env)
rte_power_turbo_status = power_acpi_turbo_status;
rte_power_freq_enable_turbo = power_acpi_enable_turbo;
rte_power_freq_disable_turbo = power_acpi_disable_turbo;
+   rte_power_get_capabilities = power_acpi_get_capabilities;
} else if (env == PM_ENV_KVM_VM) {
rte_power_freqs = power_kvm_vm_freqs;
rte_power_get_freq = power_kvm_vm_get_freq;
@@ -53,6 +55,7 @@ rte_power_set_env(enum power_management_env env)
  

[dpdk-dev] [PATCH v2 2/3] test/power: add unit test for get capabilities API

[Radu Nicolau]

Signed-off-by: Radu Nicolau 
---
 test/test/test_power_acpi_cpufreq.c | 42 +
 1 file changed, 42 insertions(+)

diff --git a/test/test/test_power_acpi_cpufreq.c 
b/test/test/test_power_acpi_cpufreq.c
index 8da2dcc..67d5ee0 100644
--- a/test/test/test_power_acpi_cpufreq.c
+++ b/test/test/test_power_acpi_cpufreq.c
@@ -18,6 +18,12 @@ test_power_acpi_cpufreq(void)
printf("Power management library not supported, skipping test\n");
return TEST_SKIPPED;
 }
+static int
+test_power_acpi_caps(void)
+{
+   printf("Power management library not supported, skipping test\n");
+   return TEST_SKIPPED;
+}
 
 #else
 #include 
@@ -517,6 +523,42 @@ test_power_acpi_cpufreq(void)
rte_power_unset_env();
return -1;
 }
+
+static int
+test_power_acpi_caps(void)
+{
+   struct rte_power_core_capabilities caps;
+   int ret;
+
+   ret = rte_power_set_env(PM_ENV_ACPI_CPUFREQ);
+   if (ret) {
+   printf("Error setting ACPI environment\n");
+   return -1;
+   }
+
+   ret = rte_power_init(TEST_POWER_LCORE_ID);
+   if (ret < 0) {
+   printf("Cannot initialise power management for lcore %u, this "
+   "may occur if environment is not configured "
+   "correctly(APCI cpufreq) or operating in another valid "
+   "Power management environment\n", TEST_POWER_LCORE_ID);
+   rte_power_unset_env();
+   return -1;
+   }
+
+   ret = rte_power_get_capabilities(TEST_POWER_LCORE_ID, &caps);
+   if (ret) {
+   printf("ACPI: Error getting capabilities\n");
+   return -1;
+   }
+
+   printf("ACPI: Capabilities %lx\n", caps.capabilities);
+
+   rte_power_unset_env();
+   return 0;
+}
+
 #endif
 
 REGISTER_TEST_COMMAND(power_acpi_cpufreq_autotest, test_power_acpi_cpufreq);
+REGISTER_TEST_COMMAND(power_acpi_caps_autotest, test_power_acpi_caps);
-- 
2.7.5

[dpdk-dev] [PATCH v2 3/3] examples/l3fw-power: add high/regular performance cores option

[Radu Nicolau]

Added high/regular performance core pinning configuration options
that can be used in place of the existing 'config' option.

'--high-perf-cores CORELIST' option allow the user to specify a
high performance cores list; if this option is not used and the
'perf-config' option is used, the application will query the
system using the rte_power library in order to get a list of
available high performance cores. The cores that are considered
high performance are the cores that have turbo enabled.

'--perf-config (port,queue,hi_perf,lcore_index)'
option is similar to the existing config option, the cores are specified
as indices for bins containing high or regular performance cores.

Example:

l3fwd-power -l 6,7 -- -p 0xff \
--high-perf-cores 6 --perf-config="(0,0,0,0),(1,0,1,0)"

cores 6 and 7 are used, core 6 is specified as a high performance core.
port 0 queue 0 will use a regular performance core, index 0 (core 7)
port 1 queue 0 will use a high performance core, index 0 (core 6)

Signed-off-by: Radu Nicolau 
---
 examples/l3fwd-power/Makefile|   4 +-
 examples/l3fwd-power/main.c  |  74 ++---
 examples/l3fwd-power/main.h  |  20 
 examples/l3fwd-power/meson.build |   4 +-
 examples/l3fwd-power/perf_core.c | 230 +++
 examples/l3fwd-power/perf_core.h |  12 ++
 6 files changed, 323 insertions(+), 21 deletions(-)
 create mode 100644 examples/l3fwd-power/main.h
 create mode 100644 examples/l3fwd-power/perf_core.c
 create mode 100644 examples/l3fwd-power/perf_core.h

diff --git a/examples/l3fwd-power/Makefile b/examples/l3fwd-power/Makefile
index 390b7d6..1a46033 100644
--- a/examples/l3fwd-power/Makefile
+++ b/examples/l3fwd-power/Makefile
@@ -1,11 +1,11 @@
 # SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2010-2014 Intel Corporation
+# Copyright(c) 2010-2018 Intel Corporation
 
 # binary name
 APP = l3fwd-power
 
 # all source are stored in SRCS-y
-SRCS-y := main.c
+SRCS-y := main.c perf_core.c
 
 # Build using pkg-config variables if possible
 $(shell pkg-config --exists libdpdk)
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index 596d645..2268d54 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2010-2016 Intel Corporation
+ * Copyright(c) 2010-2018 Intel Corporation
  */
 
 #include 
@@ -44,6 +44,9 @@
 #include 
 #include 
 
+#include "perf_core.h"
+#include "main.h"
+
 #define RTE_LOGTYPE_L3FWD_POWER RTE_LOGTYPE_USER1
 
 #define MAX_PKT_BURST 32
@@ -155,14 +158,7 @@ struct lcore_rx_queue {
 #define MAX_RX_QUEUE_INTERRUPT_PER_PORT 16
 
 
-#define MAX_LCORE_PARAMS 1024
-struct lcore_params {
-   uint16_t port_id;
-   uint8_t queue_id;
-   uint8_t lcore_id;
-} __rte_cache_aligned;
-
-static struct lcore_params lcore_params_array[MAX_LCORE_PARAMS];
+struct lcore_params lcore_params_array[MAX_LCORE_PARAMS];
 static struct lcore_params lcore_params_array_default[] = {
{0, 0, 2},
{0, 1, 2},
@@ -175,8 +171,8 @@ static struct lcore_params lcore_params_array_default[] = {
{3, 1, 3},
 };
 
-static struct lcore_params * lcore_params = lcore_params_array_default;
-static uint16_t nb_lcore_params = sizeof(lcore_params_array_default) /
+struct lcore_params *lcore_params = lcore_params_array_default;
+uint16_t nb_lcore_params = sizeof(lcore_params_array_default) /
sizeof(lcore_params_array_default[0]);
 
 static struct rte_eth_conf port_conf = {
@@ -1121,10 +1117,15 @@ print_usage(const char *prgname)
 {
printf ("%s [EAL options] -- -p PORTMASK -P"
"  [--config (port,queue,lcore)[,(port,queue,lcore]]"
+   "  [--high-perf-cores CORELIST"
+   "  [--perf-config 
(port,queue,hi_perf,lcore_index)[,(port,queue,hi_perf,lcore_index]]"
"  [--enable-jumbo [--max-pkt-len PKTLEN]]\n"
"  -p PORTMASK: hexadecimal bitmask of ports to configure\n"
"  -P : enable promiscuous mode\n"
"  --config (port,queue,lcore): rx queues configuration\n"
+   "  --high-perf-cores CORELIST: list of high performance cores\n"
+   "  --perf-config: similar as config, cores specified as indices"
+   " for bins containing high or regular performance cores\n"
"  --no-numa: optional, disable numa awareness\n"
"  --enable-jumbo: enable jumbo frame"
" which max packet len is PKTLEN in decimal (64-9600)\n"
@@ -1234,6 +1235,8 @@ parse_args(int argc, char **argv)
char *prgname = argv[0];
static struct option lgopts[] = {
{"config", 1, 0, 0},
+   {"perf-config", 1, 0, 0},
+   {"high-perf-cores", 1, 0, 0},
{"no-numa", 0, 0, 0},
{"enable-jumbo", 0, 0, 0},
{CMD_LINE_OPT_PARSE_PTYPE, 0, 0, 0},
@@ -1272,6 +1275,26 @@ parse_arg

Re: [dpdk-dev] [PATCH v3] test/eventdev: add multi port test to suite

[Jerin Jacob]

-Original Message-
> Date: Mon, 21 May 2018 19:23:55 +0530
> From: Vipin Varghese 
> To: dev@dpdk.org, nikhil@intel.com, deepak.k.j...@intel.com
> CC: Vipin Varghese 
> Subject: [dpdk-dev] [PATCH v3] test/eventdev: add multi port test to suite
> X-Mailer: git-send-email 2.7.4
> 
> Add a new test to enhance the test suite, to allow multiple eth ports
> rx queue to be added to rx bridge adapter. Update the test function to
> reflect change of port index from 8 to 16 bit
> 
> Signed-off-by: Vipin Varghese 
> Acked-by: Nikhil Rao 

Acked-by: Jerin Jacob 

Applied to dpdk-next-eventdev/master. Thanks.

> ---
> 
> Changes in V3:
> - removed residue code for capabilities - Nikhil Rao
> - removed free instance safe guard - Nikhil Rao
> 
> Changes in V2:
> - reprhased the variable names for dtiver - Nikhil Rao
> - Initialization removed for driver_name - Nikhil Rao
> - removed adapter capability instance - Nikhil Rao
> - reprhased comment - Nikhil Rao
> ---
>  test/test/test_event_eth_rx_adapter.c | 71 
> ++-
>  1 file changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git a/test/test/test_event_eth_rx_adapter.c 
> b/test/test/test_event_eth_rx_adapter.c
> index dee632b..d432731 100644
> --- a/test/test/test_event_eth_rx_adapter.c
> +++ b/test/test/test_event_eth_rx_adapter.c
> @@ -110,12 +110,18 @@ init_ports(int num_ports)
>   uint16_t portid;
>   int retval;
>  
> - default_params.mp = rte_pktmbuf_pool_create("packet_pool",
> + struct rte_mempool *ptr = rte_mempool_lookup("packet_pool");
> +
> + if (ptr == NULL)
> + default_params.mp = rte_pktmbuf_pool_create("packet_pool",
>   NB_MBUFS,
>   MBUF_CACHE_SIZE,
>   MBUF_PRIV_SIZE,
>   RTE_MBUF_DEFAULT_BUF_SIZE,
>   rte_socket_id());
> + else
> + default_params.mp = ptr;
> +
>   if (!default_params.mp)
>   return -ENOMEM;
>  
> @@ -333,6 +339,68 @@ adapter_queue_add_del(void)
>  }
>  
>  static int
> +adapter_multi_eth_add_del(void)
> +{
> + int err;
> + struct rte_event ev;
> +
> + uint16_t port_index, drv_id = 0;
> + char driver_name[50];
> +
> + struct rte_event_eth_rx_adapter_queue_conf queue_config;
> +
> + ev.queue_id = 0;
> + ev.sched_type = RTE_SCHED_TYPE_ATOMIC;
> + ev.priority = 0;
> +
> + queue_config.rx_queue_flags = 0;
> + queue_config.ev = ev;
> + queue_config.servicing_weight = 1;
> +
> + /* stop eth devices for existing */
> + port_index = 0;
> + for (; port_index < rte_eth_dev_count_total(); port_index += 1)
> + rte_eth_dev_stop(port_index);
> +
> + /* add the max port for rx_adapter */
> + port_index = rte_eth_dev_count_total();
> + for (; port_index < RTE_MAX_ETHPORTS; port_index += 1) {
> + sprintf(driver_name, "%s%u", "net_null", drv_id);
> + err = rte_vdev_init(driver_name, NULL);
> + TEST_ASSERT(err == 0, "Failed driver %s got %d",
> + driver_name, err);
> + drv_id += 1;
> + }
> +
> + err = init_ports(rte_eth_dev_count_total());
> + TEST_ASSERT(err == 0, "Port initialization failed err %d\n", err);
> +
> + /* creating new instance for all newly added eth devices */
> + adapter_create();
> +
> + /* eth_rx_adapter_queue_add for n ports */
> + port_index = 0;
> + for (; port_index < rte_eth_dev_count_total(); port_index += 1) {
> + err = rte_event_eth_rx_adapter_queue_add(TEST_INST_ID,
> + port_index, 0,
> + &queue_config);
> + TEST_ASSERT(err == 0, "Expected 0 got %d", err);
> + }
> +
> + /* eth_rx_adapter_queue_del n ports */
> + port_index = 0;
> + for (; port_index < rte_eth_dev_count_total(); port_index += 1) {
> + err = rte_event_eth_rx_adapter_queue_del(TEST_INST_ID,
> + port_index, 0);
> + TEST_ASSERT(err == 0, "Expected 0 got %d", err);
> + }
> +
> + adapter_free();
> +
> + return TEST_SUCCESS;
> +}
> +
> +static int
>  adapter_start_stop(void)
>  {
>   int err;
> @@ -410,6 +478,7 @@ static struct unit_test_suite service_tests  = {
>   TEST_CASE_ST(NULL, NULL, adapter_create_free),
>   TEST_CASE_ST(adapter_create, adapter_free,
>   adapter_queue_add_del),
> + TEST_CASE_ST(NULL, NULL, adapter_multi_eth_add_del),
>   TEST_CASE_ST(adapter_create, adapter_free, adapter_start_stop),
>   TEST_CASE_ST(adapter_create, adapter_free, adapter_stats),
>   TEST_CASES_END() /**< NULL terminate unit test array */
> -- 
> 2.7.4
> 

Re: [dpdk-dev] [PATCH v4 2/2] net/ena: update ena_com to the newer version

[Ferruh Yigit]

On 6/11/2018 10:54 AM, Michal Krawczyk wrote:
> ena_com is the HAL provided by the vendor and it shouldn't be modified
> by the driver developers.
> 
> The PMD and platform file was adjusted for the new version of the
> ena_com:
> * Do not use deprecated meta descriptor fields
> * Add empty AENQ handler structure with unimplemented handlers
> * Add memzone allocations count to ena_ethdev.c file - it was
>   removed from ena_com.c file
> * Add new macros used in new ena_com files
> * Use error code ENA_COM_UNSUPPORTED instead of ENA_COM_PERMISSION
> 
> Signed-off-by: Michal Krawczyk 
> Signed-off-by: Rafal Kozik 

Can you please check following?

.../dpdk/drivers/net/ena/base/ena_com.c: In function 
‘ena_com_aenq_intr_handler’:
.../dpdk/drivers/net/ena/base/ena_com.c:1833:21: error: variable ‘timestamp’ set
but not used [-Werror=unused-but-set-variable]
  unsigned long long timestamp;
 ^

[dpdk-dev] [RFC v2] ethdev: support MPLS tunnel encapsulation action

[Ori Kam]

Until now MPLS tunnel is supported only for checksum and
TSO offloading.

IN DPDK 18.05 some encapsulation API has been added for
VXLAN and NVGRE.

This patch adds the encapsulation offload for the MPLS tunnel type.

Signed-off-by: Ori Kam 

---
v2: Specific MPLS encapsulation RFC

v1: generic tunnel encapsulation RFC [1].
The generic approach must be discussed some more
so it will not be ready for the 18.08 DPDK release.

This MPLS-specific API targets 18.08 and is based on the current
encapsulation API.

[1] http://dpdk.org/ml/archives/dev/2018-June/103485.html
---
---
 doc/guides/prog_guide/rte_flow.rst |   54 
 lib/librte_ethdev/rte_flow.h   |   54 
 2 files changed, 108 insertions(+), 0 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index b305a72..e40f9fe 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2076,6 +2076,60 @@ RTE_FLOW_ERROR_TYPE_ACTION error should be returned.
 
 This action modifies the payload of matched flows.
 
+Action: ``MPLS_L2_ENCAP``
+^
+
+Performs MPLS encapsulation action over L2 inner packet by encapsulating
+the matched flow with the requested MPLS tunnel as defined in 
+the``rte_flow_action_mpls_l2_encap`` flow item
+definition.
+
+This action modifies the payload of matched flows. The flow definition 
specified
+in the ``rte_flow_action_mpls_l2_encap`` action structure must defined a valid
+MPLS network overlay. The pattern must be
+terminated with the RTE_FLOW_ITEM_TYPE_END item type.
+
+.. _table_rte_flow_action_mpls_l2_encap:
+
+.. table:: MPLS_ENCAP
+
+   ++-+
+   | Field  | Value   |
+   ++=+
+   | ``definition`` | MPLS end-point overlay definition  |
+   ++-+
+
+.. _table_rte_flow_action_mpls_l2_encap_example:
+
+.. table:: IPv4 GRE MPLS flow pattern example.
+
+   +---+--+
+   | Index | Item |
+   +===+==+
+   | 0 | Ethernet |
+   +---+--+
+   | 1 | IPv4 |
+   +---+--+
+   | 2 | GRE  |
+   +---+--+
+   | 3 | MPLS |
+   +---+--+
+   | 4 | END  |
+   +---+--+
+
+Action: ``MPLS_l2_DECAP``
+^
+
+Performs a decapsulation action by stripping all headers of the MPLS tunnel
+network overlay from the matched flow.
+
+The flow items pattern defined for the flow rule with which a ``MPLS_DECAP``
+action is specified, must define a valid MPLS tunnel. If the
+flow pattern does not specify a valid MPLS tunnel then a
+RTE_FLOW_ERROR_TYPE_ACTION error should be returned.
+
+This action modifies the payload of matched flows.
+
 Negative types
 ~~
 
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index f8ba71c..6edce68 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -1505,6 +1505,23 @@ enum rte_flow_action_type {
 * error.
 */
RTE_FLOW_ACTION_TYPE_NVGRE_DECAP,
+
+   /**
+* Encapsulate flow in MPLS L2 tunnel defined in the
+* rte_flow_action_mpls_l2_encap action structure.
+*
+* See struct rte_flow_action_mpls_l2_encap.
+*/
+   RTE_FLOW_ACTION_TYPE_MPLS_L2_ENCAP,
+
+   /**
+* Decapsulate outer most MPLS L2 tunnel from matched flow.
+*
+* If flow pattern does not define a valid MPLS L2 tunnel
+* then the PMD should return a RTE_FLOW_ERROR_TYPE_ACTION
+* error.
+*/
+   RTE_FLOW_ACTION_TYPE_MPLS_L2_DECAP,
 };
 
 /**
@@ -1868,6 +1885,43 @@ struct rte_flow_action_nvgre_encap {
struct rte_flow_item *definition;
 };
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ACTION_TYPE_MPLS_L2_ENCAP
+ *
+ * MPLS l2 tunnel end-point encapsulation data definition
+ *
+ * The tunnel definition is provided through the flow item pattern.
+ * This action includes both MPLSoGRE and MPLSoUDP.
+ * The flow definition must be provided in order from the 
+ * RTE_FLOW_ITEM_TYPE_ETH definition up the end item,
+ * which is specified by RTE_FLOW_ITEM_TYPE_END.
+ *
+ * The mask field allows user to specify which fields in the flow item
+ * definitions can be ignored and which have valid data and can be used
+ * verbatim.
+ *
+ * Note: the last field is not used in the definition of a tunnel and can be
+ * ignored.
+ *
+ * Example of valid flow definition for RTE_FLOW_ACTION_TYPE_MPLS_L2_ENCAP:
+ *
+ * - ETH / IPV4 / GRE / MPLS / END
+ * - ETH / VLAN / IPV4 / GRE / MPLS / END
+ * - ETH / IPV4 / UDP / MPLS / END
+ * - ETH / VLAN / IPV4 / UDP / MPLS / END
+ *
+ */
+struct rte_flow_action_mpls_l2_encap {
+   /**
+* Encapsulatin

Re: [dpdk-dev] [RFC] ethdev: support MPLS tunnel encapsulation action

[Ori Kam]

The generic encapsulation approach has been
replaced by this more specific MPLS API.

As a consequence it is better threaded as v2 of the
generic API proposal, which may be considered again for 
later release.

This version of the RFC is discarded in patchwork

> -Original Message-
> Due to time risk and to enable more discussion over
> the proposed generic tunnel encapsulation [1]
> 
> This RFC only adds encapsulation for MPLS tunnel type,
> which is based on the current tunnel encapsulaiton actions.
> 
> [1] http://dpdk.org/ml/archives/dev/2018-June/103485.html
> 
> Signed-off-by: Ori Kam 

Re: [dpdk-dev] [RFC] ethdev: remove all offload API

[Shahaf Shuler]

Hi Ferruh,

Thanks for this patch. 

Monday, June 11, 2018 12:10 PM, Ferruh Yigit:
> Subject: Re: [RFC] ethdev: remove all offload API
> 
> On 6/9/2018 9:04 AM, Andrew Rybchenko wrote:
> > On 06/09/2018 01:41 AM, Ferruh Yigit wrote:
> >> Cc: Shahaf Shuler 
> >>
> >> Signed-off-by: Ferruh Yigit 
> >> ---
> >
> > <...>
> >
> >> diff --git a/app/test-eventdev/test_perf_common.c
> >> b/app/test-eventdev/test_perf_common.c
> >> index d00f91802..9fe042ffe 100644
> >> --- a/app/test-eventdev/test_perf_common.c
> >> +++ b/app/test-eventdev/test_perf_common.c
> >> @@ -680,13 +680,7 @@ perf_ethdev_setup(struct evt_test *test, struct
> evt_options *opt)
> >>.mq_mode = ETH_MQ_RX_RSS,
> >>.max_rx_pkt_len = ETHER_MAX_LEN,
> >>.split_hdr_size = 0,
> >> -  .header_split   = 0,
> >> -  .hw_ip_checksum = 0,
> >> -  .hw_vlan_filter = 0,
> >> -  .hw_vlan_strip  = 0,
> >> -  .hw_vlan_extend = 0,
> >>.jumbo_frame= 0,
> >> -  .hw_strip_crc   = 1,
> >
> 
> Hi Andrew,
> 
> > I have 2 questions here:
> >  1. Why is jumbo_frame kept? There is
> DEV_RX_OFFLOAD_JUMBO_FRAME.
> 
> Because there are still some usage of this flag in PMDs, they need to be
> clarified before removing the flag. I am for removing the flag in final 
> version,
> but for this RFC I am not able to find enough time to work on PMDs for it.

Can you elaborate?
Is this something more than just a replace of the jumbo_frame bit with its 
corresponding flag? 

> 
> >  2. Why is hw_strip_crc=1 discarded? Yes, I remember plans to make it
> >      default behaviour and introduce flag to keep CRC, but right now
> > the
> >  patch looks like mixture of two changes which is not good.
> 
> Yes it is wrong, app should replace "".hw_strip_crc=1 with KEEP_CRC offload.
> Since both are RFC, kind of hard to maintain, but I think good to create a
> dependency from this patch to KEEP_CRC one.
> 
> >
> > There are more cases in the patch where hw_strip_crc=1 is simply
> discarded.
> >
> > <...>
> >
> >> diff --git a/drivers/net/sfc/sfc_ethdev.c
> >> b/drivers/net/sfc/sfc_ethdev.c index 1b6499f85..ee8ae5b9f 100644
> >> --- a/drivers/net/sfc/sfc_ethdev.c
> >> +++ b/drivers/net/sfc/sfc_ethdev.c
> >> @@ -1089,7 +1089,6 @@ sfc_tx_queue_info_get(struct rte_eth_dev
> *dev,
> >> uint16_t tx_queue_id,
> >>
> >>memset(qinfo, 0, sizeof(*qinfo));
> >>
> >> -  qinfo->conf.txq_flags = txq_info->txq->flags;
> >>qinfo->conf.offloads = txq_info->txq->offloads;
> >>qinfo->conf.tx_free_thresh = txq_info->txq->free_thresh;
> >>qinfo->conf.tx_deferred_start = txq_info->deferred_start; diff
> >> --git a/drivers/net/sfc/sfc_rx.c b/drivers/net/sfc/sfc_rx.c index
> >> cc76a5b15..58a0df583 100644
> >> --- a/drivers/net/sfc/sfc_rx.c
> >> +++ b/drivers/net/sfc/sfc_rx.c
> >> @@ -1446,7 +1446,6 @@ sfc_rx_check_mode(struct sfc_adapter *sa,
> struct rte_eth_rxmode *rxmode)
> >>if (~rxmode->offloads & DEV_RX_OFFLOAD_CRC_STRIP) {
> >>sfc_warn(sa, "FCS stripping cannot be disabled - always on");
> >>rxmode->offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
> >> -  rxmode->hw_strip_crc = 1;
> >>}
> >>
> >>return rc;
> >> diff --git a/drivers/net/sfc/sfc_tx.c b/drivers/net/sfc/sfc_tx.c
> >> index 1bcc2c697..6d42a1a65 100644
> >> --- a/drivers/net/sfc/sfc_tx.c
> >> +++ b/drivers/net/sfc/sfc_tx.c
> >> @@ -171,7 +171,6 @@ sfc_tx_qinit(struct sfc_adapter *sa, unsigned int
> sw_index,
> >>txq->free_thresh =
> >>(tx_conf->tx_free_thresh) ? tx_conf->tx_free_thresh :
> >>SFC_TX_DEFAULT_FREE_THRESH;
> >> -  txq->flags = tx_conf->txq_flags;
> >>txq->offloads = offloads;
> >>
> >>rc = sfc_dma_alloc(sa, "txq", sw_index,
> >> EFX_TXQ_SIZE(txq_info->entries), @@ -182,7 +181,6 @@
> sfc_tx_qinit(struct sfc_adapter *sa, unsigned int sw_index,
> >>memset(&info, 0, sizeof(info));
> >>info.max_fill_level = txq_max_fill_level;
> >>info.free_thresh = txq->free_thresh;
> >> -  info.flags = tx_conf->txq_flags;
> >>info.offloads = offloads;
> >>info.txq_entries = txq_info->entries;
> >>info.dma_desc_size_max = encp->enc_tx_dma_desc_size_max;
> @@ -431,18
> >> +429,10 @@ sfc_tx_qstart(struct sfc_adapter *sa, unsigned int sw_index)
> >>if (rc != 0)
> >>goto fail_ev_qstart;
> >>
> >> -  /*
> >> -   * The absence of ETH_TXQ_FLAGS_IGNORE is associated with a
> legacy
> >> -   * application which expects that IPv4 checksum offload is enabled
> >> -   * all the time as there is no legacy flag to turn off the offload.
> >> -   */
> >> -  if ((txq->offloads & DEV_TX_OFFLOAD_IPV4_CKSUM) ||
> >> -  (~txq->flags & ETH_TXQ_FLAGS_IGNORE))
> >> +  if (txq->offloads & DEV_TX_OFFLOAD_IPV4_CKSUM)
> >>flags |= EFX_TXQ_CKSUM_IPV4;
> >>
> >> -  if ((txq->offloads & DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM) ||
> >> -  ((~txq->flags & ETH_TXQ_FLAGS_IGNOR

[dpdk-dev] [PATCH v5 0/27] net/ena: new features and fixes

[Michal Krawczyk]

The ENA driver was updated with the new features and few fixes and minor
changes are introduced.
First of all, the communication layer which is delivered by vendor was
updated - the version in the HEAD is a bit outdated now. ENA is able to
communicate with the driver through Admin queue by using admin interrupts
instead of polling.
Admin interrupts are also used for handling AENQ events, which are used for
the following new features:
  - LSC handlers
  - watchdog and device rest
  - monitoring the admin queue
  - handling ENA notifications (getting hints from device)
For the watchdog and admin queue monitoring, the timers had to be used, so
the makefile was modified to do not cut out the librte_timer.

>From other fixes and changes:
  - legacy LLQ was removed which is now deprecated API
  - Rx out of order completion was added to enable cleaning up packets out
of order
  - Tx mbufs are now linearized if they exceed supported number of segments
  - pass information about maximum number of Tx and Rx descriptors
  - the IO queue number is now taking into consideration maximum number of
sq and cq
  - Tx id requested for sending is now being validated and the reset is
being triggered if it is invalid
  - branch predictioning was added for better performance
  - error checking and returned values were fixed
  - macros for allocating memory in communication layer were fixed
  - information about numa mode is now being passed to the NIC

---
v5:
* Fix icc compile error in ena_com (timestamp unsused if debug not set)

v4:
* Fix ena_com build error with debug enabled

v3:
* Change version of the ENA PMD to 1.1.0
* Fix icc compile errors
* Remove patch adding librte_timer as --whole-archive (it is already in)
* Add lrte-timer dependency to ENA to resolve error when building DPDK
  as shared library

v2:
* Rebased on top of dpdk-next-net
* Added link speed patch
* Added fix when allocating coherent memory in the PMD

Michal Krawczyk (12):
  net/ena: change version number to 1.1.0
  net/ena: update ena_com to the newer version
  net/ena: add interrupt handler for admin queue
  net/ena: add stop and uninit routines
  net/ena: add LSC intr support and AENQ handling
  net/ena: restart only initialized queues instead of all
  net/ena: add reset routine
  net/ena: add lrte_timer dependency for linking
  net/ena: add watchdog and keep alive AENQ handler
  net/ena: add checking for admin queue state
  net/ena: add RX out of order completion
  net/ena: store handle after memory allocation

Rafal Kozik (15):
  net/ena: remove support of legacy LLQ
  net/ena: handle ENA notification
  net/ena: make watchdog configurable
  net/ena: linearize Tx mbuf
  net/ena: add info about max number of Tx/Rx descriptors
  net/ena: unimplemented handler error
  net/ena: rework configuration of IO queue numbers
  net/ena: validate Tx req id
  net/ena: add (un)likely statements
  net/ena: adjust error checking and cleaning
  net/ena: update numa node
  net/ena: check pointer before memset
  net/ena: change memory type
  net/ena: fix GENMASK_ULL macro
  net/ena: set link speed as none

 drivers/net/ena/Makefile|1 +
 drivers/net/ena/base/ena_com.c  |  711 +++---
 drivers/net/ena/base/ena_com.h  |  112 +--
 drivers/net/ena/base/ena_defs/ena_admin_defs.h  | 1164 +++
 drivers/net/ena/base/ena_defs/ena_common_defs.h |8 +-
 drivers/net/ena/base/ena_defs/ena_eth_io_defs.h |  758 +--
 drivers/net/ena/base/ena_defs/ena_gen_info.h|4 +-
 drivers/net/ena/base/ena_defs/ena_includes.h|2 -
 drivers/net/ena/base/ena_defs/ena_regs_defs.h   |   36 +
 drivers/net/ena/base/ena_eth_com.c  |   78 +-
 drivers/net/ena/base/ena_eth_com.h  |   10 +-
 drivers/net/ena/base/ena_plat.h |2 -
 drivers/net/ena/base/ena_plat_dpdk.h|   74 +-
 drivers/net/ena/ena_ethdev.c|  720 +++---
 drivers/net/ena/ena_ethdev.h|   32 +-
 mk/rte.app.mk   |1 +
 16 files changed, 1710 insertions(+), 2003 deletions(-)

-- 
2.14.1

Re: [dpdk-dev] [RFC] ethdev: support tunnel encapsulation action

[Ori Kam]

Due to the very short release cycle for this
18.08 release, and the need for good discussions,
It is more reasonable to target 18.11 for this proposal.

The intent is to have a good generic API for all tunnel encapsulation
and working well with all HW constraints.

So please let's start the multi-vendor discussion now.

For your information I have submitted a patch for MPLS only (as v2) 
to be integrated in 18.08 in the meantime. 

> -Original Message-
> From: Ori Kam
> Sent: Tuesday, June 5, 2018 6:48 PM
> To: ferruh.yi...@intel.com; declan.dohe...@intel.com; dev@dpdk.org;
> Adrien Mazarguil ; Nélio Laranjeiro
> ; Ori Kam 
> Subject: [RFC] ethdev: support tunnel encapsulation action
> 
> This RFC contain proposal to add generic support for tunnel
> encapsulation/decapsulation.
> 
> Due to the fact that there are many possible tunnel types
> and each tunnel type has number of header variations, there
> is a need for some generic command.
> 
> example for tunnel headers in case of MPLSoGRE:
> ETH / VLAN / IPV4 / GRE / MPLS / ETH / IP / L4-L7
> ETH / VLAN / IPV6 / GRE / MPLS / ETH / IP / L4-L7
> ETH / IPV4 / GRE / MPLS / ETH / IP / L4-L7
> ETH / IPV6 / GRE / MPLS / ETH / IP / L4-L7
> ETH / VLAN / IPV4 / GRE / MPLS / IP / L4-L7
> ETH / VLAN / IPV6 / GRE / MPLS / IP / L4-L7
> ETH / IPV4 / GRE / MPLS / IP / L4-L7
> ETH / IPV6 / GRE / MPLS / IP / L4-L7
> 
> As can be seen from the examples some of the encapsulation
> is done by overwriting the inner L2 packet spec.
> 
> To support all of those configuration it is much
> easer if we create 2 encap functions one that
> is used to encap L2 packet and one that is used
> to encap L3 packet by removing the L2 and applying
> the encapsulation header.
> 
> The use of void * buffer will enable the
> insertion of any valid encapsulation header.
> the use of such a buffer will also simplify the processing
> needed to validate and apply vs the use of rte_flow_items.
> The use of a buffer will also will be easer
> for some applications (for example vrouter)
> 
> For decap we will also have 2 actions
> one for decaping a packet with inner L2
> and one for decaping a packet with inner L3.
> when decaping L3 packet the user should
> supplay the L2 data which should be added to the inner packet.
> 
> Signed-off-by: Ori Kam 
> ---
>  doc/guides/prog_guide/rte_flow.rst |  141 ++-
>  lib/librte_ethdev/rte_flow.h   |  165 +-
> -
>  2 files changed, 161 insertions(+), 145 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index b305a72..7417833 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1969,112 +1969,95 @@ Implements ``OFPAT_PUSH_MPLS`` ("push a
> new MPLS tag") as defined by the
> | ``ethertype`` | EtherType |
> +---+---+
> 
> -Action: ``VXLAN_ENCAP``
> -^^^
> -
> -Performs a VXLAN encapsulation action by encapsulating the matched flow
> in the
> -VXLAN tunnel as defined in the``rte_flow_action_vxlan_encap`` flow items
> -definition.
> +Action: ``TUNNEL_ENCAP``
> +
> 
> -This action modifies the payload of matched flows. The flow definition
> specified
> -in the ``rte_flow_action_tunnel_encap`` action structure must define a valid
> -VLXAN network overlay which conforms with RFC 7348 (Virtual eXtensible
> Local
> -Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2
> Networks
> -over Layer 3 Networks). The pattern must be terminated with the
> -RTE_FLOW_ITEM_TYPE_END item type.
> +Perform a tunnel encapsulation action by encapsulating the matched flow
> with
> +the given buffer.
> 
> -.. _table_rte_flow_action_vxlan_encap:
> +This action modifies the payload of the matched flows.
> +The buffer must hold a valid tunnel encapsulation header.
> 
> -.. table:: VXLAN_ENCAP
> +.. _table_rte_flow_action_tunnel_encap:
> 
> +.. table:: TUNNEL_ENCAP
> +
> ++-+
> | Field  | Value   |
> ++=+
> -   | ``definition`` | Tunnel end-point overlay definition |
> +   | ``type``   | Encapsulation tunnel type.  |
> +   ++-+
> +   | ``buf``| The encapsulation header.   |
> +   ++-+
> +   | ``len``| Buf len.|
> ++-+
> 
> -.. _table_rte_flow_action_vxlan_encap_example:
> -
> -.. table:: IPv4 VxLAN flow pattern example.
> -
> -   +---+--+
> -   | Index | Item |
> -   +===+==+
> -   | 0 | Ethernet |
> -   +---+--+
> -   | 1 | IPv4 |
> -   +---+--+
> -   | 2 | UDP  |
> -   +---+--+
> -   | 

Re: [dpdk-dev] [PATCH v5 0/27] net/ena: new features and fixes

[Ferruh Yigit]

On 6/11/2018 12:00 PM, Michal Krawczyk wrote:
> The ENA driver was updated with the new features and few fixes and minor
> changes are introduced.
> First of all, the communication layer which is delivered by vendor was
> updated - the version in the HEAD is a bit outdated now. ENA is able to
> communicate with the driver through Admin queue by using admin interrupts
> instead of polling.
> Admin interrupts are also used for handling AENQ events, which are used for
> the following new features:
>   - LSC handlers
>   - watchdog and device rest
>   - monitoring the admin queue
>   - handling ENA notifications (getting hints from device)
> For the watchdog and admin queue monitoring, the timers had to be used, so
> the makefile was modified to do not cut out the librte_timer.
> 
> From other fixes and changes:
>   - legacy LLQ was removed which is now deprecated API
>   - Rx out of order completion was added to enable cleaning up packets out
> of order
>   - Tx mbufs are now linearized if they exceed supported number of segments
>   - pass information about maximum number of Tx and Rx descriptors
>   - the IO queue number is now taking into consideration maximum number of
> sq and cq
>   - Tx id requested for sending is now being validated and the reset is
> being triggered if it is invalid
>   - branch predictioning was added for better performance
>   - error checking and returned values were fixed
>   - macros for allocating memory in communication layer were fixed
>   - information about numa mode is now being passed to the NIC
> 
> ---
> v5:
> * Fix icc compile error in ena_com (timestamp unsused if debug not set)

perhaps no so important but to clarify, this is not an ICC specific issue, this
is a unused variable warning!

[dpdk-dev] [PATCH v3] doc: add suggested new feature order to release notes

[Ferruh Yigit]

Signed-off-by: Ferruh Yigit 
Acked-by: John McNamara 
---
Cc: Shreyansh Jain 

v2:
* Wording fixed

v3:
* Used suggested multi line format
* added abstraction layer and PMDs order
---
 doc/guides/rel_notes/release_18_08.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/rel_notes/release_18_08.rst 
b/doc/guides/rel_notes/release_18_08.rst
index 5bc23c537..b6f0c030e 100644
--- a/doc/guides/rel_notes/release_18_08.rst
+++ b/doc/guides/rel_notes/release_18_08.rst
@@ -37,6 +37,15 @@ New Features
 
  Refer to the previous release notes for examples.
 
+ Suggested order in release notes items:
+ * Core libs
+ * Device abstraction libs and PMDs
+   + ethdev - ethdev PMDs, cryptodev - cryptodev PMDs, etc..
+ * Other libs
+ * Apps
+ * Examples
+ * Unit tests
+
  This section is a comment. Do not overwrite or remove it.
  Also, make sure to start the actual text at the margin.
  =
-- 
2.14.4

Re: [dpdk-dev] [RFC] ethdev: remove all offload API

[Ferruh Yigit]

On 6/11/2018 12:00 PM, Shahaf Shuler wrote:
> Hi Ferruh,
> 
> Thanks for this patch. 
> 
> Monday, June 11, 2018 12:10 PM, Ferruh Yigit:
>> Subject: Re: [RFC] ethdev: remove all offload API
>>
>> On 6/9/2018 9:04 AM, Andrew Rybchenko wrote:
>>> On 06/09/2018 01:41 AM, Ferruh Yigit wrote:
 Cc: Shahaf Shuler 

 Signed-off-by: Ferruh Yigit 
 ---
>>>
>>> <...>
>>>
 diff --git a/app/test-eventdev/test_perf_common.c
 b/app/test-eventdev/test_perf_common.c
 index d00f91802..9fe042ffe 100644
 --- a/app/test-eventdev/test_perf_common.c
 +++ b/app/test-eventdev/test_perf_common.c
 @@ -680,13 +680,7 @@ perf_ethdev_setup(struct evt_test *test, struct
>> evt_options *opt)
.mq_mode = ETH_MQ_RX_RSS,
.max_rx_pkt_len = ETHER_MAX_LEN,
.split_hdr_size = 0,
 -  .header_split   = 0,
 -  .hw_ip_checksum = 0,
 -  .hw_vlan_filter = 0,
 -  .hw_vlan_strip  = 0,
 -  .hw_vlan_extend = 0,
.jumbo_frame= 0,
 -  .hw_strip_crc   = 1,
>>>
>>
>> Hi Andrew,
>>
>>> I have 2 questions here:
>>>  1. Why is jumbo_frame kept? There is
>> DEV_RX_OFFLOAD_JUMBO_FRAME.
>>
>> Because there are still some usage of this flag in PMDs, they need to be
>> clarified before removing the flag. I am for removing the flag in final 
>> version,
>> but for this RFC I am not able to find enough time to work on PMDs for it.
> 
> Can you elaborate?
> Is this something more than just a replace of the jumbo_frame bit with its 
> corresponding flag? 

That was my concern that copy paste won't be enough because some drivers not
just use the jumbo_frame but set it based on max_rx_pkt_len etc.., that is why
left out .jumbo_frame in the RFC.

> 
>>
>>>  2. Why is hw_strip_crc=1 discarded? Yes, I remember plans to make it
>>>      default behaviour and introduce flag to keep CRC, but right now
>>> the
>>>  patch looks like mixture of two changes which is not good.
>>
>> Yes it is wrong, app should replace "".hw_strip_crc=1 with KEEP_CRC offload.
>> Since both are RFC, kind of hard to maintain, but I think good to create a
>> dependency from this patch to KEEP_CRC one.
>>
>>>
>>> There are more cases in the patch where hw_strip_crc=1 is simply
>> discarded.
>>>
>>> <...>
>>>
 diff --git a/drivers/net/sfc/sfc_ethdev.c
 b/drivers/net/sfc/sfc_ethdev.c index 1b6499f85..ee8ae5b9f 100644
 --- a/drivers/net/sfc/sfc_ethdev.c
 +++ b/drivers/net/sfc/sfc_ethdev.c
 @@ -1089,7 +1089,6 @@ sfc_tx_queue_info_get(struct rte_eth_dev
>> *dev,
 uint16_t tx_queue_id,

memset(qinfo, 0, sizeof(*qinfo));

 -  qinfo->conf.txq_flags = txq_info->txq->flags;
qinfo->conf.offloads = txq_info->txq->offloads;
qinfo->conf.tx_free_thresh = txq_info->txq->free_thresh;
qinfo->conf.tx_deferred_start = txq_info->deferred_start; diff
 --git a/drivers/net/sfc/sfc_rx.c b/drivers/net/sfc/sfc_rx.c index
 cc76a5b15..58a0df583 100644
 --- a/drivers/net/sfc/sfc_rx.c
 +++ b/drivers/net/sfc/sfc_rx.c
 @@ -1446,7 +1446,6 @@ sfc_rx_check_mode(struct sfc_adapter *sa,
>> struct rte_eth_rxmode *rxmode)
if (~rxmode->offloads & DEV_RX_OFFLOAD_CRC_STRIP) {
sfc_warn(sa, "FCS stripping cannot be disabled - always on");
rxmode->offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
 -  rxmode->hw_strip_crc = 1;
}

return rc;
 diff --git a/drivers/net/sfc/sfc_tx.c b/drivers/net/sfc/sfc_tx.c
 index 1bcc2c697..6d42a1a65 100644
 --- a/drivers/net/sfc/sfc_tx.c
 +++ b/drivers/net/sfc/sfc_tx.c
 @@ -171,7 +171,6 @@ sfc_tx_qinit(struct sfc_adapter *sa, unsigned int
>> sw_index,
txq->free_thresh =
(tx_conf->tx_free_thresh) ? tx_conf->tx_free_thresh :
SFC_TX_DEFAULT_FREE_THRESH;
 -  txq->flags = tx_conf->txq_flags;
txq->offloads = offloads;

rc = sfc_dma_alloc(sa, "txq", sw_index,
 EFX_TXQ_SIZE(txq_info->entries), @@ -182,7 +181,6 @@
>> sfc_tx_qinit(struct sfc_adapter *sa, unsigned int sw_index,
memset(&info, 0, sizeof(info));
info.max_fill_level = txq_max_fill_level;
info.free_thresh = txq->free_thresh;
 -  info.flags = tx_conf->txq_flags;
info.offloads = offloads;
info.txq_entries = txq_info->entries;
info.dma_desc_size_max = encp->enc_tx_dma_desc_size_max;
>> @@ -431,18
 +429,10 @@ sfc_tx_qstart(struct sfc_adapter *sa, unsigned int sw_index)
if (rc != 0)
goto fail_ev_qstart;

 -  /*
 -   * The absence of ETH_TXQ_FLAGS_IGNORE is associated with a
>> legacy
 -   * application which expects that IPv4 checksum offload is enabled
 -   * all the time as there is no legacy flag to turn off the offload.
 -   */
 -  if ((txq->offloads & DEV_TX_OFFLOAD_IPV4_CK

Re: [dpdk-dev] [RFC] ethdev: support tunnel encapsulation action

[Thomas Monjalon]

11/06/2018 13:03, Ori Kam:
> Due to the very short release cycle for this
> 18.08 release, and the need for good discussions,
> It is more reasonable to target 18.11 for this proposal.

I agree the timeframe is too short in 18.08 to accept such
a new generic API.

> The intent is to have a good generic API for all tunnel encapsulation
> and working well with all HW constraints.
> 
> So please let's start the multi-vendor discussion now.

Adding more people as Cc to let the discussion starting.


> For your information I have submitted a patch for MPLS only (as v2) 
> to be integrated in 18.08 in the meantime. 

Yes it is more reasonnable to extend the API introduced in 18.05,
by adding MPLS in 18.08.
This API requires to declare every tunnel protocols we want to offload.
If a more generic API can be found, it could replace the "18.05 one" later.

[dpdk-dev] [PATCH v2] net/nfp: fix unused header reference

[Alejandro Lucero]

Apart from not being used, this is causing problem when compiling
DPDK with the musl library as reported by bugzilla.

Bugzilla ID: 40
Fixes: c7e9729da6b5 ("net/nfp: support CPP")

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h 
b/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
index b8541c5..d46574b 100644
--- a/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
+++ b/drivers/net/nfp/nfpcore/nfp-common/nfp_platform.h
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.9.1

Re: [dpdk-dev] [RFC] ethdev: remove all offload API

[Ananyev, Konstantin]

> -Original Message-
> From: Yigit, Ferruh
> Sent: Monday, June 11, 2018 12:18 PM
> To: Shahaf Shuler ; Andrew Rybchenko 
> ; Jerin Jacob
> ; Lu, Wenzhuo ; Wu, 
> Jingjing ; Iremonger,
> Bernard ; Mcnamara, John 
> ; Kovacevic, Marko
> ; Neil Horman ; Horton, 
> Remy ; Ori Kam
> ; Richardson, Bruce ; De Lara 
> Guarch, Pablo
> ; Nicolau, Radu ; 
> Akhil Goyal ; Kantecki, Tomasz
> ; Van Haaren, Harry ; 
> Jijiang Liu ; Ravi Kumar
> ; Ananyev, Konstantin ; 
> Maxime Coquelin
> ; Bie, Tiwei ; Yong Wang 
> ; Mokhtar, Amr
> ; Doherty, Declan ; Chas 
> Williams ; Hunt, David
> ; Dumitrescu, Cristian ; 
> Burakov, Anatoly ;
> Pattan, Reshma ; Marohn, Byron 
> ; Thomas Monjalon
> 
> Cc: dev@dpdk.org
> Subject: Re: [RFC] ethdev: remove all offload API
> 
> On 6/11/2018 12:00 PM, Shahaf Shuler wrote:
> > Hi Ferruh,
> >
> > Thanks for this patch.
> >
> > Monday, June 11, 2018 12:10 PM, Ferruh Yigit:
> >> Subject: Re: [RFC] ethdev: remove all offload API
> >>
> >> On 6/9/2018 9:04 AM, Andrew Rybchenko wrote:
> >>> On 06/09/2018 01:41 AM, Ferruh Yigit wrote:
>  Cc: Shahaf Shuler 
> 
>  Signed-off-by: Ferruh Yigit 
>  ---
> >>>
> >>> <...>
> >>>
>  diff --git a/app/test-eventdev/test_perf_common.c
>  b/app/test-eventdev/test_perf_common.c
>  index d00f91802..9fe042ffe 100644
>  --- a/app/test-eventdev/test_perf_common.c
>  +++ b/app/test-eventdev/test_perf_common.c
>  @@ -680,13 +680,7 @@ perf_ethdev_setup(struct evt_test *test, struct
> >> evt_options *opt)
>   .mq_mode = ETH_MQ_RX_RSS,
>   .max_rx_pkt_len = ETHER_MAX_LEN,
>   .split_hdr_size = 0,
>  -.header_split   = 0,
>  -.hw_ip_checksum = 0,
>  -.hw_vlan_filter = 0,
>  -.hw_vlan_strip  = 0,
>  -.hw_vlan_extend = 0,
>   .jumbo_frame= 0,
>  -.hw_strip_crc   = 1,
> >>>
> >>
> >> Hi Andrew,
> >>
> >>> I have 2 questions here:
> >>>  1. Why is jumbo_frame kept? There is
> >> DEV_RX_OFFLOAD_JUMBO_FRAME.
> >>
> >> Because there are still some usage of this flag in PMDs, they need to be
> >> clarified before removing the flag. I am for removing the flag in final 
> >> version,
> >> but for this RFC I am not able to find enough time to work on PMDs for it.
> >
> > Can you elaborate?
> > Is this something more than just a replace of the jumbo_frame bit with its 
> > corresponding flag?
> 
> That was my concern that copy paste won't be enough because some drivers not
> just use the jumbo_frame but set it based on max_rx_pkt_len etc.., that is why
> left out .jumbo_frame in the RFC.

But max_rx_pkt_len need to be remained (and properly processed anyway) no?
BTW, I always wonder is there any reason to have jumbo_frame flag at all
(as we do have max_rx_pkt_len anyway)?
Konstantin

> 
> >
> >>
> >>>  2. Why is hw_strip_crc=1 discarded? Yes, I remember plans to make it
> >>>      default behaviour and introduce flag to keep CRC, but right now
> >>> the
> >>>  patch looks like mixture of two changes which is not good.
> >>
> >> Yes it is wrong, app should replace "".hw_strip_crc=1 with KEEP_CRC 
> >> offload.
> >> Since both are RFC, kind of hard to maintain, but I think good to create a
> >> dependency from this patch to KEEP_CRC one.
> >>
> >>>
> >>> There are more cases in the patch where hw_strip_crc=1 is simply
> >> discarded.
> >>>
> >>> <...>
> >>>
>  diff --git a/drivers/net/sfc/sfc_ethdev.c
>  b/drivers/net/sfc/sfc_ethdev.c index 1b6499f85..ee8ae5b9f 100644
>  --- a/drivers/net/sfc/sfc_ethdev.c
>  +++ b/drivers/net/sfc/sfc_ethdev.c
>  @@ -1089,7 +1089,6 @@ sfc_tx_queue_info_get(struct rte_eth_dev
> >> *dev,
>  uint16_t tx_queue_id,
> 
>   memset(qinfo, 0, sizeof(*qinfo));
> 
>  -qinfo->conf.txq_flags = txq_info->txq->flags;
>   qinfo->conf.offloads = txq_info->txq->offloads;
>   qinfo->conf.tx_free_thresh = txq_info->txq->free_thresh;
>   qinfo->conf.tx_deferred_start = txq_info->deferred_start; diff
>  --git a/drivers/net/sfc/sfc_rx.c b/drivers/net/sfc/sfc_rx.c index
>  cc76a5b15..58a0df583 100644
>  --- a/drivers/net/sfc/sfc_rx.c
>  +++ b/drivers/net/sfc/sfc_rx.c
>  @@ -1446,7 +1446,6 @@ sfc_rx_check_mode(struct sfc_adapter *sa,
> >> struct rte_eth_rxmode *rxmode)
>   if (~rxmode->offloads & DEV_RX_OFFLOAD_CRC_STRIP) {
>   sfc_warn(sa, "FCS stripping cannot be disabled - always 
>  on");
>   rxmode->offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
>  -rxmode->hw_strip_crc = 1;
>   }
> 
>   return rc;
>  diff --git a/drivers/net/sfc/sfc_tx.c b/drivers/net/sfc/sfc_tx.c
>  index 1bcc2c697..6d42a1a65 100644
>  --- a/drivers/net/s

Re: [dpdk-dev] [RFC] ethdev: remove all offload API

[Ferruh Yigit]

On 6/11/2018 12:26 PM, Ananyev, Konstantin wrote:
> 
> 
>> -Original Message-
>> From: Yigit, Ferruh
>> Sent: Monday, June 11, 2018 12:18 PM
>> To: Shahaf Shuler ; Andrew Rybchenko 
>> ; Jerin Jacob
>> ; Lu, Wenzhuo ; Wu, 
>> Jingjing ; Iremonger,
>> Bernard ; Mcnamara, John 
>> ; Kovacevic, Marko
>> ; Neil Horman ; Horton, 
>> Remy ; Ori Kam
>> ; Richardson, Bruce ; De 
>> Lara Guarch, Pablo
>> ; Nicolau, Radu ; 
>> Akhil Goyal ; Kantecki, Tomasz
>> ; Van Haaren, Harry ; 
>> Jijiang Liu ; Ravi Kumar
>> ; Ananyev, Konstantin ; 
>> Maxime Coquelin
>> ; Bie, Tiwei ; Yong Wang 
>> ; Mokhtar, Amr
>> ; Doherty, Declan ; Chas 
>> Williams ; Hunt, David
>> ; Dumitrescu, Cristian 
>> ; Burakov, Anatoly 
>> ;
>> Pattan, Reshma ; Marohn, Byron 
>> ; Thomas Monjalon
>> 
>> Cc: dev@dpdk.org
>> Subject: Re: [RFC] ethdev: remove all offload API
>>
>> On 6/11/2018 12:00 PM, Shahaf Shuler wrote:
>>> Hi Ferruh,
>>>
>>> Thanks for this patch.
>>>
>>> Monday, June 11, 2018 12:10 PM, Ferruh Yigit:
 Subject: Re: [RFC] ethdev: remove all offload API

 On 6/9/2018 9:04 AM, Andrew Rybchenko wrote:
> On 06/09/2018 01:41 AM, Ferruh Yigit wrote:
>> Cc: Shahaf Shuler 
>>
>> Signed-off-by: Ferruh Yigit 
>> ---
>
> <...>
>
>> diff --git a/app/test-eventdev/test_perf_common.c
>> b/app/test-eventdev/test_perf_common.c
>> index d00f91802..9fe042ffe 100644
>> --- a/app/test-eventdev/test_perf_common.c
>> +++ b/app/test-eventdev/test_perf_common.c
>> @@ -680,13 +680,7 @@ perf_ethdev_setup(struct evt_test *test, struct
 evt_options *opt)
>>  .mq_mode = ETH_MQ_RX_RSS,
>>  .max_rx_pkt_len = ETHER_MAX_LEN,
>>  .split_hdr_size = 0,
>> -.header_split   = 0,
>> -.hw_ip_checksum = 0,
>> -.hw_vlan_filter = 0,
>> -.hw_vlan_strip  = 0,
>> -.hw_vlan_extend = 0,
>>  .jumbo_frame= 0,
>> -.hw_strip_crc   = 1,
>

 Hi Andrew,

> I have 2 questions here:
>  1. Why is jumbo_frame kept? There is
 DEV_RX_OFFLOAD_JUMBO_FRAME.

 Because there are still some usage of this flag in PMDs, they need to be
 clarified before removing the flag. I am for removing the flag in final 
 version,
 but for this RFC I am not able to find enough time to work on PMDs for it.
>>>
>>> Can you elaborate?
>>> Is this something more than just a replace of the jumbo_frame bit with its 
>>> corresponding flag?
>>
>> That was my concern that copy paste won't be enough because some drivers not
>> just use the jumbo_frame but set it based on max_rx_pkt_len etc.., that is 
>> why
>> left out .jumbo_frame in the RFC.
> 
> But max_rx_pkt_len need to be remained (and properly processed anyway) no?

Yes, it will remain.

> BTW, I always wonder is there any reason to have jumbo_frame flag at all
> (as we do have max_rx_pkt_len anyway)?

agree that jumbo_frame flag, max_rx_pkt_len and mtu usage/relation can be
clarified more.

> Konstantin
> 
>>
>>>

>  2. Why is hw_strip_crc=1 discarded? Yes, I remember plans to make it
>      default behaviour and introduce flag to keep CRC, but right now
> the
>  patch looks like mixture of two changes which is not good.

 Yes it is wrong, app should replace "".hw_strip_crc=1 with KEEP_CRC 
 offload.
 Since both are RFC, kind of hard to maintain, but I think good to create a
 dependency from this patch to KEEP_CRC one.

>
> There are more cases in the patch where hw_strip_crc=1 is simply
 discarded.
>
> <...>
>
>> diff --git a/drivers/net/sfc/sfc_ethdev.c
>> b/drivers/net/sfc/sfc_ethdev.c index 1b6499f85..ee8ae5b9f 100644
>> --- a/drivers/net/sfc/sfc_ethdev.c
>> +++ b/drivers/net/sfc/sfc_ethdev.c
>> @@ -1089,7 +1089,6 @@ sfc_tx_queue_info_get(struct rte_eth_dev
 *dev,
>> uint16_t tx_queue_id,
>>
>>  memset(qinfo, 0, sizeof(*qinfo));
>>
>> -qinfo->conf.txq_flags = txq_info->txq->flags;
>>  qinfo->conf.offloads = txq_info->txq->offloads;
>>  qinfo->conf.tx_free_thresh = txq_info->txq->free_thresh;
>>  qinfo->conf.tx_deferred_start = txq_info->deferred_start; diff
>> --git a/drivers/net/sfc/sfc_rx.c b/drivers/net/sfc/sfc_rx.c index
>> cc76a5b15..58a0df583 100644
>> --- a/drivers/net/sfc/sfc_rx.c
>> +++ b/drivers/net/sfc/sfc_rx.c
>> @@ -1446,7 +1446,6 @@ sfc_rx_check_mode(struct sfc_adapter *sa,
 struct rte_eth_rxmode *rxmode)
>>  if (~rxmode->offloads & DEV_RX_OFFLOAD_CRC_STRIP) {
>>  sfc_warn(sa, "FCS stripping cannot be disabled - always 
>> on");
>>  rxmode->offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
>> -  

Re: [dpdk-dev] [RFC] ethdev: remove all offload API

[Shahaf Shuler]

Monday, June 11, 2018 2:26 PM, Ananyev, Konstantin:
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] ethdev: remove all offload API
> > Subject: Re: [RFC] ethdev: remove all offload API
> >
> > On 6/11/2018 12:00 PM, Shahaf Shuler wrote:
> > > Hi Ferruh,
> > >
> > > Thanks for this patch.
> > >
> > > Monday, June 11, 2018 12:10 PM, Ferruh Yigit:
> > >> Subject: Re: [RFC] ethdev: remove all offload API
> > >>
> > >> On 6/9/2018 9:04 AM, Andrew Rybchenko wrote:
> > >>> On 06/09/2018 01:41 AM, Ferruh Yigit wrote:
> >  Cc: Shahaf Shuler 
> > 
> >  Signed-off-by: Ferruh Yigit 
> >  ---
> > >>>
> > >>> <...>
> > >>>
> >  diff --git a/app/test-eventdev/test_perf_common.c
> >  b/app/test-eventdev/test_perf_common.c
> >  index d00f91802..9fe042ffe 100644
> >  --- a/app/test-eventdev/test_perf_common.c
> >  +++ b/app/test-eventdev/test_perf_common.c
> >  @@ -680,13 +680,7 @@ perf_ethdev_setup(struct evt_test *test,
> >  struct
> > >> evt_options *opt)
> > .mq_mode = ETH_MQ_RX_RSS,
> > .max_rx_pkt_len = ETHER_MAX_LEN,
> > .split_hdr_size = 0,
> >  -  .header_split   = 0,
> >  -  .hw_ip_checksum = 0,
> >  -  .hw_vlan_filter = 0,
> >  -  .hw_vlan_strip  = 0,
> >  -  .hw_vlan_extend = 0,
> > .jumbo_frame= 0,
> >  -  .hw_strip_crc   = 1,
> > >>>
> > >>
> > >> Hi Andrew,
> > >>
> > >>> I have 2 questions here:
> > >>>  1. Why is jumbo_frame kept? There is
> > >> DEV_RX_OFFLOAD_JUMBO_FRAME.
> > >>
> > >> Because there are still some usage of this flag in PMDs, they need
> > >> to be clarified before removing the flag. I am for removing the
> > >> flag in final version, but for this RFC I am not able to find enough 
> > >> time to
> work on PMDs for it.
> > >
> > > Can you elaborate?
> > > Is this something more than just a replace of the jumbo_frame bit with its
> corresponding flag?
> >
> > That was my concern that copy paste won't be enough because some
> > drivers not just use the jumbo_frame but set it based on
> > max_rx_pkt_len etc.., that is why left out .jumbo_frame in the RFC.

I understand the max_rx_pkt_len consideration, but in the end there is some 
logic which decide if to set/not the jumbo_frame bit. I would expect it just to 
replace it with the JUMBO_FRAME flag w/o touching the rest of the logic.

Can you refer to some specific file which you encounter it? 

> 
> But max_rx_pkt_len need to be remained (and properly processed anyway)
> no?
> BTW, I always wonder is there any reason to have jumbo_frame flag at all (as
> we do have max_rx_pkt_len anyway)?

I share the same thought, and it was expressed in multiple threads. There is 
more - {MTU, SCATTER, JUMBO_FRAME}, all are connected and depended only on 
max_rx_pkt_len and mbuf size. 
However I think it is too much work to include into this RFC and completely 
orthogonal. 

> Konstantin
> 
> >
> > >
> > >>
> > >>>  2. Why is hw_strip_crc=1 discarded? Yes, I remember plans to make
> > >>> it
> > >>>      default behaviour and introduce flag to keep CRC, but right
> > >>> now the
> > >>>  patch looks like mixture of two changes which is not good.
> > >>
> > >> Yes it is wrong, app should replace "".hw_strip_crc=1 with KEEP_CRC
> offload.
> > >> Since both are RFC, kind of hard to maintain, but I think good to
> > >> create a dependency from this patch to KEEP_CRC one.
> > >>
> > >>>
> > >>> There are more cases in the patch where hw_strip_crc=1 is simply
> > >> discarded.
> > >>>
> > >>> <...>
> > >>>
> >  diff --git a/drivers/net/sfc/sfc_ethdev.c
> >  b/drivers/net/sfc/sfc_ethdev.c index 1b6499f85..ee8ae5b9f 100644
> >  --- a/drivers/net/sfc/sfc_ethdev.c
> >  +++ b/drivers/net/sfc/sfc_ethdev.c
> >  @@ -1089,7 +1089,6 @@ sfc_tx_queue_info_get(struct rte_eth_dev
> > >> *dev,
> >  uint16_t tx_queue_id,
> > 
> > memset(qinfo, 0, sizeof(*qinfo));
> > 
> >  -  qinfo->conf.txq_flags = txq_info->txq->flags;
> > qinfo->conf.offloads = txq_info->txq->offloads;
> > qinfo->conf.tx_free_thresh = txq_info->txq->free_thresh;
> > qinfo->conf.tx_deferred_start = txq_info->deferred_start;
> diff
> >  --git a/drivers/net/sfc/sfc_rx.c b/drivers/net/sfc/sfc_rx.c index
> >  cc76a5b15..58a0df583 100644
> >  --- a/drivers/net/sfc/sfc_rx.c
> >  +++ b/drivers/net/sfc/sfc_rx.c
> >  @@ -1446,7 +1446,6 @@ sfc_rx_check_mode(struct sfc_adapter *sa,
> > >> struct rte_eth_rxmode *rxmode)
> > if (~rxmode->offloads & DEV_RX_OFFLOAD_CRC_STRIP) {
> > sfc_warn(sa, "FCS stripping cannot be disabled -
> always on");
> > rxmode->offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
> >  -  rxmode->hw_strip_crc = 1;
> > }
> >

Re: [dpdk-dev] [PATCH 4/7] net/mlx5: re-indent generic probing function

[Xueming(Steven) Li]

Reviewed-by: Xueming(Steven) Li 

> -Original Message-
> From: dev  On Behalf Of Adrien Mazarguil
> Sent: Saturday, May 26, 2018 12:35 AM
> To: Shahaf Shuler 
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH 4/7] net/mlx5: re-indent generic probing function
> 
> Since commit "net/mlx5: split PCI from generic probing code" extracted the 
> inner loop to a separate
> function, mlx5_dev_spawn_one() is left with an unnecessary indent level.
> 
> This patch eliminates a block, moves its local variables to function scope, 
> and re-indents its
> contents.
> 
> No functional impact.
> 
> Signed-off-by: Adrien Mazarguil 
> ---
>  drivers/net/mlx5/mlx5.c | 589 +--
>  1 file changed, 286 insertions(+), 303 deletions(-)
> 
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c index 
> 7a812ef93..d57e8118c 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -658,8 +658,27 @@ mlx5_dev_spawn_one(struct rte_device *dpdk_dev,
>  unsigned int port)
>  {
>   struct ibv_context *ctx;
> + struct ibv_port_attr port_attr;
> + struct ibv_pd *pd = NULL;
>   struct mlx5dv_context dv_attr = { .comp_mask = 0 };
> + struct mlx5_dev_config config = {
> + .vf = !!vf,
> + .tx_vec_en = 1,
> + .rx_vec_en = 1,
> + .mpw_hdr_dseg = 0,
> + .txq_inline = MLX5_ARG_UNSET,
> + .txqs_inline = MLX5_ARG_UNSET,
> + .inline_max_packet_sz = MLX5_ARG_UNSET,
> + .vf_nl_en = 1,
> + .mprq = {
> + .enabled = 0,
> + .stride_num_n = MLX5_MPRQ_STRIDE_NUM_N,
> + .max_memcpy_len = MLX5_MPRQ_MEMCPY_DEFAULT_LEN,
> + .min_rxqs_num = MLX5_MPRQ_MIN_RXQS,
> + },
> + };
>   struct rte_eth_dev *eth_dev = NULL;
> + struct priv *priv = NULL;
>   int err = 0;
>   unsigned int mps;
>   unsigned int cqe_comp;
> @@ -675,6 +694,8 @@ mlx5_dev_spawn_one(struct rte_device *dpdk_dev,  #ifdef
> HAVE_IBV_DEVICE_COUNTERS_SET_SUPPORT
>   struct ibv_counter_set_description cs_desc;  #endif
> + struct ether_addr mac;
> + char name[RTE_ETH_NAME_MAX_LEN];
> 
>   /* Prepare shared data between primary and secondary process. */
>   mlx5_prepare_shared_data();
> @@ -710,11 +731,13 @@ mlx5_dev_spawn_one(struct rte_device *dpdk_dev,
>   DRV_LOG(DEBUG, "MPW isn't supported");
>   mps = MLX5_MPW_DISABLED;
>   }
> + config.mps = mps;
>  #ifdef HAVE_IBV_MLX5_MOD_SWP
>   if (dv_attr.comp_mask & MLX5DV_CONTEXT_MASK_SWP)
>   swp = dv_attr.sw_parsing_caps.sw_parsing_offloads;
>   DRV_LOG(DEBUG, "SWP support: %u", swp);  #endif
> + config.swp = !!swp;
>  #ifdef HAVE_IBV_DEVICE_STRIDING_RQ_SUPPORT
>   if (dv_attr.comp_mask & MLX5DV_CONTEXT_MASK_STRIDING_RQ) {
>   struct mlx5dv_striding_rq_caps mprq_caps = @@ -740,6 +763,8 @@ 
> mlx5_dev_spawn_one(struct
> rte_device *dpdk_dev,
>   mprq_caps.min_single_wqe_log_num_of_strides;
>   mprq_max_stride_num_n =
>   mprq_caps.max_single_wqe_log_num_of_strides;
> + config.mprq.stride_num_n = RTE_MAX(MLX5_MPRQ_STRIDE_NUM_N,
> +mprq_min_stride_num_n);
>   }
>  #endif
>   if (RTE_CACHE_LINE_SIZE == 128 &&
> @@ -747,6 +772,7 @@ mlx5_dev_spawn_one(struct rte_device *dpdk_dev,
>   cqe_comp = 0;
>   else
>   cqe_comp = 1;
> + config.cqe_comp = cqe_comp;
>  #ifdef HAVE_IBV_DEVICE_TUNNEL_SUPPORT
>   if (dv_attr.comp_mask & MLX5DV_CONTEXT_MASK_TUNNEL_OFFLOADS) {
>   tunnel_en = ((dv_attr.tunnel_offloads_caps & @@ -760,6 +786,7 
> @@ mlx5_dev_spawn_one(struct
> rte_device *dpdk_dev,
>   DRV_LOG(WARNING,
>   "tunnel offloading disabled due to old OFED/rdma-core 
> version");  #endif
> + config.tunnel_en = tunnel_en;
>  #ifdef HAVE_IBV_DEVICE_MPLS_SUPPORT
>   mpls_en = ((dv_attr.tunnel_offloads_caps &
>   MLX5DV_RAW_PACKET_CAP_TUNNELED_OFFLOAD_CW_MPLS_OVER_GRE) && 
> @@ -771,325 +798,281 @@
> mlx5_dev_spawn_one(struct rte_device *dpdk_dev,
>   DRV_LOG(WARNING, "MPLS over GRE/UDP tunnel offloading disabled due to"
>   " old OFED/rdma-core version or firmware configuration");  
> #endif
> - {
> - char name[RTE_ETH_NAME_MAX_LEN];
> - struct ibv_port_attr port_attr;
> - struct ibv_pd *pd = NULL;
> - struct priv *priv = NULL;
> - struct ether_addr mac;
> - struct mlx5_dev_config config = {
> - .cqe_comp = cqe_comp,
> - .mps = mps,
> - .tunnel_en = tunnel_en,
> - .mpls_en = mpls_en,
> - .tx_vec_en = 1,
> - .rx_vec_en = 1,
> -

Re: [dpdk-dev] [RFC] ethdev: remove all offload API

[Ferruh Yigit]

On 6/11/2018 12:35 PM, Shahaf Shuler wrote:
> Monday, June 11, 2018 2:26 PM, Ananyev, Konstantin:
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] [RFC] ethdev: remove all offload API
>>> Subject: Re: [RFC] ethdev: remove all offload API
>>>
>>> On 6/11/2018 12:00 PM, Shahaf Shuler wrote:
 Hi Ferruh,

 Thanks for this patch.

 Monday, June 11, 2018 12:10 PM, Ferruh Yigit:
> Subject: Re: [RFC] ethdev: remove all offload API
>
> On 6/9/2018 9:04 AM, Andrew Rybchenko wrote:
>> On 06/09/2018 01:41 AM, Ferruh Yigit wrote:
>>> Cc: Shahaf Shuler 
>>>
>>> Signed-off-by: Ferruh Yigit 
>>> ---
>>
>> <...>
>>
>>> diff --git a/app/test-eventdev/test_perf_common.c
>>> b/app/test-eventdev/test_perf_common.c
>>> index d00f91802..9fe042ffe 100644
>>> --- a/app/test-eventdev/test_perf_common.c
>>> +++ b/app/test-eventdev/test_perf_common.c
>>> @@ -680,13 +680,7 @@ perf_ethdev_setup(struct evt_test *test,
>>> struct
> evt_options *opt)
>>> .mq_mode = ETH_MQ_RX_RSS,
>>> .max_rx_pkt_len = ETHER_MAX_LEN,
>>> .split_hdr_size = 0,
>>> -   .header_split   = 0,
>>> -   .hw_ip_checksum = 0,
>>> -   .hw_vlan_filter = 0,
>>> -   .hw_vlan_strip  = 0,
>>> -   .hw_vlan_extend = 0,
>>> .jumbo_frame= 0,
>>> -   .hw_strip_crc   = 1,
>>
>
> Hi Andrew,
>
>> I have 2 questions here:
>>  1. Why is jumbo_frame kept? There is
> DEV_RX_OFFLOAD_JUMBO_FRAME.
>
> Because there are still some usage of this flag in PMDs, they need
> to be clarified before removing the flag. I am for removing the
> flag in final version, but for this RFC I am not able to find enough time 
> to
>> work on PMDs for it.

 Can you elaborate?
 Is this something more than just a replace of the jumbo_frame bit with its
>> corresponding flag?
>>>
>>> That was my concern that copy paste won't be enough because some
>>> drivers not just use the jumbo_frame but set it based on
>>> max_rx_pkt_len etc.., that is why left out .jumbo_frame in the RFC.
> 
> I understand the max_rx_pkt_len consideration, but in the end there is some 
> logic which decide if to set/not the jumbo_frame bit. I would expect it just 
> to replace it with the JUMBO_FRAME flag w/o touching the rest of the logic.
> 
> Can you refer to some specific file which you encounter it? 

Hi Shahaf,

There is no specific usage, briefly while preparing RFC I concerned that the
jumbo_frame usage may not be straightforward and just left it in the RFC to not
mislead and postponed to consider later.
As mentioned before jumbo_frame should be replaced in final version of the 
patch.

Thanks,
ferruh


> 
>>
>> But max_rx_pkt_len need to be remained (and properly processed anyway)
>> no?
>> BTW, I always wonder is there any reason to have jumbo_frame flag at all (as
>> we do have max_rx_pkt_len anyway)?
> 
> I share the same thought, and it was expressed in multiple threads. There is 
> more - {MTU, SCATTER, JUMBO_FRAME}, all are connected and depended only on 
> max_rx_pkt_len and mbuf size. 
> However I think it is too much work to include into this RFC and completely 
> orthogonal. 
> 
>> Konstantin
>>
>>>

>
>>  2. Why is hw_strip_crc=1 discarded? Yes, I remember plans to make
>> it
>>      default behaviour and introduce flag to keep CRC, but right
>> now the
>>  patch looks like mixture of two changes which is not good.
>
> Yes it is wrong, app should replace "".hw_strip_crc=1 with KEEP_CRC
>> offload.
> Since both are RFC, kind of hard to maintain, but I think good to
> create a dependency from this patch to KEEP_CRC one.
>
>>
>> There are more cases in the patch where hw_strip_crc=1 is simply
> discarded.
>>
>> <...>
>>
>>> diff --git a/drivers/net/sfc/sfc_ethdev.c
>>> b/drivers/net/sfc/sfc_ethdev.c index 1b6499f85..ee8ae5b9f 100644
>>> --- a/drivers/net/sfc/sfc_ethdev.c
>>> +++ b/drivers/net/sfc/sfc_ethdev.c
>>> @@ -1089,7 +1089,6 @@ sfc_tx_queue_info_get(struct rte_eth_dev
> *dev,
>>> uint16_t tx_queue_id,
>>>
>>> memset(qinfo, 0, sizeof(*qinfo));
>>>
>>> -   qinfo->conf.txq_flags = txq_info->txq->flags;
>>> qinfo->conf.offloads = txq_info->txq->offloads;
>>> qinfo->conf.tx_free_thresh = txq_info->txq->free_thresh;
>>> qinfo->conf.tx_deferred_start = txq_info->deferred_start;
>> diff
>>> --git a/drivers/net/sfc/sfc_rx.c b/drivers/net/sfc/sfc_rx.c index
>>> cc76a5b15..58a0df583 100644
>>> --- a/drivers/net/sfc/sfc_rx.c
>>> +++ b/drivers/net/sfc/sfc_rx.c
>>> @@ -1446,7 +1446,6 @@ sfc_rx_check_mode(struct sfc_adapter *sa,
> str

Re: [dpdk-dev] [PATCH] eventdev: fix missing update to Rx adaper WRR position

[Jerin Jacob]

-Original Message-
> Date: Sun, 3 Jun 2018 17:11:08 +0530
> From: Nikhil Rao 
> To: jerin.ja...@caviumnetworks.com
> CC: dev@dpdk.org, Nikhil Rao , sta...@dpdk.org
> Subject: [PATCH] eventdev: fix missing update to Rx adaper WRR position
> X-Mailer: git-send-email 1.8.3.1
> 
> After dequeuing Rx packets and enqueueing them to the
> temporary buffer towards eventdev, the packet Rx loop exits
> if the temporary buffer is full but the current WRR position
> is not saved.
> 
> Save away the current value of the WRR position, so packets
> are dequeued from the correct Rx queue in the next invocation.
> 
> Fixes: 9c38b704d280 ("eventdev: add eth Rx adapter implementation")
> Suggested-by: Gage Eads 
> Signed-off-by: Nikhil Rao 
> Cc: sta...@dpdk.org


Applied to dpdk-next-eventdev/master. Thanks.


> ---
>  lib/librte_eventdev/rte_event_eth_rx_adapter.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c 
> b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> index 6f70509..53a3788 100644
> --- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> @@ -517,8 +517,10 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
>*/
>   if (buf->count >= BATCH_SIZE)
>   flush_event_buffer(rx_adapter);
> - if (BATCH_SIZE > (ETH_EVENT_BUFFER_SIZE - buf->count))
> + if (BATCH_SIZE > (ETH_EVENT_BUFFER_SIZE - buf->count)) {
> + rx_adapter->wrr_pos = wrr_pos;
>   break;
> + }
>  
>   stats->rx_poll_count++;
>   n = rte_eth_rx_burst(d, qid, mbufs, BATCH_SIZE);
> -- 
> 1.8.3.1
> 

Re: [dpdk-dev] [PATCH] eventdev: add event buffer flush in Rx adapter

[Jerin Jacob]

-Original Message-
> Date: Sun, 3 Jun 2018 18:12:25 +0530
> From: Nikhil Rao 
> To: jerin.ja...@caviumnetworks.com
> CC: dev@dpdk.org, Nikhil Rao , sta...@dpdk.org
> Subject: [PATCH] eventdev: add event buffer flush in Rx adapter
> X-Mailer: git-send-email 1.8.3.1
> 
> Add an event buffer flush when the current invocation
> of the Rx adapter is completed.
> 
> This patch provides lower latency in case there is a
> BATCH_SIZE of events in the event buffer.
> 
> Suggested-by: Narender Vangati 
> Signed-off-by: Nikhil Rao 
> Cc: sta...@dpdk.org

Acked-by: Jerin Jacob 

Applied to dpdk-next-eventdev/master. Thanks.


> ---
>  lib/librte_eventdev/rte_event_eth_rx_adapter.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c 
> b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> index 53a3788..3a70058 100644
> --- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> @@ -490,7 +490,7 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
>   * the hypervisor's switching layer where adjustments can be made to deal 
> with
>   * it.
>   */
> -static inline uint32_t
> +static inline void
>  eth_rx_poll(struct rte_event_eth_rx_adapter *rx_adapter)
>  {
>   uint32_t num_queue;
> @@ -519,7 +519,7 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
>   flush_event_buffer(rx_adapter);
>   if (BATCH_SIZE > (ETH_EVENT_BUFFER_SIZE - buf->count)) {
>   rx_adapter->wrr_pos = wrr_pos;
> - break;
> + return;
>   }
>  
>   stats->rx_poll_count++;
> @@ -535,7 +535,7 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
>   if (nb_rx > max_nb_rx) {
>   rx_adapter->wrr_pos =
>   (wrr_pos + 1) % rx_adapter->wrr_len;
> - return nb_rx;
> + break;
>   }
>   }
>  
> @@ -543,20 +543,18 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
>   wrr_pos = 0;
>   }
>  
> - return nb_rx;
> + if (buf->count >= BATCH_SIZE)
> + flush_event_buffer(rx_adapter);
>  }
>  
>  static int
>  event_eth_rx_adapter_service_func(void *args)
>  {
>   struct rte_event_eth_rx_adapter *rx_adapter = args;
> - struct rte_eth_event_enqueue_buffer *buf;
>  
> - buf = &rx_adapter->event_enqueue_buffer;
>   if (rte_spinlock_trylock(&rx_adapter->rx_lock) == 0)
>   return 0;
> - if (eth_rx_poll(rx_adapter) == 0 && buf->count)
> - flush_event_buffer(rx_adapter);
> + eth_rx_poll(rx_adapter);
>   rte_spinlock_unlock(&rx_adapter->rx_lock);
>   return 0;
>  }
> -- 
> 1.8.3.1
> 

Re: [dpdk-dev] [PATCH] eventdev: fix internal event port logic in Rx event adapter

[Jerin Jacob]

-Original Message-
> Date: Sun, 3 Jun 2018 19:40:46 +0530
> From: Nikhil Rao 
> To: jerin.ja...@caviumnetworks.com
> CC: dev@dpdk.org, Nikhil Rao , sta...@dpdk.org
> Subject: [PATCH] eventdev: fix internal event port logic in Rx event adapter
> X-Mailer: git-send-email 1.8.3.1
> 
> Set the internal_event_port flag when the ethdev-eventdev
> packet transfer is implemented in hardware and add a check
> for the flag to ignore the connection when setting up the
> WRR polling sequence.
> 
> Fixes: 9c38b704d280 ("eventdev: add eth Rx adapter implementation")
> Signed-off-by: Nikhil Rao 
> CC: sta...@dpdk.org

Acked-by: Jerin Jacob 

Applied to dpdk-next-eventdev/master. Thanks.


> ---
>  lib/librte_eventdev/rte_event_eth_rx_adapter.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c 
> b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> index 3a70058..d03f870 100644
> --- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> @@ -224,6 +224,8 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
>   nb_rx_queues = dev_info->dev->data->nb_rx_queues;
>   if (dev_info->rx_queue == NULL)
>   continue;
> + if (dev_info->internal_event_port)
> + continue;
>   for (q = 0; q < nb_rx_queues; q++) {
>   struct eth_rx_queue_info *queue_info =
>   &dev_info->rx_queue[q];
> @@ -1050,6 +1052,7 @@ static int add_rx_queue(struct rte_event_eth_rx_adapter 
> *rx_adapter,
>   &rte_eth_devices[eth_dev_id],
>   rx_queue_id, queue_conf);
>   if (ret == 0) {
> + dev_info->internal_event_port = 1;
>   update_queue_info(rx_adapter,
>   &rx_adapter->eth_devices[eth_dev_id],
>   rx_queue_id,
> @@ -1057,6 +1060,7 @@ static int add_rx_queue(struct rte_event_eth_rx_adapter 
> *rx_adapter,
>   }
>   } else {
>   rte_spinlock_lock(&rx_adapter->rx_lock);
> + dev_info->internal_event_port = 0;
>   ret = init_service(rx_adapter, id);
>   if (ret == 0)
>   ret = add_rx_queue(rx_adapter, eth_dev_id, rx_queue_id,
> -- 
> 1.8.3.1
> 

Re: [dpdk-dev] [PATCH] eventdev: fix Rx SW adapter stop

[Jerin Jacob]

-Original Message-
> Date: Mon, 4 Jun 2018 18:25:17 +0530
> From: Nikhil Rao 
> To: jerin.ja...@caviumnetworks.com
> CC: dev@dpdk.org, Nikhil Rao , sta...@dpdk.org
> Subject: [PATCH] eventdev: fix Rx SW adapter stop
> X-Mailer: git-send-email 1.8.3.1
> 
> The Rx adapter stop call does not guarantee that the
> SW service function will not execute after the
> rte_event_eth_rx_adapter_stop() call.
> 
> Add a "started" flag to prevent the adapter from executing
> if stop has been called.
> 
> Fixes: 9c38b704d280 ("eventdev: add eth Rx adapter implementation")
> Signed-off-by: Nikhil Rao 
> CC: sta...@dpdk.org

Applied to dpdk-next-eventdev/master. Thanks.

> ---
>  lib/librte_eventdev/rte_event_eth_rx_adapter.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c 
> b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> index d03f870..7b39e39 100644
> --- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> @@ -91,6 +91,8 @@ struct rte_event_eth_rx_adapter {
>   int socket_id;
>   /* Per adapter EAL service */
>   uint32_t service_id;
> + /* Adapter started flag */
> + uint8_t rxa_started;
>  } __rte_cache_aligned;
>  
>  /* Per eth device */
> @@ -556,6 +558,10 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
>  
>   if (rte_spinlock_trylock(&rx_adapter->rx_lock) == 0)
>   return 0;
> + if (!rx_adapter->rxa_started) {
> + return 0;
> + rte_spinlock_unlock(&rx_adapter->rx_lock);
> + }
>   eth_rx_poll(rx_adapter);
>   rte_spinlock_unlock(&rx_adapter->rx_lock);
>   return 0;
> @@ -847,8 +853,12 @@ static int add_rx_queue(struct rte_event_eth_rx_adapter 
> *rx_adapter,
>   &rte_eth_devices[i]);
>   }
>  
> - if (use_service)
> + if (use_service) {
> + rte_spinlock_lock(&rx_adapter->rx_lock);
> + rx_adapter->rxa_started = start;
>   rte_service_runstate_set(rx_adapter->service_id, start);
> + rte_spinlock_unlock(&rx_adapter->rx_lock);
> + }
>  
>   return 0;
>  }
> -- 
> 1.8.3.1
> 

Re: [dpdk-dev] 18.02.2 patches review and test

[Shreyansh Jain]

On 6/4/2018 2:28 PM, Luca Boccassi wrote:

Hi all,

Here is a list of patches targeted for stable release 18.02.2. Please
help review and test. The planned date for the final release is Thursday,
the 14th of June. Before that, please shout if anyone has objections with these
patches being applied.

Also for the companies committed to running regression tests,
please run the tests and report any issue before the release date.


I verified the above branch on NXP dpaa2 platform and have found no issues.


Thanks for working on this stable tree.



These patches are located at branch 18.02 of dpdk-stable repo:
 https://dpdk.org/browse/dpdk-stable/



[...]

Regards,
Shreyansh

Re: [dpdk-dev] [PATCH v3 01/27] net/ena: change version number to 1.1.0

[Ferruh Yigit]

On 6/7/2018 10:42 AM, Michal Krawczyk wrote:
> The upcoming patches for the ENA PMD are part of 1.1.0 update of the PMD
> and the version number is updated accordingly.
> 
> Signed-off-by: Michal Krawczyk 

Series applied to dpdk-next-net/master, thanks.

(02/27 replaced with https://dpdk.org/dev/patchwork/patch/40976/)
(will get release notes update later)

Re: [dpdk-dev] 18.02.2 patches review and test

[Luca Boccassi]

On Mon, 2018-06-11 at 17:58 +0530, Shreyansh Jain wrote:
> On 6/4/2018 2:28 PM, Luca Boccassi wrote:
> > Hi all,
> > 
> > Here is a list of patches targeted for stable release 18.02.2.
> > Please
> > help review and test. The planned date for the final release is
> > Thursday,
> > the 14th of June. Before that, please shout if anyone has
> > objections with these
> > patches being applied.
> > 
> > Also for the companies committed to running regression tests,
> > please run the tests and report any issue before the release date.
> 
> I verified the above branch on NXP dpaa2 platform and have found no
> issues.
> 
> 
> Thanks for working on this stable tree.

Great, thanks!

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [PATCH] net/thunderx: add support for hardware first skip feature

[Jerin Jacob]

-Original Message-
> Date: Mon, 28 May 2018 18:27:04 +0530
> From: rkudurumalla 
> To: dev@dpdk.org
> CC: Rakesh Kudurumalla 
> Subject: [dpdk-dev] [PATCH] net/thunderx: add support for hardware first
>  skip feature
> X-Mailer: git-send-email 2.7.4
> 
> This feature is used to create a hole between HEADROOM
> and actual data.Size of hole is specified in bytes as
> module param to pmd
> 
> Signed-off-by: Rakesh Kudurumalla 
> ---
>  doc/guides/nics/thunderx.rst | 26 
>  drivers/net/thunderx/base/nicvf_hw.c | 12 ++
>  drivers/net/thunderx/base/nicvf_hw.h |  1 +
>  drivers/net/thunderx/nicvf_ethdev.c  | 76 
> +++-
>  drivers/net/thunderx/nicvf_ethdev.h  |  1 +
>  drivers/net/thunderx/nicvf_struct.h  |  1 +
>  6 files changed, 116 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
> index 2642374..3d68c61 100644
> --- a/doc/guides/nics/thunderx.rst
> +++ b/doc/guides/nics/thunderx.rst
> @@ -30,6 +30,7 @@ Features of the ThunderX PMD are:
>  - SR-IOV VF
>  - NUMA support
>  - Multi queue set support (up to 96 queues (12 queue sets)) per port
> +- First skip support
>  
>  Supported ThunderX SoCs
>  ---
> @@ -312,6 +313,26 @@ We will choose four secondary queue sets from the ending 
> of the list (0002:01:01
>  
>  The nicvf thunderx driver will make use of attached secondary VFs 
> automatically during the interface configuration stage.
>  
> +
> +# Module params
> +
> +This feature is used to create a hole between HEADROOM and actual data.
> +Size of hole is specified in bytes as module param to pmd.
> +

This "Module params" comes under "32.6.3. Example device binding", Which
is not correct.

> +Configuration and Options
> +-

Change the "Configuration and Options" to "Module params" section.

Add sub section called "skip_data_bytes". The above sentence can be
copied here. i.e

---
This feature is used to create a hole between HEADROOM and actual
data.Size of hole is specified in bytes as module
param("skip_data_bytes") to pmd.
This scheme is useful when application would like to 
insert vlan header without disturbing HEADROOM



> +Use ``-w pci_id,skip_data_bytes="number of bytes to skip"`` in the EAL 
> options
> +Example:
> +
> +.. code-block:: console

This section is not rendering correctly.
Please use "make  doc-guides-html" to see the rendered output on the
local PC @ dpdk_dir/build/doc/...


> +
> +./your_application -w pci_id=skip_data_bytes=bytes_to_skip
> +
> +Ex: ./build/app/testpmd -w 0001:01:00.1,skip_data_bytes=8 -- --rxq=1 
> --txq=1 --nb-cores=1 --port-topology=chained -i -- -c 0x1
> +This will create a hole of 8 bytes between HEADROOM and actual data.
> +
> +Use case: The hole created with first_skip can be used to insert vlan 
> header without disturbing HEADROOM

Remove this as it mentioned above.

> +
>  Limitations
>  ---
>  
> @@ -335,3 +356,8 @@ Maximum packet segments
>  The ThunderX SoC family NICs support up to 12 segments per packet when 
> working
>  in scatter/gather mode. So, setting MTU will result with ``EINVAL`` when the
>  frame size does not fit in the maximum number of segments.
> +
> +First_skip
> +~~
> +
> +Maximum limit on first_skip is 128 bytes and number of bytes should be 
> multiple of 8

period(.) is missing at the end.

> diff --git a/drivers/net/thunderx/base/nicvf_hw.c 
> b/drivers/net/thunderx/base/nicvf_hw.c
> index ea8092c..b07a293 100644
> --- a/drivers/net/thunderx/base/nicvf_hw.c
> +++ b/drivers/net/thunderx/base/nicvf_hw.c
> @@ -703,6 +703,18 @@ nicvf_vlan_hw_strip(struct nicvf *nic, bool enable)
>  }
>  
>  void
> +nicvf_first_skip_config(struct nicvf *nic, uint8_t num_dwords)
> +{
> + uint64_t val;
> +
> + val = nicvf_reg_read(nic, NIC_VNIC_RQ_GEN_CFG);
> + val &= ~(0xfULL);
> + val |= (num_dwords & 0xf);
> +
> + nicvf_reg_write(nic, NIC_VNIC_RQ_GEN_CFG, val);
> +}
> +
> +void
>  nicvf_apad_config(struct nicvf *nic, bool enable)
>  {
>   uint64_t val;
> diff --git a/drivers/net/thunderx/base/nicvf_hw.h 
> b/drivers/net/thunderx/base/nicvf_hw.h
> index 284d0bd..fd13ea8 100644
> --- a/drivers/net/thunderx/base/nicvf_hw.h
> +++ b/drivers/net/thunderx/base/nicvf_hw.h
> @@ -193,6 +193,7 @@ uint32_t nicvf_qsize_sq_roundup(uint32_t val);
>  void nicvf_vlan_hw_strip(struct nicvf *nic, bool enable);
>  
>  void nicvf_apad_config(struct nicvf *nic, bool enable);
> +void nicvf_first_skip_config(struct nicvf *nic, uint8_t dwords);
>  
>  int nicvf_rss_config(struct nicvf *nic, uint32_t  qcnt, uint64_t cfg);
>  int nicvf_rss_term(struct nicvf *nic);
> diff --git a/drivers/net/thunderx/nicvf_ethdev.c 
> b/drivers/net/thunderx/nicvf_ethdev.c
> index 99fcd51..466cb86 100644
> --- a/drivers/net/thunderx/nicvf_ethdev.c
> +++ b/drivers/net/thunderx/nicvf_ethdev.c
> @@ -34,6 +34,8 @@
>  #include 
>  #include 
>  #include 
> +#include 

Re: [dpdk-dev] [dpdk-dev, 5/7] net/mlx5: add port representor awareness

[Xueming(Steven) Li]

Hi Adrien,

Couldn't find your original email from inbox anyway, have to start a new thread 
here.

> The current PCI probing method is not aware of Verbs port representors,
> which appear as standard Verbs devices bound to the same PCI address and
> cannot be distinguished.
> 
> Problem is that more often than not, the wrong Verbs device is used,
> resulting in unexpected traffic.
> 
> This patch adds necessary heuristics to bind affected driver instances to
> the intended (i.e. non-representor) device.
> 
> (Patch based on prior work from Yuanhan Liu)
> 
> Signed-off-by: Adrien Mazarguil 
> ---
>  drivers/net/mlx5/mlx5.c | 61 +---
>  1 file changed, 57 insertions(+), 4 deletions(-)
> Patch diffmbox
> 
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index d57e8118c..d3a298332 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -1155,6 +1155,32 @@  mlx5_dev_spawn(struct rte_device *dpdk_dev,
>  }
>  
>  /**
> + * Comparison callback to sort Verbs device names.
> + *
> + * This is meant to be used with qsort().
> + *
> + * @param a[in]
> + *   Pointer to pointer to first Verbs device.
> + * @param b[in]
> + *   Pointer to pointer to second Verbs device.
> + *
> + * @return
> + *   0 if both names are equal, less than 0 if the first argument is less
> + *   than the second, greater than 0 otherwise.
> + */
> +static int
> +mlx5_cmp_ibv_name(const void *a, const void *b)
> +{
> + const char *name_a = (*(const struct ibv_device *const *)a)->name;
> + const char *name_b = (*(const struct ibv_device *const *)b)->name;
> + size_t i = 0;
> +
> + while (name_a[i] && name_a[i] == name_b[i])
> + ++i;
> + return atoi(name_a + i) - atoi(name_b + i);

Comparing "1" and "10" here will return 0, does this matter?

> +}
> +
> +/**
>   * DPDK callback to register a PCI device.
>   *
>   * This function creates an Ethernet device for each port of a given
> @@ -1174,6 +1200,7 @@  mlx5_pci_probe(struct rte_pci_driver *pci_drv 
> __rte_unused,
>  {
>   struct ibv_device **ibv_list;
>   struct rte_eth_dev **eth_list = NULL;
> + int n = 0;
>   int vf;
>   int ret;
>  
> @@ -1195,6 +1222,9 @@  mlx5_pci_probe(struct rte_pci_driver *pci_drv 
> __rte_unused,
>   DRV_LOG(ERR, "cannot list devices, is ib_uverbs loaded?");
>   return -rte_errno;
>   }
> +
> + struct ibv_device *ibv_match[ret + 1];
> +
>   while (ret-- > 0) {
>   struct rte_pci_addr pci_addr;
>  
> @@ -1206,12 +1236,35 @@  mlx5_pci_probe(struct rte_pci_driver *pci_drv 
> __rte_unused,
>   pci_dev->addr.devid != pci_addr.devid ||
>   pci_dev->addr.function != pci_addr.function)
>   continue;
> - DRV_LOG(INFO, "PCI information matches, using device \"%s\"",
> + DRV_LOG(INFO, "PCI information matches for device \"%s\"",
>   ibv_list[ret]->name);
> - break;
> + ibv_match[n++] = ibv_list[ret];
> + }
> + ibv_match[n] = NULL;
> + if (n > 1) {
> + /*
> +  * The existence of several matching entries means port
> +  * representors have been instantiated. No existing Verbs
> +  * call nor /sys entries can tell them apart at this point.
> +  *
> +  * While definitely hackish, assume their names are numbered
> +  * based on order of creation with master device first,
> +  * followed by first port representor, followed by the
> +  * second one and so on.
> +  */
> + DRV_LOG(WARNING,
> + "probing device with port representors involves"
> + " heuristics with uncertain outcome");
> + qsort(ibv_match, n, sizeof(*ibv_match), mlx5_cmp_ibv_name);
> + DRV_LOG(WARNING, "assuming \"%s\" is the master device",
> + ibv_match[0]->name);
> + for (ret = 1; ret < n; ++ret)
> + DRV_LOG(WARNING,
> + "assuming \"%s\" is port representor #%d",
> + ibv_match[ret]->name, ret - 1);

Such dump will appear when attaching each rep port, how about just 
do it for PF in DEBUG level?

>   }
> - if (ret >= 0)
> - eth_list = mlx5_dev_spawn(&pci_dev->device, ibv_list[ret], vf);
> + if (n)
> + eth_list = mlx5_dev_spawn(&pci_dev->device, ibv_match[0], vf);
>   mlx5_glue->free_device_list(ibv_list);
>   if (!eth_list || !*eth_list) {
>   DRV_LOG(WARNING,
>

Re: [dpdk-dev] [PATCH] mbuf: remove experimental tag from pool ops functions

[Jerin Jacob]

-Original Message-
> Date: Tue,  5 Jun 2018 11:54:11 +0530
> From: Hemant Agrawal 
> To: dev@dpdk.org
> CC: olivier.m...@6wind.com, santosh.shu...@caviumnetworks.com, Hemant
>  Agrawal 
> Subject: [dpdk-dev] [PATCH] mbuf: remove experimental tag from pool ops
>  functions
> X-Mailer: git-send-email 2.7.4
> 
> Signed-off-by: Hemant Agrawal 

Acked-by: Jerin Jacob 

Re: [dpdk-dev] [PATCH] mbuf: remove experimental tag from pool ops functions

[santosh]

On Monday 11 June 2018 07:37 PM, Jerin Jacob wrote:
> -Original Message-
>> Date: Tue,  5 Jun 2018 11:54:11 +0530
>> From: Hemant Agrawal 
>> To: dev@dpdk.org
>> CC: olivier.m...@6wind.com, santosh.shu...@caviumnetworks.com, Hemant
>>  Agrawal 
>> Subject: [dpdk-dev] [PATCH] mbuf: remove experimental tag from pool ops
>>  functions
>> X-Mailer: git-send-email 2.7.4
>>
>> Signed-off-by: Hemant Agrawal 

Acked-by: Santosh Shukla 

Thanks.

Re: [dpdk-dev] [dpdk-stable] [PATCH v2] net/nfp: fix unused header reference

[Ferruh Yigit]

On 6/11/2018 12:20 PM, Alejandro Lucero wrote:
> Apart from not being used, this is causing problem when compiling
> DPDK with the musl library as reported by bugzilla.
> 
> Bugzilla ID: 40
> Fixes: c7e9729da6b5 ("net/nfp: support CPP")

Cc: sta...@dpdk.org

> Signed-off-by: Alejandro Lucero 

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

Re: [dpdk-dev] [RFC] ethdev: add new offload flag to keep CRC

[Stephen Hemminger]

On Fri,  8 Jun 2018 23:57:09 +0100
Ferruh Yigit  wrote:

> DEV_RX_OFFLOAD_KEEP_CRC offload flag added.
> 
> DEV_RX_OFFLOAD_CRC_STRIP flag will remain one more release
> default behavior in PMDs is to keep the CRC until this flag removed

This won't work for virtual devices that never keep CRC.
Maybe wording should be changed.

[dpdk-dev] 18.08 integration window

[Thomas Monjalon]

Hi all,

The proposal deadline (June 8) is over.
All the features must be reviewed and integrated during June.
It will be a short release cycle.
The release 18.08.0 is expected to happen at the very beginning of August.
The deadlines will be more strictly respected than for 18.05.

Please let's focus on reasonnable expectations to make
this release on time with good quality: be 18.08 a success!

[dpdk-dev] [PATCH v1] net/tap: explain how to compile eBPF C file

[Ophir Munk]

This commit explains how to manually compile the C source file
tap_bpf_program.c into an ELF file using the clang compiler.
The code in tap_bpf_program.c requires definitions found in iproute2
source code. This commit suggests cloning the iproute2 git tree and
include its path in the clang command. It also adds inclusion of file
bpf_api.h (required for eBPF definitions) which is located in iproute2
source tree. For more details refer to TAP documentation.
This commit is related to commits [1] and [2].

[1] commit cdc07e83bb24 ("net/tap: add eBPF program file")
[2] commit aabe70df73a3 ("net/tap: add eBPF bytes code")

Signed-off-by: Ophir Munk 
---
 doc/guides/nics/tap.rst   | 21 +
 drivers/net/tap/tap_bpf_program.c |  5 +
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 2714868..af6c534 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -234,13 +234,26 @@ C functions under different ELF sections.
 
 2. Install ``LLVM`` library and ``clang`` compiler versions 3.7 and above
 
-3. Compile ``tap_bpf_program.c`` via ``LLVM`` into an object file::
+3. The code in ``tap_bpf_program.c`` requires definitions found in iproute2
+source code.
 
-clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf \
--filetype=obj -o 
+Clone the iproute2 git tree and make it accessible to the build environment, 
say
+under directory  ::
+
+git clone https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/ \
+
+
+The code in ``tap_bpf_program.c`` must include file ``bpf_api.h`` which is
+located under  directory. This file contains eBPF
+related definitions.
 
+4. Compile ``tap_bpf_program.c`` via ``LLVM`` into an object file::
+
+clang -I /iproute2/include \
+-O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf \
+-filetype=obj -o 
 
-4. Use a tool that receives two parameters: an eBPF object file and a section
+5. Use a tool that receives two parameters: an eBPF object file and a section
 name, and prints out the section as a C array of eBPF instructions.
 Embed the C array in your TAP PMD tree.
 
diff --git a/drivers/net/tap/tap_bpf_program.c 
b/drivers/net/tap/tap_bpf_program.c
index 1cb7382..60b069b 100644
--- a/drivers/net/tap/tap_bpf_program.c
+++ b/drivers/net/tap/tap_bpf_program.c
@@ -17,6 +17,11 @@
 #include 
 
 #include "tap_rss.h"
+/*
+ * bpf_api.h file is located under iproute2
+ * tree, see TAP documentation.
+ */
+#include "bpf_api.h"
 
 /** Create IPv4 address */
 #define IPv4(a, b, c, d) ((__u32)(((a) & 0xff) << 24) | \
-- 
1.8.3.1

[dpdk-dev] [PATCH 3/3] eal: make memory segment preallocation OS-specific

[Anatoly Burakov]

In the perfect world, it wouldn't matter how much memory was
preallocated because most of it was always going to be private
anonymous zero-page mappings for the duration of the program.
However, in practice, due to peculiarities of FreeBSD, we need
to additionally limit memory allocation there. This patch moves
the segment preallocation to EAL private functions that will be
implemented by an OS-specific EAL rather than being in the common
memory-related code.

Since there is no support for growing/shrinking memory use at
runtime on FreeBSD anyway, this does not inhibit any functionality
but makes core dumps faster even on default settings.

Signed-off-by: Anatoly Burakov 
---

Notes:
For Linuxapp, this is 99% code move (aside from slight changes due to
code deduplication between Linuxapp EAL and old common memory code),
while for FreeBSD it's mostly code move but with changes due to
dropping 32-bit code and implementing FreeBSD-specific limits on
memory preallocation outlined in the commit.

 lib/librte_eal/bsdapp/eal/eal_memory.c| 215 
 lib/librte_eal/common/eal_common_memory.c | 386 +-
 lib/librte_eal/common/eal_private.h   |  12 +
 lib/librte_eal/linuxapp/eal/eal_memory.c  | 341 +++
 4 files changed, 569 insertions(+), 385 deletions(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal_memory.c 
b/lib/librte_eal/bsdapp/eal/eal_memory.c
index 21a390fac..3dc427bd8 100644
--- a/lib/librte_eal/bsdapp/eal/eal_memory.c
+++ b/lib/librte_eal/bsdapp/eal/eal_memory.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "eal_private.h"
@@ -300,3 +301,217 @@ rte_eal_using_phys_addrs(void)
 {
return 0;
 }
+
+static uint64_t
+get_mem_amount(uint64_t page_sz, uint64_t max_mem)
+{
+   uint64_t area_sz, max_pages;
+
+   /* limit to RTE_MAX_MEMSEG_PER_LIST pages or RTE_MAX_MEM_MB_PER_LIST */
+   max_pages = RTE_MAX_MEMSEG_PER_LIST;
+   max_mem = RTE_MIN((uint64_t)RTE_MAX_MEM_MB_PER_LIST << 20, max_mem);
+
+   area_sz = RTE_MIN(page_sz * max_pages, max_mem);
+
+   /* make sure the list isn't smaller than the page size */
+   area_sz = RTE_MAX(area_sz, page_sz);
+
+   return RTE_ALIGN(area_sz, page_sz);
+}
+
+#define MEMSEG_LIST_FMT "memseg-%" PRIu64 "k-%i-%i"
+static int
+alloc_memseg_list(struct rte_memseg_list *msl, uint64_t page_sz,
+   int n_segs, int socket_id, int type_msl_idx)
+{
+   char name[RTE_FBARRAY_NAME_LEN];
+
+   snprintf(name, sizeof(name), MEMSEG_LIST_FMT, page_sz >> 10, socket_id,
+type_msl_idx);
+   if (rte_fbarray_init(&msl->memseg_arr, name, n_segs,
+   sizeof(struct rte_memseg))) {
+   RTE_LOG(ERR, EAL, "Cannot allocate memseg list: %s\n",
+   rte_strerror(rte_errno));
+   return -1;
+   }
+
+   msl->page_sz = page_sz;
+   msl->socket_id = socket_id;
+   msl->base_va = NULL;
+
+   RTE_LOG(DEBUG, EAL, "Memseg list allocated: 0x%zxkB at socket %i\n",
+   (size_t)page_sz >> 10, socket_id);
+
+   return 0;
+}
+
+static int
+alloc_va_space(struct rte_memseg_list *msl)
+{
+   uint64_t page_sz;
+   size_t mem_sz;
+   void *addr;
+   int flags = 0;
+
+#ifdef RTE_ARCH_PPC_64
+   flags |= MAP_HUGETLB;
+#endif
+
+   page_sz = msl->page_sz;
+   mem_sz = page_sz * msl->memseg_arr.len;
+
+   addr = eal_get_virtual_area(msl->base_va, &mem_sz, page_sz, 0, flags);
+   if (addr == NULL) {
+   if (rte_errno == EADDRNOTAVAIL)
+   RTE_LOG(ERR, EAL, "Could not mmap %llu bytes at [%p] - 
please use '--base-virtaddr' option\n",
+   (unsigned long long)mem_sz, msl->base_va);
+   else
+   RTE_LOG(ERR, EAL, "Cannot reserve memory\n");
+   return -1;
+   }
+   msl->base_va = addr;
+
+   return 0;
+}
+
+
+static int
+memseg_primary_init(void)
+{
+   struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
+   int hpi_idx, msl_idx = 0;
+   struct rte_memseg_list *msl;
+   uint64_t max_mem, total_mem;
+
+   /* no-huge does not need this at all */
+   if (internal_config.no_hugetlbfs)
+   return 0;
+
+   /* FreeBSD has an issue where core dump will dump the entire memory
+* contents, including anonymous zero-page memory. Therefore, while we
+* will be limiting total amount of memory to RTE_MAX_MEM_MB, we will
+* also be further limiting total memory amount to whatever memory is
+* available to us through contigmem driver (plus spacing blocks).
+*
+* so, at each stage, we will be checking how much memory we are
+* preallocating, and adjust all the values accordingly.
+*/
+
+   max_mem = (uint64_t)RTE_MAX_MEM_MB << 20;
+   total_mem = 0;
+
+   /* create memseg lists */
+  

[dpdk-dev] [PATCH 2/3] eal/bsdapp: concatenate adjacent segments

[Anatoly Burakov]

Previously, memory allocator always left holes between mapped
contigmem segments, even if they were IOVA-contiguous. Fix this
by remembering last IOVA address and memseg index, and checking
against those when mapping new contigmem segments.

Signed-off-by: Anatoly Burakov 
---
 lib/librte_eal/bsdapp/eal/eal_memory.c | 48 --
 1 file changed, 30 insertions(+), 18 deletions(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal_memory.c 
b/lib/librte_eal/bsdapp/eal/eal_memory.c
index ca06de2f8..21a390fac 100644
--- a/lib/librte_eal/bsdapp/eal/eal_memory.c
+++ b/lib/librte_eal/bsdapp/eal/eal_memory.c
@@ -104,6 +104,8 @@ rte_eal_hugepage_init(void)
/* map all hugepages and sort them */
for (i = 0; i < internal_config.num_hugepage_sizes; i ++){
struct hugepage_info *hpi;
+   rte_iova_t prev_end = 0;
+   int prev_ms_idx = -1;
uint64_t page_sz, mem_needed;
unsigned int n_pages, max_pages;
 
@@ -124,10 +126,27 @@ rte_eal_hugepage_init(void)
int error;
size_t sysctl_size = sizeof(physaddr);
char physaddr_str[64];
+   bool is_adjacent;
+
+   /* first, check if this segment is IOVA-adjacent to
+* the previous one.
+*/
+   snprintf(physaddr_str, sizeof(physaddr_str),
+   "hw.contigmem.physaddr.%d", j);
+   error = sysctlbyname(physaddr_str, &physaddr,
+   &sysctl_size, NULL, 0);
+   if (error < 0) {
+   RTE_LOG(ERR, EAL, "Failed to get physical addr 
for buffer %u "
+   "from %s\n", j, hpi->hugedir);
+   return -1;
+   }
+
+   is_adjacent = prev_end != 0 && physaddr == prev_end;
+   prev_end = physaddr + hpi->hugepage_sz;
 
for (msl_idx = 0; msl_idx < RTE_MAX_MEMSEG_LISTS;
msl_idx++) {
-   bool empty;
+   bool empty, need_hole;
msl = &mcfg->memsegs[msl_idx];
arr = &msl->memseg_arr;
 
@@ -136,20 +155,23 @@ rte_eal_hugepage_init(void)
 
empty = arr->count == 0;
 
-   /* we need 1, plus hole if not empty */
+   /* we need a hole if this isn't an empty memseg
+* list, and if previous segment was not
+* adjacent to current one.
+*/
+   need_hole = !empty && !is_adjacent;
+
+   /* we need 1, plus hole if not adjacent */
ms_idx = rte_fbarray_find_next_n_free(arr,
-   0, 1 + (empty ? 1 : 0));
+   0, 1 + (need_hole ? 1 : 0));
 
/* memseg list is full? */
if (ms_idx < 0)
continue;
 
-   /* leave some space between memsegs, they are
-* not IOVA contiguous, so they shouldn't be VA
-* contiguous either.
-*/
-   if (!empty)
+   if (need_hole && prev_ms_idx != ms_idx - 1)
ms_idx++;
+   prev_ms_idx = ms_idx;
 
break;
}
@@ -178,16 +200,6 @@ rte_eal_hugepage_init(void)
return -1;
}
 
-   snprintf(physaddr_str, sizeof(physaddr_str), 
"hw.contigmem"
-   ".physaddr.%d", j);
-   error = sysctlbyname(physaddr_str, &physaddr, 
&sysctl_size,
-   NULL, 0);
-   if (error < 0) {
-   RTE_LOG(ERR, EAL, "Failed to get physical addr 
for buffer %u "
-   "from %s\n", j, hpi->hugedir);
-   return -1;
-   }
-
seg->addr = addr;
seg->iova = physaddr;
seg->hugepage_sz = page_sz;
-- 
2.17.1

[dpdk-dev] [PATCH 1/3] eal/bsdapp: fix segment index display

[Anatoly Burakov]

Segment index was set to 0 at start but was never incremented.
This has no consequences other than displayed number of segments
allocated at initialization. Fix this by incrementing it after
displaying.

Fixes: 66cc45e293ed ("mem: replace memseg with memseg lists")
Cc: sta...@dpdk.org

Signed-off-by: Anatoly Burakov 
---
 lib/librte_eal/bsdapp/eal/eal_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_eal/bsdapp/eal/eal_memory.c 
b/lib/librte_eal/bsdapp/eal/eal_memory.c
index a5e034789..ca06de2f8 100644
--- a/lib/librte_eal/bsdapp/eal/eal_memory.c
+++ b/lib/librte_eal/bsdapp/eal/eal_memory.c
@@ -200,7 +200,7 @@ rte_eal_hugepage_init(void)
 
RTE_LOG(INFO, EAL, "Mapped memory segment %u @ %p: 
physaddr:0x%"
PRIx64", len %zu\n",
-   seg_idx, addr, physaddr, page_sz);
+   seg_idx++, addr, physaddr, page_sz);
 
total_mem += seg->len;
}
-- 
2.17.1

Re: [dpdk-dev] [PATCH v3 27/27] net/ena: set link speed as none

[Chas Williams]

On Mon, Jun 11, 2018 at 4:01 AM Michał Krawczyk  wrote:

> 2018-06-10 3:35 GMT+02:00 Chas Williams <3ch...@gmail.com>:
> >
> >
> > On Fri, Jun 8, 2018 at 3:37 PM Ferruh Yigit 
> wrote:
> >>
> >> On 6/7/2018 10:43 AM, Michal Krawczyk wrote:
> >> > From: Rafal Kozik 
> >> >
> >> > Link speed should is not limited to 10Gb/s and it shouldn't be
> >> > hardcoded.
> >> >
> >> > They link speed is set to none instead and the applications shouldn't
> >> > rely on this value when using ENA PMD.
> >>
> >> Why not able to set link speed?
> >>
> >> And what is the link_autoneg, ETH_LINK_FIXED? What is the point of
> setting
> >> link
> >> speed FIXED and later speed value NONE?
> >
> >
> > The link speed is part of the spanning tree path computation.  I don't
> think
> > picking 0 (or undefined)
> > is the appropriate choice.  For virtual interfaces link speed is a
> > troublesome quantity but advertising
> > undefined seems worse then just use some constant value.
> >
>
> Setting constant value is not making much sense in the virtualized
> environment (ENA can be only used in the cloud). Link speed can be
> very flexible in that case and that's why ENA isn't providing it. If
> we will use constant value, what it should be? It may lead to
> confusion or can result in the performance issues because some
> applications are relying on this number to send max traffic.
>

What applications are using this value to determine the transmit speed?


> Applications should not make assumption that the link speed is always
> giving valid value and if it is not, they should try to configure rate
> dynamically, instead of statically.


So advertising a fixed speed of 10G should be perfectly fine.  The
application should not assume 10G is a valid value and will attempt
to dynamically configure the rate.

The link speed should never be used to determine a transmit rate
for an application because you don't know the speeds in the middle
of the network.


>
> >>
> >>
> >> >
> >> > Fixes: 1173fca ("ena: add polling-mode driver")
> >>
> >> For next time can you please use git alias to have consistent Fixes
> format
> >>
> >> >
> >> > Signed-off-by: Rafal Kozik 
> >> > Acked-by: Michal Krawczyk 
> >> > ---
> >> >  drivers/net/ena/ena_ethdev.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/net/ena/ena_ethdev.c
> b/drivers/net/ena/ena_ethdev.c
> >> > index 5c3b6494f..9ae73e331 100644
> >> > --- a/drivers/net/ena/ena_ethdev.c
> >> > +++ b/drivers/net/ena/ena_ethdev.c
> >> > @@ -848,7 +848,7 @@ static int ena_link_update(struct rte_eth_dev
> *dev,
> >> >   adapter = (struct ena_adapter *)(dev->data->dev_private);
> >> >
> >> >   link->link_status = adapter->link_status ? ETH_LINK_UP :
> >> > ETH_LINK_DOWN;
> >> > - link->link_speed = ETH_SPEED_NUM_10G;
> >> > + link->link_speed = ETH_SPEED_NUM_NONE;
> >> >   link->link_duplex = ETH_LINK_FULL_DUPLEX;
> >> >
> >> >   return 0;
> >> >
> >>
> >
>

Re: [dpdk-dev] I40evf VLAN stripping disable

[Dey, Souvik]

Hi Xing,
Do we need to do i40evf_add_vlan() to get the vlan packets up 
to the VM like we had in ixgbe_vf?  I see that if I have the vlan added through 
i40evf_add_vlan(), then the packet is received with the vlan stripped even if 
the vlan_strip is disabled in the PF. If I just do vlan_strip disabled and then 
send vlan packets it is all coming up to the VM. But is that not security issue 
as all VLANs even if not configured will be coming up to the VM, which never 
happened in the ixgbe case. I only have rte_eth_allmulticast_enable in my app , 
so expect that unicast/broadcast promisc mode is disabled by default.

--
Regard,
Souvik

From: Xing, Beilei [mailto:beilei.x...@intel.com]
Sent: Monday, June 11, 2018 3:58 AM
To: Dey, Souvik ; Wu, Jingjing ; 
dev@dpdk.org
Cc: us...@dpdk.org
Subject: RE: I40evf VLAN stripping disable


NOTICE: This email was received from an EXTERNAL sender


Hi Souvik,

Could you try with kernel driver (version 2.4.3) first? In my environment, 
disable vlan strip in DPDK works with kernel driver version 2.4.3.

My test steps with testpmd:
>set fwd rxonly
>set verbose 1
>set promisc 0 off
>vlan set strip off 0
Then send a vlan packet with VF mac address.

Best Regards,
Beilei Xing

From: Dey, Souvik [mailto:so...@rbbn.com]
Sent: Friday, June 8, 2018 11:22 PM
To: Xing, Beilei mailto:beilei.x...@intel.com>>; Wu, 
Jingjing mailto:jingjing...@intel.com>>; 
dev@dpdk.org
Cc: us...@dpdk.org
Subject: I40evf VLAN stripping disable

Hi i40e/i40evf maintainers,

I was testing VLANs with i40evf pmd and is hitting the below issue.

I have the following configuration:
- host runs with Linux pf i40e driver(version 2.4.6)
- guest runs with DPDK 17.11.2 vf i40e driver

When I am sending a vlan packet from the outside to the guest, on the guest, I 
receive the packet which has the PKT_RX_VLAN_STRIPPED flag set although I'm not 
asking for it.
Even though my DPDK app has the rte_eth_conf.rxmode.hw_vlan_strip set to 0 and 
also verified that the 
i40evf_disable_vlan_strip(VIRTCHNL_OP_DISABLE_VLAN_STRIPPING) function is 
getting called and not returning any error from the linux pf driver.
Is this the default behavior that the VLAN will be always stripped by the PF 
irrespective of the setting ? Should the DPDK version take care of the 
re-adding the tag back to the packet in case hw_vlan_strip is disabled ? What 
should be best way of handling it ? Is it a bug in DPDK or I am missing 
something here.

I do see in the linux i40evf driver we are insert vlan header in the received 
packets in some cases.

--
Regards,
Souvik

Re: [dpdk-dev] [PATCH v1] net/tap: explain how to compile eBPF C file

[Wiles, Keith]

> On Jun 11, 2018, at 11:06 AM, Ophir Munk  wrote:
> 
> This commit explains how to manually compile the C source file
> tap_bpf_program.c into an ELF file using the clang compiler.
> The code in tap_bpf_program.c requires definitions found in iproute2
> source code. This commit suggests cloning the iproute2 git tree and
> include its path in the clang command. It also adds inclusion of file
> bpf_api.h (required for eBPF definitions) which is located in iproute2
> source tree. For more details refer to TAP documentation.
> This commit is related to commits [1] and [2].

Normally I would have suggested that eBPF be disable in the TAP driver as it 
requires external code and programs, but that ship has sailed.

I would like to see building the tap_bpf_program.o as a target in the Makefile, 
this way the developer can just run the ‘make bpf_program’ target and it would 
be simpler and less error prone.
> 
> [1] commit cdc07e83bb24 ("net/tap: add eBPF program file")
> [2] commit aabe70df73a3 ("net/tap: add eBPF bytes code")
> 
> Signed-off-by: Ophir Munk 
> ---
> doc/guides/nics/tap.rst   | 21 +
> drivers/net/tap/tap_bpf_program.c |  5 +
> 2 files changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
> index 2714868..af6c534 100644
> --- a/doc/guides/nics/tap.rst
> +++ b/doc/guides/nics/tap.rst
> @@ -234,13 +234,26 @@ C functions under different ELF sections.
> 
> 2. Install ``LLVM`` library and ``clang`` compiler versions 3.7 and above
> 
> -3. Compile ``tap_bpf_program.c`` via ``LLVM`` into an object file::
> +3. The code in ``tap_bpf_program.c`` requires definitions found in iproute2
> +source code.
> 
> -clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf \
> --filetype=obj -o 
> +Clone the iproute2 git tree and make it accessible to the build environment, 
> say
> +under directory  ::
> +
> +git clone https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/ \
> +
> +
> +The code in ``tap_bpf_program.c`` must include file ``bpf_api.h`` which is
> +located under  directory. This file contains eBPF
> +related definitions.
> 
> +4. Compile ``tap_bpf_program.c`` via ``LLVM`` into an object file::
> +
> +clang -I /iproute2/include \
> +-O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf \
> +-filetype=obj -o 
> 
> -4. Use a tool that receives two parameters: an eBPF object file and a section
> +5. Use a tool that receives two parameters: an eBPF object file and a section

What ‘tool’ should be used here? objdump?

> name, and prints out the section as a C array of eBPF instructions.
> Embed the C array in your TAP PMD tree.
> 
> diff --git a/drivers/net/tap/tap_bpf_program.c 
> b/drivers/net/tap/tap_bpf_program.c
> index 1cb7382..60b069b 100644
> --- a/drivers/net/tap/tap_bpf_program.c
> +++ b/drivers/net/tap/tap_bpf_program.c
> @@ -17,6 +17,11 @@
> #include 
> 
> #include "tap_rss.h"
> +/*
> + * bpf_api.h file is located under iproute2
> + * tree, see TAP documentation.
> + */
> +#include "bpf_api.h"
> 
> /** Create IPv4 address */
> #define IPv4(a, b, c, d) ((__u32)(((a) & 0xff) << 24) | \
> -- 
> 1.8.3.1
> 

Regards,
Keith

Re: [dpdk-dev] [PATCH v10 1/5] eal: add rte_uuid support

[Stephen Hemminger]

On Sun, 10 Jun 2018 16:46:42 +0530
Jerin Jacob  wrote:

> -Original Message-
> > Date: Fri, 8 Jun 2018 11:11:54 -0700
> > From: Stephen Hemminger 
> > To: "Wiles, Keith" 
> > Cc: "dev@dpdk.org" , Stephen Hemminger
> >  
> > Subject: Re: [dpdk-dev] [PATCH v10 1/5] eal: add rte_uuid support
> > 
> > On Fri, 8 Jun 2018 17:15:04 +
> > "Wiles, Keith"  wrote:
> >   
> > > > On Jun 8, 2018, at 9:59 AM, Stephen Hemminger 
> > > >  wrote:
> > > > 
> > > > Since uuid functions may not be available everywhere, implement
> > > > uuid functions in DPDK. These are based off the BSD licensed
> > > > libuuid in util-link.
> > > > 
> > > > Signed-off-by: Stephen Hemminger 
> > > > ---
> > > > lib/librte_eal/bsdapp/eal/Makefile   |   1 +
> > > > lib/librte_eal/common/Makefile   |   2 +-
> > > > lib/librte_eal/common/eal_common_uuid.c  | 193 +++
> > > > lib/librte_eal/common/include/rte_uuid.h | 129 +++
> > > > lib/librte_eal/common/meson.build|   2 +
> > > > lib/librte_eal/linuxapp/eal/Makefile |   1 +
> > > > lib/librte_eal/rte_eal_version.map   |   9 ++
> > > > 7 files changed, 336 insertions(+), 1 deletion(-)
> > > > create mode 100644 lib/librte_eal/common/eal_common_uuid.c
> > > > create mode 100644 lib/librte_eal/common/include/rte_uuid.h
> > > > 
> > > 
> > > Hi Stephen, Why does this need to be in EAl/Common would this be better 
> > > in the lib directory for utils or string routines? Does the EAl use the 
> > > feature for something?
> > > 
> > > Regards,
> > > Keith
> > >   
> > 
> > It could be anywhere. Not tied to being in EAL common but that is where the 
> > PCI parsing code is.
> > Still not 100% sure we need our own version of this simple code. It is more 
> > about BSD and eventually Windows support.  
> 
> 
> IMO, It is useful to add it in common EAL as some drivers can also use it.
> But, I think, we must add unit test case for this new API.
> 

I don't see much point in going through the effort of writing unit test since 
it is just a straight
copy of Ted's uuid code which has been around for a long time.

[dpdk-dev] [PATCH v2 0/2] testpmd: allow configure of Tx IP parameters

[Stephen Hemminger]

The testpmd application had hardcoded 192.168.0.1 port 1024
which is a problem when used in environments where IP address of
network is different. For example, running testpmd on Azure
where virtual networks are assigned by host infrastructure.

Stephen Hemminger (2):
  testpmd: use RFC values for Tx address and port
  testpmd: add ability to set tx IP and UDP parameters

 app/test-pmd/parameters.c | 49 +++
 app/test-pmd/testpmd.h|  6 
 app/test-pmd/txonly.c | 18 +-
 doc/guides/testpmd_app_ug/run_app.rst |  9 +
 4 files changed, 74 insertions(+), 8 deletions(-)

-- 
2.17.1

[dpdk-dev] [PATCH v2 1/2] testpmd: use RFC values for Tx address and port

[Stephen Hemminger]

Change the IP address and UDP port used for testpmd Tx only
test. The old values overlap common NAT local networks; instead
use reserved addresses in IETF RFC 2544.

Signed-off-by: Stephen Hemminger 
---
 app/test-pmd/txonly.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c
index 1f08b6ed37a2..a24000e3af44 100644
--- a/app/test-pmd/txonly.c
+++ b/app/test-pmd/txonly.c
@@ -40,11 +40,13 @@
 
 #include "testpmd.h"
 
-#define UDP_SRC_PORT 1024
-#define UDP_DST_PORT 1024
+/* RFC863 discard port */
+#define UDP_SRC_PORT 9
+#define UDP_DST_PORT 9
 
-#define IP_SRC_ADDR ((192U << 24) | (168 << 16) | (0 << 8) | 1)
-#define IP_DST_ADDR ((192U << 24) | (168 << 16) | (0 << 8) | 2)
+/* RFC2544 reserved test subnet 192.18.0.0 */
+#define IP_SRC_ADDR ((192U << 24) | (18 << 16) | (0 << 8) | 1)
+#define IP_DST_ADDR ((192U << 24) | (18 << 16) | (0 << 8) | 2)
 
 #define IP_DEFTTL  64   /* from RFC 1340. */
 #define IP_VERSION 0x40
-- 
2.17.1

[dpdk-dev] [PATCH v2 2/2] testpmd: add ability to set tx IP and UDP parameters

[Stephen Hemminger]

Allow user to override the hard coded IP address and UDP
port values in Tx only test.

Signed-off-by: Stephen Hemminger 
---
 app/test-pmd/parameters.c | 49 +++
 app/test-pmd/testpmd.h|  6 
 app/test-pmd/txonly.c | 16 -
 doc/guides/testpmd_app_ug/run_app.rst |  9 +
 4 files changed, 72 insertions(+), 8 deletions(-)

diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 75807623c719..6d666e088fd9 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -65,6 +66,7 @@ usage(char* progname)
 #ifdef RTE_LIBRTE_CMDLINE
   "--eth-peers-configfile= | "
   "--eth-peer=X,M:M:M:M:M:M | "
+  "--tx-ip=SRC,DST | --tx-udp=PORT | "
 #endif
   "--pkt-filter-mode= |"
   "--rss-ip | --rss-udp | "
@@ -625,6 +627,8 @@ launch_args_parse(int argc, char** argv)
{ "vxlan-gpe-port", 1, 0, 0 },
{ "mlockall",   0, 0, 0 },
{ "no-mlockall",0, 0, 0 },
+   { "tx-ip",  1, 0, 0 },
+   { "tx-udp", 1, 0, 0 },
{ 0, 0, 0, 0 },
};
 
@@ -717,6 +721,51 @@ launch_args_parse(int argc, char** argv)
nb_peer_eth_addrs++;
}
 #endif
+   if (!strcmp(lgopts[opt_idx].name, "tx-ip")) {
+   struct in_addr in;
+   char *end;
+
+   end = strchr(optarg, ',');
+   if (end == optarg || !end)
+   rte_exit(EXIT_FAILURE,
+"Invalid tx-ip: %s", optarg);
+
+   *end++ = 0;
+   if (inet_aton(optarg, &in) == 0)
+   rte_exit(EXIT_FAILURE,
+"Invalid source IP address: 
%s\n", optarg);
+   tx_ip_src_addr = rte_be_to_cpu_32(in.s_addr);
+
+   if (inet_aton(end, &in) == 0)
+   rte_exit(EXIT_FAILURE,
+"Invalid destination IP 
address: %s\n", optarg);
+   tx_ip_dst_addr = rte_be_to_cpu_32(in.s_addr);
+   }
+   if (!strcmp(lgopts[opt_idx].name, "tx-udp")) {
+   char *end = NULL;
+
+   errno = 0;
+   n = strtoul(optarg, &end, 10);
+   if (errno != 0 || end == optarg || n > 
UINT16_MAX ||
+   !(*end == '\0' || *end == ','))
+   rte_exit(EXIT_FAILURE,
+"Invalid UDP port: %s\n", 
optarg);
+   tx_udp_src_port = n;
+   if (*end == ',') {
+   char *dst = end + 1;
+
+   n = strtoul(dst, &end, 10);
+   if (errno != 0 || end == dst ||
+   n > UINT16_MAX || *end)
+   rte_exit(EXIT_FAILURE,
+"Invalid destination 
UDP port: %s\n",
+dst);
+   tx_udp_dst_port = n;
+   } else {
+   tx_udp_dst_port = n;
+   }
+
+   }
if (!strcmp(lgopts[opt_idx].name, "nb-ports")) {
n = atoi(optarg);
if (n > 0 && n <= nb_ports)
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index f51cd9dd9bbd..48f7b364e9b3 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -444,6 +444,12 @@ extern int8_t tx_pthresh;
 extern int8_t tx_hthresh;
 extern int8_t tx_wthresh;
 
+extern uint16_t tx_udp_src_port;
+extern uint16_t tx_udp_dst_port;
+
+extern uint32_t tx_ip_src_addr;
+extern uint32_t tx_ip_dst_addr;
+
 extern struct fwd_config cur_fwd_config;
 extern struct fwd_engine *cur_fwd_eng;
 extern uint32_t retry_enabled;
diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c
index a24000e3af44..6d7ddf99d639 100644
--- a/app/test-pmd/txonly.c
+++ b/app/test-pmd/txonly.c
@@ -41,12 +41,12 @@
 #include "testpmd.h"
 
 /* RFC863 discard port */
-#define UDP_SRC_PORT 9
-#define UDP_DST_PORT 9
+uint16_t tx_udp_src_port = 9;
+uint16_t tx_udp_dst_port = 9;

[dpdk-dev] [PATCH 1/9] fbarray: fix errno values returned from functions

[Anatoly Burakov]

Errno values are supposed to be positive, yet they were negative.

This changes API, so not backporting.

Fixes: c44d09811b40 ("eal: add shared indexed file-backed array")

Signed-off-by: Anatoly Burakov 
---
 lib/librte_eal/common/eal_common_fbarray.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_fbarray.c 
b/lib/librte_eal/common/eal_common_fbarray.c
index 019f84c18..9ae942bfe 100644
--- a/lib/librte_eal/common/eal_common_fbarray.c
+++ b/lib/librte_eal/common/eal_common_fbarray.c
@@ -231,7 +231,7 @@ find_next_n(const struct rte_fbarray *arr, unsigned int 
start, unsigned int n,
return MASK_GET_IDX(msk_idx, run_start);
}
/* we didn't find anything */
-   rte_errno = used ? -ENOENT : -ENOSPC;
+   rte_errno = used ? ENOENT : ENOSPC;
return -1;
 }
 
@@ -287,7 +287,7 @@ find_next(const struct rte_fbarray *arr, unsigned int 
start, bool used)
return MASK_GET_IDX(idx, found);
}
/* we didn't find anything */
-   rte_errno = used ? -ENOENT : -ENOSPC;
+   rte_errno = used ? ENOENT : ENOSPC;
return -1;
 }
 
-- 
2.17.1

[dpdk-dev] [PATCH 0/9] mem: reduce memory fragmentation

[Anatoly Burakov]

This patchset is mostly dealing with changes fbarray, but it is
actually about reducing fragmentation in Linuxapp memalloc.

We allocate hugepages from lower VA to higher VA. However, our
malloc heap allocates addresses from higher VA to lower VA. This
results in a situation where, whenever new page is allocated,
malloc starts to allocate memory from the top, leaving fragmented
space between new allocation's leftover and previous leftover.

Over time, this leads to lots of free elements sitting at page
boundaries, small enough to be useful but large enough to have an
impact on memory fragmentation in certain circumstances.

To fix this, we need to allocate memory from higher VA first.
However, in order to do that, we need the ability to search fbarray
in reverse, which is currently not supported. Adding this support is
what most of this patchset is about.

First 4 patches fix some issues in existing fbarray implementation
and remove some code duplication, preparing for adding of new
functionality.

Next 3 patches add new functionality - reverse search of used/free
slots, mirroring already existing functionality in semantics and
capable of returning identical results but in reverse order.

Patch 8 adds unit tests for fbarray, testing both existing and new
functionality.

Finally, patch 9 changes memalloc to look up free slots in memseg
list in reverse order. No other changes is necessary, as all other
code can handle segments, wherever they are allocated.

Anatoly Burakov (9):
  fbarray: fix errno values returned from functions
  fbarray: reduce duplication in find_contig code
  fbarray: reduce duplication in find_next_n code
  fbarray: reduce duplication in find_next code
  fbarray: add reverse find_free/used
  fbarray: add reverse find n used/free
  fbarray: add reverse find contig used/free
  test: add fbarray autotests
  memalloc: allocate memory in reverse

 lib/librte_eal/common/eal_common_fbarray.c  | 493 ++---
 lib/librte_eal/common/include/rte_fbarray.h | 114 
 lib/librte_eal/linuxapp/eal/eal_memalloc.c  |   3 +-
 lib/librte_eal/rte_eal_version.map  |   6 +
 test/test/Makefile  |   1 +
 test/test/test_fbarray.c| 576 
 6 files changed, 1119 insertions(+), 74 deletions(-)
 create mode 100644 test/test/test_fbarray.c

-- 
2.17.1

[dpdk-dev] [PATCH 2/9] fbarray: reduce duplication in find_contig code

[Anatoly Burakov]

Mostly a code move, to have all code related to find_contig in
one place. This slightly changes the API in that previously,
calling find_contig_free() on a full fbarray would've been
an error, but equivalent call to find_contig_used() on an empty
array does not return an error, leading to an inconsistency in
the API.

The decision was made to not treat this condition as an error,
because it is equivalent to calling find_contig() on an index
that just happens to be used/free, which is not an error and
will return 0.

Signed-off-by: Anatoly Burakov 
---
 lib/librte_eal/common/eal_common_fbarray.c | 52 --
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_fbarray.c 
b/lib/librte_eal/common/eal_common_fbarray.c
index 9ae942bfe..e37fe1e4d 100644
--- a/lib/librte_eal/common/eal_common_fbarray.c
+++ b/lib/librte_eal/common/eal_common_fbarray.c
@@ -773,8 +773,8 @@ rte_fbarray_find_next_n_used(struct rte_fbarray *arr, 
unsigned int start,
return ret;
 }
 
-int __rte_experimental
-rte_fbarray_find_contig_free(struct rte_fbarray *arr, unsigned int start)
+static int
+fbarray_find_contig(struct rte_fbarray *arr, unsigned int start, bool used)
 {
int ret = -1;
 
@@ -786,14 +786,25 @@ rte_fbarray_find_contig_free(struct rte_fbarray *arr, 
unsigned int start)
/* prevent array from changing under us */
rte_rwlock_read_lock(&arr->rwlock);
 
-   if (arr->len == arr->count) {
-   rte_errno = ENOSPC;
-   goto out;
-   }
-
-   if (arr->count == 0) {
-   ret = arr->len - start;
-   goto out;
+   /* cheap checks to prevent doing useless work */
+   if (used) {
+   if (arr->count == 0) {
+   ret = 0;
+   goto out;
+   }
+   if (arr->len == arr->count) {
+   ret = arr->len - start;
+   goto out;
+   }
+   } else {
+   if (arr->len == arr->count) {
+   ret = 0;
+   goto out;
+   }
+   if (arr->count == 0) {
+   ret = arr->len - start;
+   goto out;
+   }
}
 
ret = find_contig(arr, start, false);
@@ -803,22 +814,15 @@ rte_fbarray_find_contig_free(struct rte_fbarray *arr, 
unsigned int start)
 }
 
 int __rte_experimental
-rte_fbarray_find_contig_used(struct rte_fbarray *arr, unsigned int start)
+rte_fbarray_find_contig_free(struct rte_fbarray *arr, unsigned int start)
 {
-   int ret = -1;
-
-   if (arr == NULL || start >= arr->len) {
-   rte_errno = EINVAL;
-   return -1;
-   }
-
-   /* prevent array from changing under us */
-   rte_rwlock_read_lock(&arr->rwlock);
-
-   ret = find_contig(arr, start, true);
+   return fbarray_find_contig(arr, start, false);
+}
 
-   rte_rwlock_read_unlock(&arr->rwlock);
-   return ret;
+int __rte_experimental
+rte_fbarray_find_contig_used(struct rte_fbarray *arr, unsigned int start)
+{
+   return fbarray_find_contig(arr, start, true);
 }
 
 int __rte_experimental
-- 
2.17.1

[dpdk-dev] [PATCH 5/9] fbarray: add reverse find_free/used

[Anatoly Burakov]

Add function to look up used/free indexes starting from specified
index, but going backwards instead of forward. Semantics are kept
similar to the existing function, except for the fact that, given
the same input, the results returned will be in reverse order.

Signed-off-by: Anatoly Burakov 
---
 lib/librte_eal/common/eal_common_fbarray.c  | 78 +++--
 lib/librte_eal/common/include/rte_fbarray.h | 34 +
 lib/librte_eal/rte_eal_version.map  |  2 +
 3 files changed, 109 insertions(+), 5 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_fbarray.c 
b/lib/librte_eal/common/eal_common_fbarray.c
index 22370398f..d5d72e37b 100644
--- a/lib/librte_eal/common/eal_common_fbarray.c
+++ b/lib/librte_eal/common/eal_common_fbarray.c
@@ -352,6 +352,60 @@ find_contig(const struct rte_fbarray *arr, unsigned int 
start, bool used)
return result;
 }
 
+static int
+find_prev(const struct rte_fbarray *arr, unsigned int start, bool used)
+{
+   const struct used_mask *msk = get_used_mask(arr->data, arr->elt_sz,
+   arr->len);
+   unsigned int idx, first, first_mod;
+   uint64_t ignore_msk;
+
+   /*
+* mask only has granularity of MASK_ALIGN, but start may not be aligned
+* on that boundary, so construct a special mask to exclude anything we
+* don't want to see to avoid confusing clz.
+*/
+   first = MASK_LEN_TO_IDX(start);
+   first_mod = MASK_LEN_TO_MOD(start);
+   /* we're going backwards, so mask must start from the top */
+   ignore_msk = first_mod == MASK_ALIGN - 1 ?
+   -1ULL : /* prevent overflow */
+   ~(-1ULL << (first_mod + 1));
+
+   /* go backwards, include zero */
+   idx = first;
+   do {
+   uint64_t cur = msk->data[idx];
+   int found;
+
+   /* if we're looking for free entries, invert mask */
+   if (!used)
+   cur = ~cur;
+
+   /* ignore everything before start on first iteration */
+   if (idx == first)
+   cur &= ignore_msk;
+
+   /* check if we have any entries */
+   if (cur == 0)
+   continue;
+
+   /*
+* find last set bit - that will correspond to whatever it is
+* that we're looking for. we're counting trailing zeroes, thus
+* the value we get is counted from end of mask, so calculate
+* position from start of mask.
+*/
+   found = MASK_ALIGN - __builtin_clzll(cur) - 1;
+
+   return MASK_GET_IDX(idx, found);
+   } while (idx-- != 0); /* decrement after check  to include zero*/
+
+   /* we didn't find anything */
+   rte_errno = used ? ENOENT : ENOSPC;
+   return -1;
+}
+
 static int
 set_used(struct rte_fbarray *arr, unsigned int idx, bool used)
 {
@@ -676,7 +730,7 @@ rte_fbarray_is_used(struct rte_fbarray *arr, unsigned int 
idx)
 }
 
 static int
-fbarray_find(struct rte_fbarray *arr, unsigned int start, bool used)
+fbarray_find(struct rte_fbarray *arr, unsigned int start, bool next, bool used)
 {
int ret = -1;
 
@@ -708,8 +762,10 @@ fbarray_find(struct rte_fbarray *arr, unsigned int start, 
bool used)
goto out;
}
}
-
-   ret = find_next(arr, start, used);
+   if (next)
+   ret = find_next(arr, start, used);
+   else
+   ret = find_prev(arr, start, used);
 out:
rte_rwlock_read_unlock(&arr->rwlock);
return ret;
@@ -718,13 +774,25 @@ fbarray_find(struct rte_fbarray *arr, unsigned int start, 
bool used)
 int __rte_experimental
 rte_fbarray_find_next_free(struct rte_fbarray *arr, unsigned int start)
 {
-   return fbarray_find(arr, start, false);
+   return fbarray_find(arr, start, true, false);
 }
 
 int __rte_experimental
 rte_fbarray_find_next_used(struct rte_fbarray *arr, unsigned int start)
 {
-   return fbarray_find(arr, start, true);
+   return fbarray_find(arr, start, true, true);
+}
+
+int __rte_experimental
+rte_fbarray_find_prev_free(struct rte_fbarray *arr, unsigned int start)
+{
+   return fbarray_find(arr, start, false, false);
+}
+
+int __rte_experimental
+rte_fbarray_find_prev_used(struct rte_fbarray *arr, unsigned int start)
+{
+   return fbarray_find(arr, start, false, true);
 }
 
 static int
diff --git a/lib/librte_eal/common/include/rte_fbarray.h 
b/lib/librte_eal/common/include/rte_fbarray.h
index 3e61fffee..54abe938a 100644
--- a/lib/librte_eal/common/include/rte_fbarray.h
+++ b/lib/librte_eal/common/include/rte_fbarray.h
@@ -336,6 +336,40 @@ rte_fbarray_find_contig_free(struct rte_fbarray *arr,
 int __rte_experimental
 rte_fbarray_find_contig_used(struct rte_fbarray *arr, unsigned int start);
 
+/**
+ * Find index of previous free element, starting at specified index.
+ *
+ *

[dpdk-dev] [PATCH 6/9] fbarray: add reverse find n used/free

[Anatoly Burakov]

Add a function to look for N used/free slots, but going backwards
instead of forwards. All semantics are kept similar to the existing
function, with the difference being that given the same input, the
same results will be returned in reverse order.

Signed-off-by: Anatoly Burakov 
---
 lib/librte_eal/common/eal_common_fbarray.c  | 198 +++-
 lib/librte_eal/common/include/rte_fbarray.h |  44 +
 lib/librte_eal/rte_eal_version.map  |   2 +
 3 files changed, 237 insertions(+), 7 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_fbarray.c 
b/lib/librte_eal/common/eal_common_fbarray.c
index d5d72e37b..a2e01148b 100644
--- a/lib/librte_eal/common/eal_common_fbarray.c
+++ b/lib/librte_eal/common/eal_common_fbarray.c
@@ -352,6 +352,169 @@ find_contig(const struct rte_fbarray *arr, unsigned int 
start, bool used)
return result;
 }
 
+static int
+find_prev_n(const struct rte_fbarray *arr, unsigned int start, unsigned int n,
+   bool used)
+{
+   const struct used_mask *msk = get_used_mask(arr->data, arr->elt_sz,
+   arr->len);
+   unsigned int msk_idx, lookbehind_idx, first, first_mod;
+   uint64_t ignore_msk;
+
+   /*
+* mask only has granularity of MASK_ALIGN, but start may not be aligned
+* on that boundary, so construct a special mask to exclude anything we
+* don't want to see to avoid confusing ctz.
+*/
+   first = MASK_LEN_TO_IDX(start);
+   first_mod = MASK_LEN_TO_MOD(start);
+   /* we're going backwards, so mask must start from the top */
+   ignore_msk = first_mod == MASK_ALIGN - 1 ?
+   -1ULL : /* prevent overflow */
+   ~(-1ULL << (first_mod + 1));
+
+   /* go backwards, include zero */
+   msk_idx = first;
+   do {
+   uint64_t cur_msk, lookbehind_msk;
+   unsigned int run_start, run_end, ctz, left;
+   bool found = false;
+   /*
+* The process of getting n consecutive bits from the top for
+* arbitrary n is a bit involved, but here it is in a nutshell:
+*
+*  1. let n be the number of consecutive bits we're looking for
+*  2. check if n can fit in one mask, and if so, do n-1
+* lshift-ands to see if there is an appropriate run inside
+* our current mask
+*2a. if we found a run, bail out early
+*2b. if we didn't find a run, proceed
+*  3. invert the mask and count trailing zeroes (that is, count
+* how many consecutive set bits we had starting from the
+* start of current mask) as k
+*3a. if k is 0, continue to next mask
+*3b. if k is not 0, we have a potential run
+*  4. to satisfy our requirements, next mask must have n-k
+* consecutive set bits at the end, so we will do (n-k-1)
+* lshift-ands and check if last bit is set.
+*
+* Step 4 will need to be repeated if (n-k) > MASK_ALIGN until
+* we either run out of masks, lose the run, or find what we
+* were looking for.
+*/
+   cur_msk = msk->data[msk_idx];
+   left = n;
+
+   /* if we're looking for free spaces, invert the mask */
+   if (!used)
+   cur_msk = ~cur_msk;
+
+   /* if we have an ignore mask, ignore once */
+   if (ignore_msk) {
+   cur_msk &= ignore_msk;
+   ignore_msk = 0;
+   }
+
+   /* if n can fit in within a single mask, do a search */
+   if (n <= MASK_ALIGN) {
+   uint64_t tmp_msk = cur_msk;
+   unsigned int s_idx;
+   for (s_idx = 0; s_idx < n - 1; s_idx++)
+   tmp_msk &= tmp_msk << 1ULL;
+   /* we found what we were looking for */
+   if (tmp_msk != 0) {
+   /* clz will give us offset from end of mask, and
+* we only get the end of our run, not start,
+* so adjust result to point to where start
+* would have been.
+*/
+   run_start = MASK_ALIGN -
+   __builtin_clzll(tmp_msk) - n;
+   return MASK_GET_IDX(msk_idx, run_start);
+   }
+   }
+
+   /*
+* we didn't find our run within the mask, or n > MASK_ALIGN,
+* so we're going for plan B.
+*/
+
+   /* coun

[dpdk-dev] [PATCH 3/9] fbarray: reduce duplication in find_next_n code

[Anatoly Burakov]

Mostly code move, aside from more quick checks done to avoid
doing computations in obviously hopeless cases.

Signed-off-by: Anatoly Burakov 
---
 lib/librte_eal/common/eal_common_fbarray.c | 63 --
 1 file changed, 36 insertions(+), 27 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_fbarray.c 
b/lib/librte_eal/common/eal_common_fbarray.c
index e37fe1e4d..c5ee017dd 100644
--- a/lib/librte_eal/common/eal_common_fbarray.c
+++ b/lib/librte_eal/common/eal_common_fbarray.c
@@ -723,54 +723,63 @@ rte_fbarray_find_next_used(struct rte_fbarray *arr, 
unsigned int start)
return ret;
 }
 
-int __rte_experimental
-rte_fbarray_find_next_n_free(struct rte_fbarray *arr, unsigned int start,
-   unsigned int n)
+static int
+fbarray_find_n(struct rte_fbarray *arr, unsigned int start, unsigned int n,
+   bool used)
 {
int ret = -1;
 
-   if (arr == NULL || start >= arr->len || n > arr->len) {
+   if (arr == NULL || start >= arr->len || n > arr->len || n == 0) {
rte_errno = EINVAL;
return -1;
}
+   if (arr->len - start < n) {
+   rte_errno = used ? ENOENT : ENOSPC;
+   return -1;
+   }
 
/* prevent array from changing under us */
rte_rwlock_read_lock(&arr->rwlock);
 
-   if (arr->len == arr->count || arr->len - arr->count < n) {
-   rte_errno = ENOSPC;
-   goto out;
+   /* cheap checks to prevent doing useless work */
+   if (!used) {
+   if (arr->len == arr->count || arr->len - arr->count < n) {
+   rte_errno = ENOSPC;
+   goto out;
+   }
+   if (arr->count == 0) {
+   ret = start;
+   goto out;
+   }
+   } else {
+   if (arr->count < n) {
+   rte_errno = ENOENT;
+   goto out;
+   }
+   if (arr->count == arr->len) {
+   ret = start;
+   goto out;
+   }
}
 
-   ret = find_next_n(arr, start, n, false);
+   ret = find_next_n(arr, start, n, used);
 out:
rte_rwlock_read_unlock(&arr->rwlock);
return ret;
 }
 
 int __rte_experimental
-rte_fbarray_find_next_n_used(struct rte_fbarray *arr, unsigned int start,
+rte_fbarray_find_next_n_free(struct rte_fbarray *arr, unsigned int start,
unsigned int n)
 {
-   int ret = -1;
-
-   if (arr == NULL || start >= arr->len || n > arr->len) {
-   rte_errno = EINVAL;
-   return -1;
-   }
-
-   /* prevent array from changing under us */
-   rte_rwlock_read_lock(&arr->rwlock);
-
-   if (arr->count < n) {
-   rte_errno = ENOENT;
-   goto out;
-   }
+   return fbarray_find_n(arr, start, n, false);
+}
 
-   ret = find_next_n(arr, start, n, true);
-out:
-   rte_rwlock_read_unlock(&arr->rwlock);
-   return ret;
+int __rte_experimental
+rte_fbarray_find_next_n_used(struct rte_fbarray *arr, unsigned int start,
+   unsigned int n)
+{
+   return fbarray_find_n(arr, start, n, true);
 }
 
 static int
-- 
2.17.1

[dpdk-dev] [PATCH 4/9] fbarray: reduce duplication in find_next code

[Anatoly Burakov]

Just code move to put all checks and calls in one place.

Signed-off-by: Anatoly Burakov 
---
 lib/librte_eal/common/eal_common_fbarray.c | 54 --
 1 file changed, 29 insertions(+), 25 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_fbarray.c 
b/lib/librte_eal/common/eal_common_fbarray.c
index c5ee017dd..22370398f 100644
--- a/lib/librte_eal/common/eal_common_fbarray.c
+++ b/lib/librte_eal/common/eal_common_fbarray.c
@@ -675,8 +675,8 @@ rte_fbarray_is_used(struct rte_fbarray *arr, unsigned int 
idx)
return ret;
 }
 
-int __rte_experimental
-rte_fbarray_find_next_free(struct rte_fbarray *arr, unsigned int start)
+static int
+fbarray_find(struct rte_fbarray *arr, unsigned int start, bool used)
 {
int ret = -1;
 
@@ -688,39 +688,43 @@ rte_fbarray_find_next_free(struct rte_fbarray *arr, 
unsigned int start)
/* prevent array from changing under us */
rte_rwlock_read_lock(&arr->rwlock);
 
-   if (arr->len == arr->count) {
-   rte_errno = ENOSPC;
-   goto out;
+   /* cheap checks to prevent doing useless work */
+   if (!used) {
+   if (arr->len == arr->count) {
+   rte_errno = ENOSPC;
+   goto out;
+   }
+   if (arr->count == 0) {
+   ret = start;
+   goto out;
+   }
+   } else {
+   if (arr->count == 0) {
+   rte_errno = ENOENT;
+   goto out;
+   }
+   if (arr->len == arr->count) {
+   ret = start;
+   goto out;
+   }
}
 
-   ret = find_next(arr, start, false);
+   ret = find_next(arr, start, used);
 out:
rte_rwlock_read_unlock(&arr->rwlock);
return ret;
 }
 
 int __rte_experimental
-rte_fbarray_find_next_used(struct rte_fbarray *arr, unsigned int start)
+rte_fbarray_find_next_free(struct rte_fbarray *arr, unsigned int start)
 {
-   int ret = -1;
-
-   if (arr == NULL || start >= arr->len) {
-   rte_errno = EINVAL;
-   return -1;
-   }
-
-   /* prevent array from changing under us */
-   rte_rwlock_read_lock(&arr->rwlock);
-
-   if (arr->count == 0) {
-   rte_errno = ENOENT;
-   goto out;
-   }
+   return fbarray_find(arr, start, false);
+}
 
-   ret = find_next(arr, start, true);
-out:
-   rte_rwlock_read_unlock(&arr->rwlock);
-   return ret;
+int __rte_experimental
+rte_fbarray_find_next_used(struct rte_fbarray *arr, unsigned int start)
+{
+   return fbarray_find(arr, start, true);
 }
 
 static int
-- 
2.17.1

[dpdk-dev] [PATCH 7/9] fbarray: add reverse find contig used/free

[Anatoly Burakov]

Add a function to return starting point of current contiguous
block, going backwards. All semantics are kept the same as the
existing function, with the only difference being that given the
same input, results will be returned in reverse order.

Signed-off-by: Anatoly Burakov 
---
 lib/librte_eal/common/eal_common_fbarray.c  | 90 +++--
 lib/librte_eal/common/include/rte_fbarray.h | 36 +
 lib/librte_eal/rte_eal_version.map  |  2 +
 3 files changed, 122 insertions(+), 6 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_fbarray.c 
b/lib/librte_eal/common/eal_common_fbarray.c
index a2e01148b..977174c4f 100644
--- a/lib/librte_eal/common/eal_common_fbarray.c
+++ b/lib/librte_eal/common/eal_common_fbarray.c
@@ -569,6 +569,60 @@ find_prev(const struct rte_fbarray *arr, unsigned int 
start, bool used)
return -1;
 }
 
+static int
+find_rev_contig(const struct rte_fbarray *arr, unsigned int start, bool used)
+{
+   const struct used_mask *msk = get_used_mask(arr->data, arr->elt_sz,
+   arr->len);
+   unsigned int idx, first, first_mod;
+   unsigned int need_len, result = 0;
+
+   first = MASK_LEN_TO_IDX(start);
+   first_mod = MASK_LEN_TO_MOD(start);
+
+   /* go backwards, include zero */
+   idx = first;
+   do {
+   uint64_t cur = msk->data[idx];
+   unsigned int run_len;
+
+   need_len = MASK_ALIGN;
+
+   /* if we're looking for free entries, invert mask */
+   if (!used)
+   cur = ~cur;
+
+   /* ignore everything after start on first iteration */
+   if (idx == first) {
+   unsigned int end_len = MASK_ALIGN - first_mod - 1;
+   cur <<= end_len;
+   /* at the start, we don't need the full mask len */
+   need_len -= end_len;
+   }
+
+   /* we will be looking for zeroes, so invert the mask */
+   cur = ~cur;
+
+   /* if mask is zero, we have a complete run */
+   if (cur == 0)
+   goto endloop;
+
+   /*
+* see where run ends, starting from the end.
+*/
+   run_len = __builtin_clzll(cur);
+
+   /* add however many zeroes we've had in the last run and quit */
+   if (run_len < need_len) {
+   result += run_len;
+   break;
+   }
+endloop:
+   result += need_len;
+   } while (idx-- != 0); /* decrement after check to include zero */
+   return result;
+}
+
 static int
 set_used(struct rte_fbarray *arr, unsigned int idx, bool used)
 {
@@ -1039,7 +1093,8 @@ rte_fbarray_find_prev_n_used(struct rte_fbarray *arr, 
unsigned int start,
 }
 
 static int
-fbarray_find_contig(struct rte_fbarray *arr, unsigned int start, bool used)
+fbarray_find_contig(struct rte_fbarray *arr, unsigned int start, bool next,
+   bool used)
 {
int ret = -1;
 
@@ -1057,22 +1112,33 @@ fbarray_find_contig(struct rte_fbarray *arr, unsigned 
int start, bool used)
ret = 0;
goto out;
}
-   if (arr->len == arr->count) {
+   if (next && arr->count == arr->len) {
ret = arr->len - start;
goto out;
}
+   if (!next && arr->count == arr->len) {
+   ret = start + 1;
+   goto out;
+   }
} else {
if (arr->len == arr->count) {
ret = 0;
goto out;
}
-   if (arr->count == 0) {
+   if (next && arr->count == 0) {
ret = arr->len - start;
goto out;
}
+   if (!next && arr->count == 0) {
+   ret = start + 1;
+   goto out;
+   }
}
 
-   ret = find_contig(arr, start, false);
+   if (next)
+   ret = find_contig(arr, start, used);
+   else
+   ret = find_rev_contig(arr, start, used);
 out:
rte_rwlock_read_unlock(&arr->rwlock);
return ret;
@@ -1081,13 +1147,25 @@ fbarray_find_contig(struct rte_fbarray *arr, unsigned 
int start, bool used)
 int __rte_experimental
 rte_fbarray_find_contig_free(struct rte_fbarray *arr, unsigned int start)
 {
-   return fbarray_find_contig(arr, start, false);
+   return fbarray_find_contig(arr, start, true, false);
 }
 
 int __rte_experimental
 rte_fbarray_find_contig_used(struct rte_fbarray *arr, unsigned int start)
 {
-   return fbarray_find_contig(arr, start, true);
+   return fbarray_find_contig(arr, start, true, true);
+}
+
+int __rte_experimental
+rte_fbarray_find_rev_contig_free(struct rte_fbar

[dpdk-dev] [PATCH 8/9] test: add fbarray autotests

[Anatoly Burakov]

Introduce a suite of autotests to cover functionality of fbarray.
This will check for invalid parameters, check API return values and
errno codes, and will also do some basic functionality checks on the
indexing code.

Signed-off-by: Anatoly Burakov 
---
 test/test/Makefile   |   1 +
 test/test/test_fbarray.c | 576 +++
 2 files changed, 577 insertions(+)
 create mode 100644 test/test/test_fbarray.c

diff --git a/test/test/Makefile b/test/test/Makefile
index eccc8efcf..41eab00e7 100644
--- a/test/test/Makefile
+++ b/test/test/Makefile
@@ -70,6 +70,7 @@ SRCS-y += test_memzone.c
 SRCS-y += test_bitmap.c
 SRCS-y += test_reciprocal_division.c
 SRCS-y += test_reciprocal_division_perf.c
+SRCS-y += test_fbarray.c
 
 SRCS-y += test_ring.c
 SRCS-y += test_ring_perf.c
diff --git a/test/test/test_fbarray.c b/test/test/test_fbarray.c
new file mode 100644
index 0..8c44e2c7e
--- /dev/null
+++ b/test/test/test_fbarray.c
@@ -0,0 +1,576 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2014 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+struct fbarray_testsuite_params {
+   struct rte_fbarray arr;
+   int start;
+   int end;
+};
+
+static struct fbarray_testsuite_params param;
+
+#define FBARRAY_TEST_ARR_NAME "fbarray_autotest"
+#define FBARRAY_TEST_LEN 256
+#define FBARRAY_TEST_ELT_SZ (sizeof(int))
+
+static int autotest_setup(void)
+{
+   return rte_fbarray_init(¶m.arr, FBARRAY_TEST_ARR_NAME,
+   FBARRAY_TEST_LEN, FBARRAY_TEST_ELT_SZ);
+}
+
+static void autotest_teardown(void)
+{
+   rte_fbarray_destroy(¶m.arr);
+}
+
+static int init_array(void)
+{
+   int i;
+   for (i = param.start; i <= param.end; i++) {
+   if (rte_fbarray_set_used(¶m.arr, i))
+   return -1;
+   }
+   return 0;
+}
+
+static void reset_array(void)
+{
+   int i;
+   for (i = 0; i < FBARRAY_TEST_LEN; i++)
+   rte_fbarray_set_free(¶m.arr, i);
+}
+
+static int first_msk_test_setup(void)
+{
+   /* put all within first mask */
+   param.start = 3;
+   param.end = 10;
+   return init_array();
+}
+
+static int cross_msk_test_setup(void)
+{
+   /* put all within second and third mask */
+   param.start = 70;
+   param.end = 160;
+   return init_array();
+}
+
+static int multi_msk_test_setup(void)
+{
+   /* put all within first and last mask */
+   param.start = 3;
+   param.end = FBARRAY_TEST_LEN - 20;
+   return init_array();
+}
+
+static int last_msk_test_setup(void)
+{
+   /* put all within last mask */
+   param.start = FBARRAY_TEST_LEN - 20;
+   param.end = FBARRAY_TEST_LEN - 1;
+   return init_array();
+}
+
+static int full_msk_test_setup(void)
+{
+   /* fill entire mask */
+   param.start = 0;
+   param.end = FBARRAY_TEST_LEN - 1;
+   return init_array();
+}
+
+static int empty_msk_test_setup(void)
+{
+   /* do not fill anything in */
+   reset_array();
+   return 0;
+}
+
+static int test_invalid(void)
+{
+   struct rte_fbarray dummy;
+
+   /* invalid parameters */
+   TEST_ASSERT_FAIL(rte_fbarray_attach(NULL),
+   "Call succeeded with invalid parameters\n");
+   TEST_ASSERT_EQUAL(rte_errno, EINVAL, "Wrong errno value\n");
+   TEST_ASSERT_FAIL(rte_fbarray_detach(NULL),
+   "Call succeeded with invalid parameters\n");
+   TEST_ASSERT_EQUAL(rte_errno, EINVAL, "Wrong errno value\n");
+
+   TEST_ASSERT_FAIL(rte_fbarray_destroy(NULL),
+   "Call succeeded with invalid parameters\n");
+   TEST_ASSERT_EQUAL(rte_errno, EINVAL, "Wrong errno valuey\n");
+   TEST_ASSERT_FAIL(rte_fbarray_init(NULL, "fail", 16, 16),
+   "Call succeeded with invalid parameters\n");
+   TEST_ASSERT_EQUAL(rte_errno, EINVAL, "Wrong errno value\n");
+   TEST_ASSERT_FAIL(rte_fbarray_init(&dummy, NULL, 16, 16),
+   "Call succeeded with invalid parameters\n");
+   TEST_ASSERT_EQUAL(rte_errno, EINVAL, "Wrong errno value\n");
+   TEST_ASSERT_FAIL(rte_fbarray_init(&dummy, "fail", 0, 16),
+   "Call succeeded with invalid parameters\n");
+   TEST_ASSERT_EQUAL(rte_errno, EINVAL, "Wrong errno value\n");
+   TEST_ASSERT_FAIL(rte_fbarray_init(&dummy, "fail", 16, 0),
+   "Call succeeded with invalid parameters\n");
+   TEST_ASSERT_EQUAL(rte_errno, EINVAL, "Wrong errno value\n");
+   /* len must not be greater than INT_MAX */
+   TEST_ASSERT_FAIL(rte_fbarray_init(&dummy, "fail", INT_MAX + 1U, 16),
+   "Call succeeded with invalid parameters\n");
+   TEST_ASSERT_EQUAL(rte_errno, EINVAL, "Wrong errno value\n");
+
+   TEST_ASSERT_NULL(rte_fbarray_get(NULL, 0),
+   "Call succeeded with invalid parameters\n");
+  

[dpdk-dev] [PATCH 9/9] memalloc: allocate memory in reverse

[Anatoly Burakov]

Currently, all hugepages are allocated from lower VA address to
higher VA address, while malloc heap allocates from higher VA
address to lower VA address. This results in heap fragmentation
over time due to multiple reserves leaving small space below the
allocated elements.

Fix this by allocating VA memory from the top, thereby reducing
fragmentation and lowering overall memory usage.

Signed-off-by: Anatoly Burakov 
---
 lib/librte_eal/linuxapp/eal/eal_memalloc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c 
b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
index 8c11f98c9..d35fb52c4 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memalloc.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
@@ -682,7 +682,8 @@ alloc_seg_walk(const struct rte_memseg_list *msl, void *arg)
need = wa->n_segs;
 
/* try finding space in memseg list */
-   cur_idx = rte_fbarray_find_next_n_free(&cur_msl->memseg_arr, 0, need);
+   cur_idx = rte_fbarray_find_prev_n_free(&cur_msl->memseg_arr,
+   cur_msl->memseg_arr.len - 1, need);
if (cur_idx < 0)
return 0;
start_idx = cur_idx;
-- 
2.17.1

Re: [dpdk-dev] [PATCH v2 03/31] crypto/qat: remove unused includes

[De Lara Guarch, Pablo]

Hi,

> -Original Message-
> From: Trahe, Fiona
> Sent: Friday, May 11, 2018 12:14 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo ; Trahe, Fiona
> ; Jozwiak, TomaszX ;
> ArkadiuszX Kusztal 
> Subject: [PATCH v2 03/31] crypto/qat: remove unused includes
> 
> This commit removes unused includes from qat_crypto.c and removes unused
> file qat_algs.h
> 
> Signed-off-by: ArkadiuszX Kusztal 
> Signed-off-by: Fiona Trahe 

There is a compilation error on this patch.

Thanks,
Pablo

Re: [dpdk-dev] [PATCH v2 26/31] crypto/qat: cleanups

[De Lara Guarch, Pablo]

> -Original Message-
> From: Trahe, Fiona
> Sent: Friday, May 11, 2018 12:14 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo ; Trahe, Fiona
> ; Jozwiak, TomaszX 
> Subject: [PATCH v2 26/31] crypto/qat: cleanups
> 
>  - renamed sgl_cookie to cookie
>  - renamed qp_gen_config to qat_gen_config as it is intended
>to hold more than just qp data.
>  - removed unused macro - ALIGN_POW2
>  - moved 64_BYTE_ALIGN to qat_common.h
>  - removed crypto reference in common debug msg
>  - free cookie pool on qp creation error
> 
> Signed-off-by: Fiona Trahe 
> Signed-off-by: Tomasz Jozwiak 

This patch can be split into multiple patches based on the commit message.

Thanks,
Pablo

Re: [dpdk-dev] [PATCH v2 29/31] crypto/qat: add performance improvement into qat crypto dev.

[De Lara Guarch, Pablo]

> -Original Message-
> From: Trahe, Fiona
> Sent: Friday, May 11, 2018 12:14 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo ; Trahe, Fiona
> ; Jozwiak, TomaszX 
> Subject: [PATCH v2 29/31] crypto/qat: add performance improvement into qat
> crypto dev.
> 
> From: Tomasz Jozwiak 
> 
>   - removed unused args. from process_response function
>   - changed adf_modulo function
>   - changed qat_sym_process_response into static inline version
> 
> Signed-off-by: Tomasz Jozwiak 
> Signed-off-by: Fiona Trahe 

This patch can be split into multiple patches, looking at the commit message.

Thanks,
Pablo

Re: [dpdk-dev] [PATCH] app/testpmd: fix VLAN tci mask set error for FDIR

[Lu, Wenzhuo]

Hi,

> -Original Message-
> From: Zhao1, Wei
> Sent: Tuesday, June 5, 2018 5:12 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; sta...@dpdk.org; Zhao1, Wei
> 
> Subject: [PATCH] app/testpmd: fix VLAN tci mask set error for FDIR
> 
> The vlan tci mask should be set to 0xEFFF, not 0x0, the wrong mask will
> cause mask error for register set.
> 
> Fixes: d9d5e6f2f0ba ("app/testpmd: set default flow director mask")
> Signed-off-by: Wei Zhao 
Acked-by: Wenzhuo Lu 

Re: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for cross compiling from x86

[Gavin Hu]

> -Original Message-
> From: Jerin Jacob 
> Sent: Monday, June 4, 2018 8:51 PM
> To: Gavin Hu 
> Cc: Bruce Richardson ; Thomas Monjalon
> ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for cross
> compiling from x86
> 
> -Original Message-
> > Date: Mon, 4 Jun 2018 06:03:34 +
> > From: Gavin Hu 
> > To: Jerin Jacob , Bruce Richardson
> > , Thomas Monjalon 
> > CC: "dev@dpdk.org" 
> > Subject: RE: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for cross
> > compiling from x86
> >
> > See my inline comments:
> >
> > > -Original Message-
> > > From: Jerin Jacob 
> > > Sent: Thursday, May 31, 2018 3:36 AM
> > > To: Gavin Hu 
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for
> > > cross compiling from x86
> > >
> > > -Original Message-
> > > > Date: Tue, 29 May 2018 18:43:36 +0800
> > > > From: Gavin Hu 
> > > > To: dev@dpdk.org
> > > > CC: gavin...@arm.com
> > > > Subject: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for cross
> > > > compiling  from x86
> > > > X-Mailer: git-send-email 2.1.4
> > > >
> > > > +   1. EXTRA_CFLAGS and EXTRA_LDFLAGS should be added to include
> > > > + the
> > > NUMA headers and link the library respectively,
> > > > +   if the step
> > > > + :ref:`argment_the_cross_toolcain_with_numa_support` was
> > > skipped therefore the toolchain was not
> > > > +   argmented with NUMA support.
> > > > +
> > > > +   2. RTE_DEVEL_BUILD has to be disabled, otherwise the numa.h
> > > > + file gets
> > >
> > > If the warnings are from numa.h then please use -isystem  > > install dir> instead of disabling RTE_DEVEL_BUILD.
> > >
> > [Gavin Hu] This is a good advice, I verified it okay and can upload a new
> patch.
> >
> > > > +   a lot of compiling errors of Werror=cast-qual,
> > > > + Werror=strict-prototypes
> > > and Werror=old-style-definition.
> > > > +   An example is given below:
> > > > +
> > > > +   .. code-block:: console
> > > > +
> > > > +  make -j CROSS=aarch64-linux-gnu- CONFIG_RTE_KNI_KMOD=n
> > > CONFIG_RTE_EAL_IGB_UIO=n
> > > > +  RTE_DEVEL_BUILD=n EXTRA_CFLAGS="-
> I/include"
> > > EXTRA_LDFLAGS=
> > > > +  "-L/lib -lnuma"
> > > > +
> > >
> > > As discussed earlier, meson cross build instruction is missing.
> > >
> > [Gavin Hu] I reproduced the meson build issue Bruce reported, as shown
> below.
> > It was not introduced by gcc, nor clang, it was actually introduced by
> > meson.build, see line #65 of
> > http://www.dpdk.org/browse/dpdk/tree/config/meson.build
> > Even worse, "has_argument" is not reliable(refer here:
> http://mesonbuild.com/Compiler-properties.html#has-argument) for some
> compilers.
> > This is the case of gcc and clang, which caused the 4 warning options were
> included in the whole project, either the compiler is gcc or clang, cross or
> native.
> > This finally caused the unrecognized warning options.
> >
> > I tried to disable the warning options, then the compiling got lots of noisy
> warnings and errors.
> >
> > To fix this issue, we need to create a meson subproject  for pmdinfogen,
> the change is not little and I am not familiar with this.
> >
> > Any comments are welcome!
> 
> 
> If I am not wrong, This is specific to host compiler issue with specific 
> version.
> Right? The build steps will remain same, so as far as this patch concerned,
> you can add the meson build step in this patch.
> 
[Gavin Hu] Hi Jerin, 
Sorry for late response, but I am still keeping working on that(some more 
patches are in process of internal review).
The host compiler issue with specific version was fixed by one of my patch. 

With all my patches applied:
For GNU Makefile, 
1. Host clang + cross gcc works
2. Host gcc + cross gcc works

For Meson/Ninja:
3. Host gcc + cross gcc works
4. Host clang + cross gcc does NOT work

The root cause of number 4  is clear, it is a meson build project issue. 
Both gcc and clang take all the 4 project arguments, but can NOT recognize this 
one: warning option '-Wno-format-truncation'
For more details , please have a look at line #56~#67 of this file:
http://www.dpdk.org/browse/dpdk/tree/config/meson.build 
http://mesonbuild.com/Compiler-properties.html#has-argument 

The compiling error:
clang  -Ibuildtools/pmdinfogen/pmdinfogen@exe -Ibuildtools/pmdinfogen 
-I../buildtools/pmdinfogen -Iconfig -I../config -I. -I../ 
-Ilib/librte_eal/common/include/arch/arm 
-I../lib/librte_eal/common/include/arch/arm -Ilib/librte_eal/common/include 
-I../lib/librte_eal/common/include -Ilib/librte_eal/common 
-I../lib/librte_eal/common -Ilib/librte_eal/linuxapp/eal/../../../librte_compat 
-I../lib/librte_eal/linuxapp/eal/../../../librte_compat 
-I../lib/librte_eal/linuxapp/eal/include 
-Ibuildtools/pmdinfogen/../../lib/librte_pci 
-I../buildtools/pmdinfogen/../../lib/librte_pci -Xclang -fcolor-diagnostics 
-pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -O3 -include 
rte_config.h -Wsign-compare -Wcast-qual -Wno-address-of-pa

Re: [dpdk-dev] [PATCH 1/4] mbuf: add accessor function for private data area

[Dan Gora]

Hi Andrew,

On Sat, Jun 9, 2018 at 2:23 AM, Andrew Rybchenko
 wrote:

> BTW, thinking about function I found out there is a trap in private area
> size related to the function. I think that the function description should
> highlight that rte_pktmbuf_priv_size(m->pool) should be used to
> find out the size of private area since indirect mbuf has size of the
> direct private are in its priv_size (but we return pointer to the indirect
> mbuf (the mbuf itself) private area here).
>

hmm... I guess I didn't realize that.

I think that what I'm going to do is just remove the check for
m->priv_size == 0 entirely.  It seems like checking the priv_size is
just going to cause more problems down the road than it is worth.  The
whole point of this was just to have a simple API function to access
the private area, not to fully save the programmer from shooting
him/herself in the foot by accessing a private data area which doesn't
necessarily exist.

thanks,
dan

Re: [dpdk-dev] [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR

[Lu, Wenzhuo]

Hi Wei,


> -Original Message-
> From: Zhao1, Wei
> Sent: Tuesday, June 5, 2018 5:12 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; sta...@dpdk.org; Zhao1, Wei
> 
> Subject: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> 
> In IP mode FDIR, X550 can support not only 4 tuple parameters but also vlan
> tci in protocol, so add this feature to flow parser.
> 
> Fixes: 11777435c727 ("net/ixgbe: parse flow director filter")
> 
> Signed-off-by: Wei Zhao 
> ---
>  drivers/net/ixgbe/ixgbe_flow.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
> index 0427e6f..f5e7805 100644
> --- a/drivers/net/ixgbe/ixgbe_flow.c
> +++ b/drivers/net/ixgbe/ixgbe_flow.c
> @@ -322,7 +322,8 @@ cons_parse_ntuple_filter(const struct rte_flow_attr
> *attr,
>   }
>   /* check if the next not void item is IPv4 */
The comment should be updated too, if we need below change.

>   item = next_no_void_pattern(pattern, item);
> - if (item->type != RTE_FLOW_ITEM_TYPE_IPV4) {
> + if (item->type != RTE_FLOW_ITEM_TYPE_IPV4 &&
> + item->type != RTE_FLOW_ITEM_TYPE_VLAN) {
>   rte_flow_error_set(error,
> EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
> item, "Not supported by ntuple filter"); 
Really confused. I see the above code is already wrapped by " if (item->type == 
RTE_FLOW_ITEM_TYPE_VLAN) {". You want to support double vlan?

Re: [dpdk-dev] [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR

[Zhao1, Wei]

Hi, wenzhuo

> -Original Message-
> From: Lu, Wenzhuo
> Sent: Tuesday, June 12, 2018 10:26 AM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: sta...@dpdk.org
> Subject: RE: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> 
> Hi Wei,
> 
> 
> > -Original Message-
> > From: Zhao1, Wei
> > Sent: Tuesday, June 5, 2018 5:12 PM
> > To: dev@dpdk.org
> > Cc: Lu, Wenzhuo ; sta...@dpdk.org; Zhao1, Wei
> > 
> > Subject: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> >
> > In IP mode FDIR, X550 can support not only 4 tuple parameters but also
> > vlan tci in protocol, so add this feature to flow parser.
> >
> > Fixes: 11777435c727 ("net/ixgbe: parse flow director filter")
> >
> > Signed-off-by: Wei Zhao 
> > ---
> >  drivers/net/ixgbe/ixgbe_flow.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_flow.c
> > b/drivers/net/ixgbe/ixgbe_flow.c index 0427e6f..f5e7805 100644
> > --- a/drivers/net/ixgbe/ixgbe_flow.c
> > +++ b/drivers/net/ixgbe/ixgbe_flow.c
> > @@ -322,7 +322,8 @@ cons_parse_ntuple_filter(const struct
> > rte_flow_attr *attr,
> > }
> > /* check if the next not void item is IPv4 */
> The comment should be updated too, if we need below change.

Ok， I will update it.
> 
> > item = next_no_void_pattern(pattern, item);
> > -   if (item->type != RTE_FLOW_ITEM_TYPE_IPV4) {
> > +   if (item->type != RTE_FLOW_ITEM_TYPE_IPV4 &&
> > +   item->type != RTE_FLOW_ITEM_TYPE_VLAN)
> {
> > rte_flow_error_set(error,
> >   EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
> >   item, "Not supported by ntuple filter");
> Really confused. I see the above code is already wrapped by " if (item->type
> == RTE_FLOW_ITEM_TYPE_VLAN) {". You want to support double vlan?

No, I have get a report that some use the following mode 
sendp([Ether(dst="A0:36:9F:BD:5D:B0")/Dot1Q(vlan=1)/IP(src="192.168.0.1",dst="192.168.0.2",tos=2,ttl=40)/UDP(dport=23,
 sport=22)/Raw('x'*100)],iface="enp3s0f0",count=10)
to test fdir IP mode.
In order to support this, we need this patch.

Re: [dpdk-dev] [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR

[Lu, Wenzhuo]

> -Original Message-
> From: Zhao1, Wei
> Sent: Tuesday, June 12, 2018 10:31 AM
> To: Lu, Wenzhuo ; dev@dpdk.org
> Cc: sta...@dpdk.org
> Subject: RE: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> 
> Hi, wenzhuo
> 
> > -Original Message-
> > From: Lu, Wenzhuo
> > Sent: Tuesday, June 12, 2018 10:26 AM
> > To: Zhao1, Wei ; dev@dpdk.org
> > Cc: sta...@dpdk.org
> > Subject: RE: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> >
> > Hi Wei,
> >
> >
> > > -Original Message-
> > > From: Zhao1, Wei
> > > Sent: Tuesday, June 5, 2018 5:12 PM
> > > To: dev@dpdk.org
> > > Cc: Lu, Wenzhuo ; sta...@dpdk.org; Zhao1, Wei
> > > 
> > > Subject: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> > >
> > > In IP mode FDIR, X550 can support not only 4 tuple parameters but
> > > also vlan tci in protocol, so add this feature to flow parser.
> > >
> > > Fixes: 11777435c727 ("net/ixgbe: parse flow director filter")
> > >
> > > Signed-off-by: Wei Zhao 
> > > ---

> >
> > >   item = next_no_void_pattern(pattern, item);
> > > - if (item->type != RTE_FLOW_ITEM_TYPE_IPV4) {
> > > + if (item->type != RTE_FLOW_ITEM_TYPE_IPV4 &&
> > > + item->type != RTE_FLOW_ITEM_TYPE_VLAN)
> > {
> > >   rte_flow_error_set(error,
> > > EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
> > > item, "Not supported by ntuple filter");
> > Really confused. I see the above code is already wrapped by " if
> > (item->type == RTE_FLOW_ITEM_TYPE_VLAN) {". You want to support
> double vlan?
> 
> No, I have get a report that some use the following mode
> sendp([Ether(dst="A0:36:9F:BD:5D:B0")/Dot1Q(vlan=1)/IP(src="192.168.0.1",d
> st="192.168.0.2",tos=2,ttl=40)/UDP(dport=23,
> sport=22)/Raw('x'*100)],iface="enp3s0f0",count=10)
> to test fdir IP mode.
> In order to support this, we need this patch.
I can understand the change in ' ixgbe_parse_fdir_filter_normal' is to support 
this case.
What I cannot understand is the above change. The original code is already for 
the case vlan + IPv4.

Re: [dpdk-dev] [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR

[Zhao1, Wei]

> -Original Message-
> From: Lu, Wenzhuo
> Sent: Tuesday, June 12, 2018 10:42 AM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: sta...@dpdk.org
> Subject: RE: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> 
> > -Original Message-
> > From: Zhao1, Wei
> > Sent: Tuesday, June 12, 2018 10:31 AM
> > To: Lu, Wenzhuo ; dev@dpdk.org
> > Cc: sta...@dpdk.org
> > Subject: RE: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> >
> > Hi, wenzhuo
> >
> > > -Original Message-
> > > From: Lu, Wenzhuo
> > > Sent: Tuesday, June 12, 2018 10:26 AM
> > > To: Zhao1, Wei ; dev@dpdk.org
> > > Cc: sta...@dpdk.org
> > > Subject: RE: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> > >
> > > Hi Wei,
> > >
> > >
> > > > -Original Message-
> > > > From: Zhao1, Wei
> > > > Sent: Tuesday, June 5, 2018 5:12 PM
> > > > To: dev@dpdk.org
> > > > Cc: Lu, Wenzhuo ; sta...@dpdk.org; Zhao1,
> > > > Wei 
> > > > Subject: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> > > >
> > > > In IP mode FDIR, X550 can support not only 4 tuple parameters but
> > > > also vlan tci in protocol, so add this feature to flow parser.
> > > >
> > > > Fixes: 11777435c727 ("net/ixgbe: parse flow director filter")
> > > >
> > > > Signed-off-by: Wei Zhao 
> > > > ---
> 
> > >
> > > > item = next_no_void_pattern(pattern, item);
> > > > -   if (item->type != RTE_FLOW_ITEM_TYPE_IPV4) {
> > > > +   if (item->type != RTE_FLOW_ITEM_TYPE_IPV4 &&
> > > > +   item->type != RTE_FLOW_ITEM_TYPE_VLAN)
> > > {
> > > > rte_flow_error_set(error,
> > > >   EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
> > > >   item, "Not supported by ntuple filter");
> > > Really confused. I see the above code is already wrapped by " if
> > > (item->type == RTE_FLOW_ITEM_TYPE_VLAN) {". You want to support
> > double vlan?
> >
> > No, I have get a report that some use the following mode
> > sendp([Ether(dst="A0:36:9F:BD:5D:B0")/Dot1Q(vlan=1)/IP(src="192.168.0.
> > 1",d st="192.168.0.2",tos=2,ttl=40)/UDP(dport=23,
> > sport=22)/Raw('x'*100)],iface="enp3s0f0",count=10)
> > to test fdir IP mode.
> > In order to support this, we need this patch.
> I can understand the change in ' ixgbe_parse_fdir_filter_normal' is to support
> this case.
> What I cannot understand is the above change. The original code is already
> for the case vlan + IPv4.
> 

If we do not change code as this way, as we do not add " item->type != 
RTE_FLOW_ITEM_TYPE_VLAN ".
Even there is code which support VLAN in the following code,  but it will " 
return -rte_errno; " first when user using 
Ether/ Dot1Q(vlan=1)/IP()/UDP mode packet, this error is caused by missing " 
item->type != RTE_FLOW_ITEM_TYPE_VLAN".

Re: [dpdk-dev] [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR

[Zhao1, Wei]

Hi， wenzhuo

> -Original Message-
> From: Lu, Wenzhuo
> Sent: Tuesday, June 12, 2018 10:42 AM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: sta...@dpdk.org
> Subject: RE: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> 
> > -Original Message-
> > From: Zhao1, Wei
> > Sent: Tuesday, June 12, 2018 10:31 AM
> > To: Lu, Wenzhuo ; dev@dpdk.org
> > Cc: sta...@dpdk.org
> > Subject: RE: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> >
> > Hi, wenzhuo
> >
> > > -Original Message-
> > > From: Lu, Wenzhuo
> > > Sent: Tuesday, June 12, 2018 10:26 AM
> > > To: Zhao1, Wei ; dev@dpdk.org
> > > Cc: sta...@dpdk.org
> > > Subject: RE: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> > >
> > > Hi Wei,
> > >
> > >
> > > > -Original Message-
> > > > From: Zhao1, Wei
> > > > Sent: Tuesday, June 5, 2018 5:12 PM
> > > > To: dev@dpdk.org
> > > > Cc: Lu, Wenzhuo ; sta...@dpdk.org; Zhao1,
> > > > Wei 
> > > > Subject: [PATCH] net/ixgbe: add support for VLAN in IP mode FDIR
> > > >
> > > > In IP mode FDIR, X550 can support not only 4 tuple parameters but
> > > > also vlan tci in protocol, so add this feature to flow parser.
> > > >
> > > > Fixes: 11777435c727 ("net/ixgbe: parse flow director filter")
> > > >
> > > > Signed-off-by: Wei Zhao 
> > > > ---
> 
> > >
> > > > item = next_no_void_pattern(pattern, item);
> > > > -   if (item->type != RTE_FLOW_ITEM_TYPE_IPV4) {
> > > > +   if (item->type != RTE_FLOW_ITEM_TYPE_IPV4 &&
> > > > +   item->type != RTE_FLOW_ITEM_TYPE_VLAN)
> > > {
> > > > rte_flow_error_set(error,
> > > >   EINVAL, RTE_FLOW_ERROR_TYPE_ITEM,
> > > >   item, "Not supported by ntuple filter");
> > > Really confused. I see the above code is already wrapped by " if
> > > (item->type == RTE_FLOW_ITEM_TYPE_VLAN) {". You want to support
> > double vlan?
> >
> > No, I have get a report that some use the following mode
> > sendp([Ether(dst="A0:36:9F:BD:5D:B0")/Dot1Q(vlan=1)/IP(src="192.168.0.
> > 1",d st="192.168.0.2",tos=2,ttl=40)/UDP(dport=23,
> > sport=22)/Raw('x'*100)],iface="enp3s0f0",count=10)
> > to test fdir IP mode.
> > In order to support this, we need this patch.
> I can understand the change in ' ixgbe_parse_fdir_filter_normal' is to support
> this case.
> What I cannot understand is the above change. The original code is already
> for the case vlan + IPv4.
> 

I will commit new v2 for your comment.

Re: [dpdk-dev] [PATCH] net/ixgbe: fix tunnel id format error for FDIR

[Lu, Wenzhuo]

Hi Wei,


> -Original Message-
> From: Zhao1, Wei
> Sent: Tuesday, June 5, 2018 5:12 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; sta...@dpdk.org; Zhao1, Wei
> 
> Subject: [PATCH] net/ixgbe: fix tunnel id format error for FDIR
> 
> In cloud mode for FDIR, tunnel id should be set as protocol request, the
> lower 8 bits should be set as reserved.
To my opinion, the original implementation and this patch have different 
understanding of the 'tunnel_id' in ' struct rte_eth_tunnel_flow'. Originally 
it only means the tunnel id but not including the reserved 8 bits.
This patch means it should include the reserved bits. Maybe it makes things 
easier because the whole 4 bytes are big endian.
So, may I suggest to add some comments in ' struct rte_eth_tunnel_flow' to let 
the users know what the 'tunnel_id' really means?

> 
> Fixes: 82fb702077f6 ("ixgbe: support new flow director modes for X550")
> Fixes: 11777435c727 ("net/ixgbe: parse flow director filter")
> 
> Signed-off-by: Wei Zhao 
> ---
>  drivers/net/ixgbe/ixgbe_fdir.c | 2 +-
>  drivers/net/ixgbe/ixgbe_flow.c | 5 ++---
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_fdir.c b/drivers/net/ixgbe/ixgbe_fdir.c
> index d5e5179..67ab627 100644
> --- a/drivers/net/ixgbe/ixgbe_fdir.c
> +++ b/drivers/net/ixgbe/ixgbe_fdir.c
> @@ -774,7 +774,7 @@ ixgbe_fdir_filter_to_atr_input(const struct
> rte_eth_fdir_filter *fdir_filter,
>   input->formatted.tunnel_type =
>   fdir_filter->input.flow.tunnel_flow.tunnel_type;
>   input->formatted.tni_vni =
> - fdir_filter->input.flow.tunnel_flow.tunnel_id;
> + fdir_filter->input.flow.tunnel_flow.tunnel_id >> 8;
>   }
> 
>   return 0;
> diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
> index eb0644c..64af777 100644
> --- a/drivers/net/ixgbe/ixgbe_flow.c
> +++ b/drivers/net/ixgbe/ixgbe_flow.c
> @@ -2489,8 +2489,7 @@ ixgbe_parse_fdir_filter_tunnel(const struct
> rte_flow_attr *attr,
>   rte_memcpy(((uint8_t *)
>   &rule->ixgbe_fdir.formatted.tni_vni + 1),
>   vxlan_spec->vni, RTE_DIM(vxlan_spec->vni));
> - rule->ixgbe_fdir.formatted.tni_vni =
> rte_be_to_cpu_32(
> - rule->ixgbe_fdir.formatted.tni_vni);
> + rule->ixgbe_fdir.formatted.tni_vni >>= 8;
>   }
>   }
> 
> @@ -2587,7 +2586,7 @@ ixgbe_parse_fdir_filter_tunnel(const struct
> rte_flow_attr *attr,
>   /* tni is a 24-bits bit field */
>   rte_memcpy(&rule->ixgbe_fdir.formatted.tni_vni,
>   nvgre_spec->tni, RTE_DIM(nvgre_spec->tni));
> - rule->ixgbe_fdir.formatted.tni_vni <<= 8;
> + rule->ixgbe_fdir.formatted.tni_vni >>= 8;
>   }
>   }
> 
> --
> 2.7.5

[dpdk-dev] [PATCH v2] crypto/scheduler: add dynamic logging to scheduler

[Hari Kumar]

From: hvemulax 

1.added new logtype for driver.
2.registered the new logtype.
3.CS_LOG_ERR and RTE_LOG logtypes are replaced
with new logtype name.

Signed-off-by: Hari Kumar 
Reviewed-by: Reshma Pattan 

---
v2: Removed newline from logs as it is in log macro itself
---
 drivers/crypto/scheduler/rte_cryptodev_scheduler.c | 97 --
 drivers/crypto/scheduler/scheduler_failover.c  |  4 +-
 drivers/crypto/scheduler/scheduler_multicore.c | 11 +--
 .../crypto/scheduler/scheduler_pkt_size_distr.c| 14 ++--
 drivers/crypto/scheduler/scheduler_pmd.c   | 30 +++
 drivers/crypto/scheduler/scheduler_pmd_ops.c   | 30 +++
 drivers/crypto/scheduler/scheduler_pmd_private.h   | 24 ++
 drivers/crypto/scheduler/scheduler_roundrobin.c|  2 +-
 8 files changed, 105 insertions(+), 107 deletions(-)

diff --git a/drivers/crypto/scheduler/rte_cryptodev_scheduler.c 
b/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
index ed574cc18..ce35b5fac 100644
--- a/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
+++ b/drivers/crypto/scheduler/rte_cryptodev_scheduler.c
@@ -9,6 +9,8 @@
 #include "rte_cryptodev_scheduler.h"
 #include "scheduler_pmd_private.h"
 
+int scheduler_logtype_driver;
+
 /** update the scheduler pmd's capability with attaching device's
  *  capability.
  *  For each device to be attached, the scheduler's capability should be
@@ -168,30 +170,30 @@ rte_cryptodev_scheduler_slave_attach(uint8_t 
scheduler_id, uint8_t slave_id)
uint32_t i;
 
if (!dev) {
-   CS_LOG_ERR("Operation not supported");
+   SCHEDULER_PMD_LOG(ERR, "Operation not supported");
return -ENOTSUP;
}
 
if (dev->driver_id != cryptodev_driver_id) {
-   CS_LOG_ERR("Operation not supported");
+   SCHEDULER_PMD_LOG(ERR, "Operation not supported");
return -ENOTSUP;
}
 
if (dev->data->dev_started) {
-   CS_LOG_ERR("Illegal operation");
+   SCHEDULER_PMD_LOG(ERR, "Illegal operation");
return -EBUSY;
}
 
sched_ctx = dev->data->dev_private;
if (sched_ctx->nb_slaves >=
RTE_CRYPTODEV_SCHEDULER_MAX_NB_SLAVES) {
-   CS_LOG_ERR("Too many slaves attached");
+   SCHEDULER_PMD_LOG(ERR, "Too many slaves attached");
return -ENOMEM;
}
 
for (i = 0; i < sched_ctx->nb_slaves; i++)
if (sched_ctx->slaves[i].dev_id == slave_id) {
-   CS_LOG_ERR("Slave already added");
+   SCHEDULER_PMD_LOG(ERR, "Slave already added");
return -ENOTSUP;
}
 
@@ -208,7 +210,7 @@ rte_cryptodev_scheduler_slave_attach(uint8_t scheduler_id, 
uint8_t slave_id)
slave->driver_id = 0;
sched_ctx->nb_slaves--;
 
-   CS_LOG_ERR("capabilities update failed");
+   SCHEDULER_PMD_LOG(ERR, "capabilities update failed");
return -ENOTSUP;
}
 
@@ -227,17 +229,17 @@ rte_cryptodev_scheduler_slave_detach(uint8_t 
scheduler_id, uint8_t slave_id)
uint32_t i, slave_pos;
 
if (!dev) {
-   CS_LOG_ERR("Operation not supported");
+   SCHEDULER_PMD_LOG(ERR, "Operation not supported");
return -ENOTSUP;
}
 
if (dev->driver_id != cryptodev_driver_id) {
-   CS_LOG_ERR("Operation not supported");
+   SCHEDULER_PMD_LOG(ERR, "Operation not supported");
return -ENOTSUP;
}
 
if (dev->data->dev_started) {
-   CS_LOG_ERR("Illegal operation");
+   SCHEDULER_PMD_LOG(ERR, "Illegal operation");
return -EBUSY;
}
 
@@ -247,12 +249,12 @@ rte_cryptodev_scheduler_slave_detach(uint8_t 
scheduler_id, uint8_t slave_id)
if (sched_ctx->slaves[slave_pos].dev_id == slave_id)
break;
if (slave_pos == sched_ctx->nb_slaves) {
-   CS_LOG_ERR("Cannot find slave");
+   SCHEDULER_PMD_LOG(ERR, "Cannot find slave");
return -ENOTSUP;
}
 
if (sched_ctx->ops.slave_detach(dev, slave_id) < 0) {
-   CS_LOG_ERR("Failed to detach slave");
+   SCHEDULER_PMD_LOG(ERR, "Failed to detach slave");
return -ENOTSUP;
}
 
@@ -265,7 +267,7 @@ rte_cryptodev_scheduler_slave_detach(uint8_t scheduler_id, 
uint8_t slave_id)
sched_ctx->nb_slaves--;
 
if (update_scheduler_capability(sched_ctx) < 0) {
-   CS_LOG_ERR("capabilities update failed");
+   SCHEDULER_PMD_LOG(ERR, "capabilities update failed");
return -ENOTSUP;
}
 
@@ -284,17 +286,17 @@ rte_cryptodev_scheduler_mode_set(uint8_t scheduler_id,
struct scheduler_ctx *sched_ctx;
 
if (!dev) {
-   CS_LOG_ERR("Operation not supported

[dpdk-dev] [PATCH] crypto/openssl: add dynamic logging to openssl

[Naga Suresh Somarowthu]

1.added new logtype for openssl driver.
2.registered new logtype.
3.OPENSSL_LOG_ERR and CDEV_LOG_ERR are
replaced with new logtype name OPENSSL_PMD_LOG.

Signed-off-by: Naga Suresh Somarowthu 
---
 drivers/crypto/openssl/rte_openssl_pmd.c | 40 ++--
 drivers/crypto/openssl/rte_openssl_pmd_ops.c | 14 -
 drivers/crypto/openssl/rte_openssl_pmd_private.h | 25 ---
 3 files changed, 37 insertions(+), 42 deletions(-)

diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c 
b/drivers/crypto/openssl/rte_openssl_pmd.c
index 93c6d7e5d..6a2324982 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -119,7 +119,7 @@ get_cipher_key_ede(uint8_t *key, int keylen, uint8_t 
*key_ede)
memcpy(key_ede + 16, key, 8);
break;
default:
-   OPENSSL_LOG_ERR("Unsupported key size");
+   OPENSSL_PMD_LOG(ERR, "Unsupported key size");
res = -EINVAL;
}
 
@@ -677,7 +677,7 @@ openssl_set_session_parameters(struct openssl_session *sess,
ret = openssl_set_session_cipher_parameters(
sess, cipher_xform);
if (ret != 0) {
-   OPENSSL_LOG_ERR(
+   OPENSSL_PMD_LOG(ERR,
"Invalid/unsupported cipher parameters");
return ret;
}
@@ -686,7 +686,7 @@ openssl_set_session_parameters(struct openssl_session *sess,
if (auth_xform) {
ret = openssl_set_session_auth_parameters(sess, auth_xform);
if (ret != 0) {
-   OPENSSL_LOG_ERR(
+   OPENSSL_PMD_LOG(ERR,
"Invalid/unsupported auth parameters");
return ret;
}
@@ -695,7 +695,7 @@ openssl_set_session_parameters(struct openssl_session *sess,
if (aead_xform) {
ret = openssl_set_session_aead_parameters(sess, aead_xform);
if (ret != 0) {
-   OPENSSL_LOG_ERR(
+   OPENSSL_PMD_LOG(ERR,
"Invalid/unsupported AEAD parameters");
return ret;
}
@@ -884,7 +884,7 @@ process_openssl_cipher_encrypt(struct rte_mbuf *mbuf_src, 
uint8_t *dst,
return 0;
 
 process_cipher_encrypt_err:
-   OPENSSL_LOG_ERR("Process openssl cipher encrypt failed");
+   OPENSSL_PMD_LOG(ERR, "Process openssl cipher encrypt failed");
return -EINVAL;
 }
 
@@ -908,7 +908,7 @@ process_openssl_cipher_bpi_encrypt(uint8_t *src, uint8_t 
*dst,
return 0;
 
 process_cipher_encrypt_err:
-   OPENSSL_LOG_ERR("Process openssl cipher bpi encrypt failed");
+   OPENSSL_PMD_LOG(ERR, "Process openssl cipher bpi encrypt failed");
return -EINVAL;
 }
 /** Process standard openssl cipher decryption */
@@ -932,7 +932,7 @@ process_openssl_cipher_decrypt(struct rte_mbuf *mbuf_src, 
uint8_t *dst,
return 0;
 
 process_cipher_decrypt_err:
-   OPENSSL_LOG_ERR("Process openssl cipher decrypt failed");
+   OPENSSL_PMD_LOG(ERR, "Process openssl cipher decrypt failed");
return -EINVAL;
 }
 
@@ -989,7 +989,7 @@ process_openssl_cipher_des3ctr(struct rte_mbuf *mbuf_src, 
uint8_t *dst,
return 0;
 
 process_cipher_des3ctr_err:
-   OPENSSL_LOG_ERR("Process openssl cipher des 3 ede ctr failed");
+   OPENSSL_PMD_LOG(ERR, "Process openssl cipher des 3 ede ctr failed");
return -EINVAL;
 }
 
@@ -1027,7 +1027,7 @@ process_openssl_auth_encryption_gcm(struct rte_mbuf 
*mbuf_src, int offset,
return 0;
 
 process_auth_encryption_gcm_err:
-   OPENSSL_LOG_ERR("Process openssl auth encryption gcm failed");
+   OPENSSL_PMD_LOG(ERR, "Process openssl auth encryption gcm failed");
return -EINVAL;
 }
 
@@ -1068,7 +1068,7 @@ process_openssl_auth_encryption_ccm(struct rte_mbuf 
*mbuf_src, int offset,
return 0;
 
 process_auth_encryption_ccm_err:
-   OPENSSL_LOG_ERR("Process openssl auth encryption ccm failed");
+   OPENSSL_PMD_LOG(ERR, "Process openssl auth encryption ccm failed");
return -EINVAL;
 }
 
@@ -1106,7 +1106,7 @@ process_openssl_auth_decryption_gcm(struct rte_mbuf 
*mbuf_src, int offset,
return 0;
 
 process_auth_decryption_gcm_err:
-   OPENSSL_LOG_ERR("Process openssl auth decryption gcm failed");
+   OPENSSL_PMD_LOG(ERR, "Process openssl auth decryption gcm failed");
return -EINVAL;
 }
 
@@ -1145,7 +1145,7 @@ process_openssl_auth_decryption_ccm(struct rte_mbuf 
*mbuf_src, int offset,
return 0;
 
 process_auth_decryption_ccm_err:
-   OPENSSL_LOG_ERR("Process openssl auth decryption ccm failed");
+   OPENSSL_PMD_LOG(ERR, "Process openssl auth decryption ccm failed");
return -EINVAL;
 }
 
@@ -1198,7 +1198,7 @@ process_openssl_auth(struct rte_mbuf *mbuf_src, uint