From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: [PATCH] fbarray: support no-shconf Date: Wed, 23 May 2018 09:40:42 +0100 Message-ID: References: <80aff8bc0255cdab2331dcb0b21219d50f154937.1527006762.git.anatoly.burakov@intel.com> <1778895.HHJToTI6Sl@xps> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Thomas Monjalon Return-path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 21E6523B for ; Wed, 23 May 2018 10:40:51 +0200 (CEST) In-Reply-To: <1778895.HHJToTI6Sl@xps> Content-Language: en-US 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 22-May-18 9:38 PM, Thomas Monjalon wrote: > 22/05/2018 18:35, Anatoly Burakov: >> When using --no-shconf option, the expectation is that no multiprocess >> will be supported as no shared files are created. However, fbarray >> still creates some shared files that prevent multiple processes with >> the same prefix from starting. >> >> Fix this by avoiding creating shared files whenever noshconf option is >> specified. Since virtual areas we get from eal_get_virtual_area() are >> read-only, remap them as writable. >> >> Signed-off-by: Anatoly Burakov >> --- >> >> Notes: >> Without this patch, EAL flags autotest will fail when attempting >> to run a test with the same prefix as primary, and --no-shconf >> specified. >> >> Technically, we never spelled out any guarantees about --no-shconf >> mode, and we've been sloppy about it, so even though we don't create >> the shared config, we still create lots of other miscelaneous files. >> This patch only fixes issue with fbarray, as this affects intialization >> of different primaries with the same prefix (fbarrays are shared too), >> but does not address the other instances where we create "shared" files >> such as hugepage info. > > Just for confirmation: this patch won't be integrated in 18.05. > OK, no objection to that. I'll work on an expanded version for 18.08 fixing all the inconsistencies then. -- Thanks, Anatoly