From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wang, Liang-min" Subject: Re: [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs Date: Sun, 31 May 2015 18:31:39 +0000 Message-ID: References: <1432946276-9424-1-git-send-email-liang-min.wang@intel.com> <1432946276-9424-3-git-send-email-liang-min.wang@intel.com> <20150530084800.56e3585e@urahara> <20150530122617.1bf2cd18@urahara> <20150531094828.371263fe@urahara> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: Stephen Hemminger Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 2F23E12A8 for ; Sun, 31 May 2015 20:31:42 +0200 (CEST) Content-Language: en-US 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 Sat, 30 May 2015 19:40:46 +0000 >>"Wang, Liang-min" wrote: >> >>>=20 > >>On Sat, 30 May 2015 16:16:01 +0000 > >>"Wang, Liang-min" wrote: > >> > >> >>The design decision is to keep ethdev as THE interface for all the e= xternal API, so ethtool APIs are designed based upon ethdev API. At the mea= ntime, the ethtool APIs are designed to enable users to migrate designs bas= ed upon kernel-space ethtool. The open/close/start are put in place to enab= le quick migration. > >>> > >>>But there is no open/close/start in ethtool in kernel. > >>>Anyway ethtool is currently on the disfavored list from kernel develop= ers. > >>>What about netlink or something better? > >>> > >>>Remember each new API creates more long term compatiablity and ABI iss= ues. > >>>So I am against introducing any new API that does the same thing as ex= isting API's. > >> >>> Just to clarify APIs supported by this ethtool api: there are=20 >>> net_open > >>and net_stop and no net_start. Both functions are put in place to=20 > >>support net_device_ops::ndo_open and net_device_ops::ndo_close as=20 > >>defined in linux/netdevice.h >> >> >>I get the feeling there is some use case you are not telling the list abo= ut. >>What kind of application would use this api only. Why or how would DPDK a= pplication be involved in net_device_ops. If you are planning on putting DP= DK in the kernel there are lots of other issues >>including kernel ABI stab= ility and licensing that need to be dealt with. > >(I'm manually adding ">" through my email, outlook, to make my reply. I ap= ology if I make any mistake on adding ">" in wrong place) No, we don't plan= to put DPDK into kernel space, and this patch has >nothing to do with bifu= rcated driver that was announced for DPDK 2.0 then got scrubbed (or deferre= d). In contrary, the entire ethtool API (more support is coming) is designe= d to assist applications that >were designed based upon kernel ethtool to m= igrate into user-space driver based DPDK libraries. Being said that, as you= are aware the kernel version of ndo_open/ndo_close is more than just start= and >stop device. The initial implementation is to provide minimum functio= nality (strip off all the kernel related state management). In the future r= elease (we need comments like yours), we will continue >make improvement. S= o this new API can be another alternative for applications to run device ma= nagement. Just to clarify my last reply: when I said "... based upon kernel ethtool t= o migrate ...", I was referring to both ethtool and net_device_op.