[dpdk-dev] [PATCH] eal/linux: fix negative value for undetermined numa_node

2015-08-03 Thread Thomas Monjalon
2015-08-02 22:04, Matthew Hall: > On Mon, Aug 03, 2015 at 09:46:54AM +0800, Liang, Cunming wrote: > > According to the API definition, if the socket could not be determined, a > > default of zero will take. > > The '-1' is returned when the port_id value is out of range. > > Yes, but when I asked

[dpdk-dev] [PATCH] eal/linux: fix negative value for undetermined numa_node

2015-08-03 Thread Liang, Cunming
Hi, On 8/1/2015 11:56 AM, Matthew Hall wrote: > I asked about this many months ago and was informed that "-1" is a "standard > error value" that I should expect from these APIs when NUMA is not present. > Now we're saying I have to change my code again to handle a zero value? > > Also not sure

[dpdk-dev] [PATCH] eal/linux: fix negative value for undetermined numa_node

2015-08-02 Thread Matthew Hall
On Mon, Aug 03, 2015 at 09:46:54AM +0800, Liang, Cunming wrote: > According to the API definition, if the socket could not be determined, a > default of zero will take. > The '-1' is returned when the port_id value is out of range. Yes, but when I asked the exact same question and was told the

[dpdk-dev] [PATCH] eal/linux: fix negative value for undetermined numa_node

2015-07-31 Thread Matthew Hall
I asked about this many months ago and was informed that "-1" is a "standard error value" that I should expect from these APIs when NUMA is not present. Now we're saying I have to change my code again to handle a zero value? Also not sure how to tell the difference between no NUMA, something

[dpdk-dev] [PATCH] eal/linux: fix negative value for undetermined numa_node

2015-07-31 Thread Cunming Liang
The patch sets zero as the default value of pci device numa_node if the socket could not be determined. It provides the same default value as FreeBSD which has no NUMA support, and makes the return value of rte_eth_dev_socket_id() be consistent with the API description. Signed-off-by: Cunming