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

Panu Matilainen pmatilai at redhat.com
Tue Jan 19 12:29:32 CET 2016

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 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?
> 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 -

More information about the dev mailing list