From: Andrew Rybchenko <arybchenko@solarflare.com>
To: Gage Eads <gage.eads@intel.com>, <dev@dpdk.org>
Cc: <olivier.matz@6wind.com>, <stable@dpdk.org>
Subject: Re: [dpdk-stable] [PATCH] doc: add multi-proc shared lib mempool note
Date: Thu, 20 Jun 2019 21:01:29 +0300 [thread overview]
Message-ID: <381b4578-891f-5b1a-f2c4-38d73360f5d7@solarflare.com> (raw)
In-Reply-To: <20190618184830.29110-1-gage.eads@intel.com>
On 6/18/19 9:48 PM, Gage Eads wrote:
> The mempool library assigns handler ops indexes based on the dynamic load
> order of mempool handlers. Indexes are used so a mempool can be used by
> multiple processes, but this only works if all processes agree on the
> mapping from index to mempool handler.
>
> When using the '-d' argument, it's possible for different processes to load
> mempool handlers in different orders, and thus have different
> index->handler mappings. Using a mempool in multiple of such processes will
> result in undefined behavior.
>
> This commit adds a note to the mempool library programmer's guide warning
> users against this.
>
> Fixes: 449c49b93a6b ("mempool: support handler operations")
> Cc: stable@dpdk.org
>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
> doc/guides/prog_guide/mempool_lib.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/doc/guides/prog_guide/mempool_lib.rst b/doc/guides/prog_guide/mempool_lib.rst
> index 52a569f57..4470f6b38 100644
> --- a/doc/guides/prog_guide/mempool_lib.rst
> +++ b/doc/guides/prog_guide/mempool_lib.rst
> @@ -133,6 +133,13 @@ For applications that use ``rte_pktmbuf_create()``, there is a config setting
> (``RTE_MBUF_DEFAULT_MEMPOOL_OPS``) that allows the application to make use of
> an alternative mempool handler.
>
> + .. note::
> +
> + When running a DPDK application with shared libraries, mempool handler
> + shared objects specified with the '-d' EAL command-line parameter are
> + dynamically loaded. When running a multi-process application with shared
> + libraries, the -d arguments for mempool handlers *must be specified in the
> + same order for all processes* to ensure correct operation.
>
One more empty line is required here, other than that:
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
I think it is OK as a fix for stable branches.
In theory I think it is still technically possible to guarantee ops
indices correctness
using dedicated memzone (as Olivier suggested), but with sync up on
rte_mempool_{get,set}_ops() (which should be called when EAL is
initialized) and
reordering. However, it requires API breakage to avoid returning of
ops_index
on register (since it may change in secondary process on resync when EAL is
already initialized).
next prev parent reply other threads:[~2019-06-20 18:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 18:48 Gage Eads
2019-06-20 18:01 ` Andrew Rybchenko [this message]
2019-06-20 19:07 ` Eads, Gage
2019-06-21 7:25 ` Andrew Rybchenko
2019-06-20 22:07 ` [dpdk-stable] [PATCH v2] " Gage Eads
2019-07-04 20:53 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=381b4578-891f-5b1a-f2c4-38d73360f5d7@solarflare.com \
--to=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=olivier.matz@6wind.com \
--cc=stable@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).