* [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path @ 2021-03-10 17:21 Stephen Hemminger 2021-03-10 17:27 ` Bruce Richardson 0 siblings, 1 reply; 7+ messages in thread From: Stephen Hemminger @ 2021-03-10 17:21 UTC (permalink / raw) To: dev; +Cc: Stephen Hemminger, Stephen Hemminger 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> --- lib/librte_eal/linux/eal.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/linux/eal.c b/lib/librte_eal/linux/eal.c index 6c34ac890386..f2a5e73817d6 100644 --- a/lib/librte_eal/linux/eal.c +++ b/lib/librte_eal/linux/eal.c @@ -90,20 +90,26 @@ static const char *default_runtime_dir = "/var/run"; int eal_create_runtime_dir(void) { - const char *directory = default_runtime_dir; + const char *directory; const char *xdg_runtime_dir = getenv("XDG_RUNTIME_DIR"); const char *fallback = "/tmp"; char run_dir[PATH_MAX]; char tmp[PATH_MAX]; int ret; - if (getuid() != 0) { + directory = getenv("DPDK_RUNTIME_DIR"); + if (directory != NULL) { + RTE_LOG(DEBUG, EAL, "Using DPDK runtime directory: %s\n", directory); + } else if (getuid() == 0) { + directory = default_runtime_dir; + } else { /* try XDG path first, fall back to /tmp */ if (xdg_runtime_dir != NULL) directory = xdg_runtime_dir; else directory = fallback; } + /* create DPDK subdirectory under runtime dir */ ret = snprintf(tmp, sizeof(tmp), "%s/dpdk", directory); if (ret < 0 || ret == sizeof(tmp)) { -- 2.30.1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path 2021-03-10 17:21 [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path Stephen Hemminger @ 2021-03-10 17:27 ` Bruce Richardson 2021-03-10 18:33 ` Stephen Hemminger 0 siblings, 1 reply; 7+ messages in thread From: Bruce Richardson @ 2021-03-10 17:27 UTC (permalink / raw) To: Stephen Hemminger; +Cc: dev, Stephen Hemminger 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path 2021-03-10 17:27 ` Bruce Richardson @ 2021-03-10 18:33 ` Stephen Hemminger 2021-03-11 12:13 ` Bruce Richardson 0 siblings, 1 reply; 7+ messages in thread From: Stephen Hemminger @ 2021-03-10 18:33 UTC (permalink / raw) To: Bruce Richardson; +Cc: dev, Stephen Hemminger 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path 2021-03-10 18:33 ` Stephen Hemminger @ 2021-03-11 12:13 ` Bruce Richardson 2021-03-12 10:56 ` Burakov, Anatoly 0 siblings, 1 reply; 7+ messages in thread From: Bruce Richardson @ 2021-03-11 12:13 UTC (permalink / raw) To: Stephen Hemminger; +Cc: dev, Stephen Hemminger 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path 2021-03-11 12:13 ` Bruce Richardson @ 2021-03-12 10:56 ` Burakov, Anatoly 2021-03-12 12:05 ` Bruce Richardson 0 siblings, 1 reply; 7+ messages in thread From: Burakov, Anatoly @ 2021-03-12 10:56 UTC (permalink / raw) To: Bruce Richardson, Stephen Hemminger; +Cc: dev, Stephen Hemminger 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. -- Thanks, Anatoly ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path 2021-03-12 10:56 ` Burakov, Anatoly @ 2021-03-12 12:05 ` Bruce Richardson 2021-03-12 12:49 ` Burakov, Anatoly 0 siblings, 1 reply; 7+ messages in thread From: Bruce Richardson @ 2021-03-12 12:05 UTC (permalink / raw) To: Burakov, Anatoly; +Cc: Stephen Hemminger, dev, Stephen Hemminger 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. 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path 2021-03-12 12:05 ` Bruce Richardson @ 2021-03-12 12:49 ` Burakov, Anatoly 0 siblings, 0 replies; 7+ messages in thread From: Burakov, Anatoly @ 2021-03-12 12:49 UTC (permalink / raw) To: Bruce Richardson; +Cc: Stephen Hemminger, dev, Stephen Hemminger 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-03-12 12:49 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-10 17:21 [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path Stephen Hemminger 2021-03-10 17:27 ` Bruce Richardson 2021-03-10 18:33 ` Stephen Hemminger 2021-03-11 12:13 ` Bruce Richardson 2021-03-12 10:56 ` Burakov, Anatoly 2021-03-12 12:05 ` Bruce Richardson 2021-03-12 12:49 ` Burakov, Anatoly
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).