On 5/24/2018 3:02 PM, Alejandro Lucero wrote: > > > On Thu, May 24, 2018 at 11:18 AM, Ferruh Yigit <ferruh.yi...@intel.com > <mailto:ferruh.yi...@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.yi...@intel.com > <mailto:ferruh.yi...@intel.com> > > <mailto:ferruh.yi...@intel.com <mailto:ferruh.yi...@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.luc...@netronome.com > <mailto:alejandro.luc...@netronome.com> > <mailto:alejandro.luc...@netronome.com > <mailto:alejandro.luc...@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? > > The VFIO driver does avoid this situation, but this lock is required for UIO. >
