[dpdk-dev] [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances

[Thomas Monjalon]

Hi Arnon,

Any update about this work?
Would be good to merge these patches early in 19.08 release.
If you need help or more time for some of the patches,
do not hesitate to split the work.
We could merge obvious patches first.

Thanks


09/05/2019 15:16, Thomas Monjalon:
> 09/05/2019 14:05, Burakov, Anatoly:
> > On 08-May-19 12:15 PM, Thomas Monjalon wrote:
> > > 24/04/2018 08:41, Arnon Warshavsky:
> > >> The purpose of this patch series is to cleanup the library code
> > >> from paths that end up aborting the process,
> > >> and move to checking error values, in order to allow the running process
> > >> perform an orderly teardown or other mitigation of the event.
> > >>
> > >> This patch modifies the majority of rte_panic calls
> > >> under lib and drivers, and replaces them with a log message
> > >> and an error return code according to context,
> > >> that can be propagated up the call stack.
> > >>
> > >> - Focus was given to the dpdk initialization path
> > >> - Some of the panic calls within drivers were left in place where
> > >>    the call is from within an interrupt or calls that are
> > >>    on the data path,where there is no simple applicative
> > >>    route to propagate the error to temination.
> > >>    These should be handled by the driver maintainers..
> > >> - local void functions with no api were changed to retrun a value
> > >>    where needed
> > >> - No change took place in example and test files
> > >> - No change took place for debug assertions calling panic
> > > 
> > > I did a status of rte_panic/rte_exit calls in libs.
> > > 
> > > There are a lot of cleanups to do in EAL.
> > > We may apply the same kind of solution for Linux, FreeBSD and Windows.
> > > 
> > > The status is described below in a kind of call tree:
> > 
> > <snip>
> > 
> > > librte_mempool:
> > >      void rte_mempool_*
> > >          RTE_LIBRTE_MEMPOOL_DEBUG
> > >              rte_panic
> > > 
> > 
> > (and other similar places)
> > 
> > Could an argument not be made that when debugging options are enabled, 
> > having rte_panic there is actually useful?
> 
> Yes I think we can keep them.
> In order to make it clear, we could replace them
> with RTE_ASSERT or RTE_VERIFY (which calls rte_panic).