2017-01-30 13:38, Aaron Conole:

Stephen Hemminger [off-list ref] writes:

quoted

Bruce Richardson [off-list ref] wrote:

quoted

On Fri, Jan 27, 2017 at 08:33:46AM -0800, Stephen Hemminger wrote:

quoted

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.

I am using rte_errno here because I assumed it was the preferred
method.  In fact, looking at some recently contributed modules (for
instance pdump), it seems that folks are using it.

I'm not really sure the purpose of having rte_errno if it isn't used, so
it'd be helpful to know if there's some consensus on reflecting errors
via this variable, or on returning error codes.  Whichever is the more
consistent with the way the DPDK project does things, I'm game :).

I think we can use both return value and rte_errno.
We could try to enforce rte_errno as mandatory everywhere.

Adrien did the recent rte_flow API.
Please Adrien, could you give your thought?