From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id B9C331B1EF for ; Sun, 2 Dec 2018 19:40:59 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2018 10:40:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,307,1539673200"; d="scan'208";a="98019751" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga008.jf.intel.com with ESMTP; 02 Dec 2018 10:40:58 -0800 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 2 Dec 2018 10:40:58 -0800 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.100]) by FMSMSX110.amr.corp.intel.com ([169.254.14.33]) with mapi id 14.03.0415.000; Sun, 2 Dec 2018 10:40:57 -0800 From: "Wiles, Keith" To: "Zhang, Qi Z" CC: dpdk-dev , "Richardson, Bruce" , "Yigit, Ferruh" , Thomas Monjalon , "Ananyev, Konstantin" Thread-Topic: [dpdk-dev] [RFC] DFS (DPDK Filesystem) Thread-Index: AQHUX1g+rIvd8hoH1Eq/csPHM63tj6Vkiy8AgASZHYCAAC71gIACyy4K Date: Sun, 2 Dec 2018 18:40:57 +0000 Message-ID: References: <897126DE-FC79-48FF-9B35-3E262EBDF093@intel.com> <039ED4275CED7440929022BC67E70611532F7D53@SHSMSX103.ccr.corp.intel.com>, <0A3DA11B-6998-4343-8C2C-D4D7E91943B6@intel.com> In-Reply-To: <0A3DA11B-6998-4343-8C2C-D4D7E91943B6@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] DFS (DPDK Filesystem) 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: Sun, 02 Dec 2018 18:41:00 -0000 Sent from my iPhone > On Nov 30, 2018, at 10:01 AM, Wiles, Keith wrote: >=20 > Plain text format is a real pain unless I time travel to the 1990=92s :-( >=20 >> On Nov 30, 2018, at 7:13 AM, Zhang, Qi Z wrote: >>=20 >> Hi Keith: >>=20 >>=20 >>> -----Original Message----- >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith >>> Sent: Tuesday, November 27, 2018 11:00 PM >>> To: dpdk-dev >>> Cc: Richardson, Bruce ; Yigit, Ferruh >>> ; Thomas Monjalon ; >>> Ananyev, Konstantin >>> Subject: Re: [dpdk-dev] [RFC] DFS (DPDK Filesystem) >>>=20 >>>=20 >>>=20 >>>> On Oct 8, 2018, at 5:42 PM, Wiles, Keith wrote= : >>>>=20 >>>> Hi Everyone, >>>>=20 >>>> I would like to request comments on DFS as I presented at the DPDK sum= mit >>> in Ireland. >>>>=20 >>>> As we know DPDK can be difficult to manage at run time and as DPDK >>> becomes more dynamic we need to address how to configure and monitor >>> DPDK and DPDK-based applications. A possible solution is to use FUSE fi= le >>> system support already in the Linux kernel through a DPDK library to ex= pose a >>> directory structure for anyone to be able to monitor and control the ap= p by >>> reading/writing files. >>>>=20 >>>> Primarily DPDK runs on Linux based systems, where FUSE is well support= ed. >>> FUSE was added to FreeBSD 10 which appears to be the same design as Lin= ux. >>> Windows does not support FUSE directly from MS, but a open source desig= n >>> has a FUSE based set of wrapper APIs to help port FUSE based file syste= ms. >>>>=20 >>>> Today the only way to get information out of DPDK is to use log files = or a >>> command line within DPDK to display the information. The information is= not >>> easy for an external application to collect or monitor. Using DFS any a= pplication >>> can read and write into this virtual file system (FUSE) and retrieve in= formation >>> from DPDK/Application via a raw ASCII text file and/or JSON formatted t= ext. >>>>=20 >>>> Data read from DFS can be static or dynamic e.g. version/copyright tex= t >>> would be static, but port stats would be dynamic and generated when the= user >>> requests the information. Writing new configuration data into DPDK can = be a >>> simple number or text or a JSON data structure. Writing simple ASCII te= xt data >>> is simple, but writing a long JSON or configuration file may some care,= i.e. write >>> a path to a file in DFS to the location of the configuration and use th= at file path >>> for the configuration. >>>>=20 >>>> DPDK command line is getting to be very complex and long, but we can >>> eliminate or greatly reduce the command line by using DFS to configure = DPDK >>> at startup along with the application configuration. Having DPDK start = up with >>> minimum resources and allow updating/creating a file in the DPDK file s= ystem >>> to configure DPDK would be easier. >>>>=20 >>>> The DFS is a FUSE filesystem anchored at /dpdk in the host file system= , then a >>> directory is created under /dpdk for each DPDK instance or application = using >>> - as a directory name format. Then it is up to DPDK/Applicat= ion to >>> create the directory structures, permissions and files within the direc= tory >>> mount point. >>>>=20 >>>> Currently I have a directory and files layout for DPDK, that needs mor= e >>> attention as I was focusing on FUSE then the layout as it can be change= d fairly >>> easily. I can email the working documentation for DFS if needed please = send me >>> a short email or I can post to the dev list. The docs also try to expla= in the design >>> and APIs used by the developer for creating files/directories. The docs= are still a >>> work in progress and more attention needs to be done as we progress. >>>>=20 >>>> DFS is just a library and not required to be used plus it does not mod= ify DPDK >>> APIs or structures except for adding a few new dump routines for featur= es that >>> do not have one today. The file system or FUSE backend in DPDK is a fre= e >>> floating thread at this time, but could be affinitized to a core if req= uired. >>>>=20 >>>> The FUSE protocol to the backend code (in DPDK) has a large number of >>> operations, but we have simplified the interface for developers to 5-6.= The >>> interface on top of libfuse3 is very simple and currently provides most= of the >>> needed APIs for managing the files and directories. The FUSE file syste= m with >>> the added simpler API is dynamic and can be changed at runtime. The >>> directory/files can be constructed via APIs at startup or anytime after= startup. >>>>=20 >>>> I would like to put a repo someplace with DPDK/DFS say on GitHub to al= low >>> others to play with the design in the short term. I also have a doc fil= e for DFS if >>> anyone wants to learn more information and will be in the repo as well.= If we >>> agree I can then create a set of patches for DPDK. >>>=20 >>> Well the 18.11 release is out the door, this one seemed pretty big and = I lot of >>> hard work was put into this one, thanks to everyone. >>>=20 >>>=20 >>> It is time to try and get some feedback on this RFC. I know the code in= the repo >>> is not finished, but I would like to get some folks to give it a try an= d give >>> feedback. I would like to submit the basic DFS code with some low hangi= ng >>> items mostly readonly information for the 19.02 release. >>>=20 >>> Here is the repo again you can look at and play with. The code is mostl= y ready >>> for upstream but still more work needs to be done. I will try to update= the repo >>> to the 18.11 release code based soon. >>>=20 >>> https://github.com/pktgen/dfs-dpdk >>>=20 >>> Thanks for giving this a review. >>=20 >> Some thoughts base on a quick test and review. >>=20 >> Overall, I think this is a very handy feature. I really hope it can be m= erged quickly :) >>=20 >> Below are some captures: >>=20 >> 1) when I try to test dfs with exist application (say testpmd), I need t= o replace rte_eal_init with dfs_eal_init,=20 >> I think a better way is by using args like --dfs which can avoid the cod= e change, but please let me know if I missed the point. >=20 > This is a good idea, let me look into what that would take. I do not want= to require DFS to be linked into the image in this case so =97dfs need to = be a noop if not present. I did change the code to use the =97dfs option and it looks like it will wo= rk out well. Will update the repo soon with changes.=20 >>=20 >> 2) Is PMD allowed to use dfs to expose device specific information (priv= ate API access, utilities for diagnose purpose ...) ? if it is=20 >> I think dfs could provide more standard way for PMD to add content to a = sub directory , It could be=20 >> struct dfs_ops { >> mount(dfs_node parent...); /* create content of in the sub dire= ctory */ >> unmount(dfs_node parent...); /* destroy the content. */ >> } =20 >>=20 >> PMD is responsible for creating a dfs_ops instance and setup the callbac= k functions during initialization.(probe) >> An API rte_eth_dev_get_dfs_ctx(port_id) can be used to get the context t= hat wrapped dfs_ops and related ethdev instance. (similar for cryptodev and= others ) >> So during dfs init, after we create folder for a port, we can do additio= nal step to create a parent node for PMD then call its's dev_ops->mount, th= en all the device specific information will be popped in that folder >>=20 >=20 > This seems like a reasonable option, it sounds like a callback from the D= FS init or possible a constructor method. >=20 > PMD is responsible for creating a dfs_ops instance and setup the callback= functions during initialization.(probe) > An API rte_eth_dev_get_dfs_ctx(port_id) can be used to get the context th= at wrapped dfs_ops and related ethdev instance. (similar for cryptodev and = others ) > So during dfs init, after we create folder for a port, we can do addition= al step to create a parent node for PMD then call its's dev_ops->mount, the= n all the device specific information will be popped in that folder >> 3) For primary-secondary model, dfs should works well, but the missing p= art is there is no link between primary and secondary process,=20 >> it will be nature if we can list all secondary process in a primary fold= er or even better if we can jump to secondary folder by some soft link and = same thing in the reverse direction.=20 >=20 > I think this can be done, but each secondary would have its own dfs file = system. Adding the links could be reasonable if we could assume the seconda= ry processes are always up. >=20 >>=20 >> Thanks >> Qi >>=20 >>>=20 >>>>=20 >>>> Regards, >>>> Keith >>>>=20 >>>=20 >>> Regards, >>> Keith >=20 > Regards, > Keith >=20