[dpdk-dev] [pull-request] next-eventdev 18.05 RC1

[Jerin Jacob]

The following changes since commit fb73e096110a41b77448fe27fd9be8c489ec5d82:

  app/testpmd: enable device hotplug monitoring (2018-04-13 12:01:19 +0200)

are available in the Git repository at:

  http://dpdk.org/git/next/dpdk-next-eventdev 

for you to fetch changes up to fe5abd3150bc1caa8369e743c395c39f53265597:

  eventdev: remove stale forward declaration (2018-04-14 12:49:53 +0530)


Erik Carrillo (9):
  eventtimer: introduce event timer adapter
  eventdev: convert to SPDX license tag in header
  eventtimer: add common code
  mk: update library order in static build
  eventtimer: add default software driver
  eventtimer: add support for meson build system
  test: add event timer adapter auto-test
  doc: add event timer adapter section to programmer's guide
  doc: add event timer adapter documentation

Gage Eads (2):
  event/sw: perform partial burst enqueues
  eventdev: add device stop flush callback

Jerin Jacob (1):
  event/octeontx: support device stop flush callback

Liang Ma (1):
  event/opdl: fix atomic queue race condition issue

Mattias Rönnblom (1):
  eventdev: fix incorrect MP/MC tail updates in event ring

Nikhil Rao (1):
  eventdev: add timestamping to received packets

Pavan Nikhilesh (15):
  app/eventdev: add event timer adapter as a producer
  app/eventdev: add burst mode for event timer adapter
  app/eventdev: add options to configure event timer adapter
  doc: update test eventdev documentation
  usertools: add Cavium TIM as an event device
  event/octeontx: add support to probe timvf PCIe devices
  event/octeontx: add support to create and free timer adapter
  event/octeontx: add support to start and stop timer device
  event/octeontx: add event timer stats get and reset
  event/octeontx: add multiproducer timer arm and cancel
  event/octeontx: add single producer timer arm variant
  event/octeontx: add burst mode for timer arm
  event/octeontx: optimize timer adapter resolution parameters
  event/octeontx: add option to use fpavf as chunk pool
  doc: update eventdev OcteonTx documentation

Rami Rosen (1):
  eventdev: remove stale forward declaration

Vipin Varghese (3):
  event/sw: add unlikely branch predict
  event/sw: move stats code for better cache access
  event/sw: code refractor for counter set

 MAINTAINERS|   11 +
 app/test-eventdev/evt_options.c|  132 +-
 app/test-eventdev/evt_options.h|   35 +
 app/test-eventdev/test_perf_atq.c  |   10 +-
 app/test-eventdev/test_perf_common.c   |  236 ++-
 app/test-eventdev/test_perf_common.h   |   14 +-
 app/test-eventdev/test_perf_queue.c|7 +-
 config/common_base |1 +
 config/rte_config.h|1 +
 doc/api/doxy-api-index.md  |   32 +-
 doc/guides/eventdevs/octeontx.rst  |   29 +
 .../prog_guide/event_ethernet_rx_adapter.rst   |6 +-
 doc/guides/prog_guide/event_timer_adapter.rst  |  296 
 doc/guides/prog_guide/index.rst|1 +
 doc/guides/rel_notes/release_18_05.rst |7 +
 doc/guides/tools/testeventdev.rst  |   60 +
 drivers/event/dpaa/dpaa_eventdev.c |2 +-
 drivers/event/dpaa2/dpaa2_eventdev.c   |2 +-
 drivers/event/octeontx/Makefile|8 +
 drivers/event/octeontx/meson.build |6 +-
 drivers/event/octeontx/ssovf_evdev.c   |   39 +-
 drivers/event/octeontx/ssovf_evdev.h   |5 +-
 drivers/event/octeontx/ssovf_evdev_selftest.c  |   36 +
 drivers/event/octeontx/ssovf_worker.c  |   15 +-
 drivers/event/octeontx/timvf_evdev.c   |  407 +
 drivers/event/octeontx/timvf_evdev.h   |  226 +++
 drivers/event/octeontx/timvf_probe.c   |  148 ++
 drivers/event/octeontx/timvf_worker.c  |  200 +++
 drivers/event/octeontx/timvf_worker.h  |  443 +
 drivers/event/opdl/opdl_evdev.c|2 +-
 drivers/event/opdl/opdl_evdev_init.c   |3 +
 drivers/event/opdl/opdl_ring.c |   93 +-
 drivers/event/opdl/opdl_ring.h |   16 +-
 drivers/event/skeleton/skeleton_eventdev.c |2 +-
 drivers/event/sw/sw_evdev.c|   20 +-
 drivers/event/sw/sw_evdev_scheduler.c  |   17 +-
 drivers/event/sw/sw_evdev_worker.c |6 +-
 lib/Makefile   |2 +-
 lib/librte_eventdev/Makefile   |5 +-
 lib/librte_eventdev/meson.build|9 +-
 lib/librte_eventdev/rte_event_eth_rx_adapter.c

[dpdk-dev] [PATCH] vhost: fix meson build for vDPA

[Jay Zhou]

CC: Zhihong Wang 
Fixes: 8b991d412e (vhost: support selective datapath)

Signed-off-by: Jay Zhou 
---
 lib/librte_vhost/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_vhost/meson.build b/lib/librte_vhost/meson.build
index 66cced1cb..b021894a0 100644
--- a/lib/librte_vhost/meson.build
+++ b/lib/librte_vhost/meson.build
@@ -10,6 +10,6 @@ endif
 version = 4
 allow_experimental_apis = true
 sources = files('fd_man.c', 'iotlb.c', 'socket.c', 'vhost.c', 'vhost_user.c',
-   'virtio_net.c', 'vhost_crypto.c')
+   'virtio_net.c', 'vhost_crypto.c', 'vdpa.c')
 headers = files('rte_vhost.h', 'rte_vhost_crypto.h')
 deps += ['ethdev', 'cryptodev', 'hash', 'pci']
-- 
2.14.2

[dpdk-dev] [PATCH] compat: add virtio crypto header file

[Jay Zhou]

Moving the virtio crypto header file from vhost lib to compat lib,
then this header file can be shared between vhost crypto backend and
virtio crypto PMD.

Signed-off-by: Jay Zhou 
---
 lib/librte_compat/Makefile  | 3 ++-
 lib/librte_compat/meson.build   | 2 +-
 lib/{librte_vhost => librte_compat}/virtio_crypto.h | 0
 lib/librte_vhost/vhost_crypto.c | 2 +-
 4 files changed, 4 insertions(+), 3 deletions(-)
 rename lib/{librte_vhost => librte_compat}/virtio_crypto.h (100%)

diff --git a/lib/librte_compat/Makefile b/lib/librte_compat/Makefile
index 0c57533c1..5f78824c1 100644
--- a/lib/librte_compat/Makefile
+++ b/lib/librte_compat/Makefile
@@ -35,6 +35,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
 LIBABIVER := 1
 
 # install includes
-SYMLINK-y-include := rte_compat.h
+SYMLINK-y-include += rte_compat.h
+SYMLINK-y-include += virtio_crypto.h
 
 include $(RTE_SDK)/mk/rte.install.mk
diff --git a/lib/librte_compat/meson.build b/lib/librte_compat/meson.build
index 82c7eea55..28762288e 100644
--- a/lib/librte_compat/meson.build
+++ b/lib/librte_compat/meson.build
@@ -2,7 +2,7 @@
 # Copyright(c) 2017 Intel Corporation
 
 
-install_headers('rte_compat.h')
+install_headers('rte_compat.h', 'virtio_crypto.h')
 
 set_variable('dep_rte_compat',
declare_dependency(include_directories: include_directories('.')))
diff --git a/lib/librte_vhost/virtio_crypto.h 
b/lib/librte_compat/virtio_crypto.h
similarity index 100%
rename from lib/librte_vhost/virtio_crypto.h
rename to lib/librte_compat/virtio_crypto.h
diff --git a/lib/librte_vhost/vhost_crypto.c b/lib/librte_vhost/vhost_crypto.c
index c154ef673..6e1f5eda5 100644
--- a/lib/librte_vhost/vhost_crypto.c
+++ b/lib/librte_vhost/vhost_crypto.c
@@ -6,11 +6,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rte_vhost_crypto.h"
 #include "vhost.h"
 #include "vhost_user.h"
-#include "virtio_crypto.h"
 
 #define INHDR_LEN  (sizeof(struct virtio_crypto_inhdr))
 #define IV_OFFSET  (sizeof(struct rte_crypto_op) + \
-- 
2.14.2

[dpdk-dev] [PATCH v8 03/11] crypto/virtio: support basic PMD ops

[Jay Zhou]

This patch implements the basic operations of virtio crypto PMD, which
includes start, stop, close, information getting, queue setup and
release of the device.
The virtio crypto device has two types of queues, data queue and
control queue. It has one data queue at least and has one and only one
control queue. For example, if a virtio crypto device has N queues,
then [0, N-2] is the data queue index, N-1 is the control
queue index.

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 drivers/crypto/virtio/virtio_cryptodev.c | 437 ++-
 drivers/crypto/virtio/virtio_cryptodev.h |  32 ++-
 drivers/crypto/virtio/virtio_rxtx.c  |  68 +
 3 files changed, 528 insertions(+), 9 deletions(-)

diff --git a/drivers/crypto/virtio/virtio_cryptodev.c 
b/drivers/crypto/virtio/virtio_cryptodev.c
index 3fe2c80..73f8b96 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: BSD-3-Clause
  * Copyright(c) 2018 HUAWEI TECHNOLOGIES CO., LTD.
  */
+#include 
 #include 
 #include 
 #include 
@@ -15,6 +16,22 @@
 int virtio_crypto_logtype_tx;
 int virtio_crypto_logtype_driver;
 
+static int virtio_crypto_dev_configure(struct rte_cryptodev *dev,
+   struct rte_cryptodev_config *config);
+static int virtio_crypto_dev_start(struct rte_cryptodev *dev);
+static void virtio_crypto_dev_stop(struct rte_cryptodev *dev);
+static int virtio_crypto_dev_close(struct rte_cryptodev *dev);
+static void virtio_crypto_dev_info_get(struct rte_cryptodev *dev,
+   struct rte_cryptodev_info *dev_info);
+static int virtio_crypto_qp_setup(struct rte_cryptodev *dev,
+   uint16_t queue_pair_id,
+   const struct rte_cryptodev_qp_conf *qp_conf,
+   int socket_id,
+   struct rte_mempool *session_pool);
+static int virtio_crypto_qp_release(struct rte_cryptodev *dev,
+   uint16_t queue_pair_id);
+static void virtio_crypto_dev_free_mbufs(struct rte_cryptodev *dev);
+
 /*
  * The set of PCI devices this driver supports
  */
@@ -26,22 +43,251 @@
 
 uint8_t cryptodev_virtio_driver_id;
 
+void
+virtio_crypto_queue_release(struct virtqueue *vq)
+{
+   struct virtio_crypto_hw *hw;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (vq) {
+   hw = vq->hw;
+   /* Select and deactivate the queue */
+   VTPCI_OPS(hw)->del_queue(hw, vq);
+
+   rte_memzone_free(vq->mz);
+   rte_mempool_free(vq->mpool);
+   rte_free(vq);
+   }
+}
+
+#define MPOOL_MAX_NAME_SZ 32
+
+int
+virtio_crypto_queue_setup(struct rte_cryptodev *dev,
+   int queue_type,
+   uint16_t vtpci_queue_idx,
+   uint16_t nb_desc,
+   int socket_id,
+   struct virtqueue **pvq)
+{
+   char vq_name[VIRTQUEUE_MAX_NAME_SZ];
+   char mpool_name[MPOOL_MAX_NAME_SZ];
+   const struct rte_memzone *mz;
+   unsigned int vq_size, size;
+   struct virtio_crypto_hw *hw = dev->data->dev_private;
+   struct virtqueue *vq = NULL;
+   uint32_t i = 0;
+   uint32_t j;
+
+   PMD_INIT_FUNC_TRACE();
+
+   VIRTIO_CRYPTO_INIT_LOG_DBG("setting up queue: %u", vtpci_queue_idx);
+
+   /*
+* Read the virtqueue size from the Queue Size field
+* Always power of 2 and if 0 virtqueue does not exist
+*/
+   vq_size = VTPCI_OPS(hw)->get_queue_num(hw, vtpci_queue_idx);
+   if (vq_size == 0) {
+   VIRTIO_CRYPTO_INIT_LOG_ERR("virtqueue does not exist");
+   return -EINVAL;
+   }
+   VIRTIO_CRYPTO_INIT_LOG_DBG("vq_size: %u", vq_size);
+
+   if (!rte_is_power_of_2(vq_size)) {
+   VIRTIO_CRYPTO_INIT_LOG_ERR("virtqueue size is not powerof 2");
+   return -EINVAL;
+   }
+
+   if (queue_type == VTCRYPTO_DATAQ) {
+   snprintf(vq_name, sizeof(vq_name), "dev%d_dataqueue%d",
+   dev->data->dev_id, vtpci_queue_idx);
+   snprintf(mpool_name, sizeof(mpool_name),
+   "dev%d_dataqueue%d_mpool",
+   dev->data->dev_id, vtpci_queue_idx);
+   } else if (queue_type == VTCRYPTO_CTRLQ) {
+   snprintf(vq_name, sizeof(vq_name), "dev%d_controlqueue",
+   dev->data->dev_id);
+   snprintf(mpool_name, sizeof(mpool_name),
+   "dev%d_controlqueue_mpool",
+   dev->data->dev_id);
+   }
+   size = RTE_ALIGN_CEIL(sizeof(*vq) +
+   vq_size * sizeof(struct vq_desc_extra),
+   RTE_CACHE_LINE_SIZE);
+   vq = rte_zmalloc_socket(vq_name, size, RTE_CACHE_LINE_SIZE,
+   socket_id);
+   if (vq == NULL) {
+   VIRTIO_CRYPTO_INIT_LOG_ERR("Can not allocate virtqueue");
+   

[dpdk-dev] [PATCH v8 01/11] crypto/virtio: add virtio crypto PMD

[Jay Zhou]

The virtio crypto device is a virtual cryptography device
as well as a kind of virtual hardware accelerator for
virtual machines. The linux kernel virtio-crypto driver
has been merged, and this patch introduces virtio crypto
PMD to achieve better performance.

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 MAINTAINERS|  4 +++
 config/common_base | 14 +
 doc/guides/rel_notes/release_18_05.rst |  4 +++
 drivers/crypto/Makefile|  1 +
 drivers/crypto/virtio/Makefile | 28 +
 .../virtio/rte_pmd_virtio_crypto_version.map   |  3 ++
 drivers/crypto/virtio/virtio_cryptodev.c   | 36 ++
 drivers/crypto/virtio/virtio_cryptodev.h   | 10 ++
 mk/rte.app.mk  |  1 +
 9 files changed, 101 insertions(+)
 create mode 100644 drivers/crypto/virtio/Makefile
 create mode 100644 drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map
 create mode 100644 drivers/crypto/virtio/virtio_cryptodev.c
 create mode 100644 drivers/crypto/virtio/virtio_cryptodev.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e54c1f0..d171f10 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -758,6 +758,10 @@ F: drivers/crypto/snow3g/
 F: doc/guides/cryptodevs/snow3g.rst
 F: doc/guides/cryptodevs/features/snow3g.ini
 
+Virtio
+M: Jay Zhou 
+F: drivers/crypto/virtio/
+
 ZUC
 M: Pablo de Lara 
 F: drivers/crypto/zuc/
diff --git a/config/common_base b/config/common_base
index 9e3fbaa..8a150f8 100644
--- a/config/common_base
+++ b/config/common_base
@@ -493,6 +493,20 @@ CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=n
 CONFIG_RTE_QAT_PMD_MAX_NB_SESSIONS=2048
 
 #
+# Compile PMD for virtio crypto devices
+#
+CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO=n
+#
+# Number of maximum virtio crypto devices
+#
+CONFIG_RTE_MAX_VIRTIO_CRYPTO=32
+#
+# Number of sessions to create in the session memory pool
+# on a single virtio crypto device.
+#
+CONFIG_RTE_VIRTIO_CRYPTO_PMD_MAX_NB_SESSIONS=1024
+
+#
 # Compile PMD for AESNI backed device
 #
 CONFIG_RTE_LIBRTE_PMD_AESNI_MB=n
diff --git a/doc/guides/rel_notes/release_18_05.rst 
b/doc/guides/rel_notes/release_18_05.rst
index e455cf6..cb05b89 100644
--- a/doc/guides/rel_notes/release_18_05.rst
+++ b/doc/guides/rel_notes/release_18_05.rst
@@ -82,6 +82,10 @@ New Features
 
   Linux uevent is supported as backend of this device event notification 
framework.
 
+* **Added the virtio crypto PMD.**
+
+  Added a new poll mode driver for virtio crypto devices.
+
 
 API Changes
 ---
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 9fbd986..e9e8b1f 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -21,5 +21,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_DPAA_BUS),y)
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_DPAA_SEC) += dpaa_sec
 endif
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_CCP) += ccp
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO) += virtio
 
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/crypto/virtio/Makefile b/drivers/crypto/virtio/Makefile
new file mode 100644
index 000..a3b44e9
--- /dev/null
+++ b/drivers/crypto/virtio/Makefile
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2018 HUAWEI TECHNOLOGIES CO., LTD.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_virtio_crypto.a
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+EXPORT_MAP := rte_pmd_virtio_crypto_version.map
+
+LIBABIVER := 1
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO) += virtio_cryptodev.c
+
+# this lib depends upon:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO) += lib/librte_eal
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO) += lib/librte_mempool 
lib/librte_mbuf
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO) += lib/librte_cryptodev
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map 
b/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map
new file mode 100644
index 000..de8e412
--- /dev/null
+++ b/drivers/crypto/virtio/rte_pmd_virtio_crypto_version.map
@@ -0,0 +1,3 @@
+DPDK_18.05 {
+   local: *;
+};
diff --git a/drivers/crypto/virtio/virtio_cryptodev.c 
b/drivers/crypto/virtio/virtio_cryptodev.c
new file mode 100644
index 000..3e54942
--- /dev/null
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 HUAWEI TECHNOLOGIES CO., LTD.
+ */
+#include 
+#include 
+#include 
+#include "virtio_cryptodev.h"
+
+uint8_t cryptodev_virtio_driver_id;
+
+static int
+crypto_virtio_pci_probe(
+   struct rte_pci_driver *pci_drv __rte_unused,
+   struct rte_pci_device *pci_dev __rte_unused)
+{
+   return 0;
+}
+
+static int
+crypto_virtio_pci_remove(
+   struct rte_pci_device *pci_dev __rte_unused)
+{
+   return 0;
+}
+
+static struct rte_pci_driver rte_virtio_crypto_

[dpdk-dev] [PATCH v8 02/11] crypto/virtio: support virtio device init

[Jay Zhou]

This patch implements the initialization of the virtio crypto device.
The virtio crypto device conforms to virtio-1.0, so this patch only
supports modern mode operation.
The cryptodev is created at the virtio crypto pci device probing stage.
The function of virtio_crypto_pkt_tx_burst() is used to burst transfer
packets and virtio_crypto_pkt_rx_burst() is used to burst receive packets.

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 drivers/crypto/virtio/Makefile   |   3 +
 drivers/crypto/virtio/virtio_cryptodev.c | 245 +++-
 drivers/crypto/virtio/virtio_cryptodev.h |  13 +
 drivers/crypto/virtio/virtio_logs.h  |  91 ++
 drivers/crypto/virtio/virtio_pci.c   | 460 +++
 drivers/crypto/virtio/virtio_pci.h   | 252 +
 drivers/crypto/virtio/virtio_ring.h  | 137 +
 drivers/crypto/virtio/virtio_rxtx.c  |  26 ++
 drivers/crypto/virtio/virtqueue.c|  43 +++
 drivers/crypto/virtio/virtqueue.h| 171 
 10 files changed, 1439 insertions(+), 2 deletions(-)
 create mode 100644 drivers/crypto/virtio/virtio_logs.h
 create mode 100644 drivers/crypto/virtio/virtio_pci.c
 create mode 100644 drivers/crypto/virtio/virtio_pci.h
 create mode 100644 drivers/crypto/virtio/virtio_ring.h
 create mode 100644 drivers/crypto/virtio/virtio_rxtx.c
 create mode 100644 drivers/crypto/virtio/virtqueue.c
 create mode 100644 drivers/crypto/virtio/virtqueue.h

diff --git a/drivers/crypto/virtio/Makefile b/drivers/crypto/virtio/Makefile
index a3b44e9..c4727ea 100644
--- a/drivers/crypto/virtio/Makefile
+++ b/drivers/crypto/virtio/Makefile
@@ -18,6 +18,9 @@ LIBABIVER := 1
 #
 # all source are stored in SRCS-y
 #
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO) += virtqueue.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO) += virtio_pci.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO) += virtio_rxtx.c
 SRCS-$(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO) += virtio_cryptodev.c
 
 # this lib depends upon:
diff --git a/drivers/crypto/virtio/virtio_cryptodev.c 
b/drivers/crypto/virtio/virtio_cryptodev.c
index 3e54942..3fe2c80 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -3,27 +3,240 @@
  */
 #include 
 #include 
+#include 
 #include 
+#include 
 #include "virtio_cryptodev.h"
+#include "virtqueue.h"
+
+int virtio_crypto_logtype_init;
+int virtio_crypto_logtype_session;
+int virtio_crypto_logtype_rx;
+int virtio_crypto_logtype_tx;
+int virtio_crypto_logtype_driver;
+
+/*
+ * The set of PCI devices this driver supports
+ */
+static const struct rte_pci_id pci_id_virtio_crypto_map[] = {
+   { RTE_PCI_DEVICE(VIRTIO_CRYPTO_PCI_VENDORID,
+   VIRTIO_CRYPTO_PCI_DEVICEID) },
+   { .vendor_id = 0, /* sentinel */ },
+};
 
 uint8_t cryptodev_virtio_driver_id;
 
+/*
+ * dev_ops for virtio, bare necessities for basic operation
+ */
+static struct rte_cryptodev_ops virtio_crypto_dev_ops = {
+   /* Device related operations */
+   .dev_configure   = NULL,
+   .dev_start   = NULL,
+   .dev_stop= NULL,
+   .dev_close   = NULL,
+   .dev_infos_get   = NULL,
+
+   .stats_get   = NULL,
+   .stats_reset = NULL,
+
+   .queue_pair_setup= NULL,
+   .queue_pair_release  = NULL,
+   .queue_pair_start= NULL,
+   .queue_pair_stop = NULL,
+   .queue_pair_count= NULL,
+
+   /* Crypto related operations */
+   .session_get_size   = NULL,
+   .session_configure  = NULL,
+   .session_clear  = NULL,
+   .qp_attach_session = NULL,
+   .qp_detach_session = NULL
+};
+
+static int
+virtio_negotiate_features(struct virtio_crypto_hw *hw, uint64_t req_features)
+{
+   uint64_t host_features;
+
+   PMD_INIT_FUNC_TRACE();
+
+   /* Prepare guest_features: feature that driver wants to support */
+   VIRTIO_CRYPTO_INIT_LOG_DBG("guest_features before negotiate = %" PRIx64,
+   req_features);
+
+   /* Read device(host) feature bits */
+   host_features = VTPCI_OPS(hw)->get_features(hw);
+   VIRTIO_CRYPTO_INIT_LOG_DBG("host_features before negotiate = %" PRIx64,
+   host_features);
+
+   /*
+* Negotiate features: Subset of device feature bits are written back
+* guest feature bits.
+*/
+   hw->guest_features = req_features;
+   hw->guest_features = vtpci_cryptodev_negotiate_features(hw,
+   host_features);
+   VIRTIO_CRYPTO_INIT_LOG_DBG("features after negotiate = %" PRIx64,
+   hw->guest_features);
+
+   if (hw->modern) {
+   if (!vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) {
+   VIRTIO_CRYPTO_

[dpdk-dev] [PATCH v8 09/11] crypto/virtio: build with meson

[Jay Zhou]

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 drivers/crypto/meson.build|  2 +-
 drivers/crypto/virtio/meson.build | 12 
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/virtio/meson.build

diff --git a/drivers/crypto/meson.build b/drivers/crypto/meson.build
index 736c9f5..63649c9 100644
--- a/drivers/crypto/meson.build
+++ b/drivers/crypto/meson.build
@@ -2,7 +2,7 @@
 # Copyright(c) 2017 Intel Corporation
 
 drivers = ['dpaa_sec', 'dpaa2_sec',
-   'openssl', 'null', 'qat']
+   'openssl', 'null', 'qat', 'virtio']
 
 std_deps = ['cryptodev'] # cryptodev pulls in all other needed deps
 config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
diff --git a/drivers/crypto/virtio/meson.build 
b/drivers/crypto/virtio/meson.build
new file mode 100644
index 000..cee77cc
--- /dev/null
+++ b/drivers/crypto/virtio/meson.build
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2018 HUAWEI TECHNOLOGIES CO., LTD.
+
+dep = dependency('libcrypto', required: false)
+if not dep.found()
+   build = false
+endif
+deps += ['bus_pci']
+sources = files('virtio_cryptodev.c', 'virtio_pci.c',
+   'virtio_rxtx.c', 'virtqueue.c')
+ext_deps += dep
+pkgconfig_extra_libs += '-lcrypto'
-- 
1.8.3.1

[dpdk-dev] [PATCH v8 05/11] crypto/virtio: support crypto enqueue/dequeue burst API

[Jay Zhou]

This patch implements the functions of virtio_crypto_pkt_tx_burst()
and virtio_crypto_pkt_rx_burst(). The encryption and decryption requests
are placed in the data queue and are ultimately handled by
the backend crypto accelerators.

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 drivers/crypto/virtio/virtio_cryptodev.h |   2 +
 drivers/crypto/virtio/virtio_rxtx.c  | 441 ++-
 2 files changed, 433 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/virtio/virtio_cryptodev.h 
b/drivers/crypto/virtio/virtio_cryptodev.h
index 5f740ca..aa40b5f 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.h
+++ b/drivers/crypto/virtio/virtio_cryptodev.h
@@ -17,6 +17,8 @@
 
 #define NUM_ENTRY_VIRTIO_CRYPTO_OP 7
 
+extern uint8_t cryptodev_virtio_driver_id;
+
 enum virtio_crypto_cmd_id {
VIRTIO_CRYPTO_CMD_CIPHER = 0,
VIRTIO_CRYPTO_CMD_AUTH = 1,
diff --git a/drivers/crypto/virtio/virtio_rxtx.c 
b/drivers/crypto/virtio/virtio_rxtx.c
index 3b038a7..4503928 100644
--- a/drivers/crypto/virtio/virtio_rxtx.c
+++ b/drivers/crypto/virtio/virtio_rxtx.c
@@ -1,8 +1,353 @@
 /* SPDX-License-Identifier: BSD-3-Clause
  * Copyright(c) 2018 HUAWEI TECHNOLOGIES CO., LTD.
  */
+#include 
+
 #include "virtqueue.h"
 #include "virtio_cryptodev.h"
+#include "virtio_crypto_algs.h"
+
+static void
+vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
+{
+   struct vring_desc *dp, *dp_tail;
+   struct vq_desc_extra *dxp;
+   uint16_t desc_idx_last = desc_idx;
+
+   dp = &vq->vq_ring.desc[desc_idx];
+   dxp = &vq->vq_descx[desc_idx];
+   vq->vq_free_cnt = (uint16_t)(vq->vq_free_cnt + dxp->ndescs);
+   if ((dp->flags & VRING_DESC_F_INDIRECT) == 0) {
+   while (dp->flags & VRING_DESC_F_NEXT) {
+   desc_idx_last = dp->next;
+   dp = &vq->vq_ring.desc[dp->next];
+   }
+   }
+   dxp->ndescs = 0;
+
+   /*
+* We must append the existing free chain, if any, to the end of
+* newly freed chain. If the virtqueue was completely used, then
+* head would be VQ_RING_DESC_CHAIN_END (ASSERTed above).
+*/
+   if (vq->vq_desc_tail_idx == VQ_RING_DESC_CHAIN_END) {
+   vq->vq_desc_head_idx = desc_idx;
+   } else {
+   dp_tail = &vq->vq_ring.desc[vq->vq_desc_tail_idx];
+   dp_tail->next = desc_idx;
+   }
+
+   vq->vq_desc_tail_idx = desc_idx_last;
+   dp->next = VQ_RING_DESC_CHAIN_END;
+}
+
+static uint16_t
+virtqueue_dequeue_burst_rx(struct virtqueue *vq,
+   struct rte_crypto_op **rx_pkts, uint16_t num)
+{
+   struct vring_used_elem *uep;
+   struct rte_crypto_op *cop;
+   uint16_t used_idx, desc_idx;
+   uint16_t i;
+   struct virtio_crypto_inhdr *inhdr;
+   struct virtio_crypto_op_cookie *op_cookie;
+
+   /* Caller does the check */
+   for (i = 0; i < num ; i++) {
+   used_idx = (uint16_t)(vq->vq_used_cons_idx
+   & (vq->vq_nentries - 1));
+   uep = &vq->vq_ring.used->ring[used_idx];
+   desc_idx = (uint16_t)uep->id;
+   cop = (struct rte_crypto_op *)
+   vq->vq_descx[desc_idx].crypto_op;
+   if (unlikely(cop == NULL)) {
+   VIRTIO_CRYPTO_RX_LOG_DBG("vring descriptor with no "
+   "mbuf cookie at %u",
+   vq->vq_used_cons_idx);
+   break;
+   }
+
+   op_cookie = (struct virtio_crypto_op_cookie *)
+   vq->vq_descx[desc_idx].cookie;
+   inhdr = &(op_cookie->inhdr);
+   switch (inhdr->status) {
+   case VIRTIO_CRYPTO_OK:
+   cop->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
+   break;
+   case VIRTIO_CRYPTO_ERR:
+   cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
+   vq->packets_received_failed++;
+   break;
+   case VIRTIO_CRYPTO_BADMSG:
+   cop->status = RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
+   vq->packets_received_failed++;
+   break;
+   case VIRTIO_CRYPTO_NOTSUPP:
+   cop->status = RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
+   vq->packets_received_failed++;
+   break;
+   case VIRTIO_CRYPTO_INVSESS:
+   cop->status = RTE_CRYPTO_OP_STATUS_INVALID_SESSION;
+   vq->packets_received_failed++;
+   break;
+   default:
+   break;
+   }
+
+   vq->packets_received_total++;
+
+   rx_pkts[i] = cop;
+   rte_mempool_put(vq->mpool, op_cookie);
+
+

[dpdk-dev] [PATCH v8 07/11] crypto/virtio: support AES-CBC

[Jay Zhou]

The AES-CBC cipher only algorithm has been supported now.

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 drivers/crypto/virtio/virtio_crypto_capabilities.h | 30 ++
 drivers/crypto/virtio/virtio_cryptodev.c   | 11 
 2 files changed, 41 insertions(+)
 create mode 100644 drivers/crypto/virtio/virtio_crypto_capabilities.h

diff --git a/drivers/crypto/virtio/virtio_crypto_capabilities.h 
b/drivers/crypto/virtio/virtio_crypto_capabilities.h
new file mode 100644
index 000..db6932f
--- /dev/null
+++ b/drivers/crypto/virtio/virtio_crypto_capabilities.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 HUAWEI TECHNOLOGIES CO., LTD.
+ */
+
+#ifndef _VIRTIO_CRYPTO_CAPABILITIES_H_
+#define _VIRTIO_CRYPTO_CAPABILITIES_H_
+
+#define VIRTIO_SYM_CAPABILITIES\
+   {   /* AES CBC */   \
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, \
+   {.sym = {   \
+   .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,  \
+   {.cipher = {\
+   .algo = RTE_CRYPTO_CIPHER_AES_CBC,  \
+   .block_size = 16,   \
+   .key_size = {   \
+   .min = 16,  \
+   .max = 32,  \
+   .increment = 8  \
+   },  \
+   .iv_size = {\
+   .min = 16,  \
+   .max = 16,  \
+   .increment = 0  \
+   }   \
+   }, }\
+   }, }\
+   }
+
+#endif /* _VIRTIO_CRYPTO_CAPABILITIES_H_ */
diff --git a/drivers/crypto/virtio/virtio_cryptodev.c 
b/drivers/crypto/virtio/virtio_cryptodev.c
index 6f92e99..f924b04 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -15,6 +15,7 @@
 #include "virtio_cryptodev.h"
 #include "virtqueue.h"
 #include "virtio_crypto_algs.h"
+#include "virtio_crypto_capabilities.h"
 
 int virtio_crypto_logtype_init;
 int virtio_crypto_logtype_session;
@@ -58,6 +59,11 @@ static int virtio_crypto_sym_configure_session(struct 
rte_cryptodev *dev,
{ .vendor_id = 0, /* sentinel */ },
 };
 
+static const struct rte_cryptodev_capabilities virtio_capabilities[] = {
+   VIRTIO_SYM_CAPABILITIES,
+   RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
+};
+
 uint8_t cryptodev_virtio_driver_id;
 
 #define NUM_ENTRY_SYM_CREATE_SESSION 4
@@ -746,6 +752,7 @@ static int virtio_crypto_sym_configure_session(struct 
rte_cryptodev *dev,
 
hw = cryptodev->data->dev_private;
hw->dev_id = cryptodev->data->dev_id;
+   hw->virtio_dev_capabilities = virtio_capabilities;
 
VIRTIO_CRYPTO_INIT_LOG_DBG("dev %d vendorID=0x%x deviceID=0x%x",
cryptodev->data->dev_id, pci_dev->id.vendor_id,
@@ -1139,6 +1146,9 @@ static int virtio_crypto_sym_configure_session(struct 
rte_cryptodev *dev,
struct rte_crypto_cipher_xform *cipher_xform)
 {
switch (cipher_xform->algo) {
+   case RTE_CRYPTO_CIPHER_AES_CBC:
+   para->algo = VIRTIO_CRYPTO_CIPHER_AES_CBC;
+   break;
default:
VIRTIO_CRYPTO_SESSION_LOG_ERR("Crypto: Unsupported "
"Cipher alg %u", cipher_xform->algo);
@@ -1402,6 +1412,7 @@ static int virtio_crypto_sym_configure_session(struct 
rte_cryptodev *dev,
info->max_nb_queue_pairs = hw->max_dataqueues;
info->sym.max_nb_sessions =
RTE_VIRTIO_CRYPTO_PMD_MAX_NB_SESSIONS;
+   info->capabilities = hw->virtio_dev_capabilities;
}
 }
 
-- 
1.8.3.1

[dpdk-dev] [PATCH v8 04/11] crypto/virtio: support session related ops

[Jay Zhou]

This patch implements session related operations, which includes creating
and destroying the session. For now, it only supports the session-oriented
API implementation. The control queue used to create or destroy sessions
for symmetric algorithms.

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 drivers/crypto/virtio/virtio_crypto_algs.h |  27 ++
 drivers/crypto/virtio/virtio_cryptodev.c   | 737 -
 drivers/crypto/virtio/virtio_cryptodev.h   |   7 +
 3 files changed, 768 insertions(+), 3 deletions(-)
 create mode 100644 drivers/crypto/virtio/virtio_crypto_algs.h

diff --git a/drivers/crypto/virtio/virtio_crypto_algs.h 
b/drivers/crypto/virtio/virtio_crypto_algs.h
new file mode 100644
index 000..df13b82
--- /dev/null
+++ b/drivers/crypto/virtio/virtio_crypto_algs.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 HUAWEI TECHNOLOGIES CO., LTD.
+ */
+
+#ifndef _VIRTIO_CRYPTO_ALGS_H_
+#define _VIRTIO_CRYPTO_ALGS_H_
+
+#include 
+#include 
+
+struct virtio_crypto_session {
+   uint64_t session_id;
+
+   struct {
+   uint16_t offset;
+   uint16_t length;
+   } iv;
+
+   struct {
+   uint32_t length;
+   phys_addr_t phys_addr;
+   } aad;
+
+   struct virtio_crypto_op_ctrl_req ctrl;
+};
+
+#endif /* _VIRTIO_CRYPTO_ALGS_H_ */
diff --git a/drivers/crypto/virtio/virtio_cryptodev.c 
b/drivers/crypto/virtio/virtio_cryptodev.c
index 73f8b96..596a237 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -1,14 +1,20 @@
 /* SPDX-License-Identifier: BSD-3-Clause
  * Copyright(c) 2018 HUAWEI TECHNOLOGIES CO., LTD.
  */
+#include 
+#include 
+
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+
 #include "virtio_cryptodev.h"
 #include "virtqueue.h"
+#include "virtio_crypto_algs.h"
 
 int virtio_crypto_logtype_init;
 int virtio_crypto_logtype_session;
@@ -31,6 +37,14 @@ static int virtio_crypto_qp_setup(struct rte_cryptodev *dev,
 static int virtio_crypto_qp_release(struct rte_cryptodev *dev,
uint16_t queue_pair_id);
 static void virtio_crypto_dev_free_mbufs(struct rte_cryptodev *dev);
+static unsigned int virtio_crypto_sym_get_session_private_size(
+   struct rte_cryptodev *dev);
+static void virtio_crypto_sym_clear_session(struct rte_cryptodev *dev,
+   struct rte_cryptodev_sym_session *sess);
+static int virtio_crypto_sym_configure_session(struct rte_cryptodev *dev,
+   struct rte_crypto_sym_xform *xform,
+   struct rte_cryptodev_sym_session *session,
+   struct rte_mempool *mp);
 
 /*
  * The set of PCI devices this driver supports
@@ -43,6 +57,210 @@ static int virtio_crypto_qp_release(struct rte_cryptodev 
*dev,
 
 uint8_t cryptodev_virtio_driver_id;
 
+#define NUM_ENTRY_SYM_CREATE_SESSION 4
+
+static int
+virtio_crypto_send_command(struct virtqueue *vq,
+   struct virtio_crypto_op_ctrl_req *ctrl, uint8_t *cipher_key,
+   uint8_t *auth_key, struct virtio_crypto_session *session)
+{
+   uint8_t idx = 0;
+   uint8_t needed = 1;
+   uint32_t head = 0;
+   uint32_t len_cipher_key = 0;
+   uint32_t len_auth_key = 0;
+   uint32_t len_ctrl_req = sizeof(struct virtio_crypto_op_ctrl_req);
+   uint32_t len_session_input = sizeof(struct virtio_crypto_session_input);
+   uint32_t len_total = 0;
+   uint32_t input_offset = 0;
+   void *virt_addr_started = NULL;
+   phys_addr_t phys_addr_started;
+   struct vring_desc *desc;
+   uint32_t desc_offset;
+   struct virtio_crypto_session_input *input;
+   int ret;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (session == NULL) {
+   VIRTIO_CRYPTO_SESSION_LOG_ERR("session is NULL.");
+   return -EINVAL;
+   }
+   /* cipher only is supported, it is available if auth_key is NULL */
+   if (!cipher_key) {
+   VIRTIO_CRYPTO_SESSION_LOG_ERR("cipher key is NULL.");
+   return -EINVAL;
+   }
+
+   head = vq->vq_desc_head_idx;
+   VIRTIO_CRYPTO_INIT_LOG_DBG("vq->vq_desc_head_idx = %d, vq = %p",
+   head, vq);
+
+   if (vq->vq_free_cnt < needed) {
+   VIRTIO_CRYPTO_SESSION_LOG_ERR("Not enough entry");
+   return -ENOSPC;
+   }
+
+   /* calculate the length of cipher key */
+   if (cipher_key) {
+   switch (ctrl->u.sym_create_session.op_type) {
+   case VIRTIO_CRYPTO_SYM_OP_CIPHER:
+   len_cipher_key
+   = ctrl->u.sym_create_session.u.cipher
+   .para.keylen;
+   break;
+   case VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING:
+   len_cipher_key
+   = ctrl->u.sym_create_s

[dpdk-dev] [PATCH v8 00/11] crypto: add virtio poll mode driver

[Jay Zhou]

This patch series introduce virtio crypto poll mode driver.

Since it is limited by the vhost crypto backend of the virtio-crypto,
this patch series only supports a limited subset of crypto services.
Only the following algorithms are tested:

Cipher algorithms:
  - RTE_CRYPTO_CIPHER_AES_CBC (128-bit, 192-bit and 256-bit keys)

Cipher then hash algorithms:
  - RTE_CRYPTO_CIPHER_AES_CBC with RTE_CRYPTO_AUTH_SHA1_HMAC

The qemu side has supported vhost crypto and the vhost user crypto server
side patches had been merged into dpdk-next-virtio too.

Firstly run DPDK vhost crypto sample as a server side and build QEMU with
vhost crypto enabled. 
QEMU can then be started using the following parameters:

qemu-system-x86_64 \
[...] \
-chardev socket,id=charcrypto0,path=/path/to/your/socket \
-object cryptodev-vhost-user,id=cryptodev0,chardev=charcrypto0 \
-device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0
[...]

Bind the uio_generic driver for the virtio-crypto device.
For example, :00:04.0 is the domain, bus, device and function
number of the virtio-crypto device:
modprobe uio_pci_generic
echo -n :00:04.0 > /sys/bus/pci/drivers/virtio-pci/unbind
echo "1af4 1054" > /sys/bus/pci/drivers/uio_pci_generic/new_id

The front-end virtio crypto PMD driver can be installed:
cd to the top-level DPDK directory
sed -i 's,\(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO\)=n,\1=y,' 
config/common_base
make config T=x86_64-native-linuxapp-gcc
make install T=x86_64-native-linuxapp-gcc

The unit test cases can be compiled as below:
cd to the top-level DPDK directory
export RTE_TARGET=x86_64-native-linuxapp-gcc
export RTE_SDK=`pwd`
cd to test/test
make
./test (MUST reserve enough huge pages memory)
type the command "cryptodev_virtio_autotest" to test

The result should be like this:
RTE>>cryptodev_virtio_autotest
 + --- +
 + Test Suite : Crypto VIRTIO Unit Test Suite
 + --- +
  0) TestCase AES-128-CBC Encryption PASS
  1) TestCase AES-128-CBC Decryption PASS
  2) TestCase AES-192-CBC Encryption PASS
  3) TestCase AES-192-CBC Decryption PASS
  4) TestCase AES-256-CBC Encryption PASS
  5) TestCase AES-256-CBC Decryption PASS
  6) TestCase AES-256-CBC OOP Encryption PASS
  7) TestCase AES-256-CBC OOP Decryption PASS
 + TestCase [ 0] : test_AES_cipheronly_virtio_all succeeded
 + --- +
 + Test Suite Summary
 + Tests Total :1
 + Tests Skipped :  0
 + Tests Executed : 1
 + Tests Unsupported:   0
 + Tests Passed :   1
 + Tests Failed :   0
 + --- +
Test OK

The performance can be tested as below:

reserve enough huge pages
cd to the top-level DPDK directory
export RTE_TARGET=x86_64-native-linuxapp-gcc
export RTE_SDK=`pwd`
cd to app/test-crypto-perf
type the command "make" to compile
run the tests with the following command:

./dpdk-test-crypto-perf -l 0,1 -- --devtype crypto_virtio \
--ptest throughput --optype cipher-then-auth --cipher-algo aes-cbc \
--cipher-op encrypt --cipher-key-sz 16 --auth-algo sha1-hmac \
--auth-op generate --auth-key-sz 64 --digest-sz 12 \
--total-ops 1 --burst-sz 64 --buffer-sz 2048

Please help to review, thanks!

Changes in v8:
 - using the virtio_crypto.h in compat lib instead of
   the linux header file
 - add meson build

Changes in v7:
 - add detailed commit messages [Pablo]

Changes in v6:
 - split the patches in a more functional way [Pablo]

Changes in v5:
 - rebased on the newest dpdk-next-crypto

Changes in v4:
 - using dynamic logging [Pablo]
 - elaborate on the core code [Pablo]
 - delete algorithms which can not be tested [Pablo]
 - rebased on dpdk-next-crypto [Pablo]
 - fix doc compilation error [Pablo]
 - add release note for this PMD [Pablo]
 - add R-b from Fan Zhang
 - fix some typos

Changes in v3:
 - set up capabilities for virtio crypto PMD [Fan]
 - delete AES-CTR unit test cases since vhost_user crypto backend does not
   support [Fan]
 - fix a variable uninitialized in virtio_crypto_queue_setup() [Xin, Fan]
 - fix a bug in virtqueue_dequeue_burst_rx()

Changes in v2:
 - using pre-allocated mempool instead of rte_malloc to improve performance 
[Fan]
 - split the patch into a patchset [Fan]
 - using linux/virtio_crypto.h instead of creating a copy of the file [Fan]
 - update doc/guides/cryptodevs for describing virtio crypto PMD [Fan]
 - update copyright
 - delete virtio legacy mode code since virtio-crypto conforms to virtio-1.0
 - refine the function and variable names
 - fix errors and warnings reported by checkpatch

Jay Zhou (11):
  crypto/virtio: add virtio crypto PMD
  crypto/virtio: support virtio device init
  crypto/virtio: support basic PMD ops
  crypto/virtio: support session related ops
  cry

[dpdk-dev] [PATCH v8 11/11] doc: add virtio crypto PMD guide

[Jay Zhou]

This patch adds the guide for virtio crypto PMD.

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 MAINTAINERS   |   2 +
 doc/guides/cryptodevs/features/virtio.ini |  26 +++
 doc/guides/cryptodevs/index.rst   |   1 +
 doc/guides/cryptodevs/virtio.rst  | 117 ++
 doc/guides/rel_notes/release_18_05.rst|   5 +-
 5 files changed, 150 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/cryptodevs/features/virtio.ini
 create mode 100644 doc/guides/cryptodevs/virtio.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index d171f10..1e9bd7d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -761,6 +761,8 @@ F: doc/guides/cryptodevs/features/snow3g.ini
 Virtio
 M: Jay Zhou 
 F: drivers/crypto/virtio/
+F: doc/guides/cryptodevs/virtio.rst
+F: doc/guides/cryptodevs/features/virtio.ini
 
 ZUC
 M: Pablo de Lara 
diff --git a/doc/guides/cryptodevs/features/virtio.ini 
b/doc/guides/cryptodevs/features/virtio.ini
new file mode 100644
index 000..168fc17
--- /dev/null
+++ b/doc/guides/cryptodevs/features/virtio.ini
@@ -0,0 +1,26 @@
+; Supported features of the 'virtio' crypto driver.
+;
+; Refer to default.ini for the full list of available PMD features.
+;
+[Features]
+Symmetric crypto   = Y
+Sym operation chaining = Y
+
+;
+; Supported crypto algorithms of the 'virtio' crypto driver.
+;
+[Cipher]
+AES CBC (128)  = Y
+AES CBC (192)  = Y
+AES CBC (256)  = Y
+
+;
+; Supported authentication algorithms of the 'virtio' crypto driver.
+;
+[Auth]
+SHA1 HMAC  = Y
+
+;
+; Supported AEAD algorithms of the 'virtio' crypto driver.
+;
+[AEAD]
diff --git a/doc/guides/cryptodevs/index.rst b/doc/guides/cryptodevs/index.rst
index 8a921dd..0529583 100644
--- a/doc/guides/cryptodevs/index.rst
+++ b/doc/guides/cryptodevs/index.rst
@@ -23,4 +23,5 @@ Crypto Device Drivers
 scheduler
 snow3g
 qat
+virtio
 zuc
diff --git a/doc/guides/cryptodevs/virtio.rst b/doc/guides/cryptodevs/virtio.rst
new file mode 100644
index 000..f3aa7c6
--- /dev/null
+++ b/doc/guides/cryptodevs/virtio.rst
@@ -0,0 +1,117 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2018 HUAWEI TECHNOLOGIES CO., LTD.
+
+Virtio Crypto Poll Mode Driver
+==
+
+The virtio crypto PMD provides poll mode driver support for the virtio crypto
+device.
+
+Features
+
+
+The virtio crypto PMD has support for:
+
+Cipher algorithms:
+
+* ``RTE_CRYPTO_CIPHER_AES_CBC``
+
+Hash algorithms:
+
+* ``RTE_CRYPTO_AUTH_SHA1_HMAC``
+
+Limitations
+---
+
+*  Only supports the session-oriented API implementation (session-less APIs are
+   not supported).
+*  Only supports modern mode since virtio crypto conforms to virtio-1.0.
+*  Only has two types of queues: data queue and control queue. These two queues
+   only support indirect buffers to communication with the virtio backend.
+*  Only supports AES_CBC cipher only algorithm and AES_CBC with HMAC_SHA1
+   chaining algorithm since the vhost crypto backend only these algorithms
+   are supported.
+*  Does not support Link State interrupt.
+*  Does not support runtime configuration.
+
+Virtio crypto PMD Rx/Tx Callbacks
+-
+
+Rx callbacks:
+
+* ``virtio_crypto_pkt_rx_burst``
+
+Tx callbacks:
+
+* ``virtio_crypto_pkt_tx_burst``
+
+Installation
+
+
+Quick instructions are as follows:
+
+Firstly run DPDK vhost crypto sample as a server side and build QEMU with
+vhost crypto enabled.
+QEMU can then be started using the following parameters:
+
+.. code-block:: console
+
+qemu-system-x86_64 \
+[...] \
+-chardev socket,id=charcrypto0,path=/path/to/your/socket \
+-object cryptodev-vhost-user,id=cryptodev0,chardev=charcrypto0 \
+-device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0
+[...]
+
+Secondly bind the uio_generic driver for the virtio-crypto device.
+For example, :00:04.0 is the domain, bus, device and function
+number of the virtio-crypto device:
+
+.. code-block:: console
+
+modprobe uio_pci_generic
+echo -n :00:04.0 > /sys/bus/pci/drivers/virtio-pci/unbind
+echo "1af4 1054" > /sys/bus/pci/drivers/uio_pci_generic/new_id
+
+Finally the front-end virtio crypto PMD driver can be installed:
+
+.. code-block:: console
+
+cd to the top-level DPDK directory
+sed -i 's,\(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO\)=n,\1=y,' 
config/common_base
+make config T=x86_64-native-linuxapp-gcc
+make install T=x86_64-native-linuxapp-gcc
+
+Tests
+-
+
+The unit test cases can be tested as below:
+
+.. code-block:: console
+
+reserve enough huge pages
+cd to the top-level DPDK directory
+export RTE_TARGET=x86_64-native-linuxapp-gcc
+export RTE_SDK=`pwd`
+cd to test/test
+type the command "make" to compile
+run the tests with "./test"
+type the command "cryptodev_virtio_autotest" to test
+
+The performance can be tested as below:
+
+.. code-bloc

[dpdk-dev] [PATCH v8 06/11] crypto/virtio: support stats related ops

[Jay Zhou]

This patch implements the statistics of the packets.

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 drivers/crypto/virtio/virtio_cryptodev.c | 66 +++-
 1 file changed, 64 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/virtio/virtio_cryptodev.c 
b/drivers/crypto/virtio/virtio_cryptodev.c
index 596a237..6f92e99 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -29,6 +29,9 @@ static int virtio_crypto_dev_configure(struct rte_cryptodev 
*dev,
 static int virtio_crypto_dev_close(struct rte_cryptodev *dev);
 static void virtio_crypto_dev_info_get(struct rte_cryptodev *dev,
struct rte_cryptodev_info *dev_info);
+static void virtio_crypto_dev_stats_get(struct rte_cryptodev *dev,
+   struct rte_cryptodev_stats *stats);
+static void virtio_crypto_dev_stats_reset(struct rte_cryptodev *dev);
 static int virtio_crypto_qp_setup(struct rte_cryptodev *dev,
uint16_t queue_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
@@ -501,8 +504,8 @@ static int virtio_crypto_sym_configure_session(struct 
rte_cryptodev *dev,
.dev_close   = virtio_crypto_dev_close,
.dev_infos_get   = virtio_crypto_dev_info_get,
 
-   .stats_get   = NULL,
-   .stats_reset = NULL,
+   .stats_get   = virtio_crypto_dev_stats_get,
+   .stats_reset = virtio_crypto_dev_stats_reset,
 
.queue_pair_setup= virtio_crypto_qp_setup,
.queue_pair_release  = virtio_crypto_qp_release,
@@ -518,6 +521,65 @@ static int virtio_crypto_sym_configure_session(struct 
rte_cryptodev *dev,
.qp_detach_session = NULL
 };
 
+static void
+virtio_crypto_update_stats(struct rte_cryptodev *dev,
+   struct rte_cryptodev_stats *stats)
+{
+   unsigned int i;
+   struct virtio_crypto_hw *hw = dev->data->dev_private;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (stats == NULL) {
+   VIRTIO_CRYPTO_DRV_LOG_ERR("invalid pointer");
+   return;
+   }
+
+   for (i = 0; i < hw->max_dataqueues; i++) {
+   const struct virtqueue *data_queue
+   = dev->data->queue_pairs[i];
+   if (data_queue == NULL)
+   continue;
+
+   stats->enqueued_count += data_queue->packets_sent_total;
+   stats->enqueue_err_count += data_queue->packets_sent_failed;
+
+   stats->dequeued_count += data_queue->packets_received_total;
+   stats->dequeue_err_count
+   += data_queue->packets_received_failed;
+   }
+}
+
+static void
+virtio_crypto_dev_stats_get(struct rte_cryptodev *dev,
+   struct rte_cryptodev_stats *stats)
+{
+   PMD_INIT_FUNC_TRACE();
+
+   virtio_crypto_update_stats(dev, stats);
+}
+
+static void
+virtio_crypto_dev_stats_reset(struct rte_cryptodev *dev)
+{
+   unsigned int i;
+   struct virtio_crypto_hw *hw = dev->data->dev_private;
+
+   PMD_INIT_FUNC_TRACE();
+
+   for (i = 0; i < hw->max_dataqueues; i++) {
+   struct virtqueue *data_queue = dev->data->queue_pairs[i];
+   if (data_queue == NULL)
+   continue;
+
+   data_queue->packets_sent_total = 0;
+   data_queue->packets_sent_failed = 0;
+
+   data_queue->packets_received_total = 0;
+   data_queue->packets_received_failed = 0;
+   }
+}
+
 static int
 virtio_crypto_qp_setup(struct rte_cryptodev *dev, uint16_t queue_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
-- 
1.8.3.1

[dpdk-dev] [PATCH v8 08/11] crypto/virtio: support HMAC-SHA1

[Jay Zhou]

The AES-CBC with HMAC-SHA1 has been supported now.

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 drivers/crypto/virtio/virtio_crypto_capabilities.h | 21 +
 drivers/crypto/virtio/virtio_cryptodev.c   |  4 +++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/virtio/virtio_crypto_capabilities.h 
b/drivers/crypto/virtio/virtio_crypto_capabilities.h
index db6932f..03c30de 100644
--- a/drivers/crypto/virtio/virtio_crypto_capabilities.h
+++ b/drivers/crypto/virtio/virtio_crypto_capabilities.h
@@ -6,6 +6,27 @@
 #define _VIRTIO_CRYPTO_CAPABILITIES_H_
 
 #define VIRTIO_SYM_CAPABILITIES\
+   {   /* SHA1 HMAC */ \
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, \
+   {.sym = {   \
+   .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,\
+   {.auth = {  \
+   .algo = RTE_CRYPTO_AUTH_SHA1_HMAC,  \
+   .block_size = 64,   \
+   .key_size = {   \
+   .min = 1,   \
+   .max = 64,  \
+   .increment = 1  \
+   },  \
+   .digest_size = {\
+   .min = 1,   \
+   .max = 20,  \
+   .increment = 1  \
+   },  \
+   .iv_size = { 0 }\
+   }, }\
+   }, }\
+   },  \
{   /* AES CBC */   \
.op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, \
{.sym = {   \
diff --git a/drivers/crypto/virtio/virtio_cryptodev.c 
b/drivers/crypto/virtio/virtio_cryptodev.c
index f924b04..df88953 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -1196,11 +1196,13 @@ static int virtio_crypto_sym_configure_session(struct 
rte_cryptodev *dev,
}
 
switch (auth_xform->algo) {
+   case RTE_CRYPTO_AUTH_SHA1_HMAC:
+   *algo = VIRTIO_CRYPTO_MAC_HMAC_SHA1;
+   break;
default:
VIRTIO_CRYPTO_SESSION_LOG_ERR(
"Crypto: Undefined Hash algo %u specified",
auth_xform->algo);
-   *algo = VIRTIO_CRYPTO_NO_MAC;
return -1;
}
 
-- 
1.8.3.1

[dpdk-dev] [PATCH v8 10/11] test/crypto: add function tests for virtio crypto PMD

[Jay Zhou]

Only RTE_CRYPTO_CIPHER_AES_CBC cipher
algorithm are tested as unit test, it is supported both by the
cryptodev-backend-builtin and cryptodev-vhost-user of qemu side.

Signed-off-by: Jay Zhou 
Reviewed-by: Fan Zhang 
Acked-by: Fan Zhang 
---
 test/test/test_cryptodev.c  | 48 +
 test/test/test_cryptodev.h  |  1 +
 test/test/test_cryptodev_aes_test_vectors.h | 24 ++-
 test/test/test_cryptodev_blockcipher.c  |  9 +-
 test/test/test_cryptodev_blockcipher.h  |  1 +
 5 files changed, 74 insertions(+), 9 deletions(-)

diff --git a/test/test/test_cryptodev.c b/test/test/test_cryptodev.c
index d1d7925..2f31ec9 100644
--- a/test/test/test_cryptodev.c
+++ b/test/test/test_cryptodev.c
@@ -1820,6 +1820,25 @@ struct crypto_unittest_params {
 }
 
 static int
+test_AES_cipheronly_virtio_all(void)
+{
+   struct crypto_testsuite_params *ts_params = &testsuite_params;
+   int status;
+
+   status = test_blockcipher_all_tests(ts_params->mbuf_pool,
+   ts_params->op_mpool,
+   ts_params->session_mpool,
+   ts_params->valid_devs[0],
+   rte_cryptodev_driver_id_get(
+   RTE_STR(CRYPTODEV_NAME_VIRTIO_PMD)),
+   BLKCIPHER_AES_CIPHERONLY_TYPE);
+
+   TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+   return TEST_SUCCESS;
+}
+
+static int
 test_AES_chain_dpaa_sec_all(void)
 {
struct crypto_testsuite_params *ts_params = &testsuite_params;
@@ -8879,6 +8898,18 @@ struct test_crypto_vector {
}
 };
 
+static struct unit_test_suite cryptodev_virtio_testsuite = {
+   .suite_name = "Crypto VIRTIO Unit Test Suite",
+   .setup = testsuite_setup,
+   .teardown = testsuite_teardown,
+   .unit_test_cases = {
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_AES_cipheronly_virtio_all),
+
+   TEST_CASES_END() /**< NULL terminate unit test array */
+   }
+};
+
 static struct unit_test_suite cryptodev_aesni_mb_testsuite  = {
.suite_name = "Crypto Device AESNI MB Unit Test Suite",
.setup = testsuite_setup,
@@ -9808,6 +9839,22 @@ struct test_crypto_vector {
 }
 
 static int
+test_cryptodev_virtio(void /*argv __rte_unused, int argc __rte_unused*/)
+{
+   gbl_driver_id = rte_cryptodev_driver_id_get(
+   RTE_STR(CRYPTODEV_NAME_VIRTIO_PMD));
+
+   if (gbl_driver_id == -1) {
+   RTE_LOG(ERR, USER1, "VIRTIO PMD must be loaded. Check if "
+   "CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO is enabled 
"
+   "in config file to run this testsuite.\n");
+   return TEST_FAILED;
+   }
+
+   return unit_test_suite_runner(&cryptodev_virtio_testsuite);
+}
+
+static int
 test_cryptodev_aesni_mb(void /*argv __rte_unused, int argc __rte_unused*/)
 {
gbl_driver_id = rte_cryptodev_driver_id_get(
@@ -10040,3 +10087,4 @@ struct test_crypto_vector {
 REGISTER_TEST_COMMAND(cryptodev_dpaa2_sec_autotest, test_cryptodev_dpaa2_sec);
 REGISTER_TEST_COMMAND(cryptodev_dpaa_sec_autotest, test_cryptodev_dpaa_sec);
 REGISTER_TEST_COMMAND(cryptodev_ccp_autotest, test_cryptodev_ccp);
+REGISTER_TEST_COMMAND(cryptodev_virtio_autotest, test_cryptodev_virtio);
diff --git a/test/test/test_cryptodev.h b/test/test/test_cryptodev.h
index 9a01403..a630ee8 100644
--- a/test/test/test_cryptodev.h
+++ b/test/test/test_cryptodev.h
@@ -63,6 +63,7 @@
 #define CRYPTODEV_NAME_SCHEDULER_PMD   crypto_scheduler
 #define CRYPTODEV_NAME_MRVL_PMDcrypto_mrvl
 #define CRYPTODEV_NAME_CCP_PMD crypto_ccp
+#define CRYPTODEV_NAME_VIRTIO_PMD  crypto_virtio
 
 /**
  * Write (spread) data from buffer to mbuf data
diff --git a/test/test/test_cryptodev_aes_test_vectors.h 
b/test/test/test_cryptodev_aes_test_vectors.h
index 6f2422a..724c1e0 100644
--- a/test/test/test_cryptodev_aes_test_vectors.h
+++ b/test/test/test_cryptodev_aes_test_vectors.h
@@ -1544,7 +1544,8 @@
BLOCKCIPHER_TEST_TARGET_PMD_DPAA2_SEC |
BLOCKCIPHER_TEST_TARGET_PMD_DPAA_SEC |
BLOCKCIPHER_TEST_TARGET_PMD_MRVL |
-   BLOCKCIPHER_TEST_TARGET_PMD_CCP
+   BLOCKCIPHER_TEST_TARGET_PMD_CCP |
+   BLOCKCIPHER_TEST_TARGET_PMD_VIRTIO
},
{
.test_descr = "AES-128-CBC Decryption",
@@ -1557,7 +1558,8 @@
BLOCKCIPHER_TEST_TARGET_PMD_DPAA2_SEC |
BLOCKCIPHER_TEST_TARGET_PMD_DPAA_SEC |
BLOCKCIPHER_TEST_TARGET_PMD_MRVL |
-   BLOCKCIPHER_TEST_TARGET_PMD_CCP
+   BLOCKCIPHER_TEST_TARGET_PMD_CCP |
+   BLOCKCIPHER_TEST_TARGET_PMD_VIRTIO
},
{
.test_descr = "AES-192-CBC Encryption",
@@ -1569,7 +1571,8 @@
BLOCKCIPHER_TEST_TARGE

Re: [dpdk-dev] [PATCH v3 2/2] eal: fix signed integers in fbarray

[Burakov, Anatoly]

On 13-Apr-18 7:43 PM, Adrien Mazarguil wrote:

While debugging startup issues encountered with Clang (see "eal: fix
undefined behavior in fbarray"), I noticed that fbarray stores indices,
sizes and masks on signed integers involved in bitwise operations.

Such operations almost invariably cause undefined behavior with values that
cannot be represented by the result type, as is often the case with
bit-masks and left-shifts.

This patch replaces them with unsigned integers as a safety measure and
promotes a few internal variables to larger types for consistency.

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

Signed-off-by: Adrien Mazarguil 

--

v3 changes:

- Added INT_MAX upper bound check in fully_validate() as suggested by
   Anatoly.
- Added a sysconf() result check to appease Coverity since calc_data_size()
   now takes an unsigned page size (Coverity issues 272598 and 272599).

v2 changes:

Removed unnecessary "(unsigned int)" cast leftovers.


Acked-by: Anatoly Burakov 

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH v3 07/14] net/mlx5: support tunnel RSS level

[Xueming(Steven) Li]

Hi Nelio,

> -Original Message-
> From: Nélio Laranjeiro 
> Sent: Friday, April 13, 2018 9:27 PM
> To: Xueming(Steven) Li 
> Cc: Shahaf Shuler ; dev@dpdk.org
> Subject: Re: [PATCH v3 07/14] net/mlx5: support tunnel RSS level
> 
> Seems you did not read my comments on this patch, I have exactly the same
> ones.

I finally found your previous comments in trash box, not sure why outlook 
always deliver important mail to trash box, anyway I updated rules.

> 
> On Fri, Apr 13, 2018 at 07:20:16PM +0800, Xueming Li wrote:
> > Tunnel RSS level of flow RSS action offers user a choice to do RSS
> > hash calculation on inner or outer RSS fields. Testpmd flow command
> examples:
> >
> > GRE flow inner RSS:
> >   flow create 0 ingress pattern eth / ipv4 proto is 47 / gre / end
> > actions rss queues 1 2 end level 1 / end
> >
> > GRE tunnel flow outer RSS:
> >   flow create 0 ingress pattern eth  / ipv4 proto is 47 / gre / end
> > actions rss queues 1 2 end level 0 / end
> >
> > Signed-off-by: Xueming Li 
> > ---
> >  drivers/net/mlx5/Makefile|   2 +-
> >  drivers/net/mlx5/mlx5_flow.c | 247
> > +--
> >  drivers/net/mlx5/mlx5_glue.c |  16 +++
> >  drivers/net/mlx5/mlx5_glue.h |   8 ++
> >  drivers/net/mlx5/mlx5_rxq.c  |  56 +-
> >  drivers/net/mlx5/mlx5_rxtx.h |   5 +-
> >  6 files changed, 248 insertions(+), 86 deletions(-)
> >
> > diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
> > index ae118ad33..f9a6c460b 100644
> > --- a/drivers/net/mlx5/Makefile
> > +++ b/drivers/net/mlx5/Makefile
> > @@ -35,7 +35,7 @@ include $(RTE_SDK)/mk/rte.vars.mk  LIB =
> > librte_pmd_mlx5.a  LIB_GLUE = $(LIB_GLUE_BASE).$(LIB_GLUE_VERSION)
> >  LIB_GLUE_BASE = librte_pmd_mlx5_glue.so -LIB_GLUE_VERSION = 18.02.0
> > +LIB_GLUE_VERSION = 18.05.0
> >
> >  # Sources.
> >  SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5.c diff --git
> > a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c index
> > dd099f328..a22554706 100644
> > --- a/drivers/net/mlx5/mlx5_flow.c
> > +++ b/drivers/net/mlx5/mlx5_flow.c
> > @@ -116,6 +116,7 @@ enum hash_rxq_type {
> > HASH_RXQ_UDPV6,
> > HASH_RXQ_IPV6,
> > HASH_RXQ_ETH,
> > +   HASH_RXQ_TUNNEL,
> >  };
> >
> >  /* Initialization data for hash RX queue. */ @@ -454,6 +455,7 @@
> > struct mlx5_flow_parse {
> > uint16_t queues[RTE_MAX_QUEUES_PER_PORT]; /**< Queues indexes to use.
> */
> > uint8_t rss_key[40]; /**< copy of the RSS key. */
> > enum hash_rxq_type layer; /**< Last pattern layer detected. */
> > +   enum hash_rxq_type out_layer; /**< Last outer pattern layer
> > +detected. */
> > uint32_t tunnel; /**< Tunnel type of RTE_PTYPE_TUNNEL_XXX. */
> > struct ibv_counter_set *cs; /**< Holds the counter set for the rule
> */
> > struct {
> > @@ -461,6 +463,7 @@ struct mlx5_flow_parse {
> > /**< Pointer to Verbs attributes. */
> > unsigned int offset;
> > /**< Current position or total size of the attribute. */
> > +   uint64_t hash_fields; /**< Verbs hash fields. */
> > } queue[RTE_DIM(hash_rxq_init)];
> >  };
> >
> > @@ -696,7 +699,8 @@ mlx5_flow_convert_actions(struct rte_eth_dev *dev,
> >" function is Toeplitz");
> > return -rte_errno;
> > }
> > -   if (rss->level) {
> > +#ifndef HAVE_IBV_DEVICE_TUNNEL_SUPPORT
> > +   if (parser->rss_conf.level > 0) {
> > rte_flow_error_set(error, EINVAL,
> >RTE_FLOW_ERROR_TYPE_ACTION,
> >actions,
> > @@ -704,6 +708,15 @@ mlx5_flow_convert_actions(struct rte_eth_dev *dev,
> >" level is not supported");
> > return -rte_errno;
> > }
> > +#endif
> > +   if (parser->rss_conf.level > 1) {
> > +   rte_flow_error_set(error, EINVAL,
> > +  RTE_FLOW_ERROR_TYPE_ACTION,
> > +  actions,
> > +  "RSS encapsulation level"
> > +  " > 1 is not supported");
> > +   return -rte_errno;
> > +   }
> > if (rss->types & MLX5_RSS_HF_MASK) {
> > rte_flow_error_set(error, EINVAL,
> >RTE_FLOW_ERROR_TYPE_ACTION,
> 
> Same comment as in previous review.
> The levels are not matching the proposed API.
> Level  0 = unspecified, 1 = outermost, 2 = next outermost, 3 = next
> next ...

Thanks, a big  missing in rebase.

> 
> > @@ -754,7 +767,7 @@ mlx5_flow_convert_actions(struct rte_eth_dev *dev,
> > }
> > parser->rss_conf 

Re: [dpdk-dev] [PATCH] drivers/net: update link status

[Tiwei Bie]

On Fri, Apr 13, 2018 at 10:53:55PM +0100, Ferruh Yigit wrote:
> On 4/10/2018 4:41 PM, Tiwei Bie wrote:
> > On Tue, Mar 13, 2018 at 06:05:34PM +, Ferruh Yigit wrote:
> >> Update link status related feature document items and minor updates in
> >> some link status related functions.
> >>
> >> Signed-off-by: Ferruh Yigit 
> >> ---
> >>  doc/guides/nics/features/fm10k.ini  | 2 ++
> >>  doc/guides/nics/features/fm10k_vf.ini   | 2 ++
> >>  doc/guides/nics/features/i40e_vf.ini| 1 +
> >>  doc/guides/nics/features/igb_vf.ini | 1 +
> >>  doc/guides/nics/features/qede.ini   | 1 -
> >>  doc/guides/nics/features/qede_vf.ini| 1 -
> >>  doc/guides/nics/features/vhost.ini  | 2 --
> >>  doc/guides/nics/features/virtio_vec.ini | 1 +
> >>  drivers/net/e1000/em_ethdev.c   | 2 +-
> >>  drivers/net/ena/ena_ethdev.c| 2 +-
> >>  drivers/net/fm10k/fm10k_ethdev.c| 6 ++
> >>  drivers/net/i40e/i40e_ethdev_vf.c   | 2 +-
> >>  drivers/net/ixgbe/ixgbe_ethdev.c| 2 +-
> >>  drivers/net/mlx4/mlx4_ethdev.c  | 2 +-
> >>  drivers/net/mlx5/mlx5_ethdev.c  | 2 +-
> >>  15 files changed, 15 insertions(+), 14 deletions(-)
> > [...]
> >> diff --git a/doc/guides/nics/features/vhost.ini 
> >> b/doc/guides/nics/features/vhost.ini
> >> index dffd1f493..31302745a 100644
> >> --- a/doc/guides/nics/features/vhost.ini
> >> +++ b/doc/guides/nics/features/vhost.ini
> >> @@ -4,8 +4,6 @@
> >>  ; Refer to default.ini for the full list of available PMD features.
> >>  ;
> >>  [Features]
> >> -Link status  = Y
> >> -Link status event= Y
> > 
> > I think vhost PMD supports above features.
> 
> I am not able to find where it is supported.
> 
> Some virtual PMDs report fixed link, with empty link_update() dev_ops, and 
> they
> are not reported as supporting Link status, as far as I can see vhost also one
> of them.
> 
> And for Link status event, PMD needs to support LSC interrupts and should
> register interrupt handler for it, which I can't find for vhost.
> 
> I will send next version without updating above one, please point me where 
> these
> support added if I missed them.

In drivers/net/vhost/rte_eth_vhost.c you could find below functions:

static int
new_device(int vid)
{
..

eth_dev->data->dev_link.link_status = ETH_LINK_UP;

..

_rte_eth_dev_callback_process(eth_dev, RTE_ETH_EVENT_INTR_LSC, NULL);

..
}

static void
destroy_device(int vid)
{
..

eth_dev->data->dev_link.link_status = ETH_LINK_DOWN;

..

_rte_eth_dev_callback_process(eth_dev, RTE_ETH_EVENT_INTR_LSC, NULL);

..
}

They are the callbacks for vhost library.

When a frontend (e.g. QEMU) is connected to this vhost backend
and the frontend virtio device becomes ready, new_device() will
be called by the vhost library, and the link status will be
updated to UP.

And when e.g. the connection is closed, destroy_device() will be
called by the vhost library, and the link status will be updated
to DOWN.

So vhost PMD reports meaningful link status and also generates
link status events.

Thanks

Re: [dpdk-dev] [PATCH v2 07/15] net/mlx5: support tunnel RSS level

[Xueming(Steven) Li]

> -Original Message-
> From: Nélio Laranjeiro 
> Sent: Wednesday, April 11, 2018 4:55 PM
> To: Xueming(Steven) Li 
> Cc: Shahaf Shuler ; dev@dpdk.org
> Subject: Re: [PATCH v2 07/15] net/mlx5: support tunnel RSS level
> 
> On Tue, Apr 10, 2018 at 09:34:07PM +0800, Xueming Li wrote:
> > Tunnel RSS level of flow RSS action offers user a choice to do RSS
> > hash calculation on inner or outer RSS fields. Testpmd flow command
> examples:
> >
> > GRE flow inner RSS:
> >   flow create 0 ingress pattern eth / ipv4 proto is 47 / gre / end
> > actions rss queues 1 2 end level 1 / end
> >
> > GRE tunnel flow outer RSS:
> >   flow create 0 ingress pattern eth  / ipv4 proto is 47 / gre / end
> > actions rss queues 1 2 end level 0 / end
> >
> > Signed-off-by: Xueming Li 
> > ---
> >  drivers/net/mlx5/Makefile|   2 +-
> >  drivers/net/mlx5/mlx5_flow.c | 249
> > ++-
> >  drivers/net/mlx5/mlx5_glue.c |  16 +++
> >  drivers/net/mlx5/mlx5_glue.h |   8 ++
> >  drivers/net/mlx5/mlx5_rxq.c  |  46 +++-
> >  drivers/net/mlx5/mlx5_rxtx.h |   5 +-
> >  6 files changed, 246 insertions(+), 80 deletions(-)
> >
> > diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
> > index ae118ad33..f9a6c460b 100644
> > --- a/drivers/net/mlx5/Makefile
> > +++ b/drivers/net/mlx5/Makefile
> > @@ -35,7 +35,7 @@ include $(RTE_SDK)/mk/rte.vars.mk  LIB =
> > librte_pmd_mlx5.a  LIB_GLUE = $(LIB_GLUE_BASE).$(LIB_GLUE_VERSION)
> >  LIB_GLUE_BASE = librte_pmd_mlx5_glue.so -LIB_GLUE_VERSION = 18.02.0
> > +LIB_GLUE_VERSION = 18.05.0
> >
> >  # Sources.
> >  SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5.c diff --git
> > a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c index
> > 64658bc0e..66c7d7993 100644
> > --- a/drivers/net/mlx5/mlx5_flow.c
> > +++ b/drivers/net/mlx5/mlx5_flow.c
> > @@ -113,6 +113,7 @@ enum hash_rxq_type {
> > HASH_RXQ_UDPV6,
> > HASH_RXQ_IPV6,
> > HASH_RXQ_ETH,
> > +   HASH_RXQ_TUNNEL,
> >  };
> >
> >  /* Initialization data for hash RX queue. */ @@ -451,6 +452,7 @@
> > struct mlx5_flow_parse {
> > uint16_t queues[RTE_MAX_QUEUES_PER_PORT]; /**< Queues indexes to use.
> */
> > uint8_t rss_key[40]; /**< copy of the RSS key. */
> > enum hash_rxq_type layer; /**< Last pattern layer detected. */
> > +   enum hash_rxq_type out_layer; /**< Last outer pattern layer
> > +detected. */
> > uint32_t tunnel; /**< Tunnel type of RTE_PTYPE_TUNNEL_XXX. */
> > struct ibv_counter_set *cs; /**< Holds the counter set for the rule
> */
> > struct {
> > @@ -458,6 +460,7 @@ struct mlx5_flow_parse {
> > /**< Pointer to Verbs attributes. */
> > unsigned int offset;
> > /**< Current position or total size of the attribute. */
> > +   uint64_t hash_fields; /**< Verbs hash fields. */
> > } queue[RTE_DIM(hash_rxq_init)];
> >  };
> >
> > @@ -698,7 +701,8 @@ mlx5_flow_convert_actions(struct rte_eth_dev *dev,
> >" function is Toeplitz");
> > return -rte_errno;
> > }
> > -   if (rss->level) {
> > +#ifndef HAVE_IBV_DEVICE_TUNNEL_SUPPORT
> > +   if (parser->rss_conf.level > 0) {
> 
> According to Adrien's API level 0 means do whatever you want and 1 means
> outer.
> This is removing the outer RSS support.
> 
> > rte_flow_error_set(error, EINVAL,
> >RTE_FLOW_ERROR_TYPE_ACTION,
> >actions,
> > @@ -706,6 +710,15 @@ mlx5_flow_convert_actions(struct rte_eth_dev *dev,
> >" level is not supported");
> > return -rte_errno;
> > }
> > +#endif
> > +   if (parser->rss_conf.level > 1) {
> > +   rte_flow_error_set(error, EINVAL,
> > +  RTE_FLOW_ERROR_TYPE_ACTION,
> > +  actions,
> > +  "RSS encapsulation level"
> > +  " > 1 is not supported");
> > +   return -rte_errno;
> > +   }
> 
> Seems the levels are wrongly used.

Thanks, updated.

> 
> > if (rss->types & MLX5_RSS_HF_MASK) {
> > rte_flow_error_set(error, EINVAL,
> >RTE_FLOW_ERROR_TYPE_ACTION,
> > @@ -756,7 +769,7 @@ mlx5_flow_convert_actions(struct rte_eth_dev *dev,
> > }
> > parser->rss_conf = (struct rte_flow_action_rss){
> > .func = RTE_ETH_HASH_FUNCTION_DEFAULT,
> > -   .level = 0,
> > +   .level = rss->level,
> > .types = rss->types,
> 

Re: [dpdk-dev] [PATCH v3 04/14] net/mlx5: support Rx tunnel type identification

[Xueming(Steven) Li]

+Adrien

> -Original Message-
> From: Nélio Laranjeiro 
> Sent: Friday, April 13, 2018 9:03 PM
> To: Xueming(Steven) Li 
> Cc: Shahaf Shuler ; dev@dpdk.org; Olivier Matz
> 
> Subject: Re: [PATCH v3 04/14] net/mlx5: support Rx tunnel type
> identification
> 
> +Olivier,
> 
> On Fri, Apr 13, 2018 at 07:20:13PM +0800, Xueming Li wrote:
> > This patch introduced tunnel type identification based on flow rules.
> > If flows of multiple tunnel types built on same queue,
> > RTE_PTYPE_TUNNEL_MASK will be returned, user application could use
> > bits in flow mark as tunnel type identifier.
> 
> For an application it will mean the packet embed all tunnel types defined
> in DPDK, to make such thing you need a RTE_PTYPE_TUNNEL_UNKNOWN which does
> not exists currently.

There was a RTE_PTYPE_TUNNEL_UNKNOWN definition, but removed due to discussion.
So I think it good to add it in the patchset of reviewed by Adrien.

> Even with it, the application still needs to parse the packet to discover
> which tunnel the packet embed, is there any benefit having such bit?  Not
> so sure.

With a tunnel flag, checksum status represent inner checksum.
Setting flow mark for different flow type could save time of parsing tunnel.

> 
> Thanks,
> 
> > Signed-off-by: Xueming Li 
> > ---
> >  drivers/net/mlx5/mlx5_flow.c  | 127
> +-
> >  drivers/net/mlx5/mlx5_rxq.c   |  11 ++-
> >  drivers/net/mlx5/mlx5_rxtx.c  |  12 ++--
> >  drivers/net/mlx5/mlx5_rxtx.h  |   9 ++-
> >  drivers/net/mlx5/mlx5_rxtx_vec_neon.h |  21 +++---
> > drivers/net/mlx5/mlx5_rxtx_vec_sse.h  |  17 +++--
> >  6 files changed, 159 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/net/mlx5/mlx5_flow.c
> > b/drivers/net/mlx5/mlx5_flow.c index 644f26a95..7d04b4d65 100644
> > --- a/drivers/net/mlx5/mlx5_flow.c
> > +++ b/drivers/net/mlx5/mlx5_flow.c
> > @@ -225,6 +225,7 @@ struct rte_flow {
> > struct rte_flow_action_rss rss_conf; /**< RSS configuration */
> > uint16_t (*queues)[]; /**< Queues indexes to use. */
> > uint8_t rss_key[40]; /**< copy of the RSS key. */
> > +   uint32_t tunnel; /**< Tunnel type of RTE_PTYPE_TUNNEL_XXX. */
> > struct ibv_counter_set *cs; /**< Holds the counters for the rule. */
> > struct mlx5_flow_counter_stats counter_stats;/** */
> > struct mlx5_flow frxq[RTE_DIM(hash_rxq_init)]; @@ -241,6 +242,19 @@
> > struct rte_flow {
> > (type) == RTE_FLOW_ITEM_TYPE_VXLAN || \
> > (type) == RTE_FLOW_ITEM_TYPE_GRE)
> >
> > +const uint32_t flow_ptype[] = {
> > +   [RTE_FLOW_ITEM_TYPE_VXLAN] = RTE_PTYPE_TUNNEL_VXLAN,
> > +   [RTE_FLOW_ITEM_TYPE_GRE] = RTE_PTYPE_TUNNEL_GRE, };
> > +
> > +#define PTYPE_IDX(t) ((RTE_PTYPE_TUNNEL_MASK & (t)) >> 12)
> > +
> > +const uint32_t ptype_ext[] = {
> > +   [PTYPE_IDX(RTE_PTYPE_TUNNEL_VXLAN)] = RTE_PTYPE_TUNNEL_VXLAN |
> > + RTE_PTYPE_L4_UDP,
> > +   [PTYPE_IDX(RTE_PTYPE_TUNNEL_GRE)] = RTE_PTYPE_TUNNEL_GRE, };
> > +
> >  /** Structure to generate a simple graph of layers supported by the
> > NIC. */  struct mlx5_flow_items {
> > /** List of possible actions for these items. */ @@ -440,6 +454,7 @@
> > struct mlx5_flow_parse {
> > uint16_t queues[RTE_MAX_QUEUES_PER_PORT]; /**< Queues indexes to use.
> */
> > uint8_t rss_key[40]; /**< copy of the RSS key. */
> > enum hash_rxq_type layer; /**< Last pattern layer detected. */
> > +   uint32_t tunnel; /**< Tunnel type of RTE_PTYPE_TUNNEL_XXX. */
> > struct ibv_counter_set *cs; /**< Holds the counter set for the rule
> */
> > struct {
> > struct ibv_flow_attr *ibv_attr;
> > @@ -858,7 +873,7 @@ mlx5_flow_convert_items_validate(const struct
> rte_flow_item items[],
> > if (ret)
> > goto exit_item_not_supported;
> > if (IS_TUNNEL(items->type)) {
> > -   if (parser->inner) {
> > +   if (parser->tunnel) {
> > rte_flow_error_set(error, ENOTSUP,
> >RTE_FLOW_ERROR_TYPE_ITEM,
> >items,
> > @@ -867,6 +882,7 @@ mlx5_flow_convert_items_validate(const struct
> rte_flow_item items[],
> > return -rte_errno;
> > }
> > parser->inner = IBV_FLOW_SPEC_INNER;
> > +   parser->tunnel = flow_ptype[items->type];
> > }
> > if (parser->drop) {
> > parser->queue[HASH_RXQ_ETH].offset += cur_item->dst_sz;
> @@ -1175,6
> > +1191,7 @@ mlx5_flow_convert(struct rte_eth_dev *dev,
> > }
> > /* Third step. Conversion parse, fill the specifications. */
> > parser->inner = 0;
> > +   parser->tunnel = 0;
> > for (; items->type != RTE_FLOW_ITEM_TYPE_END; ++items) {
> > struct mlx5_flow_data data = {
> > .parser = parser,
> > @@ -1643,6 +1660,7 @@ mlx5_flow_create_

Re: [dpdk-dev] [PATCH] vhost: fix meson build for vDPA

[Maxime Coquelin]

On 04/14/2018 11:22 AM, Jay Zhou wrote:

CC: Zhihong Wang 
Fixes: 8b991d412e (vhost: support selective datapath)

Signed-off-by: Jay Zhou 
---
  lib/librte_vhost/meson.build | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_vhost/meson.build b/lib/librte_vhost/meson.build
index 66cced1cb..b021894a0 100644
--- a/lib/librte_vhost/meson.build
+++ b/lib/librte_vhost/meson.build
@@ -10,6 +10,6 @@ endif
  version = 4
  allow_experimental_apis = true
  sources = files('fd_man.c', 'iotlb.c', 'socket.c', 'vhost.c', 'vhost_user.c',
-   'virtio_net.c', 'vhost_crypto.c')
+   'virtio_net.c', 'vhost_crypto.c', 'vdpa.c')
  headers = files('rte_vhost.h', 'rte_vhost_crypto.h')
  deps += ['ethdev', 'cryptodev', 'hash', 'pci']



Reviewed-by: Maxime Coquelin 

Thanks!
Maxime

Re: [dpdk-dev] [PATCH v5 02/21] eal: list acceptable init priorities

[Neil Horman]

On Fri, Apr 13, 2018 at 02:55:11PM +0200, Gaëtan Rivet wrote:
> Hi Shreyansh,
> 
> On Fri, Apr 13, 2018 at 06:22:43PM +0530, Shreyansh Jain wrote:
> > On Friday 13 April 2018 05:12 PM, Neil Horman wrote:
> > > On Thu, Apr 12, 2018 at 11:57:47PM +0200, Gaëtan Rivet wrote:
> > > > Hello Neil,
> > > > 
> > > > On Thu, Apr 12, 2018 at 07:28:26AM -0400, Neil Horman wrote:
> > > > > On Wed, Apr 11, 2018 at 02:04:03AM +0200, Gaetan Rivet wrote:
> > > > > > Build a central list to quickly see each used priorities for
> > > > > > constructors, allowing to verify that they are both above 100 and 
> > > > > > in the
> > > > > > proper order.
> > > > > > 
> > > > > > Signed-off-by: Gaetan Rivet 
> > > > > > Acked-by: Neil Horman 
> > > > > > Acked-by: Shreyansh Jain 
> > > > > > ---
> > > > > >   lib/librte_eal/common/eal_common_log.c | 2 +-
> > > > > >   lib/librte_eal/common/include/rte_bus.h| 2 +-
> > > > > >   lib/librte_eal/common/include/rte_common.h | 8 +++-
> > > > > >   3 files changed, 9 insertions(+), 3 deletions(-)
> > > > > > 
> > > > > > diff --git a/lib/librte_eal/common/eal_common_log.c 
> > > > > > b/lib/librte_eal/common/eal_common_log.c
> > > > > > index a27192620..36b9d6e08 100644
> > > > > > --- a/lib/librte_eal/common/eal_common_log.c
> > > > > > +++ b/lib/librte_eal/common/eal_common_log.c
> > > > > > @@ -260,7 +260,7 @@ static const struct logtype logtype_strings[] = 
> > > > > > {
> > > > > >   };
> > > > > >   /* Logging should be first initializer (before drivers and bus) */
> > > > > > -RTE_INIT_PRIO(rte_log_init, 101);
> > > > > > +RTE_INIT_PRIO(rte_log_init, LOG);
> > > > > >   static void
> > > > > >   rte_log_init(void)
> > > > > >   {
> > > > > > diff --git a/lib/librte_eal/common/include/rte_bus.h 
> > > > > > b/lib/librte_eal/common/include/rte_bus.h
> > > > > > index 6fb08341a..eb9eded4e 100644
> > > > > > --- a/lib/librte_eal/common/include/rte_bus.h
> > > > > > +++ b/lib/librte_eal/common/include/rte_bus.h
> > > > > > @@ -325,7 +325,7 @@ enum rte_iova_mode 
> > > > > > rte_bus_get_iommu_class(void);
> > > > > >* The constructor has higher priority than PMD constructors.
> > > > > >*/
> > > > > >   #define RTE_REGISTER_BUS(nm, bus) \
> > > > > > -RTE_INIT_PRIO(businitfn_ ##nm, 110); \
> > > > > > +RTE_INIT_PRIO(businitfn_ ##nm, BUS); \
> > > > > >   static void businitfn_ ##nm(void) \
> > > > > >   {\
> > > > > > (bus).name = RTE_STR(nm);\
> > > > > > diff --git a/lib/librte_eal/common/include/rte_common.h 
> > > > > > b/lib/librte_eal/common/include/rte_common.h
> > > > > > index 6c5bc5a76..8f04518f7 100644
> > > > > > --- a/lib/librte_eal/common/include/rte_common.h
> > > > > > +++ b/lib/librte_eal/common/include/rte_common.h
> > > > > > @@ -81,6 +81,12 @@ typedef uint16_t unaligned_uint16_t;
> > > > > >*/
> > > > > >   #define RTE_SET_USED(x) (void)(x)
> > > > > > +#define RTE_PRIORITY_LOG 101
> > > > > > +#define RTE_PRIORITY_BUS 110
> > > > > > +
> > > > > > +#define RTE_PRIO(prio) \
> > > > > > +   RTE_PRIORITY_ ## prio
> > > > > > +
> > > > > >   /**
> > > > > >* Run function before main() with low priority.
> > > > > >*
> > > > > > @@ -102,7 +108,7 @@ static void __attribute__((constructor, used)) 
> > > > > > func(void)
> > > > > >*   Lowest number is the first to run.
> > > > > >*/
> > > > > >   #define RTE_INIT_PRIO(func, prio) \
> > > > > > -static void __attribute__((constructor(prio), used)) func(void)
> > > > > > +static void __attribute__((constructor(RTE_PRIO(prio)), used)) 
> > > > > > func(void)
> > > > > It just occured to me, that perhaps you should add a RTE_PRORITY_LAST 
> > > > > priority,
> > > > > and redefine RTE_INIT to RTE_INIT_PRIO(func, RTE_PRIORITY_LAST) for 
> > > > > clarity.  I
> > > > > presume that constructors with no explicit priority run last, but the 
> > > > > gcc
> > > > > manual doesn't explicitly say that.  It would be a heck of a bug to 
> > > > > track down
> > > > > if somehow unprioritized constructors ran early.
> > > > > 
> > > > > Neil
> > > > > 
> > > > 
> > > > While certainly poorly documented, the behavior is well-defined. I 
> > > > don't see
> > > > a situation where the bug you describe could arise.
> > > > 
> > > > Adding RTE_PRIORITY_LAST is pretty harmless, but I'm not sure it's
> > > > justified to add it. If you still think it is useful, I will do it.
> > > > 
> > > It was more just a way to unify the macros is all, probably not important.
> > > 
> > > > I'd be curious to hear if anyone has had issues of this kind.
> > > > 
> > > I've not had any, but I was suprised to see that the gcc manual didn't
> > > explicitly call out the implied priority of unprioritized constructors
> > 
> > I (tried to) looked into the gcc code base. It seems that when priority is
> > not defined, DEFAULT_INIT_PRIORITY 65536, is used.
> > 
> > --->8--- gcc/collect2.c ---
> >   /* Extract init_p number from ctor/dtor name.  */
> >   pri = atoi (name + pos);
> >   return pri ? pri : DEFAULT_INIT_PRIOR

Re: [dpdk-dev] kernel binding of devices + hotplug

[Matan Azrad]

Hi all

From: Burakov, Anatoly, Friday, April 13, 2018 8:41 PM
> To: Bruce Richardson ; Thomas Monjalon
> 
> Cc: dev@dpdk.org; pmati...@redhat.com; david.march...@6wind.com;
> jia@intel.com; Matan Azrad ;
> konstantin.anan...@intel.com; step...@networkplumber.org;
> f...@redhat.com
> Subject: Re: kernel binding of devices + hotplug
> 
> On 13-Apr-18 5:40 PM, Bruce Richardson wrote:
> > On Fri, Apr 13, 2018 at 06:31:21PM +0200, Thomas Monjalon wrote:
> >> It's time to think (again) how we bind devices with kernel modules.
> >> We need to decide how we want to manage hotplugged devices with
> DPDK.
> >>
> >> A bit of history first.
> >> There was some code in DPDK for bind/unbind, but it has been removed
> >> in DPDK 1.7 -
> >>
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd
> >>
> k.org%2Fcommit%2F5d8751b83&data=02%7C01%7Cmatan%40mellanox.com
> %7C6ea5
> >>
> 5ce994ff4bb0d65208d5a165b417%7Ca652971c7d2e4d9ba6a4d149256f461b%7
> C0%7
> >>
> C0%7C636592380565078675&sdata=uLRDAk65hYtJYxjIvY20de377yayCN5DrjCZ
> x8H
> >> p61o%3D&reserved=0 Copy of the commit message (in 2014):
> >> "
> >>The bind/unbind operations should not be handled by the eal.
> >>These operations should be either done outside of dpdk or
> >>inside the PMDs themselves as these are their problems.
> >> "
> >>
> >> The question raised at this time (4 years ago) is still under discussion.
> >> Should we manage binding inside or outside DPDK?
> >> Should it be controlled in the application or in the OS base?
> >>
> >> As you know, we use dpdk-devbind.py.
> >> This tool lacks two major features:
> >>- persistent configuration
> >>- hotplug
> >>
> >> If we consider that the DPDK applications should be able to apply its
> >> own policy to choose the devices to bind, then we need to implement
> >> binding in the PMD (with EAL helpers).
> >>
> >> On the other hand, if we consider that it is the system
> >> responsibility, then we could choose systemd/udev and driverctl.
> >>
> >> The debate is launched!
> >>
> >
> > Allow me to nail my colours to the mast early! :-)
> >
> > I believe it's system not application responsibility.
> > I also believe I have previously explained my reasons for that choice
> > in some of the previous email threads.
> 
> For what it's worth, I tend to agree, if only because writing code for what is
> essentially a bunch of read/write/filesystem enumeration in C is extremely
> fiddly and error prone :) IMO things like this are better handled either by
> scripts, or by tools whose sole purpose is doing exactly that (or both).
> 
> I like having scripts like devbind in DPDK because we can tailor them to our
> use cases better, and having them is amenable to automation, but while I
> wouldn't be opposed to removing them altogether in favor of some external
> tool (systemd/udev/driverctl/whatever), in my humble opinion moving them
> back into EAL or even PMD's would be a mistake.
> 

Since the application runs in the system by a command of the system user I 
think the responsibility is for the user.
The DPDK user forwards the control of some devices to the DPDK application 
using the EAL whitelist\blacklist mode to specify the devices,
Any DPDK PMD should know which binding it needs to probe\control the device and 
can apply it,
So, if the user asks to control on a device by DPDK application it makes sense 
that the application will do the correct binding to the device since the user 
wants to use it(no need to ask more operation of pre binding from the user).

Regarding the conflict of system rules for a device, it is again the user 
responsibility, whatever we will decide for the binding procedure of DPDK 
application the user needs to take it into account and to solve such like 
conflicts.
One option is to remove any binding rules of a DPDK device in the DPDK 
application initialization and adjust the new rules by the PMDs, then any 
conflict should not disturb the user.

In current hot-plug case the application will need to do a lot of work to 
bind\remap devices in plug-in\plug-out events while the PMD could have all the 
knowledge to do it. 

One more issue with the script is that the user should do different bind per 
device, in case of PMD responsibility the user can forget it:
Think about that, any time the user wants to switch\add new supported nic it 
should update the script usage and to do per nic operation contrary to the DPDK 
principles.

Matan.

> Thanks,
> Anatoly

Re: [dpdk-dev] kernel binding of devices + hotplug

[Stephen Hemminger]

My vote is to work with udev and not try to replace it.

Driverctl works well. Just not for bifurcated driver

On Fri, Apr 13, 2018, 9:31 AM Thomas Monjalon  wrote:

> It's time to think (again) how we bind devices with kernel modules.
> We need to decide how we want to manage hotplugged devices with DPDK.
>
> A bit of history first.
> There was some code in DPDK for bind/unbind, but it has been removed
> in DPDK 1.7 - http://dpdk.org/commit/5d8751b83
> Copy of the commit message (in 2014):
> "
> The bind/unbind operations should not be handled by the eal.
> These operations should be either done outside of dpdk or
> inside the PMDs themselves as these are their problems.
> "
>
> The question raised at this time (4 years ago) is still under discussion.
> Should we manage binding inside or outside DPDK?
> Should it be controlled in the application or in the OS base?
>
> As you know, we use dpdk-devbind.py.
> This tool lacks two major features:
> - persistent configuration
> - hotplug
>
> If we consider that the DPDK applications should be able to apply its own
> policy to choose the devices to bind, then we need to implement binding
> in the PMD (with EAL helpers).
>
> On the other hand, if we consider that it is the system responsibility,
> then we could choose systemd/udev and driverctl.
>
> The debate is launched!
>
> Please find more details in the references below.
>
> Announce of driverctl:
> http://dpdk.org/ml/archives/dev/2015-December/029500.html
> Repository of driverctl:
> https://gitlab.com/driverctl/driverctl
>
> Discussion about binding script and driverctl:
> http://dpdk.org/ml/archives/dev/2018-April/095687.html
>
> Patch to implement binding in DPDK (for hotplug):
> http://dpdk.org/ml/archives/dev/2018-April/095714.html
>
> Discussion in the same hotplug series:
> http://dpdk.org/ml/archives/dev/2018-April/097058.html
>
>
>
>

Re: [dpdk-dev] kernel binding of devices + hotplug

[Wiles, Keith]

On Apr 13, 2018, at 11:40 AM, Bruce Richardson 
mailto:bruce.richard...@intel.com>> wrote:

On Fri, Apr 13, 2018 at 06:31:21PM +0200, Thomas Monjalon wrote:
It's time to think (again) how we bind devices with kernel modules.
We need to decide how we want to manage hotplugged devices with DPDK.

A bit of history first.
There was some code in DPDK for bind/unbind, but it has been removed
in DPDK 1.7 - http://dpdk.org/commit/5d8751b83
Copy of the commit message (in 2014):
"
The bind/unbind operations should not be handled by the eal.
These operations should be either done outside of dpdk or
inside the PMDs themselves as these are their problems.
"

The question raised at this time (4 years ago) is still under discussion.
Should we manage binding inside or outside DPDK?
Should it be controlled in the application or in the OS base?

As you know, we use dpdk-devbind.py.
This tool lacks two major features:
- persistent configuration
- hotplug

If we consider that the DPDK applications should be able to apply its own
policy to choose the devices to bind, then we need to implement binding
in the PMD (with EAL helpers).

On the other hand, if we consider that it is the system responsibility,
then we could choose systemd/udev and driverctl.

The debate is launched!


Allow me to nail my colours to the mast early! :-)

I believe it's system not application responsibility.
I also believe I have previously explained my reasons for that choice in
some of the previous email threads.

I agree the system should be handling hot-plug and device bindings as the 
sys-admin or orchestration layer would be handling what device 
appears/disappears plus which are accessible by an application. Now an 
application would need to know when a device appears/disappears, which should 
be handled by the current hot-plug support (I assume).


/Bruce

Regards,
Keith

Re: [dpdk-dev] [PATCH v2] doc: reduce initial offload API scope to drivers

[Shahaf Shuler]

Saturday, April 14, 2018 12:21 AM, Ferruh Yigit:
> Subject: [PATCH v2] doc: reduce initial offload API scope to drivers
> 
> Do ethdev new offloading API switch in two steps.
> 
> In v18.05 target is implementing the new ethdev-PMD offload interface,
> which means converting all PMDs to new offloading API.
> 
> Next target is removing the old ethdev offload API.
> It will effect applications and will force them to implement new offloading
> API.
> 
> Fixes: 3004d3454192 ("doc: update deprecation of ethdev offload API")
> Cc: shah...@mellanox.com
> 
> Signed-off-by: Ferruh Yigit 
> ---
> v2:
> * Update commit log and deprecation notice for clarification
> ---
>  doc/guides/rel_notes/deprecation.rst | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index c929dcc31..fd9def20c 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -72,8 +72,12 @@ Deprecation Notices
>  * ethdev: a new Tx and Rx offload API was introduced on 17.11.
>In the new API, offloads are divided into per-port and per-queue offloads.
>Offloads are disabled by default and enabled per application request.
> -  The old offloads API is target to be deprecated on 18.05. This includes:
> 
> +  The old ethdev - drivers offload interface will be deprecated on 18.05.
> +  This includes:
> +  - removal of the conversion in ethdev from new offloading API to old API
> for drivers.
> +
> +  In later releases the old offloading API will be deprecated, which will
> include:
>- removal of ``ETH_TXQ_FLAGS_NO*`` flags.
>- removal of ``txq_flags`` field from ``rte_eth_txconf`` struct.
>- removal of the offloads bit-field from ``rte_eth_rxmode`` struct.
> --
> 2.14.3

Acked-by: Shahaf Shuler