From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 0F7A11B2C1 for ; Tue, 16 Jan 2018 18:35:26 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 85A6220853; Tue, 16 Jan 2018 12:35:25 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 16 Jan 2018 12:35:25 -0500 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; s=mesmtp; bh=Pek9CrWxgHVPOsP0j8/jhYYbcu sGfniMFctQu+NKL3Q=; b=N10Px2d0EpyjiqT1KLNWpnVPJg9LOOJv++PsRK6L/A 7ENOKzdwjRjz2B6faaANSKQqcTRmUfHY3M0G04qrbBOMtcmm24kidqjYkHvV1OGV A+kLf/O29RpEMeFvrGi6MBtYN52E9J/f7nnH5abaxV6BFMmbs79FG0Le5ayndamt g= 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; s=fm1; bh=Pek9Cr WxgHVPOsP0j8/jhYYbcusGfniMFctQu+NKL3Q=; b=BJ5Zjt0dej/SHSGM2Di/8Q E9LFSLAHQP5CHLnYdja0TxOplB2dixIi1hbdYLD6yKNKupoPkNPZubIvI0NCryV4 Xi/3i53Ew6MToH98xzr/0bgOkNTPCpC8A2bPGTLzmHrxE+311S9bjWsgdqnmyJet 8QnIe0kyMu4EoQfy4lnaBBMSyAQ8AK9/t12BS3ayTd0ioCdBRC9U/z5bpdgggL3B JWvEiAAlogb3hmtBY0l5WD0ioVW8RVtRPYWuHtp4Hz0pVui59WJavcvGMs7oy6FQ zxMCwkdaRi2jQ/GeENcvMhcErvnPU+S4fCP0bQnC3rtKes3bri9U3sYqvKF516DQ == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 36F2D7E322; Tue, 16 Jan 2018 12:35:25 -0500 (EST) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: dev@dpdk.org Date: Tue, 16 Jan 2018 18:34:53 +0100 Message-ID: <1810706.ItrCMZY2UQ@xps> In-Reply-To: <58e15893-0f6e-7fed-d847-b128be26e483@intel.com> References: <3f9df1ca17e97b2df560d5af5fa31a778af3263f.1513942728.git.anatoly.burakov@intel.com> <2134391.uA7JBUhxlf@xps> <58e15893-0f6e-7fed-d847-b128be26e483@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] eal: add function to return number of detected sockets 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: Tue, 16 Jan 2018 17:35:26 -0000 16/01/2018 16:05, Burakov, Anatoly: > On 16-Jan-18 12:20 PM, Thomas Monjalon wrote: > > 16/01/2018 12:56, Burakov, Anatoly: > >> On 12-Jan-18 11:50 AM, Thomas Monjalon wrote: > >>> 12/01/2018 12:44, Burakov, Anatoly: > >>>> On 11-Jan-18 10:20 PM, Thomas Monjalon wrote: > >>>>> 22/12/2017 13:41, Anatoly Burakov: > >>>>>> During lcore scan, find maximum socket ID and store it. > >>>>>> > >>>>>> Signed-off-by: Anatoly Burakov > >>>>>> --- > >>>>>> --- a/lib/librte_eal/common/include/rte_eal.h > >>>>>> +++ b/lib/librte_eal/common/include/rte_eal.h > >>>>>> @@ -83,6 +83,7 @@ enum rte_proc_type_t { > >>>>>> struct rte_config { > >>>>>> uint32_t master_lcore; /**< Id of the master lcore */ > >>>>>> uint32_t lcore_count; /**< Number of available logical cores. */ > >>>>>> + uint32_t numa_node_count; /**< Number of detected NUMA nodes. */ > >>>>>> uint32_t service_lcore_count;/**< Number of available service cores. */ > >>>>>> enum rte_lcore_role_t lcore_role[RTE_MAX_LCORE]; /**< State of cores. */ > >>>>> > >>>>> isn't it breaking the ABI? > >>>>> > >>>>> > >>>> > >>>> Yep, you're right, forgot to add that. I didn't expect this to get > >>>> merged in 18.02 anyway, so v2 will follow. > >>> > >>> Please write 18.05 in the subject to show your expectation. > >>> Thanks > >>> > >> > >> Does it have to be an ABI change though? We can put numa_node_count > >> after pointer to mem_config, in which case it won't be an ABI break. > >> Would that be better? > > > > Changing the size of a struct which is allocated by the app, > > is an ABI break. > > Is your solution changing the size? > > > > It's not really allocated as such. rte_config is a global static > variable, and we only ever get pointers to it from the user code. If we > add the new value at the end, all of the old data layout would be intact > and work as before, so nothing would change as far as old code is concerned. > > However, if that's still considered an ABI break, then OK, break it is. Maybe that assuming it is never allocated (not copied for instance) we could consider it is not an ABI break. > Some background for why this is needed - for the memory hotplug, we need > to know how many sockets we can allocate memory at, to distinguish > between socket that doesn't exist, and socket that exists but has no > memory allocated on it. I'm OK with trying other approaches (such as > storing numa nodes in a static variable somewhere) if breaking ABI for > this is too much to ask for such a minute change. Why is it important for 18.02? Memory hotplug will be integrated only in 18.05. I think it is better to just wait (and announce the deprecation).