From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) by dpdk.org (Postfix) with ESMTP id 43B39ADCA for ; Tue, 21 Jun 2016 09:26:09 +0200 (CEST) Received: by mail-lf0-f46.google.com with SMTP id l188so9714859lfe.2 for ; Tue, 21 Jun 2016 00:26:09 -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=PDoV59/5YBz0opLJU67i5YCgEBKC5cKBWDrXNLQlq7M=; b=i/U5RRLOG7RdzgKW+1gCvcUJ/HZvBsmbhsoGKf7soBktYcXwEZAmYwVnj1Q0AkTxGG H59NEieBtl4T6pHidwfgkTRV9OrMc2FR7RW/A5TDlSj/gWblEn5gN3Gy1FwgJTZkRclX WxU4PVDG9CG1dRvP20uZ9IFbPZ3d5IYp7EkrdQSvgi4QY+lG5HH1cSrwQDN+TfQBGhfs /NVgS6uB8HbFhcTp0XcW3hXO4guYMK7G0KvmpEdb+irc3yy7qbTtkHyukibHCFty5ynk 1wWTqOF0ve+oBJH7b6/gi5O+yjQ8GP+9ioYVt+1YI1ljX8GTE9nvZWkrf28WvW9o0W5i 4nrw== 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=PDoV59/5YBz0opLJU67i5YCgEBKC5cKBWDrXNLQlq7M=; b=e4E16Jl5FHO/7ppD1c1vnh1wo5a7ki6dP4cUsoQMRd66Lk0lquHc6v4xeXKGpzAAJG pnh8ZIl0U5hLHFlP9GNvSUcgzEc8DL2rHmyiE95r8m/1dpDjvQXKJ4vgQ6jfPXAIWzv1 /bgO4QncSjSulyE2Y1U01cDbHV7FdGhpcKdriJQKx63FUZgrRe9Sv1XwI4i+Va7uIcoS xNwQmidRx0IarhPm9mhuLKhL/54wBQiBvUg7dBXHgLJE+iyd2LJMpS+niJpx4NV8xBGS EhrCafUL/NWATf2Exee7jrJ7f7iPUsaT3F+SOaml/LZ4KC32jUe3iK1DTp29OheG73J3 DdRQ== X-Gm-Message-State: ALyK8tJ3ymg6ogC+fdF7EJ86/+QzDSGCooPNPTgnWsHNt7WhZsfGekSWBhlz4EIUVbgw9XNb7YwJyJATQEKG3g== X-Received: by 10.28.218.10 with SMTP id r10mr1708047wmg.18.1466493968681; Tue, 21 Jun 2016 00:26:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.14.1 with HTTP; Tue, 21 Jun 2016 00:26:08 -0700 (PDT) In-Reply-To: <6e0329b1-d67c-3b23-55d2-dc88b78f6f2a@intel.com> References: <6e0329b1-d67c-3b23-55d2-dc88b78f6f2a@intel.com> From: Chinmaya Dwibedy Date: Tue, 21 Jun 2016 12:56:08 +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: Tue, 21 Jun 2016 07:26:09 -0000 Hi Sergio, As suggested by you, run =E2=80=98app/test' application and then run 'cryptodev_qat_autotest' . Found the same issue i.e., It halts in rte_cryptodev_dequeue_burst () (while loop) in process_crypto_request () function (app/test/test_cryptodev.c). Debugged the qat_crypto_pkt_rx_burst() (in drivers/crypto/qat/qat_crypto.c) and found that , the value of resp_msg is 0x7F7F7F7F (i.e., ADF_RING_EMPTY_SIG) . Thus it is not getting crypto packet (i.e., rte_mbuf) from the RX queue. But I find that, in qat_crypto_pkt_tx_burst(), the qat_alg_write_mbuf_entry() is being called. The qat_alg_write_mbuf_entry () prints qat_req using rte_hexdump () and returns zero. One question, the base_addr + tail of tx_q (in qat_crypto_pkt_tx_burst()) should be same as base_addr + head (in qat_crypto_pkt_rx_burst()). Right ? Please feel free to correct me if I am wrong. Also can you please provide some pointers for further debugging? Would it be configuration issue? Note that, I am using VF in VM. Thank you once again for your prompt response and great support. Regards, Chinmaya On Mon, Jun 20, 2016 at 3:04 PM, Sergio Gonzalez Monroy < sergio.gonzalez.monroy@intel.com> wrote: > On 20/06/2016 10:08, Chinmaya Dwibedy wrote: > >> >> 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 ju= st >> one UDP packet. So there will be one crypto ops. Right? Also I put a sl= eep >> (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 () >> functionreturns 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 IP= sec >> 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. >> >> > Could you try to run 'app/test' application then run > 'cryptodev_qat_autotest' ? That is a functional test for cryptodev QAT PM= D. > > Sergio > >