From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 2D91C2BF4 for ; Mon, 18 Jul 2016 15:15:48 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 18 Jul 2016 06:15:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,384,1464678000"; d="scan'208";a="1008971284" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.12]) ([10.237.221.12]) by fmsmga001.fm.intel.com with ESMTP; 18 Jul 2016 06:15:46 -0700 To: Olivier Matz , "Xu, HuilongX" , "dev@dpdk.org" References: <5784D4DF.6070204@6wind.com> <0f4d2722-a9ed-1203-29df-46ad8a169cd7@6wind.com> Cc: "Cao, Waterman" , "Chen, WeichunX" , Thomas Monjalon From: Sergio Gonzalez Monroy Message-ID: <3d95435f-b253-7291-d2fd-24cba2a66ea0@intel.com> Date: Mon, 18 Jul 2016 14:15:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <0f4d2722-a9ed-1203-29df-46ad8a169cd7@6wind.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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 13:15:48 -0000 On 18/07/2016 12:49, Olivier Matz wrote: > 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. If that is the case then I would suggest to zero all memory on EAL init (only for Xen) so all memory is zeroed after init for both Linux and Xen. What do you think about that? Regards, Sergio > >>> --- 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