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 5567DC332 for ; Tue, 2 Jun 2015 19:07:23 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 02 Jun 2015 10:06:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,541,1427785200"; d="scan'208";a="719451553" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by fmsmga001.fm.intel.com with ESMTP; 02 Jun 2015 10:06:44 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 2 Jun 2015 10:06:44 -0700 Received: from FMSMSX110.amr.corp.intel.com ([169.254.14.46]) by FMSMSX157.amr.corp.intel.com ([169.254.14.191]) with mapi id 14.03.0224.002; Tue, 2 Jun 2015 10:06:39 -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//5lG4A== Date: Tue, 2 Jun 2015 17:06:38 +0000 Message-ID: References: <1432927612-12244-1-git-send-email-liang-min.wang@intel.com> <3076202.B6CvAKP4DR@xps13> <38737329.jBeOYmBEyN@xps13> In-Reply-To: <38737329.jBeOYmBEyN@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.107] 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: Tue, 02 Jun 2015 17:07:23 -0000 >2015-06-02 15:47, Wang, Liang-min: >> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]=20 >> > >>I'm curious to understand how renaming rte_eth_dev_set_mtu() to >> > >>rte_ethtool_net_change_mtu() will help anyone. >> >>=20 >> >> As described, this interface is designed to provide API closely to ke= rnel space ethtool ops and net_device_op. >>=20 >> >But the application still needs to adapt the code to call rte_* functio= ns. >> >So changing to rte_ethtool_net_change_mtu is equivalent to change to th= e existing rte_eth_dev_set_mtu. I don't see the benefit. >>=20 >> The benefit is single interface for users to access. Instead of looking = into two different interfaces (ethtool, ether).=20 > >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?=20 Or your concern is on the implementation. If that's latter.=20 Do you oppose adding a new library to implement ethtool ops and net_device_= ops? If so, are you satisfied with my previous answer on avoiding polluting = ethdev APIs?=20 If not, do you suggest integrating ethtool APIs into ethdev API? If not, is your concern on the implementation of common functionality b= etween 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 BTW, as my reply to Steve's comment, more ops are on their way. This patch = is to open up the interface.