From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 26E44C418 for ; Mon, 3 Aug 2015 03:46:55 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 02 Aug 2015 18:46:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,598,1432623600"; d="scan'208";a="740828097" Received: from shwdeisgchi017.ccr.corp.intel.com (HELO [10.239.66.47]) ([10.239.66.47]) by orsmga001.jf.intel.com with ESMTP; 02 Aug 2015 18:46:54 -0700 Message-ID: <55BEC80E.5010309@intel.com> Date: Mon, 03 Aug 2015 09:46:54 +0800 From: "Liang, Cunming" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Matthew Hall References: <1438306572-25434-1-git-send-email-cunming.liang@intel.com> <20150801035655.GA29805@mhcomputing.net> In-Reply-To: <20150801035655.GA29805@mhcomputing.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] eal/linux: fix negative value for undetermined numa_node X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 01:46:56 -0000 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 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 >> >> /* * Return the NUMA socket to which an Ethernet device is connected * * @param port_id * The port identifier of the Ethernet device * @return * The NUMA socket id to which the Ethernet device is connected or * a default of zero if the socket could not be determined. * -1 is returned is the port_id value is out of range. */ extern int rte_eth_dev_socket_id(uint8_t port_id); 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. To your concern, "difference between no NUMA, something running on socket zero, and something with multiple sockets.". The latter two belongs to the same situation, that is the numa_node stores the NUMA id. So in fact the concern is about using '-1' or '0' when there's no NUMA detect. If we won't plan to redefine the API return value, the fix patch is reasonable. Btw, if it returns '-1' when no NUMA is detected, what will you do, do condition check '-1' and then use node 0 instead ? In that way, you can't distinguish '-'1 is out of range port_id error or no NUMA detection error. If it is, why not follow the API definition. /Steve