date:20160130

[dpdk-dev] Fw: RE: DPDK vhostuser with vxlan

2016-01-30 Thread Abhijeet Karve

 Hi przemek,


We have setup vxlan tunnel between our two compute nodes, Can see the traafic 
in vxlan port on br-tun of source instance's compute node.

We are in same situation which is being described in below thread, i looked dev 
mailing archieves for it but seems no one has responded it.

 http://comments.gmane.org/gmane.linux.network.openvswitch.general/9878

Would be really appriciate if provide us any suggestions on it.



Thanks & Regards
Abhijeet Karve

 -Forwarded by on 01/30/2016 07:24PM -

 ===
 To: "Czesnowicz, Przemyslaw" 
 From: Abhijeet Karve/AHD/TCS at TCS
 Date: 01/27/2016 09:52PM 
 Cc: "dev at dpdk.org" , "discuss at openvswitch.org" , "Gray, Mark D" 
 Subject: RE: [dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# Inter-VM 
communication & IP allocation through DHCP issue
 ===
   Hi Przemek,

Thanks for the quick response. Now  able to get the DHCP ip's for 2 vhostuser 
instances and able to ping each other. Isssue was a bug in cirros 0.3.0 images 
which we were using in openstack after using 0.3.1 image as given in the 
URL(https://www.redhat.com/archives/rhos-list/2013-August/msg00032.html), able 
to get the IP's in vhostuser VM instances.

As per our understanding, Packet flow across DPDK datapath will be like 
vhostuser ports are connected to the br-int bridge & same is being patched to 
the br-dpdk bridge where in our physical network (NIC) is connected with dpdk0 
port. 

So for testing the flow we have to connect that physical network(NIC) with 
external packet generator (e.g - ixia, iperf) & run the testpmd application in 
the vhostuser VM, right?

Does it required to add any flows/efforts in bridge configurations(either 
br-int or br-dpdk)?


Thanks & Regards
Abhijeet Karve




From:   "Czesnowicz, Przemyslaw" 
To: Abhijeet Karve 
Cc: "dev at dpdk.org" , "discuss at openvswitch.org" 
, "Gray, Mark D" 
Date:   01/27/2016 05:11 PM
Subject:RE: [dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# 
Inter-VM communication & IP allocation through DHCP issue



Hi Abhijeet,


It seems you are almost there! 
When booting the VMs do you request hugepage memory for them (by setting 
hw:mem_page_size=large in flavor extra_spec)?
If not then please do, if yes then please look into libvirt logfiles for the 
VMs (in /var/log/libvirt/qemu/instance-xxx), I think there could be a 
clue.


Regards
Przemek

From: Abhijeet Karve [mailto:abhijeet.ka...@tcs.com] 
Sent: Monday, January 25, 2016 6:13 PM
To: Czesnowicz, Przemyslaw
Cc: dev at dpdk.org; discuss at openvswitch.org; Gray, Mark D
Subject: RE: [dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# Inter-VM 
communication & IP allocation through DHCP issue

Hi Przemek, 

Thank you for your response, It really provided us breakthrough. 

After setting up DPDK on compute node for stable/kilo, We are trying to set up 
Openstack stable/liberty all-in-one setup, At present we are not able to get 
the IP allocation for the vhost type instances through DHCP. Also we tried 
assigning IP's manually to them but the inter-VM communication also not 
happening, 

#neutron agent-list 
root at nfv-dpdk-devstack:/etc/neutron# neutron agent-list 
+--++---+---++---+
 
| id   | agent_type | host  
| alive | admin_state_up | binary| 
+--++---+---++---+
 
| 3b29e93c-3a25-4f7d-bf6c-6bb309db5ec0 | DPDK OVS Agent | nfv-dpdk-devstack 
| :-)   | True   | neutron-openvswitch-agent | 
| 62593b2c-c10f-4d93-8551-c46ce24895a6 | L3 agent   | nfv-dpdk-devstack 
| :-)   | True   | neutron-l3-agent  | 
| 7cb97af9-cc20-41f8-90fb-aba97d39dfbd | DHCP agent | nfv-dpdk-devstack 
| :-)   | True   | neutron-dhcp-agent| 
| b613c654-99b7-437e-9317-20fa651a1310 | Linux bridge agent | nfv-dpdk-devstack 
| :-)   | True   | neutron-linuxbridge-agent | 
| c2dd0384-6517-4b44-9c25-0d2825d23f57 | Metadata agent | nfv-dpdk-devstack 
| :-)   | True   | neutron-metadata-agent| 
| f23dde40-7dc0-4f20-8b3e-eb90ddb15e49 | Open vSwitch agent | nfv-dpdk-devstack 
| xxx   | True   | neutron-openvswitch-agent | 
+--++---+---++---+
 


ovs-vsctl show output# 
 
Bridge br-dpdk 
Port br-dpdk 
Interface br-dpdk 
type: internal 
Port phy-br-dpdk 
Interface phy-br-dpdk 
type: patch 
options: {peer=int-br-dpdk} 
Bridge br-int 
fail_mode: secure 
Port "vhufa41e799-f2"

[dpdk-dev] lcore Access to All ports

2016-01-30 Thread Sa Sa

I want to write a l2fwd  . Plus I need to have access to all my ports TX
queue to inject some packets into it . I don't know how Should I create
mempool and how to assigne those queues to each lcore .

[dpdk-dev] [PATCH] aesni_gcm: PMD to support AES_GCM crypto operations

2016-01-30 Thread O'Driscoll, Tim


> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty
> Sent: Saturday, January 30, 2016 1:10 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] aesni_gcm: PMD to support AES_GCM crypto
> operations
> 
> This patch provides the implementation of an AES-NI accelerated crypto
> PMD
> which is dependent on Intel's multi-buffer library, see the white paper
> "Fast Multi-buffer IPsec Implementations on Intel?  Architecture
> Processors"
> 
> This PMD supports AES_GCM authenticated encryption and authenticated
> decryption using
> 128-bit AES keys
> 
> The patch also contains the related unit tests functions for the
> implemented functionality
> 
> Signed-off-by: Declan Doherty 
> ---
>  MAINTAINERS|   4 +
>  app/test/test_cryptodev.c  | 462
> +++
>  app/test/test_cryptodev_gcm_test_vectors.h | 423
> +
>  config/common_linuxapp |  11 +-
>  config/defconfig_i686-native-linuxapp-gcc  |  10 +
>  drivers/crypto/Makefile|   1 +
>  drivers/crypto/aesni_gcm/Makefile  |  66 +++
>  drivers/crypto/aesni_gcm/aesni_gcm_ops.h   | 127 ++
>  drivers/crypto/aesni_gcm/aesni_gcm_pmd.c   | 498
> +
>  drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c   | 292 
>  drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h   | 120 +
>  .../crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map |   3 +
>  lib/librte_cryptodev/rte_cryptodev.h   |   5 +
>  mk/rte.app.mk  |  11 +-
>  14 files changed, 2028 insertions(+), 5 deletions(-)
>  create mode 100644 app/test/test_cryptodev_gcm_test_vectors.h
>  create mode 100644 drivers/crypto/aesni_gcm/Makefile
>  create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_ops.h
>  create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
>  create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
>  create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
>  create mode 100644
> drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map
> 

There should be an update to the Crypto Device Drivers guide for the new PMD.


Tim

[dpdk-dev] [PATCH 0/4] DPDK polling-mode driver for Amazon Elastic Network Adapters (ENA)

2016-01-30 Thread Matushevsky, Alexander

Hello Thomas,?
Regarding the documentation, we are going to add a description in 
doc/guides/nics in updated patch early on the upcoming week.

The full device spec still undergoes internal review, and will be released as 
soon as we have the approvals.

Best regards,
Alex

From: Thomas Monjalon 
Sent: Friday, January 29, 2016 6:04 PM
To: Jan M?dala
Cc: Matushevsky, Alexander; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] DPDK polling-mode driver for Amazon Elastic 
Network Adapters (ENA)

2016-01-29 16:42, Jan M?dala:
> Hello Thomas,
>
> 2016-01-28 16:40 GMT+01:00 Thomas Monjalon :
>
> > >  lib/librte_eal/linuxapp/ena_uio/ena_uio_driver.c   |  276 +++
> >
> > Sorry the kernel module party is over.
> > One day, igb_uio will be removed.
> > I suggest to make a first version without interrupt support
> > and work with Linux community to fix your issues.
>
> Rationale to deliver UIO kernel module is based on lack of legacy INTx
> interrupts in ENA device. It's operating only on MSI-X.
> Currently we do not implement interrupt support (yet) in PMD, but hardware
> was unable to operate under uio_generic_pci driver - probe is failing.
> It might be possible to use igb_uio kmod with ENA and I will do necessary
> investigation+experiments to prove that.
>
> Could you elaborate on the topic of kernel module removal - how would it
> look like, is there going to be generic PCI driver dedicated for MSI-X
> devices?

VFIO is the driver which should cover every needs for userspace drivers
requiring a generic kernel module. Another approach is used for mlx devices.
Thanks for checking how to improve your driver.

My other question was about documentation. I don't know your device.
Please any info or pointer?

[dpdk-dev] [PATCH] pcap: fix captured frame length

2016-01-30 Thread Dror Birkman

Hi Nicolas,

Thanks.
I tried to test my application with a pcap file I had, but got weird
results, so I wrote back the rte_mbufs in pcap format and hex compared it
to my input pcap. Only then I noticed that my original pcap had frames that
were captured with a length smaller than the frame length.

I guess you can call it pure (bad) luck :)


Dror

On Thu, Jan 28, 2016 at 8:00 PM, Nicolas Pernas Maradei <
nicolas.pernas.maradei at emutex.com> wrote:

> Hi Dror,
>
> Good catch. What you are saying makes sense and it is also explained in
> pcap's documentation. Was your setup unusual though?
> This might sound like a silly question but I don't remember seeing that
> issue and I should have since your fix is correct.
>
> Nico.
>
> On 28/01/16 08:09, Dror Birkman wrote:
>
> The actual captured length is header.caplen, whereas header.len is
> the original length on the wire.
>
> Signed-off-by: Dror Birkman   lightcyber.com>
> ---
>
>
> Without this fix, if the captured length is smaller than the original
> length on the wire, mbuf will contain incorrect data.
>
>
>  drivers/net/pcap/rte_eth_pcap.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
> index f9230eb..1d121f8 100644
> --- a/drivers/net/pcap/rte_eth_pcap.c
> +++ b/drivers/net/pcap/rte_eth_pcap.c
> @@ -220,25 +220,25 @@ eth_pcap_rx(void *queue,
>   buf_size = 
> (uint16_t)(rte_pktmbuf_data_room_size(pcap_q->mb_pool) -
>   RTE_PKTMBUF_HEADROOM);
>
> - if (header.len <= buf_size) {
> + if (header.caplen <= buf_size) {
>   /* pcap packet will fit in the mbuf, go ahead and copy 
> */
>   rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
> - header.len);
> - mbuf->data_len = (uint16_t)header.len;
> + header.caplen);
> + mbuf->data_len = (uint16_t)header.caplen;
>   } else {
>   /* Try read jumbo frame into multi mbufs. */
>   if (unlikely(eth_pcap_rx_jumbo(pcap_q->mb_pool,
>  mbuf,
>  packet,
> -header.len) == -1))
> +header.caplen) == -1))
>   break;
>   }
>
> - mbuf->pkt_len = (uint16_t)header.len;
> + mbuf->pkt_len = (uint16_t)header.caplen;
>   mbuf->port = pcap_q->in_port;
>   bufs[num_rx] = mbuf;
>   num_rx++;
> - rx_bytes += header.len;
> + rx_bytes += header.caplen;
>   }
>   pcap_q->rx_pkts += num_rx;
>   pcap_q->rx_bytes += rx_bytes;
>
>
> - no title specified @page { } table { border-collapse:collapse;
> border-spacing:0; empty-cells:show } td, th { vertical-align:top;
> font-size:12pt;} h1, h2, h3, h4, h5, h6 { clear:both } ol, ul { margin:0;
> padding:0;} li { list-style: none; margin:0; padding:0;}  li span. { clear: both; line-height:0;
> width:0; height:0; margin:0; padding:0; } span.footnodeNumber {
> padding-right:1em; } span.annotation_style_by_filter { font-size:95%;
> font-family:Arial; background-color:#fff000; margin:0; border:0; padding:0;
> } * { margin:0;} .P1_borderStart { font-size:12pt; line-height:120%;
> margin-top:0cm; font-family:Liberation Serif; writing-mode:page;
> margin-left:0.3cm; margin-right:0cm; text-indent:0cm;
> background-color:transparent; padding-bottom:0.247cm;
> border-bottom-style:none; } .P1 { font-size:12pt; line-height:120%;
> font-family:Liberation Serif; writing-mode:page; margin-left:0.3cm;
> margin-right:0cm; text-indent:0cm; background-color:transparent;
> padding-bottom:0.247cm; padding-top:0cm; border-top-style:none;
> border-bottom-style:none; } .P1_borderEnd { font-size:12pt;
> line-height:120%; margin-bottom:0.247cm; font-family:Liberation Serif;
> writing-mode:page; margin-left:0.3cm; margin-right:0cm; text-indent:0cm;
> background-color:transparent; padding-top:0cm; border-top-style:none;}
> .P2_borderStart { font-size:12pt; line-height:120%; margin-top:0cm;
> font-family:Liberation Serif; writing-mode:page; margin-left:0.3cm;
> margin-right:0cm; text-indent:0cm; background-color:transparent;
> padding-bottom:0.247cm; border-bottom-style:none; } .P2 { font-size:12pt;
> line-height:120%; font-family:Liberation Serif; writing-mode:page;
> margin-left:0.3cm; margin-right:0cm; text-indent:0cm;
> background-color:transparent; padding-bottom:0.247cm; padding-top:0cm;
> border-top-style:none; border-bottom-style:none; } .P2_borderEnd {
> font-size:12pt; line-height:120%; margin-bottom:0.247cm;
> font-family:Liberation Serif; writing-mode:page; margin-left:0.3cm;
> margin-right:0cm;

[dpdk-dev] [PATCH] cryptodev: add capabilities discovery mechanism

2016-01-30 Thread Declan Doherty

This patch add a mechanism for discovery of crypto device features and supported
crypto operations and algorithms. It also provides a method for a crypto PMD to
publish any data range limitations it may have for the operations and algorithms
it supports.

The parameter feature_flags added to rte_cryptodev struct is used to capture
features such as operations supported (symmetric crypto, operation chaining etc)
as well parameter such as whether the device is hardware accelerated or uses
SIMD instructions.

The capabilities parameter allows a PMD to define an array of supported 
operations
with any limitation which that implementation may have.

Finally the rte_cryptodev_info struct has been extended to allow retrieval of
these parameter using the existing rte_cryptodev_info_get() API.

Signed-off-by: Declan Doherty 
---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c |  19 
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  83 +
 drivers/crypto/qat/qat_crypto.c|  83 -
 drivers/crypto/qat/rte_qat_cryptodev.c |   2 +
 lib/librte_cryptodev/rte_crypto.h  |   7 ++
 lib/librte_cryptodev/rte_cryptodev.c   |  28 ++
 lib/librte_cryptodev/rte_cryptodev.h   | 123 +
 lib/librte_cryptodev/rte_cryptodev_version.map |   2 +-
 8 files changed, 345 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index d8ccf05..a759829 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -572,6 +572,7 @@ aesni_mb_pmd_dequeue_burst(void *queue_pair,
 }


+
 static int cryptodev_aesni_mb_uninit(const char *name);

 static int
@@ -622,6 +623,24 @@ cryptodev_aesni_mb_create(const char *name, unsigned 
socket_id)
dev->dequeue_burst = aesni_mb_pmd_dequeue_burst;
dev->enqueue_burst = aesni_mb_pmd_enqueue_burst;

+   dev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
+   RTE_CRYPTODEV_FF_OPERATION_CHAINING |
+   RTE_CRYPTODEV_FF_CPU_AESNI;
+
+   switch (vector_mode) {
+   case RTE_AESNI_MB_SSE:
+   dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_SSE;
+   break;
+   case RTE_AESNI_MB_AVX:
+   dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX;
+   break;
+   case RTE_AESNI_MB_AVX2:
+   dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX2;
+   break;
+   default:
+   break;
+   }
+
/* Set vector instructions mode supported */
internals = dev->data->dev_private;

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 96d22f6..368a803 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
@@ -38,6 +38,87 @@

 #include "rte_aesni_mb_pmd_private.h"

+
+static const struct rte_cryptodev_capabilities aesni_mb_pmd_capabilities[] = {
+   {   /* MD5 HMAC */
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   .sym = {
+   .type = RTE_CRYPTO_XFORM_AUTH,
+   .auth = {
+   RTE_CRYPTO_AUTH_MD5_HMAC, 64, 16, 12, { 0 }
+   }
+   }
+   },
+   {   /* SHA1 HMAC */
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   .sym = {
+   .type = RTE_CRYPTO_XFORM_AUTH,
+   .auth = {
+   RTE_CRYPTO_AUTH_SHA1_HMAC, 20, 64, 12, { 0 }
+   }
+   }
+   },
+   {   /* SHA224 HMAC */
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   .sym = {
+   .type = RTE_CRYPTO_XFORM_AUTH,
+   .auth = {
+   RTE_CRYPTO_AUTH_SHA224_HMAC, 28, 64, 14, { 0 }
+   }
+   }
+   },
+   {   /* SHA256 HMAC */
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   .sym = {
+   .type = RTE_CRYPTO_XFORM_AUTH,
+   .auth = {
+   RTE_CRYPTO_AUTH_SHA256_HMAC, 32, 64, 16, { 0 }
+   }
+   }
+   },
+   {   /* SHA384 HMAC */
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   .sym = {
+   .type = RTE_CRYPTO_XFORM_AUTH,
+   .auth = {
+   RTE_CRYPTO_AUTH_SHA384_HMAC, 48, 128, 24, { 0 }
+   }
+   }
+   },
+   {   /* SHA512 HMAC */
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   .sym = {
+   .type = RTE_CRYPTO_XFORM_AUTH,
+   .auth = {
+   RTE_CRYPTO_AUTH_SHA512_HMAC,

[dpdk-dev] [PATCH] aesni_gcm: PMD to support AES_GCM crypto operations

2016-01-30 Thread Declan Doherty

This patch provides the implementation of an AES-NI accelerated crypto PMD
which is dependent on Intel's multi-buffer library, see the white paper
"Fast Multi-buffer IPsec Implementations on Intel?  Architecture  Processors"

This PMD supports AES_GCM authenticated encryption and authenticated decryption 
using
128-bit AES keys

The patch also contains the related unit tests functions for the implemented 
functionality

Signed-off-by: Declan Doherty 
---
 MAINTAINERS|   4 +
 app/test/test_cryptodev.c  | 462 +++
 app/test/test_cryptodev_gcm_test_vectors.h | 423 +
 config/common_linuxapp |  11 +-
 config/defconfig_i686-native-linuxapp-gcc  |  10 +
 drivers/crypto/Makefile|   1 +
 drivers/crypto/aesni_gcm/Makefile  |  66 +++
 drivers/crypto/aesni_gcm/aesni_gcm_ops.h   | 127 ++
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c   | 498 +
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c   | 292 
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h   | 120 +
 .../crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map |   3 +
 lib/librte_cryptodev/rte_cryptodev.h   |   5 +
 mk/rte.app.mk  |  11 +-
 14 files changed, 2028 insertions(+), 5 deletions(-)
 create mode 100644 app/test/test_cryptodev_gcm_test_vectors.h
 create mode 100644 drivers/crypto/aesni_gcm/Makefile
 create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_ops.h
 create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
 create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
 create mode 100644 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
 create mode 100644 drivers/crypto/aesni_gcm/rte_pmd_aesni_gcm_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index b90aeea..f2b3657 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -348,6 +348,10 @@ Null PMD
 M: Tetsuya Mukawa 
 F: drivers/net/null/

+Intel AES-NI GCM PMD
+M: Declan Doherty 
+F: drivers/crypto/aesni_gcm/
+
 Intel AES-NI Multi-Buffer
 M: Declan Doherty 
 F: drivers/crypto/aesni_mb/
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index fd5b7ec..f09635f 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -43,6 +43,7 @@

 #include "test.h"
 #include "test_cryptodev.h"
+#include "test_cryptodev_gcm_test_vectors.h"

 static enum rte_cryptodev_type gbl_cryptodev_type;

@@ -70,6 +71,9 @@ struct crypto_unittest_params {
uint8_t *digest;
 };

+#define ALIGN_POW2_ROUNDUP(num, align) \
+   (((num) + (align) - 1) & ~((align) - 1))
+
 /*
  * Forward declarations.
  */
@@ -188,6 +192,23 @@ testsuite_setup(void)
}
}

+   /* Create 2 AESNI GCM devices if required */
+   if (gbl_cryptodev_type == RTE_CRYPTODEV_AESNI_GCM_PMD) {
+   nb_devs = rte_cryptodev_count_devtype(
+   RTE_CRYPTODEV_AESNI_GCM_PMD);
+   if (nb_devs < 2) {
+   for (i = nb_devs; i < 2; i++) {
+   int dev_id = rte_eal_vdev_init(
+   CRYPTODEV_NAME_AESNI_GCM_PMD, NULL);
+
+   TEST_ASSERT(dev_id >= 0,
+   "Failed to create instance %u of"
+   " pmd : %s",
+   i, CRYPTODEV_NAME_AESNI_GCM_PMD);
+   }
+   }
+   }
+
nb_devs = rte_cryptodev_count();
if (nb_devs < 1) {
RTE_LOG(ERR, USER1, "No crypto devices found?");
@@ -1685,6 +1706,392 @@ test_AES_CBC_HMAC_AES_XCBC_decrypt_digest_verify(void)
 /* * AES-GCM Tests * */

 static int
+create_gcm_session(uint8_t dev_id, enum rte_crypto_cipher_operation op,
+   const uint8_t *key, const uint8_t key_len,
+   const uint8_t aad_len, const uint8_t auth_len)
+{
+   uint8_t cipher_key[key_len];
+
+   struct crypto_unittest_params *ut_params = _params;
+
+
+   memcpy(cipher_key, key, key_len);
+
+   /* Setup Cipher Parameters */
+   ut_params->cipher_xform.type = RTE_CRYPTO_XFORM_CIPHER;
+   ut_params->cipher_xform.next = NULL;
+
+   ut_params->cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_AES_GCM;
+   ut_params->cipher_xform.cipher.op = op;
+   ut_params->cipher_xform.cipher.key.data = cipher_key;
+   ut_params->cipher_xform.cipher.key.length = key_len;
+
+#ifdef RTE_APP_TEST_DEBUG
+   rte_hexdump(stdout, "key:", key, key_len);
+#endif
+   /* Setup Authentication Parameters */
+   ut_params->auth_xform.type = RTE_CRYPTO_XFORM_AUTH;
+   ut_params->auth_xform.next = NULL;
+
+   ut_params->auth_xform.auth.algo = RTE_CRYPTO_AUTH_AES_GCM;
+
+   ut_params->auth_xform.auth.digest_length = auth_len;
+

[dpdk-dev] [PATCH] aesni_mb: strict-aliasing rule compilation fix

2016-01-30 Thread Declan Doherty

When compiling the AESNI_MB PMD with GCC on Centos 6 a "dereferencing pointer
?obj_p? does break strict-aliasing rules" warning occurs in the get_session()
function. This patch fixes this build warning.

Signed-off-by: Declan Doherty 
---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c 
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index d8ccf05..18ce176 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -299,7 +299,7 @@ aesni_mb_set_session_parameters(const struct aesni_mb_ops 
*mb_ops,
 static struct aesni_mb_session *
 get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *crypto_op)
 {
-   struct aesni_mb_session *sess;
+   struct aesni_mb_session *sess = NULL;

if (crypto_op->type == RTE_CRYPTO_OP_WITH_SESSION) {
if (unlikely(crypto_op->session->type !=
@@ -308,16 +308,19 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op 
*crypto_op)

sess = (struct aesni_mb_session *)crypto_op->session->_private;
} else  {
-   struct rte_cryptodev_session *c_sess = NULL;
+   void *_sess = NULL;

-   if (rte_mempool_get(qp->sess_mp, (void **)_sess))
+   if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;

-   sess = (struct aesni_mb_session *)c_sess->_private;
+   sess = (struct aesni_mb_session *)
+   ((struct rte_cryptodev_session *)_sess)->_private;

if (unlikely(aesni_mb_set_session_parameters(qp->ops,
-   sess, crypto_op->xform) != 0))
-   return NULL;
+   sess, crypto_op->xform) != 0)) {
+   rte_mempool_put(qp->sess_mp, _sess);
+   sess = NULL;
+   }
}

return sess;
-- 
2.5.0

[dpdk-dev] [PATCH] cryptodev: API change to rte_crypto_op bursts

2016-01-30 Thread Declan Doherty

This patch modifies the crypto burst enqueue/dequeue APIs to operate on bursts
rte_crypto_op's rather than the current implementation which operates on
rte_mbuf bursts which simplifies the burst processing in the crypto PMDs and the
use of crypto operations in general.

The changes also separates the symmetric operation parameters from the more
general operation parameters, this will  simplify the integration of
asymmetric crypto operations in the future.

As well as the changes to the crypto APIs this patch adds  function for managing
rte_crypto_op pools to the cryptodev API. It modifies the existing PMDs, unit
tests and sample application to work with the modified APIs and finally
removes the now unused rte_mbuf_offload library.

Signed-off-by: Declan Doherty 
---
 MAINTAINERS|   4 -
 app/test/test_cryptodev.c  | 713 +++--
 app/test/test_cryptodev.h  |   8 +-
 app/test/test_cryptodev_perf.c | 242 +++
 config/common_bsdapp   |   7 -
 config/common_linuxapp |   7 -
 doc/api/doxy-api-index.md  |   1 -
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 182 +++---
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c |  12 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   2 +-
 drivers/crypto/qat/qat_crypto.c| 117 ++--
 drivers/crypto/qat/qat_crypto.h|  10 +-
 drivers/crypto/qat/rte_qat_cryptodev.c |   4 +-
 examples/l2fwd-crypto/main.c   | 229 +++
 lib/Makefile   |   1 -
 lib/librte_cryptodev/rte_crypto.h  | 578 -
 lib/librte_cryptodev/rte_cryptodev.c   |  77 +++
 lib/librte_cryptodev/rte_cryptodev.h   | 105 +--
 lib/librte_cryptodev/rte_cryptodev_version.map |   1 +
 lib/librte_mbuf/rte_mbuf.h |   6 -
 lib/librte_mbuf_offload/Makefile   |  52 --
 lib/librte_mbuf_offload/rte_mbuf_offload.c | 100 ---
 lib/librte_mbuf_offload/rte_mbuf_offload.h | 307 -
 .../rte_mbuf_offload_version.map   |   7 -
 24 files changed, 1342 insertions(+), 1430 deletions(-)
 delete mode 100644 lib/librte_mbuf_offload/Makefile
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.c
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.h
 delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index b90aeea..7082e20 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -218,10 +218,6 @@ F: lib/librte_mbuf/
 F: doc/guides/prog_guide/mbuf_lib.rst
 F: app/test/test_mbuf.c

-Packet buffer offload - EXPERIMENTAL
-M: Declan Doherty 
-F: lib/librte_mbuf_offload/
-
 Ethernet API
 M: Thomas Monjalon 
 F: lib/librte_ether/
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index fd5b7ec..283395e 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 

 #include 
 #include 
@@ -48,7 +47,7 @@ static enum rte_cryptodev_type gbl_cryptodev_type;

 struct crypto_testsuite_params {
struct rte_mempool *mbuf_pool;
-   struct rte_mempool *mbuf_ol_pool;
+   struct rte_mempool *op_mpool;
struct rte_cryptodev_config conf;
struct rte_cryptodev_qp_conf qp_conf;

@@ -62,7 +61,6 @@ struct crypto_unittest_params {

struct rte_cryptodev_session *sess;

-   struct rte_mbuf_offload *ol;
struct rte_crypto_op *op;

struct rte_mbuf *obuf, *ibuf;
@@ -104,7 +102,7 @@ setup_test_string(struct rte_mempool *mpool,
return m;
 }

-#if HEX_DUMP
+#ifdef HEX_DUMP
 static void
 hexdump_mbuf_data(FILE *f, const char *title, struct rte_mbuf *m)
 {
@@ -112,27 +110,29 @@ hexdump_mbuf_data(FILE *f, const char *title, struct 
rte_mbuf *m)
 }
 #endif

-static struct rte_mbuf *
-process_crypto_request(uint8_t dev_id, struct rte_mbuf *ibuf)
+static struct rte_crypto_op *
+process_crypto_request(uint8_t dev_id, struct rte_crypto_op *op)
 {
-   struct rte_mbuf *obuf = NULL;
-#if HEX_DUMP
+#ifdef HEX_DUMP
hexdump_mbuf_data(stdout, "Enqueued Packet", ibuf);
 #endif

-   if (rte_cryptodev_enqueue_burst(dev_id, 0, , 1) != 1) {
+   if (rte_cryptodev_enqueue_burst(dev_id, 0, , 1) != 1) {
printf("Error sending packet for encryption");
return NULL;
}
-   while (rte_cryptodev_dequeue_burst(dev_id, 0, , 1) == 0)
+
+   op = NULL;
+
+   while (rte_cryptodev_dequeue_burst(dev_id, 0, , 1) == 0)
rte_pause();

-#if HEX_DUMP
+#ifdef HEX_DUMP
if (obuf)
hexdump_mbuf_data(stdout, "Dequeued Packet", obuf);
 #endif

-   return obuf;
+   return op;
 }

 static struct crypto_testsuite_params testsuite_params = {

[dpdk-dev] Errors Rx count increasing while pktgen doing nothing on Intel 82598EB 10G

2016-01-30 Thread Wiles, Keith


>
>From: Moon-Sang Lee mailto:sang0627 at gmail.com>>
>Date: Wednesday, January 27, 2016 at 1:50 AM
>To: "Keith Wiles (Intel)" mailto:keith.wiles at 
>intel.com>>
>Cc: Laurent GUERBY mailto:laurent at guerby.net>>, "dev 
>at dpdk.org" mailto:dev at dpdk.org>>
>Subject: Re: [dpdk-dev] Errors Rx count increasing while pktgen doing nothing 
>on Intel 82598EB 10G
>
>
>Laurent, have you resolved this problem?
>I'm using the same NIC as yours (i.e. Intel 82598EB 10G NIC) and faced the 
>same problem as you.
>Here is parts of my log and it says that PMD cannot enable RX queue for my NIC.
>I'm using DPDK 2.2.0 and used 'null' for the 4th parameter in calling 
>rte_eth_rx_queue_setup().
>(i.e. 'null' parameter provides the default rx_conf value.)
>
>Thanks.
>
>The problem I found with the increasing RX errors is because a stats register 
>was being read that does not exist in that given chipset and removing that 
>register read would eliminate the false errors you were seeing. Here is part 
>of the email I sent to Laurent.

The problem I found with the increasing RX errors is because a stats register 
was being read that does not exist in that given chipset and removing that 
register read would eliminate the false errors you were seeing. Here is part of 
the email I sent to Laurent.

Hi Laurent,

Well, it appears the problem is on the ixgbe driver the fccrc and fclast hw 
stats are not supported on 82598 only the 82599+ devices.

On t3 you can look at the ixgbe_ethdev.c code I modified to remove these two 
stats, which caused ierrors to increase. You can also revert any changes in 
Pktgen to master as they did not help fix any thing. Sorry is it 6 am and I 
need to sleep some, I could not sleep tonight, so you I was able to debug the 
problem. Please remove the debug code in the ixgbe driver if you like as well 
and move that change to t1 machine. I will report this to the list later.

The performance of pktgen/DPDK was not being effected by these counters.

Thanks
++Keith

[dpdk-dev] Errors Rx count increasing while pktgen doing nothing on Intel 82598EB 10G

2016-01-30 Thread Wiles, Keith

Regards,
Keith

From: Moon-Sang Lee mailto:sang0...@gmail.com>>
Date: Wednesday, January 27, 2016 at 1:50 AM
To: "Keith Wiles (Intel)" mailto:keith.wiles at 
intel.com>>
Cc: Laurent GUERBY mailto:laurent at guerby.net>>, "dev 
at dpdk.org" mailto:dev at dpdk.org>>
Subject: Re: [dpdk-dev] Errors Rx count increasing while pktgen doing nothing 
on Intel 82598EB 10G

Laurent, have you resolved this problem?
I'm using the same NIC as yours (i.e. Intel 82598EB 10G NIC) and faced the same 
problem as you.
Here is parts of my log and it says that PMD cannot enable RX queue for my NIC.
I'm using DPDK 2.2.0 and used 'null' for the 4th parameter in calling 
rte_eth_rx_queue_setup().
(i.e. 'null' parameter provides the default rx_conf value.)

Thanks.

The problem I found with the increasing RX errors is because a stats register 
was being read that does not exist in that given chipset and removing that 
register read would eliminate the false errors you were seeing. Here is part of 
the email I sent to Laurent.

Hi Laurent,

Well, it appears the problem is on the ixgbe driver the fccrc and fclast hw 
stats are not supported on 82598 only the 82599+ devices.

On t3 you can look at the ixgbe_ethdev.c code I modified to remove these two 
stats, which caused ierrors to increase. You can also revert any changes in 
Pktgen to master as they did not help fix any thing. Sorry is it 6 am and I 
need to sleep some, I could not sleep tonight, so you I was able to debug the 
problem. Please remove the debug code in the ixgbe driver if you like as well 
and move that change to t1 machine. I will report this to the list later.

The performance of pktgen/DPDK was not being effected by these counters.

Thanks
++Keith

APP: initialising port 0 ...
PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f5f27258040 
sw_sc_ring=0x7f5f27257b00 hw_ring=0x7f5f27258580 dma_addr=0x41f458580
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f5f27245940 hw_ring=0x7f5f27247980 
dma_addr=0x41f447980
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f5f272337c0 hw_ring=0x7f5f27235800 
dma_addr=0x41f435800
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_set_rx_function(): Vector rx enabled, please make sure RX burst size 
no less than 4 (port=0).
PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 0
APP: port 0 has started
APP: port 0 has entered in promiscuous mode
APP: port 0 initialization is done.
KNI: pci: 09:00:00 8086:10c7
APP: kni allocation is done for port 0.
APP: initialising port 1 ...
PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f5f27222dc0 
sw_sc_ring=0x7f5f27222880 hw_ring=0x7f5f27223300 dma_addr=0x41f423300
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f5f272106c0 hw_ring=0x7f5f27212700 
dma_addr=0x41f412700
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f5f271fe540 hw_ring=0x7f5f27200580 
dma_addr=0x41f400580
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_set_rx_function(): Vector rx enabled, please make sure RX burst size 
no less than 4 (port=1).
PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 0
APP: port 1 has started
APP: port 1 has entered in promiscuous mode
APP: port 1 initialization is done.
KNI: pci: 0a:00:00 8086:10c7
APP: kni allocation is done for port 1.

checking link status
.done
Port 0 Link Up - speed 1 Mbps - full-duplex
Port 1 Link Up - speed 1 Mbps - full-duplex

On Mon, Dec 28, 2015 at 5:28 AM, Wiles, Keith mailto:keith.wiles at intel.com>> wrote:
On 12/27/15, 2:09 PM, "Laurent GUERBY" mailto:laurent at 
guerby.net>> wrote:

>On Sun, 2015-12-27 at 19:43 +, Wiles, Keith wrote:
>> On 12/27/15, 12:31 PM, "dev on behalf of Laurent GUERBY" > dpdk.org on behalf of laurent at 
>> guerby.net> wrote:
>>
>> >Hi,
>> >
>> >I reported today an issue when using Pktgen-DPDK:
>> >https://github.com/pktgen/Pktgen-DPDK/issues/52
>> >
>> >But I think it's more in DPDK than pktgen
>> >
>> >two identical machines with SFP+ DA cable between them
>> >DPDK 2.2.0 from tarball
>> >Pktgen-DPDK from git
>> >two identical machines:
>> >core i7 2600 (sandy bridge 4C/8T), HT disabled in the BIOS
>> >ASUS P8H67-M PRO BIOS 3904 (latest available)
>> >Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF Dual Port
>> >Network Connection (rev 01)
>> >01:00.0 0200: 8086:10f1 (rev 01)
>> >Subsystem: 8086:a21f
>> >boot kernel 3.16 unbutu 14.04 with isolcpus=2,3,4
>> >
>> >When launching pktgen even with no TX asked the Errors RX counters keeps
>> >going up by about 7.4 millions per second:
>> >
>> >Errors Rx/Tx : 7471857054/0
>> >
>> >In the log I get "Could not enable Rx Queue", might be the
>> >source

[dpdk-dev] Fw: RE: DPDK vhostuser with vxlan

[dpdk-dev] lcore Access to All ports

[dpdk-dev] [PATCH] aesni_gcm: PMD to support AES_GCM crypto operations

[dpdk-dev] [PATCH 0/4] DPDK polling-mode driver for Amazon Elastic Network Adapters (ENA)

[dpdk-dev] [PATCH] pcap: fix captured frame length

[dpdk-dev] [PATCH] cryptodev: add capabilities discovery mechanism

[dpdk-dev] [PATCH] aesni_gcm: PMD to support AES_GCM crypto operations

[dpdk-dev] [PATCH] aesni_mb: strict-aliasing rule compilation fix

[dpdk-dev] [PATCH] cryptodev: API change to rte_crypto_op bursts

[dpdk-dev] Errors Rx count increasing while pktgen doing nothing on Intel 82598EB 10G

[dpdk-dev] Errors Rx count increasing while pktgen doing nothing on Intel 82598EB 10G

11 matches

Site Navigation

Mail list logo

Footer information