[ovs-dev] [PATCH v4 5/5] redhat: allow dpdk to also run as non-root user

[Aaron Conole]

Russell Bryant <russell at ovn.org> writes:

> On Sun, Aug 6, 2017 at 7:24 AM, Aaron Conole <aconole at redhat.com> wrote:
>> Russell Bryant <russell at ovn.org> writes:
>>
>>> On Fri, Aug 4, 2017 at 1:00 PM, Aaron Conole <aconole at redhat.com> wrote:
>>>> After this commit, users may start a dpdk-enabled ovs setup as a
>>>> non-root user.  This is accomplished by exporting the $HOME directory,
>>>> which dpdk uses to fill in it's semi-persistent RTE configuration.
>>>>
>>>> This change may be a bit controversial since it modifies /dev/hugepages
>>>> as part of starting the ovs-vswitchd to set a hugetlbfs group
>>>> ownership.  This is used to enable writing to /dev/hugepages so that the
>>>> dpdk_init will successfully complete.  There is an alternate way of
>>>> accomplishing this - namely to initialize DPDK before dropping
>>>> privileges.  However, this would mean that if DPDK ever grows an uninit
>>>> / reinit function, non-root ovs likely could never use it.
>>>
>>> Indeed ... the modifications to /dev/hugepages don't look ideal ...
>>>
>>> If this was truly limited to when DPDK was in use, I'd feel better
>>> about it.  We want to build a single package for OVS, right?  The
>>> package will have DPDK enabled, even for normal uses that won't use
>>> DPDK.  That means these modifications take place even for non-DPDK
>>> use.  I'd feel more comfortable if it could be restricted to only when
>>> DPDK was actually in use.  Maybe some of this logic could be moved
>>> into ovs-ctl so that the check could be at runtime?
>>
>> I couldn't find a way of doing that check.  It is possible to
>> dynamically enable dpdk (since commit ec2b070143c2 "dpdk: Late
>> initialization"), which means we would need something constantly polling
>> for the status change -OR- we would need to have a way of changing gid
>> in response to the database change.  The second might be possible but
>> would require some changes in ovs-vswitchd.
>
> OK, then I don't have any alternatives to propose at this point.
>
> I've applied this series to master and branch-2.8.

Thanks Russell!