[dpdk-users] Issue with ipsec-secgw sample application on VM using Intel QAT device (pass-through mode)

[Chinmaya Dwibedy]

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 () function
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 at vpn-s ipsec-secgw]# cat
../../config/defconfig_x86_64-native-linuxapp-gcc

#include "common_linuxapp"

CONFIG_RTE_MACHINE="native"

CONFIG_RTE_ARCH="x86_64"

CONFIG_RTE_ARCH_X86_64=y

CONFIG_RTE_ARCH_64=y



CONFIG_RTE_TOOLCHAIN="gcc"

CONFIG_RTE_TOOLCHAIN_GCC=y

CONFIG_RTE_LIBRTE_PMD_AESNI_MB=y

CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=y

CONFIG_RTE_LIBRTE_VIRTIO_PMD=y

CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=y

CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=y

CONFIG_RTE_LIBRTE_PMD_QAT=y

CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_INIT=y

CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_TX=y

CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_RX=y

CONFIG_RTE_LIBRTE_PMD_QAT_DEBUG_DRIVER=y

[root at vpn-s ipsec-secgw]#



Regards,
Chinmaya

On Mon, Jun 20, 2016 at 1:36 PM, Sergio Gonzalez Monroy <
sergio.gonzalez.monroy at 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 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() 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 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
>
>