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