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 6B8441B00B for ; Tue, 16 Jan 2018 19:26:49 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EA3C8207A8; Tue, 16 Jan 2018 13:26:47 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 16 Jan 2018 13:26:47 -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=w+kLdS1oRE6eauFT43SNgqv4Po o1B3cqmL/287ifsJU=; b=jhsCUL6V9e0ZmOOAokmHto/EbRafxYa4erIGScLSud Hc0f/7S7Bmhg8JVSzL1NxcjmL73c1J6qJAt+COQqeqlmE83qE5SvS1Yox4apcKFz 4UKMpN1j8+n4tz0IjRYNNs5nvaXkaP6+q6z8gh5NBpIgxdmGE8OmoiFJcQ0vq6ux 0= 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=w+kLdS 1oRE6eauFT43SNgqv4Poo1B3cqmL/287ifsJU=; b=JPAwJMKsmHO50qvDZ9Acql trh1I4FrQEBc+nHHW/CuYFT5CttkeZhpStKo4Xux4BNeaOrR3s1ROAKUE1s3B60W 5LAm8Ct0O8GPhHzDeigdQRolSTL622QvpPgeIGPnnayAVR/HdMALA3WD7b1fBYZ7 FUSa56J/cTcOgki2sCr65tJEUGbyAtny9QsQS3nUxNftnl5DsPBWObUuiRgqmLkB uWs+NBJHOCznvcZktNYbxnx3uO1BkcYmyCsdq6nJeGQY/ys3VUTJ3QnaTpycSCdj cak+c6GQ0T8xISpue1h3qfTx46/tIpJ5S4NllgoXeBCLO4yO6oDe2JU+947CE/fA == 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 9A7537E322; Tue, 16 Jan 2018 13:26:47 -0500 (EST) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: dev@dpdk.org Date: Tue, 16 Jan 2018 19:26:16 +0100 Message-ID: <54170223.fFWToWT910@xps> In-Reply-To: References: <3f9df1ca17e97b2df560d5af5fa31a778af3263f.1513942728.git.anatoly.burakov@intel.com> <1810706.ItrCMZY2UQ@xps> 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 18:26:49 -0000 16/01/2018 18:38, Burakov, Anatoly: > On 16-Jan-18 5:34 PM, Thomas Monjalon wrote: > > 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). > > > > It isn't, i've already marked this patch as deferred. However, we'll > have to have this discussion anyway :) To be on the safe side, you announce a deprecation. And there will be no debate in 18.05 (except if someone has a better idea).