From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by dpdk.space (Postfix) with ESMTP id 15CD1A0471
	for <public@inbox.dpdk.org>; Thu, 20 Jun 2019 20:01:43 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 8F02B1D42E;
	Thu, 20 Jun 2019 20:01:41 +0200 (CEST)
Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com
 [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 6251F1D42D;
 Thu, 20 Jun 2019 20:01:40 +0200 (CEST)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
 (No client certificate requested)
 by mx1-us4.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id AE70C280064;
 Thu, 20 Jun 2019 18:01:38 +0000 (UTC)
Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com
 (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 20 Jun
 2019 19:01:32 +0100
To: Gage Eads <gage.eads@intel.com>, <dev@dpdk.org>
CC: <olivier.matz@6wind.com>, <stable@dpdk.org>
References: <20190618184830.29110-1-gage.eads@intel.com>
From: Andrew Rybchenko <arybchenko@solarflare.com>
Message-ID: <381b4578-891f-5b1a-f2c4-38d73360f5d7@solarflare.com>
Date: Thu, 20 Jun 2019 21:01:29 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.1
MIME-Version: 1.0
In-Reply-To: <20190618184830.29110-1-gage.eads@intel.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-Originating-IP: [91.220.146.112]
X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To
 ukex01.SolarFlarecom.com (10.17.10.4)
X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24696.000
X-TM-AS-Result: No-9.887500-8.000000-10
X-TMASE-MatchedRID: fE0JoqABJp10nsJmoztmWO6MKg9QShiw69aS+7/zbj+qvcIF1TcLYFVG
 4bS+O3XZdbk6uIpex0h+AiNJQk+9/S4YlXCNHMx/SMFvyr5L84ImOgC1/BTSzgytGucsJkSay4x
 5ZVHpfJzJG9a4lQBQQ3oLKuV1ManHEPI1TSE7G1sD2WXLXdz+AfsJB65N+sbMI0YrtQLsSUwGMS
 cpH7qOAKF8BNmSAz+6kRxI5ZYMpwkhfZxKT6RFH+W9J5hJgRQsDh8P8jTpEYHQZ38GWvCEeII7s
 5f4WtvNKngj+6fT7OXPUgNICksJ2gx5TL3qCTgEKJYo5K4P1qQiJN3aXuV/ocz/SxKo9mJ4n5iT
 buChGTzQ9WuivTxy9uH1JVgx2wdQT3nCKCHJ3mmVyEX4i+SWU8iZ5w9RXnqOmyiLZetSf8nJ4y0
 wP1A6AKEwgORH8p/AjaPj0W1qn0Q7AFczfjr/7LQ65H8pvtuWQZJbSqK/NWqzweI6Mbpl3ZxZGt
 AfTrwaod8spQ9/6W4=
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-TMASE-Result: 10--9.887500-8.000000
X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24696.000
X-MDID: 1561053699-0F7ZnzFidO2J
Subject: Re: [dpdk-dev] [PATCH] doc: add multi-proc shared lib mempool note
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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).