From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id ABB8E72FB for ; Mon, 20 Jun 2016 11:08:07 +0200 (CEST) Received: by mail-wm0-f46.google.com with SMTP id f126so60296847wma.1 for ; Mon, 20 Jun 2016 02:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eT/uuQ5cPJiAdO4caEakBi2AX1cq09nz3krR/ZQ6bM0=; b=x3yU053XsOrWz3M6ypCu1QFYVMYoEXvGhGMKrmJhpVnUM8aR3Ek8xqgcb0wIEXp2ps 15jtW3HXYh8RW5hH59heu2TTwJxVNz0Jl3RfEQYoDeaspyR/HPBq92PHg1QDrAxiSKt0 htBjXrHBXnU20d78uRBPr4KuJ6JDbdqGyoK4C1ayU4cYPSpD8MC6nY/A15n4O4CInT61 CXiuZtKqjC3pMBiTqBVZf0IOZDC39B0Yfgf5jWO6DsfDtktg1WIwdUEF7RFCcLinVS/A ZQbzg9Cel1fOt2pn6Db+LnnMxtal3rpDOmDaDdWDtSA4+8o6MmRt2irqP5UzlpvD40uT sTSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eT/uuQ5cPJiAdO4caEakBi2AX1cq09nz3krR/ZQ6bM0=; b=iP8v/NmsPojax9tqEQMDft6cTwiPhSlyHsbCnMyiYB0Q4IwIF0Otf6PSihu/bmEwHa +XS9AaXveNakf1GzK8tvlkFPZ3UxD1N6+upmClNJt6fUzJM6QID20wEwvTihkNLtEyUA ofA4VTuJCYQa9JR/1lKetW1QSIYCSA8m5IH0t8fUEihzTqiaspH9YuxVhJvAZaMsnJjz PvOftQo5YJUNlAiP5ADCUP11Yz3FLAPLf0lNhAULPQ2ZZDaBir+XZiWolmmvDWcPmwQz AgBXYubLi3ysxMJe0S3rSiEudWjgRfALrUSNJnrL2UVVS8dt+9c8m4T5GAbLy4cQ150R 2bBQ== X-Gm-Message-State: ALyK8tKh9CTahqqZB27oXBevYhb6rIlDiT7o5h1FsWMcnHILnpXp/Rnx+n4BFqW9w99bcrjlec0U69E+zcqFYw== X-Received: by 10.194.56.134 with SMTP id a6mr4384860wjq.106.1466413687412; Mon, 20 Jun 2016 02:08:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.14.1 with HTTP; Mon, 20 Jun 2016 02:08:06 -0700 (PDT) In-Reply-To: References: From: Chinmaya Dwibedy Date: Mon, 20 Jun 2016 14:38:06 +0530 Message-ID: To: Sergio Gonzalez Monroy Cc: users@dpdk.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Issue with ipsec-secgw sample application on VM using Intel QAT device (pass-through mode) X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 09:08:07 -0000 Hi Sergio, Agreed. We might not dequeue the same amount of crypto ops we just previously enqueued, it's asynchronous. But in this case, I have sent just one UDP packet. So there will be one crypto ops. Right? Also I put a sleep (50) after the rte_crypto_enqueue_burst() function in ipsec_processing() (ipsec.c) , so as to allow more time ( for QAT device) for processing. Still getting the same result i.e., the rte_crypto_dequeue_burst () functio= n returns zero. In case of S/W crypto device (i.e., AESNI), the VM gets inbound UDP packets on Port 1/eth1, encapsulates (after consulting its SPD) in an IPsec ESP packet and sends to its peer through Port 0/eth0 interface. Yes, the security policy, security association and Routing entries/configurations are exactly same. Please feel free to let me know if you need additional information. Here goes my configuration file. [root@vpn-s ipsec-secgw]# cat ../../config/defconfig_x86_64-native-linuxapp-gcc #include "common_linuxapp" CONFIG_RTE_MACHINE=3D"native" CONFIG_RTE_ARCH=3D"x86_64" CONFIG_RTE_ARCH_X86_64=3Dy CONFIG_RTE_ARCH_64=3Dy CONFIG_RTE_TOOLCHAIN=3D"gcc" CONFIG_RTE_TOOLCHAIN_GCC=3Dy CONFIG_RTE_LIBRTE_PMD_AESNI_MB=3Dy CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=3Dy CONFIG_RTE_LIBRTE_VIRTIO_PMD=3Dy CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=3Dy CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=3Dy CONFIG_RTE_LIBRTE_PMD_QAT=3Dy CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_INIT=3Dy CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_TX=3Dy CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_RX=3Dy CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=3Dy [root@vpn-s ipsec-secgw]# Regards, Chinmaya On Mon, Jun 20, 2016 at 1:36 PM, Sergio Gonzalez Monroy < sergio.gonzalez.monroy@intel.com> wrote: > On 20/06/2016 08:33, Chinmaya Dwibedy wrote: > > > Hi All, > > > @Sergio: Thank you for your valuable suggestion. > > > I passed through one of VFs and it detected the QAT device in VM. I just > sent one UDP datagram which has to be encapsulated using H/W crypto devic= e > (i.e., Intel QAT). I run the ipsec-segw application with following > arguments. ./build/ipsec-secgw -l 0 -n 4 -- -p 0x3 -P > --config=3D"(0,0,0),(1,0,0)" --cdev QAT --ep0. Found that, the > rte_crypto_enqueue_burst() function returns one. It means it could able t= o > suceesfully place packet on the queue =E2=80=9Cqueue_id=E2=80=9D of the Q= AT device > designated by its =E2=80=9Cdev_id=E2=80=9D*. But The rte_crypto_dequeue_= burst() function > returns zero. It means it cannot dequeue the packet and that packet might > not have been processed by QAT device. > > > > It's expected when using crypto HW offload that you might not dequeue the > same amount of crypto ops you just previously enqueued, it's asynchronous= . > > Please note that, I have tested the same application with AESNI device an= d > did not encounter any such issue. Furthermore the > rte_crypto_dequeue_burst() API does not provide any error notification. > Can anyone please suggest what might be the issue and is there any way to > debug further? > > > Can you give a bit more details about what the issue is when using HW vs > using SW crypto? > > Are using the same config (SP/SA/RT) when using HW and SW? > > Sergio > >