From mboxrd@z Thu Jan 1 00:00:00 1970 From: Panu Matilainen Subject: Re: [RFC 0/3] Use common Linux tools to control DPDK ports Date: Tue, 19 Jan 2016 13:29:32 +0200 Message-ID: <569E1E1C.6050406@redhat.com> References: <1452874684-12750-1-git-send-email-ferruh.yigit@intel.com> <87twmauafh.fsf@redhat.com> <20160119095950.GA15736@sivlogin002.ir.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Ferruh Yigit Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 4ECBF5A62 for ; Tue, 19 Jan 2016 12:29:35 +0100 (CET) In-Reply-To: <20160119095950.GA15736@sivlogin002.ir.intel.com> 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" 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 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. - Panu -