From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id A3871F72 for ; Wed, 10 May 2017 14:45:01 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 338612079D; Wed, 10 May 2017 08:45:01 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 10 May 2017 08:45:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=KQTpZvjGUZ8GOJh bTlgr5LnECH+KBmkvK23P2Jtnx3g=; b=bbdsXn0M4d464TsHIZSzPuPh65ro86l gGAE6AT6FJSBGzH6p/o6W5Q/dpJOFRjbQMNj/Esq+hn5dWCaMoOvFrz71zIQEpYy YT0RB2o2dCEFsEXleOP2GWQKwXWITWv+jqrVmZ/ShkYAw8AqT12+O+KQ10pjcvz3 ALFvRrfABMIQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=KQTpZvjGUZ8GOJhbTlgr5LnECH+KBmkvK23P2Jtnx3g=; b=FfGNPwXF CpqdMeKrAiWYhbGom9upSLhm9xwxIC/rA7NnMT1xQqF/wlNkmr7sSYzdD4Z0P0Df GfJ1pvWZz+QyWP/vlxoFNrHzu/Ez2auYI42XENwTyNPN8ZTpPzzHo5GGH60qGV9r 09rTJfKY9xTbIRnT7cRp/9J9awsRGLH6SqFi1ZV7t9Cum6Fi7RgFsQeE00kWwmpg 3LiqU9n1VulqumaJQwbXUskq1y9d8hyzsFI4hgo6oNev33YdPzX5St0l1Wljm8Pn T4p59sg/0CoazoOyQ85xJlHgQLD7e8o1s2X8qwqbpwaWtppAUiFPzjDSlKMN+shH o6GDRCntDtWA+A== X-ME-Sender: X-Sasl-enc: 0VzbRF8OEowM/Kxk6JIym2eoFKm+YNcLnGA6okdcxaxP 1494420300 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id DD05F24929; Wed, 10 May 2017 08:45:00 -0400 (EDT) From: Thomas Monjalon To: Tonghao Zhang Cc: dev@dpdk.org, stephen@networkplumber.org Date: Wed, 10 May 2017 14:45:00 +0200 Message-ID: <1716317.nSDOrcW80P@xps> In-Reply-To: <1494315002-41982-1-git-send-email-nic@opencloud.tech> References: <1494315002-41982-1-git-send-email-nic@opencloud.tech> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3] eal: Set numa node value for system which not support it. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 12:45:02 -0000 09/05/2017 09:30, Tonghao Zhang: > The NUMA node information for PCI devices provided through > sysfs is invalid for AMD Opteron(TM) Processor 62xx and 63xx > on Red Hat Enterprise Linux 6, and VMs on some hypervisors. Sorry I don't understand the range of affected platforms. Is it only on Opteron? Opteron with RHEL6? Is it fixed in recent kernels? Which hypervisors? with which kernel? > It is good to see more checking for valid values. If values are wrong, what can we do? Here you check that value is not too high. What about other kind of wrong values? > Signed-off-by: Tonghao Zhang [...] > - /* get numa node */ > + /* get numa node, default to 0 if not present */ > snprintf(filename, sizeof(filename), "%s/numa_node", > dirname); > - if (access(filename, R_OK) != 0) { > - /* if no NUMA support, set default to 0 */ > - dev->device.numa_node = 0; Why removing the access() check? > - } else { > - if (eal_parse_sysfs_value(filename, &tmp) < 0) { > - free(dev); > - return -1; > - } > + > + if (eal_parse_sysfs_value(filename, &tmp) == 0 && > + tmp < RTE_MAX_NUMA_NODES) > dev->device.numa_node = tmp; > - } > + else > + dev->device.numa_node = 0; It would deserve at least a warning log.