From: Alejandro Lucero <alejandro.lucero@netronome.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev <dev@dpdk.org>, "Varghese, Vipin" <vipin.varghese@intel.com>
Subject: Re: [dpdk-dev] [PATCH] net/nfp: fix lock file usage
Date: Thu, 24 May 2018 16:39:56 +0100 [thread overview]
Message-ID: <CAD+H993uvehph94ydy-Ki=O6umzAZpWQ1wtXXyVerWvj_CRq2Q@mail.gmail.com> (raw)
In-Reply-To: <b7fed729-0f7a-f320-1c58-a3ce0b84e08a@intel.com>
On Thu, May 24, 2018 at 3:15 PM, Ferruh Yigit <ferruh.yigit@intel.com>
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
> >> <mailto: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 <mailto:ferruh.yigit@intel.com>
> >> > <mailto:ferruh.yigit@intel.com <mailto: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
> >> <mailto:alejandro.lucero@netronome.com>
> >> <mailto:alejandro.lucero@netronome.com <mailto: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.
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.
> >>
> >
>
>
next prev parent reply other threads:[~2018-05-24 15:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 12:28 Alejandro Lucero
2018-05-23 15:57 ` Ferruh Yigit
2018-05-23 16:50 ` Alejandro Lucero
2018-05-24 10:18 ` Ferruh Yigit
2018-05-24 14:02 ` Alejandro Lucero
2018-05-24 14:13 ` Ferruh Yigit
2018-05-24 14:15 ` Ferruh Yigit
2018-05-24 15:39 ` Alejandro Lucero [this message]
2018-05-24 16:30 ` Ferruh Yigit
2018-05-24 17:10 ` Alejandro Lucero
2018-05-25 8:03 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAD+H993uvehph94ydy-Ki=O6umzAZpWQ1wtXXyVerWvj_CRq2Q@mail.gmail.com' \
--to=alejandro.lucero@netronome.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=vipin.varghese@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).