From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v3 1/3] dfs:add FUSE based filesystem for DPDK Date: Mon, 17 Dec 2018 12:45:16 +0100 Message-ID: <2437900.lBdCot2IvA@xps> References: <20181216174604.91445-1-keith.wiles@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Keith Wiles 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) In-Reply-To: <20181216174604.91445-1-keith.wiles@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.