On Thu, 13 Oct 2016 16:30:20 +0000 "Van Haaren, Harry" <harry.van.haaren at intel.com> wrote:
> Hi, > > > From: John Ousterhout [mailto:ouster at 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 at > > intel.com> wrote: > >Hi John, > > >> From: dev [mailto:dev-bounces at 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.
