05/07/2022 22:44, Stephen Hemminger: > The DPDK is not designed to be used from a signal handler. > Add a notice in the documentation describing this limitation, > similar to Linux signal-safety manual page. > > Bugzilla ID: 1030 > Signed-off-by: Stephen Hemminger <step...@networkplumber.org> > Acked-by: Tyler Retzlaff <roret...@linux.microsoft.com> > Acked-by: Chengwen Feng <fengcheng...@huawei.com> > --- > doc/guides/prog_guide/env_abstraction_layer.rst | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst > b/doc/guides/prog_guide/env_abstraction_layer.rst > index 67842ae27207..de7ee92bba39 100644 > --- a/doc/guides/prog_guide/env_abstraction_layer.rst > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst > @@ -818,6 +818,21 @@ Known Issues > > The debug statistics of rte_ring, rte_mempool and rte_timer are not > supported in an unregistered non-EAL pthread. > > ++ signal safety > + > + The DPDK library is not designed to be async-signal-safe. > + Except where explicitly stated otherwise [#]_, the DPDK functions are > nonreentrant and are unsafe to call from a signal handler. > + > +.. [#] Only the function ``rte_dump_stack()`` can safely be called from > signal handler in this version of DPDK.
Really? Are you sure? Note: the use of [#] is probably limited to a single usage in the page? > + > +.. note:: > + The kinds of issues that make DPDK functions unsafe can be understood when > + one considers that much of the code in DPDK uses locks and other shared > + resources. If a device driver holding a ``rte_spinlock`` is interrupted > + by a signal and control operation is then performed that would acquire > + the same lock, a deadlock would result. I find this note quite confusing.
