Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter

[Jerin Jacob]

-Original Message-
> Date: Tue, 24 Apr 2018 18:13:22 +0530
> From: Abhinandan Gujjar 
> To: jerin.ja...@caviumnetworks.com, hemant.agra...@nxp.com,
>  akhil.go...@nxp.com, dev@dpdk.org
> CC: narender.vang...@intel.com, abhinandan.guj...@intel.com,
>  nikhil@intel.com, gage.e...@intel.com
> Subject: [v2,1/6] eventdev: introduce event crypto adapter
> X-Mailer: git-send-email 1.9.1
> 
> Signed-off-by: Abhinandan Gujjar 
> Signed-off-by: Nikhil Rao 
> Signed-off-by: Gage Eads 
> ---
>  lib/librte_eventdev/rte_event_crypto_adapter.h | 532 
> +
>  1 file changed, 532 insertions(+)
>  create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h
> 
> diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h 
> b/lib/librte_eventdev/rte_event_crypto_adapter.h
> new file mode 100644
> index 000..aa4f32c
> --- /dev/null
> +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
> @@ -0,0 +1,532 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2017-2018 Intel Corporation
> + */
> +
> +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_
> +#define _RTE_EVENT_CRYPTO_ADAPTER_

1) Please rebase to next-eventdev tree, If everything goes well, we will
try to add it in RC2.

2) Please update MAINTAINERS section in this patch set with just one 
rte_event_crypto_adapter.h file and as when you add new files update the
new files in the MAINTAINERS file

> +
> +/**
> + * @file
> + *
> + * RTE Event crypto adapter
> + *
> + * Eventdev library provides couple of adapters to bridge between various
> + * components for providing new event source. The event crypto adapter is
> + * one of those adapter which is intended to bridge between event devices
> + * and crypto devices.
> + *
> + * The crypto adapter adds support to enqueue/dequeue crypto operations to/
> + * from event device. The packet flow between crypto device and the event
> + * device can be accomplished using both SW and HW based transfer mechanisms.
> + * The adapter uses an EAL service core function for SW based packet transfer
> + * and uses the eventdev PMD functions to configure HW based packet transfer
> + * between the crypto device and the event device.
> + *
> + * The application can choose to submit a crypto operation directly to
> + * crypto device or send it to the crypto adapter via eventdev, the crypto
> + * adapter then submits the crypto operation to the crypto device.
> + * The first mode is known as the dequeue only (DEQ_ONLY) mode and the
> + * second as the enqueue - dequeue (ENQ_DEQ) mode. The choice of mode can
> + * be specified while creating the adapter.

We need to tell why these modes are required or use of it/when to use
what like, OPS_NEW does not maintain ingress order. example, use of DEQ_ONLY 
with
FWD or ENQ_DEQ mode to use ingress order maintenance.


> + *
> + *
> + * Working model of DEQ_ONLY mode:
> + * ===

This diagram is not rendering correctly in doxygen html file.
check lib/librte_eventdev/rte_eventdev.h as reference.

invoke "make doc-api-html" to see the html output.


> + *
> + * +--+ +--+
> + * Events  |  | | Crypto stage |
> + * <-->| Event device |>| + enqueue to |
> + * |  | |   cryptodev  |
> + * +--+ +--+
> + * event  ^|
> + * enqueue||  crypto
> + *|v enqueue
> + * +--+ +--+
> + * |  | |  |
> + * |Crypto adapter|<|  Cryptodev   |
> + * |  | |  |
> + * +--+ +--+
> + *

I think, we need to add sequence of numbers scheme to define the
data flow for this diagram as it is complex.

something like, --[1]> and describe the action means.

> + * In the DEQ_ONLY mode, application submits crypto operations directly to
> + * crypto device. The adapter then dequeues crypto completions from crypto
> + * device and enqueue events to the event device.
> + * In this mode, application needs to specify event information (response
> + * information) which is needed to enqueue an event after the crypto 
> operation
> + * is completed.
> + *
> + *
> + * Working model of ENQ_DEQ mode:
> + * ==
> + *
> + * +--+ +--+
> + * Events  |  | |  |
> + * <-->| Event device |>| Crypto stage |
> + * |  | |  |
> + * +--+ +--+

I think, instead of "crypto stage", it is  better to call it as "atomic stage" 
something
like that where the source queue's(ORDERED mode) ingress order will be updated
in that stage and then enqueue to cryptodev happens for ingress order 
maintenance.

Re: [dpdk-dev] [v2, 2/6] eventdev: add APIs and PMD callbacks for crypto adapter

[Jerin Jacob]

-Original Message-
> Date: Tue, 24 Apr 2018 18:13:23 +0530
> From: Abhinandan Gujjar 
> To: jerin.ja...@caviumnetworks.com, hemant.agra...@nxp.com,
>  akhil.go...@nxp.com, dev@dpdk.org
> CC: narender.vang...@intel.com, abhinandan.guj...@intel.com,
>  nikhil@intel.com, gage.e...@intel.com
> Subject: [v2,2/6] eventdev: add APIs and PMD callbacks for crypto adapter
> X-Mailer: git-send-email 1.9.1
> 
> Signed-off-by: Abhinandan Gujjar 
> ---
>  drivers/event/sw/sw_evdev.c|  13 +++
>  lib/librte_eventdev/rte_eventdev.c |  25 +
>  lib/librte_eventdev/rte_eventdev.h |  52 +
>  lib/librte_eventdev/rte_eventdev_pmd.h | 189 
> +
>  4 files changed, 279 insertions(+)
> 
> diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
> index dcb6551..10f0e1a 100644
> --- a/drivers/event/sw/sw_evdev.c
> +++ b/drivers/event/sw/sw_evdev.c
> @@ -480,6 +480,17 @@
>   return 0;
>  }
>  
> +static int
> +sw_crypto_adapter_caps_get(const struct rte_eventdev *dev,
> +const struct rte_cryptodev *cdev,
> +uint32_t *caps)
> +{
> + RTE_SET_USED(dev);
> + RTE_SET_USED(cdev);
> + *caps = RTE_EVENT_CRYPTO_ADAPTER_SW_CAP;
> + return 0;
> +}
> +
>  static void
>  sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
>  {
> @@ -809,6 +820,8 @@ static int32_t sw_sched_service_func(void *args)
>  
>   .timer_adapter_caps_get = sw_timer_adapter_caps_get,
>  
> + .crypto_adapter_caps_get = sw_crypto_adapter_caps_get,
> +
>   .xstats_get = sw_xstats_get,
>   .xstats_get_names = sw_xstats_get_names,
>   .xstats_get_by_name = sw_xstats_get_by_name,
> diff --git a/lib/librte_eventdev/rte_eventdev.c 
> b/lib/librte_eventdev/rte_eventdev.c
> index 3f016f4..7ca9fd1 100644
> --- a/lib/librte_eventdev/rte_eventdev.c
> +++ b/lib/librte_eventdev/rte_eventdev.c
> @@ -29,6 +29,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "rte_eventdev.h"
>  #include "rte_eventdev_pmd.h"
> @@ -145,6 +147,29 @@
>   : 0;
>  }
>  
> +int __rte_experimental
> +rte_event_crypto_adapter_caps_get(uint8_t dev_id, uint8_t cdev_id,
> +   uint32_t *caps)
> +{
> + struct rte_eventdev *dev;
> + struct rte_cryptodev *cdev;
> +
> + RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
> + if (!rte_cryptodev_pmd_is_valid_dev(cdev_id))
> + return -EINVAL;
> +
> + dev = &rte_eventdevs[dev_id];
> + cdev = rte_cryptodev_pmd_get_dev(cdev_id);
> +
> + if (caps == NULL)
> + return -EINVAL;
> + *caps = 0;
> +
> + return dev->dev_ops->crypto_adapter_caps_get ?
> + (*dev->dev_ops->crypto_adapter_caps_get)
> + (dev, cdev, caps) : -ENOTSUP;
> +}
> +
>  static inline int
>  rte_event_dev_queue_config(struct rte_eventdev *dev, uint8_t nb_queues)
>  {
> diff --git a/lib/librte_eventdev/rte_eventdev.h 
> b/lib/librte_eventdev/rte_eventdev.h
> index 8297f24..9822747 100644
> --- a/lib/librte_eventdev/rte_eventdev.h
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -8,6 +8,8 @@
>  #ifndef _RTE_EVENTDEV_H_
>  #define _RTE_EVENTDEV_H_
>  
> +#include 
> +
>  /**
>   * @file
>   *
> @@ -1135,6 +1137,56 @@ struct rte_event {
>  int __rte_experimental
>  rte_event_timer_adapter_caps_get(uint8_t dev_id, uint32_t *caps);
>  
> +/* Crypto adapter capability bitmap flag */
> +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW   0x1
> +/**< Flag indicates HW is capable of generating events.

events in RTE_EVENT_OP_NEW enqueue operation

> + * Cryptodev will send packets to the event device as new events
> + * using an internal event port.
> + */
> +
> +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD   0x2
> +/**< Flag indicates HW is capable of generating events.

events in RTE_EVENT_OP_FWD enqueue operation

> + * Cryptodev will send packets to the event device as forwarded event
> + * using an internal event port.
> + */
> +
> +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND  0x4
> +/**< Flag indicates HW is capable of mapping crypto queue pair to
> + * event queue.
> + */
> +
> +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA   0x8
> +/**< Flag indicates HW/SW suports a mechanism to store and retrieve
> + * the private data information along with the crypto session.
> + */
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Retrieve the event device's crypto adapter capabilities for the
> + * specified cryptodev device
> + *
> + * @param dev_id
> + *   The identifier of the device.
> + *
> + * @param cdev_id
> + *   The identifier of the cryptodev device.
> + *
> + * @param[out] caps
> + *   A pointer to memory filled with event adapter capabilities.
> + *   It is expected to be p

Re: [dpdk-dev] [v2, 3/6] eventdev: add crypto adapter implementation

[Jerin Jacob]

-Original Message-
> Date: Tue, 24 Apr 2018 18:13:24 +0530
> From: Abhinandan Gujjar 
> To: jerin.ja...@caviumnetworks.com, hemant.agra...@nxp.com,
>  akhil.go...@nxp.com, dev@dpdk.org
> CC: narender.vang...@intel.com, abhinandan.guj...@intel.com,
>  nikhil@intel.com, gage.e...@intel.com
> Subject: [v2,3/6] eventdev: add crypto adapter implementation
> X-Mailer: git-send-email 1.9.1
> 
> Signed-off-by: Abhinandan Gujjar 
> Signed-off-by: Nikhil Rao 
> Signed-off-by: Gage Eads 
> ---
> +
> +/* Per crypto device information */
> +struct crypto_device_info {
> + /* Pointer to cryptodev */
> + struct rte_cryptodev *dev;
> + /* Pointer to queue pair info */
> + struct crypto_queue_pair_info *qpairs;
> + /* Next queue pair to be processed */
> + uint16_t next_queue_pair_id;
> + /* Set to indicate cryptodev->eventdev packet
> +  * transfer uses a hardware mechanism
> +  */
> + uint8_t internal_event_port;
> + /* Set to indicate processing has been started */
> + uint8_t dev_started;
> + /* If num_qpairs > 0, the start callback will
> +  * be invoked if not already invoked
> +  */
> + uint16_t num_qpairs;
> +};

Looks like it is used in fastpath, if so add the cache alignment.

> +
> +/* Per queue pair information */
> +struct crypto_queue_pair_info {
> + /* Set to indicate queue pair is enabled */
> + bool qp_enabled;
> + /* Pointer to hold rte_crypto_ops for batching */
> + struct rte_crypto_op **op_buffer;
> + /* No of crypto ops accumulated */
> + uint8_t len;
> +};
> +
> +static struct rte_event_crypto_adapter **event_crypto_adapter;
> +
> +eca_enq_to_cryptodev(struct rte_event_crypto_adapter *adapter,
> +  struct rte_event *ev, unsigned int cnt)
> +{
> + struct rte_event_crypto_adapter_stats *stats = &adapter->crypto_stats;
> + union rte_event_crypto_metadata *m_data = NULL;
> + struct crypto_queue_pair_info *qp_info = NULL;
> + struct rte_crypto_op *crypto_op;
> + unsigned int i, n = 0;
> + uint16_t qp_id = 0, len = 0, ret = 0;

Please review the explicit '0' assignment.

> + uint8_t cdev_id = 0;
> +
> + stats->event_dequeue_count += cnt;
> +
> + for (i = 0; i < cnt; i++) {
> + crypto_op = ev[i].event_ptr;
> + if (crypto_op == NULL)
> + continue;
> + if (crypto_op->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
> + m_data = rte_cryptodev_sym_session_get_private_data(
> + crypto_op->sym->session);
> + if (m_data == NULL) {
> + rte_pktmbuf_free(crypto_op->sym->m_src);
> + rte_crypto_op_free(crypto_op);
> + continue;
> + }
> +
> + cdev_id = m_data->request_info.cdev_id;
> + qp_id = m_data->request_info.queue_pair_id;
> + qp_info = &adapter->cdevs[cdev_id].qpairs[qp_id];
> + if (qp_info == NULL) {
> + rte_pktmbuf_free(crypto_op->sym->m_src);
> + rte_crypto_op_free(crypto_op);
> + continue;
> + }
> + len = qp_info->len;
> + qp_info->op_buffer[len] = crypto_op;
> + len++;
> +
> +int __rte_experimental
> +rte_event_crypto_adapter_queue_pair_add(uint8_t id,
> + uint8_t cdev_id,
> + int32_t queue_pair_id,
> + const struct rte_event_crypto_queue_pair_conf *conf)
> +{
> + struct rte_event_crypto_adapter *adapter;
> + struct rte_eventdev *dev;
> + struct crypto_device_info *dev_info;
> + uint32_t cap;
> + int ret;
> +
> + RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
> +
> + if (!rte_cryptodev_pmd_is_valid_dev(cdev_id)) {
> + RTE_EDEV_LOG_ERR("Invalid dev_id=%" PRIu8, cdev_id);
> + return -EINVAL;
> + }
> +
> + adapter = eca_id_to_adapter(id);
> + if (adapter == NULL)
> + return -EINVAL;
> +
> + dev = &rte_eventdevs[adapter->eventdev_id];
> + ret = rte_event_crypto_adapter_caps_get(adapter->eventdev_id,
> + cdev_id,
> + &cap);
> + if (ret) {
> + if ((cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW &&
> +  adapter->mode == RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ) || cap) {
> + rte_spinlock_lock(&adapter->lock);
> + ret = eca_init_service(adapter, id);
> + if (ret == 0)
> + ret = eca_add_queue_pair(adapter, cdev_id,
> + queue_pair_id);
> + rte_spinlock_unlock(&adapter->lock);
> + }
> +
> + if (ret)
> + return ret;

Re: [dpdk-dev] [v2, 5/6] eventdev: add event crypto adapter to meson build system

[Jerin Jacob]

-Original Message-
> Date: Tue, 24 Apr 2018 18:13:26 +0530
> From: Abhinandan Gujjar 
> To: jerin.ja...@caviumnetworks.com, hemant.agra...@nxp.com,
>  akhil.go...@nxp.com, dev@dpdk.org
> CC: narender.vang...@intel.com, abhinandan.guj...@intel.com,
>  nikhil@intel.com, gage.e...@intel.com
> Subject: [v2,5/6] eventdev: add event crypto adapter to meson build system
> X-Mailer: git-send-email 1.9.1
> 
> Signed-off-by: Abhinandan Gujjar 
> ---
>  lib/librte_eventdev/meson.build | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/librte_eventdev/meson.build b/lib/librte_eventdev/meson.build

Separate patch is not required for meson build. Have it in the same patch
for make based build and ADD each files as when it added in the patch.

Re: [dpdk-dev] [v2, 6/6] doc: add event crypto adapter documentation

[Jerin Jacob]

-Original Message-
> Date: Tue, 24 Apr 2018 18:13:27 +0530
> From: Abhinandan Gujjar 
> To: jerin.ja...@caviumnetworks.com, hemant.agra...@nxp.com,
>  akhil.go...@nxp.com, dev@dpdk.org
> CC: narender.vang...@intel.com, abhinandan.guj...@intel.com,
>  nikhil@intel.com, gage.e...@intel.com
> Subject: [v2,6/6] doc: add event crypto adapter documentation
> X-Mailer: git-send-email 1.9.1
> 
> Add entries in the programmer's guide, API index, maintainer's file
> and release notes for the event crypto adapter.
> 
> Signed-off-by: Abhinandan Gujjar 
> ---
> +
> +The packet flow from cryptodev to the event device can be accomplished
> +using both SW and HW based transfer mechanisms.
> +The Adapter queries an eventdev PMD to determine which mechanism to be used.
> +The adapter uses an EAL service core function for SW based packet transfer
> +and uses the eventdev PMD functions to configure HW based packet transfer
> +between the cryptodev and the event device.
> +
> +Crypto adapter uses a new event type called ``RTE_EVENT_TYPE_CRYPTODEV``
> +to indicate the event source.
> +

I think, we can add diagrams used in rte_event_crypto_adapter.h with
sequence number in SVG format here to make it easier to understand for the end 
user.


> +API Overview
> +
> +
> +This section has a brief introduction to the event crypto adapter APIs.
> +The application is expected to create an adapter which is associated with
> +a single eventdev, then add cryptodev and queue pair to the adapter instance.
> +
> +Adapter can be started in ``RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY`` or
> +``RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ`` mode.
> +In first mode, application will submit a crypto operation directly to 
> cryptodev.
> +In the second mode, application will send a crypto ops to cryptodev adapter
> +via eventdev. The cryptodev adapter then submits the crypto operation to the
> +crypto device.
> +
> +Create an adapter instance
> +--
> +
> +An adapter instance is created using ``rte_event_crypto_adapter_create()``. 
> This
> +function is called with event device to be associated with the adapter and 
> port
> +configuration for the adapter to setup an event port(if the adapter needs to 
> use
> +a service function).
> +
> +.. code-block:: c
> +
> +int err;
> +uint8_t dev_id, id;
> +struct rte_event_dev_info dev_info;
> +struct rte_event_port_conf conf;
> + enum rte_event_crypto_adapter_mode mode;
> +
> +err = rte_event_dev_info_get(id, &dev_info);
> +
> +conf.new_event_threshold = dev_info.max_num_events;
> +conf.dequeue_depth = dev_info.max_event_port_dequeue_depth;
> +conf.enqueue_depth = dev_info.max_event_port_enqueue_depth;
> + mode = RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ;
> +err = rte_event_crypto_adapter_create(id, dev_id, &conf, mode);
> +
> +If the application desires to have finer control of eventdev port allocation
> +and setup, it can use the ``rte_event_crypto_adapter_create_ext()`` function.
> +The ``rte_event_crypto_adapter_create_ext()`` function is passed as a 
> callback
> +function. The callback function is invoked if the adapter needs to use a
> +service function and needs to create an event port for it. The callback is
> +expected to fill the ``struct rte_event_crypto_adapter_conf`` structure
> +passed to it.
> +
> +For ENQ-DEQ mode, the event port created by adapter can be retrived using

s/retrived/retrieved ?

> +``rte_event_crypto_adapter_event_port_get()`` API.
> +Application can use this event port to link with event queue on which it
> +enqueue events towards the crypto adapter.
> +
> +.. code-block:: c
> +
> + uint8_t id, evdev, crypto_ev_port_id, app_qid;
> + struct rte_event ev;
> + int ret;
> +
> + ret = rte_event_crypto_adapter_event_port_get(id, &crypto_ev_port_id);
> + ret = rte_event_queue_setup(evdev, app_qid, NULL);
> + ret = rte_event_port_link(evdev, crypto_ev_port_id, &app_qid, NULL, 1);
> +
> + /* Fill in event info and update event_ptr with rte_crypto_op */
> + memset(&ev, 0, sizeof(ev));
> + ev.queue_id = app_qid;
> + .
> + .
> + ev.event_ptr = op;
> + ret = rte_event_enqueue_burst(evdev, app_ev_port_id, ev, nb_events);
> +
> +
> +Adding queue pair to the adapter instance
> +-
> +
> +Cryptodev device id and queue pair are created using cryptodev APIs.
> +Refer '`_.
> +
> +.. code-block:: c
> +
> + struct rte_cryptodev_config conf;
> + struct rte_cryptodev_qp_conf qp_conf;
> + uint8_t cdev_id = 0;
> + uint16_t qp_id = 0;
> +
> + rte_cryptodev_configure(cdev_id, &conf);
> + rte_cryptodev_queue_pair_setup(cdev_id, qp_id, &qp_conf);
> +
> +These cryptodev id and queue pair are added to the instance using the
> +``rte_event_crypto_adapter_queue_pair_add()`` function.
> +The same is removed using ``rte_event_crypto_adapter_

[dpdk-dev] [PATCH 2/2] net/mlx5: add Rx and Tx tuning parameters

[Shahaf Shuler]

A new ethdev API was exposed by
commit 3be82f5cc5e3 ("ethdev: support PMD-tuned Tx/Rx parameters")

Enabling the PMD to provide default parameters in case no strict request
from application in order to improve the out of the box experience.

While the current API lacks the means for the PMD to provide the best
possible value, providing the best default the PMD can guess.
The values are based on Mellanox performance report and depends on the
underlying NIC capabilities.

Cc: ere...@mellanox.com
Cc: am...@mellanox.com
Cc: ol...@mellanox.com

Signed-off-by: Shahaf Shuler 
---
 drivers/net/mlx5/mlx5_ethdev.c | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 588d4ba627..78354922b0 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -417,6 +417,56 @@ mlx5_dev_configure(struct rte_eth_dev *dev)
 }
 
 /**
+ * Sets default tuning parameters.
+ *
+ * @param dev
+ *   Pointer to Ethernet device.
+ * @param[out] info
+ *   Info structure output buffer.
+ */
+static void
+mlx5_set_default_params(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
+{
+   struct priv *priv = dev->data->dev_private;
+
+   if (priv->link_speed_capa & ETH_LINK_SPEED_100G) {
+   if (dev->data->nb_rx_queues <= 2 &&
+   dev->data->nb_tx_queues <= 2) {
+   /* Minimum CPU utilization. */
+   info->default_rxportconf.ring_size = 256;
+   info->default_txportconf.ring_size = 256;
+   /* Don't care as queue num is set. */
+   info->default_rxportconf.nb_queues = 0;
+   info->default_txportconf.nb_queues = 0;
+   } else {
+   /* Max Throughput. */
+   info->default_rxportconf.ring_size = 2048;
+   info->default_txportconf.ring_size = 2048;
+   info->default_rxportconf.nb_queues = 16;
+   info->default_txportconf.nb_queues = 16;
+   }
+   } else {
+   if (dev->data->nb_rx_queues <= 2 &&
+   dev->data->nb_tx_queues <= 2) {
+   /* Minimum CPU utilization. */
+   info->default_rxportconf.ring_size = 256;
+   info->default_txportconf.ring_size = 256;
+   /* Don't care as queue num is set. */
+   info->default_rxportconf.nb_queues = 0;
+   info->default_txportconf.nb_queues = 0;
+   } else {
+   /* Max Throughput. */
+   info->default_rxportconf.ring_size = 4096;
+   info->default_txportconf.ring_size = 4096;
+   info->default_rxportconf.nb_queues = 8;
+   info->default_txportconf.nb_queues = 8;
+   }
+   }
+   info->default_rxportconf.burst_size = 64;
+   info->default_txportconf.burst_size = 64;
+}
+
+/**
  * DPDK callback to get information about the device.
  *
  * @param dev
@@ -458,6 +508,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
info->hash_key_size = rss_hash_default_key_len;
info->speed_capa = priv->link_speed_capa;
info->flow_type_rss_offloads = ~MLX5_RSS_HF_MASK;
+   mlx5_set_default_params(dev, info);
 }
 
 /**
-- 
2.12.0

[dpdk-dev] [PATCH 1/2] net/mlx5: fix ethtool link setting call order

[Shahaf Shuler]

According to ethtool_link_setting API recommendation ETHTOOL_GLINKSETTINGS
should be called before ETHTOOL_GSET as the later one deprecated.

Fixes: f47ba80080ab ("net/mlx5: remove kernel version check")
Cc: nelio.laranje...@6wind.com

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

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 746b94f734..588d4ba627 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -697,9 +697,9 @@ mlx5_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)
time_t start_time = time(NULL);
 
do {
-   ret = mlx5_link_update_unlocked_gset(dev, &dev_link);
+   ret = mlx5_link_update_unlocked_gs(dev, &dev_link);
if (ret)
-   ret = mlx5_link_update_unlocked_gs(dev, &dev_link);
+   ret = mlx5_link_update_unlocked_gset(dev, &dev_link);
if (ret == 0)
break;
/* Handle wait to complete situation. */
-- 
2.12.0

[dpdk-dev] [PATCH v10] devtools: alert on new instances of rte_panic and rte_exit

[Arnon Warshavsky]

This patch adds a new function that is called
per every checked patch,
and alerts for new instances of rte_panic/rte_exit.
The check excludes comments, and alerts in the case
of a positive balance between additions and removals.

Signed-off-by: Arnon Warshavsky 
Reviewed-by: Stephen Hemminger 
---
 devtools/checkpatches.sh | 96 +++-
 1 file changed, 95 insertions(+), 1 deletion(-)

diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index 7676a6b..c7d927b 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -61,6 +61,92 @@ print_usage () {
END_OF_HELP
 }
 
+check_forbidden_additions() { # 
+# -
+#This awk script receives a list of expressions to monitor
+#and a list of folders to search these expressions in
+# - No search is done inside comments
+# - Both additions and removals of the expressions are checked
+#   A positive balance of additions fails the check
+   read -d '' awk_script << 'EOF'
+   BEGIN{
+   split(FOLDERS,deny_folders," ");
+   split(EXPRESSIONS,deny_expr," ");
+   in_file=0;
+   in_comment=0;
+   count=0;
+   comment_start="/*"
+   comment_end="*/"
+}
+# search for add/remove instances in current file
+# state machine assumes the comments structure is enforced by
+# checkpatches.pl
+(in_file) {
+   # comment start
+   if (index($0,comment_start) > 0){
+   in_comment = 1
+   }
+   # non comment code
+   if (in_comment == 0) {
+   for (i in deny_expr) {
+   forbidden_added = "^\+.*" deny_expr[i];
+   forbidden_removed="^-.*" deny_expr[i];
+   current = expressions[deny_expr[i]]
+   if ($0 ~ forbidden_added) {
+   count = count + 1;
+   expressions[deny_expr[i]] = current + 1
+   }
+   if ($0 ~ forbidden_removed) {
+   count = count - 1;
+   expressions[deny_expr[i]] = current - 1
+   }
+   }
+   }
+
+   # comment end
+   if (index($0,comment_end) > 0)  {
+   in_comment = 0
+   }
+}
+   # switch to next file , check if the balance of add/remove
+   # of previous filehad new additions
+   ($0 ~ "^\+\+\+ b/") {
+   in_file = 0;
+   if (count > 0){
+   exit;
+   }
+   for (i in deny_folders){
+   re = "^\+\+\+ b/" deny_folders[i];
+   if ($0 ~ deny_folders[i]) {
+   in_file = 1
+   last_file = $0
+   }
+   }
+   }
+   END{
+   if (count > 0){
+   warnText = "\\033[1;31m" "Warning:" "\\033[0m"
+   print warnText " in " substr(last_file,6) ":"
+   print "are you sure you want to add the following:"
+   for (key in expressions) {
+   if (expressions[key] > 0) {
+   print key
+   }
+   }
+   exit 0
+   }
+   }
+EOF
+   # -
+
+   # refrain from new additions of rte_panic() and rte_exit()
+   # under lib and net
+   # multiple folders and expressions are separated by spaces
+   awk -v FOLDERS="lib net" \
+   -v EXPRESSIONS="rte_panic\\\( rte_exit\\\(" \
+   "$awk_script" -
+}
+
 number=0
 quiet=false
 verbose=false
@@ -89,11 +175,19 @@ check () { #   
total=$(($total + 1))
! $verbose || printf '\n### %s\n\n' "$3"
if [ -n "$1" ] ; then
+   cat "$1" | check_forbidden_additions
+   [ $? -eq 0 ] || return 0
report=$($DPDK_CHECKPATCH_PATH $options "$1" 2>/dev/null)
elif [ -n "$2" ] ; then
-   report=$(git format-patch --find-renames --no-stat --stdout -1 
$commit |
+   params=$(echo "--find-renames --no-stat --stdout -1")
+   body=$(git format-patch $params $commit)
+   echo "$body" | check_forbidden_additions
+   [ $? -eq 0 ] || return 0
+   report=$(echo "$body" |
$DPDK_CHECKPATCH_PATH $options - 2>/dev/null)
else
+   check_forbidden_additions -
+   [ $? -eq 0 ] || return 0
report=$($DPDK_CHECKPATCH_