[dpdk-dev] Replacing KCP (Kernel Control Path) out-of-tree kernel module with in-kernel module

[dpdk-dev] Replacing KCP (Kernel Control Path) out-of-tree kernel module with in-kernel module

[Ferruh Yigit]

This is continuation of previous mail thread:
	http://dpdk.org/ml/archives/dev/2016-February/032701.html

Since there were no comments, I want to give another try, this can be good opportunity to escape from out-of-kernel Linux module.

First high level important question:
- Do you think will Linux community welcome a network driver that enables/supports userspace network driver?


And let me rephrase what I have in my mind:
- Implement a Linux network driver, that uses rtnetlink, so that userspace applications can create network interfaces.
- This driver implements net_device_ops as a forwarding layer to userspace; using netlink sockets.
- Each userspace network driver has a unique identifier.
- Userspace drivers listens netlink group created by kernel driver.
- An application, or userspace driver itself, attaches userspace driver, by providing its unique id, to the created network interface. This associates network interface to userspace driver.
- After this point userspace driver detects its own id in netlink messages and responds back to the requests.
- Anytime userspace driver can be detached and network interface can be removed by a userspace application.

I believe this can work, but not sure if this worths to the investment because this can be quite some work. Also not sure if this gets accepted by Linux upstream.
I would like to have some support/feedback to undertake something like this.

Any comment is welcome.


Thanks,
ferruh

Re: [dpdk-dev] Replacing KCP (Kernel Control Path) out-of-tree kernel module with in-kernel module

[Aaron Conole]

Hi Ferruh,

Ferruh Yigit <ferruh.yigit@intel.com> writes:
> This is continuation of previous mail thread:
> 	http://dpdk.org/ml/archives/dev/2016-February/032701.html
>
> Since there were no comments, I want to give another try, this can be
> good opportunity to escape from out-of-kernel Linux module.

Awesome! I fully endorse this effort, btw :)

> First high level important question:
> - Do you think will Linux community welcome a network driver that
> enables/supports userspace network driver?
>
> And let me rephrase what I have in my mind:
>
> - Implement a Linux network driver, that uses rtnetlink, so that
> userspace applications can create network interfaces.
> - This driver implements net_device_ops as a forwarding layer to
> userspace; using netlink sockets.

I think a new driver isn't needed. There exists the TUN/TAP driver, so
it might be better to provide a way of implementing a (for lack of
better terms) forwarding layer in that device. There are some things
that I think would make sense for upstream to accept (after all, if
userspace creates this tun/tap device and wants to get involved in the
control side, there are many hoops that need to be jumped). I also think
such an effort could gain some traction upstream.

On the other hand, for most actions there exists already a bunch of APIs
for interacting with TAP/TUN devices for monitoring changes.

If you want more info on what the heck I'm talking about, there's a
project called switchlink which aims to do some kind of switch
management in P4; the library they have uses event listeners and
rtnetlink to know when a device has been added, monitors state, etc. I
think such an approach from the dpdk side would be useful to accomplish
this task.

> - Each userspace network driver has a unique identifier.
> - Userspace drivers listens netlink group created by kernel driver.
> - An application, or userspace driver itself, attaches userspace
> driver, by providing its unique id, to the created network
> interface. This associates network interface to userspace driver.
> - After this point userspace driver detects its own id in netlink
> messages and responds back to the requests.
> - Anytime userspace driver can be detached and network interface can
> be removed by a userspace application.
>
> I believe this can work, but not sure if this worths to the investment
> because this can be quite some work. Also not sure if this gets
> accepted by Linux upstream.

As always, it's the actual code that counts. No amount of pontification
or prognostication changes that.

> I would like to have some support/feedback to undertake something like this.

I am happy to work with you on this effort. I can feed you some of my
old "unpolished" (read hacky proof of concept) patches if you want to
see what I've done in this area. I am currently trying to get some other
stuff cleared off my backlog.

> Any comment is welcome.
>
> Thanks,
> ferruh

-Aaron