[dpdk-users] Fwd: Issue in Dequeue Operations

Sami Ullah sami.ullah2316 at gmail.com
Thu Dec 6 03:54:30 CET 2018


I am trying to develop a custom application using DPDK API. My application
scenario is like Host2Host encryption/decryption using single port and my
hardware is intel *X520* NIC.
The problem is in the dequeue operations, and in my testing i think the
problem is in queue argument. I am using one queue for* aesni based crypto
device* and crypto type is NONE.
1- If i skip *rte_crypto_enqueue_burst()*, then application does not crash
but surely there will be no packet in *rte_crypto_dequeue_burst().*
2- if I don't skip rte_crypto_enqueue_burst() and use same queue 0 in
rte_crypto_dequeue_burst(), application crashes. And if i set #packets to
0, no crash.

Initially, I though may be we can't use same queue in enqueue and dequeue
operation but after analyzing DPDK crypto examples that is possible. When
application crashed, i receive following error.:
dumping 9 stack frame addresses:
  /lib/x86_64-linux-gnu/libpthread.so.0 @ 0x7fd58b97f000 [0x7fd58b991890]
    -> ??:?
  /usr/local/lib/x86_64-linux-gnu/dpdk/drivers/librte_pmd_aesni_mb.so.1.1 @
0x7fd58678a000 [0x7fd58678f041]
    -> rte_aesni_mb_pmd.c:?
  /usr/local/lib/ipsec/libipsec.so.0 @ 0x7fc56e2b5000
(ipsec_outbound+0x917) [0x7fc56e2c2c57]
    -> /usr/include/x86_64-linux-gnu/bits/stdio2.h:104
  /usr/local/lib/ipsec/libipsec.so.0 @ 0x7fc56e2b5000
(process_pkts_outbound+0x2c2) [0x7fc56e2bd992]
    -> /usr/include/x86_64-linux-gnu/bits/stdio2.h:104
  /usr/local/lib/ipsec/libipsec.so.0 @ 0x7fc56e2b5000
(process_unprotected+0x76) [0x7fc56e2bdeb6]
  /usr/local/lib/ipsec/libipsec.so.0 @ 0x7fc56e2b5000
(dpdk_processing_job+0x24e) [0x7fc56e2be35e]
    -> /usr/local/include/generic/rte_atomic.h:541
  /usr/local/lib/x86_64-linux-gnu/librte_eal.so.9 @ 0x7fd58cf72000
    -> :?
  /lib/x86_64-linux-gnu/libpthread.so.0 @ 0x7fd58b97f000 [0x7fd58b9866db]
    -> /build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463
  /lib/x86_64-linux-gnu/libc.so.6 @ 0x7fd58b58e000 (clone+0x3f)
18[DMN] killing ourself, received critical signal

One thing* worth mentioning*, applications breaks with same error message
if i use wrong queue pair id like 1 instead of 0. So may be crypto queue is
captured by rte_crypto_enqueue_burst() but I am confused and don't have
further clue.

kind regards,

More information about the users mailing list