All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Ryzhov <iryzhov@nfware.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: KNI discussion in userspace event
Date: Fri, 28 Oct 2016 22:23:01 +0300	[thread overview]
Message-ID: <CAF+s_FwVWxbbF9Yf8B=hR9ZqOiTO5SEYaO0LipyXcaHQeos8Sg@mail.gmail.com> (raw)
In-Reply-To: <9236278.Tlj3KysXEu@xps13>

On Fri, Oct 28, 2016 at 9:40 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
wrote:

> 2016-10-28 20:29, Igor Ryzhov:
> > On Fri, Oct 28, 2016 Thomas Monjalon wrote:
> > > 2016-10-28 15:51, Richardson, Bruce:
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > > > > 2016-10-28 15:31, Ferruh Yigit:
> > > > > > * Remove ethtool support ?
> > > > >
> > > > > That's the other part of KNI.
> > > > > It works only for e1000/ixgbe. That's a niche.
> > > >
> > > > Yes, it's something we need to remove, but again, we need an
> > > > alternative first.
> > > >
> > > > >
> > > > > > Still there is some interest, will keep it. But not able to
> extend it
> > > > > > to other drivers with current design.
> > > > >
> > > > > It should be removed one day.
> > > > > We must seriously think about a generic alternative.
> > > > > Either we add DPDK support in ethtool or we create a dpdk-ethtool.
> > > > > (or at least a library as the one in examples/).
> > > >
> > > > I don't view that as a great path forward. Sure, we can do our own
> > > > ethtool, but then people will look for ifconfig to work, and "ip" to
> work,
> > > > etc. I view having a kernel proxy module as the best path here as it
> is
> > > > tool agnostic on the userspace side, rather than trying to make every
> > > > tool for working with kernel netdevs also have support for dpdk
> ports.
> > >
> > > Yes that's the ultimately best solution.
> > > But:
> > > - we need some cooperation of the kernel team
> > > - ethtool manages a device (what DPDK provides) whereas iproute and
> others
> > > manage a TCP/IP stack so is out of control of DPDK.
> >
> > That's not true.
> > iproute can control a lot of things like MAC address, promiscuous, MTU,
> > etc. that cannot be controlled with ethtool.
> > Just compare net_device_ops and ethtool_ops to see the difference.
>
> Yes you're right. iproute was not a good example :)
>
> > And the question is not only about tools, it is also about how Linux
> kernel
> > works with network devices.
> > And it uses net_device_ops, not ethtool_ops.
>
> What do you mean exactly? I feel you have something in mind.
>

My main point is that if we want to control DPDK ports from Linux, it
should be done with standard utilities.
Every standard utility like iproute just uses existing Linux kernel
interfaces and kernel in its turn uses net_device_ops to control the device.

For example, you want to set MTU of the network device.
Regardless of the utility you use to do that (even if you write your own),
there are two options – ioctl or netlink.
And regardless of the method you choose,  Linux kernel will then call
"ndo_change_mtu".

  reply	other threads:[~2016-10-28 19:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-28 14:31 KNI discussion in userspace event Ferruh Yigit
2016-10-28 15:03 ` Igor Ryzhov
2016-10-28 15:13 ` Thomas Monjalon
2016-10-28 15:51   ` Richardson, Bruce
2016-10-28 16:13     ` Thomas Monjalon
2016-10-28 17:29       ` Igor Ryzhov
2016-10-28 18:40         ` Thomas Monjalon
2016-10-28 19:23           ` Igor Ryzhov [this message]
2016-10-28 23:09             ` Vincent Jardin
2016-10-28 16:25 ` Stephen Hemminger
2016-11-23 16:49   ` Aws Ismail

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='CAF+s_FwVWxbbF9Yf8B=hR9ZqOiTO5SEYaO0LipyXcaHQeos8Sg@mail.gmail.com' \
    --to=iryzhov@nfware.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=thomas.monjalon@6wind.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.