From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by dpdk.org (Postfix) with ESMTP id 674FC5693 for ; Wed, 3 Jun 2015 03:00:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4220; q=dns/txt; s=iport; t=1433293210; x=1434502810; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=18cXkf/YzWKPPDU/R+yMMVQ47nMc37eQKFxE0dMK0XI=; b=fjGPVRiLWn3Qhl6LoL9ue9KZiNZU9a2S51E3hzIM1nTBya7roBpcKIr7 ZrciPxxGk5y8bVzxuZKwSbdr1yb1hCJAslNh26Yk/anKEcZiiGEHjdCIi /2YMVQiEtNJbVutjGbm5AZ0L7UectA6pRL3mk9/JqLHPoULdMP8uV2g5J g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYBAC0UG5V/4wNJK1bgxCBMga+cAmHUQKBQjgUAQEBAQEBAYEKhCIBAQEEOj8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCIgl2kIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0OELicxBwaDEYEWAQSTEYsfgS2Dc45Gg1kjYYFagT1vgQRCgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,543,1427760000"; d="scan'208";a="4027221" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 03 Jun 2015 01:00:08 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t53107N3017703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jun 2015 01:00:08 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.78]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 2 Jun 2015 20:00:07 -0500 From: "David Harton (dharton)" To: "Wang, Liang-min" , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide ethtool-alike APIs Thread-Index: AQHQnXQdqrvCjN6w0kaoDRtwtzUfoZ2aBhAA///upeA= Date: Wed, 3 Jun 2015 01:00:07 +0000 Message-ID: References: <1432927612-12244-1-git-send-email-liang-min.wang@intel.com> <38737329.jBeOYmBEyN@xps13> <24712227.WkznNjn3ZB@xps13> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.220.104] 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: Wed, 03 Jun 2015 01:00:09 -0000 Hi Thomas, I think Larry explains things pretty clearly below. A new application facing API is bring provided that avoids reusing kernel s= pecific types and structs or dipping into the kernel itself. It also clear= ly separates the user space API from driver related functions/types. We do want to limit dipping into the kernel for performance reasons. I hope this helps, Dave > -----Original Message----- > From: Wang, Liang-min [mailto:liang-min.wang@intel.com] > Sent: Tuesday, June 02, 2015 4:56 PM > To: Thomas Monjalon > Cc: dev@dpdk.org; David Harton (dharton) > Subject: RE: [dpdk-dev] [PATCH 2/2] ethtool: add new library to provide > ethtool-alike APIs >=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 ne= w > 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. >=20 > So, the design purposely stays away from struct net_device to avoid > carrying kernel states. We consciously choose port in place of net_device= . > The kni already provides ethtool for kernel space code, this interface is > designed for user-space application (fast-path comparing to kni). >=20 > >> 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? >=20 > For application that was designed based upon kernel-space ethtool-op and > net-device-op, the user-space APIs provide a path for quick integration. >=20 > >> 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? > Due to amount of code change, I was advised to put into separate release > and started with APIs that only requires minor changes on ethdev. > The rest of API requires changes on NIC pmd driver to support ops that ar= e > not currently supported.