From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Hall Subject: Re: [PATCH] eal/linux: fix negative value for undetermined numa_node Date: Fri, 31 Jul 2015 20:56:55 -0700 Message-ID: <20150801035655.GA29805@mhcomputing.net> References: <1438306572-25434-1-git-send-email-cunming.liang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org To: Cunming Liang Return-path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.46.186]) by dpdk.org (Postfix) with ESMTP id DEBEF5A79 for ; Sat, 1 Aug 2015 05:57:10 +0200 (CEST) Content-Disposition: inline In-Reply-To: <1438306572-25434-1-git-send-email-cunming.liang@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 running on socket zero, and something with multiple sockets. Seems like we need a bit of thought about how the NUMA APIs should behave overall. Matthew. On Fri, Jul 31, 2015 at 09:36:12AM +0800, Cunming Liang wrote: > 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 Liang