[dpdk-dev] [PATCH v8 0/4] Userspace Network Control Interface (UNCI)

[Bruce Richardson]

On Wed, Jun 21, 2017 at 12:06:47PM +0100, Ferruh Yigit wrote:
> Userspace Network Control Interface (UNCI), (formerly KCP).
> 
> When a NIC bound to the DPDK, it can't be controlled by Linux tools.
> 
> This patch creates a virtual network interface for each DPDK port,
> initial target is to get some data from those interfaces, in next
> step target is to control DPDK ports using virtual interfaces.
> 

I've tried out this set to see how it goes, and apart from a few
compile/link errors with individual patches which I've flagged, I think
the result is great. Running testpmd and seeing the dpdk interfaces
listed in "ifconfig" for example, is a great improvement for usability.
Let's hope we can get this into DPDK as soon as possible.

Some thoughts about the patchset:

1. Do we really need to use a whole new library for the ethtool
functions? Can the UNCI userspace code not just call into ethdev
directly without going through another library?

2. Right now the interfaces are only created on application start, but
are not removed on app close. My first thought is that we should correct
his imbalance, but perhaps it might be better to always have the
interfaces displayed even before/after an app has run. We obviously need
some way of detecting if a process is controlling the ports or not, but
I'm hopeful that should be doable without too much work.

3. From a patchset split point of view, could this set be split up to be
a bit more granular. There are a lot of functions to be performed on
NICs called out in the code, e.g. start/stop, get stats, etc. etc. To
make review easier, should we initially add the kernel module and
userspace parts with just one function supported, and then add in each
additional function in a new patchset, so that we can clearly see the
code for each function isolated from the rest. This is the approach -
adding feature by feature - that is recommended for NIC drivers, and it
might make sense here too.

Otherwise, great work. I think this is a huge improvement in usability
for DPDK, especially if we add in future support for controlling DPDK
interfaces in a (not interfering with the app) safe manner too.

/Bruce