From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id BEEABDE3 for ; Thu, 24 May 2018 16:02:50 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id a67-v6so5438159wmf.3 for ; Thu, 24 May 2018 07:02:50 -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=f3sUGXyQRqylgqENGf4qmqhJSPwJhfOc17jvfOpQM1g=; b=EFFolyGmdwk580SOLTSo7exF4YmJFsh+2yxKZty+zPCd8TaNPQAA2Dk/Tm0bMwmQ+e zT/yrAzHC4OVE97Q+EhB38HsN94i9Vyga6tCtTcbpNfakoeA7fC34xj6jFFNLtnayjYI Lsk1HdM3H0cWj64tbiT3UmDP8i8g3c4nrWO3ASWXMX6NfS8oxMgJ1N+Har0XSMlPKb7I 1wgEAKsDncf4y+1nofA0Ijfgo/FwTOLyZFet/bMAH+UY+xzKOZWSBef46lmD1nM6XRCY Oa3leODEJYvixum26C3DxjKs1rJhEOnL+gQYO4VMXpSShKwU31RS0kP++wtwTIcetmKZ YYhw== 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=f3sUGXyQRqylgqENGf4qmqhJSPwJhfOc17jvfOpQM1g=; b=En5GPqeGDINcOQ9CVOFTPQZCd0R+YImgNyWGmxUhhuitekMkSjisieBH46aBzepUpU aXN39vPla91WRCHwcaE4mn93E3d3dzFyxtkJgAiGOeIbS7EX1R8VPIbtsSpobxGFBiJa FAerVB9D4yvA1wBDQR3ZC7bAMpxkT7e4X2zROMxtdYIOe45nv1KMTY3SjwAAM0OPZq4r z0AYGJg9+DY9jmq4HirrA9/9WC44Rd/2jLYsYXdGeVSg+67ofOK8beiDY1blyZ/vjGWB S5QCPWRWiaqXCQVo2/2EilE5BN2V/tFeW1/j7EULQBFv3IdoBNoIiMjtswDtke9UQX04 U3Lg== X-Gm-Message-State: ALKqPwerpk+t8NVu1het7pwMQfn92XhtbsEakrTQiWdyq64S7Y7fGOvh Ok69GtruATfM39Oj9HqrENSlcRmjCiavIc4s0Bd5YQ== X-Google-Smtp-Source: AB8JxZo4OkahnlMz4CK4U7GdSYyPdvm9IXMIYb3jVjIkjabrshnNh5q0FJ3kzTVQUi4ouym+0vdEQGo0zfg/7ZQew58= X-Received: by 2002:a50:8e59:: with SMTP id 25-v6mr12274146edx.101.1527170570527; Thu, 24 May 2018 07:02:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:d49b:0:0:0:0:0 with HTTP; Thu, 24 May 2018 07:02:49 -0700 (PDT) In-Reply-To: References: <1527078536-1443-1-git-send-email-alejandro.lucero@netronome.com> From: Alejandro Lucero Date: Thu, 24 May 2018 15:02:49 +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 14:02:50 -0000 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 > > 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 > > > > > 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. The VFIO driver does avoid this situation, but this lock is required for UIO.