From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id E91811B1D9 for ; Thu, 4 Oct 2018 12:48:03 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2018 03:48:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,338,1534834800"; d="scan'208";a="262795102" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.49]) ([10.237.221.49]) by orsmga005.jf.intel.com with ESMTP; 04 Oct 2018 03:46:23 -0700 To: Thomas Monjalon , "Burakov, Anatoly" Cc: dev@dpdk.org, John McNamara , Marko Kovacevic References: <98f283ce5bcf8973c5c08d13f4fbfe375ded6ebf.1535368896.git.anatoly.burakov@intel.com> <102589449.7KdqRJ0jb8@xps> <1885384.20xM5LhNRE@xps> From: Ferruh Yigit Openpgp: preference=signencrypt Message-ID: Date: Thu, 4 Oct 2018 11:46:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1885384.20xM5LhNRE@xps> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] mem: store memory mode flags in shared 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: , X-List-Received-Date: Thu, 04 Oct 2018 10:48:04 -0000 On 10/4/2018 10:18 AM, Thomas Monjalon wrote: > 04/10/2018 11:17, Burakov, Anatoly: >> On 03-Oct-18 11:05 PM, Thomas Monjalon wrote: >>> 20/09/2018 17:41, Anatoly Burakov: >>>> Currently, command-line switches for legacy mem mode or single-file >>>> segments mode are only stored in internal config. This leads to a >>>> situation where these flags have to always match between primary >>>> and secondary, which is bad for usability. >>>> >>>> Fix this by storing these flags in the shared config as well, so >>>> that secondary process can know if the primary was launched in >>>> single-file segments or legacy mem mode. >>>> >>>> This bumps the EAL ABI, however there's an EAL deprecation notice >>>> already in place[1] for a different feature, so that's OK. >>>> >>>> [1] http://patches.dpdk.org/patch/43502/ >>>> >>>> Signed-off-by: Anatoly Burakov >>>> --- >>>> >>>> Notes: >>>> v2: >>>> - Added documentation on ABI break >>>> >>>> doc/guides/rel_notes/rel_description.rst | 5 +++++ >>> >>> Removed change in this file (dup of release note). >>> >>>> doc/guides/rel_notes/release_18_11.rst | 6 +++++- >>>> .../common/include/rte_eal_memconfig.h | 4 ++++ >>>> lib/librte_eal/linuxapp/eal/Makefile | 2 +- >>>> lib/librte_eal/linuxapp/eal/eal.c | 20 +++++++++++++++++++ >>>> lib/librte_eal/meson.build | 2 +- >>>> 6 files changed, 36 insertions(+), 3 deletions(-) >>> >>> Applied (without extra note), thanks. >>> >> >> This will probably break external mem patches due to conflict in release >> notes. Should i respin? > > No, conflicts in release notes are usual. I manage such conflict myself. It is common to have conflict in release notes and as Thomas said we resolve it manually but now this is causing problem in automated per patch tests because patch can't be applied. We should think about a way to prevent these conflicts.