From: Stephen Hemminger <stephen@networkplumber.org>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>
Cc: John Ousterhout <ouster@cs.stanford.edu>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"thomas.monjalon@6wind.com" <thomas.monjalon@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] eal: avoid unnecessary conflicts over rte_config file
Date: Thu, 13 Oct 2016 11:28:52 -0700 [thread overview]
Message-ID: <20161013112852.13055753@xeon-e3> (raw)
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA61299BB0A@IRSMSX102.ger.corp.intel.com>
On Thu, 13 Oct 2016 16:30:20 +0000
"Van Haaren, Harry" <harry.van.haaren@intel.com> wrote:
> Hi,
>
> > From: John Ousterhout [mailto:ouster@cs.stanford.edu]
>
> > But, given the existence of the --file-prefix option, isn't it already unsafe for Collectd to check only for .rte_config? If it's important for other programs to be able to find the config files, it seems to me that a more robust mechanism is needed than the current one.
>
> If the user is using the DPDK --file-prefix, we expect the user to provide that same --file-prefix to inform Collectd of the changed config path. Details on how to do so are available here: https://github.com/collectd/collectd/blob/master/src/collectd.conf.pod#plugin-dpdkstat
>
> Keep in mind a for a simple setup the current defaults will just work, so changing the default seems a bad idea to me.
>
> Regards, -Harry
>
>
> > On Thu, Oct 13, 2016 at 9:07 AM, Van Haaren, Harry <harry.van.haaren@intel.com> wrote:
> >Hi John,
>
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of John Ousterhout
> >> Subject: Re: [dpdk-dev] [PATCH] eal: avoid unnecessary conflicts over rte_config file
>
> > <snip>
>
> > For example, it took me several hours
> > to figure out why the problem was occurring and then to hunt down the
> > --file-prefix solution. Is there some reason why it would be a bad idea to
> > fix this in DPDK?
>
> Right now, DPDK will by default always use a consistent .rte_config location, which allows other applications to monitor that. For example, Collectd is able to monitor a DPDK primary process by checking if the .rte_config file exists at its default location[1].
>
> If we change the default behavior of DPDK, other projects can no longer rely on that file being created, and these monitoring projects must be updated in sync with DPDK to avoid breakage if versions mismatch.
>
> Although I see your use-case, I think using the --file-prefix as Konstantin suggests is a better solution in this case.
>
> Regards, -Harry
>
> [1] https://github.com/collectd/collectd/blob/master/src/dpdkstat.c#L60
I think DPDK model of lock file is overly simplistic. On Linux it should be putting any lockfiles in /run
not users home directory, since it is a system not user lock.
next prev parent reply other threads:[~2016-10-13 18:28 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 [this message]
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
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=20161013112852.13055753@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=ouster@cs.stanford.edu \
--cc=thomas.monjalon@6wind.com \
/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).