[dpdk-dev] [PATCH v3 1/3] dfs:add FUSE based filesystem for DPDK

[Thomas Monjalon]

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.