[dpdk-dev] [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances
thomas at monjalon.net
Thu May 9 15:16:18 CEST 2019
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:
> > 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).
More information about the dev