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
