From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 66D02DE0 for ; Mon, 18 Jul 2016 13:49:37 +0200 (CEST) Received: from alille-653-1-293-182.w90-1.abo.wanadoo.fr ([90.1.53.182] helo=[192.168.1.13]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bP75j-0002qi-Pb; Mon, 18 Jul 2016 13:52:10 +0200 To: Sergio Gonzalez Monroy , "Xu, HuilongX" , "dev@dpdk.org" References: <5784D4DF.6070204@6wind.com> Cc: "Cao, Waterman" , "Chen, WeichunX" , Thomas Monjalon From: Olivier Matz Message-ID: <0f4d2722-a9ed-1203-29df-46ad8a169cd7@6wind.com> Date: Mon, 18 Jul 2016 13:49:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] mutli process C/S model example init failed on xen dom0 with dpdk-16.07 rc2 package X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 11:49:37 -0000 Hi Sergio, On 07/18/2016 01:33 PM, Sergio Gonzalez Monroy wrote: > On 12/07/2016 12:30, Olivier MATZ wrote: >> On 07/12/2016 11:22 AM, Xu, HuilongX wrote: >>> /examples/multi_process/client_server_mp/mp_server/mp_server/x86_64-native-linuxapp-gcc/mp_server >>> >>> -c f -n 4 --xen-dom0 -- -p 0x3 -n 2 >>> EAL: Detected 72 lcore(s) >>> EAL: Probing VFIO support... >>> PMD: bnxt_rte_pmd_init() called for (null) >>> EAL: PCI device 0000:01:00.0 on NUMA socket 0 >>> EAL: probe driver: 8086:1521 rte_igb_pmd >>> EAL: PCI device 0000:01:00.1 on NUMA socket 0 >>> EAL: probe driver: 8086:1521 rte_igb_pmd >>> EAL: PCI device 0000:04:00.0 on NUMA socket 0 >>> EAL: probe driver: 8086:10fb rte_ixgbe_pmd >>> EAL: PCI device 0000:04:00.1 on NUMA socket 0 >>> EAL: probe driver: 8086:10fb rte_ixgbe_pmd >>> Creating mbuf pool 'MProc_pktmbuf_pool' [6144 mbufs] ... >>> Port 0 init ... Segmentation fault (core dumped) >>> >> >> I reproduced the issue on my platform. In my case, the crash occurs in >> rx_queue_setup(): >> >> /* Free memory prior to re-allocation if needed. */ >> if (dev->data->rx_queues[queue_idx] != NULL) { >> => em_rx_queue_release(dev->data->rx_queues[queue_idx]); >> dev->data->rx_queues[queue_idx] = NULL; >> } >> >> I don't this we should go in that area for the first rx queue >> initialization. I suspect it could be related to this commit: >> http://dpdk.org/browse/dpdk/commit/?id=ea0bddbd14e68f >> >> I think we cannot expect that memory is initialized at 0 when using >> Xen dom0. If I add the following (dirty) patch, I don't see a crash >> anymore: > > I don't have a Xen system available right now, but I'm not sure I follow > here. > Are you saying that when we allocate pages/hugepages from Xen they are > not zeroed? I did not check it, but from the tests I've done, I suppose they're not. >> --- a/lib/librte_eal/common/eal_common_memzone.c >> +++ b/lib/librte_eal/common/eal_common_memzone.c >> @@ -258,6 +258,8 @@ memzone_reserve_aligned_thread_unsafe(const char >> *name, size_t len, >> mz->flags = 0; >> mz->memseg_id = elem->ms - >> rte_eal_get_configuration()->mem_config->memseg; >> >> + memset(mz->addr, 0, mz->len); >> + >> return mz; >> } >> > > The commit you are referring to does not touch the memzone reserve APIs, > only changes zmalloc and related APIs. I just did a quick test, adding the memset() at the places where I thought it could be required. Maybe the patch is a bit overkill and only the zmalloc part fixes the issue. Regards, Olivier