From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by dpdk.org (Postfix) with ESMTP id BCC531DA4 for ; Thu, 24 May 2018 17:39:57 +0200 (CEST) Received: by mail-wm0-f68.google.com with SMTP id j5-v6so6593348wme.5 for ; Thu, 24 May 2018 08:39:57 -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=2/HRZhnmJs8auVc1zZXfUHxGt79UkN4LpWDrDjtCtVA=; b=dmwlxfULTZjQ0PSGg94tQ3mP8WiVxL9KexFDVx+xbSOm4SSLwiFEVi+ywhOUp8y6t1 xh1B+c1kT9DVRUugQ2VjEl99qSDPJy2N2SS+8jIBeL5HsrNN8gyr8ym1/B8AZ9D93nH3 1KTPnXUWmMpR7iCvVsrvN0Vd9lBjtzpjefPOLV8JRW5gJgkOht4RXrUKEe2ie+aCp+dJ MW2Bq3qyZ+8UHFdWJs6istOqVbiJeWRucmKdM6NB+gcH11emN1xOKqHGAz1jvWkOnumU O83QjkaB0QDGSROMN27dk25zw45Jb59eKF8QojlnboGW8QkzxJS4y4w6yOFmPqvPwo5u TcxQ== 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=2/HRZhnmJs8auVc1zZXfUHxGt79UkN4LpWDrDjtCtVA=; b=JhlGjcvL5UEZ8cEe4IZkYAcYlZ/0gKSgflkCtDPcbvjQky70qO5WZOS0ALnjU0iSCh rtguPDVR/CPCU5p1S+Ugv1ejlR+DkRt5NoyXaYKf+zXHuIemwUUlZ2E10hGTuUxlhR+9 TA7DaVa144UbFMpK2lawEFVvzskduNfPEqDdTADK3RA41G4u1JczLTw9Fdew5Sb07Fqr ZzDI3BhvoO9Bnsgc1mrC50xAOv2TolwlDwLS2MZSM2GXH1I1H8ZZtKwNOgnrJZYsknam Cxk3fbZSWebe0xvkIQn0kVo2oj/B+39ugoSlpb7/jpLgCEyazz+N42Nar7tpKIDKiHIu LT6Q== X-Gm-Message-State: ALKqPweRVl1h9/8Eip69UHPRfy518kRjpaj9TEj3nCXF8VrjuqLZIxGr E1pOE/r4XFBStaBneGmwryERgdOaBvSY9SimV/kHBw== X-Google-Smtp-Source: AB8JxZqdcIlJnAIAZQXjIWhIR/Zz7r/WXMhovP07IxfDZpBHxvgK/jpnBozNhl13C4UXqca/rHV3JkjJawgIyKwv6pk= X-Received: by 2002:a50:b946:: with SMTP id m64-v6mr12764438ede.32.1527176397426; Thu, 24 May 2018 08:39:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:d49b:0:0:0:0:0 with HTTP; Thu, 24 May 2018 08:39:56 -0700 (PDT) In-Reply-To: References: <1527078536-1443-1-git-send-email-alejandro.lucero@netronome.com> From: Alejandro Lucero Date: Thu, 24 May 2018 16:39:56 +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 15:39:57 -0000 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 >> > 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 < > alejandro.lucero@netronome.com > >> > >> 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. 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. > > > >> > >> The VFIO driver does avoid this situation, but this lock is required > for UIO. > >> > > > >