From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AD8AAA0547; Fri, 12 Mar 2021 13:49:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5CAB716088A; Fri, 12 Mar 2021 13:49:47 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 354F5406FF for ; Fri, 12 Mar 2021 13:49:45 +0100 (CET) IronPort-SDR: RrvygzsvlPdxcE895h2gl0HiwunOG2uqO+VzN2ZUVC3bjW7bzDF3ar82Xc0BpWgveUHxRyoC8N IHyy2NVCh9vA== X-IronPort-AV: E=McAfee;i="6000,8403,9920"; a="185471962" X-IronPort-AV: E=Sophos;i="5.81,243,1610438400"; d="scan'208";a="185471962" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2021 04:49:42 -0800 IronPort-SDR: PDu8jtUGb/cKWA0f8tBa6MVXQUiWabhjGc3fcvRtx53rkdR8O6xqOATQWq0IF6fAZgPuFQG8CT eNVWG0r7rP8g== X-IronPort-AV: E=Sophos;i="5.81,243,1610438400"; d="scan'208";a="404405851" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.21.107]) ([10.252.21.107]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2021 04:49:41 -0800 To: Bruce Richardson Cc: Stephen Hemminger , dev@dpdk.org, Stephen Hemminger References: <20210310172137.59938-1-sthemmin@microsoft.com> <20210310172717.GE1267@bricha3-MOBL.ger.corp.intel.com> <20210310103350.133bfdf2@hermes.local> <20210311121334.GA1509@bricha3-MOBL.ger.corp.intel.com> <72b09013-a78c-c8d0-a140-849d5f5a774b@intel.com> <20210312120548.GA937@bricha3-MOBL.ger.corp.intel.com> From: "Burakov, Anatoly" Message-ID: <3361f9fb-9121-c271-30f0-0e124c09e919@intel.com> Date: Fri, 12 Mar 2021 12:49:33 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <20210312120548.GA937@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] eal: allow user to override DPDK runtime path X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 12-Mar-21 12:05 PM, Bruce Richardson wrote: > On Fri, Mar 12, 2021 at 10:56:20AM +0000, Burakov, Anatoly wrote: >> On 11-Mar-21 12:13 PM, Bruce Richardson wrote: >>> On Wed, Mar 10, 2021 at 10:33:50AM -0800, Stephen Hemminger wrote: >>>> On Wed, 10 Mar 2021 17:27:17 +0000 >>>> Bruce Richardson wrote: >>>> >>>>> On Wed, Mar 10, 2021 at 09:21:37AM -0800, Stephen Hemminger wrote: >>>>>> There can be cases such as containers or other runtime environments >>>>>> where DPDK may not be able to access the default runtime path. >>>>>> This patch introduces DPDK_RUNTIME_DIR as an environment variable >>>>>> to allow controlling and overriding the path. >>>>>> >>>>>> The example we have is DPDK application running in an untrusted >>>>>> systemd container. In this case, it is not root, and XDG_RUNTIME_DIR >>>>>> is not set (since it is not a user application), and /tmp is >>>>>> blocked. The correct place for this application is to use /run. >>>>>> >>>>>> In any case, hard coded path assumptions are a problem. >>>>>> >>>>>> Signed-off-by: Stephen Hemminger >>>>>> --- >>>>> >>>>> Basic question, if the user/operator can set DPDK_RUNTIME_DIR in the >>>>> container, can they not also set XDG_RUNTIME_DIR? >>>> >>>> Yes they could, but more about not having hard coded paths. >>> >>> As far as I can see, you aren't removing the hard-coded path to "/tmp" in >>> your patch, so unless I'm missing something I'm not seeing the significance >>> of the change here? It largely just seems to be adding a new environment >>> variable on top of the existing one, while changing nothing if neither is >>> set. >>> >>> /Bruce >>> >> >> An argument could be made that DPDK_RUNTIME_DIR is DPDK-specific while >> XDG_RUNTIME_DIR is system-wide, so setting up an environment like that is >> more "correct". However, since you can set environment variables per >> executable without affecting the rest of the system, i'm not sure it's worth >> the hassle of adding another variable. >> > > Since some of the concern seems to be around the use of "/tmp" as a > hardcoded path, I would actually suggest that instead of an extra > environment variable we add an EAL flag for the runtime dir. Then we can > fail eal init if XDG_RUNTIME_DIR is not set and if no runtime dir is > specified on cmdline. That would remove any hard-coded paths and gives two > separate ways to set runtime dir, rather than having two options using the > same method. Yep, i don't think there are any distributions that don't set this path any more. And if they don't, well, they should :D > > One final note that whatever the behaviour of EAL is changed to, some > scripts which mimic that behaviour e.g. to find sockets, will also need > updating. "dpdk-telemetry.py" is one that I am aware of anyway. > > /Bruce > -- Thanks, Anatoly