From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 15CD1A0471 for ; 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 , CC: , References: <20190618184830.29110-1-gage.eads@intel.com> From: Andrew Rybchenko 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > --- > 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 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).