From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 1BE985A6E for ; Mon, 17 Dec 2018 12:45:20 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AD97922145; Mon, 17 Dec 2018 06:45:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 17 Dec 2018 06:45:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=hY20WWQw5K4LEUsVtRRwEvrksU+U7+GzE+LtuMpYEvk=; b=I8zfPFluI57Z KAboBr7vLXo8KAMTwioF6cuYc0JsTJgsMfjLYqC1QiP0xv9DwQiXKgXDeoNrRIqM fydoMSg+KvAJfmP0iDD3usVewPlcIjSYBGvYVuF31pv2fdblxwpCOYJdVFrBvjLJ aVFp99/flT36qZn19JGQorEsjJCLLac= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=hY20WWQw5K4LEUsVtRRwEvrksU+U7+GzE+LtuMpYE vk=; b=MQJHUhLH6YThRfsy6M2DjbS0CjjxVGSr5PXf61DkESQN6xZashcdqc3bv 5gdEfr4kz0a9dD+0aMs/XHs7twdpRi2CUwHQtoQCji4JMIcGGSx25VxRxtEqA5nQ kfqewvEkt1K1z9sNGfYvVfJy6xiD9S/pLjsyGeMZstdZCnUQydiKEOFoihFaavGE kZ3gky+WUnRlpdVHsHhgYINDrfbGKqCeiobgB96EFzQdHaospK/CcPJ2lMYt528x P1tAtVz7XWSTsO7txpYjtmACnnKvZO+Y4J1BGZVlsjjmuTfBnf8KwBXMOR4hkbXx O2NlK38HK95+SOib3BSYPu0xnznrg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudeivddgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjg hfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcu oehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffohhmrghinhepghhithhhuh gsrdgtohhmnecukfhppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghi lhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghruf hiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D9768E459A; Mon, 17 Dec 2018 06:45:18 -0500 (EST) From: Thomas Monjalon To: Keith Wiles Cc: dev@dpdk.org Date: Mon, 17 Dec 2018 12:45:16 +0100 Message-ID: <2437900.lBdCot2IvA@xps> In-Reply-To: <20181216174604.91445-1-keith.wiles@intel.com> References: <20181216174604.91445-1-keith.wiles@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 1/3] dfs:add FUSE based filesystem for DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 11:45:20 -0000 Hi Keith, 16/12/2018 18:46, Keith Wiles: > DFS stands for DPDK Filesystem, which helps expose data > and control files in a FUSE based filesystem. The dfs requires > libfuse3 and libjansson to be present in the Linux system. You presented this idea at the DPDK Summit in Dublin, and I have not seen any public discussion about the idea. Let's try to debate it here. > DFS provides a simplified API on top of the FUSE APIs to > simplify creating and using FUSE. > > Here is the github repo: https://github.com/akheron/jansson > Here is the github repo: https://github.com/libfuse/libfuse > > Please use you system updater tool yum, apt-get, ... to add > support for these two libraries. Also read the dfs documentation > in the docs directory for more details. [...] > +DPDK File System (DFS) > +====================== > + > +This DPDK library provides a pseudo file system much like Linux /proc or /system > +file systems, but this one is a userspace file system. Allowing applications to > +create and design file system directories and files using the FUSE 3.2 > +https://github.com/libfuse/libfuse code. My first thought is we are missing the problem statement. What are you trying to solve? Which use case? In DPDK, we have some run-time options accessible from the command line, and some public API functions. I think it is agreed that the primary interface must be the API functions. The command line options should be a responsibility of the application to implement them or not. I think exposing a filesystem tree interface would be also an application responsibility. Actually, it could be part of a DPDK application, or be run as a secondary process application. It is probably a good idea to implement it as a ready-to-use library. As it can be implemented on top of DPDK API, I think it should live outside of the main repository. As any other DPDK applications, it will require to be updated when the DPDK APIs are updated or extended. In my opinion, we should not mandate DPDK contributors to update DFS when adding or updating an API. That's why it should not be part of the DPDK package. One more argument to keep it outside: for diversity and innovation, it is better to not enforce one (new) control interface as the official (and suggested) one way. One more question, Is there something exposed in DFS that has not a public DPDK API? If so, we should try fill the gaps.