Re: [PATCH v2] mem: store memory mode flags in shared config

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 04-Oct-18 11:46 AM, Ferruh Yigit wrote:
> 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 <anatoly.burakov@intel.com>
>>>>> ---
>>>>>
>>>>> 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.
> 

How about just ignore them? 'git status' will show you which particular 
files cause conflicts. if it's anything in the doc/ directory, it's safe 
to 'git add' those files and proceed with rebase/apply, no?

-- 
Thanks,
Anatoly