On Mon, Jan 25, 2021 at 12:07 PM oulijun [off-list ref] wrote:

quoted

quoted

+static void
+signal_handler(int signal)
+{
+       if (signal == SIGINT)
+               rte_eal_cleanup();
+       exit(0);
+}

Calling rte_eal_cleanup from a signal handler is a bad idea.
In most cases, you are racing with other threads still using DPDK resources.
https://git.dpdk.org/dpdk/commit?id=2c434431f4
https://git.dpdk.org/dpdk/commit?id=613ce6691c

This might not be a problem in this multi_process example, but let's
keep a consistent way across all examples.
Thanks.

Hi，
   I want to know why you don't think he's a problem. recently, we use
the patch
https://patchwork.dpdk.org/patch/86988/
startup with multiprocess. Use the tester to send traffic and kill the
slave process repeatedly.
The coredump exception occurs. According to my analysis, the cause is
that resources are not released after the slave process is killed.

Not sure I get your question and I don't see the relation with the
testpmd patch.
I did not say we must not release resources.

Just to rephrase my previous mail:

Generally speaking, calling rte_eal_cleanup() from a signal handler is
wrong since it creates races with other threads.
I recommend putting in place a synchronisation mechanism so that all
worker threads break out of their processing loop and the main thread
synchronizes/joins with them before calling rte_eal_cleanup() in its
exit path.

Now, for this patch, in
examples/multi_process/client_server_mp/mp_client/client.c, this
secondary process code seems to only have one thread (but I might be
wrong).
If this is true, then no race in theory => my comment "This might not
be a problem in this multi_process example".


-- 
David Marchand