Re: [dpdk-dev] MLX5 should define the timestamp field in the doc

[Tom Barbette]

Thanks for your answer Shahaf !


We're trying to measure the latency of packets going through various service 
chains inside individual "server".  Eg. we can see that on Server 1, the 
latency for the service chain handling HTTP packets is ~800ns (+ max and mins, 
tail latency, etc). What we do now is to timestamp packets right after they are 
received, and compute the difference with the timestamp just before they are 
sent. Over a cluster this shows us where the latency is happening.


We would like this "box" latency to include the time spent in queues, and for 
that the hardware timestamp seems fit-for-purpose as it would timestamp the 
packets before the software queues. Moreover, as we use batching, we lose a lot 
of precision as we timestamp a whole batch at once.


I'm pretty sure this use case is of interest for many others. Tail latency is 
of the essence nowadays, and finding where packets get delayed precisely is 
important.

?

Instead of converting the timestamp to real time, in this very use case it 
seems the Mellanox card could actually be our unique source of time, we just 
need to be able to convert ticks to seconds.


Any chance we can run an equivalent of mlx5_read_internal_timer 
(https://elixir.bootlin.com/linux/v4.18.5/source/drivers/net/ethernet/mellanox/mlx5/core/main.c#L623)
 ?from userspace ? Are these registers also mapped, or can be done so with a 
few changes? With only that we can actually derive the frequency and the offset 
easily.?


Tom

Re: [dpdk-dev] eventdev: method for finding out unlink status

[Elo, Matias (Nokia - FI/Espoo)]

>> 
>> I'm not sure I understand the issue here.
>> Is anybody suggesting to make unlink() blocking?
>> 
>> For certain PMDs, perhaps it must be a synchronous handled unlink().
>> For other PMDs (eg event/sw) there are multiple threads involved,
>> so it must be async. Hence, APIs should be async to avoid blocking the 
>> caller.
>> 
>> With an async API, if you don't want the async behaviuor, it is
>> easy to build the sync version: call it in a loop, optionally with a delay().
> 
> Correct. My point was, rte_event_port_unlink() can be blocking as it 
> is a slow path API(does not really matter how long it waits).
> If you think, it can be called in fastpath and/or application can
> leverage some cpu cycles on completing the async call then you can add
> at the cost of new API unlinks_in_progress() and make sure to update the 
> documentation
> about unlink() that it can be async call(currently it is documented as a sync
> call).

Did you come to an agreement how to solve this issue? Any solution (e.g. make
rte_event_port_unlink() blocking with SW eventdev) would be welcomed since this
issue is currently blocking my work with eventdev.

Re: [dpdk-dev] [PATCH 1/3] net/virtio-user: fix deadlock in memory events callback

[Sean Harte]

On 5 September 2018 at 05:28, Tiwei Bie  wrote:
> Deadlock can occur when allocating memory if a vhost-kernel
> based virtio-user device is in use. To fix the deadlock,
> we will take memory hotplug lock explicitly in virtio-user
> when necessary, and always call the _thread_unsafe memory
> functions.
>
> Bugzilla ID: 81
> Fixes: 12ecb2f63b12 ("net/virtio-user: support memory hotplug")
> Cc: sta...@dpdk.org
>
> Reported-by: Seán Harte 
> Signed-off-by: Tiwei Bie 
> ---
>  drivers/net/virtio/virtio_user/vhost_kernel.c |  6 +-
>  .../net/virtio/virtio_user/virtio_user_dev.c  | 19 +++
>  2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio/virtio_user/vhost_kernel.c 
> b/drivers/net/virtio/virtio_user/vhost_kernel.c
> index b2444096c..897fee0af 100644
> --- a/drivers/net/virtio/virtio_user/vhost_kernel.c
> +++ b/drivers/net/virtio/virtio_user/vhost_kernel.c
> @@ -115,7 +115,11 @@ prepare_vhost_memory_kernel(void)
> wa.region_nr = 0;
> wa.vm = vm;
>
> -   if (rte_memseg_contig_walk(add_memory_region, &wa) < 0) {
> +   /*
> +* The memory lock has already been taken by memory subsystem
> +* or virtio_user_start_device().
> +*/
> +   if (rte_memseg_contig_walk_thread_unsafe(add_memory_region, &wa) < 0) 
> {
> free(vm);
> return NULL;
> }
> diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c 
> b/drivers/net/virtio/virtio_user/virtio_user_dev.c
> index 7df600b02..869e96f87 100644
> --- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
> +++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  #include "vhost.h"
>  #include "virtio_user_dev.h"
>  #include "../virtio_ethdev.h"
> @@ -109,9 +111,24 @@ is_vhost_user_by_type(const char *path)
>  int
>  virtio_user_start_device(struct virtio_user_dev *dev)
>  {
> +   struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
> uint64_t features;
> int ret;
>
> +   /*
> +* XXX workaround!
> +*
> +* We need to make sure that the locks will be
> +* taken in the correct order to avoid deadlocks.
> +*
> +* Before releasing this lock, this thread should
> +* not trigger any memory hotplug events.
> +*
> +* This is a temporary workaround, and should be
> +* replaced when we get proper supports from the
> +* memory subsystem in the future.
> +*/
> +   rte_rwlock_read_lock(&mcfg->memory_hotplug_lock);
> pthread_mutex_lock(&dev->mutex);
>
> if (is_vhost_user_by_type(dev->path) && dev->vhostfd < 0)
> @@ -152,10 +169,12 @@ virtio_user_start_device(struct virtio_user_dev *dev)
>
> dev->started = true;
> pthread_mutex_unlock(&dev->mutex);
> +   rte_rwlock_read_unlock(&mcfg->memory_hotplug_lock);
>
> return 0;
>  error:
> pthread_mutex_unlock(&dev->mutex);
> +   rte_rwlock_read_unlock(&mcfg->memory_hotplug_lock);
> /* TODO: free resource here or caller to check */
> return -1;
>  }
> --
> 2.18.0
>

Tested-by: Seán Harte 
Reviewed-by: Seán Harte 

Re: [dpdk-dev] MLX5 should define the timestamp field in the doc

[Shahaf Shuler]

Thanks for the details.

The use case is clear. We will take it internally to see when we can support it.
AFAIK we cannot read the internal time from userspace.

Adding also AlexR to comment

From: Tom Barbette 
Sent: Wednesday, September 5, 2018 10:11 AM
To: Shahaf Shuler ; dev@dpdk.org
Cc: Yongseok Koh ; john.mcnam...@intel.com; 
marko.kovace...@intel.com
Subject: RE: MLX5 should define the timestamp field in the doc


Thanks for your answer Shahaf !



We're trying to measure the latency of packets going through various service 
chains inside individual "server".  Eg. we can see that on Server 1, the 
latency for the service chain handling HTTP packets is ~800ns (+ max and mins, 
tail latency, etc). What we do now is to timestamp packets right after they are 
received, and compute the difference with the timestamp just before they are 
sent. Over a cluster this shows us where the latency is happening.



We would like this "box" latency to include the time spent in queues, and for 
that the hardware timestamp seems fit-for-purpose as it would timestamp the 
packets before the software queues. Moreover, as we use batching, we lose a lot 
of precision as we timestamp a whole batch at once.



I'm pretty sure this use case is of interest for many others. Tail latency is 
of the essence nowadays, and finding where packets get delayed precisely is 
important.

​

Instead of converting the timestamp to real time, in this very use case it 
seems the Mellanox card could actually be our unique source of time, we just 
need to be able to convert ticks to seconds.



Any chance we can run an equivalent of mlx5_read_internal_timer 
(https://elixir.bootlin.com/linux/v4.18.5/source/drivers/net/ethernet/mellanox/mlx5/core/main.c#L623)
 ​from userspace ? Are these registers also mapped, or can be done so with a 
few changes? With only that we can actually derive the frequency and the offset 
easily.​



Tom

Re: [dpdk-dev] [PATCH v2 3/4] app/test-eventdev: add Tx adapter support

[Pavan Nikhilesh]

On Wed, Sep 05, 2018 at 12:24:18PM +0530, Rao, Nikhil wrote:
> On 9/4/2018 7:42 PM, Pavan Nikhilesh wrote:
> > Convert existing Tx service based pipeline to Tx adapter based APIs and
> > simplify worker functions.
> >
> > Signed-off-by: Pavan Nikhilesh 
> > ---
> >   app/test-eventdev/test_pipeline_atq.c| 269 ---
> >   app/test-eventdev/test_pipeline_common.c | 206 +
> >   app/test-eventdev/test_pipeline_common.h |  62 +++---
> >   app/test-eventdev/test_pipeline_queue.c  | 241 ++--
> >   4 files changed, 367 insertions(+), 411 deletions(-)
> >
> > diff --git a/app/test-eventdev/test_pipeline_common.c 
> > b/app/test-eventdev/test_pipeline_common.c
> > index 832ab8b6e..ab407dbbb 100644
> > --- a/app/test-eventdev/test_pipeline_common.c
> > +++ b/app/test-eventdev/test_pipeline_common.c
> > @@ -5,58 +5,6 @@
> >
> >
> > @@ -215,7 +160,6 @@ pipeline_ethdev_setup(struct evt_test *test, struct 
> > evt_options *opt)
> >   {
> >   uint16_t i;
> >   uint8_t nb_queues = 1;
> > - uint8_t mt_state = 0;
> >   struct test_pipeline *t = evt_test_priv(test);
> >   struct rte_eth_rxconf rx_conf;
> >   struct rte_eth_conf port_conf = {
> > @@ -238,13 +182,21 @@ pipeline_ethdev_setup(struct evt_test *test, struct 
> > evt_options *opt)
> >   return -ENODEV;
> >   }
> >
> > + t->internal_port = 0;
> >   RTE_ETH_FOREACH_DEV(i) {
> >   struct rte_eth_dev_info dev_info;
> >   struct rte_eth_conf local_port_conf = port_conf;
> > + uint32_t caps = 0;
> > +
> > + rte_event_eth_tx_adapter_caps_get(opt->dev_id, i, &caps);
> > + if ((caps & RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT)) {
> > + t->internal_port = 1;
> > + } else if (t->internal_port == 1) {
> > + evt_err("Eventdev can't use %d port", i);
> > + return -EINVAL;
> > + }
> >
> Shouldn't this function also return -EINVAL for the case where
> internal_port = 0 for i = 0, and internal_port = 1 for i = 1 ?

I think it would be better to force all the ports to use the non-internal cap
mode when we detect that one of the port doesn't have internal port capability
rather than exiting. This was the behaviour previously it will leave room to
support both the pipeline models in future.

>
> Nikhil
>

Thanks,
Pavan.

Re: [dpdk-dev] MLX5 should define the timestamp field in the doc

[Tom Barbette]

Actually I managed this patch to implement support for 
rte_eth_timesync_read_time.


Please tell me potential modifications, and if I shall submit it again as a 
"normal" patch to dev ?


---
 drivers/net/mlx5/mlx5.c|  1 +
 drivers/net/mlx5/mlx5.h|  1 +
 drivers/net/mlx5/mlx5_ethdev.c | 30 ++
 drivers/net/mlx5/mlx5_glue.c   |  8 
 drivers/net/mlx5/mlx5_glue.h   |  2 ++
 5 files changed, 42 insertions(+)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index c933e27..8c34794 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -324,6 +324,7 @@ const struct eth_dev_ops mlx5_dev_ops = {
  .xstats_reset = mlx5_xstats_reset,
  .xstats_get_names = mlx5_xstats_get_names,
  .dev_infos_get = mlx5_dev_infos_get,
+ .timesync_read_time = mlx5_timesync_read_time,
  .dev_supported_ptypes_get = mlx5_dev_supported_ptypes_get,
  .vlan_filter_set = mlx5_vlan_filter_set,
  .rx_queue_setup = mlx5_rx_queue_setup,
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 997b04a..5747304 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -217,6 +217,7 @@ int mlx5_set_flags(struct rte_eth_dev *dev, unsigned int 
keep,
 unsigned int flags);
 int mlx5_dev_configure(struct rte_eth_dev *dev);
 void mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info 
*info);
+int mlx5_timesync_read_time(struct rte_eth_dev *dev, struct timespec* time);
 const uint32_t *mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev);
 int mlx5_link_update(struct rte_eth_dev *dev, int wait_to_complete);
 int mlx5_force_link_status_change(struct rte_eth_dev *dev, int status);
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 90488af..b7f0d91 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -480,6 +480,36 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
 }

 /**
+ * Get device current time
+ *
+ * @param dev
+ *   Pointer to Ethernet device structure.
+ *
+ * @param[out] time
+ *   Time output value.
+ *
+ * @return
+ *   0 if the time has correctly been set
+ */
+int
+mlx5_timesync_read_time(struct rte_eth_dev *dev, struct timespec *time)
+{
+struct priv *priv = dev->data->dev_private;
+struct ibv_values_ex values;
+int err = 0;
+
+values.comp_mask = IBV_VALUES_MASK_RAW_CLOCK;
+if ((err = mlx5_glue->query_rt_values_ex(priv->ctx, &values)) != 0) {
+ DRV_LOG(WARNING, "Could not query time !");
+return err;
+}
+
+*time = values.raw_clock;
+return 0;
+}
+
+
+/**
  * Get supported packet types.
  *
  * @param dev
diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c
index c7965e5..3c72f5b 100644
--- a/drivers/net/mlx5/mlx5_glue.c
+++ b/drivers/net/mlx5/mlx5_glue.c
@@ -84,6 +84,13 @@ mlx5_glue_query_device_ex(struct ibv_context *context,
 }

 static int
+mlx5_glue_query_rt_values_ex(struct ibv_context *context,
+   struct ibv_values_ex* values)
+{
+ return ibv_query_rt_values_ex(context, values);
+}
+
+static int
 mlx5_glue_query_port(struct ibv_context *context, uint8_t port_num,
   struct ibv_port_attr *port_attr)
 {
@@ -354,6 +361,7 @@ const struct mlx5_glue *mlx5_glue = &(const struct 
mlx5_glue){
  .close_device = mlx5_glue_close_device,
  .query_device = mlx5_glue_query_device,
  .query_device_ex = mlx5_glue_query_device_ex,
+ .query_rt_values_ex = mlx5_glue_query_rt_values_ex,
  .query_port = mlx5_glue_query_port,
  .create_comp_channel = mlx5_glue_create_comp_channel,
  .destroy_comp_channel = mlx5_glue_destroy_comp_channel,
diff --git a/drivers/net/mlx5/mlx5_glue.h b/drivers/net/mlx5/mlx5_glue.h
index e584d36..0582e95 100644
--- a/drivers/net/mlx5/mlx5_glue.h
+++ b/drivers/net/mlx5/mlx5_glue.h
@@ -54,6 +54,8 @@ struct mlx5_glue {
  int (*query_device_ex)(struct ibv_context *context,
 const struct ibv_query_device_ex_input *input,
 struct ibv_device_attr_ex *attr);
+ int (*query_rt_values_ex)(struct ibv_context *context,
+struct ibv_values_ex *values);
  int (*query_port)(struct ibv_context *context, uint8_t port_num,
struct ibv_port_attr *port_attr);
  struct ibv_comp_channel *(*create_comp_channel)
--
2.7.4






De : Shahaf Shuler 
Envoyé : mercredi 5 septembre 2018 10:18
À : Tom Barbette; dev@dpdk.org; Alex Rosenbaum
Cc : Yongseok Koh; john.mcnam...@intel.com; marko.kovace...@intel.com
Objet : RE: MLX5 should define the timestamp field in the doc

Thanks for the details.

The use case is clear. We will take it internally to see when we can support it.
AFAIK we cannot read the internal time from userspace.

Adding also AlexR to comment

From: Tom Barbette 
Sent: Wednesday, September 5, 2018 10:11 AM
To: Shahaf Shuler ; dev@dpdk.org
Cc: Yongseok Koh ; john.mcnam...@intel.com; 
marko.kovace...@intel.com
Subject: RE: MLX5 should define the timestamp field in the doc


Thanks for your answer Shahaf !



We're tr

[dpdk-dev] [PATCH 2/2] net/bonding: inherit descriptor limits from slaves

[Andrew Rybchenko]

From: Ivan Malov 

Descriptor limits are used by applications to take
optimal decisions on queue sizing.

Signed-off-by: Ivan Malov 
Signed-off-by: Andrew Rybchenko 
---
 drivers/net/bonding/rte_eth_bond_api.c | 54 ++
 drivers/net/bonding/rte_eth_bond_pmd.c |  8 
 drivers/net/bonding/rte_eth_bond_private.h |  2 +
 3 files changed, 64 insertions(+)

diff --git a/drivers/net/bonding/rte_eth_bond_api.c 
b/drivers/net/bonding/rte_eth_bond_api.c
index 206a5c797..9e039e73b 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -399,6 +399,43 @@ eth_bond_slave_inherit_dev_info_tx_next(struct 
bond_dev_private *internals,
 internals->tx_queue_offload_capa;
 }
 
+static void
+eth_bond_slave_inherit_desc_lim_first(struct rte_eth_desc_lim *bond_desc_lim,
+   const struct rte_eth_desc_lim *slave_desc_lim)
+{
+   memcpy(bond_desc_lim, slave_desc_lim, sizeof(*bond_desc_lim));
+}
+
+static int
+eth_bond_slave_inherit_desc_lim_next(struct rte_eth_desc_lim *bond_desc_lim,
+   const struct rte_eth_desc_lim *slave_desc_lim)
+{
+   bond_desc_lim->nb_max = RTE_MIN(bond_desc_lim->nb_max,
+   slave_desc_lim->nb_max);
+   bond_desc_lim->nb_min = RTE_MAX(bond_desc_lim->nb_min,
+   slave_desc_lim->nb_min);
+   bond_desc_lim->nb_align = RTE_MAX(bond_desc_lim->nb_align,
+ slave_desc_lim->nb_align);
+
+   if (bond_desc_lim->nb_min > bond_desc_lim->nb_max ||
+   bond_desc_lim->nb_align > bond_desc_lim->nb_max) {
+   RTE_BOND_LOG(ERR, "Failed to inherit descriptor limits");
+   return -EINVAL;
+   }
+
+   /* Treat maximum number of segments equal to 0 as unspecified */
+   if (slave_desc_lim->nb_seg_max != 0 &&
+   (bond_desc_lim->nb_seg_max == 0 ||
+slave_desc_lim->nb_seg_max < bond_desc_lim->nb_seg_max))
+   bond_desc_lim->nb_seg_max = slave_desc_lim->nb_seg_max;
+   if (slave_desc_lim->nb_mtu_seg_max != 0 &&
+   (bond_desc_lim->nb_mtu_seg_max == 0 ||
+slave_desc_lim->nb_mtu_seg_max < bond_desc_lim->nb_mtu_seg_max))
+   bond_desc_lim->nb_mtu_seg_max = slave_desc_lim->nb_mtu_seg_max;
+
+   return 0;
+}
+
 static int
 __eth_bond_slave_add_lock_free(uint16_t bonded_port_id, uint16_t slave_port_id)
 {
@@ -458,9 +495,26 @@ __eth_bond_slave_add_lock_free(uint16_t bonded_port_id, 
uint16_t slave_port_id)
 
eth_bond_slave_inherit_dev_info_rx_first(internals, &dev_info);
eth_bond_slave_inherit_dev_info_tx_first(internals, &dev_info);
+
+   eth_bond_slave_inherit_desc_lim_first(&internals->rx_desc_lim,
+ &dev_info.rx_desc_lim);
+   eth_bond_slave_inherit_desc_lim_first(&internals->tx_desc_lim,
+ &dev_info.tx_desc_lim);
} else {
+   int ret;
+
eth_bond_slave_inherit_dev_info_rx_next(internals, &dev_info);
eth_bond_slave_inherit_dev_info_tx_next(internals, &dev_info);
+
+   ret = eth_bond_slave_inherit_desc_lim_next(
+   &internals->rx_desc_lim, &dev_info.rx_desc_lim);
+   if (ret != 0)
+   return ret;
+
+   ret = eth_bond_slave_inherit_desc_lim_next(
+   &internals->tx_desc_lim, &dev_info.tx_desc_lim);
+   if (ret != 0)
+   return ret;
}
 
bonded_eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf &=
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
b/drivers/net/bonding/rte_eth_bond_pmd.c
index ee24e9658..46b660396 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2239,6 +2239,11 @@ bond_ethdev_info(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
memcpy(&dev_info->default_txconf, &internals->default_txconf,
   sizeof(dev_info->default_txconf));
 
+   memcpy(&dev_info->rx_desc_lim, &internals->rx_desc_lim,
+  sizeof(dev_info->rx_desc_lim));
+   memcpy(&dev_info->tx_desc_lim, &internals->tx_desc_lim,
+  sizeof(dev_info->tx_desc_lim));
+
/**
 * If dedicated hw queues enabled for link bonding device in LACP mode
 * then we need to reduce the maximum number of data path queues by 1.
@@ -3064,6 +3069,9 @@ bond_alloc(struct rte_vdev_device *dev, uint8_t mode)
memset(&internals->default_txconf, 0,
   sizeof(internals->default_txconf));
 
+   memset(&internals->rx_desc_lim, 0, sizeof(internals->rx_desc_lim));
+   memset(&internals->tx_desc_lim, 0, sizeof(internals->tx_desc_lim));
+
memset(internals->active_slaves, 0, sizeof(internals->active_s

[dpdk-dev] [PATCH 1/2] net/bonding: provide default Rx/Tx configuration

[Andrew Rybchenko]

From: Ivan Malov 

Default Rx/Tx configuration has become a helpful
resource for applications relying on the optimal
values to make rte_eth_rxconf and rte_eth_txconf
structures. These structures can then be tweaked.

Default configuration is also used internally by
rte_eth_rx_queue_setup or rte_eth_tx_queue_setup
API calls when NULL pointer is passed by callers
with the argument for custom queue configuration.

The use cases of bonding driver may also benefit
from exercising default settings in the same way.

Restructure the code to collect various settings
from slave ports and make it possible to combine
default Rx/Tx configuration of these devices and
report it to the callers of rte_eth_dev_info_get.

Signed-off-by: Ivan Malov 
Signed-off-by: Andrew Rybchenko 
---
 drivers/net/bonding/rte_eth_bond_api.c | 161 +
 drivers/net/bonding/rte_eth_bond_pmd.c |  10 ++
 drivers/net/bonding/rte_eth_bond_private.h |   3 +
 3 files changed, 147 insertions(+), 27 deletions(-)

diff --git a/drivers/net/bonding/rte_eth_bond_api.c 
b/drivers/net/bonding/rte_eth_bond_api.c
index 8bc04cfd1..206a5c797 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -269,6 +269,136 @@ slave_rte_flow_prepare(uint16_t slave_id, struct 
bond_dev_private *internals)
return 0;
 }
 
+static void
+eth_bond_slave_inherit_dev_info_rx_first(struct bond_dev_private *internals,
+const struct rte_eth_dev_info *di)
+{
+   struct rte_eth_rxconf *rxconf_i = &internals->default_rxconf;
+
+   internals->reta_size = di->reta_size;
+
+   /* Inherit Rx offload capabilities from the first slave device */
+   internals->rx_offload_capa = di->rx_offload_capa;
+   internals->rx_queue_offload_capa = di->rx_queue_offload_capa;
+   internals->flow_type_rss_offloads = di->flow_type_rss_offloads;
+
+   /* Inherit maximum Rx packet size from the first slave device */
+   internals->candidate_max_rx_pktlen = di->max_rx_pktlen;
+
+   /* Inherit default Rx queue settings from the first slave device */
+   memcpy(rxconf_i, &di->default_rxconf, sizeof(*rxconf_i));
+
+   /*
+* Turn off descriptor prefetch and writeback by default for all
+* slave devices. Applications may tweak this setting if need be.
+*/
+   rxconf_i->rx_thresh.pthresh = 0;
+   rxconf_i->rx_thresh.hthresh = 0;
+   rxconf_i->rx_thresh.wthresh = 0;
+
+   /* Setting this to zero should effectively enable default values */
+   rxconf_i->rx_free_thresh = 0;
+
+   /* Disable deferred start by default for all slave devices */
+   rxconf_i->rx_deferred_start = 0;
+}
+
+static void
+eth_bond_slave_inherit_dev_info_tx_first(struct bond_dev_private *internals,
+const struct rte_eth_dev_info *di)
+{
+   struct rte_eth_txconf *txconf_i = &internals->default_txconf;
+
+   /* Inherit Tx offload capabilities from the first slave device */
+   internals->tx_offload_capa = di->tx_offload_capa;
+   internals->tx_queue_offload_capa = di->tx_queue_offload_capa;
+
+   /* Inherit default Tx queue settings from the first slave device */
+   memcpy(txconf_i, &di->default_txconf, sizeof(*txconf_i));
+
+   /*
+* Turn off descriptor prefetch and writeback by default for all
+* slave devices. Applications may tweak this setting if need be.
+*/
+   txconf_i->tx_thresh.pthresh = 0;
+   txconf_i->tx_thresh.hthresh = 0;
+   txconf_i->tx_thresh.wthresh = 0;
+
+   /*
+* Setting these parameters to zero assumes that default
+* values will be configured implicitly by slave devices.
+*/
+   txconf_i->tx_free_thresh = 0;
+   txconf_i->tx_rs_thresh = 0;
+
+   /* Disable deferred start by default for all slave devices */
+   txconf_i->tx_deferred_start = 0;
+}
+
+static void
+eth_bond_slave_inherit_dev_info_rx_next(struct bond_dev_private *internals,
+   const struct rte_eth_dev_info *di)
+{
+   struct rte_eth_rxconf *rxconf_i = &internals->default_rxconf;
+   const struct rte_eth_rxconf *rxconf = &di->default_rxconf;
+
+   internals->rx_offload_capa &= di->rx_offload_capa;
+   internals->rx_queue_offload_capa &= di->rx_queue_offload_capa;
+   internals->flow_type_rss_offloads &= di->flow_type_rss_offloads;
+
+   /*
+* If at least one slave device suggests enabling this
+* setting by default, enable it for all slave devices
+* since disabling it may not be necessarily supported.
+*/
+   if (rxconf->rx_drop_en == 1)
+   rxconf_i->rx_drop_en = 1;
+
+   /*
+* Adding a new slave device may cause some of previously inherited
+* offloads to be withdrawn from the internal rx_queue_offload_capa
+* value. Thus, the new internal value of default Rx queue offloa

Re: [dpdk-dev] [PATCH] doc: Clarify IOMMU usage with "uio-pci" kernel module

[Stephen Hemminger]

On Wed, 5 Sep 2018 00:20:29 +
"Tone Zhang (Arm Technology China)"  wrote:

> Hi Rami,
> 
> Yes, I mean “uio_pci_generic” kernel module.
> 
> I will update the change accordingly.
> 
> Thanks.
> 
> Br,
> Tone
> 
> From: Rami Rosen 
> Sent: Wednesday, September 5, 2018 3:55 AM
> To: Tone Zhang (Arm Technology China) 
> Cc: dev@dpdk.org; nd 
> Subject: Re: [dpdk-dev] [PATCH] doc: Clarify IOMMU usage with "uio-pci" 
> kernel module
> 
> Hi Tone,
> >if the devices for used DPDK bound to the ``uio-pci`` kernel module, please 
> >make  
> 
> The three kernel modules which can be used for DPDK binding are vfio-pci, 
> uio_pci_generic and igb_uio. Don't you mean here uio_pci_generic ?
> 
> Regards,
> Rami Rosen
> 
> 
> בתאריך יום ג׳, 4 בספט׳ 2018, 11:59, מאת tone.z
> When binding the devices used by DPDK to the "uio-pci" kernel module,
> the IOMMU should be disabled in order not to break the
> because of the virtual / physical address mapping.
> 
> The patch clarifies the IOMMU configuration on both x86_64 and arm64
> systems.
> 
> Signed-off-by: tone.zhang mailto:tone.zh...@arm.com>>
> ---
>  doc/guides/linux_gsg/linux_drivers.rst | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
> b/doc/guides/linux_gsg/linux_drivers.rst
> index 371a817..8f9ec8f 100644
> --- a/doc/guides/linux_gsg/linux_drivers.rst
> +++ b/doc/guides/linux_gsg/linux_drivers.rst
> @@ -48,6 +48,13 @@ be loaded as shown below:
> ``vfio-pci``
> 2.7.4

Also, it would be good if documentation was clear in recommending using VFIO
instead if IOMMU is present.

Re: [dpdk-dev] [PATCH v2 3/4] app/test-eventdev: add Tx adapter support

[Rao, Nikhil]

On 9/5/2018 2:24 PM, Pavan Nikhilesh wrote:

On Wed, Sep 05, 2018 at 12:24:18PM +0530, Rao, Nikhil wrote:

On 9/4/2018 7:42 PM, Pavan Nikhilesh wrote:

Convert existing Tx service based pipeline to Tx adapter based APIs and
simplify worker functions.

Signed-off-by: Pavan Nikhilesh 
---
   app/test-eventdev/test_pipeline_atq.c| 269 ---
   app/test-eventdev/test_pipeline_common.c | 206 +
   app/test-eventdev/test_pipeline_common.h |  62 +++---
   app/test-eventdev/test_pipeline_queue.c  | 241 ++--
   4 files changed, 367 insertions(+), 411 deletions(-)

diff --git a/app/test-eventdev/test_pipeline_common.c 
b/app/test-eventdev/test_pipeline_common.c
index 832ab8b6e..ab407dbbb 100644
--- a/app/test-eventdev/test_pipeline_common.c
+++ b/app/test-eventdev/test_pipeline_common.c
@@ -5,58 +5,6 @@


@@ -215,7 +160,6 @@ pipeline_ethdev_setup(struct evt_test *test, struct 
evt_options *opt)
   {
   uint16_t i;
   uint8_t nb_queues = 1;
- uint8_t mt_state = 0;
   struct test_pipeline *t = evt_test_priv(test);
   struct rte_eth_rxconf rx_conf;
   struct rte_eth_conf port_conf = {
@@ -238,13 +182,21 @@ pipeline_ethdev_setup(struct evt_test *test, struct 
evt_options *opt)
   return -ENODEV;
   }

+ t->internal_port = 0;
   RTE_ETH_FOREACH_DEV(i) {
   struct rte_eth_dev_info dev_info;
   struct rte_eth_conf local_port_conf = port_conf;
+ uint32_t caps = 0;
+
+ rte_event_eth_tx_adapter_caps_get(opt->dev_id, i, &caps);
+ if ((caps & RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT)) {
+ t->internal_port = 1;
+ } else if (t->internal_port == 1) {
+ evt_err("Eventdev can't use %d port", i);
+ return -EINVAL;
+ }


Shouldn't this function also return -EINVAL for the case where
internal_port = 0 for i = 0, and internal_port = 1 for i = 1 ?


I think it would be better to force all the ports to use the non-internal cap
mode when we detect that one of the port doesn't have internal port capability
rather than exiting. This was the behaviour previously it will leave room to
support both the pipeline models in future.


Agreed.

Nikhil

[dpdk-dev] [PATCH] test/event: remove RSS config in eth Rx adapter test

[Nikhil Rao]

Remove RSS config as it is not required (this also fixes an
error with a hardcoded RSS config not supported by the NIC)

Signed-off-by: Nikhil Rao 
Fixes: 8863a1fbfc66 ("ethdev: add supported hash function check")
CC: sta...@dpdk.org
---
 test/test/test_event_eth_rx_adapter.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/test/test/test_event_eth_rx_adapter.c 
b/test/test/test_event_eth_rx_adapter.c
index 2337e54..4cca77f 100644
--- a/test/test/test_event_eth_rx_adapter.c
+++ b/test/test/test_event_eth_rx_adapter.c
@@ -117,13 +117,6 @@ struct event_eth_rx_adapter_test_params {
.mq_mode = ETH_MQ_RX_RSS,
.max_rx_pkt_len = ETHER_MAX_LEN
},
-   .rx_adv_conf = {
-   .rss_conf = {
-   .rss_hf = ETH_RSS_IP |
-   ETH_RSS_TCP |
-   ETH_RSS_UDP,
-   }
-   }
};
 
return port_init_common(port, &port_conf_default, mp);
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH] doc: Clarify IOMMU usage with "uio-pci" kernel module

[Tone Zhang (Arm Technology China)]

-Original Message-
From: Stephen Hemminger  
Sent: Wednesday, September 5, 2018 5:22 PM
To: Tone Zhang (Arm Technology China) 
Cc: Rami Rosen ; dev@dpdk.org; nd 
Subject: Re: [dpdk-dev] [PATCH] doc: Clarify IOMMU usage with "uio-pci" kernel 
module

On Wed, 5 Sep 2018 00:20:29 +
"Tone Zhang (Arm Technology China)"  wrote:

> Hi Rami,
> 
> Yes, I mean “uio_pci_generic” kernel module.
> 
> I will update the change accordingly.
> 
> Thanks.
> 
> Br,
> Tone
> 
> From: Rami Rosen 
> Sent: Wednesday, September 5, 2018 3:55 AM
> To: Tone Zhang (Arm Technology China) 
> Cc: dev@dpdk.org; nd 
> Subject: Re: [dpdk-dev] [PATCH] doc: Clarify IOMMU usage with "uio-pci" 
> kernel module
> 
> Hi Tone,
> >if the devices for used DPDK bound to the ``uio-pci`` kernel module, please 
> >make  
> 
> The three kernel modules which can be used for DPDK binding are vfio-pci, 
> uio_pci_generic and igb_uio. Don't you mean here uio_pci_generic ?
> 
> Regards,
> Rami Rosen
> 
> 
> בתאריך יום ג׳, 4 בספט׳ 2018, 11:59, מאת tone.z
> When binding the devices used by DPDK to the "uio-pci" kernel module,
> the IOMMU should be disabled in order not to break the
> because of the virtual / physical address mapping.
> 
> The patch clarifies the IOMMU configuration on both x86_64 and arm64
> systems.
> 
> Signed-off-by: tone.zhang mailto:tone.zh...@arm.com>>
> ---
>  doc/guides/linux_gsg/linux_drivers.rst | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/doc/guides/linux_gsg/linux_drivers.rst 
> b/doc/guides/linux_gsg/linux_drivers.rst
> index 371a817..8f9ec8f 100644
> --- a/doc/guides/linux_gsg/linux_drivers.rst
> +++ b/doc/guides/linux_gsg/linux_drivers.rst
> @@ -48,6 +48,13 @@ be loaded as shown below:
> ``vfio-pci``
> 2.7.4

Also, it would be good if documentation was clear in recommending using VFIO
instead if IOMMU is present.

Hi Stephen,

Yes, according to the description of the "UIO" and "VFIO" in the document, I 
believe that VFIO is recommended.

BTW, I have update the change to V3 (https://patches.dpdk.org/patch/44295/). 
Please have a review.

Thanks a lot!

Br,
Tone

Re: [dpdk-dev] [PATCH 1/5] qat: remove redundant C register keyword

[Jozwiak, TomaszX]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen
> Hemminger
> Sent: Tuesday, July 31, 2018 6:31 PM
> To: dev@dpdk.org
> Cc: Stephen Hemminger 
> Subject: [dpdk-dev] [PATCH 1/5] qat: remove redundant C register keyword
> 
> Modern C compilers ignore the register keyword and do automatic register
> assignment.
> 
> Signed-off-by: Stephen Hemminger 

Acked-by: Tomasz Jozwiak 

[dpdk-dev] [PATCH v5] net/mlx: add meson build support

[Shahaf Shuler]

From: Nelio Laranjeiro 

Compile Mellanox drivers when their external dependencies are met.  A
glue version of the driver can still be requested by using the
-Denable_driver_mlx_glue=true

To avoid modifying the whole sources and keep the compatibility with
current build systems (e.g. make), the mlx{4,5}_autoconf.h is still
generated.

Meson will try to find the required external libraries.  When they are
not installed system wide, they can be provided though CFLAGS, LDFLAGS
and LD_LIBRARY_PATH environment variables, example (considering
RDMA-Core is installed in /tmp/rdma-core):

 # CLFAGS=-I/tmp/rdma-core/build/include \
   LDFLAGS=-L/tmp/rdma-core/build/lib \
   LD_LIBRARY_PATH=/tmp/rdma-core/build/lib \
   meson output
 # LD_LIBRARY_PATH=/tmp/rdma-core/build/lib \
   ninja -C output install

Note: LD_LIBRARY_PATH before ninja is necessary when the meson
configuration has changed (e.g. meson configure has been called), in
such situation the LD_LIBRARY_PATH is necessary to invoke the
autoconfiguration script.

Signed-off-by: Nelio Laranjeiro 
Signed-off-by: Shahaf Shuler 
Acked-by: Bruce Richardson 
---
Changes in v5:

- use meson tool to generate Mellanox config file instead of DPDK custom 
scripts.

Changes in v4:

- remove implicit -Wall flag (set by default by meson),
- add item information in the autoconfiguration failure error message,
- reword the help for the glue library option,

Changes in v3:

Sanitize the build files:
- remove enable_driver_mlx{4,5} options,
- test cflags capabilities before using them,
- remove old autoconfiguration file,
- use an array for autoconfiguration and put them in the build directory,
- use dependencies in shared_library for link arguments.

Changes in v2:

- dropped patch https://patches.dpdk.org/patch/43897/
- remove extra_{cflags,ldflags} as already honored by meson through
environment variables.
---
 drivers/net/meson.build  |   2 +
 drivers/net/mlx4/meson.build | 110 +
 drivers/net/mlx5/meson.build | 231 +++
 meson_options.txt|   2 +
 4 files changed, 345 insertions(+)
 create mode 100644 drivers/net/mlx4/meson.build
 create mode 100644 drivers/net/mlx5/meson.build

diff --git a/drivers/net/meson.build b/drivers/net/meson.build
index 9c28ed4da4..c7a2d0e7db 100644
--- a/drivers/net/meson.build
+++ b/drivers/net/meson.build
@@ -18,6 +18,8 @@ drivers = ['af_packet',
'ixgbe',
'kni',
'liquidio',
+   'mlx4',
+   'mlx5',
'mvpp2',
'netvsc',
'nfp',
diff --git a/drivers/net/mlx4/meson.build b/drivers/net/mlx4/meson.build
new file mode 100644
index 00..e552d7b0c2
--- /dev/null
+++ b/drivers/net/mlx4/meson.build
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2018 6WIND S.A.
+# Copyright 2018 Mellanox Technologies, Ltd
+
+pmd_dlopen = get_option('enable_driver_mlx_glue')
+LIB_GLUE_BASE = 'librte_pmd_mlx4_glue.so'
+LIB_GLUE_VERSION = '18.02.0'
+LIB_GLUE = LIB_GLUE_BASE + '.' + LIB_GLUE_VERSION
+if pmd_dlopen
+dpdk_conf.set('RTE_LIBRTE_MLX4_DLOPEN_DEPS', 1)
+cflags += [
+'-DMLX4_GLUE="@0@"'.format(LIB_GLUE),
+'-DMLX4_GLUE_VERSION="@0@"'.format(LIB_GLUE_VERSION),
+]
+endif
+libs = [
+cc.find_library('mnl', required:false),
+cc.find_library('mlx4', required:false),
+cc.find_library('ibverbs', required:false),
+]
+build = true
+foreach lib:libs
+if not lib.found()
+build = false
+endif
+endforeach
+# Compile PMD
+if build
+allow_experimental_apis = true
+ext_deps += libs
+sources = files(
+   'mlx4.c',
+   'mlx4_ethdev.c',
+   'mlx4_flow.c',
+   'mlx4_intr.c',
+   'mlx4_mr.c',
+   'mlx4_rxq.c',
+   'mlx4_rxtx.c',
+   'mlx4_txq.c',
+   'mlx4_utils.c',
+)
+if not pmd_dlopen
+sources += files('mlx4_glue.c')
+endif
+cflags_options = [
+'-Wextra',
+'-std=c11',
+'-Wno-strict-prototypes',
+'-D_BSD_SOURCE',
+'-D_DEFAULT_SOURCE',
+'-D_XOPEN_SOURCE=600'
+]
+foreach option:cflags_options
+if cc.has_argument(option)
+cflags += option
+endif
+endforeach
+if get_option('buildtype').contains('debug')
+cflags += [ '-pedantic', '-UNDEBUG', '-DPEDANTIC' ]
+else
+cflags += [ '-DNDEBUG', '-UPEDANTIC' ]
+endif
+# To maintain the compatibility with the make build system
+# mlx4_autoconf.h file is still generated.
+# input array for meson symbol search:
+# [ "MACRO to define if found", "header for the search",
+#   "type/enum/define", "symbol to search",
+#   "struct member to 

[dpdk-dev] Change in binary name w/ meson build

[Shahaf Shuler]

Hi Bruce,

Playing w/ meson build I got to know that the binary name for testpmd got 
changed to dpdk-testpmd.

Not sure if it was discussed or not before, but such change will affect all the 
automation used to run testpmd w/ the old build system.

What is the reason for the change in the name?

[dpdk-dev] [PATCH] test/event: fix eth Rx adapter autotest for skeleton PMD

[Nikhil Rao]

skeleton PMD does not support
RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ and
implicit_release_disable so make the Rx queue_id = -1 and
initialize the event port configuration to zero.

Fixes: ec36d881f56d ("eventdev: add implicit release disable capability")
Fixes: 2a9c83ae3b2e ("test/eventdev: add multi-ports test")
Cc: vipin.vargh...@intel.com
CC: sta...@dpdk.org
Signed-off-by: Nikhil Rao 
---
 test/test/test_event_eth_rx_adapter.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/test/test_event_eth_rx_adapter.c 
b/test/test/test_event_eth_rx_adapter.c
index 2337e54..29d0ff5 100644
--- a/test/test/test_event_eth_rx_adapter.c
+++ b/test/test/test_event_eth_rx_adapter.c
@@ -317,7 +317,7 @@ struct event_eth_rx_adapter_test_params {
 {
int err;
struct rte_event_dev_info dev_info;
-   struct rte_event_port_conf rx_p_conf;
+   struct rte_event_port_conf rx_p_conf = {0};
 
err = rte_event_dev_info_get(TEST_DEV_ID, &dev_info);
TEST_ASSERT(err == 0, "Expected 0 got %d", err);
@@ -503,7 +503,7 @@ struct event_eth_rx_adapter_test_params {
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,
+   port_index, -1,
&queue_config);
TEST_ASSERT(err == 0, "Expected 0 got %d", err);
}
@@ -512,7 +512,7 @@ struct event_eth_rx_adapter_test_params {
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);
+   port_index, -1);
TEST_ASSERT(err == 0, "Expected 0 got %d", err);
}
 
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v3] net/i40e: add interface to choose latest vector path

[Zhang, Qi Z]

Hi Xiaoyun:

> -Original Message-
> From: Li, Xiaoyun
> Sent: Tuesday, September 4, 2018 7:40 PM
> To: Xing, Beilei ; Zhang, Qi Z 
> Cc: dev@dpdk.org; Yang, Zhiyong ; Richardson,
> Bruce ; Hunt, David ; Li,
> Xiaoyun 
> Subject: [PATCH v3] net/i40e: add interface to choose latest vector path
> 
> Right now, vector path is limited to only use on later platform.
> This patch adds a devarg enable-latest-vec to allow the users to use the 
> latest
> vector path that the platform supported. Namely, using AVX2 vector path on
> broadwell is possible.
> 
> Signed-off-by: Xiaoyun Li 
> ---
> v3:
>  * Polish the doc and commit log.
> v2:
>  * Correct the calling of the wrong function last time.
>  * Fix seg fault bug.
> 
>  doc/guides/nics/i40e.rst   |  8 ++
>  doc/guides/rel_notes/release_18_11.rst |  4 +++
>  drivers/net/i40e/i40e_ethdev.c | 38
> ++
>  drivers/net/i40e/i40e_ethdev.h |  1 +
>  drivers/net/i40e/i40e_rxtx.c   | 27 ++
>  5 files changed, 78 insertions(+)
> 
> diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index
> 65d87f869..6158e7c34 100644
> --- a/doc/guides/nics/i40e.rst
> +++ b/doc/guides/nics/i40e.rst
> @@ -163,6 +163,14 @@ Runtime Config Options
>Currently hot-plugging of representor ports is not supported so all 
> required
>representors must be specified on the creation of the PF.
> 
> +- ``Enable latest vector`` (default ``disable``)
> +
> +  Vector path was limited to use only on later platform. But users may
> + want the  latest vector path. For example, VPP users may want to use
> + AVX2 vector path on HSW/BDW  because it can get better perf. So
> + ``devargs`` parameter ``enable-latest-vec``  is introduced, for example::
> +-w 84:00.0,enable-latest-vec=1


How about "use_latest_vec" or "use-lastest-vpmd"?

> +
>  Driver compilation and testing
>  --
> 
> diff --git a/doc/guides/rel_notes/release_18_11.rst
> b/doc/guides/rel_notes/release_18_11.rst
> index 3ae6b3f58..f8b0f3189 100644
> --- a/doc/guides/rel_notes/release_18_11.rst
> +++ b/doc/guides/rel_notes/release_18_11.rst
> @@ -54,6 +54,10 @@ New Features
>   Also, make sure to start the actual text at the margin.
>   =
> 
> +* **Added a devarg to eable the latest vector path.**
> +  A new devarg ``enable-latest-vec`` was introduced to allow users to
> +choose
> +  the latest vector path that the platform supported. For example, VPP
> +users
> +  can use AVX2 vector path on BDW/HSW to get better performance.
> 
>  API Changes
>  ---
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 85a6a867f..16b5345fb 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -12513,6 +12513,44 @@ i40e_config_rss_filter(struct i40e_pf *pf,
>   return 0;
>  }
> 
> +#define ETH_I40E_ENABLE_LATEST_VEC   "enable-latest-vec"

This should be defined along with other exist devargs, please check 
ETH_I40E_SUPPORT_MULTI_DRIVER for reference
Also it should be registered with RTE_PMD_REGISTER_PARAM_STRING.

> +
> +bool
> +i40e_parse_latest_vec(struct rte_eth_dev *dev) {
> + static const char *const valid_keys[] = {
> + ETH_I40E_ENABLE_LATEST_VEC, NULL};
> + int enable_latest_vec;
> + struct rte_kvargs *kvlist;
> +
> + if (!dev->device->devargs)
> + return 0;
> +
> + kvlist = rte_kvargs_parse(dev->device->devargs->args, valid_keys);
> + if (!kvlist)
> + return -EINVAL;
> +
> + if (!rte_kvargs_count(kvlist, ETH_I40E_ENABLE_LATEST_VEC))
> + return 0;
> +
> + if (rte_kvargs_count(kvlist, ETH_I40E_ENABLE_LATEST_VEC) > 1)
> + PMD_DRV_LOG(WARNING, "More than one argument \"%s\" and
> only "
> + "the first one is used !",
> + ETH_I40E_ENABLE_LATEST_VEC);
> +
> + enable_latest_vec = atoi((&kvlist->pairs[0])->value);
> +
> + rte_kvargs_free(kvlist);
> +
> + if (enable_latest_vec != 0 && enable_latest_vec != 1)
> + PMD_DRV_LOG(WARNING, "Value should be 0 or 1, set it as 1!");
> +
> + if (enable_latest_vec)
> + return true;
> + else
> + return false;
> +}

We call rte_kvargs_parse in different place for different parameter which is 
not necessary.
it's better to merge them into one parse_devargs function at dev_init and then 
all corresponding field of i40e_adapter can be configured at the same place.
Though this is not this patch's scope, but it's better to introduce a field 
like i40e_adapter->use_latest_vec
and in i40e_parse_latest_vec, it just assign the value which could be used 
later.
This will make things easy for future code clean and also it is not necessary 
to call i40e_parse_latest_vec multiple time in set_rx/tx_function.

> +
>  RTE_INIT(i40e_init_log)
>  {
>   i40e_logtype_init =

[dpdk-dev] [PATCH 1/2] eventdev: fix port id argument in Rx adapter caps API

[Nikhil Rao]

Make the ethernet port id passed into
rte_event_eth_rx_adapter_caps_get() 16 bit.

Fixes: c2189c907dd1 ("eventdev: make ethdev port identifiers 16-bit")
Cc: sta...@dpdk.org
Signed-off-by: Nikhil Rao 
---
 lib/librte_eventdev/Makefile   | 2 +-
 lib/librte_eventdev/rte_eventdev.c | 2 +-
 lib/librte_eventdev/rte_eventdev.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/librte_eventdev/Makefile b/lib/librte_eventdev/Makefile
index 47f599a..ce800ea 100644
--- a/lib/librte_eventdev/Makefile
+++ b/lib/librte_eventdev/Makefile
@@ -8,7 +8,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
 LIB = librte_eventdev.a
 
 # library version
-LIBABIVER := 5
+LIBABIVER := 6
 
 # build flags
 CFLAGS += -DALLOW_EXPERIMENTAL_API
diff --git a/lib/librte_eventdev/rte_eventdev.c 
b/lib/librte_eventdev/rte_eventdev.c
index 801810e..9040b11 100644
--- a/lib/librte_eventdev/rte_eventdev.c
+++ b/lib/librte_eventdev/rte_eventdev.c
@@ -109,7 +109,7 @@
 }
 
 int
-rte_event_eth_rx_adapter_caps_get(uint8_t dev_id, uint8_t eth_port_id,
+rte_event_eth_rx_adapter_caps_get(uint8_t dev_id, uint16_t eth_port_id,
uint32_t *caps)
 {
struct rte_eventdev *dev;
diff --git a/lib/librte_eventdev/rte_eventdev.h 
b/lib/librte_eventdev/rte_eventdev.h
index b6fd6ee..2966928 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -1112,7 +1112,7 @@ struct rte_event {
  *
  */
 int
-rte_event_eth_rx_adapter_caps_get(uint8_t dev_id, uint8_t eth_port_id,
+rte_event_eth_rx_adapter_caps_get(uint8_t dev_id, uint16_t eth_port_id,
uint32_t *caps);
 
 #define RTE_EVENT_TIMER_ADAPTER_CAP_INTERNAL_PORT (1ULL << 0)
-- 
1.8.3.1

[dpdk-dev] [PATCH 2/2] test/event: change ethernet port ids to be 16 bit

[Nikhil Rao]

Update the event rx adapter test to use 16 bit ethernet port ids.

Fixes: c2189c907dd1 ("eventdev: make ethdev port identifiers 16-bit")
Cc: sta...@dpdk.org
Signed-off-by: Nikhil Rao 
---
 test/test/test_event_eth_rx_adapter.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/test/test_event_eth_rx_adapter.c 
b/test/test/test_event_eth_rx_adapter.c
index 2337e54..1ce3e6f 100644
--- a/test/test/test_event_eth_rx_adapter.c
+++ b/test/test/test_event_eth_rx_adapter.c
@@ -32,7 +32,7 @@ struct event_eth_rx_adapter_test_params {
 static struct event_eth_rx_adapter_test_params default_params;
 
 static inline int
-port_init_common(uint8_t port, const struct rte_eth_conf *port_conf,
+port_init_common(uint16_t port, const struct rte_eth_conf *port_conf,
struct rte_mempool *mp)
 {
const uint16_t rx_ring_size = 512, tx_ring_size = 512;
@@ -94,7 +94,7 @@ struct event_eth_rx_adapter_test_params {
 }
 
 static inline int
-port_init_rx_intr(uint8_t port, struct rte_mempool *mp)
+port_init_rx_intr(uint16_t port, struct rte_mempool *mp)
 {
static const struct rte_eth_conf port_conf_default = {
.rxmode = {
@@ -110,7 +110,7 @@ struct event_eth_rx_adapter_test_params {
 }
 
 static inline int
-port_init(uint8_t port, struct rte_mempool *mp)
+port_init(uint16_t port, struct rte_mempool *mp)
 {
static const struct rte_eth_conf port_conf_default = {
.rxmode = {
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v2] net/ixgbe: do not return internal code in rte_eth_dev_reset

[Zhang, Qi Z]

> -Original Message-
> From: Luca Boccassi [mailto:bl...@debian.org]
> Sent: Monday, September 3, 2018 10:18 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; Ananyev, Konstantin
> ; Zhang, Qi Z ; Luca
> Boccassi ; sta...@dpdk.org
> Subject: [PATCH v2] net/ixgbe: do not return internal code in
> rte_eth_dev_reset

Change title to "net/ixgbe: do not return internal code" to avoid check-git-log 
error.

> 
> In case of a temporary failure the ixgbe driver can return the internal error
> IXGBE_ERR_RESET_FAILED to the application. Instead, return -EAGAIN as per
> the public API specification.
> 
> Fixes: cddaf87a1ecb ("lib: fix unused values")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Luca Boccassi 

Acked-by: Qi Zhang 

Applied to dpdk-next-net-intel.

Thanks!
Qi

[dpdk-dev] [PATCH] examples/ipsec-secgw: increase the number of dev mappings

[Anoob Joseph]

Increasing the number of cdev mappings to accomodate usage of crypto
devices with larger number of capabilities, with higher number of cores.

Required mappings : ([no of ciphers] * [no of auth] + [aead algos]) *
[no of cores]

Signed-off-by: Ankur Dwivedi 
Signed-off-by: Anoob Joseph 
---
 examples/ipsec-secgw/ipsec-secgw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/ipsec-secgw/ipsec-secgw.c 
b/examples/ipsec-secgw/ipsec-secgw.c
index b45b87b..ae76e67 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -54,7 +54,7 @@
 #define NB_MBUF(32000)
 
 #define CDEV_QUEUE_DESC 2048
-#define CDEV_MAP_ENTRIES 1024
+#define CDEV_MAP_ENTRIES 16384
 #define CDEV_MP_NB_OBJS 2048
 #define CDEV_MP_CACHE_SZ 64
 #define MAX_QUEUE_PAIRS 1
-- 
2.7.4

Re: [dpdk-dev] [PATCH v2 10/10] kni: add API to set link status on kernel interface

[Stephen Hemminger]

On Mon, 3 Sep 2018 21:47:22 -0300
Dan Gora  wrote:

> Hi All,
> 
> One other problem with using the sysfs method to change the link state
> rather than this ioctl method.  The sysfs/netdev method to change the
> carrier was only introduced in kernel 3.9.  For older kernels, we
> would just be out of luck.  The ioctl method will work with any kernel
> version (2.6+).  It's not clear if this is a problem for DPDK apps or
> not.
> 
> thanks
> dan
> 
> 
> On Thu, Aug 30, 2018 at 7:11 PM, Dan Gora  wrote:
> > On Thu, Aug 30, 2018 at 7:09 PM, Stephen Hemminger
> >  wrote:  
> >> On Thu, 30 Aug 2018 18:41:14 -0300
> >> Dan Gora  wrote:
> >>  
> >>> On the other hand, the "write to /sys" method is a bit more simple and
> >>> confines the changes to the user space library.  If we're confident
> >>> that the /sys ABI is stable and not going to be changed going forward
> >>> it seems like a valid alternative.  
> >>
> >> See Documentation/ABI/testing/sysfs-class-net  
> >
> > yeah, but it's in the 'testing' directory :)
> >
> > From Documentation/ABI/README:
> >
> > testing/
> >
> > This directory documents interfaces that are felt to be stable,
> > as the main development of this interface has been completed.
> > The interface can be changed to add new features, but the
> > current interface will not break by doing this, unless grave
> > errors or security problems are found in them.  Userspace
> > programs can start to rely on these interfaces, but they must be
> > aware of changes that can occur before these interfaces move to
> > be marked stable.  Programs that use these interfaces are
> > strongly encouraged to add their name to the description of
> > these interfaces, so that the kernel developers can easily
> > notify them if any changes occur (see the description of the
> > layout of the files below for details on how to do this.)
> >
> > Like I said, I'm ok with using this if that's what everyone wants to do.
> >
> > d  
> 
> 
> 

Linux 3.9 is no longer supported. Currently, upstream Linux kernel is supported
from 3.16 on. If someone is on a kernel that old, they aren't going to get
any security fixes.

Re: [dpdk-dev] [PATCH v1 1/2] eal: add nanosleep based delay function

[Stephen Hemminger]

On Mon,  3 Sep 2018 17:47:42 +0300
Ilya Maximets  wrote:

>  
> +void __rte_experimental
> +rte_delay_us_sleep(unsigned int us)
> +{
> + struct timespec wait[2];
> + int ind = 0;
> +
> + wait[0].tv_sec = 0;
> + if (us >= US_PER_S) {
> + wait[0].tv_sec = us / US_PER_S;
> + us -= wait[0].tv_sec * US_PER_S;
> + }
> + wait[0].tv_nsec = 1000 * us;
> +
> + while (nanosleep(&wait[ind], &wait[1 - ind]) == EINTR)
> + ind = 1 - ind;
> +}
> +

This seems like a complex/tricky way to handle the case where
nanosleep is interrupted. It needs a comment.

[dpdk-dev] [PATCH] examples/eventdev_pipeline: add Tx adapter support

[Pavan Nikhilesh]

Signed-off-by: Pavan Nikhilesh 
---
 This patch depends on the following series:
 http://patches.dpdk.org/project/dpdk/list/?series=1121

 examples/eventdev_pipeline/main.c |  62 ++--
 examples/eventdev_pipeline/pipeline_common.h  |  31 +-
 .../pipeline_worker_generic.c | 273 +-
 .../eventdev_pipeline/pipeline_worker_tx.c| 130 +
 4 files changed, 186 insertions(+), 310 deletions(-)

diff --git a/examples/eventdev_pipeline/main.c 
b/examples/eventdev_pipeline/main.c
index 700bc696f..95531150b 100644
--- a/examples/eventdev_pipeline/main.c
+++ b/examples/eventdev_pipeline/main.c
@@ -26,20 +26,6 @@ core_in_use(unsigned int lcore_id) {
fdata->tx_core[lcore_id] || fdata->worker_core[lcore_id]);
 }

-static void
-eth_tx_buffer_retry(struct rte_mbuf **pkts, uint16_t unsent,
-   void *userdata)
-{
-   int port_id = (uintptr_t) userdata;
-   unsigned int _sent = 0;
-
-   do {
-   /* Note: hard-coded TX queue */
-   _sent += rte_eth_tx_burst(port_id, 0, &pkts[_sent],
- unsent - _sent);
-   } while (_sent != unsent);
-}
-
 /*
  * Parse the coremask given as argument (hexadecimal string) and fill
  * the global configuration (core role and core count) with the parsed
@@ -263,6 +249,7 @@ parse_app_args(int argc, char **argv)
 static inline int
 port_init(uint8_t port, struct rte_mempool *mbuf_pool)
 {
+   struct rte_eth_rxconf rx_conf;
static const struct rte_eth_conf port_conf_default = {
.rxmode = {
.mq_mode = ETH_MQ_RX_RSS,
@@ -291,6 +278,8 @@ port_init(uint8_t port, struct rte_mempool *mbuf_pool)
if (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_MBUF_FAST_FREE)
port_conf.txmode.offloads |=
DEV_TX_OFFLOAD_MBUF_FAST_FREE;
+   rx_conf = dev_info.default_rxconf;
+   rx_conf.offloads = port_conf.rxmode.offloads;

port_conf.rx_adv_conf.rss_conf.rss_hf &=
dev_info.flow_type_rss_offloads;
@@ -311,7 +300,8 @@ port_init(uint8_t port, struct rte_mempool *mbuf_pool)
/* Allocate and set up 1 RX queue per Ethernet port. */
for (q = 0; q < rx_rings; q++) {
retval = rte_eth_rx_queue_setup(port, q, rx_ring_size,
-   rte_eth_dev_socket_id(port), NULL, mbuf_pool);
+   rte_eth_dev_socket_id(port), &rx_conf,
+   mbuf_pool);
if (retval < 0)
return retval;
}
@@ -350,7 +340,7 @@ port_init(uint8_t port, struct rte_mempool *mbuf_pool)
 static int
 init_ports(uint16_t num_ports)
 {
-   uint16_t portid, i;
+   uint16_t portid;

if (!cdata.num_mbuf)
cdata.num_mbuf = 16384 * num_ports;
@@ -367,36 +357,26 @@ init_ports(uint16_t num_ports)
rte_exit(EXIT_FAILURE, "Cannot init port %"PRIu16 "\n",
portid);

-   RTE_ETH_FOREACH_DEV(i) {
-   void *userdata = (void *)(uintptr_t) i;
-   fdata->tx_buf[i] =
-   rte_malloc(NULL, RTE_ETH_TX_BUFFER_SIZE(32), 0);
-   if (fdata->tx_buf[i] == NULL)
-   rte_panic("Out of memory\n");
-   rte_eth_tx_buffer_init(fdata->tx_buf[i], 32);
-   rte_eth_tx_buffer_set_err_callback(fdata->tx_buf[i],
-  eth_tx_buffer_retry,
-  userdata);
-   }
-
return 0;
 }

 static void
 do_capability_setup(uint8_t eventdev_id)
 {
+   int ret;
uint16_t i;
-   uint8_t mt_unsafe = 0;
+   uint8_t generic_pipeline = 0;
uint8_t burst = 0;

RTE_ETH_FOREACH_DEV(i) {
-   struct rte_eth_dev_info dev_info;
-   memset(&dev_info, 0, sizeof(struct rte_eth_dev_info));
-
-   rte_eth_dev_info_get(i, &dev_info);
-   /* Check if it is safe ask worker to tx. */
-   mt_unsafe |= !(dev_info.tx_offload_capa &
-   DEV_TX_OFFLOAD_MT_LOCKFREE);
+   uint32_t caps = 0;
+
+   ret = rte_event_eth_tx_adapter_caps_get(eventdev_id, i, &caps);
+   if (ret)
+   rte_exit(EXIT_FAILURE,
+   "Invalid capability for Tx adptr port %d\n", i);
+   generic_pipeline |= !(caps &
+   RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT);
}

struct rte_event_dev_info eventdev_info;
@@ -406,10 +386,10 @@ do_capability_setup(uint8_t eventdev_id)
burst = eventdev_info.event_dev_cap & RTE_EVENT_DEV_CAP_BURST_MODE ? 1 :
0;

-   if (mt_unsafe)
+   if (generic_pipeline)
set_worker_generic_setup_data(&fdata->cap, burst);
else
- 

[dpdk-dev] [PATCH v2 1/2] test/event: fix eth Rx adapter autotest for skeleton PMD

[Nikhil Rao]

skeleton PMD does not support
RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ and
implicit_release_disable so make the Rx queue_id = -1 and
initialize the event port configuration to zero.

Fixes: ec36d881f56d ("eventdev: add implicit release disable capability")
Fixes: 2a9c83ae3b2e ("test/eventdev: add multi-ports test")
Cc: vipin.vargh...@intel.com
CC: sta...@dpdk.org
Signed-off-by: Nikhil Rao 
---

v2:
* add include patch to fix Rx adapter intr autotest as it is
  dependent on the first patch.

 test/test/test_event_eth_rx_adapter.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/test/test_event_eth_rx_adapter.c 
b/test/test/test_event_eth_rx_adapter.c
index 2337e54..29d0ff5 100644
--- a/test/test/test_event_eth_rx_adapter.c
+++ b/test/test/test_event_eth_rx_adapter.c
@@ -317,7 +317,7 @@ struct event_eth_rx_adapter_test_params {
 {
int err;
struct rte_event_dev_info dev_info;
-   struct rte_event_port_conf rx_p_conf;
+   struct rte_event_port_conf rx_p_conf = {0};
 
err = rte_event_dev_info_get(TEST_DEV_ID, &dev_info);
TEST_ASSERT(err == 0, "Expected 0 got %d", err);
@@ -503,7 +503,7 @@ struct event_eth_rx_adapter_test_params {
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,
+   port_index, -1,
&queue_config);
TEST_ASSERT(err == 0, "Expected 0 got %d", err);
}
@@ -512,7 +512,7 @@ struct event_eth_rx_adapter_test_params {
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);
+   port_index, -1);
TEST_ASSERT(err == 0, "Expected 0 got %d", err);
}
 
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 2/2] test/event: fix Rx adapter intr autotest for skeleton PMD

[Nikhil Rao]

skeleton PMD does not support
RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ
so make the Rx queue_id = -1 and initialize the event port
configuration to zero.

Fixes: d65856999dd6 ("test/event: add Rx adapter tests for interrupt driven 
queues")
Cc: nikhil@intel.com
Signed-off-by: Nikhil Rao 
---
 test/test/test_event_eth_rx_adapter.c | 37 +--
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/test/test/test_event_eth_rx_adapter.c 
b/test/test/test_event_eth_rx_adapter.c
index 29d0ff5..937a49e 100644
--- a/test/test/test_event_eth_rx_adapter.c
+++ b/test/test/test_event_eth_rx_adapter.c
@@ -547,11 +547,13 @@ struct event_eth_rx_adapter_test_params {
/* weight = 0 => interrupt mode */
queue_config.servicing_weight = 0;
 
-   /* add queue 0 */
-   err = rte_event_eth_rx_adapter_queue_add(TEST_INST_ID,
-   TEST_ETHDEV_ID, 0,
-   &queue_config);
-   TEST_ASSERT(err == 0, "Expected 0 got %d", err);
+   if (cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ) {
+   /* add queue 0 */
+   err = rte_event_eth_rx_adapter_queue_add(TEST_INST_ID,
+   TEST_ETHDEV_ID, 0,
+   &queue_config);
+   TEST_ASSERT(err == 0, "Expected 0 got %d", err);
+   }
 
/* add all queues */
queue_config.servicing_weight = 0;
@@ -561,11 +563,13 @@ struct event_eth_rx_adapter_test_params {
&queue_config);
TEST_ASSERT(err == 0, "Expected 0 got %d", err);
 
-   /* del queue 0 */
-   err = rte_event_eth_rx_adapter_queue_del(TEST_INST_ID,
-   TEST_ETHDEV_ID,
-   0);
-   TEST_ASSERT(err == 0, "Expected 0 got %d", err);
+   if (cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ) {
+   /* del queue 0 */
+   err = rte_event_eth_rx_adapter_queue_del(TEST_INST_ID,
+   TEST_ETHDEV_ID,
+   0);
+   TEST_ASSERT(err == 0, "Expected 0 got %d", err);
+   }
 
/* del remaining queues */
err = rte_event_eth_rx_adapter_queue_del(TEST_INST_ID,
@@ -583,11 +587,14 @@ struct event_eth_rx_adapter_test_params {
 
/* intr -> poll mode queue */
queue_config.servicing_weight = 1;
-   err = rte_event_eth_rx_adapter_queue_add(TEST_INST_ID,
-   TEST_ETHDEV_ID,
-   0,
-   &queue_config);
-   TEST_ASSERT(err == 0, "Expected 0 got %d", err);
+
+   if (cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ) {
+   err = rte_event_eth_rx_adapter_queue_add(TEST_INST_ID,
+   TEST_ETHDEV_ID,
+   0,
+   &queue_config);
+   TEST_ASSERT(err == 0, "Expected 0 got %d", err);
+   }
 
err = rte_event_eth_rx_adapter_queue_add(TEST_INST_ID,
TEST_ETHDEV_ID,
-- 
1.8.3.1

[dpdk-dev] [PATCH] test/event: add adapter tests to meson build

[Nikhil Rao]

Add tests for event eth Rx, crypto and timer adapters to
meson build

Cc: Abhinandan Gujjar 
Cc: Erik G. Carrillio 
Signed-off-by: Nikhil Rao 
---
 test/test/meson.build | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/test/test/meson.build b/test/test/meson.build
index b1dd6ec..1b2e8b7 100644
--- a/test/test/meson.build
+++ b/test/test/meson.build
@@ -33,7 +33,10 @@ test_sources = files('commands.c',
'test_efd.c',
'test_efd_perf.c',
'test_errno.c',
+   'test_event_crypto_adapter.c',
+   'test_event_eth_rx_adapter.c',
'test_event_ring.c',
+   'test_event_timer_adapter.c',
'test_eventdev.c',
'test_func_reentrancy.c',
'test_flow_classify.c',
@@ -151,7 +154,11 @@ test_names = [
'efd_autotest',
'efd_perf_autotest',
'errno_autotest',
+   'event_crypto_adapter_autotest',
+   'event_eth_rx_adapter_autotest',
+   'event_eth_rx_intr_adapter_autotest',
'event_ring_autotest',
+   'event_timer_adapter_autotest',
'eventdev_common_autotest',
'eventdev_octeontx_autotest',
'eventdev_sw_autotest',
-- 
1.8.3.1

[dpdk-dev] [PATCH v2] test/event: add adapter tests to meson build

[Nikhil Rao]

Add tests for event eth Rx, crypto and timer adapters to
meson build

Cc: Abhinandan Gujjar 
Cc: Erik G. Carrillo 
Signed-off-by: Nikhil Rao 
---

v2:
* fix Erik's email address

 test/test/meson.build | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/test/test/meson.build b/test/test/meson.build
index b1dd6ec..1b2e8b7 100644
--- a/test/test/meson.build
+++ b/test/test/meson.build
@@ -33,7 +33,10 @@ test_sources = files('commands.c',
'test_efd.c',
'test_efd_perf.c',
'test_errno.c',
+   'test_event_crypto_adapter.c',
+   'test_event_eth_rx_adapter.c',
'test_event_ring.c',
+   'test_event_timer_adapter.c',
'test_eventdev.c',
'test_func_reentrancy.c',
'test_flow_classify.c',
@@ -151,7 +154,11 @@ test_names = [
'efd_autotest',
'efd_perf_autotest',
'errno_autotest',
+   'event_crypto_adapter_autotest',
+   'event_eth_rx_adapter_autotest',
+   'event_eth_rx_intr_adapter_autotest',
'event_ring_autotest',
+   'event_timer_adapter_autotest',
'eventdev_common_autotest',
'eventdev_octeontx_autotest',
'eventdev_sw_autotest',
-- 
1.8.3.1

[dpdk-dev] [PATCH] test/eventdev: fix incorrect unit test

[Pavan Nikhilesh]

Enqueue, dequeue depths are only valid for event devs that have burst
mode capability. Check event dev capability before testing depth
boundary.

Fixes: f8f9d233ea0e ("test/eventdev: add unit tests")

Signed-off-by: Pavan Nikhilesh 
---
 test/test/test_eventdev.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/test/test/test_eventdev.c b/test/test/test_eventdev.c
index 04bdc6b6c..00d73275c 100644
--- a/test/test/test_eventdev.c
+++ b/test/test/test_eventdev.c
@@ -190,15 +190,18 @@ test_eventdev_configure(void)
 "Config negative test failed");
TEST_ASSERT_EQUAL(-EINVAL,
test_ethdev_config_run(&dev_conf, &info, max_event_queue_flows),
-"Config negative test failed");
-   TEST_ASSERT_EQUAL(-EINVAL,
-   test_ethdev_config_run(&dev_conf, &info,
-   max_event_port_dequeue_depth),
-"Config negative test failed");
-   TEST_ASSERT_EQUAL(-EINVAL,
-   test_ethdev_config_run(&dev_conf, &info,
-   max_event_port_enqueue_depth),
-"Config negative test failed");
+   "Config negative test failed");
+
+   if (info.event_dev_cap & RTE_EVENT_DEV_CAP_BURST_MODE) {
+   TEST_ASSERT_EQUAL(-EINVAL,
+   test_ethdev_config_run(&dev_conf, &info,
+   max_event_port_dequeue_depth),
+   "Config negative test failed");
+   TEST_ASSERT_EQUAL(-EINVAL,
+   test_ethdev_config_run(&dev_conf, &info,
+   max_event_port_enqueue_depth),
+   "Config negative test failed");
+   }
 
/* Positive case */
devconf_set_default_sane_values(&dev_conf, &info);
-- 
2.18.0

Re: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing

[Joseph, Anoob]

Hi Konstantin,

Please see inline.


On 03-09-2018 23:51, Ananyev, Konstantin wrote:

External Email

Hi Anoob,


Hi Konstantin,

Few comments. Please see inline.

Thanks,

Anoob

On 24-08-2018 22:23, Konstantin Ananyev wrote:

External Email

This RFC introduces a new library within DPDK: librte_ipsec.
The aim is to provide DPDK native high performance library for IPsec
data-path processing.
The library is supposed to utilize existing DPDK crypto-dev and
security API to provide application with transparent IPsec processing API.
The library is concentrated on data-path protocols processing (ESP and AH),
IKE protocol(s) implementation is out of scope for that library.
Though hook/callback mechanisms will be defined to allow integrate it
with existing IKE implementations.
Due to quite complex nature of IPsec protocol suite and variety of user
requirements and usage scenarios a few API levels will be provided:
1) Security Association (SA-level) API
  Operates at SA level, provides functions to:
  - initialize/teardown SA object
  - process inbound/outbound ESP/AH packets associated with the given SA
(decrypt/encrypt, authenticate, check integrity,
 add/remove ESP/AH related headers and data, etc.).
2) Security Association Database (SAD) API
  API to create/manage/destroy IPsec SAD.
  While DPDK IPsec library plans to have its own implementation,
  the intention is to keep it as independent from the other parts
  of IPsec library as possible.
  That is supposed to give users the ability to provide their own
  implementation of the SAD compatible with the other parts of the
  IPsec library.
3) IPsec Context (CTX) API
  This is supposed to be a high-level API, where each IPsec CTX is an
  abstraction of 'independent copy of the IPsec stack'.
  CTX owns set of SAs, SADs and assigned to it crypto-dev queues, etc.
  and provides:
  - de-multiplexing stream of inbound packets to particular SAs and
further IPsec related processing.
  - IPsec related processing for the outbound packets.
  - SA add/delete/update functionality

[Anoob]: Security Policy is an important aspect of IPsec. An IPsec
library without Security Policy API would be incomplete. For inline
protocol offload, the final SP-SA check(selector check) is the only
IPsec part being done by ipsec-secgw now. Would make sense to add that
also in the library.

You mean here, that we need some sort of SPD implementation, correct?

[Anoob] Yes.



Current RFC concentrates on SA-level API only (1),
detailed discussion for 2) and 3) will be subjects for separate RFC(s).

SA (low) level API
==

API described below operates on SA level.
It provides functionality that allows user for given SA to process
inbound and outbound IPsec packets.
To be more specific:
- for inbound ESP/AH packets perform decryption, authentication,
integrity checking, remove ESP/AH related headers

[Anoob] Anti-replay check would also be required.

Yep, anti-replay and ESN support is implied as part of "integrity checking".
Probably I have to be more specific here.

[Anoob] This is fine.



- for outbound packets perform payload encryption, attach ICV,
update/add IP headers, add ESP/AH headers/trailers,
setup related mbuf felids (ol_flags, tx_offloads, etc.).

[Anoob] Do we have any plans to handle ESN expiry? Some means to
initiate an IKE renegotiation? I'm assuming application won't be aware
of the sequence numbers, in this case.
[Anoob] What is your plan with events like ESN expiry? IPsec spec talks 
about byte and time expiry as well.

- initialize/un-initialize given SA based on user provided parameters.

Processed inbound/outbound packets could be grouped by user provided
flow id (opaque 64-bit number associated by user with given SA).

SA-level API is based on top of crypto-dev/security API and relies on them
to perform actual cipher and integrity checking.
Due to the nature of crypto-dev API (enqueue/deque model) we use
asynchronous API for IPsec packets destined to be processed
by crypto-device:
rte_ipsec_crypto_prepare()->rte_cryptodev_enqueue_burst()->
rte_cryptodev_dequeue_burst()->rte_ipsec_crypto_process().
Though for packets destined for inline processing no extra overhead
is required and simple and synchronous API: rte_ipsec_inline_process()
is introduced for that case.

[Anoob] The API should include event-delivery as a crypto-op completion
mechanism as well. The application could configure the event crypto
adapter and then enqueue and dequeue to crypto device using events (via
event dev).

Not sure what particular extra API you think is required here?
As I understand in both cases (with or without event crypto-adapter) we still 
have to:
  1) fill crypto-op properly
  2) enqueue it to crypto-dev (via eventdev or directly)
3)  receive processed by crypto-dev crypto-op (either via eventdev or directly)
4) check crypto-op status, do further post-processing if a

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

[Christian Ehrhardt]

On Mon, Aug 27, 2018 at 11:29 AM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

>
>
> On Wed, Aug 22, 2018 at 9:26 AM Christian Ehrhardt <
> christian.ehrha...@canonical.com> wrote:
>
>> Hi all,
>>
>> Here is a list of patches targeted for stable release 18.05.1. Please
>> help review and test. The planned date for the final release is August,
>> 29th. Before that, please shout if anyone has objections with these
>> patches being applied.
>>
>
> There was neither positive nor negative feedback on 18.05.1-rc1 so far.
> Maybe 17.11.x priorities and general PTO time just beats 18.05 - which is
> fine to some extend.
> The only private message I got was about one party needing some extra time.
> For all of the above I will do two things:
> 1. the deadline to get back with results on 18.05.1-rc1 is extended to
> Tuesday the 4th of September
> 2. I'd highly appreciate feedback of people involved that intend to test
> it so I know what to wait for (or not)
>

I had multiple positive off-list feedbacks and the deadline has passed.
The TL;DR was always "no errors" or "only errors that already existed with
18.05(.0)"
So I'm gonna release 18.05.1 as-is today.

Thanks everybody who was running tests on this!


> Also for the companies committed to running regression tests,
>> please run the tests and report any issue before the release date.
>>
>> A release candidate tarball can be found at:
>>
>> https://dpdk.org/browse/dpdk-stable/tag/?id=v18.05.1-rc1
>>
>> These patches are located at branch 18.05 of dpdk-stable repo:
>>
>> https://git.dpdk.org/dpdk-stable/log/?h=18.05
>>
>> Thanks.
>>
>> Christian Ehrhardt 
>>
>> ---
>> Adrien Mazarguil (8):
>>   app/testpmd: fix crash when attaching a device
>>   net/mlx4: fix minor resource leak during init
>>   net/mlx5: fix errno object in probe function
>>   net/mlx5: fix missing errno in probe function
>>   net/mlx5: fix error message in probe function
>>   net/mlx5: fix invalid error check
>>   maintainers: update for Mellanox PMDs
>>   net/mlx5: fix invalid network interface index
>>
>> Ajit Khaparde (11):
>>   net/bnxt: fix clear port stats
>>   net/bnxt: fix close operation
>>   net/bnxt: fix HW Tx checksum offload check
>>   net/bnxt: check filter type before clearing it
>>   net/bnxt: fix set MTU
>>   net/bnxt: fix incorrect IO address handling in Tx
>>   net/bnxt: fix Rx ring count limitation
>>   net/bnxt: fix memory leaks in NVM commands
>>   net/bnxt: fix lock release on NVM write failure
>>   net/bnxt: check access denied for HWRM commands
>>   net/bnxt: fix RETA size
>>
>> Alejandro Lucero (2):
>>   net/nfp: fix unused header reference
>>   net/nfp: fix field initialization in Tx descriptor
>>
>> Alok Makhariya (1):
>>   bus/dpaa: fix phandle support for Linux 4.16
>>
>> Anatoly Burakov (14):
>>   ipc: fix locking while sending messages
>>   mem: fix alignment of requested virtual areas
>>   eal/bsd: fix memory segment index display
>>   malloc: fix pad erasing
>>   eal/linux: fix invalid syntax in interrupts
>>   eal/linux: fix uninitialized value
>>   vfio: fix uninitialized variable
>>   malloc: do not skip pad on free
>>   test: fix EAL flags autotest on FreeBSD
>>   test: fix result printing
>>   test: fix code on report
>>   test: make autotest runner python 2/3 compliant
>>   test: print autotest categories
>>   test: improve filtering
>>
>> Andrew Rybchenko (7):
>>   net/sfc: cut non VLAN ID bits from TCI
>>   net/sfc: discard packets with bad CRC on EF10 ESSB Rx
>>   net/sfc: fix double-free in EF10 ESSB Rx queue purge
>>   net/sfc: move Rx checksum offload check to device level
>>   net/sfc: fix Rx queue offloads reporting in queue info
>>   net/sfc: fix assert in set multicast address list
>>   net/sfc: handle unknown L3 packet class in EF10 event parser
>>
>> Andy Green (2):
>>   ring: fix declaration after statement
>>   ring: fix sign conversion warning
>>
>> Beilei Xing (5):
>>   net/i40e: fix shifts of 32-bit value
>>   net/i40e: fix PPPoL2TP packet type parsing
>>   net/i40e: fix packet type parsing with DDP
>>   net/i40e: fix setting TPID with AQ command
>>   net/i40e: fix device parameter parsing
>>
>> Bruce Richardson (3):
>>   eal: fix error message for unsupported platforms
>>   examples/exception_path: fix out-of-bounds read
>>   mk: fix permissions when using make install
>>
>> Chas Williams (2):
>>   net/bonding: always update bonding link status
>>   net/bonding: do not clear active slave count
>>
>> Christian Ehrhardt (2):
>>   FIXUP: net/mlx5: fix invalid network interface index
>>   version: 18.05.1-rc1
>>
>> Damjan Marion (1):
>>   net/i40e: do not reset device info data
>>
>> Dan Gora (1):
>>   kni: fix crash with null name
>>
>> Daria Kolistratova (1):
>>   net/ena: fix SI

[dpdk-dev] [RFC] ethdev: add min/max MTU to device info

[Stephen Hemminger]

This addresses the usability issue raised by OVS at DPDK Userspace
summit. It adds general min/max mtu into device info. For compatiablity,
and to save space, it fits in a hole in existing structure.

The initial version sets max mtu to normal Ethernet, it is up to
PMD to set larger value if it supports Jumbo frames.

Fixing the drivers to use this is trivial and can be done by 18.11.
Already have some of the patches done.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_ethdev/rte_ethdev.c | 7 +++
 lib/librte_ethdev/rte_ethdev.h | 2 ++
 2 files changed, 9 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 4c320250589a..df0c7536a7c4 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2408,6 +2408,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct 
rte_eth_dev_info *dev_info)
dev_info->rx_desc_lim = lim;
dev_info->tx_desc_lim = lim;
dev_info->device = dev->device;
+   dev_info->min_mtu = ETHER_MIN_MTU;
+   dev_info->max_mtu = ETHER_MTU;
 
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
@@ -2471,12 +2473,17 @@ int
 rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
 {
int ret;
+   struct rte_eth_dev_info dev_info;
struct rte_eth_dev *dev;
 
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
 
+   rte_eth_dev_info_get(port_id, &dev_info);
+   if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
+   return -EINVAL;
+
ret = (*dev->dev_ops->mtu_set)(dev, mtu);
if (!ret)
dev->data->mtu = mtu;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 7070e9ab408f..5171a9083288 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1015,6 +1015,8 @@ struct rte_eth_dev_info {
const char *driver_name; /**< Device Driver name. */
unsigned int if_index; /**< Index to bound host interface, or 0 if none.
Use if_indextoname() to translate into an interface name. */
+   uint16_t min_mtu;   /**< Minimum MTU allowed */
+   uint16_t max_mtu;   /**< Maximum MTU allowed */
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
-- 
2.17.1

Re: [dpdk-dev] [PATCH v3] hash table: add an iterator over conflicting entries

[Wang, Yipeng1]

Hmm I see, it falls back to my original thought to have malloc inside the init 
function..
Thanks for the explanation. :) 

So I guess with your implementation, in future if we change the internal state 
to be larger,
the ABI will be broken. BTW, this patch set also changes API so proper notice 
is needed.
People more familiar with API/ABI change policies may be able to help here.

Just to confirm, is there anyway like I said for your application to have some 
long-live states
and reuse them throughout the application so that you don’t have to have 
short-lived ones in stack?

Thanks
Yipeng

>
>The fact that struct rte_hash does not expose its private fields but
>only its type to applications means that a compiler cannot find out the
>byte length of struct rte_hash using only the header rte_hash.h. Thus,
>an application cannot allocate memory on its own (e.g. as a local
>variable) for a struct rte_hash. An application can, however, have a
>pointer to a struct rte_hash since the byte length of a pointer only
>depends on the architecture of the machine. This is the motivation
>behind having struct rte_hash_iterator_state in rte_hash.h only holding
>an array of bytes.
>
>There are good reasons to implement struct rte_hash as it is. For
>examples, struct rte_hash can change its byte length between versions of
>DPDK even if applications are dynamically linked to DPDK and not
>recompiled. Moreover a hash table is unlikely to be so short-lived as an
>iterator.
>
>[ ]'s
>Michel Machado

[dpdk-dev] ppc64: fix compilation of when AltiVec is enabled

[dwilder]

Hi Christian

I am new to the list thus was unable to reply directly to your post:

[PATCH v2] ppc64: fix compilation of when AltiVec is enabled

I reproduce the build error on my ppc64le box and verified that your V2 
patch corrects the build failure on both RHEL 7.5 and Ubuntu 18.04.  
Thanks for the patch,  apologies for the very slow response.


PS: I ran this past our Power tools team. For now the best practice is 
to #undef bool, vector, pixel after including altivec.h when compiled 
for C++ or ANSI C11.   A patch to gcc for this issue has been proposed 
to solve this issue, but it needs to be validated on a Linux 
distribution. If this works out it will show up in GCC 9.


Regards
David

Re: [dpdk-dev] [PATCH] test/bpf: use hton instead of __builtin_bswap

[Malvika Gupta]

Hi Ananyev,

I used clang version 6.0.0. Please see the following output for your reference. 

$ clang -v 
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/8.0.1
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/7.3.0
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/8.0.1
Selected GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/7.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

Also, the code compiles with both -O2 and -O0 for me. 

I hope this was helpful
Best,
Malvika

-Original Message-
From: Ananyev, Konstantin  
Sent: Tuesday, September 4, 2018 8:56 AM
To: Malvika Gupta 
Cc: dev@dpdk.org; Gavin Hu (Arm Technology China) ; Honnappa 
Nagarahalli ; Brian Brooks 
; nd 
Subject: RE: [PATCH] test/bpf: use hton instead of __builtin_bswap

Hi,

> 
> Convert host machine endianness to networking endianness for 
> comparison of incoming packets with BPF filter
> 
> 
> Signed-off-by: Malvika Gupta 
> Reviewed-by: Gavin Hu 
> Reviewed-by: Brian Brooks 
> Suggested-by: Brian Brooks 
> ---
>  test/bpf/t1.c | 7 ---
>  test/bpf/t3.c | 3 ++-
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/test/bpf/t1.c b/test/bpf/t1.c index 60f9434ab..7943fcf34 
> 100644
> --- a/test/bpf/t1.c
> +++ b/test/bpf/t1.c
> @@ -28,24 +28,25 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  uint64_t
>  entry(void *pkt)
>  {
>   struct ether_header *ether_header = (void *)pkt;
> 
> - if (ether_header->ether_type != __builtin_bswap16(0x0800))
> + if (ether_header->ether_type != htons(0x0800))

Which version of clang do you use?
With my one I get:
$ clang -O2 -target bpf -c t1.c
t1.c:37:34: error: couldn't allocate output register for constraint 'r'
if (ether_header->ether_type != ntohs(0x0800))
^
/usr/include/netinet/in.h:402:21: note: expanded from macro 'ntohs'
#   define ntohs(x) __bswap_16 (x)
^
/usr/include/bits/byteswap-16.h:31:14: note: expanded from macro '__bswap_16'
   __asm__ ("rorw $8, %w0"  

With '-O0' it compiles ok.

$ clang -v
clang version 4.0.1 (tags/RELEASE_401/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/7
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/7
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

Konstantin

>   return 0;
> 
>   struct iphdr *iphdr = (void *)(ether_header + 1);
>   if (iphdr->protocol != 17 || (iphdr->frag_off & 0x1) != 0 ||
> - iphdr->daddr != __builtin_bswap32(0x1020304))
> + iphdr->daddr != htonl(0x1020304))
>   return 0;
> 
>   int hlen = iphdr->ihl * 4;
>   struct udphdr *udphdr = (void *)iphdr + hlen;
> 
> - if (udphdr->dest !=  __builtin_bswap16(5000))
> + if (udphdr->dest != htons(5000))
>   return 0;
> 
>   return 1;
> diff --git a/test/bpf/t3.c b/test/bpf/t3.c index 531b9cb8c..24298b7c7 
> 100644
> --- a/test/bpf/t3.c
> +++ b/test/bpf/t3.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include "mbuf.h"
> +#include 
> 
>  extern void rte_pktmbuf_dump(FILE *, const struct rte_mbuf *, 
> unsigned int);
> 
> @@ -29,7 +30,7 @@ entry(const void *pkt)
>   mb = pkt;
>   eth = rte_pktmbuf_mtod(mb, const struct ether_header *);
> 
> - if (eth->ether_type == __builtin_bswap16(ETHERTYPE_ARP))
> + if (eth->ether_type == htons(ETHERTYPE_ARP))
>   rte_pktmbuf_dump(stdout, mb, 64);
> 
>   return 1;
> --
> 2.17.1

Re: [dpdk-dev] [PATCH v3] hash table: add an iterator over conflicting entries

[Honnappa Nagarahalli]

-Original Message-
From: Michel Machado  
Sent: Tuesday, September 4, 2018 2:37 PM
To: Honnappa Nagarahalli ; Qiaobin Fu 
; bruce.richard...@intel.com; pablo.de.lara.gua...@intel.com
Cc: dev@dpdk.org; douce...@bu.edu; keith.wi...@intel.com; 
sameh.gobr...@intel.com; charlie@intel.com; step...@networkplumber.org; nd 
; yipeng1.w...@intel.com
Subject: Re: [PATCH v3] hash table: add an iterator over conflicting entries

Hi Honnappa,

On 09/02/2018 06:05 PM, Honnappa Nagarahalli wrote:
> +/* istate stands for internal state. */ struct 
> +rte_hash_iterator_istate {
> + const struct rte_hash *h;
> This can be outside of this structure. This will help keep the API 
> definitions consistent with existing APIs. Please see further comments below.

Discussed later.

> + uint32_t  next;
> + uint32_t  total_entries;
> +};
> This structure can be moved to rte_cuckoo_hash.h file.

What's the purpose of moving this struct to a header file since it's only 
used in the C file rte_cuckoo_hash.c?

This is to maintain consistency. For ex: 'struct queue_node', which is an 
internal structure, is kept in rte_cuckoo_hash.h

> +int32_t
> +rte_hash_iterator_init(const struct rte_hash *h,
> + struct rte_hash_iterator_state *state) {
> + struct rte_hash_iterator_istate *__state;
> '__state' can be replaced by 's'.
> 
> +
> + RETURN_IF_TRUE(((h == NULL) || (state == NULL)), -EINVAL);
> +
> + __state = (struct rte_hash_iterator_istate *)state;
> + __state->h = h;
> + __state->next = 0;
> + __state->total_entries = h->num_buckets * RTE_HASH_BUCKET_ENTRIES;
> +
> + return 0;
> +}
> IMO, creating this API can be avoided if the initialization is handled in 
> 'rte_hash_iterate' function. The cost of doing this is very trivial (one 
> extra 'if' statement) in 'rte_hash_iterate' function. It will help keep the 
> number of APIs to minimal.

Applications would have to initialize struct rte_hash_iterator_state *state 
before calling rte_hash_iterate() anyway. Why not initializing the fields of a 
state only once?

My concern is about creating another API for every iterator API. You have a 
valid point on saving cycles as this API applies for data plane. Have you done 
any performance benchmarking with and without this API? May be we can guide our 
decision based on that.

>   int32_t
> -rte_hash_iterate(const struct rte_hash *h, const void **key, void 
> **data, uint32_t *next)
> +rte_hash_iterate(
> + struct rte_hash_iterator_state *state, const void **key, void 
> +**data)
> 
> IMO, as suggested above, do not store 'struct rte_hash *h' in 'struct 
> rte_hash_iterator_state'. Instead, change the API definition as follows:
> rte_hash_iterate(const struct rte_hash *h, const void **key, void 
> **data, struct rte_hash_iterator_state *state)
> 
> This will help keep the API signature consistent with existing APIs.
> 
> This is an ABI change. Please take a look at 
> https://doc.dpdk.org/guides/contributing/versioning.html.

The ABI will change in a way or another, so why not going for a single 
state instead of requiring parameters that are already needed for the 
initialization of the state?

Are there any cost savings we can achieve by keeping the 'h' in the iterator 
state?

Thank you for the link. We'll check how to proceed with the ABI change.

>   {
> + struct rte_hash_iterator_istate *__state;
> '__state' can be replaced with 's'.

Gaëtan Rivet has already pointed this out in his review of this version of 
our patch.

>   uint32_t bucket_idx, idx, position;
>   struct rte_hash_key *next_key;
>   
> - RETURN_IF_TRUE(((h == NULL) || (next == NULL)), -EINVAL);
> + RETURN_IF_TRUE(((state == NULL) || (key == NULL) ||
> + (data == NULL)), -EINVAL);
> +
> + __state = (struct rte_hash_iterator_istate *)state;
>   
> - const uint32_t total_entries = h->num_buckets * RTE_HASH_BUCKET_ENTRIES;
>   /* Out of bounds */
> - if (*next >= total_entries)
> + if (__state->next >= __state->total_entries)
>   return -ENOENT;
>   
> 'if (__state->next == 0)' is required to avoid creating 
> 'rte_hash_iterator_init' API.

The argument to keep _init() is presented above in this email.

>   /* Calculate bucket and index of current iterator */
> - bucket_idx = *next / RTE_HASH_BUCKET_ENTRIES;
> - idx = *next % RTE_HASH_BUCKET_ENTRIES;
> + bucket_idx = __state->next / RTE_HASH_BUCKET_ENTRIES;
> + idx = __state->next % RTE_HASH_BUCKET_ENTRIES;
>   
>   /* If current position is empty, go to the next one */
> - while (h->buckets[bucket_idx].key_idx[idx] == EMPTY_SLOT) {
> - (*next)++;
> + while (__state->h->buckets[bucket_idx].key_idx[idx] == EMPTY_SLOT) {
> + __state->next++;
>   /* End of table */
> - if (*next == total_entries)
> + if (__state->next == __state->total_entries)
>  

[dpdk-dev] [PATCH v1] examples/ipsec-secgw: increase the number of dev mappings

[Anoob Joseph]

Increasing the number of cdev mappings to accommodate usage of crypto
devices with larger number of capabilities, with higher number of cores.

Required mappings : ([no of ciphers] * [no of auth] + [aead algos]) *
[no of cores]

Signed-off-by: Ankur Dwivedi 
Signed-off-by: Anoob Joseph 
---
v1:
* Fixed typo in description

 examples/ipsec-secgw/ipsec-secgw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/ipsec-secgw/ipsec-secgw.c 
b/examples/ipsec-secgw/ipsec-secgw.c
index b45b87b..ce5365a 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -54,7 +54,7 @@
 #define NB_MBUF(32000)
 
 #define CDEV_QUEUE_DESC 2048
-#define CDEV_MAP_ENTRIES 1024
+#define CDEV_MAP_ENTRIES 16384
 #define CDEV_MP_NB_OBJS 2048
 #define CDEV_MP_CACHE_SZ 64
 #define MAX_QUEUE_PAIRS 1
-- 
2.7.4

Re: [dpdk-dev] [PATCH 1/3] security: support pdcp protocol

[Joseph, Anoob]

Hi Akhil,

Please see inline.

Thanks,
Anoob

On 28-08-2018 18:31, akhil.go...@nxp.com wrote:

External Email

From: Akhil Goyal 

Signed-off-by: Hemant Agrawal 
Signed-off-by: Akhil Goyal 
---
  doc/guides/prog_guide/rte_security.rst | 90 --
  lib/librte_security/rte_security.c |  4 ++
  lib/librte_security/rte_security.h | 62 ++
  3 files changed, 149 insertions(+), 7 deletions(-)

diff --git a/doc/guides/prog_guide/rte_security.rst 
b/doc/guides/prog_guide/rte_security.rst
index 0812abe77..412fff016 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -10,8 +10,8 @@ The security library provides a framework for management and 
provisioning
  of security protocol operations offloaded to hardware based devices. The
  library defines generic APIs to create and free security sessions which can
  support full protocol offload as well as inline crypto operation with
-NIC or crypto devices. The framework currently only supports the IPSec protocol
-and associated operations, other protocols will be added in future.
+NIC or crypto devices. The framework currently only supports the IPSec and PDCP
+protocol and associated operations, other protocols will be added in future.

  Design Principles
  -
@@ -253,6 +253,46 @@ for any protocol header addition.
  +|+
   V

+PDCP Flow Diagram
+~
+
+.. code-block:: c
+
+Transmitting PDCP Entity  Receiving PDCP Entity
+  |   ^
+  |   +---|---+
+  V   | In order delivery and |
++-|--+| Duplicate detection   |
+| Sequence Numbering ||  (Data Plane only)|
++-|--++---|---+
+  |   |
++-|--++---|--+
+| Header Compression*|| Header Decompression*|
+| (Data-Plane only)  ||   (Data Plane only)  |
++-|--++---|--+
+  |   |
++-|---+   +---|--+
+| Integrity Protection|   |Integrity Verification|
+| (Control Plane only)|   | (Control Plane only) |
++-|---+   +---|--+
++-|---++--|--+
+| Ciphering   || Deciphering |
++-|---++--|--+
++-|---++--|--+
+|   Add PDCP header   || Remove PDCP Header  |
++-|---++--|--+
+  |   |
+  +->>+
+
[Anoob] Which PDCP specification revision is this based on? In the 5G 
specification, even data-plane may undergo integrity protection.

+
+.. note::
+
+* Header Compression and decompression are not supported currently.
+
+Just like IPSec, in case of PDCP also header addition/deletion, cipher/
+de-cipher, integrity protection/verification is done based on the action
+type chosen.
+
  Device Features and Capabilities
  -

@@ -271,7 +311,7 @@ structure in the *DPDK API Reference*.

  Each driver (crypto or ethernet) defines its own private array of capabilities
  for the operations it supports. Below is an example of the capabilities for a
-PMD which supports the IPSec protocol.
+PMD which supports the IPSec and PDCP protocol.

  .. code-block:: c

@@ -298,6 +338,22 @@ PMD which supports the IPSec protocol.
  },
  .crypto_capabilities = pmd_capabilities
  },
+{ /* PDCP Lookaside Protocol offload Data Plane */
+.action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
+.protocol = RTE_SECURITY_PROTOCOL_PDCP,
+.pdcp = {
+.domain = RTE_SECURITY_PDCP_MODE_DATA,
+},
+.crypto_capabilities = pmd_capabilities
+},
+{ /* PDCP Lookaside Protocol offload Control */
+.action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
+.protocol = RTE_SECURITY_PROTOCOL_PDCP,
+.pdcp = {
+.domain = RTE_SECURITY_PDCP_MODE_CONTROL,
+},
+.crypto_capabilities = pmd_capabilities
+},
  {
  .action = RTE_SECURITY_ACTION_TYPE_NONE
  }
@@ -429,6 +485,7 @@ Security Session configuration structure is defined as 
``rte_security_ses

[dpdk-dev] [PATCH] vhost: fix return value on enqueue path

[Tiwei Bie]

Fixes: 62250c1d0978 ("vhost: extract split ring handling from Rx and Tx 
functions")
Fixes: a922401f35cc ("vhost: add Rx support for packed ring")
Cc: sta...@dpdk.org

Signed-off-by: Tiwei Bie 
---
 lib/librte_vhost/virtio_net.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index 99c7afc88..4bfae76a6 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -888,6 +888,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
struct rte_mbuf **pkts, uint32_t count)
 {
struct vhost_virtqueue *vq;
+   uint32_t nb_tx = 0;
 
VHOST_LOG_DEBUG(VHOST_DATA, "(%d) %s\n", dev->vid, __func__);
if (unlikely(!is_valid_virt_queue_idx(queue_id, 0, dev->nr_vring))) {
@@ -915,9 +916,9 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
goto out;
 
if (vq_is_packed(dev))
-   count = virtio_dev_rx_packed(dev, vq, pkts, count);
+   nb_tx = virtio_dev_rx_packed(dev, vq, pkts, count);
else
-   count = virtio_dev_rx_split(dev, vq, pkts, count);
+   nb_tx = virtio_dev_rx_split(dev, vq, pkts, count);
 
 out:
if (dev->features & (1ULL << VIRTIO_F_IOMMU_PLATFORM))
@@ -926,7 +927,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
 out_access_unlock:
rte_spinlock_unlock(&vq->access_lock);
 
-   return count;
+   return nb_tx;
 }
 
 uint16_t
-- 
2.18.0

Re: [dpdk-dev] [PATCH] net/ixgbe: fix ixgbevf link status

[Zhang, Qi Z]

Hi Yanglong:

> -Original Message-
> From: Wu, Yanglong
> Sent: Friday, August 10, 2018 4:10 PM
> To: dev@dpdk.org
> Cc: Xu, Rosen ; Wang, Dong1 ;
> Zhang, Qi Z ; Wu, Yanglong 
> Subject: [PATCH] net/ixgbe: fix ixgbevf link status
> 
> For ixgbevf kernel driver, link status changes from down to up will trigger vf
> kernel driver send IXGBE_VF_RESET message to pf kernel driver, after this, vf
> kernel driver will disable and enable it self. By these series operations, 
> the vf
> kernel driver report link up. Besides, all these operations handles in kernel
> thread.
> For DPDK user space driver, it only gets link status changes from down to up,
> but miss IXGBE_VF_RESET message sending and reset itself.
> If we will add fully implementation of link status change for DPDK user space
> driver, we need take much more modification. We have aligned that for link
> status changes from down to up we only notify link is up, users need to reset
> vf port.

OK, the commit log described the gap between kernel driver and DPDK driver, and 
the workaround which require proper change in application.
But what is the problem the patch is going to fix?, what's the relationship 
between the fix and commit log, I can't figure out.
Basically the patch remove the no_pflink_check branch, so it will always check 
with PF for the link status. I guess this help to guarantee that application 
can always get correct link status, but why we need that commit log here? would 
you explain more?

> 
> Fixes: dc66e5fd01b9 ("net/ixgbe: improve link state check on VF")
> 
> Signed-off-by: Rosen Xu 
> Signed-off-by: Yanglong Wu 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 26b192737..4d5f4441b 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -3865,13 +3865,12 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev,
> 
>  static int
>  ixgbevf_check_link(struct ixgbe_hw *hw, ixgbe_link_speed *speed,
> -int *link_up, int wait_to_complete)
> +int *link_up, __attribute__((unused)) int wait_to_complete)

I think we can just remove "wait_to_complete", right?

>  {
>   /**
>* for a quick link status checking, wait_to_compelet == 0,
>* skip PF link status checking
>*/
> - bool no_pflink_check = wait_to_complete == 0;
>   struct ixgbe_mbx_info *mbx = &hw->mbx;
>   struct ixgbe_mac_info *mac = &hw->mac;
>   uint32_t links_reg, in_msg;
> @@ -3931,15 +3930,6 @@ ixgbevf_check_link(struct ixgbe_hw *hw,
> ixgbe_link_speed *speed,
>   default:
>   *speed = IXGBE_LINK_SPEED_UNKNOWN;
>   }
> -
> - if (no_pflink_check) {
> - if (*speed == IXGBE_LINK_SPEED_UNKNOWN)
> - mac->get_link_status = true;
> - else
> - mac->get_link_status = false;
> -
> - goto out;
> - }
>   /* if the read failed it could just be a mailbox collision, best wait
>* until we are called again and don't report an error
>*/
> @@ -3949,7 +3939,7 @@ ixgbevf_check_link(struct ixgbe_hw *hw,
> ixgbe_link_speed *speed,
>   if (!(in_msg & IXGBE_VT_MSGTYPE_CTS)) {
>   /* msg is not CTS and is NACK we must have lost CTS status */
>   if (in_msg & IXGBE_VT_MSGTYPE_NACK)
> - ret_val = -1;
> + mac->get_link_status = false;
>   goto out;
>   }
> 
> --
> 2.11.0

Re: [dpdk-dev] [RFC] ethdev: add min/max MTU to device info

[Shahaf Shuler]

Wednesday, September 5, 2018 7:42 PM, Stephen Hemminger:
> Subject: [dpdk-dev] [RFC] ethdev: add min/max MTU to device info
> 
> This addresses the usability issue raised by OVS at DPDK Userspace summit.
> It adds general min/max mtu into device info. For compatiablity, and to save
> space, it fits in a hole in existing structure.
> 
> The initial version sets max mtu to normal Ethernet, it is up to PMD to set
> larger value if it supports Jumbo frames.
> 
> Fixing the drivers to use this is trivial and can be done by 18.11.
> Already have some of the patches done.
> 
> Signed-off-by: Stephen Hemminger 

Makes sense.
Acked-by: Shahaf Shuler 

> ---
>  lib/librte_ethdev/rte_ethdev.c | 7 +++  lib/librte_ethdev/rte_ethdev.h
> | 2 ++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 4c320250589a..df0c7536a7c4 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -2408,6 +2408,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct
> rte_eth_dev_info *dev_info)
>   dev_info->rx_desc_lim = lim;
>   dev_info->tx_desc_lim = lim;
>   dev_info->device = dev->device;
> + dev_info->min_mtu = ETHER_MIN_MTU;
> + dev_info->max_mtu = ETHER_MTU;
> 
>   RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
>   (*dev->dev_ops->dev_infos_get)(dev, dev_info); @@ -2471,12
> +2473,17 @@ int  rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)  {
>   int ret;
> + struct rte_eth_dev_info dev_info;
>   struct rte_eth_dev *dev;
> 
>   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>   dev = &rte_eth_devices[port_id];
>   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -
> ENOTSUP);
> 
> + rte_eth_dev_info_get(port_id, &dev_info);
> + if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
> + return -EINVAL;
> +
>   ret = (*dev->dev_ops->mtu_set)(dev, mtu);
>   if (!ret)
>   dev->data->mtu = mtu;
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index 7070e9ab408f..5171a9083288 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1015,6 +1015,8 @@ struct rte_eth_dev_info {
>   const char *driver_name; /**< Device Driver name. */
>   unsigned int if_index; /**< Index to bound host interface, or 0 if
> none.
>   Use if_indextoname() to translate into an interface name. */
> + uint16_t min_mtu;   /**< Minimum MTU allowed */
> + uint16_t max_mtu;   /**< Maximum MTU allowed */
>   const uint32_t *dev_flags; /**< Device flags */
>   uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
>   uint32_t max_rx_pktlen; /**< Maximum configurable length of RX
> pkt. */
> --
> 2.17.1

[dpdk-dev] [PATCH 0/3] introduces the ENETC PMD

[Gagandeep Singh]

This patch set introduces the PMD which integrates
with the existing PCI bus. Document is also part
of the set

Gagandeep Singh (3):
  doc: add usage doc for ENETC PMD
  net/enetc: add ENETC PMD with basic operations
  net/enetc: enable Rx and Tx

 MAINTAINERS |   7 +
 config/common_base  |   5 +
 config/common_linuxapp  |   5 +
 doc/guides/nics/enetc.rst   | 165 
 doc/guides/nics/features/enetc.ini  |  10 +
 doc/guides/nics/index.rst   |   1 +
 drivers/net/Makefile|   1 +
 drivers/net/enetc/Makefile  |  25 ++
 drivers/net/enetc/base/enetc_hw.h   | 220 ++
 drivers/net/enetc/enetc.h   | 111 +
 drivers/net/enetc/enetc_ethdev.c| 271 
 drivers/net/enetc/enetc_logs.h  |  40 ++
 drivers/net/enetc/enetc_rxtx.c  | 447 
 drivers/net/enetc/meson.build   |  11 +
 drivers/net/enetc/rte_pmd_enetc_version.map |   4 +
 drivers/net/meson.build |   1 +
 mk/rte.app.mk   |   1 +
 17 files changed, 1325 insertions(+)
 create mode 100644 doc/guides/nics/enetc.rst
 create mode 100644 doc/guides/nics/features/enetc.ini
 create mode 100644 drivers/net/enetc/Makefile
 create mode 100644 drivers/net/enetc/base/enetc_hw.h
 create mode 100644 drivers/net/enetc/enetc.h
 create mode 100644 drivers/net/enetc/enetc_ethdev.c
 create mode 100644 drivers/net/enetc/enetc_logs.h
 create mode 100644 drivers/net/enetc/enetc_rxtx.c
 create mode 100644 drivers/net/enetc/meson.build
 create mode 100644 drivers/net/enetc/rte_pmd_enetc_version.map

-- 
2.17.1

[dpdk-dev] [PATCH 2/3] net/enetc: add ENETC PMD with basic operations

[Gagandeep Singh]

This patch introduces the enetc PMD with basic
initialisation functions includes probe, teardown,
hardware intialisation

Signed-off-by: Gagandeep Singh 
---
 MAINTAINERS |   1 +
 config/common_base  |   5 +
 config/common_linuxapp  |   5 +
 doc/guides/nics/enetc.rst   |   1 +
 doc/guides/nics/features/enetc.ini  |   2 +
 drivers/net/Makefile|   1 +
 drivers/net/enetc/Makefile  |  24 ++
 drivers/net/enetc/base/enetc_hw.h   | 220 
 drivers/net/enetc/enetc.h   | 111 
 drivers/net/enetc/enetc_ethdev.c| 269 
 drivers/net/enetc/enetc_logs.h  |  40 +++
 drivers/net/enetc/meson.build   |  10 +
 drivers/net/enetc/rte_pmd_enetc_version.map |   4 +
 drivers/net/meson.build |   1 +
 mk/rte.app.mk   |   1 +
 15 files changed, 695 insertions(+)
 create mode 100644 drivers/net/enetc/Makefile
 create mode 100644 drivers/net/enetc/base/enetc_hw.h
 create mode 100644 drivers/net/enetc/enetc.h
 create mode 100644 drivers/net/enetc/enetc_ethdev.c
 create mode 100644 drivers/net/enetc/enetc_logs.h
 create mode 100644 drivers/net/enetc/meson.build
 create mode 100644 drivers/net/enetc/rte_pmd_enetc_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index eaf75b7bf..fac43bd2a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -629,6 +629,7 @@ F: doc/guides/nics/features/nfp*.ini
 
 NXP enetc
 M: Gagandeep Singh 
+F: drivers/net/enetc/
 F: doc/guides/nics/enetc.rst
 F: doc/guides/nics/features/enetc.ini
 
diff --git a/config/common_base b/config/common_base
index 4bcbaf923..474b1da4c 100644
--- a/config/common_base
+++ b/config/common_base
@@ -910,3 +910,8 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
 # Compile the eventdev application
 #
 CONFIG_RTE_APP_EVENTDEV=y
+
+#
+# Compile NXP ENETC PMD Driver
+#
+CONFIG_RTE_LIBRTE_ENETC_PMD=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 9c5ea9d89..485e1467d 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -44,3 +44,8 @@ CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV=y
 CONFIG_RTE_LIBRTE_PMD_DPAA2_SEC=y
 CONFIG_RTE_LIBRTE_PMD_DPAA2_CMDIF_RAWDEV=y
 CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV=y
+
+#
+# NXP ENETC PMD Driver
+#
+CONFIG_RTE_LIBRTE_ENETC_PMD=y
diff --git a/doc/guides/nics/enetc.rst b/doc/guides/nics/enetc.rst
index 067cd474b..688a2fa71 100644
--- a/doc/guides/nics/enetc.rst
+++ b/doc/guides/nics/enetc.rst
@@ -49,6 +49,7 @@ This infrastructure simplifies adding support for IEP and 
facilitates in followi
 ENETC Features
 ~~
 
+- Link Status
 
 NIC Driver (PMD)
 
diff --git a/doc/guides/nics/features/enetc.ini 
b/doc/guides/nics/features/enetc.ini
index fb1bf5989..83b20845a 100644
--- a/doc/guides/nics/features/enetc.ini
+++ b/doc/guides/nics/features/enetc.ini
@@ -4,5 +4,7 @@
 ; Refer to default.ini for the full list of available PMD features.
 ;
 [Features]
+Link status  = Y
+Linux VFIO   = Y
 ARMv8= Y
 Usage doc= Y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 664398de9..3ad436045 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -24,6 +24,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) += dpaa2
 endif
 DIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += e1000
 DIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena
+DIRS-$(CONFIG_RTE_LIBRTE_ENETC_PMD) += enetc
 DIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_FAILSAFE) += failsafe
 DIRS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += fm10k
diff --git a/drivers/net/enetc/Makefile b/drivers/net/enetc/Makefile
new file mode 100644
index 0..3f4ba97da
--- /dev/null
+++ b/drivers/net/enetc/Makefile
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2018 NXP
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_enetc.a
+
+CFLAGS += -O3
+EXPORT_MAP := rte_pmd_enetc_version.map
+LIBABIVER := 1
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_ENETC_PMD) += enetc_ethdev.c
+
+LDLIBS += -lrte_eal
+LDLIBS += -lrte_ethdev
+LDLIBS += -lrte_bus_pci
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/enetc/base/enetc_hw.h 
b/drivers/net/enetc/base/enetc_hw.h
new file mode 100644
index 0..806b26a2c
--- /dev/null
+++ b/drivers/net/enetc/base/enetc_hw.h
@@ -0,0 +1,220 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2018 NXP
+ */
+
+#ifndef _ENETC_HW_H_
+#define _ENETC_HW_H_
+#include 
+
+#define BIT(x) ((uint64_t)1 << ((x)))
+
+/* ENETC device IDs */
+#define ENETC_DEV_ID_VF0xef00
+#define ENETC_DEV_ID   0xe100
+
+/* ENETC register block BAR */
+#define ENETC_BAR_REGS 0x0
+
+/* SI regs, offset: 0h */
+#define ENETC_SIMR 0x0
+#define ENETC_SIMR_EN  BIT(31)
+
+#define ENETC_SIPMAR0

[dpdk-dev] [PATCH 3/3] net/enetc: enable Rx and Tx

[Gagandeep Singh]

Add RX and TX queue setup, datapath functions
and enable the packet parsing

Signed-off-by: Gagandeep Singh 
---
 MAINTAINERS  |   1 +
 drivers/net/enetc/Makefile   |   3 +-
 drivers/net/enetc/enetc_ethdev.c |   6 +-
 drivers/net/enetc/enetc_rxtx.c   | 447 +++
 drivers/net/enetc/meson.build|   3 +-
 5 files changed, 456 insertions(+), 4 deletions(-)
 create mode 100644 drivers/net/enetc/enetc_rxtx.c

diff --git a/MAINTAINERS b/MAINTAINERS
index fac43bd2a..353b5eebb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -629,6 +629,7 @@ F: doc/guides/nics/features/nfp*.ini
 
 NXP enetc
 M: Gagandeep Singh 
+M: Pankaj Chauhan 
 F: drivers/net/enetc/
 F: doc/guides/nics/enetc.rst
 F: doc/guides/nics/features/enetc.ini
diff --git a/drivers/net/enetc/Makefile b/drivers/net/enetc/Makefile
index 3f4ba97da..1f886831a 100644
--- a/drivers/net/enetc/Makefile
+++ b/drivers/net/enetc/Makefile
@@ -16,8 +16,9 @@ LIBABIVER := 1
 # all source are stored in SRCS-y
 #
 SRCS-$(CONFIG_RTE_LIBRTE_ENETC_PMD) += enetc_ethdev.c
+SRCS-$(CONFIG_RTE_LIBRTE_ENETC_PMD) += enetc_rxtx.c
 
-LDLIBS += -lrte_eal
+LDLIBS += -lrte_eal -lrte_mempool
 LDLIBS += -lrte_ethdev
 LDLIBS += -lrte_bus_pci
 
diff --git a/drivers/net/enetc/enetc_ethdev.c b/drivers/net/enetc/enetc_ethdev.c
index 06438835d..67106593f 100644
--- a/drivers/net/enetc/enetc_ethdev.c
+++ b/drivers/net/enetc/enetc_ethdev.c
@@ -37,6 +37,8 @@ static const struct eth_dev_ops enetc_ops = {
.dev_close= enetc_dev_close,
.link_update  = enetc_link_update,
.dev_infos_get= enetc_dev_infos_get,
+   .rx_queue_setup   = enetc_rx_queue_setup,
+   .tx_queue_setup   = enetc_tx_queue_setup,
 };
 
 /**
@@ -61,8 +63,8 @@ enetc_dev_init(struct rte_eth_dev *eth_dev)
 
PMD_INIT_FUNC_TRACE();
eth_dev->dev_ops = &enetc_ops;
-   eth_dev->rx_pkt_burst = NULL;
-   eth_dev->tx_pkt_burst = NULL;
+   eth_dev->rx_pkt_burst = &enetc_recv_pkts;
+   eth_dev->tx_pkt_burst = &enetc_xmit_pkts;
 
rte_eth_copy_pci_info(eth_dev, pci_dev);
 
diff --git a/drivers/net/enetc/enetc_rxtx.c b/drivers/net/enetc/enetc_rxtx.c
new file mode 100644
index 0..b01f64b0c
--- /dev/null
+++ b/drivers/net/enetc/enetc_rxtx.c
@@ -0,0 +1,447 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2018 NXP
+ */
+
+#include 
+#include 
+#include 
+
+#include "rte_ethdev.h"
+#include "rte_malloc.h"
+#include "rte_memzone.h"
+
+#include "base/enetc_hw.h"
+#include "enetc.h"
+#include "enetc_logs.h"
+
+#define ENETC_RXBD_BUNDLE 8 /* Number of BDs to update at once */
+
+static inline int enetc_bd_unused(struct enetc_bdr *bdr)
+{
+   if (bdr->next_to_clean > bdr->next_to_use)
+   return bdr->next_to_clean - bdr->next_to_use - 1;
+
+   return bdr->bd_count + bdr->next_to_clean - bdr->next_to_use - 1;
+}
+
+static bool enetc_clean_tx_ring(struct enetc_bdr *tx_ring)
+{
+   int tx_frm_cnt = 0;
+   struct enetc_swbd *tx_swbd;
+   int i;
+
+   i = tx_ring->next_to_clean;
+   tx_swbd = &tx_ring->q_swbd[i];
+   while ((int)(enetc_rd_reg(tx_ring->tcisr) & ENETC_TBCISR_IDX_MASK) != 
i) {
+   rte_pktmbuf_free(tx_swbd->buffer_addr);
+   tx_swbd->buffer_addr = NULL;
+   tx_swbd++;
+   i++;
+   if (unlikely(i == tx_ring->bd_count)) {
+   i = 0;
+   tx_swbd = &tx_ring->q_swbd[0];
+   }
+
+   tx_frm_cnt++;
+   }
+   tx_ring->next_to_clean = i;
+   return tx_frm_cnt++;
+}
+
+uint16_t enetc_xmit_pkts(void *tx_queue,
+   struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts)
+{
+   struct enetc_swbd *tx_swbd;
+   int i, start;
+   struct enetc_tx_bd *txbd;
+   struct enetc_bdr *tx_ring = (struct enetc_bdr *)tx_queue;
+
+   i = tx_ring->next_to_use;
+   start = 0;
+   while (nb_pkts--) {
+   enetc_clean_tx_ring(tx_ring);
+
+   tx_ring->q_swbd[i].buffer_addr = tx_pkts[start];
+
+   txbd = ENETC_TXBD(*tx_ring, i);
+   tx_swbd = &tx_ring->q_swbd[i];
+   txbd->frm_len = tx_pkts[start]->pkt_len;
+   txbd->buf_len = txbd->frm_len;
+   txbd->flags = rte_cpu_to_le_16(ENETC_TXBD_FLAGS_F);
+   txbd->addr =
+   (uint64_t)rte_cpu_to_le_64(tx_swbd->buffer_addr->buf_addr +
+   tx_swbd->buffer_addr->data_off);
+   i++;
+   start++;
+   if (unlikely(i == tx_ring->bd_count))
+   i = 0;
+   }
+   tx_ring->next_to_use = i;
+   enetc_wr_reg(tx_ring->tcir, i);
+   return start;
+}
+
+static int enetc_refill_rx_ring(struct enetc_bdr *rx_ring, const int buff_cnt)
+{
+   struct enetc_swbd *rx_swbd;
+   union enetc_rx_bd *rxbd;
+   int i, j;
+
+   i = rx_ring

[dpdk-dev] [PATCH 1/3] doc: add usage doc for ENETC PMD

[Gagandeep Singh]

Add enetc usage document to compile and run the
DPDK application on enetc supported platform.
This document introduces the enetc driver, supported
platforms and supported features.

Signed-off-by: Gagandeep Singh 
---
 MAINTAINERS|   5 +
 doc/guides/nics/enetc.rst  | 164 +
 doc/guides/nics/features/enetc.ini |   8 ++
 doc/guides/nics/index.rst  |   1 +
 4 files changed, 178 insertions(+)
 create mode 100644 doc/guides/nics/enetc.rst
 create mode 100644 doc/guides/nics/features/enetc.ini

diff --git a/MAINTAINERS b/MAINTAINERS
index 9fd258fad..eaf75b7bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -627,6 +627,11 @@ F: drivers/net/nfp/
 F: doc/guides/nics/nfp.rst
 F: doc/guides/nics/features/nfp*.ini
 
+NXP enetc
+M: Gagandeep Singh 
+F: doc/guides/nics/enetc.rst
+F: doc/guides/nics/features/enetc.ini
+
 NXP dpaa
 M: Hemant Agrawal 
 M: Shreyansh Jain 
diff --git a/doc/guides/nics/enetc.rst b/doc/guides/nics/enetc.rst
new file mode 100644
index 0..067cd474b
--- /dev/null
+++ b/doc/guides/nics/enetc.rst
@@ -0,0 +1,164 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+   Copyright 2018 NXP
+
+ENETC Poll Mode Driver
+==
+
+The ENETC NIC PMD (**librte_pmd_enetc**) provides poll mode driver
+support for the inbuilt NIC found in the **NXP LS1028** SoC.
+
+More information can be found at `NXP Official Website
+`_.
+
+ENETC
+-
+
+This section provides an overview of the NXP ENETC
+and how it is integrated into the DPDK.
+
+Contents summary
+
+- ENETC overview
+- ENETC features
+- PCI bus driver
+- NIC driver
+- Supported ENETC SoCs
+- Prerequisites
+- Driver compilation and testing
+
+ENETC Overview
+~~
+
+Reference: `NXP ENETC OVERVIEW 
`_.
+
+ENETC is a PCI Integrated End Point(IEP). IEP implements
+peripheral devices in an SoC such that software sees them as PCIe device.
+ENETC is an evolution of BDR(Buffer Descriptor Ring) based networking
+IPs, introducing several changes intended to bring NXP IP up to date
+with developments in the industry and support new areas like virtualization.
+A major development is the use of a PCI bus for presentation of the IP
+to software, which has implications to the software architecture.
+
+This infrastructure simplifies adding support for IEP and facilitates in 
following:
+
+- Device discovery and location
+- Resource requirement discovery and allocation (e.g. interrupt assignment,
+  device register address)
+- Event reporting
+
+ENETC Features
+~~
+
+
+NIC Driver (PMD)
+
+
+ENETC PMD is traditional DPDK PMD which provides necessary interface between
+RTE framework and ENETC internal drivers.
+
+- Driver registers the device vendor table in PCI subsystem.
+- RTE framework scans the PCI bus for connected devices.
+- This scanning will invoke the probe function of ENETC driver.
+- The probe function will set the basic device registers and also setups BD 
rings.
+- On packet Rx the respective BD Ring status bit is set which is then used for
+  packet processing.
+- Then Tx is done first followed by Rx.
+
+Supported ENETC SoCs
+
+
+- LS1028
+
+Prerequisites
+~
+
+There are three main pre-requisities for executing ENETC PMD on a ENETC
+compatible board:
+
+1. **ARM 64 Tool Chain**
+
+   For example, the `*aarch64* Linaro Toolchain 
`_.
+
+2. **Linux Kernel**
+
+   It can be obtained from `NXP's Github hosting 
`_.
+
+3. **Rootfile system**
+
+   Any *aarch64* supporting filesystem can be used. For example,
+   Ubuntu 15.10 (Wily) or 16.04 LTS (Xenial) userland which can be obtained
+   from `here 
`_.
+
+The following dependencies are not part of DPDK and must be installed
+separately:
+
+- **NXP Linux LSDK**
+
+  NXP Layerscape software development kit (LSDK) includes support for family
+  of QorIQ® ARM-Architecture-based system on chip (SoC) processors
+  and corresponding boards.
+
+  It includes the Linux board support packages (BSPs) for NXP SoCs,
+  a fully operational tool chain, kernel and board specific modules.
+
+  LSDK and related information can be obtained from:  `LSDK 
`_
+
+Driver compilation and testing
+~~
+
+#. Plea

Re: [dpdk-dev] IXGBE throughput loss with 4+ cores

[Saber Rezvani]

On 08/29/2018 11:22 PM, Wiles, Keith wrote: > >> On Aug 29, 2018, at 12:19 PM, 
Saber Rezvani  wrote: >> >> >> >> On 08/29/2018 01:39 AM, 
Wiles, Keith wrote:  On Aug 28, 2018, at 2:16 PM, Saber Rezvani 
 wrote:     On 08/28/2018 11:39 PM, Wiles, 
Keith wrote: > Which version of Pktgen? I just pushed a patch in 3.5.3 to 
fix a performance problem.  I use Pktgen verion 3.0.0, indeed it is O.k as 
far as I have one core. (10 Gb/s) but when I increase the number of core (one 
core per queue) then I loose some performance (roughly 8.5 Gb/s for 8-core). In 
my scenario Pktgen shows it is generating at line rate, but receiving 8.5 Gb/s. 
 Is it because of Pktgen??? >>> Normally Pktgen can receive at line rate up 
to 10G 64 byte frames, which means Pktgen should not be the problem. You can 
verify that by looping the cable from one port to another on the pktgen machine 
to create a external loopback. Then send traffic what ever you can send from 
one port you should be able to receive those packets unless something is 
configured wrong. >>> >>> Please send me the command line for pktgen. >>> >>> 
>>> In pktgen if you have this config -m “[1-4:5-8].0” then you have 4 cores 
sending traffic and 4 core receiving packets. >>> >>> In this case the TX cores 
will be sending the packets on all 4 lcores to the same port. On the rx side 
you have 4 cores polling 4 rx queues. The rx queues are controlled by RSS, 
which means the RX traffic 5 tuples hash must divide the inbound packets across 
all 4 queues to make sure each core is doing the same amount of work. If you 
are sending only a single packet on the Tx cores then only one rx queue be 
used. >>> >>> I hope that makes sense. >> I think there is a misunderstanding 
of the problem. Indeed the problem is not the Pktgen. >> Here is my command --> 
./app/app/x86_64-native-linuxapp-gcc/pktgen -c ffc -n 4 -w 84:00.0 -w 
84:00.1 --file-prefix pktgen_F2 --socket-mem 1000,2000,1000,1000 -- -T -P -m 
"[18-19:20-21].0, [22:23].1" >> >> The problem is when I run the symmetric_mp 
example for $numberOfProcesses=8 cores, then I have less throughput (roughly 
8.4 Gb/s). but when I run it for $numberOfProcesses=3 cores throughput is 10G. 
>> for i in `seq $numberOfProcesses`; >> do >>  some calculation goes 
here. >> symmetric_mp -c $coremask -n 2 --proc-type=auto -w 0b:00.0 -w 
0b:00.1 --file-prefix sm --socket-mem 4000,1000,1000,1000 -- -p 3 
--num-procs=$numberOfProcesses --proc-id=$procid"; >> . >> done > Most NICs 
have a limited amount of memory on the NIC and when you start to segment that 
memory because you are using more queues it can effect performance. > > In one 
of the NICs if you go over say 6 or 5 queues the memory per queue for Rx/Tx 
packets starts to become a bottle neck as you do not have enough memory in the 
Tx/Rx queues to hold enough packets. This can cause the NIC to drop Rx packets 
because the host can not pull the data from the NIC or Rx ring on the host fast 
enough. This seems to be the problem as the amount of time to process a packet 
on the host has not changed only the amount of buffer space in the NIC as you 
increase queues. > > I am not sure this is your issue, but I figured I would 
state this point. What you said sounded logical, but is there away that I can 
be sure? I mean are there some registers at NIC which show the number of packet 
loss on NIC? or does DPDK have an API which shows the number of packet loss at 
NIC level? > >> I am trying find out what makes this loss! >> >> >> On Aug 
28, 2018, at 12:05 PM, Saber Rezvani  wrote: >> >> 
>> >> On 08/28/2018 08:31 PM, Stephen Hemminger wrote: >>> On Tue, 
28 Aug 2018 17:34:27 +0430 >>> Saber Rezvani  wrote: 
>>>  Hi,    I have run 
multi_process/symmetric_mp example in DPDK example directory.  For a 
one process its throughput is line rate but as I increase the  number 
of cores I see decrease in throughput. For example, If the number  of 
queues set to 4 and each queue assigns to a single core, then the  
throughput will be something about 9.4. if 8 queues, then throughput  
will be 8.5.   I have read the following, but it was not 
convincing.   
http://mails.dpdk.org/archives/dev/2015-October/024960.html   
 I am eagerly looking forward to hearing from you, all.  
  Best wishes,   Saber   
>>> Not completely surprising. If you have more cores than packet line rate 
>>> then the number of packets returned for each call to rx_burst will be 
less. >>> With large number of cores, most of the time will be spent doing 
reads of >>> PCI registers for no packets! >> Indeed pktgen says it is 
generating traffic at line rate, but receiving less than 10 Gb/s. So, it that 
case there should be something that causes the re

[dpdk-dev] [PATCH v1 1/2] vhost: introduce rte_vdpa_get_device_num api

[Xiaolong Ye]

Signed-off-by: Xiaolong Ye 
---
 lib/librte_vhost/rte_vdpa.h | 3 +++
 lib/librte_vhost/vdpa.c | 6 ++
 2 files changed, 9 insertions(+)

diff --git a/lib/librte_vhost/rte_vdpa.h b/lib/librte_vhost/rte_vdpa.h
index 90465ca26..b8223e337 100644
--- a/lib/librte_vhost/rte_vdpa.h
+++ b/lib/librte_vhost/rte_vdpa.h
@@ -84,4 +84,7 @@ rte_vdpa_find_device_id(struct rte_vdpa_dev_addr *addr);
 struct rte_vdpa_device * __rte_experimental
 rte_vdpa_get_device(int did);
 
+/* Get current available vdpa device number */
+int __rte_experimental
+rte_vdpa_get_device_num(void);
 #endif /* _RTE_VDPA_H_ */
diff --git a/lib/librte_vhost/vdpa.c b/lib/librte_vhost/vdpa.c
index c82fd4370..c2c5dff1d 100644
--- a/lib/librte_vhost/vdpa.c
+++ b/lib/librte_vhost/vdpa.c
@@ -113,3 +113,9 @@ rte_vdpa_get_device(int did)
 
return vdpa_devices[did];
 }
+
+int
+rte_vdpa_get_device_num(void)
+{
+   return vdpa_device_num;
+}
-- 
2.18.0.rc1.1.g6f333ff2f

[dpdk-dev] [PATCH v1 2/2] examples/vdpa: add a new sample for vdpa

[Xiaolong Ye]

From: Xiao Wang 

This patch adds a sample which creates vhost-user socket based on
vdpa driver. vdpa driver can help to set up vhost datapath so this
app doesn't need to spend a dedicated worker thread on vhost
enqueue/dequeue operations.

Below are setup steps for your reference (using IFC driver):

1. Make sure your kernnel vhost module and QEMU support vhost-user.
   - OS: CentOS 7.4
   - QEMU: 2.10.1
   - Guest OS: CentOS 7.2

2. Bind VFIO-pci to VF
   a) modprobe vfio-pci
   d) ./usertools/dpdk-devbind.py -b vfio-pci 06:00.2 06:00.3

3. Start vdpa sample
./examples/vdpa/build/vdpa --log-level=9 -c 0x10 -n 4 --socket-mem
1024,1024  -w :06:00.2,vdpa=1 -w :06:00.3,vdpa=1   --
--iface  /tmp/vhost-user- (or use interactive mode to create vdpa
ports)

4. Start two VMs
   ./qemu-2.10.1/x86_64-softmmu/qemu-system-x86_64 -cpu host -enable-kvm \
   
   -mem-prealloc \
   -chardev socket,id=char0,path=/tmp/vhost-user-0 \
   -netdev type=vhost-user,id=vdpa,chardev=char0,vhostforce \
   -device virtio-net-pci,netdev=vdpa,mac=00:aa:bb:cc:dd:ee \

   ./qemu-2.10.1/x86_64-softmmu/qemu-system-x86_64 -cpu host -enable-kvm \
   
   -mem-prealloc \
   -chardev socket,id=char0,path=/tmp/vhost-user-1 \
   -netdev type=vhost-user,id=vdpa,chardev=char0,vhostforce \
   -device virtio-net-pci,netdev=vdpa,mac=00:aa:bb:cc:dd:ff \

5. Login two VMs and configure the ip, verify the network connection via
   ping.

Signed-off-by: Xiao Wang 
Signed-off-by: Xiaolong Ye 
---
 examples/vdpa/Makefile|  32 
 examples/vdpa/main.c  | 327 ++
 examples/vdpa/meson.build |  11 ++
 3 files changed, 370 insertions(+)
 create mode 100644 examples/vdpa/Makefile
 create mode 100644 examples/vdpa/main.c
 create mode 100644 examples/vdpa/meson.build

diff --git a/examples/vdpa/Makefile b/examples/vdpa/Makefile
new file mode 100644
index 0..42672a2bc
--- /dev/null
+++ b/examples/vdpa/Makefile
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2018 Intel Corporation
+
+ifeq ($(RTE_SDK),)
+$(error "Please define RTE_SDK environment variable")
+endif
+
+# Default target, can be overridden by command line or environment
+RTE_TARGET ?= x86_64-native-linuxapp-gcc
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+ifneq ($(CONFIG_RTE_EXEC_ENV),"linuxapp")
+$(info This application can only operate in a linuxapp environment, \
+please change the definition of the RTE_TARGET environment variable)
+all:
+else
+
+# binary name
+APP = vdpa
+
+# all source are stored in SRCS-y
+SRCS-y := main.c
+
+CFLAGS += -O2 -D_FILE_OFFSET_BITS=64
+CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -D_GNU_SOURCE
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+
+include $(RTE_SDK)/mk/rte.extapp.mk
+
+endif
diff --git a/examples/vdpa/main.c b/examples/vdpa/main.c
new file mode 100644
index 0..b19d7a217
--- /dev/null
+++ b/examples/vdpa/main.c
@@ -0,0 +1,327 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_PATH_LEN 128
+#define MAX_VDPA_SAMPLE_PORTS 1024
+
+struct vdpa_port {
+   char ifname[MAX_PATH_LEN];
+   int did;
+   int vid;
+};
+
+struct vdpa_port vports[MAX_VDPA_SAMPLE_PORTS];
+
+char iface[MAX_PATH_LEN];
+int devcnt;
+int dev_id;
+uint8_t interactive;
+
+/* display usage */
+static void
+vdpa_usage(const char *prgname)
+{
+   printf("Usage: %s [EAL options] -- "
+"[--interactive|-i] "
+"[--iface PATH]\n"
+"  --interactive: run in interactive 
mode.\n"
+"  --iface : specify the path prefix 
of the socket files, e.g. /tmp/vhost-user-\n",
+prgname);
+}
+
+static int
+parse_args(int argc, char **argv)
+{
+   static const char *short_option = "i";
+   static struct option long_option[] = {
+   {"iface", required_argument, NULL, 0},
+   {"interactive", 0, 0, 0},
+   {NULL, 0, 0, 0},
+   };
+   int opt, idx;
+   char *prgname = argv[0];
+
+   while ((opt = getopt_long(argc, argv, short_option, long_option, &idx))
+   != EOF) {
+   switch (opt) {
+   case 'i':
+   printf("Interactive-mode selected\n");
+   interactive = 1;
+   break;
+   /* long options */
+   case 0:
+   if (strncmp(long_option[idx].name, "iface",
+   MAX_PATH_LEN) == 0) {
+   strncpy(iface, optarg, MAX_PATH_LEN);
+   printf("iface %s\n", iface);
+   }
+   if (!strcmp(long_option[idx].name, "interactive")) {
+ 

Re: [dpdk-dev] [RFC] ethdev: add min/max MTU to device info

[Andrew Rybchenko]

On 09/05/2018 07:41 PM, Stephen Hemminger wrote:

This addresses the usability issue raised by OVS at DPDK Userspace
summit. It adds general min/max mtu into device info. For compatiablity,
and to save space, it fits in a hole in existing structure.


It is true for amd64, but it looks like it is false on 32-bit. So, ABI 
breakage.



The initial version sets max mtu to normal Ethernet, it is up to
PMD to set larger value if it supports Jumbo frames.

Fixing the drivers to use this is trivial and can be done by 18.11.
Already have some of the patches done.

Signed-off-by: Stephen Hemminger 
---
  lib/librte_ethdev/rte_ethdev.c | 7 +++
  lib/librte_ethdev/rte_ethdev.h | 2 ++
  2 files changed, 9 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 4c320250589a..df0c7536a7c4 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2408,6 +2408,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct 
rte_eth_dev_info *dev_info)
dev_info->rx_desc_lim = lim;
dev_info->tx_desc_lim = lim;
dev_info->device = dev->device;
+   dev_info->min_mtu = ETHER_MIN_MTU;
+   dev_info->max_mtu = ETHER_MTU;
  
  	RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);

(*dev->dev_ops->dev_infos_get)(dev, dev_info);
@@ -2471,12 +2473,17 @@ int
  rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
  {
int ret;
+   struct rte_eth_dev_info dev_info;
struct rte_eth_dev *dev;
  
  	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);

dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
  
+	rte_eth_dev_info_get(port_id, &dev_info);

+   if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
+   return -EINVAL;
+


The check breaks set MTU to value larger than ETHER_MTU for not
updated drivers. So, IMHO, it should be pushed only with appropriate
updates in all drivers which support bigger MTU.


ret = (*dev->dev_ops->mtu_set)(dev, mtu);
if (!ret)
dev->data->mtu = mtu;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 7070e9ab408f..5171a9083288 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1015,6 +1015,8 @@ struct rte_eth_dev_info {
const char *driver_name; /**< Device Driver name. */
unsigned int if_index; /**< Index to bound host interface, or 0 if none.
Use if_indextoname() to translate into an interface name. */
+   uint16_t min_mtu;   /**< Minimum MTU allowed */
+   uint16_t max_mtu;   /**< Maximum MTU allowed */
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */

[dpdk-dev] [PATCH] net/mlx5: fix wrong representor port link status

[Xueming Li]

Current code uses PF links status for representor port, not the representor
interface itself. This caused wrong representor port link status when
toggling linterface up or down.

Fixes: 5a4b8e2612c5 ("net/mlx5: probe all port representors")
Cc: adrien.mazarg...@6wind.com

Signed-off-by: Xueming Li 
---
 drivers/net/mlx5/mlx5_ethdev.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 34c5b95..08b22ce 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -627,7 +627,7 @@ struct ethtool_link_settings {
int link_speed = 0;
int ret;
 
-   ret = mlx5_ifreq(dev, SIOCGIFFLAGS, &ifr, 1);
+   ret = mlx5_ifreq(dev, SIOCGIFFLAGS, &ifr, 0);
if (ret) {
DRV_LOG(WARNING, "port %u ioctl(SIOCGIFFLAGS) failed: %s",
dev->data->port_id, strerror(rte_errno));
@@ -636,6 +636,7 @@ struct ethtool_link_settings {
memset(&dev_link, 0, sizeof(dev_link));
dev_link.link_status = ((ifr.ifr_flags & IFF_UP) &&
(ifr.ifr_flags & IFF_RUNNING));
+   memset(&ifr, 0, sizeof(ifr));
ifr.ifr_data = (void *)&edata;
ret = mlx5_ifreq(dev, SIOCETHTOOL, &ifr, 1);
if (ret) {
@@ -698,7 +699,7 @@ struct ethtool_link_settings {
uint64_t sc;
int ret;
 
-   ret = mlx5_ifreq(dev, SIOCGIFFLAGS, &ifr, 1);
+   ret = mlx5_ifreq(dev, SIOCGIFFLAGS, &ifr, 0);
if (ret) {
DRV_LOG(WARNING, "port %u ioctl(SIOCGIFFLAGS) failed: %s",
dev->data->port_id, strerror(rte_errno));
@@ -707,6 +708,7 @@ struct ethtool_link_settings {
memset(&dev_link, 0, sizeof(dev_link));
dev_link.link_status = ((ifr.ifr_flags & IFF_UP) &&
(ifr.ifr_flags & IFF_RUNNING));
+   memset(&ifr, 0, sizeof(ifr));
ifr.ifr_data = (void *)&gcmd;
ret = mlx5_ifreq(dev, SIOCETHTOOL, &ifr, 1);
if (ret) {
-- 
1.8.3.1