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 C66A67CCC for ; Sat, 2 Sep 2017 11:42:26 +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 BE240200EEAD; Sat, 2 Sep 2017 11:42:26 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id AB61E129EAD9; Sat, 2 Sep 2017 11:42:26 +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 MczhC1ngIheS; Sat, 2 Sep 2017 11:42:26 +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 00259129EAD8; Sat, 2 Sep 2017 11:42:25 +0200 (CEST) Date: Sat, 2 Sep 2017 11:42:25 +0200 (CEST) From: tom.barbette@ulg.ac.be To: Ming Fu Cc: users@dpdk.org, justin iurman Message-ID: <801801069.1605068.1504345345920.JavaMail.zimbra@ulg.ac.be> In-Reply-To: References: <76E92DAC-247F-41D8-B163-12248DF102C8@inventum.net> <1177759951.229696.1504094123353.JavaMail.zimbra@ulg.ac.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [109.89.210.248] 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: AdMhCIjMMcbfqufVSFGBQ7RCk7Cd8AAZ/hOAAAh/RoAABXlOgABfvR/AaX7EK94= 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: Sat, 02 Sep 2017 09:42:27 -0000 Hi, Yes it was done with DPDK 17.02, it is still fairly recent though. DPDK compile process is very rigid and intended to be somehow "the master",= adding some files using the propose technique. It is very difficult to hoo= k into it for big programs like Snort. We managed to do it with the Click M= odular Router, but that leads to a lot of maintainance efforts, backporting= changes from some rte.*.mk with each versions. The solution in our Snort DPDK RING DAQ (based on someone else's DPDK DAQ) = is to lib against Click compiled in combined library mode, simply using -ld= pdk. I think it is also what OVS does. They definitely did it before but no= w they seem to use some perl script, not sure if they still do that or live= -patch the compile rte*mk. Tom ----- Mail original ----- > De: "Ming Fu" > =C3=80: "tom barbette" > Cc: users@dpdk.org > Envoy=C3=A9: Vendredi 1 Septembre 2017 16:17:11 > Objet: RE: [dpdk-users] dpdk with snort 2.9.9 receive from DPDK ring > Hi Tom, >=20 > Thanks for share with me the dpdkring DAQ. I tried to use it with dpdk-17= .08. It > seems to be coded for an older version of DPDK, some API call has missing > argument. I assume these are extras added to the newer version of DPDK. >=20 > Conceptually, my code is the very similar to yours. However, I haven't ma= nage to > include >=09include $(RTE_SDK)/mk/rte.vars.mk >=09include $(RTE_SDK)/mk/rte.extlib.mk > into the daq Makefile for dpdkring. Do you know if you have to include an= y DPDK > mk include file from DPDK mk directory? I didn't find any such change to = the > DAQ Makefile from your git repo, but the DPDK doc seems to suggest such. >=20 > Ming >=20 > -----Original Message----- > From: tom.barbette@ulg.ac.be [mailto:tom.barbette@ulg.ac.be] > Sent: August-30-17 7:55 AM > To: Andriy Berestovskyy > Cc: Padam Jeet Singh ; Ming Fu ; > users@dpdk.org > Subject: Re: [dpdk-users] dpdk with snort 2.9.9 receive from DPDK ring >=20 > Hi all, >=20 > We have a proof of concept but working implementation of DPDK ring in sno= rt > 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_dpdkr= ing.c > . I guess you can use it to compare the difference, or use that one. >=20 > For autorship notice, it has been made by Justin Iurman for his master th= esis. >=20 > Cheers, >=20 > Tom Barbette > 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 >=20 >> 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 >>>> 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_f= ree(). >>>> >>>> Seems some internal dpdk function pointer is NULL. >>>> #0 0x0000000000000000 in ?? () >>>> #1 0x00000000004f7a8d in rte_mempool_ops_enqueue_bulk (n=3D>>> out>, 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=3D0x7fffffffe6e8, mp=3D) at >>>> /home/mfu/work/dpdk-17.08/build/include/rte_mempool.h:1069 >>>> #3 rte_mempool_generic_put (flags=3D, cache=3D>>> out>, 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>>> out>, 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" 0x00007ffff6= 2969d3 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 po= licies. >>> >>=20 >>=20 >>=20 >> -- > > Andriy Berestovskyy