From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 3A7591B2BB for ; Tue, 16 Jan 2018 18:38:20 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 09:38:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,369,1511856000"; d="scan'208";a="166553823" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.145]) ([10.237.220.145]) by orsmga004.jf.intel.com with ESMTP; 16 Jan 2018 09:38:18 -0800 To: Thomas Monjalon Cc: dev@dpdk.org References: <3f9df1ca17e97b2df560d5af5fa31a778af3263f.1513942728.git.anatoly.burakov@intel.com> <2134391.uA7JBUhxlf@xps> <58e15893-0f6e-7fed-d847-b128be26e483@intel.com> <1810706.ItrCMZY2UQ@xps> From: "Burakov, Anatoly" Message-ID: Date: Tue, 16 Jan 2018 17:38:17 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1810706.ItrCMZY2UQ@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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:38:20 -0000 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 :) -- Thanks, Anatoly