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 235C28D96 for ; Mon, 18 Jan 2016 17:20:05 +0100 (CET) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 5708337C371; Mon, 18 Jan 2016 16:20:04 +0000 (UTC) Received: from aconole-fed23 (dhcp-25-113.bos.redhat.com [10.18.25.113]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0IGK30H029332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Jan 2016 11:20:03 -0500 From: Aaron Conole To: Ferruh Yigit References: <1452874684-12750-1-git-send-email-ferruh.yigit@intel.com> Date: Mon, 18 Jan 2016 11:20:02 -0500 In-Reply-To: <1452874684-12750-1-git-send-email-ferruh.yigit@intel.com> (Ferruh Yigit's message of "Fri, 15 Jan 2016 16:18:01 +0000") Message-ID: <87twmauafh.fsf@redhat.com> 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.24 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports 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: Mon, 18 Jan 2016 16:20:05 -0000 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? I think the other stuff can be accomplished using netlink sockets + messages, no? 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. Especially since (continued below)... > Patch is based on KNI but contains only control functionality of it, > also this patch does not include any Linux kernel network driver as > part of it. > > Basically with the help of a kernel module (KCP), virtual Linux network > interfaces named as "dpdk$" are created per DPDK port, control messages > sent to these virtual interfaces are forwarded to DPDK, and response > sent back to Linux application. > > Virtual interfaces created when DPDK application started and destroyed > automatically when DPDK application terminated. > > Communication between kernel-space and DPDK done using netlink socket. ... you're already using a netlink socket here. > Currently implementation is not complete, sample support added for the > RFC, more functionality can be added based on community response. > > With this RFC Patch, supported: get/set mac address/mtu of DPDK devices, > getting stats from DPDK devices and some set of ethtool commands. I actually think there could be some additional features for debuggability with this approach, so in general I like goal - I just have implementation nit picks. -Aaron