From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 1B770199A9 for ; Tue, 19 Sep 2017 14:30:56 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP; 19 Sep 2017 05:30:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,418,1500966000"; d="scan'208";a="1173732339" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga001.jf.intel.com with ESMTP; 19 Sep 2017 05:30:45 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 19 Sep 2017 05:30:45 -0700 Received: from fmsmsx102.amr.corp.intel.com ([169.254.10.194]) by FMSMSX154.amr.corp.intel.com ([169.254.6.54]) with mapi id 14.03.0319.002; Tue, 19 Sep 2017 05:30:44 -0700 From: "Wiles, Keith" To: "Yang, Zhiyong" CC: "Yigit, Ferruh" , Thomas Monjalon , "dev@dpdk.org" , "Doherty, Declan" , "Lu, Wenzhuo" , "hemant.agrawal@nxp.com" , "Hunt, David" , "Richardson, Bruce" , "Ananyev, Konstantin" Thread-Topic: [dpdk-dev] [PATCH v3 1/4] ethdev: increase port_id range Thread-Index: AQHTMQ1mMkM9DsIE0ECd35VK/V9Q1KK8mXaA Date: Tue, 19 Sep 2017 12:30:44 +0000 Message-ID: References: <20170904055734.21354-1-zhiyong.yang@intel.com> <6c65bf3c-b434-93a0-6c9e-776461181150@intel.com> <2082709.2bg3ojJAuc@xps> <2de8d12e-3bf0-645e-2410-967efe42a4d0@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.200.58] Content-Type: text/plain; charset="us-ascii" Content-ID: <0610278E146785458DC65BED698E053F@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 1/4] ethdev: increase port_id range X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 12:30:57 -0000 > On Sep 19, 2017, at 1:05 AM, Yang, Zhiyong wrote= : >=20 >=20 >=20 >> -----Original Message----- >> From: Yigit, Ferruh >> Sent: Wednesday, September 13, 2017 9:33 PM >> To: Thomas Monjalon >> Cc: Yang, Zhiyong ; dev@dpdk.org; Doherty, Decla= n >> ; Lu, Wenzhuo ; >> hemant.agrawal@nxp.com; Hunt, David ; Richardson, >> Bruce ; Ananyev, Konstantin >> >> Subject: Re: [PATCH v3 1/4] ethdev: increase port_id range >>=20 >> On 9/13/2017 1:18 PM, Thomas Monjalon wrote: >>> 13/09/2017 13:56, Ferruh Yigit: >>>> On 9/13/2017 3:26 AM, Yang, Zhiyong wrote: >>>>> From: Yigit, Ferruh >>>>>> On 9/9/2017 3:47 PM, Zhiyong Yang wrote: >>>>>>> Extend port_id definition from uint8_t to uint16_t in lib and >>>>>>> drivers data structures, specifically rte_eth_dev_data. >>>>>>> Modify the APIs, drivers and app using port_id at the same time. >>>>>>>=20 >>>>>>> Fix some checkpatch issues from the original code and remove some >>>>>>> unnecessary cast operations. >>>>>>>=20 >>>>>>> Signed-off-by: Zhiyong Yang >>>>>>=20 >>>>>> <...> >>>>>>=20 >>>>>>> @@ -283,7 +283,7 @@ enum dcb_mode_enable #define >>>>>>> MAX_RX_QUEUE_STATS_MAPPINGS 4096 /* MAX_PORT of 32 @ 128 >>>>>>> rx_queues/port */ >>>>>>>=20 >>>>>>> struct queue_stats_mappings { >>>>>>> - uint8_t port_id; >>>>>>> + uint16_t port_id; >>>>>>=20 >>>>>> Can this be "portid_t port_id;" ? For testpmd, portid_t can be used >>>>>> for all port_id declarations. >>>>>>=20 >>>>>=20 >>>>> Ferruh, the suggestion has been discussed in the following thread. >>>>> Most of people agree on The basic type uint16_t. :). Your suggestion= was >> my preference previously. >>>>> At last, I make this decision to use uint16_t. You know, whatever I >>>>> use, some ones will stand out and Say the other is better. :) >>>>> http://www.dpdk.org/dev/patchwork/patch/23208/ >>>>=20 >>>> This discussion was whole dpdk, my comment is for testpmd only. >>>>=20 >>>> Testpmd already defines "portid_t" and uses it in many places [1]. I >>>> am saying why keep using "uint16_t" in some places in testpmd? Lets >>>> switch all to "portid_t" while we are touching them all. >>>>=20 >>>> [1] >>>> -typedef uint8_t portid_t; >>>> +typedef uint16_t portid_t; >>>=20 >>> Or the reverse, we can drop portid_t from testpmd, especially if it is >>> not used everywhere in testpmd. >>> Note: this typedef hides the size of the port, which may be important >>> when optimizing code. >>=20 >> No strong opinion about keeping "uint16_t" or "portid_t", "portid_t" is = already in >> use, not sure if worth the effort to remove it. >>=20 >> But I am for unifying the storage type used, one or other. >=20 > Think again. If basic type can bring the benefit as Thomas said, we may c= onsider to use uint16_t instead of portid_t in testpmd.=20 We have already decided to use uint16_t for the port ID type and we should = convert testpmd to use that typedef instead of the one it is using. I know = this changes testpmd a bit, but it is also very low risk to testpmd. >=20 > Zhiyong Regards, Keith