[dpdk-dev] [PATCH] eal: avoid unnecessary conflicts over rte_config file

Stephen Hemminger stephen at networkplumber.org
Thu Oct 13 20:28:52 CEST 2016


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.




More information about the dev mailing list