Re: [dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 18 Jan 2016 17:48:51 -0600
Jay Rolette <rolette@infiniteio.com> wrote:

> On Mon, Jan 18, 2016 at 5:12 PM, Stephen Hemminger <
> stephen@networkplumber.org> wrote:
> 
> > On Fri, 15 Jan 2016 16:18:01 +0000
> > Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >
> > > 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.
> >
> > I actually would like KNI to die and be replaced by something generic.
> > Right now with KNI it is driver and hardware specific. It is almost as if
> > there
> > are three drivers for ixgbe, the Linux driver, the DPDK driver, and the
> > KNI driver.
> >
> 
> Any ideas about what that would look like? Having the ability to send
> traffic to/from DPDK-owned ports from control plane applications that live
> outside of (and are ignorant of) DPDK is a platform requirement for our
> product.
> 
> I'm assuming that isn't uncommon, but that could just be the nature of the
> types of products I've built over the years.
> 
> That said, I'd love there to be something that performs better and plays
> nicer with the system than KNI.

Maybe something using switchdev API in kernel? Or making the bifurcated
driver model work? Or something more like netmap where actual driver code
is in kernel for controlling hardware and only ring buffers need to be
exposed.

The existing DPDK although high performance suffers from lots of cases
of DRY (https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).
For a recent example, we discovered that VLAN's don't work on I350
because the code to handle the workaround for byte swapping is not
there in DPDK (it is in the Linux driver).  Because DPDK causes
there to be has two driver code bases, this kind of problem is bound
to occur.

I realize this is a very hard problem, and there is no quick solution.
Any long term solution will require work in both spaces kernel and DPDK.