From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from serv108.segi.ulg.ac.be (serv108.segi.ulg.ac.be [139.165.32.111]) by dpdk.org (Postfix) with ESMTP id 0ADCE11D4 for ; Wed, 30 Aug 2017 13:55:24 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be (serv470.segi.ulg.ac.be [139.165.32.199]) by serv108.segi.ulg.ac.be (Postfix) with ESMTP id 036C8200E2DE; Wed, 30 Aug 2017 13:55:24 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id E6A4C129E77B; Wed, 30 Aug 2017 13:55:23 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be ([127.0.0.1]) by localhost (mbx12-zne.ulg.ac.be [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id esCds3lGbp_C; Wed, 30 Aug 2017 13:55:23 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be (mbx12-zne.ulg.ac.be [139.165.32.199]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id C1871129E5E6; Wed, 30 Aug 2017 13:55:23 +0200 (CEST) Date: Wed, 30 Aug 2017 13:55:23 +0200 (CEST) From: tom.barbette@ulg.ac.be To: Andriy Berestovskyy Cc: Padam Jeet Singh , Ming Fu , users@dpdk.org Message-ID: <1177759951.229696.1504094123353.JavaMail.zimbra@ulg.ac.be> In-Reply-To: References: <76E92DAC-247F-41D8-B163-12248DF102C8@inventum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [139.165.248.208] X-Mailer: Zimbra 8.7.1_GA_1670 (ZimbraWebClient - GC60 (Linux)/8.7.1_GA_1670) Thread-Topic: dpdk with snort 2.9.9 receive from DPDK ring Thread-Index: NvmGHTYuVNq8xitDue7Mk4LpfGqIOg== Subject: Re: [dpdk-users] dpdk with snort 2.9.9 receive from DPDK ring X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 11:55:25 -0000 Hi all, 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 t= he daq-2.0.6, patched for DPDK and DPDK ring support.=20 The interesting file would be https://github.com/IurmanJ/daq-2.0.6/blob/mas= ter/os-daq-modules/daq_dpdkring.c . I guess you can use it to compare the d= ifference, or use that one. For autorship notice, it has been made by Justin Iurman for his master thes= is. Cheers, Tom Barbette=20 PhD Student @ Universit=C3=A9 de Li=C3=A8ge=20 ----- Mail original ----- > De: "Andriy Berestovskyy" > =C3=80: "Padam Jeet Singh" > Cc: "Ming Fu" , users@dpdk.org > Envoy=C3=A9: Mercredi 30 Ao=C3=BBt 2017 11:18:39 > Objet: Re: [dpdk-users] dpdk with snort 2.9.9 receive from DPDK ring > Hey, > 1. There is a non-EAL thread support since DPDK 2.0, so any thread can > call rte_pktmbuf_free() >=20 > 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. >=20 > Try to compile DPDK in debug mode and you might see the reason. >=20 > Andriy >=20 > On Wed, Aug 30, 2017 at 7:15 AM, Padam Jeet Singh > wrote: >> >>> On 30-Aug-2017, at 2:21 AM, Ming Fu wrote: >>> >>> I am making a snort DAQ module to receive packet from DPDK capture thro= ugh 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 init= ialized >>> 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 fr= ee 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 f= ails 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=3D, >>> obj_table=3D, mp=3D) >>> at /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:497 >>> #2 __mempool_generic_put (cache=3D, n=3D1, obj_table=3D= 0x7fffffffe6e8, >>> mp=3D) at >>> /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:1069 >>> #3 rte_mempool_generic_put (flags=3D, cache=3D, n=3D1, >>> obj_table=3D0x7fffffffe6e8, mp=3D) >>> at /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:1109 >>> #4 rte_mempool_put_bulk (n=3D1, obj_table=3D0x7fffffffe6e8, mp=3D) at >>> /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:1132 >>> #5 rte_mempool_put (obj=3D, mp=3D) at >>> /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:1150 >>> #6 rte_mbuf_raw_free (m=3D) at >>> /home/mfu/work/dpdk-17.08/build/include/rte_mbuf.h:853 >>> #7 rte_pktmbuf_free_seg (m=3D) at >>> /home/mfu/work/dpdk-17.08/build/include/rte_mbuf.h:1349 >>> #8 rte_pktmbuf_free (m=3D) at >>> /home/mfu/work/dpdk-17.08/build/include/rte_mbuf.h:1369 >>> #9 dpdk_daq_acquire (handle=3D0x1af6910, cnt=3D0, callback=3D, >>> metaback=3D, user=3D) 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" 0x00007ffff62= 969d3 in >>> epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 >>> 3 Thread 0x7fffdf4d5700 (LWP 42482) "snort" 0x00007ffff625b30d in n= anosleep >>> () 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 EA= L >> 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 hyperlink= s >> within it) may contain information that is confidential, legally privile= ged or >> otherwise protected from disclosure. If you are not the intended recipie= nt of >> this email, you are not entitled to use, disclose, distribute, copy, pri= nt, >> 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. >> >=20 >=20 >=20 > -- > Andriy Berestovskyy