From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Panu Matilainen <pmatilai@redhat.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
Date: Thu, 4 Feb 2016 13:30:35 +0000 [thread overview]
Message-ID: <20160204133035.GA6128@sivlogin002.ir.intel.com> (raw)
In-Reply-To: <569E1E1C.6050406@redhat.com>
On Tue, Jan 19, 2016 at 01:29:32PM +0200, Panu Matilainen wrote:
> 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.
>
Hi Stephen, and other Linux experts in the mail list,
Can you please help finding a upstreamable solution for kernel control path?
Mainly what we are looking for is userspace network driver support in kernel, similar to what FUSE does but a much simple version.
Above KCP module basically does this, by having a network driver which passing requests to userspace network driver, but it is not generic enough.
I wonder if it is possible make it more generic by extending rtnetlink support:
1- Add a new network driver to Linux (or update existing one like tun) to forward requests, get responses.
2- Extend rtnelink to support to attach any userspace driver to this device? (ip link set <device> uspace <?> ?)
Does this make sense?
rtnetlink already supports creating interfaces, and it provides kernel/user space communication,
with "attach" support interface learns about it's peer in usersppace and can communicate.
FUSE like communication method also can be alternative to transfer request and responses, but since rtnelink support exists, no need to create something new think.
Thanks,
ferruh
next prev parent reply other threads:[~2016-02-04 13:30 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 [this message]
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=20160204133035.GA6128@sivlogin002.ir.intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=pmatilai@redhat.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).