Re: [dpdk-dev] [PATCH] app/pdump: exits once primary app exited

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 26-Apr-19 3:49 PM, Suanming.Mou wrote:
> 
> On 2019/4/26 22:39, Burakov, Anatoly wrote:
>> On 26-Apr-19 3:32 PM, Suanming.Mou wrote:
>>>
>>> On 2019/4/26 21:46, Burakov, Anatoly wrote:
>>>> On 26-Apr-19 1:08 PM, Suanming.Mou wrote:
>>>>>
>>>>> On 2019/4/26 18:56, Varghese, Vipin wrote:
>>>>>>
>>>>>> I will leave this suggestion open for comments from the maintainer.
>>>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for your suggestion. I have also tried to add an slave core 
>>>>> to monitor the primary status this afternoon.  It works.
>>>>>
>>>>> I doubt if it can be add an new option as you suggested, but which 
>>>>> will also require people who complain the exiting to add an extra 
>>>>> slave core for that.
>>>>>
>>>>> Please waiting for the new patch in one or two days.
>>>>>
>>>>
>>>> You can use alarm API to check for this regularly. It's not like the 
>>>> interrupt thread is doing much anyway. Just set alarm to fire every 
>>>> N seconds, and that's it.
>>>
>>> Hi,
>>>
>>> Thank you very much for the suggestion. Yes, that seems the best 
>>> solution.  Just tested it roughly as the code below:
>>>
>>> +static void monitor_primary(void *arg __rte_unused)
>>> +{
>>> +    if (quit_signal)
>>> +        return;
>>> +
>>> +    if (rte_eal_primary_proc_alive(NULL))
>>> +        rte_eal_alarm_set(MONITOR_INTERVEL, monitor_primary, NULL);
>>> +    else
>>> +        quit_signal = 1;
>>> +
>>> +    return;
>>> +}
>>> +
>>>   static inline void
>>>   dump_packets(void)
>>>   {
>>>       int i;
>>>       uint32_t lcore_id = 0;
>>>
>>> +    if (exit_with_primary)
>>> +        rte_eal_alarm_set(MONITOR_INTERVEL, monitor_primary, NULL);
>>> +
>>>
>>>
>>> I will prepare the patch with option exit_with_primary.
>>>
>>
>> Actually, i'm curious if this really does work. Unless my knowledge is 
>> out of date, interrupt thread doesn't work in secondary processes, and 
>> by extension neither should the alarm API...
> 
> Uh... If I understand correctly, the alarm API has used in the secondary 
> before.
> 
> Refer to handle_primary_request()....
> 

Then my knowledge really is out of date :)

-- 
Thanks,
Anatoly