Re: [dpdk-dev] mutli process C/S model example init failed on xen dom0 with dpdk-16.07 rc2 package

[Olivier Matz <olivier.matz@6wind.com>]

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