From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D308AA0C47 for ; Mon, 13 Sep 2021 15:37:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C3E04410E5; Mon, 13 Sep 2021 15:37:08 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id CADD14014F; Mon, 13 Sep 2021 15:37:05 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10105"; a="221342551" X-IronPort-AV: E=Sophos;i="5.85,290,1624345200"; d="scan'208";a="221342551" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2021 06:37:02 -0700 X-IronPort-AV: E=Sophos;i="5.85,290,1624345200"; d="scan'208";a="507296502" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.30.142]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 13 Sep 2021 06:37:01 -0700 Date: Mon, 13 Sep 2021 14:36:58 +0100 From: Bruce Richardson To: "Burakov, Anatoly" Cc: dev@dpdk.org, david.marchand@redhat.com, stable@dpdk.org Message-ID: References: <20210913110635.130387-1-bruce.richardson@intel.com> <48d75bc2-ae55-183c-8132-6e3e150647af@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48d75bc2-ae55-183c-8132-6e3e150647af@intel.com> Subject: Re: [dpdk-stable] [PATCH] eal/freebsd: lock memory device to prevent conflicts X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Mon, Sep 13, 2021 at 02:14:55PM +0100, Burakov, Anatoly wrote: > On 13-Sep-21 12:06 PM, Bruce Richardson wrote: > > Only a single DPDK process on the system can be using the /dev/contigmem > > mappings at a time, but this was never explicitly enforced, e.g. when > > using --in-memory flag on two processes. To prevent possible conflict > > issues, we lock the dev node when it's in use, preventing other DPDK > > processes from starting up and causing problems for us. > > > > Fixes: 764bf26873b9 ("add FreeBSD support") > > Cc: stable@dpdk.org > > > > Signed-off-by: Bruce Richardson > > --- > > lib/eal/freebsd/eal_hugepage_info.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/lib/eal/freebsd/eal_hugepage_info.c b/lib/eal/freebsd/eal_hugepage_info.c > > index 408f054f7a..4a8d87c23e 100644 > > --- a/lib/eal/freebsd/eal_hugepage_info.c > > +++ b/lib/eal/freebsd/eal_hugepage_info.c > > @@ -90,6 +90,10 @@ eal_hugepage_info_init(void) > > RTE_LOG(ERR, EAL, "could not open "CONTIGMEM_DEV"\n"); > > return -1; > > } > > + if (flock(fd, LOCK_EX) < 0) { > > + RTE_LOG(ERR, EAL, "could not lock memory. Is another DPDK process running?\n"); > > + return -1; > > + } > > if (buffer_size >= 1<<30) > > RTE_LOG(INFO, EAL, "Contigmem driver has %d buffers, each of size %dGB\n", > > > > This only gets triggered when regular init path is chosen, i.e. --no-huge > still works. Yes, but that is ok, I think, since no-huge doesn't use these resources or suffer from this problem. On the other hand, except for running unit tests, no-huge mode is pretty useless on FreeBSD as we don't have any vfio-equivalent support, so all HW access has to use physical addresses which can only be got using contigmem. > I'm a bit uneasy with --in-memory mode pretending to work on > FreeBSD and Windows, but that's a separate problem :) Yes, it is, though one that does belong is the same area as this one. The "fix" is probably to just print a warning when --in-memory is used, informing the user that the flag is ignored and then continue. Alternatively we can error out, but I think the warn+continue is better, myself. > As far as the patch > goes, the problem it addresses does get fixed. > > Reviewed-by: Anatoly Burakov > Thanks. /Bruce