[dpdk-users] Issue with ipsec-secgw sample application on VM using Intel QAT device (pass-through mode)
ckdwibedy at gmail.com
Mon Jun 20 11:08:06 CEST 2016
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
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
[root at vpn-s ipsec-secgw]#
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?
More information about the users