[dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports

Aaron Conole aconole at redhat.com
Mon Jan 18 17:20:02 CET 2016

Ferruh Yigit <ferruh.yigit at 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.


More information about the dev mailing list