From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 0FC78C0BBE68; Tue, 16 Feb 2016 15:06:49 +0000 (UTC) Received: from aconole-fed23 (dhcp-25-25.bos.redhat.com [10.18.25.25]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1GF6lJo031188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Feb 2016 10:06:48 -0500 From: Aaron Conole To: dev@dpdk.org References: <20160216144830.GA2297@sivlogin002.ir.intel.com> Date: Tue, 16 Feb 2016 10:06:47 -0500 In-Reply-To: <20160216144830.GA2297@sivlogin002.ir.intel.com> (Ferruh Yigit's message of "Tue, 16 Feb 2016 14:48:30 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Subject: Re: [dpdk-dev] Replacing KCP (Kernel Control Path) out-of-tree kernel module with in-kernel module X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 15:06:50 -0000 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