Re: [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 12-Mar-21 12:05 PM, Bruce Richardson wrote:
> On Fri, Mar 12, 2021 at 10:56:20AM +0000, Burakov, Anatoly wrote:
>> On 11-Mar-21 12:13 PM, Bruce Richardson wrote:
>>> On Wed, Mar 10, 2021 at 10:33:50AM -0800, Stephen Hemminger wrote:
>>>> On Wed, 10 Mar 2021 17:27:17 +0000
>>>> Bruce Richardson <bruce.richardson@intel.com> wrote:
>>>>
>>>>> On Wed, Mar 10, 2021 at 09:21:37AM -0800, Stephen Hemminger wrote:
>>>>>> There can be cases such as containers or other runtime environments
>>>>>> where DPDK may not be able to access the default runtime path.
>>>>>> This patch introduces DPDK_RUNTIME_DIR as an environment variable
>>>>>> to allow controlling and overriding the path.
>>>>>>
>>>>>> The example we have is DPDK application running in an untrusted
>>>>>> systemd container. In this case, it is not root, and XDG_RUNTIME_DIR
>>>>>> is not set (since it is not a user application), and /tmp is
>>>>>> blocked. The correct place for this application is to use /run.
>>>>>>
>>>>>> In any case, hard coded path assumptions are a problem.
>>>>>>
>>>>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>>>>> ---
>>>>>
>>>>> Basic question, if the user/operator can set DPDK_RUNTIME_DIR in the
>>>>> container, can they not also set XDG_RUNTIME_DIR?
>>>>
>>>> Yes they could, but more about not having hard coded paths.
>>>
>>> As far as I can see, you aren't removing the hard-coded path to "/tmp" in
>>> your patch, so unless I'm missing something I'm not seeing the significance
>>> of the change here? It largely just seems to be adding a new environment
>>> variable on top of the existing one, while changing nothing if neither is
>>> set.
>>>
>>> /Bruce
>>>
>>
>> An argument could be made that DPDK_RUNTIME_DIR is DPDK-specific while
>> XDG_RUNTIME_DIR is system-wide, so setting up an environment like that is
>> more "correct". However, since you can set environment variables per
>> executable without affecting the rest of the system, i'm not sure it's worth
>> the hassle of adding another variable.
>>
> 
> Since some of the concern seems to be around the use of "/tmp" as a
> hardcoded path, I would actually suggest that instead of an extra
> environment variable we add an EAL flag for the runtime dir. Then we can
> fail eal init if XDG_RUNTIME_DIR is not set and if no runtime dir is
> specified on cmdline. That would remove any hard-coded paths and gives two
> separate ways to set runtime dir, rather than having two options using the
> same method.

Yep, i don't think there are any distributions that don't set this path 
any more. And if they don't, well, they should :D

> 
> One final note that whatever the behaviour of EAL is changed to, some
> scripts which mimic that behaviour e.g. to find sockets, will also need
> updating. "dpdk-telemetry.py" is one that I am aware of anyway.
> 
> /Bruce
> 


-- 
Thanks,
Anatoly