From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 8BCC95A54 for ; Fri, 5 Jun 2015 16:20:59 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 05 Jun 2015 07:21:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,559,1427785200"; d="scan'208";a="503275719" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by FMSMGA003.fm.intel.com with ESMTP; 05 Jun 2015 07:20:59 -0700 Received: from orsmsx115.amr.corp.intel.com (10.22.240.11) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 5 Jun 2015 07:20:58 -0700 Received: from fmsmsx103.amr.corp.intel.com (10.18.124.201) by ORSMSX115.amr.corp.intel.com (10.22.240.11) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 5 Jun 2015 07:20:37 -0700 Received: from FMSMSX110.amr.corp.intel.com ([169.254.14.46]) by FMSMSX103.amr.corp.intel.com ([169.254.2.66]) with mapi id 14.03.0224.002; Fri, 5 Jun 2015 07:20:26 -0700 From: "Wang, Liang-min" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs Thread-Index: AQHQmkV0vh50QuHJo0WVOZnDigauCp2ZosAA//+RahCAAI6iAP//nQiAgAB8IAD//5lG4AAWcj8AAAuWYIAATSGtAAAPFjyAABps1IAADi2nQP//vyoAgABvQzA= Date: Fri, 5 Jun 2015 14:20:25 +0000 Message-ID: References: <1432927612-12244-1-git-send-email-liang-min.wang@intel.com> <18146131.KjMWrd7xqb@xps13> <1840741.YhHFF9Rtvs@xps13> In-Reply-To: <1840741.YhHFF9Rtvs@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 14:21:00 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, June 05, 2015 9:41 AM > To: Wang, Liang-min > Cc: Andrew Harvey (agh); Stephen Hemminger; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide > ethtool-alike APIs >=20 > 2015-06-05 11:25, Wang, Liang-min: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > Stephen and me say the same thing about using the ethdev API. > > > We don't understand why using a fake ethtool lib would be easier. > > > Though you are saying it "facilitated [your] adoption to dpdk". > > > Please could you explain why using an ethtool-like API is easier > > > than using the existing ethdev API? > > > In any case, you have to develop a specific backend for DPDK > > > (rte_ethtool would be also DPDK-specific). > > > > As described earlier in this patch comment reply, there are other ethto= ol > ops that have been implemented. > > Those ops includes set/get eeprom, set/get pauseparam, set/get > ringparam which are not available in the exiting ethdev library. >=20 > 1/ We cannot really consider code which is not public 2/ You may extend > ethdev if some functions are missing >=20 > > For this release, we focus on releasing some basic functions (btw, > mac_addr_set is not available but is covered by this patch). >=20 > Yes, you are extending ethdev by adding > rte_eth_dev_default_mac_addr_set. >=20 > > The key reason that this set of library is not released as part of ethd= ev is > the ethtool API dependency on kernel include file. >=20 > It is a good reason to separate the library. > But it doesn't justify its need. >=20 > > To faithfully carry the ethtool ops and net dev ops API parameters, the > ethtool APIs are designed to follow the original definition except avoidi= ng > carry kernel states. > > With that, to support ethtool APIs faithfully, we need to include > . > > As suggested by many DPDK veterans including Thomas (indicated over > your reply), you would prefer these APIs in a separate library. >=20 > I think I'm starting to understand that you really need ethtool conversio= n > (implemented in rte_ethtool_get_drvinfo) but not the other functions whic= h > are simple wrappers. Right? The rte_ethtool_get_drvinfo and many others ethtool ops have the same conve= rsion requirement. As for ethtool and net dev ops that don't require conversion. For the sake = of clean API interface, they are implemented in the same ethtool library.