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.bura...@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
