From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 8BF61A0679 for ; Wed, 3 Apr 2019 11:58:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E58117D4A; Wed, 3 Apr 2019 11:58:22 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 551615F2E for ; Wed, 3 Apr 2019 11:58:22 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2019 02:58:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,304,1549958400"; d="scan'208";a="146206872" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.103]) ([10.237.220.103]) by FMSMGA003.fm.intel.com with ESMTP; 03 Apr 2019 02:58:20 -0700 To: Stephen Hemminger , dev@dpdk.org References: <20190402200452.7dd4f029@shemminger-XPS-13-9360> From: "Burakov, Anatoly" Message-ID: <4d920e12-e344-110e-559a-dc0530a36758@intel.com> Date: Wed, 3 Apr 2019 10:58:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <20190402200452.7dd4f029@shemminger-XPS-13-9360> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] EAL lcore config 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190403095819.tvzDaZQPZMg2zkHn0TcMSOWP-9QCrZD69efBUHCxn-o@z> On 03-Apr-19 4:04 AM, Stephen Hemminger wrote: > Currently the DPDK Environment Abstraction Layer has its guts on the floor ;-) > The data structure for lcore config is a holey mess and changing it would > break the ABI. > > I propose that for 19.05 we introduce accessor functions and change all > internal (out side of eal directory) to use those. And add a deprecation notice. > > For 19.08, we can mark the data structure as deprecated but keep it > the same. Any thing built from source that hits the global variable > will get a warning. Binaries will still run unmodified. > > For 19.11, lcore_config can be moved to eal_private.h where it belongs, > and some simple rearrangements will shrink it and get almost all data > on the same cache line. This breaks ABI but API stays the same as 19.05 > > After that some of the debris can be cleaned out without affecting > API or ABI in future. > To be fair, the entire EAL API should receive the same treatment :) There are a lot of cases where the "reasonable" way to access something is to use a shared internal structure. I've attempted to fix some of that on the memory side by introducing a mountain of new API's, but more work is needed. -- Thanks, Anatoly