From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Conole Subject: Re: Replacing KCP (Kernel Control Path) out-of-tree kernel module with in-kernel module Date: Tue, 16 Feb 2016 10:06:47 -0500 Message-ID: References: <20160216144830.GA2297@sivlogin002.ir.intel.com> Mime-Version: 1.0 Content-Type: text/plain To: dev@dpdk.org Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id A8408C166 for ; Tue, 16 Feb 2016 16:06:49 +0100 (CET) In-Reply-To: <20160216144830.GA2297@sivlogin002.ir.intel.com> (Ferruh Yigit's message of "Tue, 16 Feb 2016 14:48:30 +0000") List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Ferruh, Ferruh Yigit 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