From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 078B47E6A for ; Mon, 20 Jun 2016 10:06:12 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 20 Jun 2016 01:06:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,497,1459839600"; d="scan'208,217";a="1005711915" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.32]) ([10.237.221.32]) by fmsmga002.fm.intel.com with ESMTP; 20 Jun 2016 01:06:10 -0700 To: Chinmaya Dwibedy References: Cc: users@dpdk.org From: Sergio Gonzalez Monroy Message-ID: Date: Mon, 20 Jun 2016 09:06:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 08:06:13 -0000 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 device (i.e., Intel QAT). I run the ipsec-segw application with > following arguments. ./build/ipsec-secgw -l 0 -n 4 -- -p 0x3 -P > --config="(0,0,0),(1,0,0)" --cdev QAT --ep0. Found that, the > rte_crypto_enqueue_burst() function returns one. It means it could > able to suceesfully place packet on the queue “queue_id” of the QAT > device designated by its “dev_id”*. But The > rte_crypto_dequeue_burst() functionreturns 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 > and 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