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