From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) by dpdk.org (Postfix) with ESMTP id A9C66160 for ; Thu, 24 May 2018 19:10:18 +0200 (CEST) Received: by mail-wm0-f65.google.com with SMTP id t11-v6so7171683wmt.0 for ; Thu, 24 May 2018 10:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GjK5RSsISOGk2qNsVOahxzk7cE690/lL/f7Q9EAMItQ=; b=QyrfsSH1yULWKS8jimIBRV1AufCeUZXVE+3YPbzUd/Aojb3Nas2EPxcGsZI5OUbrRM PlejyLlCHyZ+j9C1RxJRyOd0k0lVTI76XyjRq6PLXcUrq3ctGouFVTDNJFxb6E0O8IJd fKU2Kd2o22zGmR2fU1Wh9M4YDf/Y9qGer639V5rajpnfO04zD9WY7RyVYNk7fI/NlHJW Gfvu/z5tZ4HZnVFp1Iqoeb8Nyf7wwohwySjNTO43uZJ9CPL7/TxuyRjMwiNlTslelgqe 0zsRus3rj6CA28xH5Ixdv71PI3HmSQKvW3OBOcdYUlJcrE4UVDFsnJR+lRA4TOakmJ4G 8haA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GjK5RSsISOGk2qNsVOahxzk7cE690/lL/f7Q9EAMItQ=; b=KUrSX/mfP4yvRxmvUGSA9w+CR/tHaQ1/VbXmH4mmmQztzE+ZzQ8BkokGz7iEZqFiBD r3DOiF85XO68YxiGuNp/Z/V7sZ4HJlblyFfzVz1ojKUNraW8XtUd8IzFVLWCsIKojVeQ gRhaV1MMufBM4G3voX946OJGCvbr960TfiYQNBSTD8BzsuI7iH4RXbkKN6dG6KmR/x+W Gf+ahElvvbzq+xED5CoRhdAPCgb66nT0oR5Er9Ji5TvbrzfmC9ZpcBbWxUwjX8mg2vU6 E1wWpW0DjlO8E3szcsV6Hyw8yj6UwOx5TkIOIo7yEF86GQMdERJUHBZXfhagW3jnIaBp iW7w== X-Gm-Message-State: ALKqPwcb1aQopdXIoDgfNn+PuplLCTnD4zvY0w0AXl9/cfNg1dAsStdl cO5nLP01N8I4ih/syv/aE9nlGhyo7rAmcIhULCP0ag== X-Google-Smtp-Source: AB8JxZpnB3cdx5lHFcSmsILR4RucZDV3QU0H6ICcW+1L8VMF6lM+RLMf0Fe9IulGUawv04fPkYMbotZ1RtozwP/GtzY= X-Received: by 2002:a50:a802:: with SMTP id j2-v6mr13355511edc.138.1527181818417; Thu, 24 May 2018 10:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:d49b:0:0:0:0:0 with HTTP; Thu, 24 May 2018 10:10:17 -0700 (PDT) In-Reply-To: <83ed311c-509f-f297-3fcd-59287716e58f@intel.com> References: <1527078536-1443-1-git-send-email-alejandro.lucero@netronome.com> <83ed311c-509f-f297-3fcd-59287716e58f@intel.com> From: Alejandro Lucero Date: Thu, 24 May 2018 18:10:17 +0100 Message-ID: To: Ferruh Yigit Cc: dev , "Varghese, Vipin" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] net/nfp: fix lock file usage 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: , X-List-Received-Date: Thu, 24 May 2018 17:10:18 -0000 On Thu, May 24, 2018 at 5:30 PM, Ferruh Yigit wrote: > On 5/24/2018 4:39 PM, Alejandro Lucero wrote: > > > > > > On Thu, May 24, 2018 at 3:15 PM, Ferruh Yigit > > wrote: > > > > On 5/24/2018 3:13 PM, Ferruh Yigit wrote: > > > On 5/24/2018 3:02 PM, Alejandro Lucero wrote: > > >> > > >> > > >> On Thu, May 24, 2018 at 11:18 AM, Ferruh Yigit < > ferruh.yigit@intel.com > > > > >> >> > wrote: > > >> > > >> On 5/23/2018 5:50 PM, Alejandro Lucero wrote: > > >> > > > >> > > > >> > On Wed, May 23, 2018 at 4:57 PM, Ferruh Yigit > > > > > > > >> > ferruh.yigit@intel.com> > > >>> > wrote: > > >> > > > >> > On 5/23/2018 1:28 PM, Alejandro Lucero wrote: > > >> > > DPDK apps can be executed as non-root users but > current NFP lock > > >> > > file for avoiding concurrent accesses to CPP > interface is > > precluding > > >> > > this option or requires to modify system file > permissions. > > >> > > > > >> > > When the NFP device is bound to VFIO, this driver > does not > > allow this > > >> > > concurrent access, so the lock file is not required > at all. > > >> > > > > >> > > OVS-DPDK as executed in RedHat distributions is the > main NFP user > > >> > > needing this fix. > > >> > > > > >> > > Fixes: c7e9729da6b5 ("net/nfp: support CPP") > > >> > > > > >> > > Signed-off-by: Alejandro Lucero > > netronome.com> > > >> > > > > >> > > > > >>> > > >> > > > >> > Hi Alejandro, > > >> > > > >> > As far as I understand this is to fix a common use case > for > > nfp, but it looks > > >> > like there is already a workaround and only for > non-root users. > > >> > > > >> > > > >> > There is a patch submitted to stable versions because this > lock was > > also with > > >> > the old NSPU interface, but as far as I know, there is no > patch yet > > for the > > >> > current upstream tip. > > >> > > > >> > > > >> > > > >> > What is the priority of the patch, only critical but > fixes > > allowed at this > > >> > point, can we push this one to next release? > > >> > > > >> > > > >> > This is critical for us because RedHat wants to support OVS > with > > our card, and > > >> > when OVS-DPDK is used, this problem is precluding non-root > users to > > execute > > >> > OVS-DPDK. > > >> > > >> What exactly this lock for? Does it to prevent multiple > primary > > process to > > >> access CPP interface? > > >> > > >> If so this is the know limitation in DPDK, not two separate > process > > can driver > > >> same hardware, this is valid for all devices, why adding a > lock > > unique to nfp? > > >> > > >> > > >> Time ago I had, by mistake, two different DPDK processes using > same > > device, and > > >> with UIO, there is no one avoiding this. > > >> > > >> You can bound a device to UIO, igb_uio, and then use two > different processes > > >> opening the /dev/uiox file, and it works. > > > > > > But this is not anything specific to nfp, isn't it? > > > > Or let me ask something else, is this a fix for ovs-dpdk regular > use-case with > > nfp? Or this is just an extra protection in case multiple process > may try to use > > the NIC. If second, why it is critical? > > > > > > I think any device bound to UIO could end up being used by two different > DPDK > > processes. So this is a protection against that possibility, because > accessing > > the NFP through the new CPP interface could make the NFP a brick even it > could > > crash the system. > > Yes and I was suggesting if we solve this, we should solve in higher level > instead of PMD, but that is already in PMD this patch is not introducing > it. > > > > > RH is configuring OVS-DPDK for running as non-root, and the lock was > precluding > > this because it is set at /var/lock which a non-root user has not access > by > > default. This patch solves the problem, because when using the device > with VFIO, > > that lock is not necessary. And with UIO, the lock is needed and > because it is > > not possible to run DPDK apps with UIO as non-root, the lock path is > fine. > > I see, this is to enable running as non-root by relaxing locking for vfio. > OK, > let me check the patch. > > But I still believe that locking shouldn't be in driver at fist place... > > Agree. I think the UIO driver should be avoiding it, but not sure if there are other reasons for not doing it. > > > > > >> > > >> The VFIO driver does avoid this situation, but this lock is > required for UIO. > > >> > > > > > > > > >