[dpdk-dev] [PATCH v3] eal: remove non-thread panic calls from init sequence

Arnon Warshavsky arnon at qwilt.com
Mon Jun 3 16:05:45 CEST 2019


Hi


>
> The part below can go after a --- marker, this is more a comment for the
> work in progress rather than something to put in this patch commitlog.
>
Ack

>
> The calls for launching core messaging threads were left in tact
>> in all 3 eal implementations.
>>
>

> For these I will submit a patch suggesting a callback registration,
>> allowing the user to register a context to be called
>> in case of a panic that takes place outside the init sequence.
>>
>
> Not sure I understand what you want to do, but at least this patch is a
> first step.
>
Promise to be less vague in the actual patch :)

>
>
>> +                       RTE_LOG(ERR, EAL, "Cannot open '%s' for
>> rte_mem_config\n",
>> +                                       pathname);
>>
>
> Fix indent please, and in subsequent uses of RTE_LOG in this patch.
>
Ack

>
>
>> When we close this fd, we need to reset the variable pointing to it to -1
> or subsequent call would reuse an incorrect mem_cfg_fd.
> The problem is general in both linux and freebsd eal.c but something is
> still not clear to me in how we are supposed to keep this fd opened or not
> in normal successfull init case.
>

In this case we are on the way out from the process in the shortest way out
so no subsequent calls expected , but I agree for the sake of good order.
Will zero those

>
> +               if (rte_eal_config_create() < 0) {
>>
> +                       RTE_LOG(ERR, EAL, "Failed to create config\n");
>>
>
> All error paths in rte_eal_config_create() have a log.
> Adding one more here won't help and we have another one coming with the
> rte_eal_init_alert later.
>
> This comment goes for linux changes as well.
>
Agree. Will fix that

thanks
/Arnon


More information about the dev mailing list