[dpdk-dev] [PATCH] net/nfp: fix lock file usage
Alejandro Lucero
alejandro.lucero at netronome.com
Thu May 24 16:02:49 CEST 2018
On Thu, May 24, 2018 at 11:18 AM, Ferruh Yigit <ferruh.yigit at 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 at intel.com
> > <mailto:ferruh.yigit at 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 at netronome.com
> <mailto:alejandro.lucero at 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.
The VFIO driver does avoid this situation, but this lock is required for
UIO.
More information about the dev
mailing list