DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Jay Rolette <rolette@infiniteio.com>
Cc: DPDK <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
Date: Mon, 18 Jan 2016 17:36:37 -0800	[thread overview]
Message-ID: <20160118173637.09afa765@xeon-e3> (raw)
In-Reply-To: <CADNuJVqc5_TNTHv=SaUtgn0s=DwyD_LUC48Dw_n+Am9ufBDCSg@mail.gmail.com>

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.

  reply	other threads:[~2016-01-19  1:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15 16:18 Ferruh Yigit
2016-01-15 16:18 ` [dpdk-dev] [RFC 1/3] rte_ctrl_if: add control interface library Ferruh Yigit
2016-01-15 16:18 ` [dpdk-dev] [RFC 2/3] kcp: add kernel control path kernel module Ferruh Yigit
2016-01-15 16:18 ` [dpdk-dev] [RFC 3/3] examples/ethtool: add control interface support to the application Ferruh Yigit
2016-01-18 16:20 ` [dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports Aaron Conole
2016-01-19  9:59   ` Ferruh Yigit
2016-01-19 11:29     ` Panu Matilainen
2016-02-04 13:30       ` Ferruh Yigit
2016-02-04 13:38         ` Ferruh Yigit
2016-02-04 14:40         ` Aaron Conole
2016-02-04 16:28           ` Ferruh Yigit
2016-01-18 23:12 ` Stephen Hemminger
2016-01-18 23:48   ` Jay Rolette
2016-01-19  1:36     ` Stephen Hemminger [this message]
2016-01-19 10:08     ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160118173637.09afa765@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=rolette@infiniteio.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).