From: Aaron Conole <aconole@redhat.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
Date: Mon, 18 Jan 2016 11:20:02 -0500 [thread overview]
Message-ID: <87twmauafh.fsf@redhat.com> (raw)
In-Reply-To: <1452874684-12750-1-git-send-email-ferruh.yigit@intel.com> (Ferruh Yigit's message of "Fri, 15 Jan 2016 16:18:01 +0000")
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? I think the other stuff
can be accomplished using netlink sockets + messages, no? 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.
Especially since (continued below)...
> 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.
>
> Basically with the help of a kernel module (KCP), virtual Linux network
> interfaces named as "dpdk$" are created per DPDK port, control messages
> sent to these virtual interfaces are forwarded to DPDK, and response
> sent back to Linux application.
>
> Virtual interfaces created when DPDK application started and destroyed
> automatically when DPDK application terminated.
>
> Communication between kernel-space and DPDK done using netlink socket.
... you're already using a netlink socket here.
> Currently implementation is not complete, sample support added for the
> RFC, more functionality can be added based on community response.
>
> With this RFC Patch, supported: get/set mac address/mtu of DPDK devices,
> getting stats from DPDK devices and some set of ethtool commands.
I actually think there could be some additional features for
debuggability with this approach, so in general I like goal - I just have
implementation nit picks.
-Aaron
next prev parent reply other threads:[~2016-01-18 16:20 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 ` Aaron Conole [this message]
2016-01-19 9:59 ` [dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports 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
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=87twmauafh.fsf@redhat.com \
--to=aconole@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 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).