[dpdk-dev] [PATCH v8 0/4] Userspace Network Control Interface (UNCI)
ferruh.yigit at intel.com
Thu Jun 29 18:13:10 CEST 2017
On 6/26/2017 12:39 PM, Bruce Richardson wrote:
> 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.
Thanks for trying this and reviews.
> 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?
We don't have to, but ethtool library in sample folder is wrapper around
ethdev APIs for ethtool functions, that fits well here, and we can
re-use that code.
> 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.
Yes, currently interfaces should be removed manually via "ip", but this
is because PMD destroy code paths not called during app exit. I am not
sure keeping virtual interfaces always, it looks me better if they
disappear when app exits.
> 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.
Let me try to split patches more.
> 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.
More information about the dev