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 53E02B494 for ; Wed, 18 Feb 2015 10:27:07 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 18 Feb 2015 01:27:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,595,1418112000"; d="scan'208";a="653706544" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga001.jf.intel.com with ESMTP; 18 Feb 2015 01:27:05 -0800 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX107.ger.corp.intel.com (163.33.3.99) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 18 Feb 2015 09:27:03 +0000 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.218]) by irsmsx155.ger.corp.intel.com ([169.254.14.159]) with mapi id 14.03.0195.001; Wed, 18 Feb 2015 09:27:03 +0000 From: "Iremonger, Bernard" To: Tetsuya Mukawa , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v8 03/14] eal/pci, ethdev: Remove assumption that port will not be detached Thread-Index: AQHQSx3+hGsLkHpns0GuaxZs+jytHZz17OqAgAA18FA= Date: Wed, 18 Feb 2015 09:27:02 +0000 Message-ID: <8CEF83825BEC744B83065625E567D7C2049EAA2A@IRSMSX108.ger.corp.intel.com> References: <1423470639-15744-2-git-send-email-mukawa@igel.co.jp> <2372286.XQlcQsOEBg@xps13> <54E2DC38.7000907@igel.co.jp> <1518995.cYPUuEs3Fv@xps13> <54E3F0F0.1030102@igel.co.jp> <54E42CCD.6020900@igel.co.jp> In-Reply-To: <54E42CCD.6020900@igel.co.jp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" , Neil Horman Subject: Re: [dpdk-dev] [PATCH v8 03/14] eal/pci, ethdev: Remove assumption that port will not be detached 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, 18 Feb 2015 09:27:07 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tetsuya Mukawa > Sent: Wednesday, February 18, 2015 6:10 AM > To: Thomas Monjalon > Cc: dev@dpdk.org; Neil Horman > Subject: Re: [dpdk-dev] [PATCH v8 03/14] eal/pci, ethdev: Remove assumpti= on that port will not be > detached >=20 > On 2015/02/18 10:54, Tetsuya Mukawa wrote: > > On 2015/02/18 9:31, Thomas Monjalon wrote: > >> 2015-02-17 15:14, Tetsuya Mukawa: > >>> On 2015/02/17 9:36, Thomas Monjalon wrote: > >>>> 2015-02-16 13:14, Tetsuya Mukawa: > >>>> Is uint8_t sill a good size for hotpluggable virtual device ids? > >>> I am not sure it's enough, but uint8_t is widely used in "rte_ethdev.= c" > >>> as port id. > >>> If someone reports it doesn't enough, I guess it will be the time to > >>> write a patch to change all uint_8 in one patch. > >> It's a big ABI breakage. So if we feel it's going to be required, > >> it's better to do it now in 2.0 release I think. > >> > >> Any opinion? > >> > > Hi Thomas, > > > > I agree with it. > > I will add an one more patch to change uint8_t to uint16_t. > > > > Thanks, > > Tetsuya > > >=20 > Hi Thomas, >=20 > Could I make sure. > After changing uint8_t to uint16_t in "rte_ethdev.[ch]", must I also need= to change other applications > and libraries that call ethdev APIs? > If so, I would not finish it by 23rd. >=20 > I've counted how many lines call ethdev APIs that are related to port_id. > Could you please check an attached file? > It's over 1200 lines. Probably to fix one of caller, I will need to chec= k how port_id is used, and fix more > related lines. So probably thousands lines may need to be fixed. >=20 > When is deadline for fixing this changing? > Also, if you have a good idea to fix it easier, could you please let me k= now? >=20 > Thanks, > Tetsuya Hi Tetsuya, Thomas, As uint8_t is already widely used for port_id, I don't think it should be c= hanged in this patchset. If it is to be changed to uint16_t it should be done as a separate task (in= a new patchset). Regards, Bernard.