Re: [dpdk-dev] [PATCH v10 2/3] lib/gro: add TCP/IPv4 GRO support

2017-07-02 Thread Tan, Jianfeng



On 7/1/2017 7:08 PM, Jiayu Hu wrote:

In this patch, we introduce five APIs to support TCP/IPv4 GRO.
- gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used
 to merge packets.
- gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table.
- gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4
 reassembly table.
- gro_tcp4_tbl_item_num: return the number of packets in a TCP/IPv4
 reassembly table.
- gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet.

TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4
and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP
checksums for merged packets. If inputted packets are IP fragmented,
TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4
headers).

In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly
table, to reassemble packets. A TCP/IPv4 reassembly table includes a key
array and a item array, where the key array keeps the criteria to merge
packets and the item array keeps packet information.

One key in the key array points to an item group, which consists of
packets which have the same criteria value. If two packets are able to
merge, they must be in the same item group. Each key in the key array
includes two parts:
- criteria: the criteria of merging packets. If two packets can be
 merged, they must have the same criteria value.
- start_index: the index of the first incoming packet of the item group.

Each element in the item array keeps the information of one packet. It
mainly includes two parts:
- pkt: packet address
- next_pkt_index: the index of the next packet in the same item group.
 All packets in the same item group are chained by next_pkt_index.
 With next_pkt_index, we can locate all packets in the same item
 group one by one.

To process an incoming packet needs three steps:
a. check if the packet should be processed. Packets with one of the
 following properties won't be processed:
- SYN, FIN, RST or PSH bit is set;
- packet payload length is 0.
b. traverse the key array to find a key which has the same criteria
 value with the incoming packet. If find, goto step c. Otherwise,
 insert a new key and insert the packet into the item array.
c. locate the first packet in the item group via the start_index in the
 key. Then traverse all packets in the item group via next_pkt_index.
 If find one packet which can merge with the incoming one, merge them
 together. If can't find, insert the packet into this item group.

Signed-off-by: Jiayu Hu 
---
  doc/guides/rel_notes/release_17_08.rst |   7 +
  lib/librte_gro/Makefile|   1 +
  lib/librte_gro/rte_gro.c   | 123 -
  lib/librte_gro/rte_gro.h   |  10 +-
  lib/librte_gro/rte_gro_tcp4.c  | 439 +
  lib/librte_gro/rte_gro_tcp4.h  | 172 +
  6 files changed, 736 insertions(+), 16 deletions(-)
  create mode 100644 lib/librte_gro/rte_gro_tcp4.c
  create mode 100644 lib/librte_gro/rte_gro_tcp4.h

diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index 842f46f..f067247 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -75,6 +75,13 @@ New Features
  
Added support for firmwares with multiple Ethernet ports per physical port.
  
+* **Add Generic Receive Offload API support.**

+
+  Generic Receive Offload (GRO) API supports to reassemble TCP/IPv4
+  packets. GRO API assumes all inputted packets are with correct
+  checksums. GRO API doesn't update checksums for merged packets. If
+  inputted packets are IP fragmented, GRO API assumes they are complete
+  packets (i.e. with L4 headers).
  
  Resolved Issues

  ---
diff --git a/lib/librte_gro/Makefile b/lib/librte_gro/Makefile
index 7e0f128..43e276e 100644
--- a/lib/librte_gro/Makefile
+++ b/lib/librte_gro/Makefile
@@ -43,6 +43,7 @@ LIBABIVER := 1
  
  # source files

  SRCS-$(CONFIG_RTE_LIBRTE_GRO) += rte_gro.c
+SRCS-$(CONFIG_RTE_LIBRTE_GRO) += rte_gro_tcp4.c
  
  # install this header file

  SYMLINK-$(CONFIG_RTE_LIBRTE_GRO)-include += rte_gro.h
diff --git a/lib/librte_gro/rte_gro.c b/lib/librte_gro/rte_gro.c
index 648835b..a4641f9 100644
--- a/lib/librte_gro/rte_gro.c
+++ b/lib/librte_gro/rte_gro.c
@@ -32,8 +32,11 @@
  
  #include 

  #include 
+#include 
+#include 
  
  #include "rte_gro.h"

+#include "rte_gro_tcp4.h"
  
  typedef void *(*gro_tbl_create_fn)(uint16_t socket_id,

uint16_t max_flow_num,
@@ -41,9 +44,12 @@ typedef void *(*gro_tbl_create_fn)(uint16_t socket_id,
  typedef void (*gro_tbl_destroy_fn)(void *tbl);
  typedef uint32_t (*gro_tbl_item_num_fn)(void *tbl);
  
-static gro_tbl_create_fn tbl_create_functions[RTE_GRO_TYPE_MAX_NUM];

-static gro_tbl_destroy_fn tbl_destroy_functions[RTE_GRO_TYPE_MAX_NUM];
-static gro_tbl_item_num_fn tbl_item_num_functions[

Re: [dpdk-dev] [PATCH v10 1/3] lib: add Generic Receive Offload API framework

2017-07-02 Thread Tan, Jianfeng



On 7/1/2017 7:08 PM, Jiayu Hu wrote:

Generic Receive Offload (GRO) is a widely used SW-based offloading
technique to reduce per-packet processing overhead. It gains
performance by reassembling small packets into large ones. This
patchset is to support GRO in DPDK. To support GRO, this patch
implements a GRO API framework.

To enable more flexibility to applications, DPDK GRO is implemented as
a user library. Applications explicitly use the GRO library to merge
small packets into large ones. DPDK GRO provides two reassembly modes.
One is called lightweight mode, the other is called heavyweight mode.
If applications want to merge packets in a simple way and the number
of packets is relatively small, they can use the lightweight mode.
If applications need more fine-grained controls, they can choose the
heavyweight mode.

rte_gro_reassemble_burst is the main reassembly API which is used in
lightweight mode and processes N packets at a time. For applications,
performing GRO in lightweight mode is simple. They just need to invoke
rte_gro_reassemble_burst. Applications can get GROed packets as soon as
rte_gro_reassemble_burst returns.

rte_gro_reassemble is the main reassembly API which is used in
heavyweight mode and tries to merge N inputted packets with the packets
in a givn GRO table. For applications, performing GRO in heavyweight
mode is relatively complicated. Before performing GRO, applications need
to create a GRO table by rte_gro_tbl_create. Then they can use
rte_gro_reassemble to merge packets. The GROed packets are in the GRO
table. If applications want to get them, applications need to manually
flush them by flush API.



Signed-off-by: Jiayu Hu 
---
  config/common_base |   5 ++
  lib/Makefile   |   2 +
  lib/librte_gro/Makefile|  50 +++
  lib/librte_gro/rte_gro.c   | 176 +
  lib/librte_gro/rte_gro.h   | 176 +
  lib/librte_gro/rte_gro_version.map |  12 +++
  mk/rte.app.mk  |   1 +
  7 files changed, 422 insertions(+)
  create mode 100644 lib/librte_gro/Makefile
  create mode 100644 lib/librte_gro/rte_gro.c
  create mode 100644 lib/librte_gro/rte_gro.h
  create mode 100644 lib/librte_gro/rte_gro_version.map

diff --git a/config/common_base b/config/common_base
index f6aafd1..167f5ef 100644
--- a/config/common_base
+++ b/config/common_base
@@ -712,6 +712,11 @@ CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
  CONFIG_RTE_LIBRTE_PMD_VHOST=n
  
  #

+# Compile GRO library
+#
+CONFIG_RTE_LIBRTE_GRO=y
+
+#
  #Compile Xen domain0 support
  #
  CONFIG_RTE_LIBRTE_XEN_DOM0=n
diff --git a/lib/Makefile b/lib/Makefile
index 07e1fd0..ac1c2f6 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -106,6 +106,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += librte_reorder
  DEPDIRS-librte_reorder := librte_eal librte_mempool librte_mbuf
  DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += librte_pdump
  DEPDIRS-librte_pdump := librte_eal librte_mempool librte_mbuf librte_ether
+DIRS-$(CONFIG_RTE_LIBRTE_GRO) += librte_gro
+DEPDIRS-librte_gro := librte_eal librte_mbuf librte_ether librte_net
  
  ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)

  DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
diff --git a/lib/librte_gro/Makefile b/lib/librte_gro/Makefile
new file mode 100644
index 000..7e0f128
--- /dev/null
+++ b/lib/librte_gro/Makefile
@@ -0,0 +1,50 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2017 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING I

Re: [dpdk-dev] [PATCH 1/2] crypto/aesni_mb: support IPSec Multi-buffer lib v0.46

2017-07-02 Thread De Lara Guarch, Pablo


> -Original Message-
> From: Gonzalez Monroy, Sergio
> Sent: Friday, June 30, 2017 2:52 PM
> To: De Lara Guarch, Pablo ; Doherty,
> Declan 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] crypto/aesni_mb: support IPSec Multi-
> buffer lib v0.46
> 
> On 28/06/2017 12:48, Pablo de Lara wrote:
> > IPSec Multi-buffer library v0.46 has been released, which includes,
> > among othe features, support for 12-byte IV, for AES-CTR, keeping also
> > the previous 16-byte IV, for backward compatibility reasons.
> >
> > Signed-off-by: Pablo de Lara 
> > ---
> >   doc/guides/cryptodevs/aesni_mb.rst | 18 +-
> >   doc/guides/rel_notes/release_17_08.rst |  6 ++
> >   drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  4 ++--
> >   3 files changed, 25 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/guides/cryptodevs/aesni_mb.rst
> > b/doc/guides/cryptodevs/aesni_mb.rst
> > index ecb52a1..fafcd9f 100644
> > --- a/doc/guides/cryptodevs/aesni_mb.rst
> > +++ b/doc/guides/cryptodevs/aesni_mb.rst
> > @@ -69,6 +69,9 @@ Limitations
> >   * Chained mbufs are not supported.
> >   * Only in-place is currently supported (destination address is the same
> as source address).
> >   * Only supports session-oriented API implementation (session-less APIs
> are not supported).
> > +* If IV is passed with 16 bytes, last 4 bytes will be ignored, as
> > +underlying library only
> > +  requires 12 bytes and will append 4 bytes (counter) at the end.
> > +  The library always set these 4 bytes to 1, as IPSec requires counter to
> be set to 1.
> 
> I don't think the text above is correct.

Forgot to remove that, well spotted!
Will send a v2 shortly.

Thanks,
Pablo


[dpdk-dev] [PATCH v2 2/2] test/crypto: add 12-byte IV AES-CTR test cases

2017-07-02 Thread Pablo de Lara
AESNI MB PMD supports now 12-byte IVs, so some tests
are added to check that, apart from the ones with 16-byte IVs,
as this is still compatible.

Signed-off-by: Pablo de Lara 
---
 test/test/test_cryptodev_aes_test_vectors.h | 186 
 1 file changed, 186 insertions(+)

diff --git a/test/test/test_cryptodev_aes_test_vectors.h 
b/test/test/test_cryptodev_aes_test_vectors.h
index 07d6eab..6ebc1c5 100644
--- a/test/test/test_cryptodev_aes_test_vectors.h
+++ b/test/test/test_cryptodev_aes_test_vectors.h
@@ -56,6 +56,17 @@ static const uint8_t ciphertext64_aes128ctr[] = {
0x79, 0x21, 0x70, 0xA0, 0xF3, 0x00, 0x9C, 0xEE
 };
 
+static const uint8_t ciphertext64_aes128ctr_IV_12bytes[] = {
+   0x28, 0x80, 0x28, 0xC7, 0x15, 0x99, 0xC5, 0xA8,
+   0xDD, 0x53, 0xC2, 0x67, 0x1B, 0x86, 0xB8, 0x13,
+   0xAB, 0x25, 0x39, 0x7A, 0xD2, 0x1F, 0x8B, 0x4B,
+   0x94, 0x89, 0x2B, 0x65, 0xCF, 0x89, 0x1E, 0xDD,
+   0xD4, 0x7C, 0xFD, 0x8D, 0x0E, 0xCD, 0x23, 0xA4,
+   0xEB, 0x8C, 0x05, 0x58, 0x45, 0x4A, 0x63, 0x44,
+   0x11, 0x42, 0x07, 0x17, 0xB4, 0xD2, 0xCC, 0x75,
+   0xB7, 0x23, 0x99, 0xA9, 0xC5, 0x89, 0x7F, 0x66
+};
+
 static const uint8_t plaintext_aes_docsis_bpi_cfb[] = {
0x00, 0x01, 0x02, 0x88, 0xEE, 0x59, 0x7E
 };
@@ -98,6 +109,17 @@ static const uint8_t ciphertext64_aes192ctr[] = {
0x59, 0x5E, 0x9E, 0xA5, 0x7B, 0x2D, 0xD7, 0xF0
 };
 
+static const uint8_t ciphertext64_aes192ctr_IV_12bytes[] = {
+   0x67, 0x65, 0xa9, 0xee, 0xfd, 0x31, 0x62, 0xfc,
+   0xad, 0xfd, 0xc7, 0x25, 0xb7, 0x25, 0x16, 0xbe,
+   0x25, 0xce, 0xc0, 0x1d, 0xda, 0xa9, 0xd3, 0xda,
+   0x1b, 0x7d, 0x68, 0x6a, 0x6f, 0x06, 0xea, 0x47,
+   0xa0, 0xe0, 0x15, 0xf4, 0xbd, 0x1b, 0x70, 0x34,
+   0xd4, 0x6d, 0x1c, 0x84, 0x17, 0x91, 0x46, 0x0c,
+   0xe8, 0xbc, 0x7a, 0xfb, 0x9f, 0x2a, 0x8f, 0xb4,
+   0xd4, 0xf3, 0x6e, 0x5b, 0x75, 0xa0, 0xce, 0x32
+};
+
 static const uint8_t plaintext_aes256ctr[] = {
0x6B, 0xC1, 0xBE, 0xE2, 0x2E, 0x40, 0x9F, 0x96,
0xE9, 0x3D, 0x7E, 0x11, 0x73, 0x93, 0x17, 0x2A,
@@ -120,6 +142,17 @@ static const uint8_t ciphertext64_aes256ctr[] = {
0x13, 0xC2, 0xDD, 0x08, 0x45, 0x79, 0x41, 0xA6
 };
 
+static const uint8_t ciphertext64_aes256ctr_IV_12bytes[] = {
+   0x7B, 0x7A, 0x7D, 0x83, 0x85, 0xF8, 0x81, 0xF3,
+   0x32, 0x33, 0xD9, 0xFB, 0x04, 0x73, 0xD4, 0x2F,
+   0x70, 0xDE, 0x90, 0x3E, 0xD0, 0xA9, 0x93, 0x8A,
+   0x91, 0xF3, 0xB5, 0x29, 0x4D, 0x2A, 0x74, 0xD0,
+   0xDC, 0x4E, 0x5C, 0x9B, 0x97, 0x24, 0xD8, 0x02,
+   0xFE, 0xAB, 0x38, 0xE8, 0x73, 0x51, 0x29, 0x7E,
+   0xF1, 0xF9, 0x40, 0x78, 0xB1, 0x04, 0x7A, 0x78,
+   0x61, 0x07, 0x47, 0xE6, 0x8C, 0x0F, 0xA8, 0x76
+};
+
 static const uint8_t plaintext_aes_common[] = {
"What a lousy earth! He wondered how many people "
"were destitute that same night even in his own "
@@ -352,6 +385,141 @@ static const struct blockcipher_test_data aes_test_data_3 
= {
}
 };
 
+/* AES128-CTR-SHA1 test vector (12-byte IV) */
+static const struct blockcipher_test_data aes_test_data_1_IV_12_bytes = {
+   .crypto_algo = RTE_CRYPTO_CIPHER_AES_CTR,
+   .cipher_key = {
+   .data = {
+   0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6,
+   0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C
+   },
+   .len = 16
+   },
+   .iv = {
+   .data = {
+   0xF0, 0xF1, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7,
+   0xF8, 0xF9, 0xFA, 0xFB
+   },
+   .len = 12
+   },
+   .plaintext = {
+   .data = plaintext_aes128ctr,
+   .len = 64
+   },
+   .ciphertext = {
+   .data = ciphertext64_aes128ctr_IV_12bytes,
+   .len = 64
+   },
+   .auth_algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
+   .auth_key = {
+   .data = {
+   0xF8, 0x2A, 0xC7, 0x54, 0xDB, 0x96, 0x18, 0xAA,
+   0xC3, 0xA1, 0x53, 0xF6, 0x1F, 0x17, 0x60, 0xBD,
+   0xDE, 0xF4, 0xDE, 0xAD
+   },
+   .len = 20
+   },
+   .digest = {
+   .data = {
+   0x5C, 0x34, 0x6B, 0xE4, 0x9A, 0x7F, 0x4A, 0xC3,
+   0x82, 0xBE, 0xA0, 0x12, 0xD1, 0xF0, 0x15, 0xFA,
+   0xCF, 0xC8, 0x7F, 0x60
+   },
+   .len = 20,
+   .truncated_len = 12
+   }
+};
+
+/** AES-192-CTR XCBC test vector (12-byte IV) */
+static const struct blockcipher_test_data aes_test_data_2_IV_12_bytes = {
+   .crypto_algo = RTE_CRYPTO_CIPHER_AES_CTR,
+   .cipher_key = {
+   .data = {
+   0xCB, 0xC5, 0xED, 0x5B, 0xE7, 0x7C, 0xBD, 0x8C,
+   0x50, 0xD9, 0x30, 0xF2, 0xB5, 0x6A, 0x0E, 0x5F,
+   0xAA, 0xAE, 0xAD, 0xA2, 0x1F, 0x49, 0x52, 0xD4
+   

[dpdk-dev] [PATCH v2 0/2] AES-NI MB PMD: support Multi-buffer library 0.46

2017-07-02 Thread Pablo de Lara
Intel IPSec Multi-buffer library v0.46 has been released,
which among other features, adds support for 12-byte IVs
for AES Counter mode (AES-CTR), since IPSec requires only
12 bytes from the user, which are appended 4 extra bytes,
set to 1 always.

There are no major changes made in the PMD, just documentation
updates and new capability for new IV size supported.

Changes in v2:

- Fixed download link
- Removed incorrect comment in documentation

Pablo de Lara (2):
  crypto/aesni_mb: support IPSec Multi-buffer lib v0.46
  test/crypto: add 12-byte IV AES-CTR test cases

 doc/guides/cryptodevs/aesni_mb.rst |  19 ++-
 doc/guides/rel_notes/release_17_08.rst |   6 +
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |   4 +-
 test/test/test_cryptodev_aes_test_vectors.h| 186 +
 4 files changed, 210 insertions(+), 5 deletions(-)

-- 
2.9.4



[dpdk-dev] [PATCH v2 1/2] crypto/aesni_mb: support IPSec Multi-buffer lib v0.46

2017-07-02 Thread Pablo de Lara
IPSec Multi-buffer library v0.46 has been released,
which includes, among othe features, support for 12-byte IV,
for AES-CTR, keeping also the previous 16-byte IV,
for backward compatibility reasons.

Signed-off-by: Pablo de Lara 
---
 doc/guides/cryptodevs/aesni_mb.rst | 19 ---
 doc/guides/rel_notes/release_17_08.rst |  6 ++
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  4 ++--
 3 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/doc/guides/cryptodevs/aesni_mb.rst 
b/doc/guides/cryptodevs/aesni_mb.rst
index ecb52a1..7d9e977 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -76,8 +76,8 @@ Installation
 To build DPDK with the AESNI_MB_PMD the user is required to download the 
multi-buffer
 library from `here `_
 and compile it on their user system before building DPDK.
-The latest version of the library supported by this PMD is v0.45, which
-can be downloaded in 
``_.
+The latest version of the library supported by this PMD is v0.46, which
+can be downloaded in 
``_.
 
 .. code-block:: console
 
@@ -95,7 +95,7 @@ and the Multi-Buffer library version supported by them:
=  
2.2 - 16.110.43 - 0.44
17.02  0.44
-   17.05  0.45
+   17.05 - 17.08  0.45 - 0.46
=  
 
 
@@ -131,3 +131,16 @@ Example:
 .. code-block:: console
 
 ./l2fwd-crypto -l 6 -n 4 
--vdev="crypto_aesni_mb,socket_id=1,max_nb_sessions=128"
+
+Extra notes
+---
+
+For AES Counter mode (AES-CTR), the library supports two different sizes for 
Initialization
+Vector (IV):
+
+* 12 bytes: used mainly for IPSec, as it requires 12 bytes from the user, 
which internally
+  are appended the counter block (4 bytes), which is set to 1 for the first 
block
+  (no padding required from the user)
+
+* 16 bytes: when passing 16 bytes, the library will take them and use the last 
4 bytes
+  as the initial counter block for the first block.
diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index 842f46f..3d9500a 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -75,6 +75,12 @@ New Features
 
   Added support for firmwares with multiple Ethernet ports per physical port.
 
+* **Updated the AESNI MB PMD.**
+
+  The AESNI MB PMD has been updated with additional support for:
+
+  * 12-byte IV on AES Counter Mode, apart from the previous 16-byte IV.
+
 
 Resolved Issues
 ---
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
index d1bc28e..82630be 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
@@ -220,9 +220,9 @@ static const struct rte_cryptodev_capabilities 
aesni_mb_pmd_capabilities[] = {
.increment = 8
},
.iv_size = {
-   .min = 16,
+   .min = 12,
.max = 16,
-   .increment = 0
+   .increment = 4
}
}, }
}, }
-- 
2.9.4



Re: [dpdk-dev] [dpdk-stable] [PATCH] app/crypto-perf: fix digest data for chained mbufs

2017-07-02 Thread De Lara Guarch, Pablo


> -Original Message-
> From: stable [mailto:stable-boun...@dpdk.org] On Behalf Of Trahe, Fiona
> Sent: Friday, June 30, 2017 5:35 PM
> To: Gonzalez Monroy, Sergio ;
> dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] app/crypto-perf: fix digest
> data for chained mbufs
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Sergio Gonzalez
> Monroy
> > Sent: Friday, June 30, 2017 8:56 AM
> > To: dev@dpdk.org; sta...@dpdk.org
> > Subject: [dpdk-dev] [PATCH] app/crypto-perf: fix digest data for chained
> mbufs
> >
> > Use corect mbuf segment for chained mbufs.
> >
> > Fixes: f8be1786b1b8 ("app/crypto-perf: introduce performance test
> application")
> > CC: sta...@dpdk.org
> >
> > Signed-off-by: Sergio Gonzalez Monroy
> 
> Acked-by: Fiona Trahe 

Applied to dpdk-next-crypto.
Thanks,

Pablo


Re: [dpdk-dev] [PATCH] app/crypto-perf: use rte_mempool_put_bulk

2017-07-02 Thread De Lara Guarch, Pablo


> -Original Message-
> From: Trahe, Fiona
> Sent: Friday, June 30, 2017 5:13 PM
> To: Gonzalez Monroy, Sergio ;
> dev@dpdk.org
> Cc: De Lara Guarch, Pablo 
> Subject: RE: [dpdk-dev] [PATCH] app/crypto-perf: use
> rte_mempool_put_bulk
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Sergio Gonzalez
> > Monroy
> > Sent: Friday, June 30, 2017 8:57 AM
> > To: dev@dpdk.org
> > Cc: De Lara Guarch, Pablo 
> > Subject: [dpdk-dev] [PATCH] app/crypto-perf: use rte_mempool_put_bulk
> >
> > Use rte_mempool_put_bulk for both latency and throughput tests
> instead
> > of rte_crypto_op_free to improve application performance.
> >
> > Signed-off-by: Sergio Gonzalez Monroy
> > 
> > ---
> Acked-by: Fiona Trahe 

Applied to dpdk-next-crypto.
Thanks,

Pablo


[dpdk-dev] [PATCH] doc: add knowing issue for i40e VF performance

2017-07-02 Thread Qi Zhang
VF performance is limited by some kernel PCI setting.
Update the document to explain the knowing issue and
work around solution.

Signed-off-by: Qi Zhang 
---
 doc/guides/nics/i40e.rst | 24 
 1 file changed, 24 insertions(+)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 4d3c7ca..557d83d 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -447,3 +447,27 @@ It means if APP has set the max bandwidth for that TC, it 
comes to no
 effect.
 It's suggested to set the strict priority mode for a TC that is latency
 sensitive but no consuming much bandwidth.
+
+VF performance is impacted by PCI extended tag setting
+~~
+
+To reach maximum NIC performance. PCI extended tag is required to be enabled.
+DPDK I40E PF drvier will set this feature during initialization, but Kernel PF
+driver does not. So when running traffic on a VF which is  managed by kernel
+PF driver, we saw significent NIC performance downgrade (for 64 bytes packet,
+there is about 25% linerate downgrade for 25G device and about 35% for 40G
+device).
+
+Solution:
+
+For kernel version >= 4.11, kernel's PCI driver will enale extended tag if it
+detects that device support extended tag. So by default, this is not an issue.
+When extended tag is be disabled by occasionally, to re-enable it, see below.
+
+For kernel version < 4.11, use setpci command to enable PCI extended flag
+1) get current value of PCI configure register
+setpci -s  a8.w
+2) set bit 8
+value = value | 0x100
+3) set PCI configure register with new value.
+setpci -s  a8.w=
-- 
2.9.3



Re: [dpdk-dev] [PATCH] app/crypto-perf: set crypto op pool cache

2017-07-02 Thread De Lara Guarch, Pablo


> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Trahe, Fiona
> Sent: Friday, June 30, 2017 5:36 PM
> To: Gonzalez Monroy, Sergio ;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] app/crypto-perf: set crypto op pool cache
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Sergio Gonzalez
> Monroy
> > Sent: Friday, June 30, 2017 8:56 AM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH] app/crypto-perf: set crypto op pool cache
> >
> > Signed-off-by: Sergio Gonzalez Monroy
> 
> Acked by: Fiona Trahe 

Applied to dpdk-next-crypto.
Thanks,

Pablo



Re: [dpdk-dev] [PATCH v5 3/3] doc: add eventdev library to programmers guide

2017-07-02 Thread Jerin Jacob
-Original Message-
> Date: Fri, 30 Jun 2017 14:51:13 +0100
> From: David Hunt 
> To: dev@dpdk.org
> CC: jerin.ja...@caviumnetworks.com, harry.van.haa...@intel.com
> Subject: [PATCH v5 3/3] doc: add eventdev library to programmers guide
> X-Mailer: git-send-email 2.7.4
> 
> From: Harry van Haaren 
> 
> This commit adds an entry in the programmers guide
> explaining the eventdev library.
> 
> The rte_event struct, queues and ports are explained.
> An API walktrough of a simple two stage atomic pipeline
> provides the reader with a step by step overview of the
> expected usage of the Eventdev API.
> 
> Signed-off-by: Harry van Haaren 

Thanks for document. Overall it looks good. A few comments below.

> ---

Snip

> + The eventdev framework is provided as a DPDK library, allowing
> +applications to use it if they wish, but not require its usage.
> +
> +The goal of this library is to enable applications to build processing
> +pipelines where the load balancing and scheduling is handled by the eventdev.

Adding the differences between polling and event driver model will be
useful. I propose to change the above two paragraphs and add more
detailed text for the  use case. Something like below,

--Start
The eventdev framework introduces the event driven programming model.

In a polling model, lcores poll ethdev ports and associated Rx queues
directly to look for a packet. By contrast in an event driven model,
lcores call the scheduler that selects packets for them based on
programmer-specified criteria. The Eventdev library adds support for an
event driven programming model, which offers applications automatic
multicore scaling, dynamic load balancing, pipelining, packet ingress
order maintenance and synchronization services to simplify application
packet processing.

By introducing an event driven programming model, DPDK can support both
polling and event driven programming models for packet processing, and
applications are free to choose whatever model (or combination of the
two) best suits their needs.
---End


> +Step-by-step instructions of the eventdev design is available in the `API
> +Walk-through`_ section later in this document.
> +
> +Event struct
> +
> +
> +The eventdev API represents each event with a generic struct, which contains 
> a
> +payload and metadata required for scheduling by an eventdev.  The
> +``rte_event`` struct is a 16 byte C structure, defined in
> +``libs/librte_eventdev/rte_eventdev.h``.
> +

Snip

> +Event Payload
> +~
> +
> +The rte_event struct contains a union for payload, allowing flexibility in 
> what
> +the actual event being scheduled is. The payload is a union of the following:
> +
> +* ``uint64_t u64``
> +* ``void *event_ptr``
> +* ``struct rte_mbuf *mbuf``
> +
> +These three items in a union occupy the same 64 bits at the end of the 
> rte_event
> +structure. The application can utilize the 64 bits directly by accessing the
> +u64 variable, while the event_ptr and mbuf are provided as convenience
> +variables.  For example the mbuf pointer in the union can used to schedule a
> +DPDK packet.
> +
> +Queues
> +~~
> +
> +A queue is a logical "stage" of a packet processing graph, where each stage
> +has a specified scheduling type.  The application configures each queue for a
> +specific type of scheduling, and just enqueues all events to the eventdev.
> +The Eventdev API supports the following scheduling types per queue:

IMO, The above definition fits nicely if the queue is NOT with
RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES.

I think, We can take the queue definition from header file.
http://dpdk.org/browse/next/dpdk-next-eventdev/tree/lib/librte_eventdev/rte_eventdev.h#n113

and tell about the RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES and non
RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES capability queues here.


> +
> +*   Atomic
> +*   Ordered
> +*   Parallel
> +
> +Atomic, Ordered and Parallel are load-balanced scheduling types: the output
> +of the queue can be spread out over multiple CPU cores.
> +
> +Atomic scheduling on a queue ensures that a single flow is not present on two
> +different CPU cores at the same time. Ordered allows sending all flows to any
> +core, but the scheduler must ensure that on egress the packets are returned 
> to

We can emphasize of when reordering happens ie "On downstream queue enqueue"

> +ingress order. Parallel allows sending all flows to all CPU cores, without 
> any
> +re-ordering guarantees.
> +
> +Single Link Flag
> +
> +
> +There is a SINGLE_LINK flag which allows an application to indicate that only
> +one port will be connected to a queue.  Queues configured with the 
> single-link
> +flag follow a FIFO like structure, maintaining ordering but it is only 
> capable
> +of being linked to a single port (see below for port and queue linking 
> details).
> +
> +
> +Ports
> +~
> +
> +Ports are the points of contact between worker cores and the even

[dpdk-dev] [PATCH v6 1/4] app/testpmd: add isolated mode parameter

2017-07-02 Thread Vasily Philipov
Providing this parameter requests flow API isolated mode on all ports at
initialization time. It ensures all traffic is received through the
configured flow rules only (see flow command).

Ports that do not support this mode are automatically discarded.

Signed-off-by: Vasily Philipov 
---
 app/test-pmd/parameters.c |  3 +++
 app/test-pmd/testpmd.c| 14 ++
 app/test-pmd/testpmd.h|  1 +
 3 files changed, 18 insertions(+)

diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index fbe6284..e313871 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -623,6 +623,7 @@
{ "tx-queue-stats-mapping", 1, 0, 0 },
{ "rx-queue-stats-mapping", 1, 0, 0 },
{ "no-flush-rx",0, 0, 0 },
+   { "isolated-mode",  0, 0, 0 },
{ "txpkts", 1, 0, 0 },
{ "disable-link-check", 0, 0, 0 },
{ "no-lsc-interrupt",   0, 0, 0 },
@@ -1081,6 +1082,8 @@
lsc_interrupt = 0;
if (!strcmp(lgopts[opt_idx].name, "no-rmv-interrupt"))
rmv_interrupt = 0;
+   if (!strcmp(lgopts[opt_idx].name, "isolated-mode"))
+   isolated_mode = 1;
if (!strcmp(lgopts[opt_idx].name, "print-event"))
if (parse_event_printing_config(optarg, 1)) {
rte_exit(EXIT_FAILURE,
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index b3ad83b..864a2a8 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -270,6 +270,11 @@ struct fwd_engine * fwd_engines[] = {
 uint8_t no_flush_rx = 0; /* flush by default */
 
 /*
+ * Flow API isolated mode.
+ */
+uint8_t isolated_mode;
+
+/*
  * Avoids to check link status when starting/stopping a port.
  */
 uint8_t no_link_check = 0; /* check by default */
@@ -1425,6 +1430,15 @@ static int eth_event_callback(uint8_t port_id,
if (port->need_reconfig > 0) {
port->need_reconfig = 0;
 
+   if (isolated_mode) {
+   int ret = port_flow_isolate(pi, 1);
+   if (ret) {
+   printf("Failed to apply isolated"
+  " mode on port %d\n", pi);
+   return -1;
+   }
+   }
+
printf("Configuring Port %d (socket %u)\n", pi,
port->socket_id);
/* configure port */
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 364502d..d5fc9ad 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -303,6 +303,7 @@ struct queue_stats_mappings {
 extern uint8_t  numa_support; /**< set by "--numa" parameter */
 extern uint16_t port_topology; /**< set by "--port-topology" parameter */
 extern uint8_t no_flush_rx; /**

[dpdk-dev] [PATCH v6 2/4] net/mlx4: refactor RSS parent queue allocation

2017-07-02 Thread Vasily Philipov
A special "parent" queue must be allocated in addition to a group of
standard Rx queues for RSS to work. This is done automatically outside of
isolated mode by the PMD when applications request several Rx queues.

Since each configured flow rule with the RSS action may target a different
set of queues, the PMD must have the ability to dynamically allocate
several parent queues, one per RSS group.

Refactor RSS parent queue allocations (currently limited to a single
parent) in preparation for flow API RSS action support.

Signed-off-by: Vasily Philipov 
---
 drivers/net/mlx4/mlx4.c | 374 +---
 drivers/net/mlx4/mlx4.h |  17 ++-
 2 files changed, 271 insertions(+), 120 deletions(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 16cafae..96f88c6 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -552,13 +552,91 @@ void priv_unlock(struct priv *priv)
 
 static int
 rxq_setup(struct rte_eth_dev *dev, struct rxq *rxq, uint16_t desc,
- unsigned int socket, int inactive, const struct rte_eth_rxconf *conf,
- struct rte_mempool *mp);
+ unsigned int socket, int inactive,
+ const struct rte_eth_rxconf *conf,
+ struct rte_mempool *mp, int children_n,
+ struct rxq *rxq_parent);
 
 static void
 rxq_cleanup(struct rxq *rxq);
 
 /**
+ * Create RSS parent queue.
+ *
+ * The new parent is inserted in front of the list in the private structure.
+ *
+ * @param priv
+ *   Pointer to private structure.
+ * @param queues
+ *   Queues indices array, if NULL use all Rx queues.
+ * @param children_n
+ *   The number of entries in queues[].
+ *
+ * @return
+ *   0 on success, negative errno value on failure.
+ */
+static int
+priv_parent_create(struct priv *priv,
+  uint16_t queues[],
+  uint16_t children_n)
+{
+   int ret;
+   uint16_t i;
+   struct rxq *parent;
+
+   parent = rte_zmalloc("parent queue",
+sizeof(*parent),
+RTE_CACHE_LINE_SIZE);
+   if (!parent)
+   return -ENOMEM;
+   ret = rxq_setup(priv->dev, parent, 0, 0, 0,
+   NULL, NULL, children_n, NULL);
+   if (ret) {
+   rte_free(parent);
+   return -ret;
+   }
+   parent->rss.queues_n = children_n;
+   if (queues) {
+   for (i = 0; i < children_n; ++i)
+   parent->rss.queues[i] = queues[i];
+   } else {
+   /* the default RSS ring case */
+   assert(priv->rxqs_n == children_n);
+   for (i = 0; i < priv->rxqs_n; ++i)
+   parent->rss.queues[i] = i;
+   }
+   LIST_INSERT_HEAD(&priv->parents, parent, next);
+   return 0;
+}
+
+/**
+ * Clean up RX queue parent structure.
+ *
+ * @param parent
+ *   RX queue parent structure.
+ */
+void
+rxq_parent_cleanup(struct rxq *parent)
+{
+   LIST_REMOVE(parent, next);
+   rxq_cleanup(parent);
+   rte_free(parent);
+}
+
+/**
+ * Clean up parent structures from the parent list.
+ *
+ * @param priv
+ *   Pointer to private structure.
+ */
+static void
+priv_parent_list_cleanup(struct priv *priv)
+{
+   while (!LIST_EMPTY(&priv->parents))
+   rxq_parent_cleanup(LIST_FIRST(&priv->parents));
+}
+
+/**
  * Ethernet device configuration.
  *
  * Prepare the driver for a given number of TX and RX queues.
@@ -607,7 +685,7 @@ void priv_unlock(struct priv *priv)
for (i = 0; (i != priv->rxqs_n); ++i)
if ((*priv->rxqs)[i] != NULL)
return EINVAL;
-   rxq_cleanup(&priv->rxq_parent);
+   priv_parent_list_cleanup(priv);
priv->rss = 0;
priv->rxqs_n = 0;
}
@@ -632,7 +710,7 @@ void priv_unlock(struct priv *priv)
priv->rss = 1;
tmp = priv->rxqs_n;
priv->rxqs_n = rxqs_n;
-   ret = rxq_setup(dev, &priv->rxq_parent, 0, 0, 0, NULL, NULL);
+   ret = priv_parent_create(priv, NULL, priv->rxqs_n);
if (!ret)
return 0;
/* Failure, rollback. */
@@ -2522,7 +2600,7 @@ struct txq_mp2mr_mbuf_check_data {
if (!BITFIELD_ISSET(priv->mac_configured, mac_index))
return;
if (priv->rss) {
-   rxq_mac_addr_del(&priv->rxq_parent, mac_index);
+   rxq_mac_addr_del(LIST_FIRST(&priv->parents), mac_index);
goto end;
}
for (i = 0; (i != priv->dev->data->nb_rx_queues); ++i)
@@ -2589,7 +2667,7 @@ struct txq_mp2mr_mbuf_check_data {
goto end;
}
if (priv->rss) {
-   ret = rxq_mac_addr_add(&priv->rxq_parent, mac_index);
+   ret = rxq_mac_addr_add(LIST_FIRST(&priv->parents), mac_index);
if (ret)
return ret;
goto end;
@@ -2771,8 +2849,9 @@ struct txq_mp2mr_mbuf_c

[dpdk-dev] [PATCH v6 3/4] net/mlx4: implement isolated mode from flow API

2017-07-02 Thread Vasily Philipov
The user must request isolated mode before device configuration,
the default RSS ring isn't created in this case.

Signed-off-by: Vasily Philipov 
---
 drivers/net/mlx4/mlx4.c  | 58 +++-
 drivers/net/mlx4/mlx4.h  |  1 +
 drivers/net/mlx4/mlx4_flow.c | 37 
 drivers/net/mlx4/mlx4_flow.h |  5 
 4 files changed, 90 insertions(+), 11 deletions(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 96f88c6..afad2be 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -666,7 +666,7 @@ void priv_unlock(struct priv *priv)
}
if (rxqs_n == priv->rxqs_n)
return 0;
-   if (!rte_is_power_of_2(rxqs_n)) {
+   if (!rte_is_power_of_2(rxqs_n) && !priv->isolated) {
unsigned n_active;
 
n_active = rte_align32pow2(rxqs_n + 1) >> 1;
@@ -710,6 +710,8 @@ void priv_unlock(struct priv *priv)
priv->rss = 1;
tmp = priv->rxqs_n;
priv->rxqs_n = rxqs_n;
+   if (priv->isolated)
+   return 0;
ret = priv_parent_create(priv, NULL, priv->rxqs_n);
if (!ret)
return 0;
@@ -2596,6 +2598,7 @@ struct txq_mp2mr_mbuf_check_data {
 {
unsigned int i;
 
+   assert(!priv->isolated);
assert(mac_index < elemof(priv->mac));
if (!BITFIELD_ISSET(priv->mac_configured, mac_index))
return;
@@ -2845,7 +2848,7 @@ struct txq_mp2mr_mbuf_check_data {
rxq->if_cq,
¶ms));
}
-   if (rxq->qp != NULL) {
+   if (rxq->qp != NULL && !rxq->priv->isolated) {
rxq_promiscuous_disable(rxq);
rxq_allmulticast_disable(rxq);
rxq_mac_addrs_del(rxq);
@@ -3548,7 +3551,7 @@ struct txq_mp2mr_mbuf_check_data {
return 0;
}
/* Remove attached flows if RSS is disabled (no parent queue). */
-   if (!priv->rss) {
+   if (!priv->rss && !priv->isolated) {
rxq_allmulticast_disable(&tmpl);
rxq_promiscuous_disable(&tmpl);
rxq_mac_addrs_del(&tmpl);
@@ -3593,7 +3596,7 @@ struct txq_mp2mr_mbuf_check_data {
return err;
}
/* Reconfigure flows. Do not care for errors. */
-   if (!priv->rss) {
+   if (!priv->rss && !priv->isolated) {
rxq_mac_addrs_add(&tmpl);
if (priv->promisc)
rxq_promiscuous_enable(&tmpl);
@@ -3752,7 +3755,7 @@ struct txq_mp2mr_mbuf_check_data {
  strerror(ret));
return ret;
}
-   if (parent || !priv->rss) {
+   if (!priv->isolated && (parent || !priv->rss)) {
/* Configure MAC and broadcast addresses. */
ret = rxq_mac_addrs_add(rxq);
if (ret) {
@@ -4042,7 +4045,7 @@ struct txq_mp2mr_mbuf_check_data {
return -ENOMEM;
}
}
-   if (priv->rss) {
+   if (priv->rss && !priv->isolated) {
/* The list consists of the single default one. */
parent = LIST_FIRST(&priv->parents);
if (idx >= rte_align32pow2(priv->rxqs_n + 1) >> 1)
@@ -4138,7 +4141,10 @@ struct txq_mp2mr_mbuf_check_data {
}
DEBUG("%p: attaching configured flows to all RX queues", (void *)dev);
priv->started = 1;
-   if (priv->rss) {
+   if (priv->isolated) {
+   rxq = NULL;
+   r = 1;
+   } else if (priv->rss) {
rxq = LIST_FIRST(&priv->parents);
r = 1;
} else {
@@ -4226,7 +4232,10 @@ struct txq_mp2mr_mbuf_check_data {
}
DEBUG("%p: detaching flows from all RX queues", (void *)dev);
priv->started = 0;
-   if (priv->rss) {
+   if (priv->isolated) {
+   rxq = NULL;
+   r = 1;
+   } else if (priv->rss) {
rxq = LIST_FIRST(&priv->parents);
r = 1;
} else {
@@ -4658,6 +4667,8 @@ struct txq_mp2mr_mbuf_check_data {
if (mlx4_is_secondary())
return;
priv_lock(priv);
+   if (priv->isolated)
+   goto end;
DEBUG("%p: removing MAC address from index %" PRIu32,
  (void *)dev, index);
/* Last array entry is reserved for broadcast. */
@@ -4691,6 +4702,12 @@ struct txq_mp2mr_mbuf_check_data {
return -ENOTSUP;
(void)vmdq;
priv_lock(priv);
+   if (priv->isolated) {
+   DEBUG("%p: cannot add MAC address, "
+ "device is in isolated mode", (void *)dev);
+   re = EPERM;
+   goto end;
+   }
DEBUG("%p: adding MAC address at index %" PRIu32,
  (void *)dev, index);
/* Last array entry is reserved for broadcast. */
@@ -4738,6 +4755,12 @@ stru

[dpdk-dev] [PATCH v6 4/4] net/mlx4: support flow API RSS action

2017-07-02 Thread Vasily Philipov
This commit adds support for the flow API RSS action with the following
limitations:

 - Only supported when isolated mode is enabled.
 - The number of queues specified by the action (rte_flow_action_rss.num)
   must be a power of two.
 - Each queue index can be specified at most once in the configuration
   (rte_flow_action_rss.queue[]).
 - Because a queue can be associated with a single RSS context, it cannot
   be targeted by multiple RSS actions simultaneously.

Signed-off-by: Vasily Philipov 
---
 drivers/net/mlx4/mlx4.c  |  21 +++--
 drivers/net/mlx4/mlx4.h  |   5 ++
 drivers/net/mlx4/mlx4_flow.c | 197 ++-
 drivers/net/mlx4/mlx4_flow.h |   3 +-
 4 files changed, 211 insertions(+), 15 deletions(-)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index afad2be..bbc1ba4 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -573,9 +573,9 @@ void priv_unlock(struct priv *priv)
  *   The number of entries in queues[].
  *
  * @return
- *   0 on success, negative errno value on failure.
+ *   Pointer to a parent rxq structure, NULL on failure.
  */
-static int
+struct rxq *
 priv_parent_create(struct priv *priv,
   uint16_t queues[],
   uint16_t children_n)
@@ -587,13 +587,15 @@ void priv_unlock(struct priv *priv)
parent = rte_zmalloc("parent queue",
 sizeof(*parent),
 RTE_CACHE_LINE_SIZE);
-   if (!parent)
-   return -ENOMEM;
+   if (!parent) {
+   ERROR("cannot allocate memory for RSS parent queue");
+   return NULL;
+   }
ret = rxq_setup(priv->dev, parent, 0, 0, 0,
NULL, NULL, children_n, NULL);
if (ret) {
rte_free(parent);
-   return -ret;
+   return NULL;
}
parent->rss.queues_n = children_n;
if (queues) {
@@ -606,7 +608,7 @@ void priv_unlock(struct priv *priv)
parent->rss.queues[i] = i;
}
LIST_INSERT_HEAD(&priv->parents, parent, next);
-   return 0;
+   return parent;
 }
 
 /**
@@ -655,7 +657,6 @@ void priv_unlock(struct priv *priv)
unsigned int rxqs_n = dev->data->nb_rx_queues;
unsigned int txqs_n = dev->data->nb_tx_queues;
unsigned int tmp;
-   int ret;
 
priv->rxqs = (void *)dev->data->rx_queues;
priv->txqs = (void *)dev->data->tx_queues;
@@ -712,14 +713,12 @@ void priv_unlock(struct priv *priv)
priv->rxqs_n = rxqs_n;
if (priv->isolated)
return 0;
-   ret = priv_parent_create(priv, NULL, priv->rxqs_n);
-   if (!ret)
+   if (priv_parent_create(priv, NULL, priv->rxqs_n))
return 0;
/* Failure, rollback. */
priv->rss = 0;
priv->rxqs_n = tmp;
-   assert(ret > 0);
-   return ret;
+   return ENOMEM;
 }
 
 /**
diff --git a/drivers/net/mlx4/mlx4.h b/drivers/net/mlx4/mlx4.h
index 6de3484..716fd45 100644
--- a/drivers/net/mlx4/mlx4.h
+++ b/drivers/net/mlx4/mlx4.h
@@ -371,4 +371,9 @@ struct priv {
 void
 rxq_parent_cleanup(struct rxq *parent);
 
+struct rxq *
+priv_parent_create(struct priv *priv,
+  uint16_t queues[],
+  uint16_t children_n);
+
 #endif /* RTE_PMD_MLX4_H_ */
diff --git a/drivers/net/mlx4/mlx4_flow.c b/drivers/net/mlx4/mlx4_flow.c
index 5ad50bd..8ade106 100644
--- a/drivers/net/mlx4/mlx4_flow.c
+++ b/drivers/net/mlx4/mlx4_flow.c
@@ -112,6 +112,7 @@ struct rte_flow_drop {
 static const enum rte_flow_action_type valid_actions[] = {
RTE_FLOW_ACTION_TYPE_DROP,
RTE_FLOW_ACTION_TYPE_QUEUE,
+   RTE_FLOW_ACTION_TYPE_RSS,
RTE_FLOW_ACTION_TYPE_END,
 };
 
@@ -672,6 +673,76 @@ struct rte_flow_drop {
if (!queue || (queue->index > (priv->rxqs_n - 1)))
goto exit_action_not_supported;
action.queue = 1;
+   action.queues_n = 1;
+   action.queues[0] = queue->index;
+   } else if (actions->type == RTE_FLOW_ACTION_TYPE_RSS) {
+   int i;
+   int ierr;
+   const struct rte_flow_action_rss *rss =
+   (const struct rte_flow_action_rss *)
+   actions->conf;
+
+   if (!priv->hw_rss) {
+   rte_flow_error_set(error, ENOTSUP,
+  RTE_FLOW_ERROR_TYPE_ACTION,
+  actions,
+  "RSS cannot be used with "
+  "the current configuration");
+   return -rte_errno;
+   }
+   if (!priv->isolated) {
+   rte_flow_error_set(error, ENOT

[dpdk-dev] [PATCH v4 01/26] cryptodev: move session type to generic crypto op

2017-07-02 Thread Pablo de Lara
Session type (operation with or without session) is not
something specific to symmetric operations.
Therefore, the variable is moved to the generic crypto operation
structure.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 doc/guides/prog_guide/cryptodev_lib.rst | 21 ++---
 doc/guides/rel_notes/release_17_08.rst  |  8 
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c| 15 ---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c  |  4 ++--
 drivers/crypto/armv8/rte_armv8_pmd.c|  4 ++--
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c |  2 +-
 drivers/crypto/kasumi/rte_kasumi_pmd.c  |  6 +++---
 drivers/crypto/null/null_crypto_pmd.c   | 15 ---
 drivers/crypto/openssl/rte_openssl_pmd.c|  4 ++--
 drivers/crypto/qat/qat_crypto.c |  2 +-
 drivers/crypto/snow3g/rte_snow3g_pmd.c  |  6 +++---
 drivers/crypto/zuc/rte_zuc_pmd.c|  4 ++--
 lib/librte_cryptodev/rte_crypto.h   | 15 +++
 lib/librte_cryptodev/rte_crypto_sym.h   | 16 
 test/test/test_cryptodev.c  |  8 
 15 files changed, 69 insertions(+), 61 deletions(-)

diff --git a/doc/guides/prog_guide/cryptodev_lib.rst 
b/doc/guides/prog_guide/cryptodev_lib.rst
index 4f98f28..229cb7a 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-Copyright(c) 2016 Intel Corporation. All rights reserved.
+Copyright(c) 2016-2017 Intel Corporation. All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
@@ -359,11 +359,12 @@ Crypto operation to be processed on a particular Crypto 
device poll mode driver.
 
 .. figure:: img/crypto_op.*
 
-The operation structure includes the operation type and the operation status,
-a reference to the operation specific data, which can vary in size and content
-depending on the operation being provisioned. It also contains the source
-mempool for the operation, if it allocate from a mempool. Finally an
-opaque pointer for user specific data is provided.
+The operation structure includes the operation type, the operation status
+and the session type (session-based/less), a reference to the operation
+specific data, which can vary in size and content depending on the operation
+being provisioned. It also contains the source mempool for the operation,
+if it allocate from a mempool. Finally an opaque pointer for user specific
+data is provided.
 
 If Crypto operations are allocated from a Crypto operation mempool, see next
 section, there is also the ability to allocate private memory with the
@@ -512,9 +513,9 @@ buffer. It is used for either cipher, authentication, AEAD 
and chained
 operations.
 
 As a minimum the symmetric operation must have a source data buffer 
(``m_src``),
-the session type (session-based/less), a valid session (or transform chain if 
in
-session-less mode) and the minimum authentication/ cipher parameters required
-depending on the type of operation specified in the session or the transform
+a valid session (or transform chain if in session-less mode) and the minimum
+authentication/ cipher parameters required depending on the type of operation
+specified in the session or the transform
 chain.
 
 .. code-block:: c
@@ -523,8 +524,6 @@ chain.
 struct rte_mbuf *m_src;
 struct rte_mbuf *m_dst;
 
-enum rte_crypto_sym_op_sess_type type;
-
 union {
 struct rte_cryptodev_sym_session *session;
 /**< Handle for the initialised session context */
diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index 842f46f..2bc405d 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -144,6 +144,14 @@ API Changes
Also, make sure to start the actual text at the margin.
=
 
+* **Reworked rte_cryptodev library.**
+
+  The rte_cryptodev library has been reworked and updated. The following 
changes
+  have been made to it:
+
+  * Removed the field ``rte_crypto_sym_op_sess_type`` from 
``rte_crypto_sym_op``,
+and moved it to ``rte_crypto_op`` as ``rte_crypto_op_sess_type``.
+
 
 ABI Changes
 ---
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 1b95c23..a0154ff 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -139,16 +139,17 @@ aesni_gcm_set_session_parameters(struct aesni_gcm_session 
*sess,
 
 /** Get gcm session */
 static struct aesni_gcm_session *
-aesni_gcm_get_session(struct aesni_gcm_qp *qp, struct rte_crypto_sym_op *op)
+aesni_gcm_get_session(struct aesni_gcm_qp *qp, struct rte_crypto_op *op)
 {
struct aesni_gcm_session *sess = NULL;
+  

[dpdk-dev] [PATCH v4 03/26] cryptodev: remove opaque data pointer in crypto op

2017-07-02 Thread Pablo de Lara
Storing a pointer to the user data is unnecessary,
since user can store additional data, after the crypto operation.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_test_latency.c | 47 ---
 doc/guides/prog_guide/cryptodev_lib.rst   |  3 +-
 doc/guides/rel_notes/release_17_08.rst|  1 +
 lib/librte_cryptodev/rte_crypto.h |  5 
 4 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/app/test-crypto-perf/cperf_test_latency.c 
b/app/test-crypto-perf/cperf_test_latency.c
index 4fb7a9a..32cf5fd 100644
--- a/app/test-crypto-perf/cperf_test_latency.c
+++ b/app/test-crypto-perf/cperf_test_latency.c
@@ -66,6 +66,10 @@ struct cperf_latency_ctx {
struct cperf_op_result *res;
 };
 
+struct priv_op_data {
+   struct cperf_op_result *result;
+};
+
 #define max(a, b) (a > b ? (uint64_t)a : (uint64_t)b)
 #define min(a, b) (a < b ? (uint64_t)a : (uint64_t)b)
 
@@ -276,9 +280,11 @@ cperf_latency_test_constructor(uint8_t dev_id, uint16_t 
qp_id,
snprintf(pool_name, sizeof(pool_name), "cperf_op_pool_cdev_%d",
dev_id);
 
+   uint16_t priv_size = sizeof(struct priv_op_data);
ctx->crypto_op_pool = rte_crypto_op_pool_create(pool_name,
-   RTE_CRYPTO_OP_TYPE_SYMMETRIC, options->pool_sz, 512, 0,
-   rte_socket_id());
+   RTE_CRYPTO_OP_TYPE_SYMMETRIC, options->pool_sz,
+   512, priv_size, rte_socket_id());
+
if (ctx->crypto_op_pool == NULL)
goto err;
 
@@ -295,11 +301,20 @@ cperf_latency_test_constructor(uint8_t dev_id, uint16_t 
qp_id,
return NULL;
 }
 
+static inline void
+store_timestamp(struct rte_crypto_op *op, uint64_t timestamp)
+{
+   struct priv_op_data *priv_data;
+
+   priv_data = (struct priv_op_data *) (op->sym + 1);
+   priv_data->result->status = op->status;
+   priv_data->result->tsc_end = timestamp;
+}
+
 int
 cperf_latency_test_runner(void *arg)
 {
struct cperf_latency_ctx *ctx = arg;
-   struct cperf_op_result *pres;
uint16_t test_burst_size;
uint8_t burst_size_idx = 0;
 
@@ -311,6 +326,7 @@ cperf_latency_test_runner(void *arg)
struct rte_crypto_op *ops[ctx->options->max_burst_size];
struct rte_crypto_op *ops_processed[ctx->options->max_burst_size];
uint64_t i;
+   struct priv_op_data *priv_data;
 
uint32_t lcore = rte_lcore_id();
 
@@ -400,7 +416,12 @@ cperf_latency_test_runner(void *arg)
 
for (i = 0; i < ops_enqd; i++) {
ctx->res[tsc_idx].tsc_start = tsc_start;
-   ops[i]->opaque_data = (void 
*)&ctx->res[tsc_idx];
+   /*
+* Private data structure starts after the end 
of the
+* rte_crypto_sym_op structure.
+*/
+   priv_data = (struct priv_op_data *) 
(ops[i]->sym + 1);
+   priv_data->result = (void *)&ctx->res[tsc_idx];
tsc_idx++;
}
 
@@ -411,12 +432,9 @@ cperf_latency_test_runner(void *arg)
 * the crypto operation will change the data 
and cause
 * failures.
 */
-   for (i = 0; i < ops_deqd; i++) {
-   pres = (struct cperf_op_result *)
-   
(ops_processed[i]->opaque_data);
-   pres->status = ops_processed[i]->status;
-   pres->tsc_end = tsc_end;
-   }
+   for (i = 0; i < ops_deqd; i++)
+   store_timestamp(ops_processed[i], 
tsc_end);
+
rte_mempool_put_bulk(ctx->crypto_op_pool,
(void **)ops_processed, 
ops_deqd);
 
@@ -447,12 +465,9 @@ cperf_latency_test_runner(void *arg)
tsc_end = rte_rdtsc_precise();
 
if (ops_deqd != 0) {
-   for (i = 0; i < ops_deqd; i++) {
-   pres = (struct cperf_op_result *)
-   
(ops_processed[i]->opaque_data);
-   pres->status = ops_processed[i]->status;
-   pres->tsc_end = tsc_end;
-   }
+   for (i = 0; i < ops_deqd; i++)
+   store_timestamp(ops_processed[i], 
tsc_end);
+
rte_mempool_put_bulk(ctx->crypto_op_pool,
  

[dpdk-dev] [PATCH v4 02/26] cryptodev: replace enums with 1-byte variables

2017-07-02 Thread Pablo de Lara
Instead of storing some crypto operation flags,
such as operation status, as enumerations,
store them as uint8_t, for memory efficiency.

Also, reserve extra 5 bytes in the crypto operation,
for future additions.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 doc/guides/rel_notes/release_17_08.rst | 3 +++
 lib/librte_cryptodev/rte_crypto.h  | 9 +
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index 2bc405d..bbb14a9 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -151,6 +151,9 @@ API Changes
 
   * Removed the field ``rte_crypto_sym_op_sess_type`` from 
``rte_crypto_sym_op``,
 and moved it to ``rte_crypto_op`` as ``rte_crypto_op_sess_type``.
+  * Enumerations ``rte_crypto_op_sess_type``, ``rte_crypto_op_status`` and
+``rte_crypto_op_sess_type`` in ``rte_crypto_op`` have been modified to be
+uint8_t values.
 
 
 ABI Changes
diff --git a/lib/librte_cryptodev/rte_crypto.h 
b/lib/librte_cryptodev/rte_crypto.h
index ac5c184..8e2b640 100644
--- a/lib/librte_cryptodev/rte_crypto.h
+++ b/lib/librte_cryptodev/rte_crypto.h
@@ -102,19 +102,20 @@ enum rte_crypto_op_sess_type {
  * rte_cryptodev_enqueue_burst() / rte_cryptodev_dequeue_burst() .
  */
 struct rte_crypto_op {
-   enum rte_crypto_op_type type;
+   uint8_t type;
/**< operation type */
-
-   enum rte_crypto_op_status status;
+   uint8_t status;
/**<
 * operation status - this is reset to
 * RTE_CRYPTO_OP_STATUS_NOT_PROCESSED on allocation from mempool and
 * will be set to RTE_CRYPTO_OP_STATUS_SUCCESS after crypto operation
 * is successfully processed by a crypto PMD
 */
-   enum rte_crypto_op_sess_type  sess_type;
+   uint8_t sess_type;
/**< operation session type */
 
+   uint8_t reserved[5];
+   /**< Reserved bytes to fill 64 bits for future additions */
struct rte_mempool *mempool;
/**< crypto operation mempool which operation is allocated from */
 
-- 
2.9.4



[dpdk-dev] [PATCH v4 00/26] Crypto operation restructuring

2017-07-02 Thread Pablo de Lara
This patchset attempts to correct and improve the current crypto operation
(rte_crypto_op) and symmetric crypto operation (rte_crypto_sym_op) structures,
shrinking their sizes to fit both structures into two 64-byte cache lines
(with extra space for the IV and other user data) as one of the goals.

It also introduces new AEAD algorithm specific parameters, to simplify its setup
with a single transform, instead of a concatenation of a cipher and an 
authentication transform.

The following changes are made:

In rte_crypto_op:

- Moved session type (with session/sessionless) from symmetric op to crypto op,
  as this could be used for other types

- Combined operation type, operation status and session type into a 64-bit flag
  (each one taking 1 byte), instead of having enums taking 4 bytes each

- Removed opaque data from crypto operation, as private data can be allocated
  just after the symmetric (or other type) crypto operation

- Modified symmetric operation pointer to zero-array, as the symmetric op
  should be always after the crypto operation

- Removed unnecessary cache alignment

In rte_crypto_sym_xform:

- Added IV length and offset in sym_xform, so these will be fixed for all the 
operations in a session

- Added a new AEAD transform

- Added IV for authentication and AEAD transforms

- Removed AAD length from authentication transform, as it is only used for AEAD 
algorithms

In rte_crypto_sym_op:

- Removed IV parameters, which will be only in the session.

- Added AEAD specific parameters.

- Create union with the new AEAD parameters and the cipher/authentication 
parameters,
  as the three cannot be used at the same time

- Removed digest length from sym crypto op, so this length will be fixed for 
all the operations in a session

- Removed AAD length from sym crypto op, so this length will be fixed for all 
operations in a session

- Removed AAD from authentication structure, as it is only used for AEAD 
algorithms

- Added zero-array at the end of sym crypto op to be used to get extra 
allocated memory (IV + other user data)


In terms of algorithm usage:

- AEAD algorithms (like AES-GCM) are set up only using the AEAD structure

- AES GMAC will be an authentication only algorithm, using the source buffer 
directly, instead of AAD field

- Wireless algorithms (like SNOW3G) do not use AAD field for authentication IV 
anymore, as this is available now.


Finally, a comparison between the previous operation and the new operation:

Previous rte_crypto_op (40 bytes) and rte_crypto_sym_op (114 bytes) structures:

struct rte_crypto_op {
enum rte_crypto_op_type type;
enum rte_crypto_op_status status;
struct rte_mempool *mempool;
phys_addr_t phys_addr;
void *opaque_data;
union {
   struct rte_crypto_sym_op *sym;
};
} __rte_cache_aligned;

struct rte_crypto_sym_op {
struct rte_mbuf *m_src;
struct rte_mbuf *m_dst;

enum rte_crypto_sym_op_sess_type sess_type;

RTE_STD_C11
union {
   struct rte_cryptodev_sym_session *session;
   struct rte_crypto_sym_xform *xform;
};

struct {
struct {
uint32_t offset;
uint32_t length;
} data;

struct {
uint8_t *data;
phys_addr_t phys_addr;
uint16_t length;
} iv;
} cipher;

struct {
struct {
uint32_t offset;
uint32_t length;
} data;
struct {
uint8_t *data;
phys_addr_t phys_addr;
uint16_t length;
} digest; /**< Digest parameters */

struct {
uint8_t *data;
phys_addr_t phys_addr;
uint16_t length;
} aad;

} auth;
} __rte_cache_aligned;


New rte_crypto_op (24 bytes) and rte_crypto_sym_op (72 bytes) structures:

struct rte_crypto_op {
uint64_t type: 8;
uint64_t status: 8;
uint64_t sess_type: 8;

struct rte_mempool *mempool;

phys_addr_t phys_addr;

RTE_STD_C11
union {
   struct rte_crypto_sym_op sym[0];
};
} __rte_cache_aligned;


struct rte_crypto_sym_op {
struct rte_mbuf *m_src;
struct rte_mbuf *m_dst;

union {
struct rte_cryptodev_sym_session *session;
/**< Handle for the initialised session context */
struct rte_crypto_sym_xform *xform;
/**< Session-less API Crypto operation parameters */
};

union {
struct {
struct {
uint32_t offset;
uint32_t length;
} data; /**< Data offsets and length for AEAD */

struct {
uint8_t *data;
phys_addr_t phys_addr;
} digest; /**< Digest parameters */

struct {
uint8_t *data;
phys_addr_t phys_addr;
} aad;
/**< Additional authentication parameters */
} aead;

struct {
struct {
struct {
uint32_t off

[dpdk-dev] [PATCH v4 05/26] cryptodev: remove useless alignment

2017-07-02 Thread Pablo de Lara
rte_crypto_op and rte_crypto_sym_op structures
were marked as cache aligned.
However, since these structures are always initialized
in a mempool, this alignment is useless, since the mempool
forces the alignment of its objects.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 lib/librte_cryptodev/rte_crypto.h | 2 +-
 lib/librte_cryptodev/rte_crypto_sym.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_cryptodev/rte_crypto.h 
b/lib/librte_cryptodev/rte_crypto.h
index 85716a6..43be7dc 100644
--- a/lib/librte_cryptodev/rte_crypto.h
+++ b/lib/librte_cryptodev/rte_crypto.h
@@ -127,7 +127,7 @@ struct rte_crypto_op {
struct rte_crypto_sym_op sym[0];
/**< Symmetric operation parameters */
}; /**< operation specific parameters */
-} __rte_cache_aligned;
+};
 
 /**
  * Reset the fields of a crypto operation to their default values.
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h 
b/lib/librte_cryptodev/rte_crypto_sym.h
index 386b120..39ad1e3 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -640,7 +640,7 @@ struct rte_crypto_sym_op {
} aad;
/**< Additional authentication parameters */
} auth;
-} __rte_cache_aligned;
+};
 
 
 /**
-- 
2.9.4



[dpdk-dev] [PATCH v4 06/26] cryptodev: add crypto op helper macros

2017-07-02 Thread Pablo de Lara
In order to facilitate the access to the private data,
after the crypto operation, two new macros have been
implemented:

- rte_crypto_op_ctod_offset(c,t,o), which returns a pointer
  to "o" bytes after the start of the crypto operation
  (rte_crypto_op)
- rte_crypto_op_ctophys_offset(c, o), which returns
  the physical address of the data "o" bytes after the
  start of the crypto operation (rte_crypto_op)

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 lib/librte_cryptodev/rte_cryptodev.h | 32 
 1 file changed, 32 insertions(+)

diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index 4e318f0..91f3375 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -119,6 +119,38 @@ extern const char **rte_cyptodev_names;
 #define CDEV_PMD_TRACE(...) (void)0
 #endif
 
+
+
+/**
+ * A macro that points to an offset from the start
+ * of the crypto operation structure (rte_crypto_op)
+ *
+ * The returned pointer is cast to type t.
+ *
+ * @param c
+ *   The crypto operation.
+ * @param o
+ *   The offset from the start of the crypto operation.
+ * @param t
+ *   The type to cast the result into.
+ */
+#define rte_crypto_op_ctod_offset(c, t, o) \
+   ((t)((char *)(c) + (o)))
+
+/**
+ * A macro that returns the physical address that points
+ * to an offset from the start of the crypto operation
+ * (rte_crypto_op)
+ *
+ * @param c
+ *   The crypto operation.
+ * @param o
+ *   The offset from the start of the crypto operation
+ *   to calculate address from.
+ */
+#define rte_crypto_op_ctophys_offset(c, o) \
+   (phys_addr_t)((c)->phys_addr + (o))
+
 /**
  * Crypto parameters range description
  */
-- 
2.9.4



[dpdk-dev] [PATCH v4 04/26] cryptodev: do not store pointer to op specific params

2017-07-02 Thread Pablo de Lara
Instead of storing a pointer to operation specific parameters,
such as symmetric crypto parameters, use a zero-length array,
to mark that these parameters will be stored after the
generic crypto operation structure, which was already assumed
in the code, reducing the memory footprint of the crypto operation.

Besides, it is always expected to have rte_crypto_op
and rte_crypto_sym_op (the only operation specific parameters
structure right now) to be together, as they are initialized
as a single object in the crypto operation pool.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 doc/guides/rel_notes/release_17_08.rst | 2 ++
 examples/ipsec-secgw/ipsec.c   | 1 -
 lib/librte_cryptodev/rte_crypto.h  | 8 +---
 3 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index 20f459e..6acbf35 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -155,6 +155,8 @@ API Changes
 ``rte_crypto_op_sess_type`` in ``rte_crypto_op`` have been modified to be
 uint8_t values.
   * Removed the field ``opaque_data`` from ``rte_crypto_op``.
+  * Pointer to ``rte_crypto_sym_op`` in ``rte_crypto_op`` has been replaced
+with a zero length array.
 
 
 ABI Changes
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index edca5f0..126d79f 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -140,7 +140,6 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx 
*ipsec_ctx,
priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
 
rte_prefetch0(&priv->sym_cop);
-   priv->cop.sym = &priv->sym_cop;
 
if ((unlikely(sa->crypto_session == NULL)) &&
create_session(ipsec_ctx, sa)) {
diff --git a/lib/librte_cryptodev/rte_crypto.h 
b/lib/librte_cryptodev/rte_crypto.h
index c2677fa..85716a6 100644
--- a/lib/librte_cryptodev/rte_crypto.h
+++ b/lib/librte_cryptodev/rte_crypto.h
@@ -124,7 +124,7 @@ struct rte_crypto_op {
 
RTE_STD_C11
union {
-   struct rte_crypto_sym_op *sym;
+   struct rte_crypto_sym_op sym[0];
/**< Symmetric operation parameters */
}; /**< operation specific parameters */
 } __rte_cache_aligned;
@@ -144,12 +144,6 @@ __rte_crypto_op_reset(struct rte_crypto_op *op, enum 
rte_crypto_op_type type)
 
switch (type) {
case RTE_CRYPTO_OP_TYPE_SYMMETRIC:
-   /** Symmetric operation structure starts after the end of the
-* rte_crypto_op structure.
-*/
-   op->sym = (struct rte_crypto_sym_op *)(op + 1);
-   op->type = type;
-
__rte_crypto_sym_op_reset(op->sym);
break;
default:
-- 
2.9.4



[dpdk-dev] [PATCH v4 07/26] test/crypto: move IV to crypto op private data

2017-07-02 Thread Pablo de Lara
Usually, IV will change for each crypto operation.
Therefore, instead of pointing at the same location,
IV is copied after each crypto operation.

This will let the IV to be passed as an offset from
the beginning of the crypto operation, instead of
a pointer.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 test/test/test_cryptodev.c | 386 +
 test/test/test_cryptodev.h |   6 +
 test/test/test_cryptodev_blockcipher.c |  36 +--
 3 files changed, 161 insertions(+), 267 deletions(-)

diff --git a/test/test/test_cryptodev.c b/test/test/test_cryptodev.c
index 04620f3..0037e88 100644
--- a/test/test/test_cryptodev.c
+++ b/test/test/test_cryptodev.c
@@ -202,7 +202,8 @@ testsuite_setup(void)
RTE_CRYPTO_OP_TYPE_SYMMETRIC,
NUM_MBUFS, MBUF_CACHE_SIZE,
DEFAULT_NUM_XFORMS *
-   sizeof(struct rte_crypto_sym_xform),
+   sizeof(struct rte_crypto_sym_xform) +
+   MAXIMUM_IV_LENGTH,
rte_socket_id());
if (ts_params->op_mpool == NULL) {
RTE_LOG(ERR, USER1, "Can't create CRYPTO_OP_POOL\n");
@@ -1306,19 +1307,19 @@ test_AES_CBC_HMAC_SHA1_encrypt_digest(void)
ut_params->ibuf, QUOTE_512_BYTES);
sym_op->auth.digest.length = DIGEST_BYTE_LENGTH_SHA1;
 
-   sym_op->auth.data.offset = CIPHER_IV_LENGTH_AES_CBC;
+   sym_op->auth.data.offset = 0;
sym_op->auth.data.length = QUOTE_512_BYTES;
 
/* Set crypto operation cipher parameters */
-   sym_op->cipher.iv.data = (uint8_t *)rte_pktmbuf_prepend(ut_params->ibuf,
-   CIPHER_IV_LENGTH_AES_CBC);
-   sym_op->cipher.iv.phys_addr = rte_pktmbuf_mtophys(ut_params->ibuf);
+   sym_op->cipher.iv.data = rte_crypto_op_ctod_offset(ut_params->op,
+   uint8_t *, IV_OFFSET);
+   sym_op->cipher.iv.phys_addr = 
rte_crypto_op_ctophys_offset(ut_params->op,
+   IV_OFFSET);
sym_op->cipher.iv.length = CIPHER_IV_LENGTH_AES_CBC;
 
-   rte_memcpy(sym_op->cipher.iv.data, aes_cbc_iv,
-   CIPHER_IV_LENGTH_AES_CBC);
+   rte_memcpy(sym_op->cipher.iv.data, aes_cbc_iv, 
CIPHER_IV_LENGTH_AES_CBC);
 
-   sym_op->cipher.data.offset = CIPHER_IV_LENGTH_AES_CBC;
+   sym_op->cipher.data.offset = 0;
sym_op->cipher.data.length = QUOTE_512_BYTES;
 
/* Process crypto operation */
@@ -1329,8 +1330,8 @@ test_AES_CBC_HMAC_SHA1_encrypt_digest(void)
"crypto op processing failed");
 
/* Validate obuf */
-   uint8_t *ciphertext = rte_pktmbuf_mtod_offset(ut_params->op->sym->m_src,
-   uint8_t *, CIPHER_IV_LENGTH_AES_CBC);
+   uint8_t *ciphertext = rte_pktmbuf_mtod(ut_params->op->sym->m_src,
+   uint8_t *);
 
TEST_ASSERT_BUFFERS_ARE_EQUAL(ciphertext,
catch_22_quote_2_512_bytes_AES_CBC_ciphertext,
@@ -1460,19 +1461,18 @@ test_AES_CBC_HMAC_SHA512_decrypt_perform(struct 
rte_cryptodev_sym_session *sess,
ut_params->ibuf, QUOTE_512_BYTES);
sym_op->auth.digest.length = DIGEST_BYTE_LENGTH_SHA512;
 
-   sym_op->auth.data.offset = CIPHER_IV_LENGTH_AES_CBC;
+   sym_op->auth.data.offset = 0;
sym_op->auth.data.length = QUOTE_512_BYTES;
 
-   sym_op->cipher.iv.data = (uint8_t *)rte_pktmbuf_prepend(
-   ut_params->ibuf, CIPHER_IV_LENGTH_AES_CBC);
-   sym_op->cipher.iv.phys_addr = rte_pktmbuf_mtophys_offset(
-   ut_params->ibuf, 0);
+   sym_op->cipher.iv.data = rte_crypto_op_ctod_offset(ut_params->op,
+   uint8_t *, IV_OFFSET);
+   sym_op->cipher.iv.phys_addr = 
rte_crypto_op_ctophys_offset(ut_params->op,
+   IV_OFFSET);
sym_op->cipher.iv.length = CIPHER_IV_LENGTH_AES_CBC;
 
-   rte_memcpy(sym_op->cipher.iv.data, iv,
-   CIPHER_IV_LENGTH_AES_CBC);
+   rte_memcpy(sym_op->cipher.iv.data, iv, CIPHER_IV_LENGTH_AES_CBC);
 
-   sym_op->cipher.data.offset = CIPHER_IV_LENGTH_AES_CBC;
+   sym_op->cipher.data.offset = 0;
sym_op->cipher.data.length = QUOTE_512_BYTES;
 
/* Process crypto operation */
@@ -1486,8 +1486,8 @@ test_AES_CBC_HMAC_SHA512_decrypt_perform(struct 
rte_cryptodev_sym_session *sess,
 
/* Validate obuf */
TEST_ASSERT_BUFFERS_ARE_EQUAL(
-   rte_pktmbuf_mtod(ut_params->obuf, uint8_t *) +
-   CIPHER_IV_LENGTH_AES_CBC, catch_22_quote,
+   rte_pktmbuf_mtod(ut_params->obuf, uint8_t *),
+   catch_22_quote,
QUOTE_512_BYTES,
"Plaintext data not as expected");
 

[dpdk-dev] [PATCH v4 08/26] test/crypto-perf: move IV to crypto op private data

2017-07-02 Thread Pablo de Lara
Usually, IV will change for each crypto operation.
Therefore, instead of pointing at the same location,
IV is copied after each crypto operation.

This will let the IV to be passed as an offset from
the beginning of the crypto operation, instead of
a pointer.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 test/test/test_cryptodev_perf.c | 110 ++--
 1 file changed, 60 insertions(+), 50 deletions(-)

diff --git a/test/test/test_cryptodev_perf.c b/test/test/test_cryptodev_perf.c
index 7a90667..b08451d 100644
--- a/test/test/test_cryptodev_perf.c
+++ b/test/test/test_cryptodev_perf.c
@@ -110,7 +110,6 @@ struct symmetric_session_attrs {
 
 struct crypto_params {
uint8_t *aad;
-   uint8_t *iv;
uint8_t *digest;
 };
 
@@ -265,7 +264,8 @@ testsuite_setup(void)
RTE_CRYPTO_OP_TYPE_SYMMETRIC,
NUM_MBUFS, MBUF_CACHE_SIZE,
DEFAULT_NUM_XFORMS *
-   sizeof(struct rte_crypto_sym_xform),
+   sizeof(struct rte_crypto_sym_xform) +
+   MAXIMUM_IV_LENGTH,
rte_socket_id());
if (ts_params->op_mpool == NULL) {
RTE_LOG(ERR, USER1, "Can't create CRYPTO_OP_POOL\n");
@@ -1978,19 +1978,20 @@ test_perf_crypto_qp_vary_burst_size(uint16_t dev_num)
data_params[0].length);
op->sym->auth.digest.length = DIGEST_BYTE_LENGTH_SHA256;
 
-   op->sym->auth.data.offset = CIPHER_IV_LENGTH_AES_CBC;
+   op->sym->auth.data.offset = 0;
op->sym->auth.data.length = data_params[0].length;
 
 
-   op->sym->cipher.iv.data = (uint8_t *)rte_pktmbuf_prepend(m,
-   CIPHER_IV_LENGTH_AES_CBC);
-   op->sym->cipher.iv.phys_addr = rte_pktmbuf_mtophys(m);
+   op->sym->cipher.iv.data = rte_crypto_op_ctod_offset(op,
+   uint8_t *, IV_OFFSET);
+   op->sym->cipher.iv.phys_addr = rte_crypto_op_ctophys_offset(op,
+   IV_OFFSET);
op->sym->cipher.iv.length = CIPHER_IV_LENGTH_AES_CBC;
 
rte_memcpy(op->sym->cipher.iv.data, aes_cbc_128_iv,
CIPHER_IV_LENGTH_AES_CBC);
 
-   op->sym->cipher.data.offset = CIPHER_IV_LENGTH_AES_CBC;
+   op->sym->cipher.data.offset = 0;
op->sym->cipher.data.length = data_params[0].length;
 
op->sym->m_src = m;
@@ -2887,23 +2888,25 @@ test_perf_set_crypto_op_aes(struct rte_crypto_op *op, 
struct rte_mbuf *m,
op->sym->auth.data.length = 0;
} else {
op->sym->auth.digest.data = rte_pktmbuf_mtod_offset(m,
-uint8_t *, AES_CIPHER_IV_LENGTH + data_len);
+uint8_t *, data_len);
op->sym->auth.digest.phys_addr = rte_pktmbuf_mtophys_offset(m,
-   AES_CIPHER_IV_LENGTH + data_len);
+   data_len);
op->sym->auth.digest.length = digest_len;
-   op->sym->auth.data.offset = AES_CIPHER_IV_LENGTH;
+   op->sym->auth.data.offset = 0;
op->sym->auth.data.length = data_len;
}
 
 
/* Cipher Parameters */
-   op->sym->cipher.iv.data = rte_pktmbuf_mtod(m, uint8_t *);
-   op->sym->cipher.iv.phys_addr = rte_pktmbuf_mtophys(m);
+   op->sym->cipher.iv.data = rte_crypto_op_ctod_offset(op,
+   uint8_t *, IV_OFFSET);
+   op->sym->cipher.iv.phys_addr = rte_crypto_op_ctophys_offset(op,
+   IV_OFFSET);
op->sym->cipher.iv.length = AES_CIPHER_IV_LENGTH;
 
rte_memcpy(op->sym->cipher.iv.data, aes_iv, AES_CIPHER_IV_LENGTH);
 
-   op->sym->cipher.data.offset = AES_CIPHER_IV_LENGTH;
+   op->sym->cipher.data.offset = 0;
op->sym->cipher.data.length = data_len;
 
op->sym->m_src = m;
@@ -2931,8 +2934,12 @@ test_perf_set_crypto_op_aes_gcm(struct rte_crypto_op 
*op, struct rte_mbuf *m,
op->sym->auth.aad.length = AES_GCM_AAD_LENGTH;
 
/* Cipher Parameters */
-   op->sym->cipher.iv.data = aes_iv;
+   op->sym->cipher.iv.data = rte_crypto_op_ctod_offset(op,
+   uint8_t *, IV_OFFSET);
+   op->sym->cipher.iv.phys_addr = rte_crypto_op_ctophys_offset(op,
+   IV_OFFSET);
op->sym->cipher.iv.length = AES_CIPHER_IV_LENGTH;
+   rte_memcpy(op->sym->cipher.iv.data, aes_iv, AES_CIPHER_IV_LENGTH);
 
/* Data lengths/offsets Parameters */
op->sym->auth.data.offset = 0;
@@ -2951,22 +2958,31 @@ test_perf_set_crypto_op_snow3g(struct rte_crypto_op 
*op, struct rte_mbuf *m,
struct rte_cryptodev_sym_session *sess, unsigned data_len,
unsigned digest_len)

[dpdk-dev] [PATCH v4 09/26] app/crypto-perf: move IV to crypto op private data

2017-07-02 Thread Pablo de Lara
Usually, IV will change for each crypto operation.
Therefore, instead of pointing at the same location,
IV is copied after each crypto operation.

This will let the IV to be passed as an offset from
the beginning of the crypto operation, instead of
a pointer.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_ops.c | 57 +++-
 app/test-crypto-perf/cperf_ops.h |  3 +-
 app/test-crypto-perf/cperf_test_latency.c|  8 +++-
 app/test-crypto-perf/cperf_test_throughput.c | 11 +++--
 app/test-crypto-perf/cperf_test_vector_parsing.c |  1 -
 app/test-crypto-perf/cperf_test_vectors.c|  1 -
 app/test-crypto-perf/cperf_test_verify.c | 10 +++--
 7 files changed, 68 insertions(+), 23 deletions(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 17df2eb..0f45a3c 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -40,7 +40,8 @@ cperf_set_ops_null_cipher(struct rte_crypto_op **ops,
struct rte_mbuf **bufs_in, struct rte_mbuf **bufs_out,
uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
const struct cperf_options *options,
-   const struct cperf_test_vector *test_vector __rte_unused)
+   const struct cperf_test_vector *test_vector __rte_unused,
+   uint16_t iv_offset __rte_unused)
 {
uint16_t i;
 
@@ -65,7 +66,8 @@ cperf_set_ops_null_auth(struct rte_crypto_op **ops,
struct rte_mbuf **bufs_in, struct rte_mbuf **bufs_out,
uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
const struct cperf_options *options,
-   const struct cperf_test_vector *test_vector __rte_unused)
+   const struct cperf_test_vector *test_vector __rte_unused,
+   uint16_t iv_offset __rte_unused)
 {
uint16_t i;
 
@@ -90,7 +92,8 @@ cperf_set_ops_cipher(struct rte_crypto_op **ops,
struct rte_mbuf **bufs_in, struct rte_mbuf **bufs_out,
uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
const struct cperf_options *options,
-   const struct cperf_test_vector *test_vector)
+   const struct cperf_test_vector *test_vector,
+   uint16_t iv_offset)
 {
uint16_t i;
 
@@ -103,8 +106,10 @@ cperf_set_ops_cipher(struct rte_crypto_op **ops,
sym_op->m_dst = bufs_out[i];
 
/* cipher parameters */
-   sym_op->cipher.iv.data = test_vector->iv.data;
-   sym_op->cipher.iv.phys_addr = test_vector->iv.phys_addr;
+   sym_op->cipher.iv.data = rte_crypto_op_ctod_offset(ops[i],
+   uint8_t *, iv_offset);
+   sym_op->cipher.iv.phys_addr = 
rte_crypto_op_ctophys_offset(ops[i],
+   iv_offset);
sym_op->cipher.iv.length = test_vector->iv.length;
 
if (options->cipher_algo == RTE_CRYPTO_CIPHER_SNOW3G_UEA2 ||
@@ -117,6 +122,13 @@ cperf_set_ops_cipher(struct rte_crypto_op **ops,
sym_op->cipher.data.offset = 0;
}
 
+   if (options->test == CPERF_TEST_TYPE_VERIFY) {
+   for (i = 0; i < nb_ops; i++)
+   memcpy(ops[i]->sym->cipher.iv.data,
+   test_vector->iv.data,
+   test_vector->iv.length);
+   }
+
return 0;
 }
 
@@ -125,7 +137,8 @@ cperf_set_ops_auth(struct rte_crypto_op **ops,
struct rte_mbuf **bufs_in, struct rte_mbuf **bufs_out,
uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
const struct cperf_options *options,
-   const struct cperf_test_vector *test_vector)
+   const struct cperf_test_vector *test_vector,
+   uint16_t iv_offset __rte_unused)
 {
uint16_t i;
 
@@ -189,7 +202,8 @@ cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
struct rte_mbuf **bufs_in, struct rte_mbuf **bufs_out,
uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
const struct cperf_options *options,
-   const struct cperf_test_vector *test_vector)
+   const struct cperf_test_vector *test_vector,
+   uint16_t iv_offset)
 {
uint16_t i;
 
@@ -202,8 +216,10 @@ cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
sym_op->m_dst = bufs_out[i];
 
/* cipher parameters */
-   sym_op->cipher.iv.data = test_vector->iv.data;
-   sym_op->cipher.iv.phys_addr = test_vector->iv.phys_addr;
+   sym_op->cipher.iv.data = rte_crypto_op_ctod_offset(ops[i],
+   uint8_t *, iv_offset);
+   

[dpdk-dev] [PATCH v4 11/26] examples/ipsec-secgw: move IV to crypto op private data

2017-07-02 Thread Pablo de Lara
Usually, IV will change for each crypto operation.
Therefore, instead of pointing at the same location,
IV is copied after each crypto operation.

This will let the IV to be passed as an offset from
the beginning of the crypto operation, instead of
a pointer.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 examples/ipsec-secgw/esp.c   | 27 ++-
 examples/ipsec-secgw/ipsec.h |  2 +-
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
index e77afa0..5bf2d7d 100644
--- a/examples/ipsec-secgw/esp.c
+++ b/examples/ipsec-secgw/esp.c
@@ -50,6 +50,9 @@
 #include "esp.h"
 #include "ipip.h"
 
+#define IV_OFFSET  (sizeof(struct rte_crypto_op) + \
+   sizeof(struct rte_crypto_sym_op))
+
 int
 esp_inbound(struct rte_mbuf *m, struct ipsec_sa *sa,
struct rte_crypto_op *cop)
@@ -93,13 +96,17 @@ esp_inbound(struct rte_mbuf *m, struct ipsec_sa *sa,
struct cnt_blk *icb;
uint8_t *aad;
uint8_t *iv = RTE_PTR_ADD(ip4, ip_hdr_len + sizeof(struct esp_hdr));
+   uint8_t *iv_ptr = rte_crypto_op_ctod_offset(cop,
+   uint8_t *, IV_OFFSET);
 
switch (sa->cipher_algo) {
case RTE_CRYPTO_CIPHER_NULL:
case RTE_CRYPTO_CIPHER_AES_CBC:
-   sym_cop->cipher.iv.data = iv;
-   sym_cop->cipher.iv.phys_addr = rte_pktmbuf_mtophys_offset(m,
-ip_hdr_len + sizeof(struct esp_hdr));
+   /* Copy IV at the end of crypto operation */
+   rte_memcpy(iv_ptr, iv, sa->iv_len);
+   sym_cop->cipher.iv.data = iv_ptr;
+   sym_cop->cipher.iv.phys_addr =
+   rte_crypto_op_ctophys_offset(cop, IV_OFFSET);
sym_cop->cipher.iv.length = sa->iv_len;
break;
case RTE_CRYPTO_CIPHER_AES_CTR:
@@ -108,9 +115,9 @@ esp_inbound(struct rte_mbuf *m, struct ipsec_sa *sa,
icb->salt = sa->salt;
memcpy(&icb->iv, iv, 8);
icb->cnt = rte_cpu_to_be_32(1);
-   sym_cop->cipher.iv.data = (uint8_t *)icb;
-   sym_cop->cipher.iv.phys_addr = rte_pktmbuf_mtophys_offset(m,
-(uint8_t *)icb - rte_pktmbuf_mtod(m, uint8_t *));
+   sym_cop->cipher.iv.data = iv_ptr;
+   sym_cop->cipher.iv.phys_addr =
+   rte_crypto_op_ctophys_offset(cop, IV_OFFSET);
sym_cop->cipher.iv.length = 16;
break;
default:
@@ -341,13 +348,15 @@ esp_outbound(struct rte_mbuf *m, struct ipsec_sa *sa,
padding[pad_len - 2] = pad_len - 2;
padding[pad_len - 1] = nlp;
 
+   uint8_t *iv_ptr = rte_crypto_op_ctod_offset(cop,
+   uint8_t *, IV_OFFSET);
struct cnt_blk *icb = get_cnt_blk(m);
icb->salt = sa->salt;
icb->iv = sa->seq;
icb->cnt = rte_cpu_to_be_32(1);
-   sym_cop->cipher.iv.data = (uint8_t *)icb;
-   sym_cop->cipher.iv.phys_addr = rte_pktmbuf_mtophys_offset(m,
-(uint8_t *)icb - rte_pktmbuf_mtod(m, uint8_t *));
+   sym_cop->cipher.iv.data = iv_ptr;
+   sym_cop->cipher.iv.phys_addr =
+   rte_crypto_op_ctophys_offset(cop, IV_OFFSET);
sym_cop->cipher.iv.length = 16;
 
uint8_t *aad;
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index fe42661..de1df7b 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -118,10 +118,10 @@ struct ipsec_sa {
 } __rte_cache_aligned;
 
 struct ipsec_mbuf_metadata {
-   uint8_t buf[32];
struct ipsec_sa *sa;
struct rte_crypto_op cop;
struct rte_crypto_sym_op sym_cop;
+   uint8_t buf[32];
 } __rte_cache_aligned;
 
 struct cdev_qp {
-- 
2.9.4



[dpdk-dev] [PATCH v4 10/26] examples/l2fwd-crypto: move IV to crypto op private data

2017-07-02 Thread Pablo de Lara
Usually, IV will change for each crypto operation.
Therefore, instead of pointing at the same location,
IV is copied after each crypto operation.

This will let the IV to be passed as an offset from
the beginning of the crypto operation, instead of
a pointer.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 examples/l2fwd-crypto/main.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 779b4fb..1380bc6 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -89,6 +89,10 @@ enum cdev_type {
 #define MAX_PKT_BURST 32
 #define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
 
+#define MAXIMUM_IV_LENGTH  16
+#define IV_OFFSET  (sizeof(struct rte_crypto_op) + \
+   sizeof(struct rte_crypto_sym_op))
+
 /*
  * Configurable number of RX/TX ring descriptors
  */
@@ -480,8 +484,14 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,
}
 
if (cparams->do_cipher) {
-   op->sym->cipher.iv.data = cparams->iv.data;
-   op->sym->cipher.iv.phys_addr = cparams->iv.phys_addr;
+   uint8_t *iv_ptr = rte_crypto_op_ctod_offset(op, uint8_t *,
+   IV_OFFSET);
+   /* Copy IV at the end of the crypto operation */
+   rte_memcpy(iv_ptr, cparams->iv.data, cparams->iv.length);
+
+   op->sym->cipher.iv.data = iv_ptr;
+   op->sym->cipher.iv.phys_addr =
+   rte_crypto_op_ctophys_offset(op, IV_OFFSET);
op->sym->cipher.iv.length = cparams->iv.length;
 
/* For wireless algorithms, offset/length must be in bits */
@@ -1950,7 +1960,6 @@ reserve_key_memory(struct l2fwd_crypto_options *options)
options->iv.data = rte_malloc("iv", MAX_KEY_SIZE, 0);
if (options->iv.data == NULL)
rte_exit(EXIT_FAILURE, "Failed to allocate memory for IV");
-   options->iv.phys_addr = rte_malloc_virt2phy(options->iv.data);
 
options->aad.data = rte_malloc("aad", MAX_KEY_SIZE, 0);
if (options->aad.data == NULL)
@@ -1993,7 +2002,7 @@ main(int argc, char **argv)
 
/* create crypto op pool */
l2fwd_crypto_op_pool = rte_crypto_op_pool_create("crypto_op_pool",
-   RTE_CRYPTO_OP_TYPE_SYMMETRIC, NB_MBUF, 128, 0,
+   RTE_CRYPTO_OP_TYPE_SYMMETRIC, NB_MBUF, 128, 
MAXIMUM_IV_LENGTH,
rte_socket_id());
if (l2fwd_crypto_op_pool == NULL)
rte_exit(EXIT_FAILURE, "Cannot create crypto op pool\n");
-- 
2.9.4



[dpdk-dev] [PATCH v4 14/26] cryptodev: add auth IV

2017-07-02 Thread Pablo de Lara
Authentication algorithms, such as AES-GMAC or the wireless
algorithms (like SNOW3G) use IV, like cipher algorithms.
So far, AES-GMAC has used the IV from the cipher structure,
and the wireless algorithms have used the AAD field,
which is not technically correct.

Therefore, authentication IV parameters have been added,
so API is more correct. Like cipher IV, auth IV is expected
to be copied after the crypto operation.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_ops.c |  61 +--
 app/test-crypto-perf/cperf_options.h |   2 +
 app/test-crypto-perf/cperf_options_parsing.c |   9 ++
 app/test-crypto-perf/cperf_test_latency.c|   4 +-
 app/test-crypto-perf/cperf_test_throughput.c |   3 +-
 app/test-crypto-perf/cperf_test_vector_parsing.c |  54 +++---
 app/test-crypto-perf/cperf_test_vectors.c|  37 +--
 app/test-crypto-perf/cperf_test_vectors.h|   8 +-
 app/test-crypto-perf/cperf_test_verify.c |   3 +-
 app/test-crypto-perf/data/aes_cbc_128_sha.data   |   2 +-
 app/test-crypto-perf/data/aes_cbc_192_sha.data   |   2 +-
 app/test-crypto-perf/data/aes_cbc_256_sha.data   |   2 +-
 app/test-crypto-perf/main.c  |  25 -
 doc/guides/prog_guide/cryptodev_lib.rst  |   3 +-
 doc/guides/rel_notes/release_17_08.rst   |   2 +
 doc/guides/sample_app_ug/l2_forward_crypto.rst   |  17 ++-
 doc/guides/tools/cryptoperf.rst  |  14 ++-
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c |   6 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c   |  21 ++--
 drivers/crypto/armv8/rte_armv8_pmd_ops.c |   6 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h|  18 ++--
 drivers/crypto/kasumi/rte_kasumi_pmd_ops.c   |   3 +-
 drivers/crypto/null/null_crypto_pmd_ops.c|   3 +-
 drivers/crypto/openssl/rte_openssl_pmd_ops.c |  78 --
 drivers/crypto/qat/qat_crypto_capabilities.h |  41 ---
 drivers/crypto/snow3g/rte_snow3g_pmd_ops.c   |   3 +-
 drivers/crypto/zuc/rte_zuc_pmd_ops.c |   3 +-
 examples/l2fwd-crypto/main.c | 132 +--
 lib/librte_cryptodev/rte_crypto_sym.h|  24 +
 lib/librte_cryptodev/rte_cryptodev.c |   6 +-
 lib/librte_cryptodev/rte_cryptodev.h |   6 +-
 31 files changed, 439 insertions(+), 159 deletions(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index f215445..60d55a0 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -121,9 +121,11 @@ cperf_set_ops_cipher(struct rte_crypto_op **ops,
uint8_t *iv_ptr = rte_crypto_op_ctod_offset(ops[i],
uint8_t *, iv_offset);
 
-   memcpy(iv_ptr, test_vector->iv.data,
-   test_vector->iv.length);
-   }   }
+   memcpy(iv_ptr, test_vector->cipher_iv.data,
+   test_vector->cipher_iv.length);
+
+   }
+   }
 
return 0;
 }
@@ -134,7 +136,7 @@ cperf_set_ops_auth(struct rte_crypto_op **ops,
uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
-   uint16_t iv_offset __rte_unused)
+   uint16_t iv_offset)
 {
uint16_t i;
 
@@ -146,6 +148,14 @@ cperf_set_ops_auth(struct rte_crypto_op **ops,
sym_op->m_src = bufs_in[i];
sym_op->m_dst = bufs_out[i];
 
+   if (test_vector->auth_iv.length) {
+   uint8_t *iv_ptr = rte_crypto_op_ctod_offset(ops[i],
+   uint8_t *,
+   iv_offset);
+   memcpy(iv_ptr, test_vector->auth_iv.data,
+   test_vector->auth_iv.length);
+   }
+
/* authentication parameters */
if (options->auth_op == RTE_CRYPTO_AUTH_OP_VERIFY) {
sym_op->auth.digest.data = test_vector->digest.data;
@@ -190,6 +200,17 @@ cperf_set_ops_auth(struct rte_crypto_op **ops,
sym_op->auth.data.offset = 0;
}
 
+   if (options->test == CPERF_TEST_TYPE_VERIFY) {
+   if (test_vector->auth_iv.length) {
+   for (i = 0; i < nb_ops; i++) {
+   uint8_t *iv_ptr = 
rte_crypto_op_ctod_offset(ops[i],
+   uint8_t *, iv_offset);
+
+   memcpy(iv_ptr, test_vector->auth_iv.data,
+   test_vector->auth_iv.length);
+   }
+   }
+   }
 

[dpdk-dev] [PATCH v4 12/26] cryptodev: pass IV as offset

2017-07-02 Thread Pablo de Lara
Since IV now is copied after the crypto operation, in
its private size, IV can be passed only with offset
and length.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_ops.c|  49 +++--
 doc/guides/prog_guide/cryptodev_lib.rst |   3 +-
 doc/guides/rel_notes/release_17_08.rst  |   2 +
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c|  80 +++--
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c  |   3 +-
 drivers/crypto/armv8/rte_armv8_pmd.c|   3 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c |   8 ++-
 drivers/crypto/kasumi/rte_kasumi_pmd.c  |  26 ---
 drivers/crypto/openssl/rte_openssl_pmd.c|  12 ++--
 drivers/crypto/qat/qat_crypto.c |  30 +---
 drivers/crypto/snow3g/rte_snow3g_pmd.c  |  14 ++--
 drivers/crypto/zuc/rte_zuc_pmd.c|   7 +-
 examples/ipsec-secgw/esp.c  |  14 +---
 examples/l2fwd-crypto/main.c|   5 +-
 lib/librte_cryptodev/rte_crypto_sym.h   |   7 +-
 test/test/test_cryptodev.c  | 107 +++-
 test/test/test_cryptodev_blockcipher.c  |   8 +--
 test/test/test_cryptodev_perf.c |  60 ++--
 18 files changed, 211 insertions(+), 227 deletions(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 0f45a3c..018ce0e 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -106,10 +106,7 @@ cperf_set_ops_cipher(struct rte_crypto_op **ops,
sym_op->m_dst = bufs_out[i];
 
/* cipher parameters */
-   sym_op->cipher.iv.data = rte_crypto_op_ctod_offset(ops[i],
-   uint8_t *, iv_offset);
-   sym_op->cipher.iv.phys_addr = 
rte_crypto_op_ctophys_offset(ops[i],
-   iv_offset);
+   sym_op->cipher.iv.offset = iv_offset;
sym_op->cipher.iv.length = test_vector->iv.length;
 
if (options->cipher_algo == RTE_CRYPTO_CIPHER_SNOW3G_UEA2 ||
@@ -123,11 +120,13 @@ cperf_set_ops_cipher(struct rte_crypto_op **ops,
}
 
if (options->test == CPERF_TEST_TYPE_VERIFY) {
-   for (i = 0; i < nb_ops; i++)
-   memcpy(ops[i]->sym->cipher.iv.data,
-   test_vector->iv.data,
-   test_vector->iv.length);
-   }
+   for (i = 0; i < nb_ops; i++) {
+   uint8_t *iv_ptr = rte_crypto_op_ctod_offset(ops[i],
+   uint8_t *, iv_offset);
+
+   memcpy(iv_ptr, test_vector->iv.data,
+   test_vector->iv.length);
+   }   }
 
return 0;
 }
@@ -216,10 +215,7 @@ cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
sym_op->m_dst = bufs_out[i];
 
/* cipher parameters */
-   sym_op->cipher.iv.data = rte_crypto_op_ctod_offset(ops[i],
-   uint8_t *, iv_offset);
-   sym_op->cipher.iv.phys_addr = 
rte_crypto_op_ctophys_offset(ops[i],
-   iv_offset);
+   sym_op->cipher.iv.offset = iv_offset;
sym_op->cipher.iv.length = test_vector->iv.length;
 
if (options->cipher_algo == RTE_CRYPTO_CIPHER_SNOW3G_UEA2 ||
@@ -275,10 +271,13 @@ cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
}
 
if (options->test == CPERF_TEST_TYPE_VERIFY) {
-   for (i = 0; i < nb_ops; i++)
-   memcpy(ops[i]->sym->cipher.iv.data,
-   test_vector->iv.data,
-   test_vector->iv.length);
+   for (i = 0; i < nb_ops; i++) {
+   uint8_t *iv_ptr = rte_crypto_op_ctod_offset(ops[i],
+   uint8_t *, iv_offset);
+
+   memcpy(iv_ptr, test_vector->iv.data,
+   test_vector->iv.length);
+   }
}
 
return 0;
@@ -303,10 +302,7 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
sym_op->m_dst = bufs_out[i];
 
/* cipher parameters */
-   sym_op->cipher.iv.data = rte_crypto_op_ctod_offset(ops[i],
-   uint8_t *, iv_offset);
-   sym_op->cipher.iv.phys_addr = 
rte_crypto_op_ctophys_offset(ops[i],
-   iv_offset);
+   sym_op->cipher.iv.offset = iv_offset;
sym_op->cipher.iv.length = test_vector->iv.length;
 
sym_op->cipher.data.length = options->test_buffer_size;
@@ -354,10 +350,13 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,

[dpdk-dev] [PATCH v4 13/26] cryptodev: move IV parameters to crypto session

2017-07-02 Thread Pablo de Lara
Since IV parameters (offset and length) should not
change for operations in the same session, these parameters
are moved to the crypto transform structure, so they will
be stored in the sessions.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_ops.c   |  19 ++-
 app/test-crypto-perf/cperf_ops.h   |   3 +-
 app/test-crypto-perf/cperf_test_latency.c  |   7 +-
 app/test-crypto-perf/cperf_test_throughput.c   |   6 +-
 app/test-crypto-perf/cperf_test_vectors.c  |   9 ++
 app/test-crypto-perf/cperf_test_verify.c   |   6 +-
 doc/guides/prog_guide/cryptodev_lib.rst|   5 -
 doc/guides/rel_notes/release_17_08.rst |   2 +
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c   |  22 ++--
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h   |   5 +
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c |  11 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   5 +
 drivers/crypto/armv8/rte_armv8_pmd.c   |  12 +-
 drivers/crypto/armv8/rte_armv8_pmd_private.h   |   7 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c|  39 --
 drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h  |   8 +-
 drivers/crypto/kasumi/rte_kasumi_pmd.c |  25 ++--
 drivers/crypto/kasumi/rte_kasumi_pmd_private.h |   1 +
 drivers/crypto/null/null_crypto_pmd_ops.c  |   6 +-
 drivers/crypto/openssl/rte_openssl_pmd.c   |  17 ++-
 drivers/crypto/openssl/rte_openssl_pmd_private.h   |   5 +
 drivers/crypto/qat/qat_adf/qat_algs.h  |   4 +
 drivers/crypto/qat/qat_crypto.c|  44 +++
 drivers/crypto/snow3g/rte_snow3g_pmd.c |  25 ++--
 drivers/crypto/snow3g/rte_snow3g_pmd_private.h |   1 +
 drivers/crypto/zuc/rte_zuc_pmd.c   |  16 +--
 drivers/crypto/zuc/rte_zuc_pmd_ops.c   |   2 +-
 drivers/crypto/zuc/rte_zuc_pmd_private.h   |   1 +
 examples/ipsec-secgw/esp.c |   9 --
 examples/ipsec-secgw/ipsec.h   |   3 +
 examples/ipsec-secgw/sa.c  |  20 +++
 examples/l2fwd-crypto/main.c   |  90 --
 lib/librte_cryptodev/rte_crypto_sym.h  |  98 +++
 test/test/test_cryptodev.c | 134 -
 test/test/test_cryptodev_blockcipher.c |   4 +-
 test/test/test_cryptodev_perf.c|  61 +-
 36 files changed, 417 insertions(+), 315 deletions(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 018ce0e..f215445 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -106,9 +106,6 @@ cperf_set_ops_cipher(struct rte_crypto_op **ops,
sym_op->m_dst = bufs_out[i];
 
/* cipher parameters */
-   sym_op->cipher.iv.offset = iv_offset;
-   sym_op->cipher.iv.length = test_vector->iv.length;
-
if (options->cipher_algo == RTE_CRYPTO_CIPHER_SNOW3G_UEA2 ||
options->cipher_algo == 
RTE_CRYPTO_CIPHER_KASUMI_F8 ||
options->cipher_algo == 
RTE_CRYPTO_CIPHER_ZUC_EEA3)
@@ -215,9 +212,6 @@ cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
sym_op->m_dst = bufs_out[i];
 
/* cipher parameters */
-   sym_op->cipher.iv.offset = iv_offset;
-   sym_op->cipher.iv.length = test_vector->iv.length;
-
if (options->cipher_algo == RTE_CRYPTO_CIPHER_SNOW3G_UEA2 ||
options->cipher_algo == 
RTE_CRYPTO_CIPHER_KASUMI_F8 ||
options->cipher_algo == 
RTE_CRYPTO_CIPHER_ZUC_EEA3)
@@ -302,9 +296,6 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
sym_op->m_dst = bufs_out[i];
 
/* cipher parameters */
-   sym_op->cipher.iv.offset = iv_offset;
-   sym_op->cipher.iv.length = test_vector->iv.length;
-
sym_op->cipher.data.length = options->test_buffer_size;
sym_op->cipher.data.offset =
RTE_ALIGN_CEIL(options->auth_aad_sz, 16);
@@ -365,7 +356,8 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
 static struct rte_cryptodev_sym_session *
 cperf_create_session(uint8_t dev_id,
const struct cperf_options *options,
-   const struct cperf_test_vector *test_vector)
+   const struct cperf_test_vector *test_vector,
+   uint16_t iv_offset)
 {
struct rte_crypto_sym_xform cipher_xform;
struct rte_crypto_sym_xform auth_xform;
@@ -379,6 +371,7 @@ cperf_create_session(uint8_t dev_id,
cipher_xform.next = NULL;
cipher_xform.cipher.algo = options->cipher_algo;
cipher_xform.cipher.op = options->cipher_op;
+   cipher_xform.cipher.

[dpdk-dev] [PATCH v4 16/26] cryptodev: remove AAD length from crypto op

2017-07-02 Thread Pablo de Lara
Additional authenticated data (AAD) information was duplicated
in the authentication transform and in the crypto
operation structures.

Since AAD length is not meant to be changed in a same session,
it is removed from the crypto operation structure.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_ops.c |  3 ---
 doc/guides/prog_guide/cryptodev_lib.rst  |  1 -
 doc/guides/rel_notes/release_17_08.rst   |  3 +++
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c |  6 +++--
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h |  2 ++
 drivers/crypto/openssl/rte_openssl_pmd.c |  4 ++-
 drivers/crypto/openssl/rte_openssl_pmd_private.h |  3 +++
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c |  1 +
 drivers/crypto/qat/qat_crypto.c  |  4 +--
 examples/ipsec-secgw/esp.c   |  2 --
 examples/l2fwd-crypto/main.c |  4 ---
 lib/librte_cryptodev/rte_crypto_sym.h|  6 +
 test/test/test_cryptodev.c   | 10 +++-
 test/test/test_cryptodev_perf.c  | 31 +---
 14 files changed, 39 insertions(+), 41 deletions(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 60d55a0..9405cef 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -186,7 +186,6 @@ cperf_set_ops_auth(struct rte_crypto_op **ops,
sym_op->auth.digest.length = options->auth_digest_sz;
sym_op->auth.aad.phys_addr = test_vector->aad.phys_addr;
sym_op->auth.aad.data = test_vector->aad.data;
-   sym_op->auth.aad.length = options->auth_aad_sz;
 
}
 
@@ -272,7 +271,6 @@ cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
sym_op->auth.digest.length = options->auth_digest_sz;
sym_op->auth.aad.phys_addr = test_vector->aad.phys_addr;
sym_op->auth.aad.data = test_vector->aad.data;
-   sym_op->auth.aad.length = options->auth_aad_sz;
}
 
if (options->auth_algo == RTE_CRYPTO_AUTH_SNOW3G_UIA2 ||
@@ -333,7 +331,6 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
 
sym_op->auth.aad.data = rte_pktmbuf_mtod(bufs_in[i], uint8_t *);
sym_op->auth.aad.phys_addr = rte_pktmbuf_mtophys(bufs_in[i]);
-   sym_op->auth.aad.length = options->auth_aad_sz;
 
/* authentication parameters */
if (options->auth_op == RTE_CRYPTO_AUTH_OP_VERIFY) {
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst 
b/doc/guides/prog_guide/cryptodev_lib.rst
index 68890ff..ea8fc00 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -553,7 +553,6 @@ chain.
 struct {
 uint8_t *data;
 phys_addr_t phys_addr;
-uint16_t length;
 } aad;/**< Additional authentication parameters */
 } auth;
 }
diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index eabf3dd..e633d73 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -163,6 +163,9 @@ API Changes
 ``rte_crypto_cipher_xform``.
   * Added authentication IV parameters (offset and length) in
 ``rte_crypto_auth_xform``.
+  * Removed Additional Authentication Data (AAD) length from 
``rte_crypto_sym_op``.
+  * Changed field size of AAD length in ``rte_crypto_auth_xform``,
+from uint32_t to uint16_t.
 
 
 ABI Changes
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 414f22b..f6136ba 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -145,6 +145,8 @@ aesni_gcm_set_session_parameters(struct aesni_gcm_session 
*sess,
return -EINVAL;
}
 
+   sess->aad_length = auth_xform->auth.add_auth_data_length;
+
return 0;
 }
 
@@ -255,7 +257,7 @@ process_gcm_crypto_op(struct rte_crypto_op *op,
aesni_gcm_enc[session->key].init(&session->gdata,
iv_ptr,
sym_op->auth.aad.data,
-   (uint64_t)sym_op->auth.aad.length);
+   (uint64_t)session->aad_length);
 
aesni_gcm_enc[session->key].update(&session->gdata, dst, src,
(uint64_t)part_len);
@@ -293,7 +295,7 @@ process_gcm_crypto_op(struct rte_crypto_op *op,
aesni_gcm_dec[session->key].init(&session->gdata,
iv_ptr,
sym_op->auth.aad.data,
-   (uint64_t)sym_op->auth.aad.length);
+  

[dpdk-dev] [PATCH v4 15/26] cryptodev: do not use AAD in wireless algorithms

2017-07-02 Thread Pablo de Lara
For wireless algorithms (SNOW3G, KASUMI, ZUC),
the IV for the authentication algorithms (F9, UIA2 and EIA3)
was taken from the AAD parameter, as there was no IV parameter
in the authentication structure.

Now that IV is available for all algorithms, there is need
to keep doing this, so AAD is not used for these algorithms
anymore.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_test_vectors.c  |   6 -
 drivers/crypto/kasumi/rte_kasumi_pmd.c |  25 +-
 drivers/crypto/kasumi/rte_kasumi_pmd_ops.c |   4 +-
 drivers/crypto/kasumi/rte_kasumi_pmd_private.h |   3 +-
 drivers/crypto/qat/qat_adf/qat_algs.h  |   6 +-
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c   |   6 +-
 drivers/crypto/qat/qat_crypto.c|  49 ++-
 drivers/crypto/qat/qat_crypto_capabilities.h   |  12 +-
 drivers/crypto/snow3g/rte_snow3g_pmd.c |  26 +-
 drivers/crypto/snow3g/rte_snow3g_pmd_ops.c |   4 +-
 drivers/crypto/snow3g/rte_snow3g_pmd_private.h |   3 +-
 drivers/crypto/zuc/rte_zuc_pmd.c   |  24 +-
 drivers/crypto/zuc/rte_zuc_pmd_ops.c   |   4 +-
 drivers/crypto/zuc/rte_zuc_pmd_private.h   |   3 +-
 lib/librte_cryptodev/rte_crypto_sym.h  |   7 +-
 test/test/test_cryptodev.c | 418 -
 .../test/test_cryptodev_kasumi_hash_test_vectors.h |  16 +-
 test/test/test_cryptodev_kasumi_test_vectors.h |  20 +-
 test/test/test_cryptodev_perf.c|  20 +-
 .../test/test_cryptodev_snow3g_hash_test_vectors.h |  14 +-
 test/test/test_cryptodev_snow3g_test_vectors.h |  24 +-
 test/test/test_cryptodev_zuc_test_vectors.h|  38 +-
 22 files changed, 322 insertions(+), 410 deletions(-)

diff --git a/app/test-crypto-perf/cperf_test_vectors.c 
b/app/test-crypto-perf/cperf_test_vectors.c
index 6829b86..b67d0f4 100644
--- a/app/test-crypto-perf/cperf_test_vectors.c
+++ b/app/test-crypto-perf/cperf_test_vectors.c
@@ -456,12 +456,6 @@ cperf_test_vector_get_dummy(struct cperf_options *options)
t_vec->auth_key.data = NULL;
aad_alloc = 1;
break;
-   case RTE_CRYPTO_AUTH_SNOW3G_UIA2:
-   case RTE_CRYPTO_AUTH_KASUMI_F9:
-   case RTE_CRYPTO_AUTH_ZUC_EIA3:
-   t_vec->auth_key.data = auth_key;
-   aad_alloc = 1;
-   break;
case RTE_CRYPTO_AUTH_AES_GMAC:
/* auth key should be the same as cipher key */
t_vec->auth_key.data = cipher_key;
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c 
b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index c92f5d1..3a3ffa4 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -117,7 +117,7 @@ kasumi_set_session_parameters(struct kasumi_session *sess,
if (cipher_xform->cipher.algo != RTE_CRYPTO_CIPHER_KASUMI_F8)
return -EINVAL;
 
-   sess->iv_offset = cipher_xform->cipher.iv.offset;
+   sess->cipher_iv_offset = cipher_xform->cipher.iv.offset;
if (cipher_xform->cipher.iv.length != KASUMI_IV_LENGTH) {
KASUMI_LOG_ERR("Wrong IV length");
return -EINVAL;
@@ -133,6 +133,13 @@ kasumi_set_session_parameters(struct kasumi_session *sess,
if (auth_xform->auth.algo != RTE_CRYPTO_AUTH_KASUMI_F9)
return -EINVAL;
sess->auth_op = auth_xform->auth.op;
+
+   sess->auth_iv_offset = auth_xform->auth.iv.offset;
+   if (auth_xform->auth.iv.length != KASUMI_IV_LENGTH) {
+   KASUMI_LOG_ERR("Wrong IV length");
+   return -EINVAL;
+   }
+
/* Initialize key */
sso_kasumi_init_f9_key_sched(auth_xform->auth.key.data,
&sess->pKeySched_hash);
@@ -194,7 +201,7 @@ process_kasumi_cipher_op(struct rte_crypto_op **ops,
rte_pktmbuf_mtod(ops[i]->sym->m_src, uint8_t *) +
(ops[i]->sym->cipher.data.offset >> 3);
iv_ptr = rte_crypto_op_ctod_offset(ops[i], uint8_t *,
-   session->iv_offset);
+   session->cipher_iv_offset);
iv[i] = *((uint64_t *)(iv_ptr));
num_bytes[i] = ops[i]->sym->cipher.data.length >> 3;
 
@@ -227,7 +234,7 @@ process_kasumi_cipher_op_bit(struct rte_crypto_op *op,
}
dst = rte_pktmbuf_mtod(op->sym->m_dst, uint8_t *);
iv_ptr = rte_crypto_op_ctod_offset(op, uint8_t *,
-   session->iv_offset);
+   session->cipher_iv_offset);
iv = *((uint64_t *)(iv_ptr));
length_in_bits = op->sym->cip

[dpdk-dev] [PATCH v4 17/26] cryptodev: remove digest length from crypto op

2017-07-02 Thread Pablo de Lara
Digest length was duplicated in the authentication transform
and the crypto operation structures.

Since digest length is not expected to change in a same
session, it is removed from the crypto operation.

Also, the length has been shrunk to 16 bits,
which should be sufficient for any digest.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_ops.c |  7 ---
 doc/guides/prog_guide/cryptodev_lib.rst  |  1 -
 doc/guides/rel_notes/release_17_08.rst   |  3 ++
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 34 +++---
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h |  2 +
 drivers/crypto/armv8/rte_armv8_pmd.c |  9 ++--
 drivers/crypto/armv8/rte_armv8_pmd_private.h |  2 +
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c  | 34 +++---
 drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h|  1 +
 drivers/crypto/kasumi/rte_kasumi_pmd.c   | 18 
 drivers/crypto/openssl/rte_openssl_pmd.c |  7 +--
 drivers/crypto/openssl/rte_openssl_pmd_private.h |  2 +
 drivers/crypto/qat/qat_adf/qat_algs.h|  1 +
 drivers/crypto/qat/qat_crypto.c  |  3 +-
 drivers/crypto/snow3g/rte_snow3g_pmd.c   | 18 
 drivers/crypto/zuc/rte_zuc_pmd.c | 18 
 examples/ipsec-secgw/esp.c   |  2 -
 examples/l2fwd-crypto/main.c |  1 -
 lib/librte_cryptodev/rte_crypto_sym.h|  6 +--
 test/test/test_cryptodev.c   | 34 +-
 test/test/test_cryptodev_blockcipher.c   |  5 +--
 test/test/test_cryptodev_perf.c  | 56 
 22 files changed, 119 insertions(+), 145 deletions(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 9405cef..401f85e 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -161,7 +161,6 @@ cperf_set_ops_auth(struct rte_crypto_op **ops,
sym_op->auth.digest.data = test_vector->digest.data;
sym_op->auth.digest.phys_addr =
test_vector->digest.phys_addr;
-   sym_op->auth.digest.length = options->auth_digest_sz;
} else {
 
uint32_t offset = options->test_buffer_size;
@@ -183,7 +182,6 @@ cperf_set_ops_auth(struct rte_crypto_op **ops,
uint8_t *, offset);
sym_op->auth.digest.phys_addr =
rte_pktmbuf_mtophys_offset(buf, offset);
-   sym_op->auth.digest.length = options->auth_digest_sz;
sym_op->auth.aad.phys_addr = test_vector->aad.phys_addr;
sym_op->auth.aad.data = test_vector->aad.data;
 
@@ -246,7 +244,6 @@ cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
sym_op->auth.digest.data = test_vector->digest.data;
sym_op->auth.digest.phys_addr =
test_vector->digest.phys_addr;
-   sym_op->auth.digest.length = options->auth_digest_sz;
} else {
 
uint32_t offset = options->test_buffer_size;
@@ -268,7 +265,6 @@ cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
uint8_t *, offset);
sym_op->auth.digest.phys_addr =
rte_pktmbuf_mtophys_offset(buf, offset);
-   sym_op->auth.digest.length = options->auth_digest_sz;
sym_op->auth.aad.phys_addr = test_vector->aad.phys_addr;
sym_op->auth.aad.data = test_vector->aad.data;
}
@@ -337,7 +333,6 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
sym_op->auth.digest.data = test_vector->digest.data;
sym_op->auth.digest.phys_addr =
test_vector->digest.phys_addr;
-   sym_op->auth.digest.length = options->auth_digest_sz;
} else {
 
uint32_t offset = sym_op->cipher.data.length +
@@ -360,8 +355,6 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
uint8_t *, offset);
sym_op->auth.digest.phys_addr =
rte_pktmbuf_mtophys_offset(buf, offset);
-
-   sym_op->auth.digest.length = options->auth_digest_sz;
}
 
sym_op->auth.data.length = options->test_buffer_size;
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst 
b/doc/guides/prog_guide/cryptodev_lib.rst
index ea8fc00..e036611 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -547,7 +547,6 @

[dpdk-dev] [PATCH v4 19/26] cryptodev: add AEAD specific data

2017-07-02 Thread Pablo de Lara
AEAD algorithms such as AES-GCM needed to be
used as a concatenation of a cipher transform and
an authentication transform.

Instead, a new transform and functions to handle it
are created to support these kind of algorithms,
making their use easier.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 doc/guides/prog_guide/cryptodev_lib.rst  | 14 +++--
 doc/guides/prog_guide/img/crypto_xform_chain.svg |  8 ++-
 doc/guides/rel_notes/release_17_08.rst   |  6 ++
 lib/librte_cryptodev/rte_crypto_sym.h| 80 +++-
 lib/librte_cryptodev/rte_cryptodev.c | 61 ++
 lib/librte_cryptodev/rte_cryptodev.h | 52 ++-
 lib/librte_cryptodev/rte_cryptodev_version.map   |  4 ++
 7 files changed, 215 insertions(+), 10 deletions(-)

diff --git a/doc/guides/prog_guide/cryptodev_lib.rst 
b/doc/guides/prog_guide/cryptodev_lib.rst
index e036611..b888554 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -188,8 +188,9 @@ the device having hardware acceleration or supporting 
symmetric Crypto
 operations,
 
 The capabilities mechanism defines the individual algorithms/functions which
-the device supports, such as a specific symmetric Crypto cipher or
-authentication operation.
+the device supports, such as a specific symmetric Crypto cipher,
+authentication operation or Authenticated Encryption with Associated Data
+(AEAD) operation.
 
 
 Device Features
@@ -477,9 +478,8 @@ operations such as cipher encrypt and authentication 
generate, the next pointer
 allows transform to be chained together. Crypto devices which support chaining
 must publish the chaining of symmetric Crypto operations feature flag.
 
-Currently there are two transforms types cipher and authentication, to specify
-an AEAD operation it is required to chain a cipher and an authentication
-transform together. Also it is important to note that the order in which the
+Currently there are three transforms types cipher, authentication and AEAD.
+Also it is important to note that the order in which the
 transforms are passed indicates the order of the chaining.
 
 .. code-block:: c
@@ -494,6 +494,8 @@ transforms are passed indicates the order of the chaining.
 /**< Authentication / hash xform */
 struct rte_crypto_cipher_xform cipher;
 /**< Cipher xform */
+struct rte_crypto_aead_xform aead;
+/**< AEAD xform */
 };
 };
 
@@ -514,7 +516,7 @@ operations.
 
 As a minimum the symmetric operation must have a source data buffer 
(``m_src``),
 a valid session (or transform chain if in session-less mode) and the minimum
-authentication/ cipher parameters required depending on the type of operation
+authentication/ cipher/ AEAD parameters required depending on the type of 
operation
 specified in the session or the transform
 chain.
 
diff --git a/doc/guides/prog_guide/img/crypto_xform_chain.svg 
b/doc/guides/prog_guide/img/crypto_xform_chain.svg
index 4670a07..1368163 100644
--- a/doc/guides/prog_guide/img/crypto_xform_chain.svg
+++ b/doc/guides/prog_guide/img/crypto_xform_chain.svg
@@ -69,7 +69,9 @@
class="st3">auth_xform  struct 
rte_crypto_cipher_xform
+   class="st3">xformstruct rte_crypto_aead_xform

Rounded Rectangle.26
next transform (struct rte_crypto_sym_xform 
*)
@@ -116,7 +118,9 @@
class="st3">auth_xform  struct 
rte_crypto_cipher_xform
+   class="st3">xformstruct rte_crypto_aead_xform

Rounded Rectangle.32
next transform (struct rte_crypto_sym_xform 
*)
diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index a544639..b920142 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -75,6 +75,12 @@ New Features
 
   Added support for firmwares with multiple Ethernet ports per physical port.
 
+* **Updated cryptodev library.**
+
+  Added AEAD algorithm specific functions and structures, so it is not
+  necessary to use a combination of cipher and authentication
+  structures anymore.
+
 
 Resolved Issues
 ---
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h 
b/lib/librte_cryptodev/rte_crypto_sym.h
index f174e12..db3957e 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -404,11 +404,87 @@ struct rte_crypto_auth_xform {
} iv;   /**< Initialisation vector parameters */
 };
 
+
+/** Symmetric AEAD Algorithms */
+enum rte_crypto_aead_algorithm {
+   RTE_CRYPTO_AEAD_AES_CCM = 1,
+   /**< AES algorithm in CCM m

[dpdk-dev] [PATCH v4 18/26] cryptodev: set AES-GMAC as auth-only algo

2017-07-02 Thread Pablo de Lara
AES-GMAC is an authentication algorithm, based on AES-GCM
without encryption. To simplify its usage, now it can be used
setting the authentication parameters, without requiring
to concatenate a ciphering transform.

Therefore, it is not required to set AAD, but authentication
data length and offset, giving the user the option
to have Scatter-Gather List in the input buffer,
as long as the driver supports it.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_options_parsing.c |   3 +-
 app/test-crypto-perf/cperf_test_vectors.c|   5 -
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 169 ---
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c |  12 +-
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h |   4 +-
 drivers/crypto/openssl/rte_openssl_pmd.c |  52 +--
 drivers/crypto/openssl/rte_openssl_pmd_ops.c |   9 +-
 drivers/crypto/qat/qat_crypto.c  | 151 ++--
 drivers/crypto/qat/qat_crypto_capabilities.h |  11 +-
 lib/librte_cryptodev/rte_crypto_sym.h|  39 +-
 test/test/test_cryptodev.c   | 159 ++---
 test/test/test_cryptodev_gcm_test_vectors.h  |  29 +---
 12 files changed, 374 insertions(+), 269 deletions(-)

diff --git a/app/test-crypto-perf/cperf_options_parsing.c 
b/app/test-crypto-perf/cperf_options_parsing.c
index 70b6a60..5c2dcff 100644
--- a/app/test-crypto-perf/cperf_options_parsing.c
+++ b/app/test-crypto-perf/cperf_options_parsing.c
@@ -820,8 +820,7 @@ cperf_options_check(struct cperf_options *options)
if (options->cipher_algo == RTE_CRYPTO_CIPHER_AES_GCM ||
options->cipher_algo == RTE_CRYPTO_CIPHER_AES_CCM ||
options->auth_algo == RTE_CRYPTO_AUTH_AES_GCM ||
-   options->auth_algo == RTE_CRYPTO_AUTH_AES_CCM ||
-   options->auth_algo == RTE_CRYPTO_AUTH_AES_GMAC) {
+   options->auth_algo == RTE_CRYPTO_AUTH_AES_CCM) {
if (options->op_type != CPERF_AEAD) {
RTE_LOG(ERR, USER1, "Use --optype aead\n");
return -EINVAL;
diff --git a/app/test-crypto-perf/cperf_test_vectors.c 
b/app/test-crypto-perf/cperf_test_vectors.c
index b67d0f4..2e5339c 100644
--- a/app/test-crypto-perf/cperf_test_vectors.c
+++ b/app/test-crypto-perf/cperf_test_vectors.c
@@ -456,11 +456,6 @@ cperf_test_vector_get_dummy(struct cperf_options *options)
t_vec->auth_key.data = NULL;
aad_alloc = 1;
break;
-   case RTE_CRYPTO_AUTH_AES_GMAC:
-   /* auth key should be the same as cipher key */
-   t_vec->auth_key.data = cipher_key;
-   aad_alloc = 1;
-   break;
default:
t_vec->auth_key.data = auth_key;
aad_alloc = 0;
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index fcf0f8b..36372a6 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -79,35 +79,74 @@ aesni_gcm_set_session_parameters(struct aesni_gcm_session 
*sess,
const struct rte_crypto_sym_xform *auth_xform;
const struct rte_crypto_sym_xform *cipher_xform;
uint16_t digest_length;
+   uint8_t key_length;
+   uint8_t *key;
 
-   if (xform->next == NULL || xform->next->next != NULL) {
-   GCM_LOG_ERR("Two and only two chained xform required");
-   return -EINVAL;
-   }
-
-   if (xform->type == RTE_CRYPTO_SYM_XFORM_CIPHER &&
-   xform->next->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
-   auth_xform = xform->next;
-   cipher_xform = xform;
-   } else if (xform->type == RTE_CRYPTO_SYM_XFORM_AUTH &&
-   xform->next->type == RTE_CRYPTO_SYM_XFORM_CIPHER) {
+   /* AES-GMAC */
+   if (xform->next == NULL) {
auth_xform = xform;
-   cipher_xform = xform->next;
+   if (auth_xform->auth.algo != RTE_CRYPTO_AUTH_AES_GMAC) {
+   GCM_LOG_ERR("Only AES GMAC is supported as an "
+   "authentication only algorithm");
+   return -EINVAL;
+   }
+   /* Set IV parameters */
+   sess->iv.offset = auth_xform->auth.iv.offset;
+   sess->iv.length = auth_xform->auth.iv.length;
+
+   /* Select Crypto operation */
+   if (auth_xform->auth.op == RTE_CRYPTO_AUTH_OP_GENERATE)
+   sess->op = AESNI_GMAC_OP_GENERATE;
+   else
+   sess->op = AESNI_GMAC_OP_VERIFY;
+
+   key_length = auth_xform->auth.key.length;
+   key = auth_xform->auth.

[dpdk-dev] [PATCH v4 20/26] cryptodev: add AEAD parameters in crypto operation

2017-07-02 Thread Pablo de Lara
AEAD operation parameters can be set in the new
aead structure, in the crypto operation.
This structure is within a union with the cipher
and authentication parameters, since operations can be:
- AEAD: using the aead structure

- Cipher only: using only the cipher structure

- Auth only: using only the authentication structure

- Cipher-then-auth/Auth-then-cipher: using both cipher
  and authentication structures

Therefore, all three cannot be used at the same time.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 doc/guides/prog_guide/cryptodev_lib.rst |  70 +++---
 doc/guides/rel_notes/release_17_08.rst  |   1 +
 lib/librte_cryptodev/rte_crypto_sym.h   | 375 
 3 files changed, 279 insertions(+), 167 deletions(-)

diff --git a/doc/guides/prog_guide/cryptodev_lib.rst 
b/doc/guides/prog_guide/cryptodev_lib.rst
index b888554..5048839 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -431,7 +431,6 @@ operations, as well as also supporting AEAD operations.
 
 
 Session and Session Management
-~~
 
 Session are used in symmetric cryptographic processing to store the immutable
 data defined in a cryptographic transform which is used in the operation
@@ -465,9 +464,6 @@ operation and its parameters. See the section below for 
details on transforms.
struct rte_cryptodev_sym_session * rte_cryptodev_sym_session_create(
   uint8_t dev_id, struct rte_crypto_sym_xform *xform);
 
-**Note**: For AEAD operations the algorithm selected for authentication and
-ciphering must aligned, eg AES_GCM.
-
 
 Transforms and Transform Chaining
 ~
@@ -533,30 +529,54 @@ chain.
 /**< Session-less API Crypto operation parameters */
 };
 
-struct {
-struct {
-uint32_t offset;
-uint32_t length;
-} data;   /**< Data offsets and length for ciphering */
-} cipher;
-
-struct {
-struct {
-uint32_t offset;
-uint32_t length;
-} data;   /**< Data offsets and length for authentication */
-
+union {
 struct {
-uint8_t *data;
-phys_addr_t phys_addr;
-} digest; /**< Digest parameters */
+struct {
+uint32_t offset;
+uint32_t length;
+} data; /**< Data offsets and length for AEAD */
+
+struct {
+uint8_t *data;
+phys_addr_t phys_addr;
+} digest; /**< Digest parameters */
+
+struct {
+uint8_t *data;
+phys_addr_t phys_addr;
+} aad;
+/**< Additional authentication parameters */
+} aead;
 
 struct {
-uint8_t *data;
-phys_addr_t phys_addr;
-} aad;/**< Additional authentication parameters */
-} auth;
-}
+struct {
+struct {
+uint32_t offset;
+uint32_t length;
+} data; /**< Data offsets and length for ciphering */
+} cipher;
+
+struct {
+struct {
+uint32_t offset;
+uint32_t length;
+} data;
+/**< Data offsets and length for authentication */
+
+struct {
+uint8_t *data;
+phys_addr_t phys_addr;
+} digest; /**< Digest parameters */
+
+struct {
+uint8_t *data;
+phys_addr_t phys_addr;
+} aad;
+/**< Additional authentication parameters */
+} auth;
+};
+};
+};
 
 
 Asymmetric Cryptography
diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index b920142..2c6bef5 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -175,6 +175,7 @@ API Changes
   * Removed digest length from ``rte_crypto_sym_op``.
   * Changed field size of digest length in ``rte_crypto_auth_xform``,
 from uint32_t to uint16_t.
+  * Added AEAD structure in ``rte_crypto_sym_op``.
 
 
 ABI Changes
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h 
b/lib/librte_cryptodev/rte_crypto_sym.h
index db3957e..f03d2fd 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -556,151 +556,242 @@ struct rte_crypto_sym_op {
/**< Session-less API crypto operation parameters */
};
 
-   struct {
-   struct {
-   uint32_t offset;
-   

[dpdk-dev] [PATCH v4 21/26] examples/l2fwd-crypto: avoid too many tabs

2017-07-02 Thread Pablo de Lara
Some extra functions have been created to avoid
too many nested conditionals.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 examples/l2fwd-crypto/main.c | 125 ++-
 1 file changed, 77 insertions(+), 48 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 6d88937..fb829e3 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1556,7 +1556,8 @@ check_all_ports_link_status(uint8_t port_num, uint32_t 
port_mask)
 
 /* Check if device has to be HW/SW or any */
 static int
-check_type(struct l2fwd_crypto_options *options, struct rte_cryptodev_info 
*dev_info)
+check_type(const struct l2fwd_crypto_options *options,
+   const struct rte_cryptodev_info *dev_info)
 {
if (options->type == CDEV_TYPE_HW &&
(dev_info->feature_flags & 
RTE_CRYPTODEV_FF_HW_ACCELERATED))
@@ -1570,6 +1571,74 @@ check_type(struct l2fwd_crypto_options *options, struct 
rte_cryptodev_info *dev_
return -1;
 }
 
+static const struct rte_cryptodev_capabilities *
+check_device_support_cipher_algo(const struct l2fwd_crypto_options *options,
+   const struct rte_cryptodev_info *dev_info,
+   uint8_t cdev_id)
+{
+   unsigned int i = 0;
+   const struct rte_cryptodev_capabilities *cap = 
&dev_info->capabilities[0];
+   enum rte_crypto_cipher_algorithm cap_cipher_algo;
+   enum rte_crypto_cipher_algorithm opt_cipher_algo =
+   options->cipher_xform.cipher.algo;
+
+   while (cap->op != RTE_CRYPTO_OP_TYPE_UNDEFINED) {
+   cap_cipher_algo = cap->sym.cipher.algo;
+   if (cap->sym.xform_type == RTE_CRYPTO_SYM_XFORM_CIPHER) {
+   if (cap_cipher_algo == opt_cipher_algo) {
+   if (check_type(options, dev_info) == 0)
+   break;
+   }
+   }
+   cap = &dev_info->capabilities[++i];
+   }
+
+   if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
+   printf("Algorithm %s not supported by cryptodev %u"
+   " or device not of preferred type (%s)\n",
+   rte_crypto_cipher_algorithm_strings[opt_cipher_algo],
+   cdev_id,
+   options->string_type);
+   return NULL;
+   }
+
+   return cap;
+}
+
+static const struct rte_cryptodev_capabilities *
+check_device_support_auth_algo(const struct l2fwd_crypto_options *options,
+   const struct rte_cryptodev_info *dev_info,
+   uint8_t cdev_id)
+{
+   unsigned int i = 0;
+   const struct rte_cryptodev_capabilities *cap = 
&dev_info->capabilities[0];
+   enum rte_crypto_auth_algorithm cap_auth_algo;
+   enum rte_crypto_auth_algorithm opt_auth_algo =
+   options->auth_xform.auth.algo;
+
+   while (cap->op != RTE_CRYPTO_OP_TYPE_UNDEFINED) {
+   cap_auth_algo = cap->sym.auth.algo;
+   if (cap->sym.xform_type == RTE_CRYPTO_SYM_XFORM_AUTH) {
+   if (cap_auth_algo == opt_auth_algo) {
+   if (check_type(options, dev_info) == 0)
+   break;
+   }
+   }
+   cap = &dev_info->capabilities[++i];
+   }
+
+   if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
+   printf("Algorithm %s not supported by cryptodev %u"
+   " or device not of preferred type (%s)\n",
+   rte_crypto_auth_algorithm_strings[opt_auth_algo],
+   cdev_id,
+   options->string_type);
+   return NULL;
+   }
+
+   return cap;
+}
+
 /* Check if the device is enabled by cryptodev_mask */
 static int
 check_cryptodev_mask(struct l2fwd_crypto_options *options,
@@ -1647,12 +1716,8 @@ static int
 initialize_cryptodevs(struct l2fwd_crypto_options *options, unsigned nb_ports,
uint8_t *enabled_cdevs)
 {
-   unsigned i, cdev_id, cdev_count, enabled_cdev_count = 0;
+   unsigned int cdev_id, cdev_count, enabled_cdev_count = 0;
const struct rte_cryptodev_capabilities *cap;
-   enum rte_crypto_auth_algorithm cap_auth_algo;
-   enum rte_crypto_auth_algorithm opt_auth_algo;
-   enum rte_crypto_cipher_algorithm cap_cipher_algo;
-   enum rte_crypto_cipher_algorithm opt_cipher_algo;
int retval;
 
cdev_count = rte_cryptodev_count();
@@ -1685,29 +1750,10 @@ initialize_cryptodevs(struct l2fwd_crypto_options 
*options, unsigned nb_ports,
options->xform_chain == 
L2FWD_CRYPTO_HASH_CIPHER ||
options->xform_chain == 
L2FWD_CRYPTO_CIPHER_ONLY) {
/* Check if device supports cipher algo */

[dpdk-dev] [PATCH v4 22/26] app/test-crypto-perf: add AEAD parameters

2017-07-02 Thread Pablo de Lara
Since there is a new operation type (AEAD), add parameters
for this in the application.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_ops.c | 138 ++-
 app/test-crypto-perf/cperf_options.h |  22 +++-
 app/test-crypto-perf/cperf_options_parsing.c | 138 ---
 app/test-crypto-perf/cperf_test_latency.c|   8 +-
 app/test-crypto-perf/cperf_test_throughput.c |   8 +-
 app/test-crypto-perf/cperf_test_vector_parsing.c |  12 +-
 app/test-crypto-perf/cperf_test_vectors.c| 106 ++---
 app/test-crypto-perf/cperf_test_vectors.h|  12 ++
 app/test-crypto-perf/cperf_test_verify.c |  10 +-
 app/test-crypto-perf/main.c  |  42 +--
 doc/guides/tools/cryptoperf.rst  |  32 +-
 11 files changed, 330 insertions(+), 198 deletions(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 401f85e..107abb0 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -182,8 +182,6 @@ cperf_set_ops_auth(struct rte_crypto_op **ops,
uint8_t *, offset);
sym_op->auth.digest.phys_addr =
rte_pktmbuf_mtophys_offset(buf, offset);
-   sym_op->auth.aad.phys_addr = test_vector->aad.phys_addr;
-   sym_op->auth.aad.data = test_vector->aad.data;
 
}
 
@@ -265,8 +263,6 @@ cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
uint8_t *, offset);
sym_op->auth.digest.phys_addr =
rte_pktmbuf_mtophys_offset(buf, offset);
-   sym_op->auth.aad.phys_addr = test_vector->aad.phys_addr;
-   sym_op->auth.aad.data = test_vector->aad.data;
}
 
if (options->auth_algo == RTE_CRYPTO_AUTH_SNOW3G_UIA2 ||
@@ -320,23 +316,22 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
sym_op->m_src = bufs_in[i];
sym_op->m_dst = bufs_out[i];
 
-   /* cipher parameters */
-   sym_op->cipher.data.length = options->test_buffer_size;
-   sym_op->cipher.data.offset =
-   RTE_ALIGN_CEIL(options->auth_aad_sz, 16);
+   /* AEAD parameters */
+   sym_op->aead.data.length = options->test_buffer_size;
+   sym_op->aead.data.offset =
+   RTE_ALIGN_CEIL(options->aead_aad_sz, 16);
 
-   sym_op->auth.aad.data = rte_pktmbuf_mtod(bufs_in[i], uint8_t *);
-   sym_op->auth.aad.phys_addr = rte_pktmbuf_mtophys(bufs_in[i]);
+   sym_op->aead.aad.data = rte_pktmbuf_mtod(bufs_in[i], uint8_t *);
+   sym_op->aead.aad.phys_addr = rte_pktmbuf_mtophys(bufs_in[i]);
 
-   /* authentication parameters */
-   if (options->auth_op == RTE_CRYPTO_AUTH_OP_VERIFY) {
-   sym_op->auth.digest.data = test_vector->digest.data;
-   sym_op->auth.digest.phys_addr =
+   if (options->aead_op == RTE_CRYPTO_AEAD_OP_DECRYPT) {
+   sym_op->aead.digest.data = test_vector->digest.data;
+   sym_op->aead.digest.phys_addr =
test_vector->digest.phys_addr;
} else {
 
-   uint32_t offset = sym_op->cipher.data.length +
-   sym_op->cipher.data.offset;
+   uint32_t offset = sym_op->aead.data.length +
+   sym_op->aead.data.offset;
struct rte_mbuf *buf, *tbuf;
 
if (options->out_of_place) {
@@ -351,14 +346,11 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
buf = tbuf;
}
 
-   sym_op->auth.digest.data = rte_pktmbuf_mtod_offset(buf,
+   sym_op->aead.digest.data = rte_pktmbuf_mtod_offset(buf,
uint8_t *, offset);
-   sym_op->auth.digest.phys_addr =
+   sym_op->aead.digest.phys_addr =
rte_pktmbuf_mtophys_offset(buf, offset);
}
-
-   sym_op->auth.data.length = options->test_buffer_size;
-   sym_op->auth.data.offset = options->auth_aad_sz;
}
 
if (options->test == CPERF_TEST_TYPE_VERIFY) {
@@ -366,8 +358,8 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
uint8_t *iv_ptr = rte_crypto_op_ctod_offset(ops[i],
uint8_t *, iv_offset);
 
-   memcpy(iv_ptr, test

[dpdk-dev] [PATCH v4 23/26] examples/ipsec-secgw: add AEAD parameters

2017-07-02 Thread Pablo de Lara
Since there is a new operation type (AEAD), add parameters
for this in the application.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 doc/guides/sample_app_ug/ipsec_secgw.rst |  32 +++--
 examples/ipsec-secgw/ipsec.h |   1 +
 examples/ipsec-secgw/sa.c| 116 +--
 3 files changed, 139 insertions(+), 10 deletions(-)

diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst 
b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 885c77e..ca2a34d 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -412,7 +412,7 @@ where each options means:
 
  * Cipher algorithm
 
- * Optional: No
+ * Optional: Yes, unless  is not used
 
  * Available options:
 
@@ -427,7 +427,8 @@ where each options means:
 
  * Cipher key, NOT available when 'null' algorithm is used
 
- * Optional: No, must followed by  option
+ * Optional: Yes, unless  is not used.
+   Must be followed by  option
 
  * Syntax: Hexadecimal bytes (0x0-0xFF) concatenate by colon symbol ':'.
The number of bytes should be as same as the specified cipher algorithm
@@ -440,7 +441,7 @@ where each options means:
 
  * Authentication algorithm
 
- * Optional: No
+ * Optional: Yes, unless  is not used
 
  * Available options:
 
@@ -453,7 +454,8 @@ where each options means:
  * Authentication key, NOT available when 'null' or 'aes-128-gcm' algorithm
is used.
 
- * Optional: No, must followed by  option
+ * Optional: Yes, unless  is not used.
+   Must be followed by  option
 
  * Syntax: Hexadecimal bytes (0x0-0xFF) concatenate by colon symbol ':'.
The number of bytes should be as same as the specified authentication
@@ -462,6 +464,28 @@ where each options means:
For example: *auth_key A1:B2:C3:D4:A1:B2:C3:D4:A1:B2:C3:D4:A1:B2:C3:D4:
A1:B2:C3:D4*
 
+
+
+ * AEAD algorithm
+
+ * Optional: Yes, unless  and  are not used
+
+ * Syntax: *cipher_algo *
+
+
+
+ * Cipher key, NOT available when 'null' algorithm is used
+
+ * Optional: Yes, unless  and  are not used.
+   Must be followed by  option
+
+ * Syntax: Hexadecimal bytes (0x0-0xFF) concatenate by colon symbol ':'.
+   The number of bytes should be as same as the specified AEAD algorithm
+   key size.
+
+   For example: *aead_key A1:B2:C3:D4:A1:B2:C3:D4:A1:B2:C3:D4:
+   A1:B2:C3:D4*
+
 
 
  * The operation mode
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index 405cf3d..f8569ca 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -103,6 +103,7 @@ struct ipsec_sa {
struct rte_cryptodev_sym_session *crypto_session;
enum rte_crypto_cipher_algorithm cipher_algo;
enum rte_crypto_auth_algorithm auth_algo;
+   enum rte_crypto_aead_algorithm aead_algo;
uint16_t digest_len;
uint16_t iv_len;
uint16_t block_size;
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 85e4d4e..9d80bd3 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -68,6 +68,17 @@ struct supported_auth_algo {
uint8_t key_not_req;
 };
 
+struct supported_aead_algo {
+   const char *keyword;
+   enum rte_crypto_aead_algorithm algo;
+   uint16_t iv_len;
+   uint16_t block_size;
+   uint16_t digest_len;
+   uint16_t key_len;
+   uint8_t aad_len;
+};
+
+
 const struct supported_cipher_algo cipher_algos[] = {
{
.keyword = "null",
@@ -128,6 +139,8 @@ const struct supported_auth_algo auth_algos[] = {
}
 };
 
+const struct supported_aead_algo aead_algos[] = { { } };
+
 struct ipsec_sa sa_out[IPSEC_SA_MAX_ENTRIES];
 uint32_t nb_sa_out;
 
@@ -166,6 +179,22 @@ find_match_auth_algo(const char *auth_keyword)
return NULL;
 }
 
+static const struct supported_aead_algo *
+find_match_aead_algo(const char *aead_keyword)
+{
+   size_t i;
+
+   for (i = 0; i < RTE_DIM(aead_algos); i++) {
+   const struct supported_aead_algo *algo =
+   &aead_algos[i];
+
+   if (strcmp(aead_keyword, algo->keyword) == 0)
+   return algo;
+   }
+
+   return NULL;
+}
+
 /** parse_key_string
  *  parse x:x:x:x hex number key string into uint8_t *key
  *  return:
@@ -210,6 +239,7 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
uint32_t *ri /*rule index*/;
uint32_t cipher_algo_p = 0;
uint32_t auth_algo_p = 0;
+   uint32_t aead_algo_p = 0;
uint32_t src_p = 0;
uint32_t dst_p = 0;
uint32_t mode_p = 0;
@@ -386,6 +416,61 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
continue;
}
 
+   if (strcmp(tokens[ti], "aead_algo") == 0) {
+   const struct supported_aead_algo *algo;
+   uint32_t key_len;
+
+   APP_CHECK_PRESENCE(aead_algo_p, tokens[ti],
+   

[dpdk-dev] [PATCH v4 26/26] cryptodev: remove AAD from authentication structure

2017-07-02 Thread Pablo de Lara
Now that AAD is only used in AEAD algorithms,
there is no need to keep AAD in the authentication
structure.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 app/test-crypto-perf/cperf_ops.c |  2 --
 doc/guides/prog_guide/cryptodev_lib.rst  |  6 --
 doc/guides/rel_notes/release_17_08.rst   |  3 +++
 drivers/crypto/openssl/rte_openssl_pmd.c |  1 -
 lib/librte_cryptodev/rte_crypto_sym.h| 26 --
 test/test/test_cryptodev.c   |  4 
 test/test/test_cryptodev_perf.c  |  1 -
 7 files changed, 3 insertions(+), 40 deletions(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 107abb0..d718278 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -422,7 +422,6 @@ cperf_create_session(uint8_t dev_id,
test_vector->auth_iv.length;
} else {
auth_xform.auth.digest_length = 0;
-   auth_xform.auth.add_auth_data_length = 0;
auth_xform.auth.key.length = 0;
auth_xform.auth.key.data = NULL;
auth_xform.auth.iv.length = 0;
@@ -475,7 +474,6 @@ cperf_create_session(uint8_t dev_id,
test_vector->auth_key.data;
} else {
auth_xform.auth.digest_length = 0;
-   auth_xform.auth.add_auth_data_length = 0;
auth_xform.auth.key.length = 0;
auth_xform.auth.key.data = NULL;
auth_xform.auth.iv.length = 0;
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst 
b/doc/guides/prog_guide/cryptodev_lib.rst
index 5048839..f250c00 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -567,12 +567,6 @@ chain.
 uint8_t *data;
 phys_addr_t phys_addr;
 } digest; /**< Digest parameters */
-
-struct {
-uint8_t *data;
-phys_addr_t phys_addr;
-} aad;
-/**< Additional authentication parameters */
 } auth;
 };
 };
diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index 2c6bef5..d29b203 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -176,6 +176,9 @@ API Changes
   * Changed field size of digest length in ``rte_crypto_auth_xform``,
 from uint32_t to uint16_t.
   * Added AEAD structure in ``rte_crypto_sym_op``.
+  * Removed AAD length from ``rte_crypto_auth_xform``.
+  * Removed AAD pointer and physical address from auth structure
+in ``rte_crypto_sym_op``.
 
 
 ABI Changes
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c 
b/drivers/crypto/openssl/rte_openssl_pmd.c
index 7f5c6aa..73e7ff1 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -413,7 +413,6 @@ openssl_set_session_auth_parameters(struct openssl_session 
*sess,
return -EINVAL;
}
 
-   sess->auth.aad_length = xform->auth.add_auth_data_length;
sess->auth.digest_length = xform->auth.digest_length;
 
return 0;
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h 
b/lib/librte_cryptodev/rte_crypto_sym.h
index dab042b..742dc34 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -326,13 +326,6 @@ struct rte_crypto_auth_xform {
 * the result shall be truncated.
 */
 
-   uint16_t add_auth_data_length;
-   /**< The length of the additional authenticated data (AAD) in bytes.
-* The maximum permitted value is 65535 (2^16 - 1) bytes, unless
-* otherwise specified below.
-*
-*/
-
struct {
uint16_t offset;
/**< Starting point for Initialisation Vector or Counter,
@@ -670,25 +663,6 @@ struct rte_crypto_sym_op {
phys_addr_t phys_addr;
/**< Physical address of digest */
} digest; /**< Digest parameters */
-
-   struct {
-   uint8_t *data;
-   /**< Pointer to Additional Authenticated
-* Data (AAD) needed for authenticated 
cipher
-* mechanisms (CCM and GCM).
-*
-* The length of the data pointed to by 
this
-* field is set up for the session in 
the @ref
-* rte_crypto_auth_xform structur

[dpdk-dev] [PATCH v4 24/26] examples/l2fwd-crypto: add AEAD parameters

2017-07-02 Thread Pablo de Lara
Since there is a new operation type (AEAD), add parameters
for this in the application.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 doc/guides/sample_app_ug/l2_forward_crypto.rst |  24 +-
 examples/l2fwd-crypto/main.c   | 388 +
 2 files changed, 357 insertions(+), 55 deletions(-)

diff --git a/doc/guides/sample_app_ug/l2_forward_crypto.rst 
b/doc/guides/sample_app_ug/l2_forward_crypto.rst
index b9aa573..2880c43 100644
--- a/doc/guides/sample_app_ug/l2_forward_crypto.rst
+++ b/doc/guides/sample_app_ug/l2_forward_crypto.rst
@@ -110,7 +110,9 @@ where,
 
 *   chain: select the operation chaining to perform: Cipher->Hash 
(CIPHER_HASH),
 
-Hash->Cipher (HASH_CIPHER), Cipher (CIPHER_ONLY), Hash(HASH_ONLY)
+Hash->Cipher (HASH_CIPHER), Cipher (CIPHER_ONLY), Hash (HASH_ONLY)
+
+or AEAD (AEAD)
 
 (default is Cipher->Hash)
 
@@ -154,6 +156,26 @@ where,
 
 Note that if --auth_iv is used, this will be ignored.
 
+*   aead_algo: select the AEAD algorithm
+
+*   aead_op: select the AEAD operation to perform: ENCRYPT or DECRYPT
+
+(default is ENCRYPT)
+
+*   aead_key: set the AEAD key to be used. Bytes has to be separated with ":"
+
+*   aead_key_random_size: set the size of the AEAD key,
+
+which will be generated randomly.
+
+Note that if --aead_key is used, this will be ignored.
+
+*   aead_iv: set the AEAD IV to be used. Bytes has to be separated with ":"
+
+*   aead_iv_random_size: set the size of the AEAD IV, which will be generated 
randomly.
+
+Note that if --aead_iv is used, this will be ignored.
+
 *   aad: set the AAD to be used. Bytes has to be separated with ":"
 
 *   aad_random_size: set the size of the AAD, which will be generated randomly.
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index fb829e3..914f8ed 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -130,7 +130,8 @@ enum l2fwd_crypto_xform_chain {
L2FWD_CRYPTO_CIPHER_HASH,
L2FWD_CRYPTO_HASH_CIPHER,
L2FWD_CRYPTO_CIPHER_ONLY,
-   L2FWD_CRYPTO_HASH_ONLY
+   L2FWD_CRYPTO_HASH_ONLY,
+   L2FWD_CRYPTO_AEAD
 };
 
 struct l2fwd_key {
@@ -172,6 +173,14 @@ struct l2fwd_crypto_options {
unsigned int auth_iv_param;
int auth_iv_random_size;
 
+   struct rte_crypto_sym_xform aead_xform;
+   unsigned int aead_key_param;
+   int aead_key_random_size;
+
+   struct l2fwd_iv aead_iv;
+   unsigned int aead_iv_param;
+   int aead_iv_random_size;
+
struct l2fwd_key aad;
unsigned aad_param;
int aad_random_size;
@@ -194,15 +203,18 @@ struct l2fwd_crypto_params {
 
struct l2fwd_iv cipher_iv;
struct l2fwd_iv auth_iv;
+   struct l2fwd_iv aead_iv;
struct l2fwd_key aad;
struct rte_cryptodev_sym_session *session;
 
uint8_t do_cipher;
uint8_t do_hash;
+   uint8_t do_aead;
uint8_t hash_verify;
 
enum rte_crypto_cipher_algorithm cipher_algo;
enum rte_crypto_auth_algorithm auth_algo;
+   enum rte_crypto_aead_algorithm aead_algo;
 };
 
 /** lcore configuration */
@@ -492,14 +504,6 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,
op->sym->auth.data.offset = ipdata_offset;
op->sym->auth.data.length = data_len;
}
-
-   if (cparams->aad.length) {
-   op->sym->auth.aad.data = cparams->aad.data;
-   op->sym->auth.aad.phys_addr = cparams->aad.phys_addr;
-   } else {
-   op->sym->auth.aad.data = NULL;
-   op->sym->auth.aad.phys_addr = 0;
-   }
}
 
if (cparams->do_cipher) {
@@ -521,6 +525,33 @@ l2fwd_simple_crypto_enqueue(struct rte_mbuf *m,
}
}
 
+   if (cparams->do_aead) {
+   uint8_t *iv_ptr = rte_crypto_op_ctod_offset(op, uint8_t *,
+   IV_OFFSET);
+   /* Copy IV at the end of the crypto operation */
+   rte_memcpy(iv_ptr, cparams->aead_iv.data, 
cparams->aead_iv.length);
+
+   op->sym->aead.data.offset = ipdata_offset;
+   op->sym->aead.data.length = data_len;
+
+   if (!cparams->hash_verify) {
+   /* Append space for digest to end of packet */
+   op->sym->aead.digest.data = (uint8_t 
*)rte_pktmbuf_append(m,
+   cparams->digest_length);
+   } else {
+   op->sym->aead.digest.data = rte_pktmbuf_mtod(m,
+   uint8_t *) + ipdata_offset + data_len;
+   }
+
+   op->sym->auth.digest.phys_addr = rte_pktmbuf_mtophys_offset(m,
+   rte_pktmbuf_pkt_len(m) - 
cparams->digest_length);
+
+   if (cparams->aad.length) {
+   

[dpdk-dev] [PATCH v4 25/26] cryptodev: use AES-GCM/CCM as AEAD algorithms

2017-07-02 Thread Pablo de Lara
Now that all the structures/functions for AEAD algorithms
are in place, migrate the two supported algorithms
AES-GCM and AES-CCM to these, instead of using
cipher and authentication parameters.

Signed-off-by: Pablo de Lara 
Acked-by: Akhil Goyal 
Acked-by: Fiona Trahe 
---
 doc/guides/sample_app_ug/ipsec_secgw.rst |  11 +-
 doc/guides/sample_app_ug/l2_forward_crypto.rst   |   2 +-
 doc/guides/tools/cryptoperf.rst  |   4 -
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c |  76 ++--
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c |  24 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c  |   8 -
 drivers/crypto/openssl/rte_openssl_pmd.c | 140 +--
 drivers/crypto/openssl/rte_openssl_pmd_ops.c |  26 +-
 drivers/crypto/openssl/rte_openssl_pmd_private.h |   4 +
 drivers/crypto/qat/qat_crypto.c  | 186 +++---
 drivers/crypto/qat/qat_crypto.h  |   4 +
 drivers/crypto/qat/qat_crypto_capabilities.h |  34 +-
 examples/ipsec-secgw/esp.c   | 231 +++-
 examples/ipsec-secgw/sa.c| 187 ++
 examples/l2fwd-crypto/main.c |   3 +
 lib/librte_cryptodev/rte_crypto_sym.h| 100 -
 lib/librte_cryptodev/rte_cryptodev.c |   4 -
 test/test/test_cryptodev.c   | 218 +--
 test/test/test_cryptodev_perf.c  | 446 ---
 19 files changed, 892 insertions(+), 816 deletions(-)

diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst 
b/doc/guides/sample_app_ug/ipsec_secgw.rst
index ca2a34d..75b960f 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -419,7 +419,6 @@ where each options means:
* *null*: NULL algorithm
* *aes-128-cbc*: AES-CBC 128-bit algorithm
* *aes-128-ctr*: AES-CTR 128-bit algorithm
-   * *aes-128-gcm*: AES-GCM 128-bit algorithm
 
  * Syntax: *cipher_algo *
 
@@ -447,7 +446,6 @@ where each options means:
 
 * *null*: NULL algorithm
 * *sha1-hmac*: HMAC SHA1 algorithm
-* *aes-128-gcm*: AES-GCM 128-bit algorithm
 
 
 
@@ -470,6 +468,10 @@ where each options means:
 
  * Optional: Yes, unless  and  are not used
 
+ * Available options:
+
+   * *aes-128-gcm*: AES-GCM 128-bit algorithm
+
  * Syntax: *cipher_algo *
 
 
@@ -539,9 +541,8 @@ Example SA rules:
 src ::::::: \
 dst :::::::
 
-sa in 105 cipher_algo aes-128-gcm \
-cipher_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
-auth_algo aes-128-gcm \
+sa in 105 aead_algo aes-128-gcm \
+aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
 mode ipv4-tunnel src 172.16.2.5 dst 172.16.1.5
 
 Routing rule syntax
diff --git a/doc/guides/sample_app_ug/l2_forward_crypto.rst 
b/doc/guides/sample_app_ug/l2_forward_crypto.rst
index 2880c43..2a61af7 100644
--- a/doc/guides/sample_app_ug/l2_forward_crypto.rst
+++ b/doc/guides/sample_app_ug/l2_forward_crypto.rst
@@ -156,7 +156,7 @@ where,
 
 Note that if --auth_iv is used, this will be ignored.
 
-*   aead_algo: select the AEAD algorithm
+*   aead_algo: select the AEAD algorithm (default is aes-gcm)
 
 *   aead_op: select the AEAD operation to perform: ENCRYPT or DECRYPT
 
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index 6b797a7..a077e7d 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -223,10 +223,8 @@ The following are the appication command-line options:
3des-ecb
3des-ctr
aes-cbc
-   aes-ccm
aes-ctr
aes-ecb
-   aes-gcm
aes-f8
aes-xts
arc4
@@ -257,9 +255,7 @@ The following are the appication command-line options:
 
3des-cbc
aes-cbc-mac
-   aes-ccm
aes-cmac
-   aes-gcm
aes-gmac
aes-xcbc-mac
md5
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 36372a6..567c2ec 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -77,13 +77,13 @@ aesni_gcm_set_session_parameters(struct aesni_gcm_session 
*sess,
const struct rte_crypto_sym_xform *xform)
 {
const struct rte_crypto_sym_xform *auth_xform;
-   const struct rte_crypto_sym_xform *cipher_xform;
+   const struct rte_crypto_sym_xform *aead_xform;
uint16_t digest_length;
uint8_t key_length;
uint8_t *key;
 
/* AES-GMAC */
-   if (xform->next == NULL) {
+   if (xform->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
auth_xform = xform;
if (auth_xform->auth.algo != RTE_CRYPTO_AUTH_AES_GMAC) {
GCM_LOG_ERR("Only AES GMAC is supported as an "
@@ -102,52 +102,39 @@ ae

Re: [dpdk-dev] [PATCH] doc: Minor typo in documentation

2017-07-02 Thread Thomas Monjalon
> > Signed-off-by: Harrison McCullough 
> 
> Acked-by: John McNamara 

Applied, thanks



Re: [dpdk-dev] [PATCH] doc: fix some typos in prog_guide

2017-07-02 Thread Thomas Monjalon
> > Signed-off-by: Xingyou Chen 
> 
> Acked-by: John McNamara 

Applied, thanks




Re: [dpdk-dev] [PATCH] doc: fix typos in virtio howto guide

2017-07-02 Thread Thomas Monjalon
> > Signed-off-by: Yong Wang 
> 
> Acked-by: John McNamara 

Applied, thanks


Re: [dpdk-dev] [PATCH] ethdev: fix a typo in eth device API doc

2017-07-02 Thread Thomas Monjalon
30/06/2017 16:47, Mcnamara, John:
> > 
> > This patch fixes a typo in the eth device API doc, device config. not
> > stored between calls to rte_eth_dev_start/stop() should be restored before
> > a call to rte_eth_dev_start() instead of after a call to
> > rte_eth_dev_start().
> > 
> > Signed-off-by: Nikhil Rao 
> 
> Acked-by: John McNamara 

I am still not convinced by this whole text,
but applied to move forward.



Re: [dpdk-dev] [PATCH] app/testpmd:add bond type description

2017-07-02 Thread Thomas Monjalon
30/06/2017 17:39, Declan Doherty:
> On 30/06/17 08:56, RongQiang Xie wrote:
> > In function cmd_show_bonding_config_parsed() used number represent
> > the bond type,in order more detailed,add bond type description
> > otherwise we may confused about the number type.
> > And also,the primary port just use in mode active backup and tlb,
> > so,when the mode is active backup or tlb show the primary port info
> > may be more appropriate.
> > 
> > Signed-off-by: RongQiang Xie 
> > ---
> >   app/test-pmd/cmdline.c | 17 +++--
> >   1 file changed, 11 insertions(+), 6 deletions(-)
> > 
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > index ff8ffd2..45845a4 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -4390,7 +4390,9 @@ static void cmd_show_bonding_config_parsed(void 
> > *parsed_result,
> > printf("\tFailed to get bonding mode for port = %d\n", port_id);
> > return;
> > } else
> > -   printf("\tBonding mode: %d\n", bonding_mode);
> > +   printf("\tBonding mode: %d ", bonding_mode);
> > +   printf("[0:Round Robin, 1:Active Backup, 2:Balance, 3:Broadcast, ");
> > +   printf("\n\t\t\t4:802.3AD, 5:Adaptive TLB, 6:Adaptive Load 
> > Balancing]\n");
> >   
> 
> Good idea, but it would be clearer if we just returned the actual mode 
> string so the user doesn't need to parse it themselves, like below.
> 
> -   } else
> -   printf("\tBonding mode: %d ", bonding_mode);
> -   printf("[0:Round Robin, 1:Active Backup, 2:Balance, 3:Broadcast, ");
> -   printf("\n\t\t\t4:802.3AD, 5:Adaptive TLB, 6:Adaptive Load 
> Balancing]\n");
> +   }
> +
> +   printf("\tBonding mode: %d (", bonding_mode);
> +   switch (bonding_mode) {
> +   case BONDING_MODE_ROUND_ROBIN:
> +   printf("round-robin");
> +   break;
> +   case BONDING_MODE_ACTIVE_BACKUP:
> +   printf("active-backup");
> +   break;
> +   case BONDING_MODE_BALANCE:
> +   printf("link-aggregation");
> +   break;
> +   case BONDING_MODE_BROADCAST:
> +   printf("broadcast");
> +   break;
> +   case BONDING_MODE_8023AD:
> +   printf("link-aggregation-802.3ad");
> +   break;
> +   case BONDING_MODE_TLB:
> +   printf("transmit-load-balancing");
> +   break;
> +   case BONDING_MODE_ALB:
> +   printf("adaptive-load-balancing");
> +   break;
> +   default:
> +   printf("unknown-mode");
> +   }
> +   printf(")\n");

I would say no.
Can we think how to implement this kind of things inside the bonding code?



Re: [dpdk-dev] [PATCH] doc: add knowing issue for i40e VF performance

2017-07-02 Thread Mcnamara, John


> -Original Message-
> From: Zhang, Qi Z
> Sent: Sunday, July 2, 2017 1:07 PM
> To: Mcnamara, John ; Wu, Jingjing
> 
> Cc: Zhang, Helin ; dev@dpdk.org; Zhang, Qi Z
> 
> Subject: [PATCH] doc: add knowing issue for i40e VF performance
> 
> VF performance is limited by some kernel PCI setting.
> Update the document to explain the knowing issue and work around solution.
> 
> Signed-off-by: Qi Zhang 
> ---
>  doc/guides/nics/i40e.rst | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index
> 4d3c7ca..557d83d 100644
> --- a/doc/guides/nics/i40e.rst
> +++ b/doc/guides/nics/i40e.rst
> @@ -447,3 +447,27 @@ It means if APP has set the max bandwidth for that
> TC, it comes to no  effect.
>  It's suggested to set the strict priority mode for a TC that is latency
> sensitive but no consuming much bandwidth.
> +
> +VF performance is impacted by PCI extended tag setting
> +~~
> +
> +To reach maximum NIC performance. PCI extended tag is required to be
> enabled.
> +DPDK I40E PF drvier will set this feature during initialization, but
> +Kernel PF driver does not. So when running traffic on a VF which is
> +managed by kernel PF driver, we saw significent NIC performance
> +downgrade (for 64 bytes packet, there is about 25% linerate downgrade
> +for 25G device and about 35% for 40G device).
> +
> +Solution:
> +
> +For kernel version >= 4.11, kernel's PCI driver will enale extended tag
> +if it detects that device support extended tag. So by default, this is
> not an issue.
> +When extended tag is be disabled by occasionally, to re-enable it, see
> below.
> +
> +For kernel version < 4.11, use setpci command to enable PCI extended
> +flag
> +1) get current value of PCI configure register setpci -s  a8.w
> +2) set bit 8
> +value = value | 0x100
> +3) set PCI configure register with new value.
> +setpci -s  a8.w=

To use a numbered list in the doc you should do it like this:

#. Get the current value of the PCI configure register::

  setpci -s  a8.w

#. Set bit 8::

  value = value | 0x100

#. Set the PCI configure register with new value::

  setpci -s  a8.w=


John


Re: [dpdk-dev] [PATCH] ethdev: fix a typo in eth device API doc

2017-07-02 Thread Mcnamara, John
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Sunday, July 2, 2017 6:49 PM
> To: Mcnamara, John 
> Cc: dev@dpdk.org; Rao, Nikhil 
> Subject: Re: [dpdk-dev] [PATCH] ethdev: fix a typo in eth device API doc
> 
> 30/06/2017 16:47, Mcnamara, John:
> > >
> > > This patch fixes a typo in the eth device API doc, device config.
> > > not stored between calls to rte_eth_dev_start/stop() should be
> > > restored before a call to rte_eth_dev_start() instead of after a
> > > call to rte_eth_dev_start().
> > >
> > > Signed-off-by: Nikhil Rao 
> >
> > Acked-by: John McNamara 
> 
> I am still not convinced by this whole text, but applied to move forward.

Agreed. We should mark this as a defect and have someone re-evaluate the
overall text. However, in terms of this patch, at least it is less wrong than
the existing text.



Re: [dpdk-dev] [PATCH v9 19/20] doc: add control interface library documentation

2017-07-02 Thread Mcnamara, John


> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, June 30, 2017 5:52 PM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Stephen Hemminger
> ; Richardson, Bruce
> ; Burakov, Anatoly 
> Subject: [dpdk-dev] [PATCH v9 19/20] doc: add control interface library
> documentation
> 
> Signed-off-by: Ferruh Yigit 


Acked-by: John McNamara 




Re: [dpdk-dev] [PATCH v2 11/11] doc: add new crypto session information

2017-07-02 Thread Mcnamara, John


> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara
> Sent: Friday, June 30, 2017 6:10 PM
> To: Doherty, Declan ;
> zbigniew.bo...@caviumnetworks.com; jerin.ja...@caviumnetworks.com;
> akhil.go...@nxp.com; hemant.agra...@nxp.com; Trahe, Fiona
> ; Griffin, John ; Jain,
> Deepak K 
> Cc: dev@dpdk.org; De Lara Guarch, Pablo ;
> Mrozowicz, SlawomirX 
> Subject: [dpdk-dev] [PATCH v2 11/11] doc: add new crypto session
> information
> 
> Modified cryptodev library section in Programmer's Guide, with the recent
> changes in the rypto sessions.


s/rypto/crypto/




> 
> Signed-off-by: Slawomir Mrozowicz 
> Signed-off-by: Pablo de Lara 

> ...

> +The Crypto device framework provides APIs to allocate and initizalize
> +sessions for crypto devices, where sessions are mempool objects.
> +It is the application responsability to create and manage the session
> mempools.

s/application/application's/
s/responsability/responsibility/

> +This approach allows for different scenarios such as having a single
> +session mempool for all crypto devices (where the the mempool object

s/the the/the/

> +size is big enough to hold the private session of any crypto device),
> +as well as having multiple session mempools of different sizes for better
> memory usage.
> +


> +An application could use ``rte_cryptodev_get_private_session_size()``
> +to get the private session size of given crypto device. This function

s/could/can/ is probably better.
s/given/a given/

> +would allow an application to calculate the max device session size of
> +all crypto devices to create a single session mempool.
> +If instead an application creates multiple session mempools, the Crypto
> +device framework also provides
> +``rte_cryptodev_get_header_session_size`` to get the size of an
> uninitialized session.
> +
> +Once the session mempools have been created,
> +``rte_cryptodev_sym_session_create()``
> +is used to allocate an uninitialized session from the given mempool.
> +The session then must be initialized ``rte_cryptodev_sym_session_init()``
> +for each of the crypto devices to be used with. A symmetric transform

Probably better as: 

The session then must be initialized using 
``rte_cryptodev_sym_session_init()``
for each of the required crypto devices. A symmetric transform

> +chain is used to specify the operation and its parameters. See the
> +section below for details on transforms.
> +
> +Unused session should be free using ``rte_cryptodev_sym_session_free``
> +which returns them to their mempool.

s/free/freed/


Apart from these small changes which could be made inline:

Acked-by: John McNamara 





Re: [dpdk-dev] [PATCH v9 06/20] doc: add ethtool library documentation

2017-07-02 Thread Mcnamara, John


> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, June 30, 2017 5:51 PM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Stephen Hemminger
> ; Richardson, Bruce
> ; Burakov, Anatoly 
> Subject: [dpdk-dev] [PATCH v9 06/20] doc: add ethtool library
> documentation
> 
> Signed-off-by: Ferruh Yigit 


Acked-by: John McNamara 



Re: [dpdk-dev] [PATCH v9 07/20] doc: update ethtool sample app doc

2017-07-02 Thread Mcnamara, John


> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, June 30, 2017 5:51 PM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Stephen Hemminger
> ; Richardson, Bruce
> ; Burakov, Anatoly 
> Subject: [dpdk-dev] [PATCH v9 07/20] doc: update ethtool sample app doc
> 
> Signed-off-by: Ferruh Yigit 


Acked-by: John McNamara 




Re: [dpdk-dev] [PATCH v2] doc: document NIC features

2017-07-02 Thread Mcnamara, John


> -Original Message-
> From: Yigit, Ferruh
> Sent: Thursday, June 22, 2017 8:03 PM
> To: Mcnamara, John 
> Cc: dev@dpdk.org; Yigit, Ferruh ; Thomas Monjalon
> ; Olivier Matz 
> Subject: [PATCH v2] doc: document NIC features
> 
> Document NIC features, add more information about them and add more
> implementation related support.
> 
> Signed-off-by: Ferruh Yigit 

This is a good idea and a good start. I'll send you some additions you can use
for a V2. Agreed that it would be good to get more community input for this.


[dpdk-dev] [PATCH v3 0/7] service cores: cover letter

2017-07-02 Thread Harry van Haaren
This patchset introduces service cores to DPDK. A service core
is an lcore that performs functions to abstract away details of
differences in environment of the application.

An example is using the eventdev API, where either a software or hardware
PMD performs scheduling. In the case of the software PMD an lcore is
required to perform scheduling, which means application logic would have
to be aware of the PMD running under the API. To abstract away the
differences in HW / SW PMDs, service cores can run the SW PMD service
without application logic specifying the exact cores to use. Note that
eventdev is only one API that benefits; timers, interrupts handling,
statistics and monitoring, and a range of other infrastructure that
requires a slice of CPU time may all benefit from service cores.

The application is not obliged to manually use the service cores API,
however if an application wishes to use the service cores API for fine
grained control over how the services are run, this is possible. Deciding
between a performance threading-profile and scaled-down profile can be
achieved by advanced usage of service cores and setting the lcore mappings.

Finally, the last patch introduces how a PMD can register a service to run
a function. This is then available (along with any other registered services)
to be run by the service cores.

Regards, -Harry


v3:
- Added docs
- Added release notes
- Updated maintainers file
- Compile checks with devtools/test-build.sh
- Validated patches apply to latest dpdk/master
- Based on discussion, rte_service_iterate() is *not* included,
  but could be adding at a later date if use-cases require it.
- Future work includes enabling the eventdev_pipeline sample app, but there
  is still some churn there to enable both HW/SW PMDs seamlessly. Once sample
  app is enabled a service core walk-through with that sample app can be added
  to the docs, to provide a tutorial on service-core usage.


Harry van Haaren (7):
  service cores: header and implementation
  service cores: EAL init changes
  service cores: coremask parsing
  service cores: add unit tests
  service cores: enable event/sw with service
  maintainers: claim service cores
  doc: add service cores to doc and release notes

 MAINTAINERS|   6 +
 doc/api/doxy-api-index.md  |   1 +
 doc/guides/eventdevs/sw.rst|   4 +-
 doc/guides/prog_guide/index.rst|   1 +
 doc/guides/prog_guide/service_cores.rst|  81 +++
 doc/guides/rel_notes/release_17_08.rst |   8 +
 drivers/event/sw/sw_evdev.c|  32 +
 drivers/event/sw/sw_evdev.h|   3 +
 lib/librte_eal/bsdapp/eal/Makefile |   1 +
 lib/librte_eal/bsdapp/eal/eal.c|  22 +
 lib/librte_eal/bsdapp/eal/rte_eal_version.map  |  28 +
 lib/librte_eal/common/Makefile |   1 +
 lib/librte_eal/common/eal_common_lcore.c   |   1 +
 lib/librte_eal/common/eal_common_options.c |  77 +++
 lib/librte_eal/common/include/rte_eal.h|   4 +
 lib/librte_eal/common/include/rte_lcore.h  |   3 +-
 lib/librte_eal/common/include/rte_service.h| 298 +
 .../common/include/rte_service_private.h   | 118 
 lib/librte_eal/common/rte_service.c| 671 +
 lib/librte_eal/linuxapp/eal/Makefile   |   1 +
 lib/librte_eal/linuxapp/eal/eal.c  |  23 +
 lib/librte_eal/linuxapp/eal/eal_thread.c   |   9 +-
 lib/librte_eal/linuxapp/eal/rte_eal_version.map|  29 +
 test/test/Makefile |   2 +
 test/test/test_service_cores.c | 496 +++
 25 files changed, 1917 insertions(+), 3 deletions(-)
 create mode 100644 doc/guides/prog_guide/service_cores.rst
 create mode 100644 lib/librte_eal/common/include/rte_service.h
 create mode 100644 lib/librte_eal/common/include/rte_service_private.h
 create mode 100644 lib/librte_eal/common/rte_service.c
 create mode 100644 test/test/test_service_cores.c

-- 
2.7.4



[dpdk-dev] [PATCH v3 2/7] service cores: EAL init changes

2017-07-02 Thread Harry van Haaren
This commit shows the changes required in rte_eal_init()
to transparently launch the service threads. The threads
are launched into the service worker functions here because
after rte_eal_init() the application is not gauranteed to
call any other DPDK API.

As the registration of services happens at initialization
time, the services that require CPU time are already available
when we reach the end of rte_eal_init().

Signed-off-by: Harry van Haaren 

---

v2 comments:
- Include BSD implementation (Jerin)
- Move details of core-tracking into rte_service_lcore_add(Jerin)
- Given there are changes other to suggested, not using Ack
---
 lib/librte_eal/bsdapp/eal/eal.c   | 22 ++
 lib/librte_eal/linuxapp/eal/eal.c | 23 +++
 2 files changed, 45 insertions(+)

diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 05f0c1f..4f7dcb3 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -653,6 +653,17 @@ rte_eal_init(int argc, char **argv)
rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
rte_eal_mp_wait_lcore();
 
+   /* initialize services first so vdevs can register during bus_probe.
+* Ignore return value of already initialized, this means EAL parameter
+* -s was used to set a service-core mask.
+*/
+   ret = rte_service_init();
+   if (ret) {
+   rte_eal_init_alert("rte_service_init() failed\n");
+   rte_errno = ENOEXEC;
+   return -1;
+   }
+
/* Probe all the buses and devices/drivers on them */
if (rte_bus_probe()) {
rte_eal_init_alert("Cannot probe devices\n");
@@ -660,6 +671,17 @@ rte_eal_init(int argc, char **argv)
return -1;
}
 
+   /* initialize default services configuration */
+   uint32_t service_cores[RTE_MAX_LCORE];
+   int count = rte_service_lcore_list(service_cores, RTE_MAX_LCORE);
+   for (i = 0; i < count; i++)
+   rte_service_lcore_start(service_cores[i]);
+   ret = rte_service_set_default_mapping();
+   if (ret) {
+   rte_errno = ENOEXEC;
+   return -1;
+   }
+
rte_eal_mcfg_complete();
 
return fctret;
diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 7c78f2d..d63dd87 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -78,6 +78,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "eal_private.h"
 #include "eal_thread.h"
@@ -932,6 +933,17 @@ rte_eal_init(int argc, char **argv)
rte_eal_mp_remote_launch(sync_func, NULL, SKIP_MASTER);
rte_eal_mp_wait_lcore();
 
+   /* initialize services first so vdevs can register during bus_probe.
+* Ignore return value of already initialized, this means EAL parameter
+* -s was used to set a service-core mask.
+*/
+   ret = rte_service_init();
+   if (ret) {
+   rte_eal_init_alert("rte_service_init() failed\n");
+   rte_errno = ENOEXEC;
+   return -1;
+   }
+
/* Probe all the buses and devices/drivers on them */
if (rte_bus_probe()) {
rte_eal_init_alert("Cannot probe devices\n");
@@ -939,6 +951,17 @@ rte_eal_init(int argc, char **argv)
return -1;
}
 
+   /* initialize default services configuration */
+   uint32_t service_cores[RTE_MAX_LCORE];
+   int count = rte_service_lcore_list(service_cores, RTE_MAX_LCORE);
+   for (i = 0; i < count; i++)
+   rte_service_lcore_start(service_cores[i]);
+   ret = rte_service_set_default_mapping();
+   if (ret) {
+   rte_errno = ENOEXEC;
+   return -1;
+   }
+
rte_eal_mcfg_complete();
 
return fctret;
-- 
2.7.4



[dpdk-dev] [PATCH v3 1/7] service cores: header and implementation

2017-07-02 Thread Harry van Haaren
Add header files, update .map files with new service
functions, and add the service header to the doxygen
for building.

This service header API allows DPDK to use services as
a concept of something that requires CPU cycles. An example
is a PMD that runs in software to schedule events, where a
hardware version exists that does not require a CPU.

The code presented here is based on an initial RFC:
http://dpdk.org/ml/archives/dev/2017-May/065207.html
This was then reworked, and RFC v2 with the changes posted:
http://dpdk.org/ml/archives/dev/2017-June/067194.html

This is the fourth iteration of the service core concept,
with 2 RFCs and this being v2 of the implementation.

Signed-off-by: Harry van Haaren 

---

v2:
Thanks Jerin for review - below a list your suggested changes;
- Doxygen rename to "service cores" for consistency
- use lcore instead of core for function names
- Fix about 10 typos / seplling msitakse ;)
- Dix doxygen /** comments for functions
- Doxygen @param[out] improvements
- int8_t for socket_id to ordinary int
- Rename MACROS for readability
- Align structs to cache lines
- Allocate fastpath-used data from hugepages
- Added/fixed memory barriers for multi-core scheduling
- Add const to variables, and hoist above loop
- Optimize cmpset atomic if MT_SAFE or only one core mapped
- Statistics collection only when requested
- Add error check for array pointer
- Remove panic() calls from library
- Fix TODO notes from previous patchset

There are also some other changes;
- Checkpatch issues fixed
- .map file updates
- Add rte_service_get_by_name() function
---
 doc/api/doxy-api-index.md  |   1 +
 lib/librte_eal/bsdapp/eal/Makefile |   1 +
 lib/librte_eal/bsdapp/eal/rte_eal_version.map  |  28 +
 lib/librte_eal/common/Makefile |   1 +
 lib/librte_eal/common/eal_common_lcore.c   |   1 +
 lib/librte_eal/common/include/rte_eal.h|   4 +
 lib/librte_eal/common/include/rte_lcore.h  |   3 +-
 lib/librte_eal/common/include/rte_service.h| 298 +
 .../common/include/rte_service_private.h   | 118 
 lib/librte_eal/common/rte_service.c| 671 +
 lib/librte_eal/linuxapp/eal/Makefile   |   1 +
 lib/librte_eal/linuxapp/eal/eal_thread.c   |   9 +-
 lib/librte_eal/linuxapp/eal/rte_eal_version.map|  29 +
 13 files changed, 1163 insertions(+), 2 deletions(-)
 create mode 100644 lib/librte_eal/common/include/rte_service.h
 create mode 100644 lib/librte_eal/common/include/rte_service_private.h
 create mode 100644 lib/librte_eal/common/rte_service.c

diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index f5f1f19..1284402 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -158,6 +158,7 @@ There are many libraries, so their headers may be grouped 
by topics:
   [common] (@ref rte_common.h),
   [ABI compat] (@ref rte_compat.h),
   [keepalive]  (@ref rte_keepalive.h),
+  [service cores]  (@ref rte_service.h),
   [device metrics] (@ref rte_metrics.h),
   [bitrate statistics] (@ref rte_bitrate.h),
   [latency statistics] (@ref rte_latencystats.h),
diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index a0f9950..05517a2 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -87,6 +87,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += rte_malloc.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += malloc_elem.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += malloc_heap.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += rte_keepalive.c
+SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += rte_service.c
 
 # from arch dir
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += rte_cpuflags.c
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 2e48a73..5493a13 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -193,3 +193,31 @@ DPDK_17.05 {
vfio_get_group_no;
 
 } DPDK_17.02;
+
+DPDK_17.08 {
+   global:
+
+   rte_service_disable_on_lcore;
+   rte_service_dump;
+   rte_service_enable_on_lcore;
+   rte_service_get_by_id;
+   rte_service_get_by_name;
+   rte_service_get_count;
+   rte_service_get_enabled_on_lcore;
+   rte_service_is_running;
+   rte_service_lcore_add;
+   rte_service_lcore_count;
+   rte_service_lcore_del;
+   rte_service_lcore_list;
+   rte_service_lcore_reset_all;
+   rte_service_lcore_start;
+   rte_service_lcore_stop;
+   rte_service_probe_capability;
+   rte_service_register;
+   rte_service_reset;
+   rte_service_set_stats_enable;
+   rte_service_start;
+   rte_service_stop;
+   rte_service_unregister;
+
+} DPDK_17.05;
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index a5bd108..2a93397 100644
--- a/lib/lib

[dpdk-dev] [PATCH v3 3/7] service cores: coremask parsing

2017-07-02 Thread Harry van Haaren
Add logic for parsing a coremask from EAL, which allows
the application to be unaware of the cores being taken from
its coremask.

Signed-off-by: Harry van Haaren 

Acked-by: Jerin Jacob 

---

v2:
- Remove printf() (Jerin)
- Remove commented code (Jerin)
- simplified core tracking, no requirement on
  #include rte_service in EAL parsing anymore.
---
 lib/librte_eal/common/eal_common_options.c | 77 ++
 1 file changed, 77 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index f470195..cee200c 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -61,6 +61,7 @@ const char
 eal_short_options[] =
"b:" /* pci-blacklist */
"c:" /* coremask */
+   "s:" /* service coremask */
"d:" /* driver */
"h"  /* help */
"l:" /* corelist */
@@ -267,6 +268,73 @@ static int xdigit2val(unsigned char c)
 }
 
 static int
+eal_parse_service_coremask(const char *coremask)
+{
+   struct rte_config *cfg = rte_eal_get_configuration();
+   int i, j, idx = 0;
+   unsigned int count = 0;
+   char c;
+   int val;
+
+   if (coremask == NULL)
+   return -1;
+   /* Remove all blank characters ahead and after .
+* Remove 0x/0X if exists.
+*/
+   while (isblank(*coremask))
+   coremask++;
+   if (coremask[0] == '0' && ((coremask[1] == 'x')
+   || (coremask[1] == 'X')))
+   coremask += 2;
+   i = strlen(coremask);
+   while ((i > 0) && isblank(coremask[i - 1]))
+   i--;
+
+   if (i == 0)
+   return -1;
+
+   for (i = i - 1; i >= 0 && idx < RTE_MAX_LCORE; i--) {
+   c = coremask[i];
+   if (isxdigit(c) == 0) {
+   /* invalid characters */
+   return -1;
+   }
+   val = xdigit2val(c);
+   for (j = 0; j < BITS_PER_HEX && idx < RTE_MAX_LCORE;
+   j++, idx++) {
+   if ((1 << j) & val) {
+   /* handle master lcore already parsed */
+   uint32_t lcore = idx;
+   if (master_lcore_parsed &&
+   cfg->master_lcore == lcore)
+   continue;
+
+   if (!lcore_config[idx].detected) {
+   RTE_LOG(ERR, EAL,
+   "lcore %u unavailable\n", idx);
+   return -1;
+   }
+   lcore_config[idx].core_role = ROLE_SERVICE;
+   count++;
+   }
+   }
+   }
+
+   for (; i >= 0; i--)
+   if (coremask[i] != '0')
+   return -1;
+
+   for (; idx < RTE_MAX_LCORE; idx++)
+   lcore_config[idx].core_index = -1;
+
+   if (count == 0)
+   return -1;
+
+   cfg->service_lcore_count = count;
+   return 0;
+}
+
+static int
 eal_parse_coremask(const char *coremask)
 {
struct rte_config *cfg = rte_eal_get_configuration();
@@ -409,6 +477,8 @@ eal_parse_master_lcore(const char *arg)
if (cfg->master_lcore >= RTE_MAX_LCORE)
return -1;
master_lcore_parsed = 1;
+   /* ensure master core is not used as service core */
+   lcore_config[cfg->master_lcore].core_role = ROLE_RTE;
return 0;
 }
 
@@ -826,6 +896,13 @@ eal_parse_common_option(int opt, const char *optarg,
}
core_parsed = 1;
break;
+   /* service coremask */
+   case 's':
+   if (eal_parse_service_coremask(optarg) < 0) {
+   RTE_LOG(ERR, EAL, "invalid service coremask\n");
+   return -1;
+   }
+   break;
/* size of memory */
case 'm':
conf->memory = atoi(optarg);
-- 
2.7.4



[dpdk-dev] [PATCH v3 5/7] service cores: enable event/sw with service

2017-07-02 Thread Harry van Haaren
This commit shows how easy it is to enable a specific
DPDK component with a service callback, in order to get
CPU cycles for it.

The beauty of this method is that the service is unaware
of how much CPU time it is getting - the application can
decide how to split and slice cores and map them to the
registered services.

Signed-off-by: Harry van Haaren 

---

v2:
- Remove #include  (Jerin)
- Remove development prints (Jerin)
- Track service name in PMD
- Print warning if service does not have an lcore mapped (Jerin)
---
 drivers/event/sw/sw_evdev.c | 32 
 drivers/event/sw/sw_evdev.h |  3 +++
 2 files changed, 35 insertions(+)

diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index fe2a61e..baab376 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sw_evdev.h"
 #include "iq_ring.h"
@@ -597,6 +598,13 @@ sw_start(struct rte_eventdev *dev)
 {
unsigned int i, j;
struct sw_evdev *sw = sw_pmd_priv(dev);
+
+   /* check a service core is mapped to this service */
+   struct rte_service_spec *s = rte_service_get_by_name(sw->service_name);
+   if (!rte_service_is_running(s))
+   SW_LOG_ERR("Warning: No Service core enabled on service %s\n",
+   s->name);
+
/* check all ports are set up */
for (i = 0; i < sw->port_count; i++)
if (sw->ports[i].rx_worker_ring == NULL) {
@@ -699,6 +707,14 @@ set_credit_quanta(const char *key __rte_unused, const char 
*value, void *opaque)
return 0;
 }
 
+
+static int32_t sw_sched_service_func(void *args)
+{
+   struct rte_eventdev *dev = args;
+   sw_event_schedule(dev);
+   return 0;
+}
+
 static int
 sw_probe(struct rte_vdev_device *vdev)
 {
@@ -810,6 +826,22 @@ sw_probe(struct rte_vdev_device *vdev)
sw->credit_update_quanta = credit_quanta;
sw->sched_quanta = sched_quanta;
 
+   /* register service with EAL */
+   struct rte_service_spec service;
+   memset(&service, 0, sizeof(struct rte_service_spec));
+   snprintf(service.name, sizeof(service.name), "%s_service", name);
+   snprintf(sw->service_name, sizeof(sw->service_name), "%s_service",
+   name);
+   service.socket_id = socket_id;
+   service.callback = sw_sched_service_func;
+   service.callback_userdata = (void *)dev;
+
+   int32_t ret = rte_service_register(&service);
+   if (ret) {
+   SW_LOG_ERR("service register() failed");
+   return -ENOEXEC;
+   }
+
return 0;
 }
 
diff --git a/drivers/event/sw/sw_evdev.h b/drivers/event/sw/sw_evdev.h
index 0d7f94f..3e83823 100644
--- a/drivers/event/sw/sw_evdev.h
+++ b/drivers/event/sw/sw_evdev.h
@@ -59,6 +59,7 @@
 
 #define EVENTDEV_NAME_SW_PMD event_sw
 #define SW_PMD_NAME RTE_STR(event_sw)
+#define SW_PMD_NAME_MAX 64
 
 #define SW_SCHED_TYPE_DIRECT (RTE_SCHED_TYPE_PARALLEL + 1)
 
@@ -276,6 +277,8 @@ struct sw_evdev {
/* store num stats and offset of the stats for each queue */
uint16_t xstats_count_per_qid[RTE_EVENT_MAX_QUEUES_PER_DEV];
uint16_t xstats_offset_for_qid[RTE_EVENT_MAX_QUEUES_PER_DEV];
+
+   char service_name[SW_PMD_NAME_MAX];
 };
 
 static inline struct sw_evdev *
-- 
2.7.4



[dpdk-dev] [PATCH v3 4/7] service cores: add unit tests

2017-07-02 Thread Harry van Haaren
Add a bunch of unit tests, to ensure that the service
core functions are operating as expected.

As part of these tests a dummy service is registered which
allows identifying if a service callback has been invoked
by using the CPU tick counter. This allows identifying if
functions to start and stop service lcores are actually having
effect.

Signed-off-by: Harry van Haaren 

---

v2 changes;
- Rename variable to slcore_id (Jerin)
- Rename function to unregister_all() (Jerin)
- Fix typos (Jerin)
- Add unit test for get_by_name()
- Add unit tests (all suggestions by Jerin)
-- get_name()
-- Verify probe_capability API
-- Verify MT_SAFE capability (see code for details)
-- Verify rte_service_dump() API
---
 test/test/Makefile |   2 +
 test/test/test_service_cores.c | 496 +
 2 files changed, 498 insertions(+)
 create mode 100644 test/test/test_service_cores.c

diff --git a/test/test/Makefile b/test/test/Makefile
index ee240be..61e296b 100644
--- a/test/test/Makefile
+++ b/test/test/Makefile
@@ -151,6 +151,8 @@ SRCS-y += test_interrupts.c
 SRCS-y += test_version.c
 SRCS-y += test_func_reentrancy.c
 
+SRCS-y += test_service_cores.c
+
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline.c
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_num.c
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_etheraddr.c
diff --git a/test/test/test_service_cores.c b/test/test/test_service_cores.c
new file mode 100644
index 000..f2f3a93
--- /dev/null
+++ b/test/test/test_service_cores.c
@@ -0,0 +1,496 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2017 Intel Corporation. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "test.h"
+
+/* used as the service core ID */
+static uint32_t slcore_id;
+/* used as timestamp to detect if a service core is running */
+static uint64_t service_tick;
+
+#define SERVICE_DELAY 1
+
+#define DUMMY_SERVICE_NAME "dummy_service"
+#define MT_SAFE_SERVICE_NAME "mt_safe_service"
+
+static int
+testsuite_setup(void)
+{
+   /* assuming lcore 1 is available for service-core testing */
+   slcore_id = 1;
+   return TEST_SUCCESS;
+}
+
+static void
+testsuite_teardown(void)
+{
+   /* release service cores? */
+}
+
+static int32_t dummy_cb(void *args)
+{
+   RTE_SET_USED(args);
+   service_tick++;
+   rte_delay_ms(SERVICE_DELAY);
+   return 0;
+}
+
+
+static int32_t dummy_mt_safe_cb(void *args)
+{
+   /* Atomic checks to ensure MT safe services allow > 1 thread to
+* concurrently run the callback. The concept is as follows;
+* 1) if lock is available, take the lock then delay
+* 2) if first lock is taken, and a thread arrives in the CB, we know
+*that 2 threads are running the callback at the same time: MT safe
+*/
+   uint32_t *test_params = args;
+   uint32_t *atomic_lock = &test_params[0];
+   uint32_t *pass_test = &test_params[1];
+   int lock_taken = rte_atomic32_cmpset(atomic_lock, 0, 1);
+   if (lock_taken) {
+   /* delay with the lock held */
+   rte_delay_ms(250);
+   rte_atomic32_clear((rte_atomic32_t *)atomic_lock);
+   } else {
+   /* 2nd thread will fail to take lock, so set pass flag */
+   *pass_test = 1;
+   }
+
+   return 0;
+

[dpdk-dev] [PATCH v3 7/7] doc: add service cores to doc and release notes

2017-07-02 Thread Harry van Haaren
Add a section describing the fundamental concepts behind service
cores. Where service cores originate from, and how to enable services.
The release notes for 17.08 are updated, with an introductory paragraph
on the service cores concept. Finally the Eventdev SW PMD documentation
is amended to reflect that it can be run as a service.

Signed-off-by: Harry van Haaren 

---

I would like to enable the service-cores in the eventdev_pipeline
sample app, to showcase the power of the service-core abstraction.
There is some remaining work TODO, in order to genericise the sample
app for both HW and SW PMDs, and during that rework the service-cores
can be added too.

The sample app will make a good showcase for docs, and make it much
easier to understand.
---
 doc/guides/eventdevs/sw.rst |  4 +-
 doc/guides/prog_guide/index.rst |  1 +
 doc/guides/prog_guide/service_cores.rst | 81 +
 doc/guides/rel_notes/release_17_08.rst  |  8 
 4 files changed, 93 insertions(+), 1 deletion(-)
 create mode 100644 doc/guides/prog_guide/service_cores.rst

diff --git a/doc/guides/eventdevs/sw.rst b/doc/guides/eventdevs/sw.rst
index fb63c84..a3e6624 100644
--- a/doc/guides/eventdevs/sw.rst
+++ b/doc/guides/eventdevs/sw.rst
@@ -32,7 +32,9 @@ Software Eventdev Poll Mode Driver
 
 The software eventdev is an implementation of the eventdev API, that provides a
 wide range of the eventdev features. The eventdev relies on a CPU core to
-perform event scheduling.
+perform event scheduling. This PMD can use the service core library to run the
+scheduling function, allowing an application to utilize the power of service
+cores to multiplex other work on the same core if required.
 
 
 Features
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index ef5a02a..231622a 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -38,6 +38,7 @@ Programmer's Guide
 intro
 overview
 env_abstraction_layer
+service_cores
 ring_lib
 mempool_lib
 mbuf_lib
diff --git a/doc/guides/prog_guide/service_cores.rst 
b/doc/guides/prog_guide/service_cores.rst
new file mode 100644
index 000..3a029ba
--- /dev/null
+++ b/doc/guides/prog_guide/service_cores.rst
@@ -0,0 +1,81 @@
+..  BSD LICENSE
+Copyright(c) 2017 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Service Cores
+=
+
+DPDK has a concept known as service cores, which enables a dynamic way of
+performing work on DPDK lcores. Service core support is built into the EAL, and
+an API is provided to optionally allow applications to control how the service
+cores are used at runtime.
+
+The service cores concept is built up out of services (components of DPDK that
+require CPU cycles to operate) and service cores (DPDK lcores, tasked with
+running services). The power of the service core concept is that the mapping
+between service cores and services can be configured to abstract away the
+difference between platforms and environments.
+
+For example, the Eventdev has hardware and software PMDs. Of these the software
+PMD requires an lcore to perform the scheduling operations, while the hardware
+PMD does not. With service cores, the application would not directly notice
+that the scheduling is done in software.
+
+For detailed information about the service core API, please refer to the docs.
+
+Service Core Initialization
+

[dpdk-dev] [PATCH v3 6/7] maintainers: claim service cores

2017-07-02 Thread Harry van Haaren
Sign-up to be the maintainer of public header files and
implementation of the service-cores infrastructure.

Signed-off-by: Harry van Haaren 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 00351ff..2e5081c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -134,6 +134,12 @@ F: test/test/test_mp_secondary.c
 F: examples/multi_process/
 F: doc/guides/sample_app_ug/multi_process.rst
 
+Service Cores
+M: Harry van Haaren 
+F: lib/librte_eal/common/include/rte_service.h
+F: lib/librte_eal/common/include/rte_service_private.h
+F: lib/librte_eal/common/rte_keepalive.c
+
 ARM v7
 M: Jan Viktorin 
 M: Jianbo Liu 
-- 
2.7.4



Re: [dpdk-dev] [PATCH v3 7/7] doc: add service cores to doc and release notes

2017-07-02 Thread Mcnamara, John


> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Harry van Haaren
> Sent: Sunday, July 2, 2017 10:35 PM
> To: dev@dpdk.org
> Cc: jerin.ja...@caviumnetworks.com; tho...@monjalon.net; Wiles, Keith
> ; Richardson, Bruce ;
> Van Haaren, Harry 
> Subject: [dpdk-dev] [PATCH v3 7/7] doc: add service cores to doc and
> release notes
> 
> Add a section describing the fundamental concepts behind service cores.
> Where service cores originate from, and how to enable services.
> The release notes for 17.08 are updated, with an introductory paragraph on
> the service cores concept. Finally the Eventdev SW PMD documentation is
> amended to reflect that it can be run as a service.
> 
> Signed-off-by: Harry van Haaren 

Acked-by: John McNamara 



Re: [dpdk-dev] [PATCH 0/5] crypto/dpaa2_sec optimization and feature update

2017-07-02 Thread De Lara Guarch, Pablo


> -Original Message-
> From: akhil.go...@nxp.com [mailto:akhil.go...@nxp.com]
> Sent: Thursday, June 29, 2017 9:49 PM
> To: dev@dpdk.org
> Cc: hemant.agra...@nxp.com; De Lara Guarch, Pablo
> ; Doherty, Declan
> ; Akhil Goyal 
> Subject: [PATCH 0/5] crypto/dpaa2_sec optimization and feature update
> 
> From: Akhil Goyal 
> 
> This patchset updates dpaa2_sec crypto driver with following:
> - optimization in data path for memory allocation
> - add support for additional AES algorithms like AES-GCM and AES-CTR
> - Update test cases in test_cryptodev for all the supported test cases.
> - Update documentation for supported algorithms
> 
> The patches are based on dpdk-crypto-next and are rebased over the latest
> crypto restructuring changes by Pablo.
> http://dpdk.org/ml/archives/dev/2017-June/069372.html
> 
> 
> Akhil Goyal (5):
>   crypto/dpaa2_sec: add per device mempool to store frame list entries
>   crypto/dpaa2_sec: add descriptor support for gcm and ctr
>   crypto/dpaa2_sec: add support for AES-GCM and CTR
>   test/test: add test cases for gcm and ctr in dpaa2_sec test suite
>   doc: update documentation for dpaa2_sec supported algos
> 
>  doc/guides/cryptodevs/dpaa2_sec.rst  |   9 +-
>  doc/guides/cryptodevs/features/dpaa2_sec.ini |   6 +
>  drivers/bus/fslmc/portal/dpaa2_hw_pvt.h  |   7 +
>  drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c  | 384
> ---
>  drivers/crypto/dpaa2_sec/dpaa2_sec_priv.h| 100 ---
>  drivers/crypto/dpaa2_sec/hw/desc/algo.h  | 226 +++-
>  drivers/crypto/dpaa2_sec/hw/desc/ipsec.h |  19 +-
>  test/test/test_cryptodev.c   |  94 ++-
>  test/test/test_cryptodev_aes_test_vectors.h  |  78 --
>  test/test/test_cryptodev_blockcipher.c   |   1 +
>  test/test/test_cryptodev_des_test_vectors.h  |  24 +-
> test/test/test_cryptodev_hash_test_vectors.h |  36 ++-
>  12 files changed, 846 insertions(+), 138 deletions(-)
> 
> --
> 2.9.3

Hi Akhil,

There are some issues with check-git-log.sh on your patches.

Wrong headline format:
test/test: add test cases for gcm and ctr in dpaa2_sec test suite
Wrong headline prefix:
crypto/dpaa2_sec: add per device mempool to store frame list entries
Wrong headline lowercase:
crypto/dpaa2_sec: add hw desc support for CTR
crypto/dpaa2_sec: add hw desc support for AES-GCM
Headline too long:
crypto/dpaa2_sec: add per device mempool to store frame list entries
test/test: add test cases for gcm and ctr in dpaa2_sec test suite

For the first patch, change from "test/test: " to "test/crypto..." too.
Also, you can probably merge the last two patches, as you are adding existing 
tests to the dpaa2 testsuite,
for the changes made in patch 4.

Lastly, I submitted a v4 for the crypto rework, so make sure you rebase on top 
of this patchset
before sending a v2.

Thanks!
Pablo



[dpdk-dev] [PATCH v3 03/12] cryptodev: add private session size retrieval function

2017-07-02 Thread Pablo de Lara
From: Slawomir Mrozowicz 

Provide a function to get the private session size
of any crypto device (specifically, to its crypto driver).

This will be useful once the session mempool is created
outside the library.

Signed-off-by: Slawomir Mrozowicz 
Signed-off-by: Pablo de Lara 
---
 lib/librte_cryptodev/rte_cryptodev.c   | 20 
 lib/librte_cryptodev/rte_cryptodev.h   | 12 
 lib/librte_cryptodev/rte_cryptodev_version.map |  1 +
 3 files changed, 33 insertions(+)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index c914fd4..cb6f5ec 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -1217,6 +1217,26 @@ rte_cryptodev_sym_session_free(uint8_t dev_id,
return NULL;
 }
 
+unsigned int
+rte_cryptodev_get_private_session_size(uint8_t dev_id)
+{
+   struct rte_cryptodev *dev;
+   unsigned int priv_sess_size;
+
+   if (!rte_cryptodev_pmd_is_valid_dev(dev_id))
+   return 0;
+
+   dev = rte_cryptodev_pmd_get_dev(dev_id);
+
+   if (*dev->dev_ops->session_get_size == NULL)
+   return 0;
+
+   priv_sess_size = (*dev->dev_ops->session_get_size)(dev);
+
+   return priv_sess_size;
+
+}
+
 /** Initialise rte_crypto_op mempool element */
 static void
 rte_crypto_op_init(struct rte_mempool *mempool,
diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index ba51329..d883d8c 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -856,6 +856,18 @@ rte_cryptodev_sym_session_free(uint8_t dev_id,
struct rte_cryptodev_sym_session *session);
 
 /**
+ * Get the size of the private session data for a device.
+ *
+ * @param  dev_id  The device identifier.
+ *
+ * @return
+ *   - Size of the private data, if successful
+ *   - 0 if device is invalid or does not have private session
+ */
+unsigned int
+rte_cryptodev_get_private_session_size(uint8_t dev_id);
+
+/**
  * Attach queue pair with sym session.
  *
  * @param  qp_id   Queue pair to which session will be attached.
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map 
b/lib/librte_cryptodev/rte_cryptodev_version.map
index afe148a..8855a34 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -65,6 +65,7 @@ DPDK_17.08 {
rte_cryptodev_device_count_by_driver;
rte_cryptodev_driver_id_get;
rte_cryptodev_driver_name_get;
+   rte_cryptodev_get_private_session_size;
rte_cryptodev_pci_generic_probe;
rte_cryptodev_pci_generic_remove;
rte_cryptodev_vdev_parse_init_params;
-- 
2.9.4



[dpdk-dev] [PATCH v3 01/12] cryptodev: remove unused cryptodev session structure

2017-07-02 Thread Pablo de Lara
Cryptodev session structure was a duplication of the
cryptodev symmetric structure.
It was used by some PMDs that should use the symmetric
structure instead.

Since this structure was internal, there is no deprecation
notice required.

Signed-off-by: Pablo de Lara 
---
 drivers/crypto/kasumi/rte_kasumi_pmd.c   |  2 +-
 drivers/crypto/null/null_crypto_pmd.c|  2 +-
 drivers/crypto/snow3g/rte_snow3g_pmd.c   |  2 +-
 drivers/crypto/zuc/rte_zuc_pmd.c |  2 +-
 examples/ipsec-secgw/ipsec.h |  1 -
 lib/librte_cryptodev/rte_cryptodev_pmd.h | 11 ---
 6 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c 
b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index 648718c..a1a33c5 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -152,7 +152,7 @@ kasumi_get_session(struct kasumi_qp *qp, struct 
rte_crypto_op *op)
 
sess = (struct kasumi_session *)op->sym->session->_private;
} else  {
-   struct rte_cryptodev_session *c_sess = NULL;
+   struct rte_cryptodev_sym_session *c_sess = NULL;
 
if (rte_mempool_get(qp->sess_mp, (void **)&c_sess))
return NULL;
diff --git a/drivers/crypto/null/null_crypto_pmd.c 
b/drivers/crypto/null/null_crypto_pmd.c
index 7ab3570..50ede06 100644
--- a/drivers/crypto/null/null_crypto_pmd.c
+++ b/drivers/crypto/null/null_crypto_pmd.c
@@ -103,7 +103,7 @@ get_session(struct null_crypto_qp *qp, struct 
rte_crypto_sym_op *op)
 
sess = (struct null_crypto_session *)op->session->_private;
} else  {
-   struct rte_cryptodev_session *c_sess = NULL;
+   struct rte_cryptodev_sym_session *c_sess = NULL;
 
if (rte_mempool_get(qp->sess_mp, (void **)&c_sess))
return NULL;
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c 
b/drivers/crypto/snow3g/rte_snow3g_pmd.c
index fe074c1..35a2bcd 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
@@ -152,7 +152,7 @@ snow3g_get_session(struct snow3g_qp *qp, struct 
rte_crypto_op *op)
 
sess = (struct snow3g_session *)op->sym->session->_private;
} else  {
-   struct rte_cryptodev_session *c_sess = NULL;
+   struct rte_cryptodev_sym_session *c_sess = NULL;
 
if (rte_mempool_get(qp->sess_mp, (void **)&c_sess))
return NULL;
diff --git a/drivers/crypto/zuc/rte_zuc_pmd.c b/drivers/crypto/zuc/rte_zuc_pmd.c
index b7b8dfc..ff8f3b9 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd.c
@@ -151,7 +151,7 @@ zuc_get_session(struct zuc_qp *qp, struct rte_crypto_op *op)
 
sess = (struct zuc_session *)op->sym->session->_private;
} else  {
-   struct rte_cryptodev_session *c_sess = NULL;
+   struct rte_cryptodev_sym_session *c_sess = NULL;
 
if (rte_mempool_get(qp->sess_mp, (void **)&c_sess))
return NULL;
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index fe42661..1d63161 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -72,7 +72,6 @@
 
 struct rte_crypto_xform;
 struct ipsec_xform;
-struct rte_cryptodev_session;
 struct rte_mbuf;
 
 struct ipsec_sa;
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index f6aa84d..5911b83 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -56,17 +56,6 @@ extern "C" {
 #include "rte_crypto.h"
 #include "rte_cryptodev.h"
 
-struct rte_cryptodev_session {
-   RTE_STD_C11
-   struct {
-   uint8_t dev_id;
-   uint8_t driver_id;
-   struct rte_mempool *mp;
-   } __rte_aligned(8);
-
-   __extension__ char _private[0];
-};
-
 /** Global structure used for maintaining state of allocated crypto devices */
 struct rte_cryptodev_global {
struct rte_cryptodev *devs; /**< Device information array */
-- 
2.9.4



[dpdk-dev] [PATCH v3 00/12] Device independent crypto sessions

2017-07-02 Thread Pablo de Lara
Currently, the cryptodev library requires the session mempools
to be created inside each device.
This can be a waste of memory, as several devices with the same driver
could be using the same session.

This patchset makes changes in the library to allow session to contain multiple
driver private data, so it can be used by multiple devices (no need to be the 
same driver).

  SESSION MEMPOOL <---|---> DEVICE INSTANCES
 

.-.  ..
|   Crypto|. | mempool obj|
| sym-session |<--.  | .--+
|   mempool   ||  |  | | rte_cryptodev_session| .-.
`-'|  |  | |  | |   DEVICE|
 `-|---'  |  | |  | |  INSTANCE   |
   |  `-  | | - device id |
   +>| | - private data[type idx] |  .--| - session   |
   | `-+=|..|='  |  |   mempool   |
   | |  ||  `-'
   | |  ||
   | .--.|  ||  .-.
   +>|  mempool obj ||  |   ..   |  |   DEVICE|
   | | .+|  |   | DRIVER |   |  |  INSTANCE   |
   | | | PMD's private data |<---+--| - type |<--+--| |
   | +-++   |   `'  | ... |
   ||   | |
   ||   `-'
   ||
   | .--.   |   .-.
   `>|  mempool obj |   |   ..  |   DEVICE|
 | .+   |   | DRIVER |  |  INSTANCE   |
 | | PMD's private data |<--+---| - type |<-| |
 `-+'   `'  | ... |
| |
`-'
Crypto sym-session mempool

   Mempool created to store rte_cryptodev_session objects as well as
   private data for supported device types.

   This mempool replaces existing session mempools in device
   instances to ease session management and improve consistency
   (especially if the session is intended to be used for operations
   performed on different devices).

rte_crypto_session

   New rte_cryptodev_session structure is taken from crypto session
   mempool and can store more than one PMD's private data object (one
   for each device type supported by sesion).

   Crypto operations will use device type id (unique for each driver) to
   retrieve private data from rte_crypto_session right for the device
   type they are performed on.

This patchset was based on the changes proposed in RFC
(http://dpdk.org/ml/archives/dev/2017-May/065259.html)

This patchset depends on:
http://dpdk.org/dev/patchwork/patch/26156/

Changes in v3:

- Removed internal PMD's session initialize function

- Created session mempool in the right socket in
  the sample apps

- Get two objects (header and private data) from mempool
  when using sessionless operations, to get a complete
  session

- Fixed commit message (check-git-log failed)

- Added note of removed session_mp from rte_cryptodev_config
  in documentation

- Fixed minor issues in documentation


Changes in v2:

- Split the patch in multiple smaller patches to
  facilitate the review

- Removed new API to create the session mempool,
  since mempool can be created directly withe mempool_create

- Session headers and device private sessions can be
  allocated from different mempools, for better memory
  efficiency.

- Added a cover letter (partially extracted from RFC)
  for better clarification on the intention of this patchset

Pablo de Lara (5):
  cryptodev: remove unused cryptodev session structure
  cryptodev: move session init out of session pool creation
  cryptodev: add mempool pointer in queue pair setup
  cryptodev: remove session init internal function
  doc: add new crypto session information

Slawomir Mrozowicz (7):
  cryptodev: add private session size retrieval function
  cryptodev: do not create session mempool internally
  cryptodev: change attach session to queue pair API
  cryptodev: remove device id from crypto session
  cryptodev: remove driver id from session
  cryptodev: remove mempool from session
  cryptodev: support device independent sessions

 app/test-crypto-perf/cperf.h   |   5 +-
 app/t

[dpdk-dev] [PATCH v3 02/12] cryptodev: move session init out of session pool creation

2017-07-02 Thread Pablo de Lara
Prior to removing the session pool creation from cryptodev
configure function, session init function needs to be
separated from the pool creation.

Signed-off-by: Pablo de Lara 
---
 lib/librte_cryptodev/rte_cryptodev.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index 17f7c63..c914fd4 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -1030,13 +1030,9 @@ rte_cryptodev_pmd_callback_process(struct rte_cryptodev 
*dev,
 
 static void
 rte_cryptodev_sym_session_init(struct rte_mempool *mp,
-   void *opaque_arg,
-   void *_sess,
-   __rte_unused unsigned i)
+   const struct rte_cryptodev *dev,
+   struct rte_cryptodev_sym_session *sess)
 {
-   struct rte_cryptodev_sym_session *sess = _sess;
-   struct rte_cryptodev *dev = opaque_arg;
-
memset(sess, 0, mp->elt_size);
 
sess->dev_id = dev->data->dev_id;
@@ -1093,8 +1089,7 @@ rte_cryptodev_sym_session_pool_create(struct 
rte_cryptodev *dev,
0, /* private data size */
NULL, /* obj initialization constructor */
NULL, /* obj initialization constructor arg */
-   rte_cryptodev_sym_session_init,
-   /**< obj constructor*/
+   NULL, /**< obj constructor*/
dev, /* obj constructor arg */
socket_id, /* socket id */
0); /* flags */
@@ -1132,6 +1127,8 @@ rte_cryptodev_sym_session_create(uint8_t dev_id,
 
sess = _sess;
 
+   rte_cryptodev_sym_session_init(dev->data->session_pool, dev,
+   sess);
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->session_configure, NULL);
if (dev->dev_ops->session_configure(dev, xform, sess->_private) ==
NULL) {
-- 
2.9.4



[dpdk-dev] [PATCH v3 04/12] cryptodev: do not create session mempool internally

2017-07-02 Thread Pablo de Lara
From: Slawomir Mrozowicz 

Instead of creating the session mempool while configuring
the crypto device, apps will create the mempool themselves.
This way, it gives flexibility to the user to have a single
mempool for all devices (as long as the objects are big
enough to contain the biggest private session size) or
separate mempools for different drivers.

Also, since the mempool is now created outside the
device configuration function, now it needs to be passed
through this function, which will be eventually passed
when setting up the queue pairs, as ethernet devices do.

Signed-off-by: Slawomir Mrozowicz 
Signed-off-by: Pablo de Lara 
---
 app/test-crypto-perf/main.c  | 91 +---
 doc/guides/rel_notes/release_17_08.rst   |  3 +
 drivers/crypto/scheduler/scheduler_pmd_ops.c | 12 +---
 examples/ipsec-secgw/ipsec-secgw.c   | 42 +++--
 examples/ipsec-secgw/ipsec.h |  2 +
 examples/l2fwd-crypto/main.c | 65 
 lib/librte_cryptodev/rte_cryptodev.c | 77 ++-
 lib/librte_cryptodev/rte_cryptodev.h |  9 +--
 test/test/test_cryptodev.c   | 85 --
 test/test/test_cryptodev_perf.c  | 24 +++-
 10 files changed, 260 insertions(+), 150 deletions(-)

diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index 9ec2a4b..e013e82 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c
@@ -11,6 +11,9 @@
 #include "cperf_test_latency.h"
 #include "cperf_test_verify.h"
 
+#define NUM_SESSIONS 2048
+#define SESS_MEMPOOL_CACHE_SIZE 64
+
 const char *cperf_test_type_strs[] = {
[CPERF_TEST_TYPE_THROUGHPUT] = "throughput",
[CPERF_TEST_TYPE_LATENCY] = "latency",
@@ -44,9 +47,11 @@ const struct cperf_test cperf_testmap[] = {
 };
 
 static int
-cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs)
+cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs,
+   struct rte_mempool *session_pool_socket[])
 {
-   uint8_t cdev_id, enabled_cdev_count = 0, nb_lcores;
+   uint8_t enabled_cdev_count = 0, nb_lcores;
+   unsigned int i;
int ret;
 
enabled_cdev_count = rte_cryptodev_devices_get(opts->device_type,
@@ -66,40 +71,78 @@ cperf_initialize_cryptodev(struct cperf_options *opts, 
uint8_t *enabled_cdevs)
return -EINVAL;
}
 
-   for (cdev_id = 0; cdev_id < enabled_cdev_count &&
-   cdev_id < RTE_CRYPTO_MAX_DEVS; cdev_id++) {
+   /* Create a mempool shared by all the devices */
+   uint32_t max_sess_size = 0, sess_size;
+
+   for (i = 0; i < enabled_cdev_count &&
+   i < RTE_CRYPTO_MAX_DEVS; i++) {
+   uint8_t cdev_id = enabled_cdevs[i];
+   sess_size = sizeof(struct rte_cryptodev_sym_session) +
+   rte_cryptodev_get_private_session_size(cdev_id);
+   if (sess_size > max_sess_size)
+   max_sess_size = sess_size;
+   }
+
+
+   for (i = 0; i < enabled_cdev_count &&
+   i < RTE_CRYPTO_MAX_DEVS; i++) {
+   uint8_t cdev_id = enabled_cdevs[i];
+   uint8_t socket_id = rte_cryptodev_socket_id(cdev_id);
 
struct rte_cryptodev_config conf = {
.nb_queue_pairs = 1,
-   .socket_id = SOCKET_ID_ANY,
-   .session_mp = {
-   .nb_objs = 2048,
-   .cache_size = 64
-   }
-   };
+   .socket_id = socket_id
+   };
+
struct rte_cryptodev_qp_conf qp_conf = {
.nb_descriptors = 2048
};
 
-   ret = rte_cryptodev_configure(enabled_cdevs[cdev_id], &conf);
+
+   if (session_pool_socket[socket_id] == NULL) {
+   char mp_name[RTE_MEMPOOL_NAMESIZE];
+   struct rte_mempool *sess_mp;
+
+   snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
+   "sess_mp_%u", socket_id);
+
+   sess_mp = rte_mempool_create(mp_name,
+   NUM_SESSIONS,
+   max_sess_size,
+   SESS_MEMPOOL_CACHE_SIZE,
+   0, NULL, NULL, NULL,
+   NULL, socket_id,
+   0);
+
+   if (sess_mp == NULL) {
+   printf("Cannot create session pool on socket 
%d\n",
+   socket_id);
+  

[dpdk-dev] [PATCH v3 06/12] cryptodev: remove device id from crypto session

2017-07-02 Thread Pablo de Lara
From: Slawomir Mrozowicz 

Device id is necessary in the crypto session,
as it was only used for the functions that attach/detach
a session to a queue pair.

Since the session is not going to be attached to a device
anymore, this is field is no longer necessary.

Signed-off-by: Slawomir Mrozowicz 
Signed-off-by: Pablo de Lara 
---
 doc/guides/rel_notes/release_17_08.rst | 1 +
 lib/librte_cryptodev/rte_cryptodev.c   | 1 -
 lib/librte_cryptodev/rte_cryptodev.h   | 2 --
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index c7e58c6..f401ffb 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -163,6 +163,7 @@ API Changes
   * ``rte_cryptodev_queue_pair_attach_sym_session()`` and
 ``rte_cryptodev_queue_pair_dettach_sym_session()`` functions require
 the new parameter ``device id``.
+  * ``dev_id`` field has been removed from ``rte_cryptodev_sym_session`` 
structure.
 
 
 ABI Changes
diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index 477e28f..aa35b79 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -1026,7 +1026,6 @@ rte_cryptodev_sym_session_init(struct rte_mempool *mp,
 {
memset(sess, 0, mp->elt_size);
 
-   sess->dev_id = dev->data->dev_id;
sess->driver_id = dev->driver_id;
sess->mp = mp;
 
diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index d3d2794..77a763d 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -798,8 +798,6 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
 struct rte_cryptodev_sym_session {
RTE_STD_C11
struct {
-   uint8_t dev_id;
-   /**< Device Id */
uint8_t driver_id;
/** Crypto driver identifier session created on */
struct rte_mempool *mp;
-- 
2.9.4



[dpdk-dev] [PATCH v3 07/12] cryptodev: remove driver id from session

2017-07-02 Thread Pablo de Lara
From: Slawomir Mrozowicz 

Since crypto session will not be attached to a specific
device or driver, the field driver_id is not required
anymore (only used to check that a session was being
handled by the right device).

Signed-off-by: Slawomir Mrozowicz 
Signed-off-by: Pablo de Lara 
---
 doc/guides/rel_notes/release_17_08.rst | 1 +
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c   | 4 
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 5 -
 drivers/crypto/armv8/rte_armv8_pmd.c   | 4 +---
 drivers/crypto/kasumi/rte_kasumi_pmd.c | 4 
 drivers/crypto/null/null_crypto_pmd.c  | 3 +--
 drivers/crypto/openssl/rte_openssl_pmd.c   | 4 +---
 drivers/crypto/qat/qat_crypto.c| 6 --
 drivers/crypto/snow3g/rte_snow3g_pmd.c | 4 
 drivers/crypto/zuc/rte_zuc_pmd.c   | 4 
 lib/librte_cryptodev/rte_cryptodev.c   | 5 -
 lib/librte_cryptodev/rte_cryptodev.h   | 2 --
 12 files changed, 4 insertions(+), 42 deletions(-)

diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index f401ffb..b0657ec 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -164,6 +164,7 @@ API Changes
 ``rte_cryptodev_queue_pair_dettach_sym_session()`` functions require
 the new parameter ``device id``.
   * ``dev_id`` field has been removed from ``rte_cryptodev_sym_session`` 
structure.
+  * ``driver_id`` field has been removed from ``rte_cryptodev_sym_session`` 
structure.
 
 
 ABI Changes
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index ef290a3..2774b4e 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -146,10 +146,6 @@ aesni_gcm_get_session(struct aesni_gcm_qp *qp, struct 
rte_crypto_sym_op *op)
struct aesni_gcm_session *sess = NULL;
 
if (op->sess_type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
-   if (unlikely(op->session->driver_id !=
-   cryptodev_driver_id))
-   return sess;
-
sess = (struct aesni_gcm_session *)op->session->_private;
} else  {
void *_sess;
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index 4025978..ec348ab 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -348,11 +348,6 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op 
*op)
struct aesni_mb_session *sess = NULL;
 
if (op->sym->sess_type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
-   if (unlikely(op->sym->session->driver_id !=
-   cryptodev_driver_id)) {
-   return NULL;
-   }
-
sess = (struct aesni_mb_session *)op->sym->session->_private;
} else  {
void *_sess = NULL;
diff --git a/drivers/crypto/armv8/rte_armv8_pmd.c 
b/drivers/crypto/armv8/rte_armv8_pmd.c
index 9fe781b..1ddf6a2 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd.c
@@ -549,9 +549,7 @@ get_session(struct armv8_crypto_qp *qp, struct 
rte_crypto_op *op)
 
if (op->sym->sess_type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
/* get existing session */
-   if (likely(op->sym->session != NULL &&
-   op->sym->session->driver_id ==
-   cryptodev_driver_id)) {
+   if (likely(op->sym->session != NULL)) {
sess = (struct armv8_crypto_session *)
op->sym->session->_private;
}
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c 
b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index a1a33c5..67f0b06 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -146,10 +146,6 @@ kasumi_get_session(struct kasumi_qp *qp, struct 
rte_crypto_op *op)
struct kasumi_session *sess;
 
if (op->sym->sess_type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
-   if (unlikely(op->sym->session->driver_id !=
-   cryptodev_driver_id))
-   return NULL;
-
sess = (struct kasumi_session *)op->sym->session->_private;
} else  {
struct rte_cryptodev_sym_session *c_sess = NULL;
diff --git a/drivers/crypto/null/null_crypto_pmd.c 
b/drivers/crypto/null/null_crypto_pmd.c
index 50ede06..9323874 100644
--- a/drivers/crypto/null/null_crypto_pmd.c
+++ b/drivers/crypto/null/null_crypto_pmd.c
@@ -97,8 +97,7 @@ get_session(struct null_crypto_qp *qp, struct 
rte_crypto_sym_op *op)
struct null_crypto_session *sess;
 
if (op->sess_type == RTE_CRYPTO_SYM_OP_WITH_SESSION) {
-   if (unlikely(op->session == NULL || op->session->driver_id !=
-   cryptodev_driver_id))

[dpdk-dev] [PATCH v3 08/12] cryptodev: remove mempool from session

2017-07-02 Thread Pablo de Lara
From: Slawomir Mrozowicz 

Mempool pointer can be obtained from the object itself,
which means that it is not required to actually store the pointer
in the session.

Signed-off-by: Slawomir Mrozowicz 
Signed-off-by: Pablo de Lara 
---
 doc/guides/rel_notes/release_17_08.rst | 1 +
 lib/librte_cryptodev/rte_cryptodev.c   | 7 +++
 lib/librte_cryptodev/rte_cryptodev.h   | 6 --
 3 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index b0657ec..785489a 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -165,6 +165,7 @@ API Changes
 the new parameter ``device id``.
   * ``dev_id`` field has been removed from ``rte_cryptodev_sym_session`` 
structure.
   * ``driver_id`` field has been removed from ``rte_cryptodev_sym_session`` 
structure.
+  * Mempool pointer ``mp`` has been removed from ``rte_cryptodev_sym_session`` 
structure.
 
 
 ABI Changes
diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index b0b4816..5c7191b 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -1026,8 +1026,6 @@ rte_cryptodev_sym_session_init(struct rte_mempool *mp,
 {
memset(sess, 0, mp->elt_size);
 
-   sess->mp = mp;
-
if (dev->dev_ops->session_initialize)
(*dev->dev_ops->session_initialize)(mp, sess);
 }
@@ -1065,7 +1063,7 @@ rte_cryptodev_sym_session_create(uint8_t dev_id,
dev_id);
 
/* Return session to mempool */
-   rte_mempool_put(sess->mp, _sess);
+   rte_mempool_put(dev->data->session_pool, _sess);
return NULL;
}
 
@@ -1137,7 +1135,8 @@ rte_cryptodev_sym_session_free(uint8_t dev_id,
dev->dev_ops->session_clear(dev, (void *)sess->_private);
 
/* Return session to mempool */
-   rte_mempool_put(sess->mp, (void *)sess);
+   struct rte_mempool *mp = rte_mempool_from_obj(sess);
+   rte_mempool_put(mp, (void *)sess);
 
return NULL;
 }
diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index 7d574f1..044a4aa 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -797,12 +797,6 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
 /** Cryptodev symmetric crypto session */
 struct rte_cryptodev_sym_session {
RTE_STD_C11
-   struct {
-   struct rte_mempool *mp;
-   /**< Mempool session allocated from */
-   } __rte_aligned(8);
-   /**< Public symmetric session details */
-
__extension__ char _private[0];
/**< Private session material */
 };
-- 
2.9.4



[dpdk-dev] [PATCH v3 09/12] cryptodev: support device independent sessions

2017-07-02 Thread Pablo de Lara
From: Slawomir Mrozowicz 

Change crypto device's session management to make it
device independent and simplify architecture when session
is intended to be used on more than one device.

Sessions private data is agnostic to underlying device
by adding an indirection in the sessions private data
using the crypto driver identifier.
A single session can contain indirections to multiple device types.

New function rte_cryptodev_sym_session_init has been created,
to initialize the private data per driver to be used on
a same session.

Signed-off-by: Slawomir Mrozowicz 
Signed-off-by: Pablo de Lara 
---
 app/test-crypto-perf/cperf.h   |   5 +-
 app/test-crypto-perf/cperf_ops.c   |  30 +-
 app/test-crypto-perf/cperf_ops.h   |   1 +
 app/test-crypto-perf/cperf_test_latency.c  |   7 +-
 app/test-crypto-perf/cperf_test_latency.h  |   5 +-
 app/test-crypto-perf/cperf_test_throughput.c   |   7 +-
 app/test-crypto-perf/cperf_test_throughput.h   |   5 +-
 app/test-crypto-perf/cperf_test_verify.c   |   7 +-
 app/test-crypto-perf/cperf_test_verify.h   |   5 +-
 app/test-crypto-perf/main.c|   8 +-
 doc/guides/rel_notes/release_17_08.rst |   4 +
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c   |  60 ++--
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c   |  28 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c |  32 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  27 +-
 drivers/crypto/armv8/rte_armv8_pmd.c   |  37 ++-
 drivers/crypto/armv8/rte_armv8_pmd_ops.c   |  31 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c|  45 ++-
 drivers/crypto/kasumi/rte_kasumi_pmd.c |  42 ++-
 drivers/crypto/kasumi/rte_kasumi_pmd_ops.c |  28 +-
 drivers/crypto/null/null_crypto_pmd.c  |  41 ++-
 drivers/crypto/null/null_crypto_pmd_ops.c  |  31 +-
 drivers/crypto/openssl/rte_openssl_pmd.c   |  36 ++-
 drivers/crypto/openssl/rte_openssl_pmd_ops.c   |  28 +-
 drivers/crypto/qat/qat_crypto.c|  68 ++--
 drivers/crypto/qat/qat_crypto.h|  12 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   1 -
 drivers/crypto/scheduler/scheduler_failover.c  |  45 +--
 .../crypto/scheduler/scheduler_pkt_size_distr.c|  18 --
 drivers/crypto/scheduler/scheduler_pmd_ops.c   |  87 +++---
 drivers/crypto/scheduler/scheduler_pmd_private.h   |   4 -
 drivers/crypto/scheduler/scheduler_roundrobin.c|  41 ---
 drivers/crypto/snow3g/rte_snow3g_pmd.c |  42 ++-
 drivers/crypto/snow3g/rte_snow3g_pmd_ops.c |  28 +-
 drivers/crypto/zuc/rte_zuc_pmd.c   |  38 ++-
 drivers/crypto/zuc/rte_zuc_pmd_ops.c   |  28 +-
 examples/ipsec-secgw/ipsec-secgw.c |   3 +-
 examples/ipsec-secgw/ipsec.c   |   7 +-
 examples/l2fwd-crypto/main.c   |  17 +-
 lib/librte_cryptodev/rte_cryptodev.c   | 127 
 lib/librte_cryptodev/rte_cryptodev.h   |  65 ++--
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  24 +-
 lib/librte_cryptodev/rte_cryptodev_version.map |   2 +
 test/test/test_cryptodev.c | 344 ++---
 test/test/test_cryptodev_blockcipher.c |  15 +-
 test/test/test_cryptodev_blockcipher.h |   1 +
 test/test/test_cryptodev_perf.c| 173 +++
 47 files changed, 1106 insertions(+), 634 deletions(-)

diff --git a/app/test-crypto-perf/cperf.h b/app/test-crypto-perf/cperf.h
index 293ba94..c9f7f81 100644
--- a/app/test-crypto-perf/cperf.h
+++ b/app/test-crypto-perf/cperf.h
@@ -41,7 +41,10 @@ struct cperf_options;
 struct cperf_test_vector;
 struct cperf_op_fns;
 
-typedef void  *(*cperf_constructor_t)(uint8_t dev_id, uint16_t qp_id,
+typedef void  *(*cperf_constructor_t)(
+   struct rte_mempool *sess_mp,
+   uint8_t dev_id,
+   uint16_t qp_id,
const struct cperf_options *options,
const struct cperf_test_vector *t_vec,
const struct cperf_op_fns *op_fns);
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 17df2eb..82e5d60 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -331,14 +331,16 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
 }
 
 static struct rte_cryptodev_sym_session *
-cperf_create_session(uint8_t dev_id,
+cperf_create_session(struct rte_mempool *sess_mp,
+   uint8_t dev_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector)
 {
struct rte_crypto_sym_xform cipher_xform;
struct rte_crypto_sym_xform auth_xform;
-   struct rte_cryptodev_sym_session *sess = NULL;
+   struct rte_cryptodev_sym_session *sess;
 
+   sess = rte_cryptodev_sym_session_create(sess_mp

[dpdk-dev] [PATCH v3 05/12] cryptodev: change attach session to queue pair API

2017-07-02 Thread Pablo de Lara
From: Slawomir Mrozowicz 

Device id is going to be removed from session,
as the session will be device independent.
Therefore, the functions that attach/dettach a session
to a queue pair need to be updated, to accept the device id
as a parameter, apart from the queue pair id and the session.

Signed-off-by: Slawomir Mrozowicz 
Signed-off-by: Pablo de Lara 
---
 doc/guides/rel_notes/release_17_08.rst |  3 +++
 examples/ipsec-secgw/ipsec.c   |  1 +
 lib/librte_cryptodev/rte_cryptodev.c   | 20 ++--
 lib/librte_cryptodev/rte_cryptodev.h   | 10 ++
 4 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index 8cc01b2..c7e58c6 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -160,6 +160,9 @@ API Changes
   * ``rte_cryptodev_configure()`` does not create the session mempool
 for the device anymore.
   * Removed ``session_mp`` from ``rte_cryptodev_config``.
+  * ``rte_cryptodev_queue_pair_attach_sym_session()`` and
+``rte_cryptodev_queue_pair_dettach_sym_session()`` functions require
+the new parameter ``device id``.
 
 
 ABI Changes
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index edca5f0..048e441 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -77,6 +77,7 @@ create_session(struct ipsec_ctx *ipsec_ctx __rte_unused, 
struct ipsec_sa *sa)
rte_cryptodev_info_get(ipsec_ctx->tbl[cdev_id_qp].id, &cdev_info);
if (cdev_info.sym.max_nb_sessions_per_qp > 0) {
ret = rte_cryptodev_queue_pair_attach_sym_session(
+   ipsec_ctx->tbl[cdev_id_qp].id,
ipsec_ctx->tbl[cdev_id_qp].qp,
sa->crypto_session);
if (ret < 0) {
diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index dd10b99..477e28f 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -1075,23 +1075,23 @@ rte_cryptodev_sym_session_create(uint8_t dev_id,
 }
 
 int
-rte_cryptodev_queue_pair_attach_sym_session(uint16_t qp_id,
+rte_cryptodev_queue_pair_attach_sym_session(uint8_t dev_id, uint16_t qp_id,
struct rte_cryptodev_sym_session *sess)
 {
struct rte_cryptodev *dev;
 
-   if (!rte_cryptodev_pmd_is_valid_dev(sess->dev_id)) {
-   CDEV_LOG_ERR("Invalid dev_id=%d", sess->dev_id);
+   if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+   CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
return -EINVAL;
}
 
-   dev = &rte_crypto_devices[sess->dev_id];
+   dev = &rte_crypto_devices[dev_id];
 
/* The API is optional, not returning error if driver do not suuport */
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->qp_attach_session, 0);
if (dev->dev_ops->qp_attach_session(dev, qp_id, sess->_private)) {
CDEV_LOG_ERR("dev_id %d failed to attach qp: %d with session",
-   sess->dev_id, qp_id);
+   dev_id, qp_id);
return -EPERM;
}
 
@@ -1099,23 +1099,23 @@ rte_cryptodev_queue_pair_attach_sym_session(uint16_t 
qp_id,
 }
 
 int
-rte_cryptodev_queue_pair_detach_sym_session(uint16_t qp_id,
+rte_cryptodev_queue_pair_detach_sym_session(uint8_t dev_id, uint16_t qp_id,
struct rte_cryptodev_sym_session *sess)
 {
struct rte_cryptodev *dev;
 
-   if (!rte_cryptodev_pmd_is_valid_dev(sess->dev_id)) {
-   CDEV_LOG_ERR("Invalid dev_id=%d", sess->dev_id);
+   if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+   CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
return -EINVAL;
}
 
-   dev = &rte_crypto_devices[sess->dev_id];
+   dev = &rte_crypto_devices[dev_id];
 
/* The API is optional, not returning error if driver do not suuport */
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->qp_detach_session, 0);
if (dev->dev_ops->qp_detach_session(dev, qp_id, sess->_private)) {
CDEV_LOG_ERR("dev_id %d failed to detach qp: %d from session",
-   sess->dev_id, qp_id);
+   dev_id, qp_id);
return -EPERM;
}
 
diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
b/lib/librte_cryptodev/rte_cryptodev.h
index 1afd2d8..d3d2794 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -867,7 +867,8 @@ rte_cryptodev_get_private_session_size(uint8_t dev_id);
 /**
  * Attach queue pair with sym session.
  *
- * @param  qp_id   Queue pair to which session will be attached.
+ * @param  dev_id  Device to which the session will be attached.
+ * @param  qp_id   Queue pair to which the session will be 
attached.
  * @param  s

[dpdk-dev] [PATCH v3 11/12] cryptodev: remove session init internal function

2017-07-02 Thread Pablo de Lara
Since now the private session data is initialized after
the session pool is created, there is no need to keep
this PMD function.

Signed-off-by: Pablo de Lara 
---
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c |  8 
 lib/librte_cryptodev/rte_cryptodev_pmd.h| 16 
 2 files changed, 24 deletions(-)

diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c 
b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
index bab2b4e..0382dc0 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
@@ -752,13 +752,6 @@ dpaa2_sec_session_get_size(struct rte_cryptodev *dev 
__rte_unused)
return sizeof(dpaa2_sec_session);
 }
 
-static void
-dpaa2_sec_session_initialize(struct rte_mempool *mp __rte_unused,
-void *sess __rte_unused)
-{
-   PMD_INIT_FUNC_TRACE();
-}
-
 static int
 dpaa2_sec_cipher_init(struct rte_cryptodev *dev,
  struct rte_crypto_sym_xform *xform,
@@ -1505,7 +1498,6 @@ static struct rte_cryptodev_ops crypto_ops = {
.queue_pair_stop  = dpaa2_sec_queue_pair_stop,
.queue_pair_count = dpaa2_sec_queue_pair_count,
.session_get_size = dpaa2_sec_session_get_size,
-   .session_initialize   = dpaa2_sec_session_initialize,
.session_configure= dpaa2_sec_session_configure,
.session_clear= dpaa2_sec_session_clear,
 };
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 4e49e87..0e44451 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -267,20 +267,6 @@ typedef unsigned 
(*cryptodev_sym_get_session_private_size_t)(
struct rte_cryptodev *dev);
 
 /**
- * Initialize a Crypto session on a device.
- *
- * @param  dev Crypto device pointer
- * @param  xform   Single or chain of crypto xforms
- * @param  priv_sess   Pointer to cryptodev's private session structure
- *
- * @return
- *  - Returns private session structure on success.
- *  - Returns NULL on failure.
- */
-typedef void (*cryptodev_sym_initialize_session_t)(struct rte_mempool *mempool,
-   void *session_private);
-
-/**
  * Configure a Crypto session on a device.
  *
  * @param  dev Crypto device pointer
@@ -357,8 +343,6 @@ struct rte_cryptodev_ops {
 
cryptodev_sym_get_session_private_size_t session_get_size;
/**< Return private session. */
-   cryptodev_sym_initialize_session_t session_initialize;
-   /**< Initialization function for private session data */
cryptodev_sym_configure_session_t session_configure;
/**< Configure a Crypto session. */
cryptodev_sym_free_session_t session_clear;
-- 
2.9.4



[dpdk-dev] [PATCH v3 12/12] doc: add new crypto session information

2017-07-02 Thread Pablo de Lara
Modified cryptodev library section in Programmer's Guide,
with the recent changes in the crypto sessions.

Signed-off-by: Slawomir Mrozowicz 
Signed-off-by: Pablo de Lara 
---
 doc/guides/prog_guide/cryptodev_lib.rst  |  59 ++--
 doc/guides/prog_guide/img/cryptodev_sym_sess.svg | 418 ---
 2 files changed, 400 insertions(+), 77 deletions(-)

diff --git a/doc/guides/prog_guide/cryptodev_lib.rst 
b/doc/guides/prog_guide/cryptodev_lib.rst
index 4644802..3d3239d 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -114,9 +114,8 @@ The rte_cryptodev_configure API is used to configure a 
Crypto device.
int rte_cryptodev_configure(uint8_t dev_id,
struct rte_cryptodev_config *config)
 
-The ``rte_cryptodev_config`` structure is used to pass the configuration 
parameters.
-In contains parameter for socket selection, number of queue pairs and the
-session mempool configuration.
+The ``rte_cryptodev_config`` structure is used to pass the configuration
+parameters for socket selection and number of queue pairs.
 
 .. code-block:: c
 
@@ -125,12 +124,6 @@ session mempool configuration.
 /**< Socket to allocate resources on */
 uint16_t nb_queue_pairs;
 /**< Number of queue pairs to configure on device */
-
-struct {
-uint32_t nb_objs;
-uint32_t cache_size;
-} session_mp;
-/**< Session mempool configuration */
 };
 
 
@@ -431,7 +424,7 @@ operations, as well as also supporting AEAD operations.
 Session and Session Management
 ~~
 
-Session are used in symmetric cryptographic processing to store the immutable
+Sessions are used in symmetric cryptographic processing to store the immutable
 data defined in a cryptographic transform which is used in the operation
 processing of a packet flow. Sessions are used to manage information such as
 expand cipher keys and HMAC IPADs and OPADs, which need to be calculated for a
@@ -442,27 +435,31 @@ Crypto workloads.
 
 .. figure:: img/cryptodev_sym_sess.*
 
-The Crypto device framework provides a set of session pool management APIs for
-the creation and freeing of the sessions, utilizing the Mempool Library.
-
-The framework also provides hooks so the PMDs can pass the amount of memory
-required for that PMDs private session parameters, as well as initialization
-functions for the configuration of the session parameters and freeing function
-so the PMD can managed the memory on destruction of a session.
-
-**Note**: Sessions created on a particular device can only be used on Crypto
-devices of the same type - the same driver id used by this devices,
-and if you try to use a session on a device different
-to that on which it was created then the Crypto operation will fail.
-
-``rte_cryptodev_sym_session_create()`` is used to create a symmetric session on
-Crypto device. A symmetric transform chain is used to specify the particular
-operation and its parameters. See the section below for details on transforms.
-
-.. code-block:: c
-
-   struct rte_cryptodev_sym_session * rte_cryptodev_sym_session_create(
-  uint8_t dev_id, struct rte_crypto_sym_xform *xform);
+The Crypto device framework provides APIs to allocate and initizalize sessions
+for crypto devices, where sessions are mempool objects.
+It is the application's responsibility to create and manage the session 
mempools.
+This approach allows for different scenarios such as having a single session
+mempool for all crypto devices (where the mempool object size is big
+enough to hold the private session of any crypto device), as well as having
+multiple session mempools of different sizes for better memory usage.
+
+An application can use ``rte_cryptodev_get_private_session_size()`` to
+get the private session size of given crypto device. This function would allow
+an application to calculate the max device session size of all crypto devices
+to create a single session mempool.
+If instead an application creates multiple session mempools, the Crypto device
+framework also provides ``rte_cryptodev_get_header_session_size`` to get
+the size of an uninitialized session.
+
+Once the session mempools have been created, 
``rte_cryptodev_sym_session_create()``
+is used to allocate an uninitialized session from the given mempool.
+The session then must be initialized using ``rte_cryptodev_sym_session_init()``
+for each of the required crypto devices. A symmetric transform chain
+is used to specify the operation and its parameters. See the section below for
+details on transforms.
+
+Unused session should be freed using ``rte_cryptodev_sym_session_free`` which
+returns them to their mempool.
 
 **Note**: For AEAD operations the algorithm selected for authentication and
 ciphering must aligned, eg AES_GCM.
diff --git a/doc/guides/prog_guide/img/cryptodev_sym_sess.svg 
b/doc/guides/prog_guide/img/cryptodev_sym_sess.svg
inde

[dpdk-dev] [PATCH v3 10/12] cryptodev: add mempool pointer in queue pair setup

2017-07-02 Thread Pablo de Lara
The session mempool pointer is needed in each queue pair,
if session-less operations are being handled.
Therefore, the API is changed to accept this parameter,
as the session mempool is created outside the
device configuration function, similar to what ethdev
does with the rx queues.

Signed-off-by: Pablo de Lara 
---
 app/test-crypto-perf/main.c| 18 
 doc/guides/rel_notes/release_17_08.rst |  2 +-
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c   |  4 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  4 +-
 drivers/crypto/armv8/rte_armv8_pmd_ops.c   |  4 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c|  3 +-
 drivers/crypto/kasumi/rte_kasumi_pmd_ops.c |  4 +-
 drivers/crypto/null/null_crypto_pmd_ops.c  |  4 +-
 drivers/crypto/openssl/rte_openssl_pmd_ops.c   |  4 +-
 drivers/crypto/qat/qat_crypto.h|  3 +-
 drivers/crypto/qat/qat_qp.c|  2 +-
 drivers/crypto/scheduler/scheduler_pmd_ops.c   | 13 --
 drivers/crypto/snow3g/rte_snow3g_pmd_ops.c |  4 +-
 drivers/crypto/zuc/rte_zuc_pmd_ops.c   |  4 +-
 examples/ipsec-secgw/ipsec-secgw.c |  6 +--
 examples/l2fwd-crypto/main.c   |  5 +--
 lib/librte_cryptodev/rte_cryptodev.c   | 11 +++--
 lib/librte_cryptodev/rte_cryptodev.h   |  9 ++--
 lib/librte_cryptodev/rte_cryptodev_pmd.h   |  3 +-
 test/test/test_cryptodev.c | 58 +++---
 test/test/test_cryptodev_perf.c|  5 ++-
 21 files changed, 93 insertions(+), 77 deletions(-)

diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index eb2737e..f325b11 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c
@@ -123,20 +123,20 @@ cperf_initialize_cryptodev(struct cperf_options *opts, 
uint8_t *enabled_cdevs,
session_pool_socket[socket_id] = sess_mp;
}
 
-   ret = rte_cryptodev_configure(cdev_id, &conf,
-   session_pool_socket[socket_id]);
+   ret = rte_cryptodev_configure(cdev_id, &conf);
if (ret < 0) {
printf("Failed to configure cryptodev %u", cdev_id);
return -EINVAL;
}
 
-   ret = rte_cryptodev_queue_pair_setup(cdev_id, 0, &qp_conf,
-   socket_id);
-   if (ret < 0) {
-   printf("Failed to setup queue pair %u on "
-   "cryptodev %u", 0, cdev_id);
-   return -EINVAL;
-   }
+   ret = rte_cryptodev_queue_pair_setup(cdev_id, 0,
+   &qp_conf, socket_id,
+   session_pool_socket[socket_id]);
+   if (ret < 0) {
+   printf("Failed to setup queue pair %u on "
+   "cryptodev %u", 0, cdev_id);
+   return -EINVAL;
+   }
 
ret = rte_cryptodev_start(cdev_id);
if (ret < 0) {
diff --git a/doc/guides/rel_notes/release_17_08.rst 
b/doc/guides/rel_notes/release_17_08.rst
index 463b616..8630b40 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -170,7 +170,7 @@ API Changes
   * Mempool pointer ``mp`` has been removed from ``rte_cryptodev_sym_session`` 
structure.
   * Replaced ``private`` marker with array of pointers to private data sessions
 ``sess_private_data`` in ``rte_cryptodev_sym_session``
-
+  * Added new field ``session_pool`` to ``rte_cryptodev_queue_pair_setup()``.
 
 ABI Changes
 ---
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c 
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index 0b063fd..d47a041 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -244,7 +244,7 @@ aesni_gcm_pmd_qp_create_processed_pkts_ring(struct 
aesni_gcm_qp *qp,
 static int
 aesni_gcm_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
-int socket_id)
+   int socket_id, struct rte_mempool *session_pool)
 {
struct aesni_gcm_qp *qp = NULL;
 
@@ -269,7 +269,7 @@ aesni_gcm_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t 
qp_id,
if (qp->processed_pkts == NULL)
goto qp_setup_cleanup;
 
-   qp->sess_mp = dev->data->session_pool;
+   qp->sess_mp = session_pool;
 
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
 
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
index fda8296..1216e56 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
@@ -397,7 +397,7 @@ aesni_mb_pmd_qp_create_processed_ops_ring(struct 
aesni_

[dpdk-dev] [PATCH v2] doc: add known issue for i40e VF performance

2017-07-02 Thread Qi Zhang
VF performance is limited by the kernel PCI extended tag setting.
Update the document to explain the known issue and the workaround.

Signed-off-by: Qi Zhang 
---

v2:
- follow number list format.
- improve the comments.

 doc/guides/nics/i40e.rst | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 4d3c7ca..2f2cf6d 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -447,3 +447,30 @@ It means if APP has set the max bandwidth for that TC, it 
comes to no
 effect.
 It's suggested to set the strict priority mode for a TC that is latency
 sensitive but no consuming much bandwidth.
+
+VF performance is impacted by PCI extended tag setting
+~~
+
+To reach maximum NIC performance in the VF the PCI extended tag must be
+enabled. The DPDK I40E PF drvier will set this feature during initialization,
+but the kernel PF driver does not. So when running traffic on a VF which is
+managed by the kernel PF driver, a significent NIC performance downgrade has
+been observed (for 64 byte packets, there is about 25% linerate downgrade for
+a 25G device and about 35% for a 40G device).
+
+For kernel version >= 4.11, the kernel's PCI driver will enable the extended
+tag if it detects that the device supports it. So by default, this is not an
+issue. For kernels <= 4.11 or When the PCI extended tag is disabled it can be
+enabled using the steps below.
+
+#. Get the current value of the PCI configure register::
+
+  setpci -s  a8.w
+
+#. Set bit 8::
+
+  value = value | 0x100
+
+#. Set the PCI configure register with new value::
+
+  setpci -s  a8.w=
-- 
2.9.3



[dpdk-dev] rte_ctrlmbuf_init() and CTRL_MBUF_FLAG are not used - shouldn't they be removed and deprecated ?

2017-07-02 Thread Kevin Wilson
Hello,
With the most recent master tree we have:

git grep  rte_ctrlmbuf_init
doc/guides/prog_guide/mbuf_lib.rst:The rte_pktmbuf_init() and
rte_ctrlmbuf_init() functions initialize some fields in the mbuf
structure that
lib/librte_mbuf/rte_mbuf.c:rte_ctrlmbuf_init(struct rte_mempool *mp,
lib/librte_mbuf/rte_mbuf.h:void rte_ctrlmbuf_init(struct rte_mempool
*mp, void *opaque_arg,
lib/librte_mbuf/rte_mbuf_version.map:   rte_ctrlmbuf_init;

git grep  rte_is_ctrlmbuf
lib/librte_mbuf/rte_mbuf.h:rte_is_ctrlmbuf(struct rte_mbuf *m)

git grep CTRL_MBUF_FLAG
doc/guides/prog_guide/mbuf_lib.rst:or generic control buffers
(indicated by the CTRL_MBUF_FLAG).
lib/librte_mbuf/rte_mbuf.c: m->ol_flags |= CTRL_MBUF_FLAG;
lib/librte_mbuf/rte_mbuf.h:#define CTRL_MBUF_FLAG   (1ULL << 63)
/**< Mbuf contains control data */
lib/librte_mbuf/rte_mbuf.h: return !!(m->ol_flags & CTRL_MBUF_FLAG);

rte_ctrlmbuf_init() and CTRL_MBUF_FLAG and rte_is_ctrlmbuf() are not
used - shouldn't they be removed and deprecated ?

KW


Re: [dpdk-dev] [PATCH v5 1/3] examples/eventdev_pipeline: added sample app

2017-07-02 Thread Jerin Jacob
-Original Message-
> 
> From: Harry van Haaren 
> 
> This commit adds a sample app for the eventdev library.
> The app has been tested with DPDK 17.05-rc2, hence this
> release (or later) is recommended.
> 
> The sample app showcases a pipeline processing use-case,
> with event scheduling and processing defined per stage.
> The application receives traffic as normal, with each
> packet traversing the pipeline. Once the packet has
> been processed by each of the pipeline stages, it is
> transmitted again.
> 
> The app provides a framework to utilize cores for a single
> role or multiple roles. Examples of roles are the RX core,
> TX core, Scheduling core (in the case of the event/sw PMD),
> and worker cores.
> 
> Various flags are available to configure numbers of stages,
> cycles of work at each stage, type of scheduling, number of
> worker cores, queue depths etc. For a full explaination,
> please refer to the documentation.

A few comments on bugs and "to avoid the future rework on base code when
HW PMD is introduced". As we agreed, We will keep the functionality intact to
provide an application to test ethdev + eventdev with _SW PMD_ for 17.08


> ---
>  examples/Makefile   |   2 +
>  examples/eventdev_pipeline/Makefile |  49 ++
>  examples/eventdev_pipeline/main.c   | 999 
> 
>  3 files changed, 1050 insertions(+)
>  create mode 100644 examples/eventdev_pipeline/Makefile
>  create mode 100644 examples/eventdev_pipeline/main.c

Do we need to update the MAINTAINERS file?

> 
> diff --git a/examples/Makefile b/examples/Makefile
> index 6298626..a6dcc2b 100644
> --- a/examples/Makefile
> +++ b/examples/Makefile
> @@ -100,4 +100,6 @@ $(info vm_power_manager requires libvirt >= 0.9.3)
>  endif
>  endif
>  
> +DIRS-y += eventdev_pipeline

Can you change to eventdev_pipeline_sw_pmd to emphasis on the scope.
We will rename to eventdev_pipeline once it working effectively on both SW and 
HW
PMD with ethdev.

> +
>  include $(RTE_SDK)/mk/rte.extsubdir.mk
> diff --git a/examples/eventdev_pipeline/Makefile 
> b/examples/eventdev_pipeline/Makefile
> new file mode 100644
> index 000..4c26e15
> --- /dev/null
> +++ b/examples/eventdev_pipeline/Makefile
> @@ -0,0 +1,49 @@
> +#   BSD LICENSE
> +#
> +#   Copyright(c) 2016 Intel Corporation. All rights reserved.

2016-2017

> +#
> +#   Redistribution and use in source and binary forms, with or without
> +#   modification, are permitted provided that the following conditions
> +#   are met:
> +#
> +
> +static unsigned int active_cores;
> +static unsigned int num_workers;
> +static long num_packets = (1L << 25); /* do ~32M packets */
> +static unsigned int num_fids = 512;
> +static unsigned int num_stages = 1;
> +static unsigned int worker_cq_depth = 16;
> +static int queue_type = RTE_EVENT_QUEUE_CFG_ATOMIC_ONLY;
> +static int16_t next_qid[MAX_NUM_STAGES+1] = {-1};
> +static int16_t qid[MAX_NUM_STAGES] = {-1};
> +static int worker_cycles;
> +static int enable_queue_priorities;
> +
> +struct prod_data {
> + uint8_t dev_id;
> + uint8_t port_id;
> + int32_t qid;
> + unsigned int num_nic_ports;
> +} __rte_cache_aligned;
> +
> +struct cons_data {
> + uint8_t dev_id;
> + uint8_t port_id;
> +} __rte_cache_aligned;
> +
> +static struct prod_data prod_data;
> +static struct cons_data cons_data;
> +
> +struct worker_data {
> + uint8_t dev_id;
> + uint8_t port_id;
> +} __rte_cache_aligned;
> +
> +static unsigned int *enqueue_cnt;
> +static unsigned int *dequeue_cnt;

Not been consumed. Remove it.

> +
> +static volatile int done;
> +static int quiet;
> +static int dump_dev;
> +static int dump_dev_signal;
> +
> +static uint32_t rx_lock;
> +static uint32_t tx_lock;
> +static uint32_t sched_lock;
> +static bool rx_single;
> +static bool tx_single;
> +static bool sched_single;
> +
> +static unsigned int rx_core[MAX_NUM_CORE];
> +static unsigned int tx_core[MAX_NUM_CORE];
> +static unsigned int sched_core[MAX_NUM_CORE];
> +static unsigned int worker_core[MAX_NUM_CORE];
> +
> +static struct rte_eth_dev_tx_buffer *tx_buf[RTE_MAX_ETHPORTS];


Could you please remove this global variable and group under a structure
for "command line parsing specific" and "fast path specific"(anything comes
in producer(), worker() and consumer()). And please
allocate "fast path specific" structure variable from huge page area.
So that we can easily add new parsing and fastpath variable in future.


> +
> +static int
> +consumer(void)
> +{
> + const uint64_t freq_khz = rte_get_timer_hz() / 1000;
> + struct rte_event packets[BATCH_SIZE];
> +
> + static uint64_t received;
> + static uint64_t last_pkts;
> + static uint64_t last_time;
> + static uint64_t start_time;
> + unsigned int i, j;
> + uint8_t dev_id = cons_data.dev_id;
> + uint8_t port_id = cons_data.port_id;
> +
> + uint16_t n = rte_event_dequeue_burst(dev_id, port_id,
> + packets, RTE_DIM(packets), 0);
>

Re: [dpdk-dev] [PATCH v10 2/3] lib/gro: add TCP/IPv4 GRO support

2017-07-02 Thread Hu, Jiayu
Hi Jianfeng,

> -Original Message-
> From: Tan, Jianfeng
> Sent: Sunday, July 2, 2017 6:20 PM
> To: Hu, Jiayu ; dev@dpdk.org
> Cc: Ananyev, Konstantin ;
> step...@networkplumber.org; y...@fridaylinux.org; Wu, Jingjing
> ; Yao, Lei A ; Bie, Tiwei
> 
> Subject: Re: [PATCH v10 2/3] lib/gro: add TCP/IPv4 GRO support
> 
> 
> 
> On 7/1/2017 7:08 PM, Jiayu Hu wrote:
> > In this patch, we introduce five APIs to support TCP/IPv4 GRO.
> > - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used
> >  to merge packets.
> > - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table.
> > - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4
> >  reassembly table.
> > - gro_tcp4_tbl_item_num: return the number of packets in a TCP/IPv4
> >  reassembly table.
> > - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet.
> >
> > TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4
> > and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP
> > checksums for merged packets. If inputted packets are IP fragmented,
> > TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4
> > headers).
> >
> > In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly
> > table, to reassemble packets. A TCP/IPv4 reassembly table includes a key
> > array and a item array, where the key array keeps the criteria to merge
> > packets and the item array keeps packet information.
> >
> > One key in the key array points to an item group, which consists of
> > packets which have the same criteria value. If two packets are able to
> > merge, they must be in the same item group. Each key in the key array
> > includes two parts:
> > - criteria: the criteria of merging packets. If two packets can be
> >  merged, they must have the same criteria value.
> > - start_index: the index of the first incoming packet of the item group.
> >
> > Each element in the item array keeps the information of one packet. It
> > mainly includes two parts:
> > - pkt: packet address
> > - next_pkt_index: the index of the next packet in the same item group.
> >  All packets in the same item group are chained by next_pkt_index.
> >  With next_pkt_index, we can locate all packets in the same item
> >  group one by one.
> >
> > To process an incoming packet needs three steps:
> > a. check if the packet should be processed. Packets with one of the
> >  following properties won't be processed:
> > - SYN, FIN, RST or PSH bit is set;
> > - packet payload length is 0.
> > b. traverse the key array to find a key which has the same criteria
> >  value with the incoming packet. If find, goto step c. Otherwise,
> >  insert a new key and insert the packet into the item array.
> > c. locate the first packet in the item group via the start_index in the
> >  key. Then traverse all packets in the item group via next_pkt_index.
> >  If find one packet which can merge with the incoming one, merge them
> >  together. If can't find, insert the packet into this item group.
> >
> > Signed-off-by: Jiayu Hu 
> > ---
> >   doc/guides/rel_notes/release_17_08.rst |   7 +
> >   lib/librte_gro/Makefile|   1 +
> >   lib/librte_gro/rte_gro.c   | 123 -
> >   lib/librte_gro/rte_gro.h   |  10 +-
> >   lib/librte_gro/rte_gro_tcp4.c  | 439
> +
> >   lib/librte_gro/rte_gro_tcp4.h  | 172 +
> >   6 files changed, 736 insertions(+), 16 deletions(-)
> >   create mode 100644 lib/librte_gro/rte_gro_tcp4.c
> >   create mode 100644 lib/librte_gro/rte_gro_tcp4.h
> >
> > diff --git a/doc/guides/rel_notes/release_17_08.rst
> b/doc/guides/rel_notes/release_17_08.rst
> > index 842f46f..f067247 100644
> > --- a/doc/guides/rel_notes/release_17_08.rst
> > +++ b/doc/guides/rel_notes/release_17_08.rst
> > @@ -75,6 +75,13 @@ New Features
> >
> > Added support for firmwares with multiple Ethernet ports per physical
> port.
> >
> > +* **Add Generic Receive Offload API support.**
> > +
> > +  Generic Receive Offload (GRO) API supports to reassemble TCP/IPv4
> > +  packets. GRO API assumes all inputted packets are with correct
> > +  checksums. GRO API doesn't update checksums for merged packets. If
> > +  inputted packets are IP fragmented, GRO API assumes they are complete
> > +  packets (i.e. with L4 headers).
> >
> >   Resolved Issues
> >   ---
> > diff --git a/lib/librte_gro/Makefile b/lib/librte_gro/Makefile
> > index 7e0f128..43e276e 100644
> > --- a/lib/librte_gro/Makefile
> > +++ b/lib/librte_gro/Makefile
> > @@ -43,6 +43,7 @@ LIBABIVER := 1
> >
> >   # source files
> >   SRCS-$(CONFIG_RTE_LIBRTE_GRO) += rte_gro.c
> > +SRCS-$(CONFIG_RTE_LIBRTE_GRO) += rte_gro_tcp4.c
> >
> >   # install this header file
> >   SYMLINK-$(CONFIG_RTE_LIBRTE_GRO)-include += rte_gro.h
> > diff --git a/lib/librte_gro/rte_gro.c b/lib/librte_gro/rte_gro.c
> > index 648835b

Re: [dpdk-dev] [PATCH v5 2/3] doc: add sw eventdev pipeline to sample app ug

2017-07-02 Thread Jerin Jacob
-Original Message-
> 
> From: Harry van Haaren 
> > Adi a new entry in the sample app user-guides,
> which details the working of the eventdev_pipeline_sw.
> 
> Signed-off-by: Harry van Haaren 
> Signed-off-by: David Hunt 
> ---
>  doc/guides/sample_app_ug/eventdev_pipeline_sw.rst | 190 
> ++
>  doc/guides/sample_app_ug/index.rst|   1 +
>  2 files changed, 191 insertions(+)
>  create mode 100644 doc/guides/sample_app_ug/eventdev_pipeline_sw.rst
> 
> diff --git a/doc/guides/sample_app_ug/eventdev_pipeline_sw.rst 
> b/doc/guides/sample_app_ug/eventdev_pipeline_sw.rst
> new file mode 100644
> index 000..65c33a8
> --- /dev/null
> +++ b/doc/guides/sample_app_ug/eventdev_pipeline_sw.rst
> @@ -0,0 +1,190 @@
> +
> +
> +Eventdev Pipeline SW Sample Application

Eventdev Pipeline SW PMD Sample Application

> +===
> +
> +The eventdev pipeline sample application is a sample app that demonstrates
> +the usage of the eventdev API using the software PMD. It shows how an
> +application can configure a pipeline and assign a set of worker cores to
> +perform the processing required.
> +
> +The application has a range of command line arguments allowing it to be
> +configured for various numbers worker cores, stages,queue depths and cycles 
> per
> +stage of work. This is useful for performance testing as well as quickly 
> testing
> +a particular pipeline configuration.
> +
> +
> +statistics that the PMD provides. The statistics provided depend on the PMD
> +used, see the Event Device Drivers section for a list of eventdev PMDs.
> diff --git a/doc/guides/sample_app_ug/index.rst 
> b/doc/guides/sample_app_ug/index.rst
> index 02611ef..90be36a 100644
> --- a/doc/guides/sample_app_ug/index.rst
> +++ b/doc/guides/sample_app_ug/index.rst
> @@ -69,6 +69,7 @@ Sample Applications User Guides
>  netmap_compatibility
>  ip_pipeline
>  test_pipeline
> +eventdev_pipeline_sw

eventdev_pipeline_sw_pmd

>  dist_app
>  vm_power_management
>  tep_termination

With above changes:

Acked-by: Jerin Jacob 



Re: [dpdk-dev] [PATCH v10 1/3] lib: add Generic Receive Offload API framework

2017-07-02 Thread Hu, Jiayu
Hi Jianfeng,

> -Original Message-
> From: Tan, Jianfeng
> Sent: Sunday, July 2, 2017 6:20 PM
> To: Hu, Jiayu ; dev@dpdk.org
> Cc: Ananyev, Konstantin ;
> step...@networkplumber.org; y...@fridaylinux.org; Wu, Jingjing
> ; Yao, Lei A ; Bie, Tiwei
> 
> Subject: Re: [PATCH v10 1/3] lib: add Generic Receive Offload API framework
> 
> 
> 
> On 7/1/2017 7:08 PM, Jiayu Hu wrote:
> > Generic Receive Offload (GRO) is a widely used SW-based offloading
> > technique to reduce per-packet processing overhead. It gains
> > performance by reassembling small packets into large ones. This
> > patchset is to support GRO in DPDK. To support GRO, this patch
> > implements a GRO API framework.
> >
> > To enable more flexibility to applications, DPDK GRO is implemented as
> > a user library. Applications explicitly use the GRO library to merge
> > small packets into large ones. DPDK GRO provides two reassembly modes.
> > One is called lightweight mode, the other is called heavyweight mode.
> > If applications want to merge packets in a simple way and the number
> > of packets is relatively small, they can use the lightweight mode.
> > If applications need more fine-grained controls, they can choose the
> > heavyweight mode.
> >
> > rte_gro_reassemble_burst is the main reassembly API which is used in
> > lightweight mode and processes N packets at a time. For applications,
> > performing GRO in lightweight mode is simple. They just need to invoke
> > rte_gro_reassemble_burst. Applications can get GROed packets as soon as
> > rte_gro_reassemble_burst returns.
> >
> > rte_gro_reassemble is the main reassembly API which is used in
> > heavyweight mode and tries to merge N inputted packets with the packets
> > in a givn GRO table. For applications, performing GRO in heavyweight
> > mode is relatively complicated. Before performing GRO, applications need
> > to create a GRO table by rte_gro_tbl_create. Then they can use
> > rte_gro_reassemble to merge packets. The GROed packets are in the GRO
> > table. If applications want to get them, applications need to manually
> > flush them by flush API.
> 
> > Signed-off-by: Jiayu Hu 
> > ---
> >   config/common_base |   5 ++
> >   lib/Makefile   |   2 +
> >   lib/librte_gro/Makefile|  50 +++
> >   lib/librte_gro/rte_gro.c   | 176
> +
> >   lib/librte_gro/rte_gro.h   | 176
> +
> >   lib/librte_gro/rte_gro_version.map |  12 +++
> >   mk/rte.app.mk  |   1 +
> >   7 files changed, 422 insertions(+)
> >   create mode 100644 lib/librte_gro/Makefile
> >   create mode 100644 lib/librte_gro/rte_gro.c
> >   create mode 100644 lib/librte_gro/rte_gro.h
> >   create mode 100644 lib/librte_gro/rte_gro_version.map
> >
> > diff --git a/config/common_base b/config/common_base
> > index f6aafd1..167f5ef 100644
> > --- a/config/common_base
> > +++ b/config/common_base
> > @@ -712,6 +712,11 @@ CONFIG_RTE_LIBRTE_VHOST_DEBUG=n
> >   CONFIG_RTE_LIBRTE_PMD_VHOST=n
> >
> >   #
> > +# Compile GRO library
> > +#
> > +CONFIG_RTE_LIBRTE_GRO=y
> > +
> > +#
> >   #Compile Xen domain0 support
> >   #
> >   CONFIG_RTE_LIBRTE_XEN_DOM0=n
> > diff --git a/lib/Makefile b/lib/Makefile
> > index 07e1fd0..ac1c2f6 100644
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -106,6 +106,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_REORDER) +=
> librte_reorder
> >   DEPDIRS-librte_reorder := librte_eal librte_mempool librte_mbuf
> >   DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += librte_pdump
> >   DEPDIRS-librte_pdump := librte_eal librte_mempool librte_mbuf
> librte_ether
> > +DIRS-$(CONFIG_RTE_LIBRTE_GRO) += librte_gro
> > +DEPDIRS-librte_gro := librte_eal librte_mbuf librte_ether librte_net
> >
> >   ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
> >   DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
> > diff --git a/lib/librte_gro/Makefile b/lib/librte_gro/Makefile
> > new file mode 100644
> > index 000..7e0f128
> > --- /dev/null
> > +++ b/lib/librte_gro/Makefile
> > @@ -0,0 +1,50 @@
> > +#   BSD LICENSE
> > +#
> > +#   Copyright(c) 2017 Intel Corporation. All rights reserved.
> > +#   All rights reserved.
> > +#
> > +#   Redistribution and use in source and binary forms, with or without
> > +#   modification, are permitted provided that the following conditions
> > +#   are met:
> > +#
> > +# * Redistributions of source code must retain the above copyright
> > +#   notice, this list of conditions and the following disclaimer.
> > +# * Redistributions in binary form must reproduce the above copyright
> > +#   notice, this list of conditions and the following disclaimer in
> > +#   the documentation and/or other materials provided with the
> > +#   distribution.
> > +# * Neither the name of Intel Corporation nor the names of its
> > +#   contributors may be used to endorse or promote products derived
> > +#   from this software without specific prior written 

[dpdk-dev] [PATCH v2] eal: fix secondary process segfault on multipe virtio devices

2017-07-02 Thread Jianfeng Tan
Suppose we have 2 virtio devices for a VM, with only the first one,
virtio0, binding to igb_uio. Start a primary DPDK process, driving
only virtio0. Then start a secondary DPDK process, it encounters
segfault at eth_virtio_dev_init() because hw is NULL, when trying
to initialize the 2nd virtio devices.
1539if (!hw->virtio_user_dev) {

We could add a precheck to return error when hw is NULL. But the
root cause is that virtio devices which are not driven by the primary
process are not exluded by secondary eal probe function.

To support legacy virtio devices bound to none kernel driver, we
removed RTE_PCI_DRV_NEED_MAPPING in
commit 962cf902e6eb ("pci: export device mapping functions").
At the boot of primary process, ether dev is allocated in rte_eth_devices
array, rte_eth_dev_data is also allocated in rte_eth_dev_data array; then
probe function fails; and ether dev is released. However, the entry in
rte_eth_dev_data array is not cleared. Then we start secondary process,
and try to attach the virtio device that not used in primary process,
the field, dev_private (or hw), in rte_eth_dev_data, is NULL.

To fail the dev attach, we need to clear the field, name, when we
release any ether devices in primary, so that below loop in
rte_eth_dev_attach_secondary() will not find any matched names.
for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
if (strcmp(rte_eth_dev_data[i].name, name) == 0)
break;
}

Fixes: 6d890f8ab512 ("Fixes: net/virtio: fix multiple process support")
Cc: sta...@dpdk.org

Reported-by: Reshma Pattan 
Signed-off-by: Jianfeng Tan 
---
v2:
  - Assign '\0' to first char of name instead of memset as per Thomas's advice.
 lib/librte_ether/rte_ethdev_pci.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev_pci.h 
b/lib/librte_ether/rte_ethdev_pci.h
index 69aab03..0e7d7a9 100644
--- a/lib/librte_ether/rte_ethdev_pci.h
+++ b/lib/librte_ether/rte_ethdev_pci.h
@@ -133,6 +133,12 @@ rte_eth_dev_pci_release(struct rte_eth_dev *eth_dev)
 
eth_dev->data->dev_private = NULL;
 
+   /* Secondary process will use the field, name, for secondary
+* attach, clear this field to avoid attaching any released
+* ports in secondary processes.
+*/
+   eth_dev->data->name[0] = '\0';
+
eth_dev->device = NULL;
eth_dev->intr_handle = NULL;
 }
-- 
2.7.4