From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 74A041075 for ; Mon, 20 Mar 2017 14:05:18 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id u132so62931324wmg.0 for ; Mon, 20 Mar 2017 06:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=fg2YvnCH28VJB41ugtTIw+a1hedgtyKtYaIjqH1y48I=; b=e/e2uAWjBvvVShRKCqExhVBBN2Lpjhu6rsn9cUJhA1XJO25s3geyCkc07Q+ycO3pwQ yXyYyFp1DkxZXSwfiebpGW1I4Ngf7cGqBfKF30PnlVfV1zCHltE5On2Fbi1EQ4pnoREE AcV9jDElxDeAkwyrEw+nCEDCAcyLCkW+a8UmEdl4OiJfD9PWekDHdVpRT9SLdv8FRte8 KGLQfvn1VOynnKa88jLejR9gC1U6f+5SxhnC9B+KO4JO0vj6q8m+4Z0LikKRJZ/Daz+P s0bu4X2dS+I70UXvr72SqnsbyK9voWikaOPDzkXWYr33bLBzxRIEebCFKRSTW6ac814D /ELg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=fg2YvnCH28VJB41ugtTIw+a1hedgtyKtYaIjqH1y48I=; b=HB0syPrKcoYA5LAgHi9Lmj0U/0vG5PXtueO59DtHG4Au3Gj1VolUFnvbqa5NG2rt1s aAR/Y5znZED4dJqx4aNrq2wxhPNuoFnc/BIGn+upnkEeoEpjahJiDxXbEJD058Cmg+Hs DLFhSGGPs1ItzogSXgh8a4UgwRhJAu+5sytL9HHIpBc9bnJVKgNtYPQk5pVq2lsCu+M1 E6+AlqassraoeRjmH0CHhrl4t37KFVMqiMsBDHkpjKSoc0YqovKaGdKgYe9XfAbLCa1L TqDGFeI580wH4IyLc1CAjBaDejLa5B/ON2Bm6+e2RoYHVIPG8OH8mlNmQNIa6VSvXMkO EGIw== X-Gm-Message-State: AFeK/H0WY3Jw1zeqvgUwKpZM9dslXhE7nAFu7pCVw+zYXohJa2L0IAvdVAEMlhwvlL4hICaC X-Received: by 10.28.48.78 with SMTP id w75mr10844171wmw.55.1490015118062; Mon, 20 Mar 2017 06:05:18 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id 32sm20720661wrr.64.2017.03.20.06.05.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 20 Mar 2017 06:05:17 -0700 (PDT) Date: Mon, 20 Mar 2017 14:05:15 +0100 From: Olivier Matz To: Yuanhan Liu Cc: "Dey, Souvik" , "dev@dpdk.org" , Thomas Monjalon Message-ID: <20170320140515.45c91b61@platinum> In-Reply-To: <20170317050917.GX18844@yliu-dev.sh.intel.com> References: <20170317050917.GX18844@yliu-dev.sh.intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Getting crash in rte_pktmbuf_alloc with 16.11 DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 13:05:18 -0000 Hi, On Fri, 17 Mar 2017 13:09:17 +0800, Yuanhan Liu wrote: > On Fri, Mar 17, 2017 at 03:46:53AM +0000, Dey, Souvik wrote: > > Hi , > > I am trying to do rte_pktmbuf_alloc from a mempool within a secondary process after doing a rte_mempool_lookup for the same mempool. But the rte_pktmbuf_alloc crashes with the below backtrace > > I believe it's yet another "accessing a local process pointer in a shared > memory" issue in the multiple process model. Here is a similar issue I have > just fixed for virtio pmd in last release. > > commit 6d890f8ab51295045a53f41c4d2654bb1f01cf38 > Author: Yuanhan Liu > Date: Fri Jan 6 18:16:19 2017 +0800 > > net/virtio: fix multiple process support > Another idea is that your 2 processes (primary and secondary) do not have the same configuration or build system. This was discussed a bit here: http://dpdk.org/dev/patchwork/patch/16868/ Can you provide a minimal example application that reproduces the issue? Regards, Olivier > > --yliu > > > > #0 0x0000000000000000 in ?? () > > #1 0x0000000000423da2 in rte_mempool_ops_dequeue_bulk (n=1, obj_table=0x7fffffffd8e0, mp=0x7fe910fbd540) at /sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/dist > > #2 __mempool_generic_get (flags=, cache=, n=, obj_table=, mp=) > > at /sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1296 > > #3 rte_mempool_generic_get (flags=, cache=, n=, obj_table=, mp=) > > at /sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1334 > > #4 rte_mempool_get_bulk (n=1, obj_table=0x7fffffffd8e0, mp=0x7fe910fbd540) at /sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp > > #5 rte_mempool_get (obj_p=0x7fffffffd8e0, mp=0x7fe910fbd540) at /sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/r > > #6 rte_mbuf_raw_alloc (mp=0x7fe910fbd540) at /sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mbuf.h:761 > > #7 rte_pktmbuf_alloc (mp=0x7fe910fbd540) at /sonus/p4/ws/sodey/cmn_thirdparty.cloud_dev_5_1/Intel/DPDK/distrib_upd/x86_64-native-linuxapp-gcc/include/rte_mbuf.h:1046 > > > > >From the trace it looks like that the ops->dequeue is failing as the ops is not set properly. > > In the primary process I have done a rte_mempool_create with the flags passed as 0 (indicating mp_mc option). This should have taken care of setting the ops properly. Also the rte_pktmbuf_alloc calls in the primary does not give any issues. > > Both the primary and secondary DPDK app code was working fine with 2.1 DPDK, but now when I am trying to link to the newer DPDK versions like 16.07/16.11, it is crashing. There is no changes done in the app code. > > I do see that the complete rte_mempool code has been changed between 2.1 to 16.07 but could not find any obvious reasons of the crash. Is my usage wrong or do we need to pass any new flag to make this work. > > > > Did anyone faced similar issue or any help in this will be great for my debugging. Thanks in advance for the help. > > > > -- > > Regards, > > Souvik