From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH v2 6/8] mbuf: use 2 bytes for port and nb segments Date: Tue, 11 Jul 2017 15:46:03 +0200 Message-ID: <20170711154603.29777c1a@glumotte.dev.6wind.com> References: <1488966121-22853-1-git-send-email-olivier.matz@6wind.com> <20170404162807.20157-1-olivier.matz@6wind.com> <20170404162807.20157-7-olivier.matz@6wind.com> <20170406054523.GP18844@yliu-dev.sh.intel.com> <20170418150304.58d2c4a1@glumotte.dev.6wind.com> <8F6C2BD409508844A0EFC19955BE0941512B02B2@SHSMSX103.ccr.corp.intel.com> <20170710100018.403b82ec@platinum> <98CBD80474FA8B44BF855DF32C47DC359EB26E@smartserver.smartshare.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , "Wang, Zhihong" , Yuanhan Liu , DPDK , "Ananyev, Konstantin" , "Richardson, Bruce" , "Chilikin, Andrey" , Jan Blunck , =?UTF-8?B?TsOpbGlv?= Laranjeiro , "Andrew Rybchenko" , "thomas.monjalon@6wind.com" , "jerin.jacob@caviumnetworks.com" To: "Wiles, Keith" Return-path: Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by dpdk.org (Postfix) with ESMTP id 21D583257 for ; Tue, 11 Jul 2017 15:46:14 +0200 (CEST) Received: by mail-lf0-f49.google.com with SMTP id b207so49796lfg.2 for ; Tue, 11 Jul 2017 06:46:14 -0700 (PDT) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 11 Jul 2017 13:34:47 +0000, "Wiles, Keith" = wrote: > Resend because of format problems sorry. >=20 > > On Jul 10, 2017, at 3:15 AM, Morten Br=C3=B8rup wrote: > > =20 > >> -----Original Message----- > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz > >> Sent: Monday, July 10, 2017 10:00 AM > >> Subject: Re: [dpdk-dev] [PATCH v2 6/8] mbuf: use 2 bytes for port and > >> nb segments > >>=20 > >> Hi, > >>=20 > >> On Tue, 4 Jul 2017 07:54:23 +0000, "Wang, Zhihong" > >> wrote: =20 > >>>> -----Original Message----- > >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier MATZ > >>>> Sent: Tuesday, April 18, 2017 9:03 PM > >>>> To: Yuanhan Liu > >>>>=20 > >>>> Hi Yuanhan, > >>>>=20 > >>>> On Thu, 6 Apr 2017 13:45:23 +0800, Yuanhan Liu > >>>> wrote: =20 > >>>>> Hi Olivier, > >>>>>=20 > >>>>> On Tue, Apr 04, 2017 at 06:28:05PM +0200, Olivier Matz wrote: =20 > >>>>>> Change the size of m->port and m->nb_segs to 16 bits. =20 > >>>>>=20 > >>>>> But all the ethdev APIs are still using 8 bits. 16 bits won't > >>>>> really take effect without updating those APIs. Any plans? > >>>>>=20 > >>>>> --yliu =20 > >>>>=20 > >>>> Yes, there is some work in ethdev, drivers and in example apps to > >>>> make the change effective. I think we could define a specific type > >>>> for a port number, maybe rte_eth_port_num_t. Using this type could > >>>> be a first step (for 17.08) before switching to 16 bits (17.11?). > >>>>=20 > >>>> I'll do the change and send a rfc. =20 > >>>=20 > >>> Ping ;) Is this still in your plan? > >>> =20 > >>=20 > >> Sorry, I don't think I will have time to work on this issue in the > >> coming weeks. If you plan to do it, I will be happy to help with > >> reviews and comments. > >>=20 > >> As I said in a previous message, I think a good first step would be to > >> introduce a typedef for the port number: rte_eth_port_num_t. > >> It can still be uint8_t for now, and can be switched to 16 bits in one > >> step when everyone uses this new type. > >>=20 > >> Olivier =20 > >=20 > > I think that DPDK follows the Linux tradition of exposing the variable = types, as opposed to hiding them behind typedefs. This has the unfortunate = consequence that when a variable type changes, it has to be changed everywh= ere. > >=20 > > Introducing a rte_eth_port_num_t will require changing the same files a= t the same locations everywhere, so not even as a temporary solution will i= t be beneficial. =20 >=20 > I would like to see a much smaller typedef name here, we use it everywher= e. > rte_port_id_t > port_id_t > port_num_t > portid_t > pid_t > rte_pid_t >=20 > I do not see why it needs to be rte_eth or even rte_, if we do not put et= h in the name then is could be used in crypto or someplace else. rte_ is required because we want to avoid namespace collision. For instance, portid_t is too generic, and we would take the risk that it is also defined for something else in another .h file. Knowing it is is an ethernet port identifier, I also think eth_ is more consistent regarding what we already have in rte_ethdev.h. About num vs id, I have no strong opinion. *pid_t looks really unclear to me :) Olivier