[dpdk-dev] [PATCH v4 10/11] eal: replace rte_panic instances in init sequence
Arnon Warshavsky
arnon at qwilt.com
Thu Apr 19 16:48:01 CEST 2018
Copy on the commit message and volatile.
Regarding the new function defunct_and_remain_in_endless_loop ()
I don't think I can put that in a separate patch without breaking the
current patch independence.
On Thu, Apr 19, 2018 at 5:39 PM, Burakov, Anatoly <anatoly.burakov at intel.com
> wrote:
> On 19-Apr-18 7:01 AM, Arnon Warshavsky wrote:
>
>> Local functions to this file,
>> changing from void to int are non-abi-breaking.
>> For handling the single function that cannot
>> change from void to int due to abi,
>> where this is the only place it is called in,
>> I added a state variable that is being checked
>> right after the call to this function.
>>
>
> A rewrite of commit message is in order, i think :) Something like this:
>
> Change some functions' return type from void to int. This will not break
> ABI because they are internal only.
>
> (see below for comments on lcore changes)
>
>
>> --
>>
>> v4 - fix split literal strings in log messages
>>
>> Signed-off-by: Arnon Warshavsky <arnon at qwilt.com>
>>
>
> Again, please do not add patch/version notes to the commit message, put
> them after "---". Version history is not for commit messages, it's for
> people reviewing it before merge.
>
> ---
>> lib/librte_eal/bsdapp/eal/eal.c | 86 ++++++++++++++-------
>> lib/librte_eal/bsdapp/eal/eal_thread.c | 65 +++++++++++-----
>> lib/librte_eal/common/eal_common_launch.c | 21 ++++++
>> lib/librte_eal/common/include/rte_debug.h | 12 +++
>> lib/librte_eal/linuxapp/eal/eal.c | 120
>> ++++++++++++++++++++----------
>> lib/librte_eal/linuxapp/eal/eal_thread.c | 65 +++++++++++-----
>> 6 files changed, 270 insertions(+), 99 deletions(-)
>>
>> diff --git a/lib/librte_eal/bsdapp/eal/eal.c
>> b/lib/librte_eal/bsdapp/eal/eal.c
>> index d996190..9c2f6f1 100644
>> --- a/lib/librte_eal/bsdapp/eal/eal.c
>> +++ b/lib/librte_eal/bsdapp/eal/eal.c
>> @@ -151,7 +151,7 @@ enum rte_iova_mode
>> * We also don't lock the whole file, so that in future we can use
>> read-locks
>> * on other parts, e.g. memzones, to detect if there are running
>> secondary
>> * processes. */
>> -static void
>> +static int
>>
>
> <...>
>
> +
>> +/* move to panic state and do not return */
>> +static __attribute__((noreturn)) void
>> +defunct_and_remain_in_endless_loop(void)
>> +{
>> + rte_move_to_panic_state();
>> + while (1)
>> + sleep(1);
>> }
>>
>
> It seems like you're mixing two different patchsets here. Maybe it would
> be beneficial to put lcore changes in a separate patch? Technically,
> rte_panic's in lcore are not part of init sequence.
>
> (also, should panic state be volatile?)
>
>
> /* main loop of threads */
>> @@ -106,8 +123,11 @@ void eal_thread_init_master(unsigned lcore_id)
>> if (thread_id == lcore_config[lcore_id].thread_id)
>> break;
>> }
>> - if (lcore_id == RTE_MAX_LCORE)
>> - rte_panic("cannot retrieve lcore id\n");
>> + if (lcore_id == RTE_MAX_LCORE) {
>> + RTE_LOG(CRIT, EAL, "%s(): Cannot retrieve lcore id\n",
>>
>
>
> --
> Thanks,
> Anatoly
>
--
*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
<arnon at qwilt.com>*
More information about the dev
mailing list