[dpdk-dev] [PATCH 25/25] rte_eal_init: add info about rte_errno codes
Stephen Hemminger
stephen at networkplumber.org
Fri Jan 27 18:37:29 CET 2017
On Fri, 27 Jan 2017 16:47:40 +0000
Bruce Richardson <bruce.richardson at intel.com> wrote:
> On Fri, Jan 27, 2017 at 08:33:46AM -0800, Stephen Hemminger wrote:
> > On Fri, 27 Jan 2017 09:57:03 -0500
> > Aaron Conole <aconole at redhat.com> wrote:
> >
> > > diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h
> > > index 03fee50..46e427f 100644
> > > --- a/lib/librte_eal/common/include/rte_eal.h
> > > +++ b/lib/librte_eal/common/include/rte_eal.h
> > > @@ -159,7 +159,29 @@ int rte_eal_iopl_init(void);
> > > * function call and should not be further interpreted by the
> > > * application. The EAL does not take any ownership of the memory used
> > > * for either the argv array, or its members.
> > > - * - On failure, a negative error value.
> > > + * - On failure, -1 and rte_errno is set to a value indicating the cause
> > > + * for failure.
> > > + *
> > > + * The error codes returned via rte_errno:
> > > + * EACCES indicates a permissions issue.
> > > + *
> > > + * EAGAIN indicates either a bus or system resource was not available,
> > > + * try again.
> > > + *
> > > + * EALREADY indicates that the rte_eal_init function has already been
> > > + * called, and cannot be called again.
> > > + *
> > > + * EINVAL indicates invalid parameters were passed as argv/argc.
> > > + *
> > > + * EIO indicates failure to setup the logging handlers. This is usually
> > > + * caused by an out-of-memory condition.
> > > + *
> > > + * ENODEV indicates memory setup issues.
> > > + *
> > > + * ENOTSUP indicates that the EAL cannot initialize on this system.
> > > + *
> > > + * EUNATCH indicates that the PCI bus is either not present, or is not
> > > + * readable by the eal.
> > > */
> > > int rte_eal_init(int argc, char **argv);
> >
> > Why use rte_errno?
> > Most DPDK calls just return negative value on error which corresponds to error number.
> > Are you trying to keep ABI compatibility? Doesn't make sense because before all these
> > errors were panic's no working application is going to care.
>
> Either will work, but I actually prefer this way. I view using rte_errno
> to be better as it can work in just about all cases, including with
> functions which return pointers. This allows you to have a standard
> method across all functions for returning error codes, and it only
> requires a single sentinal value to indicate error, rather than using a
> whole range of values.
The problem is DPDK is getting more inconsistent on how this is done.
As long as error returns are always same as kernel/glibc errno's it really doesn't
matter much which way the value is returned from a technical point of view
but the inconsistency is sure to be a usability problem and source of errors.
More information about the dev
mailing list