From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by dpdk.org (Postfix) with ESMTP id 2CBF4B481 for ; Wed, 18 Feb 2015 13:41:37 +0100 (CET) Received: by pdbfl12 with SMTP id fl12so926460pdb.4 for ; Wed, 18 Feb 2015 04:41:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gdkCp3zpN9LYODSXeH7sxKeblWiy+yn25aBD5EKh5PY=; b=hC2kDyh/3cFvsxY7Cgd63e4qX3v22P4W+YFR10aa6qb7cg97baJVBAbkUbs6c3fRh4 mZYNBc025MbvPEhU6nTB33qhToAoZEGbcSCZVpt5eevspvckG5l1UWs1+ZSCZMfForIk 0NytmXgxSFLeyK/hS7rLA5COxKMOoOfRU9LOIw/SYb2pO1REEwJypOjg9yHqX+8Z+0c2 mcgT2CCbU/uZhmeJGv3Hb5BiuTFZk8o4JiT3pv0/u9VailFu/3UIT2lu1eo2Df4+GY5U gvphkzXkTUFYN8BSi+YZIN88OObqLJFWorlllziGrRsCudoFuKBNmqUSwbkuTFH32EYN +EEw== X-Gm-Message-State: ALoCoQluWp091RviBDkk3WgwOMtXszS8FUUKMWpJF+xLDQGB3ABeHlfsW9KyFAFY9LrBZ4BI8PsB X-Received: by 10.70.137.33 with SMTP id qf1mr58822982pdb.158.1424263296535; Wed, 18 Feb 2015 04:41:36 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by mx.google.com with ESMTPSA id qp4sm20527685pbc.63.2015.02.18.04.41.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Feb 2015 04:41:35 -0800 (PST) Message-ID: <54E4887C.8000404@igel.co.jp> Date: Wed, 18 Feb 2015 21:41:32 +0900 From: Tetsuya Mukawa User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Iremonger, Bernard" , "Richardson, Bruce" , Thomas Monjalon References: <1423470639-15744-2-git-send-email-mukawa@igel.co.jp> <54E3F0F0.1030102@igel.co.jp> <54E42CCD.6020900@igel.co.jp> <3870939.2syNine7YF@xps13> <20150218100328.GB14728@bricha3-MOBL3> <54E4703E.1010904@igel.co.jp> <8CEF83825BEC744B83065625E567D7C2049EACCC@IRSMSX108.ger.corp.intel.com> In-Reply-To: <8CEF83825BEC744B83065625E567D7C2049EACCC@IRSMSX108.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" 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 12:41:37 -0000 On 2015/02/18 21:33, Iremonger, Bernard wrote: > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tetsuya Mukawa >> Sent: Wednesday, February 18, 2015 10:58 AM >> To: Richardson, Bruce; Thomas Monjalon >> 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 >> >> On 2015/02/18 19:03, Bruce Richardson wrote: >>> On Wed, Feb 18, 2015 at 10:57:25AM +0100, Thomas Monjalon wrote: >>>> 2015-02-18 15:10, Tetsuya Mukawa: >>>>> 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 >>>>>> >>>>> Hi Thomas, >>>>> >>>>> 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. >>>>> >>>>> 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 >>>>> check how port_id is used, and fix more related lines. So probably >>>>> thousands lines may need to be fixed. >>>>> >>>>> When is deadline for fixing this changing? >>>>> Also, if you have a good idea to fix it easier, could you please let >>>>> me know? >>>> It was an open question. >>>> If everybody is fine with 255 ports maximum, let's keep it as is. >>>> >>> I think we are probably ok for now (and forseeable future) with 255 max. >>> >>> However, if we did change it, I agree that in 2.0 is a very good time to do so. >>> Since we are expanding the field, rather than shrinking it, I don't >>> see why we can't just make the change at the ethdev level (and in libs >>> API) in 2.0 and then in later releases (e.g. 2.1) update the apps and >>> examples to match. That way the ABI stays the same from 2.0 onwards, >>> and we don't have a huge amount of churn changing it everywhere late in the 2.0 release cycle. >> Hi Bruce, >> >> Could you please check my RFC patch I will send soon? >> I wrote the patch like below. >> >> 1. Copy header file like below. >> $ cp lib/librte_ether/rte_ethdev.h lib/librte_ether/rte_ethdev_internal.h >> 2. Change "rte_ethdev.c" to include "rte_ethdev_internal.h" >> 3. Change type of port id in "rte_ethdev.c" and "rte_ethdev_internal.h". >> >> If the patch is OK, I wll send it with hotplug patches. >> >> Thanks, >> Tetsuya >> >> >>> /Bruce > Hi Tetsuya, > > After this change there will be two header files with a lot of the same information. > lib/librte_ether/rte_ethdev.h > lib/librte_ether/rte_ethdev_internal.h > I don't think this is a good idea for maintenance in the future. > If 255 is ok for the foreseeable future, why change it now. Hi Bernard, I appreciate for your checking. Agree, it will not be good to have almost same headers. Thanks, Tetsuya > Regards, > > Bernard. > >