[dpdk-dev] [PATCH v2] mem: store memory mode flags in shared config
Burakov, Anatoly
anatoly.burakov at intel.com
Fri Oct 5 11:04:49 CEST 2018
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 at 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
More information about the dev
mailing list