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

Sergio Gonzalez Monroy sergio.gonzalez.monroy at intel.com
Tue Jun 21 17:40:50 CEST 2016


On 21/06/2016 08:26, Chinmaya Dwibedy wrote:
>
> Hi Sergio,
>
>
> As suggested by you, run ‘app/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.
>

In theory  you should be able to run ipsec-secgw sample app with QAT VF 
as long as the setup is right.
That the autotest fails would likely point to some possible issues with 
the setup.

Have you tried to run the autotest in the host?

Sergio

>
> 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 at intel.com 
> <mailto:sergio.gonzalez.monroy at 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 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 () 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 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.
>
>
>     Could you try to run 'app/test' application then run
>     'cryptodev_qat_autotest' ? That is a functional test for cryptodev
>     QAT PMD.
>
>     Sergio
>
>



More information about the users mailing list