From: Ferruh Yigit <ferruh.yigit@intel.com>
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: Tue, 19 Jan 2016 10:08:07 +0000 [thread overview]
Message-ID: <20160119100807.GA20995@sivlogin002.ir.intel.com> (raw)
In-Reply-To: <CADNuJVqc5_TNTHv=SaUtgn0s=DwyD_LUC48Dw_n+Am9ufBDCSg@mail.gmail.com>
On Mon, Jan 18, 2016 at 05:48:51PM -0600, Jay Rolette 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.
>
There is also another work going on for slow path communication, which converts
KNI's slow patch communication part to a PMD, to make it easier to use. An RFC
patch will be in mailing list next days.
Overall two responsibilities of KNI will be distributed into two different piece
of code with some enhancements.
If these new pieces get accepted by users and covers all KNI use cases, in long
run KNI can be depreciated...
Thanks,
ferruh
prev parent reply other threads:[~2016-01-19 10:08 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
2016-01-19 10:08 ` Ferruh Yigit [this message]
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=20160119100807.GA20995@sivlogin002.ir.intel.com \
--to=ferruh.yigit@intel.com \
--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).