From: Panu Matilainen <pmatilai@redhat.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org
Subject: Re: [RFC 0/3] Use common Linux tools to control DPDK ports
Date: Tue, 19 Jan 2016 13:29:32 +0200 [thread overview]
Message-ID: <569E1E1C.6050406@redhat.com> (raw)
In-Reply-To: <20160119095950.GA15736@sivlogin002.ir.intel.com>
On 01/19/2016 11:59 AM, Ferruh Yigit wrote:
> On Mon, Jan 18, 2016 at 11:20:02AM -0500, Aaron Conole wrote:
>> Ferruh Yigit <ferruh.yigit@intel.com> writes:
>>> This work is to make DPDK ports more visible and to enable using common
>>> Linux tools to configure DPDK ports.
>>
>> This is a good goal. Only question - why use an additional kernel module
>> to do this? Is it _JUST_ for ethtool support?
>
> Kernel module used to create/destroy Linux net_devices, and module has a simple
> driver for that device which only handles control messages by passing them into
> userspace.
>
> To represent DPDK ports as Linux net_devices we need kernel support.
>
>> I think the other stuff
>> can be accomplished using netlink sockets + messages, no?
>
> Netlink sockets just used to communicate kernel-space - user-space, this is not
> why we need a kernel module, for example this communication is implemented in
> original KNI as part of FIFO.
>
>> The only
>> trepidation I would have with something like this is the support from
>> major vendors - out of tree modules are not generally supportable. Might
>> be good to get some of the ethtool commands as netlink messages as well,
>> then it is supportable with no 3rd party kernel modules.
>
> Yes, there is a out of three module problem for some distros, but unfortunately
> we are not able to find a solution for this case without an external kernel module.
>
> This patch is still an RFC and if we receive suggested solution without a kernel
> module, we can work on it together.
If it has to be in the kernel then you need to find a design that is
upstreamable. Out of tree kernel modules are not a solution, they're a
problem that people are working on eliminating.
- Panu -
next prev parent reply other threads:[~2016-01-19 11:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-15 16:18 [RFC 0/3] Use common Linux tools to control DPDK ports Ferruh Yigit
2016-01-15 16:18 ` [RFC 1/3] rte_ctrl_if: add control interface library Ferruh Yigit
2016-01-15 16:18 ` [RFC 2/3] kcp: add kernel control path kernel module Ferruh Yigit
2016-01-15 16:18 ` [RFC 3/3] examples/ethtool: add control interface support to the application Ferruh Yigit
2016-01-18 16:20 ` [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 [this message]
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
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=569E1E1C.6050406@redhat.com \
--to=pmatilai@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.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.