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

[Ferruh Yigit]

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

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