From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) by dpdk.org (Postfix) with ESMTP id 051705591 for ; Thu, 13 Oct 2016 20:28:38 +0200 (CEST) Received: by mail-pf0-f175.google.com with SMTP id r16so14812024pfg.1 for ; Thu, 13 Oct 2016 11:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=NG5aqhdXnJygvdkoAPxuw4g1IXK8VVpZagmklEeMUgY=; b=LnSifdhgKqGSqglxvfGU0J1sTCeENxwYHMJd6MGLLYk8hGmqFuapjtu42YDyQAKm+K dWJFqwYx8CdiTExMcAe8Y0x4eACYtrn4g4FaPxbZwSk3hNc8WPGXfFOoLYVbBdV2JHFw yeKZg/wuNwuPoZ7miL2NliRO4EeiMwXvhE/p9E1SXoFPnNpeQGrt4Y0y8vlKQIjBe/Kl WnLckYLQUfwCCpEU1tW26ELmky0qLLDAFfwYi03fjjuP63bQzzLyy8LW/E7l3rNANLQL d9xzY5tbbPQrW9DUoeeHxfjqUyy5epmLVuRAg/y19BMC0H0CevsnWSjbWoxLXEAS6qRP 3HZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=NG5aqhdXnJygvdkoAPxuw4g1IXK8VVpZagmklEeMUgY=; b=LoQSSARQIdR1XKXDF27m733lmlSCh3933Jkmo0xZkAX3HiH5AOxN+/4A2Gygyi347z 4ABoW4bBMX3BFhT997tEiiaze0qyicUrupaG5TDqdd10/o8Y15Z5Qnc9woYQwfSHh330 p3KZW6NiX8k/b8LH8OAl1ogLDxlJYbg6IjWlr0f0N7WS06eIX5LkY2p6Ken0SfjsLnd1 fGW1CwD9eQLtnPOGemhdyTTwprU7xGeah+NG/kHjxTIuG0SrwhcsYEQimvx4DRwj+9Mm S8aF4779UDcna3KcdaZRcvZqK/rHpGdcTslRPejTZ8E1Mmttk/LwuHs7vyA8QUlV8pRi 7Log== X-Gm-Message-State: AA6/9RnbFaKfHigfqCzy4BZh3S9sC04+L10Z+aB6+SYtjstzMXfdc0NZtU9yCnfiUmyreA== X-Received: by 10.98.63.144 with SMTP id z16mr12014894pfj.61.1476383317314; Thu, 13 Oct 2016 11:28:37 -0700 (PDT) Received: from xeon-e3 (static-50-53-69-251.bvtn.or.frontiernet.net. [50.53.69.251]) by smtp.gmail.com with ESMTPSA id s85sm21370361pfi.17.2016.10.13.11.28.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Oct 2016 11:28:37 -0700 (PDT) Date: Thu, 13 Oct 2016 11:28:52 -0700 From: Stephen Hemminger To: "Van Haaren, Harry" Cc: John Ousterhout , "Ananyev, Konstantin" , "thomas.monjalon@6wind.com" , "dev@dpdk.org" Message-ID: <20161013112852.13055753@xeon-e3> In-Reply-To: References: <20161012212917.10760-1-ouster@cs.stanford.edu> <2601191342CEEE43887BDE71AB9772583F0C1256@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] eal: avoid unnecessary conflicts over rte_config file X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 18:28:38 -0000 On Thu, 13 Oct 2016 16:30:20 +0000 "Van Haaren, Harry" 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 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 > > > > > > 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.