On Mon, Jan 25, 2021 at 12:07 PM oulijun <ouli...@huawei.com> wrote:
> >> +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
