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 -