[dpdk-dev] [PATCH v5 0/4] Use common Linux tools to control DPDK ports

[Jay Rolette]

Is there some technical reason or is it just the push-back you are getting
from some of the maintainers?

I chimed in on one of the other threads already, but I'm extremely
disappointed that usability and serviceability improvements to existing
DPDK capabilities (KNI) are getting blocked like this.

For companies building network appliances based on DPDK, having a kernel
module that isn't in the tree just isn't that big of a deal. Long term
goals for getting this upstream are great, but why not take advantage of
incremental improvements in the meantime?

Jay

On Mon, Mar 14, 2016 at 10:31 AM, Ferruh Yigit <ferruh.yigit at intel.com>
wrote:

> On 3/9/2016 11:41 AM, Ferruh Yigit wrote:
> > This patch sent to keep record of latest status of the work.
> >
> >
> > This work is to make DPDK ports more visible and to enable using common
> > Linux tools to configure DPDK ports.
> >
> > Patch is based on KNI but contains only control functionality of it,
> > also this patch does not include any Linux kernel network driver as
> > part of it.
> >
> > Basically with the help of a kernel module (KCP), virtual Linux network
> > interfaces named as "dpdk$" are created per DPDK port, control messages
> > sent to these virtual interfaces are forwarded to DPDK, and response
> > sent back to Linux application.
> >
> > Virtual interfaces created when DPDK application started and destroyed
> > automatically when DPDK application terminated.
> >
> > Communication between kernel-space and DPDK done using netlink socket.
> >
> > In long term this patch intends to replace the KNI and KNI will be
> > depreciated.
> >
>
> Self-NACK: Will work on netdev to upstream this.
>
>