DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: John Ousterhout <ouster@cs.stanford.edu>
Cc: dpdk-dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Harry Van Haaren <harry.van.haaren@intel.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	"Tahhan, Maryam" <maryam.tahhan@intel.com>
Subject: Re: [dpdk-dev] [PATCH] eal: avoid unnecessary conflicts over rte_config file
Date: Fri, 11 Jan 2019 21:52:51 +0000	[thread overview]
Message-ID: <573ae9ca-5ee4-5858-a6f3-d9407f0e9f3b@intel.com> (raw)
In-Reply-To: <CAGXJAmzStTVxyoiE=AjtZdcKgYh5Y86d7dNc_hm=+qwbDQAY0A@mail.gmail.com>

On 10/14/2016 5:27 PM, ouster at cs.stanford.edu (John Ousterhout) wrote:
> It sounds like my patch would break some existing software, so it probably
> doesn't make sense right now.
> 
> I'd still argue that the current mechanism has a number of problems, and it
> should probably undergo a comprehensive overhaul at some point in the
> future.

Hi John,

It seems there weren't any conclusion on the patch and it is sitting on
patchwork more than two years, I am updating it as rejected, if
it is still relevant please let us know.

Sorry for any inconvenience caused.

For record, patch: https://patches.dpdk.org/patch/16527/

Regards,
ferruh

> 
> -John-
> 
> On Thu, Oct 13, 2016 at 2:39 PM, Tahhan, Maryam <maryam.tahhan at intel.com>
> wrote:
> 
>>> Hi John,
>>>
>>>> Before this patch, DPDK used the file ~/.rte_config as a lock to
>>>> detect potential interference between multiple DPDK applications
>>>> running on the same machine. However, if a single user ran DPDK
>>>> applications concurrently on several different machines, and if the
>>>> user's home directory was shared between the machines via NFS, DPDK
>>>> would incorrectly detect conflicts for all but the first application
>>>> and abort them. This patch fixes the problem by incorporating the
>>>> machine name into the config file name (e.g., ~/.rte_hostname_config).
>>>>
>>>> Signed-off-by: John Ousterhout <ouster at cs.stanford.edu>
>>>> ---
>>>>  doc/guides/prog_guide/multi_proc_support.rst | 11 +++++++----
>>>>  lib/librte_eal/common/eal_common_proc.c      |  8 ++------
>>>>  lib/librte_eal/common/eal_filesystem.h       | 15 +++++++++++++--
>>>>  3 files changed, 22 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/doc/guides/prog_guide/multi_proc_support.rst
>>>> b/doc/guides/prog_guide/multi_proc_support.rst
>>>> index badd102..a54fa1c 100644
>>>> --- a/doc/guides/prog_guide/multi_proc_support.rst
>>>> +++ b/doc/guides/prog_guide/multi_proc_support.rst
>>>> @@ -129,10 +129,13 @@ Support for this usage scenario is provided
>>>> using the ``--file-prefix`` paramete
>>>>
>>>>  By default, the EAL creates hugepage files on each hugetlbfs
>>>> filesystem using the rtemap_X filename,  where X is in the range 0 to
>> the
>>> maximum number of hugepages -1.
>>>> -Similarly, it creates shared configuration files, memory mapped in
>>>> each process, using the /var/run/.rte_config filename, -when run as
>>>> root (or $HOME/.rte_config when run as a non-root user; -if filesystem
>> and
>>> device permissions are set up to allow this).
>>>> -The rte part of the filenames of each of the above is configurable
>> using the
>>> file-prefix parameter.
>>>> +Similarly, it creates shared configuration files, memory mapped in
>> each
>>> process.
>>>> +When run as root, the name of the configuration file will be
>>>> +/var/run/.rte_*host*_config, where *host* is the name of the machine.
>>>> +When run as a non-root user, the the name of the configuration file
>>>> +will be $HOME/.rte_*host*_config (if filesystem and device permissions
>>> are set up to allow this).
>>>> +If the ``--file-prefix`` parameter has been specified, its value will
>>>> +be used in place of "rte" in the file names.
>>>
>>> I am not sure that we need to handle all such cases inside EAL.
>>> User can easily overcome that problem by just adding something like:
>>> --file-prefix=`uname -n`
>>> to his command-line.
>>> Konstantin
>>>
>>
>> I agree with Konstantin, there's no need to include the hostname in the
>> rte config file + I'm not sure this will be backward compatible with
>> existing DPDK applications that use a secondary processes that use the
>> config file (as in, multiprocess DPDK applications in use would all need to
>> be updated). What Konstantin suggests fixes the issue you were encountering
>> without breaking backward compatibility.
>> Is addition, the hostname is not unique... you could in theory have 2
>> hosts with the same hostname and encounter the issue you were seeing again.
>>
>>>>
>>>>  In addition to specifying the file-prefix parameter,  any DPDK
>>>> applications that are to be run side-by-side must explicitly limit
>> their
>>> memory use.
>>>> diff --git a/lib/librte_eal/common/eal_common_proc.c
>>>> b/lib/librte_eal/common/eal_common_proc.c
>>>> index 12e0fca..517aa0c 100644
>>>> --- a/lib/librte_eal/common/eal_common_proc.c
>>>> +++ b/lib/librte_eal/common/eal_common_proc.c
>>>> @@ -45,12 +45,8 @@ rte_eal_primary_proc_alive(const char
>>>> *config_file_path)
>>>>
>>>>     if (config_file_path)
>>>>             config_fd = open(config_file_path, O_RDONLY);
>>>> -   else {
>>>> -           char default_path[PATH_MAX+1];
>>>> -           snprintf(default_path, PATH_MAX, RUNTIME_CONFIG_FMT,
>>>> -                    default_config_dir, "rte");
>>>> -           config_fd = open(default_path, O_RDONLY);
>>>> -   }
>>>> +   else
>>>> +           config_fd = open(eal_runtime_config_path(), O_RDONLY);
>>>>     if (config_fd < 0)
>>>>             return 0;
>>>>
>>>> diff --git a/lib/librte_eal/common/eal_filesystem.h
>>>> b/lib/librte_eal/common/eal_filesystem.h
>>>> index fdb4a70..4929aa3 100644
>>>> --- a/lib/librte_eal/common/eal_filesystem.h
>>>> +++ b/lib/librte_eal/common/eal_filesystem.h
>>>> @@ -41,7 +41,7 @@
>>>>  #define EAL_FILESYSTEM_H
>>>>
>>>>  /** Path of rte config file. */
>>>> -#define RUNTIME_CONFIG_FMT "%s/.%s_config"
>>>> +#define RUNTIME_CONFIG_FMT "%s/.%s_%s_config"
>>>>
>>>>  #include <stdint.h>
>>>>  #include <limits.h>
>>>> @@ -59,11 +59,22 @@ eal_runtime_config_path(void)
>>>>     static char buffer[PATH_MAX]; /* static so auto-zeroed */
>>>>     const char *directory = default_config_dir;
>>>>     const char *home_dir = getenv("HOME");
>>>> +   static char nameBuffer[1000];
>>>> +   int result;
>>>>
>>>>     if (getuid() != 0 && home_dir != NULL)
>>>>             directory = home_dir;
>>>> +
>>>> +   /*
>>>> +    * Include the name of the host in the config file path. Otherwise,
>>>> +    * if DPDK applications run on different hosts but share a home
>>>> +    * directory (e.g. via NFS), they will choose the same config
>>>> +    * file and conflict unnecessarily.
>>>> +    */
>>>> +   result = gethostname(nameBuffer, sizeof(nameBuffer)-1);
>>>>     snprintf(buffer, sizeof(buffer) - 1, RUNTIME_CONFIG_FMT,
>>> directory,
>>>> -                   internal_config.hugefile_prefix);
>>>> +                   internal_config.hugefile_prefix,
>>>> +           (result == 0) ? nameBuffer : "unknown-host");
>>>>     return buffer;
>>>>  }
>>>>
>>>> --
>>>> 2.8.3
>>
>>
> 

      reply	other threads:[~2019-01-11 21:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-12 21:29 John Ousterhout
2016-10-13 10:53 ` Ananyev, Konstantin
2016-10-13 15:42   ` John Ousterhout
2016-10-13 16:07     ` Van Haaren, Harry
2016-10-13 16:20       ` John Ousterhout
2016-10-13 16:30         ` Van Haaren, Harry
2016-10-13 18:28           ` Stephen Hemminger
2016-10-13 16:31         ` Thomas Monjalon
2016-10-13 17:01     ` Ananyev, Konstantin
2016-10-13 21:39   ` Tahhan, Maryam
2016-10-14 16:27     ` John Ousterhout
2019-01-11 21:52       ` Ferruh Yigit [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=573ae9ca-5ee4-5858-a6f3-d9407f0e9f3b@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=maryam.tahhan@intel.com \
    --cc=ouster@cs.stanford.edu \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).