Re: [dpdk-users] dpdk with snort 2.9.9 receive from DPDK ring

[Padam Jeet Singh <padam.singh@inventum.net>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4123 bytes --]


> On 30-Aug-2017, at 2:21 AM, Ming Fu <Ming.Fu@esentire.com> wrote:
>
> I am making a snort DAQ module to receive packet from DPDK capture through a ring. The snort version is 2.9.9 and DPDK version is 17.08. The code is very similar to the multi_process/client_server_mp example. The DPDK is initialized in daq initialize function and mbuf received from daq acquire function. Snort inspects the mbuf but does not re-inject back to the network, so daq free the mbuf by rte_pktmbuf_free(mbuf) in the same thread as it calls rte_ring_dequeue_burst();
> The snort successfully received the first burst of 32 packets, but it fails on the first rte_pktmbuf_free().
>
> Seems some internal dpdk function pointer is NULL.
> #0  0x0000000000000000 in ?? ()
> #1  0x00000000004f7a8d in rte_mempool_ops_enqueue_bulk (n=<optimized out>, obj_table=<optimized out>, mp=<optimized out>)
>    at /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:497
> #2  __mempool_generic_put (cache=<optimized out>, n=1, obj_table=0x7fffffffe6e8, mp=<optimized out>) at /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:1069
> #3  rte_mempool_generic_put (flags=<optimized out>, cache=<optimized out>, n=1, obj_table=0x7fffffffe6e8, mp=<optimized out>)
>    at /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:1109
> #4  rte_mempool_put_bulk (n=1, obj_table=0x7fffffffe6e8, mp=<optimized out>) at /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:1132
> #5  rte_mempool_put (obj=<optimized out>, mp=<optimized out>) at /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:1150
> #6  rte_mbuf_raw_free (m=<optimized out>) at /home/mfu/work/dpdk-17.08/build/include/rte_mbuf.h:853
> #7  rte_pktmbuf_free_seg (m=<optimized out>) at /home/mfu/work/dpdk-17.08/build/include/rte_mbuf.h:1349
> #8  rte_pktmbuf_free (m=<optimized out>) at /home/mfu/work/dpdk-17.08/build/include/rte_mbuf.h:1369
> #9  dpdk_daq_acquire (handle=0x1af6910, cnt=0, callback=<optimized out>, metaback=<optimized out>, user=<optimized out>) at daq_dpdk.c:234
> #10 0x00000000004551d3 in DAQ_Acquire ()
> #11 0x0000000000437828 in SnortMain ()
> #12 0x00007ffff61af830 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
> #13 0x0000000000406d29 in _start ()
>
> I notice that snort has three threads,
> (gdb) info thread
>  Id   Target Id         Frame
> * 1    Thread 0x7ffff7fdf8c0 (LWP 42472) "snort" 0x0000000000000000 in ?? ()
>  2    Thread 0x7fffdff5a700 (LWP 42481) "eal-intr-thread" 0x00007ffff62969d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
>  3    Thread 0x7fffdf4d5700 (LWP 42482) "snort" 0x00007ffff625b30d in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
>
> Would it be a problem if the rte_pktmbuf_free() is not called from the eal thread?
>

The rte_mbuf_free internally calls rte_mempool put calls - which should only be called from a EAL thread - so yes, only call rte_pktmbuf_free from an EAL thread.

> Thanks
> Ming
>
>
>
>
>



-------------------------------------------------------------------------------------------------------------------------------------------------------
NOTICE

Please Consider the Environment before printing this Email.

This email was sent from within Inventum Technologies Private Limited (https://www.inventum.net). This email (and any attachments or hyperlinks within it) may contain information that is confidential, legally privileged or otherwise protected from disclosure. If you are not the intended recipient of this email, you are not entitled to use, disclose, distribute, copy, print, disseminate or rely on this email in any way. If you have received this email in error, please notify the sender immediately by telephone or email and destroy it, and all copies of it.

We have taken steps to ensure that this email (and any attachments) are free from computer viruses and the like. However, it is the recipient's responsibility to ensure that it is actually virus free. Any emails that you send to us may be monitored for the purposes of ascertaining whether the communication complies with the law and our policies.