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 0A1C330D for ; Thu, 5 Jun 2014 05:29:56 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 04 Jun 2014 20:24:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,977,1392192000"; d="scan'208";a="551827717" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by orsmga002.jf.intel.com with ESMTP; 04 Jun 2014 20:30:08 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Jun 2014 20:30:08 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Jun 2014 20:30:08 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.190]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.192]) with mapi id 14.03.0123.003; Thu, 5 Jun 2014 11:30:06 +0800 From: "Ouyang, Changchun" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v2 1/3] ether: Add API to support setting TX rate for queue and VF Thread-Index: AQHPeLaAy6tGJYlcSkmvqmS5LDr7MptUg9gAgA1im6A= Date: Thu, 5 Jun 2014 03:30:06 +0000 Message-ID: References: <1401090331-18455-1-git-send-email-changchun.ouyang@intel.com> <1401090331-18455-2-git-send-email-changchun.ouyang@intel.com> <2115230.WNnKFPWGt0@xps13> In-Reply-To: <2115230.WNnKFPWGt0@xps13> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] 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 v2 1/3] ether: Add API to support setting TX rate for queue and VF 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, 05 Jun 2014 03:29:57 -0000 Hi Thomas, As we can see below, There are already 4 existing functions for vf in the h= eader file: rte_ethdev.h:int rte_eth_dev_set_vf_rxmode(uint8_t port, uint16_t vf, uint1= 6_t rx_mode, rte_ethdev.h:rte_eth_dev_set_vf_tx(uint8_t port,uint16_t vf, uint8_t on); rte_ethdev.h:rte_eth_dev_set_vf_rx(uint8_t port,uint16_t vf, uint8_t on); rte_ethdev.h:rte_eth_dev_set_vf_vlan_filter(uint8_t port, uint16_t vlan_id, So do we have plan to move them or remove them as they are all for VF speci= fically? =20 If no, why we can accept those functions, but not accept the rte_eth_set_vf= _rate_limit? :-) I have 2 new api in this patch, the rte_eth_set_queue_rate_limit is more ge= neric, whose Argument only have port and queue.=20 but PRC customer has the requirement of API function to limit the vf tx rat= e, so personally I think rte_eth_set_vf_rate_limit is necessary for them. Thanks and regards, Changchun -----Original Message----- From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]=20 Sent: Wednesday, May 28, 2014 6:48 AM To: Ouyang, Changchun Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 1/3] ether: Add API to support setting TX= rate for queue and VF Hi Changchun, 2014-05-26 15:45, Ouyang Changchun: > /** > + * Set the rate limitation for a queue on an Ethernet device. > + * > + * @param port_id > + * The port identifier of the Ethernet device. > + * @param queue_idx > + * The queue id. > + * @param tx_rate > + * The tx rate allocated from the total link speed for this queue. > + * @return > + * - (0) if successful. > + * - (-ENOTSUP) if hardware doesn't support this feature. > + * - (-ENODEV) if *port_id* invalid. > + * - (-EINVAL) if bad parameter. > + */ > +int rte_eth_set_queue_rate_limit(uint8_t port_id, uint16_t queue_idx, > + uint16_t tx_rate); > + > +/** > + * Set the rate limitation for a vf on an Ethernet device. > + * > + * @param port_id > + * The port identifier of the Ethernet device. > + * @param vf > + * VF id. > + * @param tx_rate > + * The tx rate allocated from the total link speed for this VF id. > + * @param q_msk > + * The queue mask which need to set the rate. > + * @return > + * - (0) if successful. > + * - (-ENOTSUP) if hardware doesn't support this feature. > + * - (-ENODEV) if *port_id* invalid. > + * - (-EINVAL) if bad parameter. > + */ > +int rte_eth_set_vf_rate_limit(uint8_t port_id, uint16_t vf, > + uint16_t tx_rate, uint64_t q_msk); You are defining an API function specifically for VF. It's not generic and = shouldn't appear in the API. We now have to be careful about the API and tr= y to build a robust generic API which could become stable. Is it possible to imagine another API where only port and queue parameters = are required?=20 Thanks -- Thomas