Re: [dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API

[Burakov, Anatoly]

On 13-Feb-18 2:16 PM, Van Haaren, Harry wrote:
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Tuesday, February 13, 2018 1:51 PM
To: Burakov, Anatoly <anatoly.bura...@intel.com>
Cc: dev@dpdk.org; Tan, Jianfeng <jianfeng....@intel.com>
Subject: Re: [dpdk-dev] [PATCH] eal: fix rte_errno values for IPC API
rte_errno values should not be negative.

Fixes: bacaa2754017 ("eal: add channel for multi-process communication")
Fixes: 783b6e54971d ("eal: add synchronous multi-process communication")
Cc: jianfeng....@intel.com
Signed-off-by: Anatoly Burakov <anatoly.bura...@intel.com>

Reviewed-by: Jianfeng Tan <jianfeng....@intel.com>

Thanks for fixing this.

Applied, thanks

There are a lot of similar issues:

git grep -l 'rte_errno = -E' | sed 's,[^/]*$,,' | sort -u

        drivers/event/opdl/
        drivers/event/sw/
<snip>
        lib/librte_eventdev/


I just checked the eventdev.h port_link() docs, which indicate negative return 
values.
Perhaps the header is wrong too - but the PMDs adhere to the library header in 
this case.

Is there a requirement for rte_errno to be positive?
It looks to be declared as per-lcore signed int in rte_errno.h +20

Either-way, if we want to change the PMDs, we should change the Eventdev APIs,
which means API breakage, and application changes to handle changed return 
values.

Sound like more work than it is worth it to me?


To be clear, documentation doesn't *explicitly* spell this out, so it 
can be interpreted as not having an opinion on this. So i think the 
first step should be fixing documentation to clearly indicate this is to 
be expected at least of new code (unless decided against for consistency 
reasons).

However, while docs don't state this outright, i think they imply it 
both in cases of referring to errno values and returning "-errno" values 
(which implies sign isn't part of the errno value). Plus, errno values 
in Linux are always positive, plus rte_strerror() expects a positive 
value, and (as correctly pointed out by Harry) our custom errno values - 
so at least our API expects it to be positive, even if it doesn't state 
it outright.

--
Thanks,
Anatoly