From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 6885E2EDA for ; Tue, 2 Jun 2015 22:56:22 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 02 Jun 2015 13:56:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,541,1427785200"; d="scan'208";a="739679914" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by orsmga002.jf.intel.com with ESMTP; 02 Jun 2015 13:56:21 -0700 Received: from orsmsx114.amr.corp.intel.com (10.22.240.10) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 2 Jun 2015 13:56:21 -0700 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by ORSMSX114.amr.corp.intel.com (10.22.240.10) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 2 Jun 2015 13:56:20 -0700 Received: from FMSMSX110.amr.corp.intel.com ([169.254.14.46]) by FMSMSX112.amr.corp.intel.com ([169.254.5.158]) with mapi id 14.03.0224.002; Tue, 2 Jun 2015 13:56:20 -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//5lG4AAWcj8AAA5xwUA= Date: Tue, 2 Jun 2015 20:56:20 +0000 Message-ID: References: <1432927612-12244-1-git-send-email-liang-min.wang@intel.com> <38737329.jBeOYmBEyN@xps13> <24712227.WkznNjn3ZB@xps13> In-Reply-To: <24712227.WkznNjn3ZB@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 20:56:23 -0000 >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. >> >> >>=20 >> >> >> As described, this interface is designed to provide API closely to= kernel space ethtool ops and net_device_op. >> >>=20 >> >> >But the application still needs to adapt the code to call rte_* func= tions. >> >> >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. >> >>=20 >> >> The benefit is single interface for users to access. Instead of looki= ng 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 hel= p? >>=20 >> Need to understand your specific concern. Do you oppose introducing new = API to support ethtool ops and net_device_ops?=20 > >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 opp= osed to add an API which is neither ethdev, neither ethtool. >But I may be missing an obvious justification. So, the design purposely stays away from struct net_device to avoid carryin= g kernel states. We consciously choose port in place of net_device. The kni already provides ethtool for kernel space code, this interface is d= esigned for user-space application (fast-path comparing to kni). >> 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_devi= ce_ops? > >Already answered above >> >> If so, are you satisfied with my previous answer on avoiding polluti= ng ethdev APIs?=20 >> 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 functionalit= y between ethtool and ethdev APIs? >> If so, as explained, it is designed to provide a unified=20 >> interface to assist users to migrate from kernel ethtool/net-device-op=20 >> 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 kern= el ones? For application that was designed based upon kernel-space ethtool-op and ne= t-device-op, the user-space APIs provide a path for quick integration. >> BTW, as my reply to Steve's comment, more ops are on their way. This pat= ch 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? Due to amount of code change, I was advised to put into separate release an= d started with APIs that only requires minor changes on ethdev. The rest of API requires changes on NIC pmd driver to support ops that are = not currently supported.