From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id DDE8ADE0 for ; Thu, 4 Jun 2015 16:25:59 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 04 Jun 2015 07:25:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,552,1427785200"; d="scan'208";a="740943982" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga002.jf.intel.com with ESMTP; 04 Jun 2015 07:25:58 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 4 Jun 2015 15:25:56 +0100 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.36]) by irsmsx155.ger.corp.intel.com ([169.254.14.38]) with mapi id 14.03.0224.002; Thu, 4 Jun 2015 15:25:55 +0100 From: "O'Driscoll, Tim" To: "Andrew Harvey (agh)" , Thomas Monjalon , "Wang, Liang-min" , Stephen Hemminger , "David Harton (dharton)" Thread-Topic: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs Thread-Index: AQHQnaJjdxEJmLJfT0yYsd9XrR/3R52cZ3Vw Date: Thu, 4 Jun 2015 14:25:55 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D55BB3@IRSMSX102.ger.corp.intel.com> References: <1432927612-12244-1-git-send-email-liang-min.wang@intel.com> <38737329.jBeOYmBEyN@xps13> <24712227.WkznNjn3ZB@xps13> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="iso-8859-1" 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: Thu, 04 Jun 2015 14:26:01 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Andrew Harvey (agh) > Sent: Wednesday, June 3, 2015 3:10 AM > To: Thomas Monjalon; Wang, Liang-min > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide > ethtool-alike APIs >=20 > I believe that their is value in this interface for software stacks not > based on Linux being moved toward DPDK that need simple operations like > getting the mac address. Some of these stacks have a dearth of > resources > available and dedicating a core/thread to KNI to get/set a mac address > is considered excessive. There are also issues with 32/64 bit kernel > integration > using KNI. If the ethtool interface is not the correct interface then > please help me > understand what should/could have been used. If ethtool is considered > 'old > and clunky=B9 > Stephen's and your input would be valuable in designing another > interface > with > similar properties. The use-case is pretty simple and there is no plans > for moving > anything back into the kernel on the contrary its the complete opposite. >=20 > < Andy Stephen, Thomas: I think it was the two of you that originally questioned t= he justification for including this change. Now that Andy and Dave Harton h= ave clarified, does this resolve your concerns or do you still have questio= ns? I just want to make sure that we reach a timely conclusion on this. Tim >=20 >=20 > On 6/2/15, 1:37 PM, "Thomas Monjalon" wrote: >=20 > >I have the feeling we are not progressing in this discussion. > >Please bring new explanations or I'll give up. > >David Harton already acked it so maybe he could explain why it is > useful. > > > >Comments below > > > >2015-06-02 17:06, Wang, Liang-min: > >> >2015-06-02 15:47, Wang, Liang-min: > >> >> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > >> >> > >>I'm curious to understand how renaming rte_eth_dev_set_mtu() > to > >> >> > >>rte_ethtool_net_change_mtu() will help anyone. > >> >> >> > >> >> >> As described, this interface is designed to provide API closely > >>to kernel space ethtool ops and net_device_op. > >> >> > >> >> >But the application still needs to adapt the code to call rte_* > >>functions. > >> >> >So changing to rte_ethtool_net_change_mtu is equivalent to change > >>to the existing rte_eth_dev_set_mtu. I don't see the benefit. > >> >> > >> >> The benefit is single interface for users to access. Instead of > >>looking into two different interfaces (ethtool, ether). > >> > > >> >Sorry it doesn't help to understand. > >> >Today, there is an ethdev API. Why adding an ethtool-like API would > >>help? > >> > >> Need to understand your specific concern. Do you oppose introducing > new > >>API to support ethtool ops and net_device_ops? > > > >They are not ethtool/netdev ops but fake ones. > >In linux: > > int dev_set_mtu(struct net_device *dev, int new_mtu) > >In dpdk: > > int rte_ethtool_net_change_mtu(uint8_t port_id, int mtu); > >So yes, I'm opposed to add an API which is neither ethdev, neither > >ethtool. > >But I may be missing an obvious justification. > > > >> Or your concern is on the implementation. If that's latter. > >> Do you oppose adding a new library to implement ethtool ops and > >>net_device_ops? > > > >Already answered above > > > >> If so, are you satisfied with my previous answer on avoiding > >>polluting ethdev APIs? > >> If not, do you suggest integrating ethtool APIs into ethdev > API? > > > >No, it's better as a separate library. > > > >> If not, is your concern on the implementation of common > >>functionality between ethtool and ethdev APIs? > >> If so, as explained, it is designed to provide a unified > >>interface to assist users to migrate from kernel ethtool/net-device-op > >>API to DPDK > > > >Do you mean it would help migrating some code from kernel space to > dpdk? > >How it would help since the functions and data are different from the > >kernel ones? > > > >> BTW, as my reply to Steve's comment, more ops are on their way. This > >>patch is to open up the interface. > > > >Currently they are only some one-liners plus ethtool_drvinfo formatting > >so there is no real benefit. > >Why not wait to have more ops implemented? > >