From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <liang-min.wang@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id 2F23E12A8
 for <dev@dpdk.org>; Sun, 31 May 2015 20:31:42 +0200 (CEST)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by orsmga103.jf.intel.com with ESMTP; 31 May 2015 11:31:41 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.13,527,1427785200"; d="scan'208";a="738337559"
Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128])
 by orsmga002.jf.intel.com with ESMTP; 31 May 2015 11:31:41 -0700
Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by
 ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS)
 id 14.3.224.2; Sun, 31 May 2015 11:31:41 -0700
Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by
 ORSMSX155.amr.corp.intel.com (10.22.240.21) with Microsoft SMTP Server (TLS)
 id 14.3.224.2; Sun, 31 May 2015 11:31:40 -0700
Received: from FMSMSX110.amr.corp.intel.com ([169.254.14.46]) by
 FMSMSX113.amr.corp.intel.com ([169.254.13.51]) with mapi id 14.03.0224.002;
 Sun, 31 May 2015 11:31:40 -0700
From: "Wang, Liang-min" <liang-min.wang@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Thread-Topic: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide
 ethtool-alike APIs
Thread-Index: AQHQmnDoomo5ZxYF70Oz8oQmwyPno52VIHkA//+NpACAAK9ZgP//jKbAgAHZlwD//5NhwAACW7Mg
Date: Sun, 31 May 2015 18:31:39 +0000
Message-ID: <B6CB929FEBC10D4FAC4BCA7EF2298E2571764DF7@FMSMSX110.amr.corp.intel.com>
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>
 <B6CB929FEBC10D4FAC4BCA7EF2298E2571764BCF@FMSMSX110.amr.corp.intel.com>
 <20150530122617.1bf2cd18@urahara>
 <B6CB929FEBC10D4FAC4BCA7EF2298E2571764C06@FMSMSX110.amr.corp.intel.com>
 <20150531094828.371263fe@urahara> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.200.106]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide
 ethtool-alike APIs
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Sun, 31 May 2015 18:31:42 -0000


>>On Sat, 30 May 2015 19:40:46 +0000
>>"Wang, Liang-min" <liang-min.wang@intel.com> wrote:
>>
>>>=20
> >>On Sat, 30 May 2015 16:16:01 +0000
> >>"Wang, Liang-min" <liang-min.wang@intel.com> 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.