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 1C63BA0471 for ; Fri, 21 Jun 2019 09:25:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1249F1D53E; Fri, 21 Jun 2019 09:25:46 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id AA6B41D539; Fri, 21 Jun 2019 09:25:44 +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-us3.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 4484060005C; Fri, 21 Jun 2019 07:25:42 +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; Fri, 21 Jun 2019 08:25:35 +0100 To: "Eads, Gage" , "dev@dpdk.org" CC: "olivier.matz@6wind.com" , "stable@dpdk.org" References: <20190618184830.29110-1-gage.eads@intel.com> <381b4578-891f-5b1a-f2c4-38d73360f5d7@solarflare.com> <9184057F7FC11744A2107296B6B8EB1E68CFF97D@FMSMSX108.amr.corp.intel.com> From: Andrew Rybchenko Message-ID: <4ffbb52b-396d-b071-c737-3c63fd34b71d@solarflare.com> Date: Fri, 21 Jun 2019 10:25:32 +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: <9184057F7FC11744A2107296B6B8EB1E68CFF97D@FMSMSX108.amr.corp.intel.com> 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-24700.000 X-TM-AS-Result: No-10.579200-8.000000-10 X-TMASE-MatchedRID: rYpa/RC+czF0nsJmoztmWO6MKg9QShiw69aS+7/zbj/adW4iYSMjUV8g kdmvvg/2wc8a1xP+1+g5ZtwAbvsNRTM9BBRuZZ1vboe6sMfg+k8TcSAXT4xW4CLT+St7cam64oa ybjkzQToh4lwyBvJ8U3CwgiQ52lXf2pTKw5oLVfkzvWHRIxWXwmtqQgJyb0BRLnnqtQwNeTYDK6 XcoxVT+kW/DIQjeNRl1klR/VbdVY0YNousiD5wvOIfK/Jd5eHm6qG5M9QNAO3DlXDnbYhpr2tKV MfqNSI2cxqkspViZnDcPfSk4MFdVE3E8JaC3WoBlTsGW3DmpUtLqa9X75MqaYTGTpzirPHydvpa yVhLtoghcXR4o0btWyRJwmFsZwD59ZRkVakSSW3dIcibWbeg2w8hjyL1cWZwxt7gv7TMcfvzTu3 5URal5omZnwWWIBq/N862GpoHoW4sMLcUZMcjd2hQCsqhuTNiFW7LlhOHf7fDv5dDcuT2eVUu4d MbNIOZ/dD/o+ecn6Adw3jH6W1gvbNUVnqixiMOBxsweNg3EaGFkCkkB0UMNpsoi2XrUn/Jsuf7R WbvUtxjYGxdKEQ2dDwoMwYD9GSkVkTKTlOSCsNvmCTSL++Y6Ft1OORR86pb/14ccw7S0Pc9zUHT qrUuTFsUWbcpBOR/St679dh10pKxRWcV+qhmNaI3wSXd2dk0 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--10.579200-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24700.000 X-MDID: 1561101943-vfCqYNFHOX18 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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/20/19 10:07 PM, Eads, Gage wrote: >> -----Original Message----- >> From: Andrew Rybchenko [mailto:arybchenko@solarflare.com] >> Sent: Thursday, June 20, 2019 1:01 PM >> To: Eads, Gage ; dev@dpdk.org >> Cc: olivier.matz@6wind.com; stable@dpdk.org >> Subject: Re: [PATCH] doc: add multi-proc shared lib mempool note >> >> 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 >>> index->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 > Can do. Just for my understanding, why is the extra empty line required? https://doc.dpdk.org/guides/contributing/documentation.html#whitespace    * Add 2 blank lines before each section header.