From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by dpdk.org (Postfix) with ESMTP id 906A6FFA for ; Wed, 30 Aug 2017 11:19:00 +0200 (CEST) Received: by mail-lf0-f42.google.com with SMTP id d17so22296465lfe.1 for ; Wed, 30 Aug 2017 02:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WlY6/HLOzGNwdxsGNBHumve4YHbNnHlEj2aQoXPWyt4=; b=eMrCd6EH09pGSnNXl5ic6sW/L5nm7qz8XySZJkNP5qLGx0QUx5k0ZmDCQmunQuoYoc UkWjcYXPJZ/2XDpUuUPlogMQ+USc9W/GbJljs+xmwB6I8S13L+WVNMAvhubZgeQQBlO+ SToxyTs4KrqTpsn9xzBOFPspXAcY9kmJvddZ2CAFWVl1o4WC07jd1joS+SIumFD+RKuQ DqDFGodIg0tjpAE0TW9x00a3E9EzT5O6DQr+a1o0dfr3us/wOphnxsyulenll256HUfr k74pIF5GPQT+GpHjzgOfQpVwmlXG0wY4HeFq2xvK84fM3a/kPUcMcJb0VYfxwBvlZFtN fupQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WlY6/HLOzGNwdxsGNBHumve4YHbNnHlEj2aQoXPWyt4=; b=qakBJUPQrAQgfByxyyBF3z8pak+Kcgp16Gh74P4XCnrvtuEFKC/UHP5LEbX+1IUDTT sxfL5/Covovhzp0RaV+w1QnEembrPXD9VNQMcHjT1bx4EUttxScFNp+vQY2vJRqMyeLd Y66QCbPaIvpxSz+d74UWiuO7i2R39lpfvmqg8+oc5osNq2TNHiTVsztgI5+62xYSOTFC JRTVQ2TayLTBE+9rwShwzwx+Bju50eI78SCNLbL/tvnRoP+VJACT8bobS94UQM+m5XIx d+G+WjWLlM46vo7vdqFk/CDbjwphSPxvWZlwPrVndVQR0QyM3lLLblSSZfdHOM6y72Fc gKLw== X-Gm-Message-State: AHPjjUgb9srGtWdP4gKf+yx7rA7J1//UKGkoLmUpKd6836LvlaHf6W0b 3dLnJMbUvKEXfC8ZHfT8rAi7va6GEqnbNKoNFQ== X-Received: by 10.25.213.143 with SMTP id m137mr417419lfg.116.1504084739847; Wed, 30 Aug 2017 02:18:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.0.8 with HTTP; Wed, 30 Aug 2017 02:18:39 -0700 (PDT) In-Reply-To: <76E92DAC-247F-41D8-B163-12248DF102C8@inventum.net> References: <76E92DAC-247F-41D8-B163-12248DF102C8@inventum.net> From: Andriy Berestovskyy Date: Wed, 30 Aug 2017 11:18:39 +0200 Message-ID: To: Padam Jeet Singh Cc: Ming Fu , "users@dpdk.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 09:19:00 -0000 Hey, 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. Andriy 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 throu= gh a ring. The snort version is 2.9.9 and DPDK version is 17.08. The code i= s very similar to the multi_process/client_server_mp example. The DPDK is i= nitialized in daq initialize function and mbuf received from daq acquire fu= nction. 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 ca= lls rte_ring_dequeue_burst(); >> The snort successfully received the first burst of 32 packets, but it fa= ils 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=3D0= x7fffffffe6e8, mp=3D) at /home/mfu/work/dpdk-17.08/build/inc= lude/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 /ho= me/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:23= 4 >> #10 0x00000000004551d3 in DAQ_Acquire () >> #11 0x0000000000437828 in SnortMain () >> #12 0x00007ffff61af830 in __libc_start_main () from /lib/x86_64-linux-gn= u/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" 0x00007ffff629= 69d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 >> 3 Thread 0x7fffdf4d5700 (LWP 42482) "snort" 0x00007ffff625b30d in na= nosleep () from /lib/x86_64-linux-gnu/libc.so.6 >> >> Would it be a problem if the rte_pktmbuf_free() is not called from the e= al thread? >> > > The rte_mbuf_free internally calls rte_mempool put calls - which should o= nly be called from a EAL thread - so yes, only call rte_pktmbuf_free from a= n EAL thread. > >> Thanks >> Ming >> >> >> >> >> > > > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= --- > NOTICE > > Please Consider the Environment before printing this Email. > > This email was sent from within Inventum Technologies Private Limited (ht= tps://www.inventum.net). This email (and any attachments or hyperlinks with= in 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, 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 f= ree from computer viruses and the like. However, it is the recipient's resp= onsibility to ensure that it is actually virus free. Any emails that you se= nd to us may be monitored for the purposes of ascertaining whether the comm= unication complies with the law and our policies. > --=20 Andriy Berestovskyy