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 > >
