[dpdk-dev] Userspace testing

Burakov, Anatoly anatoly.burakov at intel.com
Fri Jul 31 11:12:39 CEST 2020


On 30-Jul-20 5:54 PM, Owen Hilyard wrote:
> Thanks for the advice.
> 
> I was wondering about the state of the "Setup VFIO permissions" option 
> in the setup script. It seems to just modify the character device's 
> permissions and then check their memory limit. Should this option also 
> handle the hugepages setup?

I was under the (mis?)impression that the hugepage setup part of the 
script did that?

> 
> Thanks
> 
> On Wed, Jul 29, 2020 at 11:35 AM Burakov, Anatoly 
> <anatoly.burakov at intel.com <mailto:anatoly.burakov at intel.com>> wrote:
> 
>     On 29-Jul-20 3:34 PM, Owen Hilyard wrote:
>      > Hello all,
>      >
>      > I was wondering what everyone's thoughts on doing both userspace
>     testing
>      > and unprivileged testing of dpdk applications is. DTS currently
>     runs all
>      > commands on the tester and the dut as the root user. Please
>     correct me if
>      > I'm wrong, but I was under the assumption that most applications
>     written
>      > with dpdk would not run as root. This could present a problem
>     since it is
>      > possible that permissions errors could arise and we wouldn't
>     notice it due
>      > to the way we currently test. Given that, I was wondering what
>     should and
>      > should not be possible as a normal (non-root) user, and what
>     would be the
>      > best way to go about verifying this.
>      >
>      > Thanks
>      >
> 
>     This is useful, but not everything is supposed to work with limited
>     privileges. Things that definitely *won't* work are KNI and anything
>     igb_uio-related. Everything VFIO should work fine, and setting up
>     correct permissions for hugepages and VFIO is one of the trickier
>     things
>     that even I don't know how to do correctly off the top of my head :D
> 
>     An easy stopgap way of running almost everything as an unprivileged
>     user
>     is to use in-memory mode (--in-memory EAL switch); this will cause EAL
>     to reserve hugepages etc. without touching the filesystem, sacrificing
>     secondary process support in the process (so e.g. EAL autotest won't
>     work in --in-memory mode as it relies on secondary process support).
> 
>     So, i would say that it would be a valuable thing to test for, but be
>     aware that not everything is expected to work.
> 
>     -- 
>     Thanks,
>     Anatoly
> 


-- 
Thanks,
Anatoly


More information about the dev mailing list