[dpdk-users] dpdk with snort 2.9.9 receive from DPDK ring
tom.barbette at ulg.ac.be
tom.barbette at ulg.ac.be
Wed Aug 30 13:55:23 CEST 2017
We have a proof of concept but working implementation of DPDK ring in snort available here : https://github.com/IurmanJ/daq-2.0.6/. It is a clone of the daq-2.0.6, patched for DPDK and DPDK ring support.
The interesting file would be https://github.com/IurmanJ/daq-2.0.6/blob/master/os-daq-modules/daq_dpdkring.c . I guess you can use it to compare the difference, or use that one.
For autorship notice, it has been made by Justin Iurman for his master thesis.
PhD Student @ Université de Liège
----- Mail original -----
> De: "Andriy Berestovskyy" <aber at semihalf.com>
> À: "Padam Jeet Singh" <padam.singh at inventum.net>
> Cc: "Ming Fu" <Ming.Fu at esentire.com>, users at dpdk.org
> Envoyé: Mercredi 30 Août 2017 11:18:39
> Objet: Re: [dpdk-users] dpdk with snort 2.9.9 receive from DPDK ring
> 1. There is a non-EAL thread support since DPDK 2.0, so any thread can
> call rte_pktmbuf_free()
> 2. From the traceback it looks like the memory pool enqueue() op is
> NULL for a reason. Note that to free an mbuf, the mbuf header should
> be valid and point to a valid memory pool mbuf belongs.
> Try to compile DPDK in debug mode and you might see the reason.
> On Wed, Aug 30, 2017 at 7:15 AM, Padam Jeet Singh
> <padam.singh at inventum.net> wrote:
>>> On 30-Aug-2017, at 2:21 AM, Ming Fu <Ming.Fu at 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
>>> 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
>>> #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
>>> #5 rte_mempool_put (obj=<optimized out>, mp=<optimized out>) at
>>> #6 rte_mbuf_raw_free (m=<optimized out>) at
>>> #7 rte_pktmbuf_free_seg (m=<optimized out>) at
>>> #8 rte_pktmbuf_free (m=<optimized out>) at
>>> #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
>>> #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
>> 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
>> 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.
> Andriy Berestovskyy
More information about the users