From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by dpdk.org (Postfix) with ESMTP id A80A4AF87 for ; Wed, 28 May 2014 11:46:05 +0200 (CEST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 28 May 2014 02:46:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,927,1392192000"; d="scan'208";a="437967282" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by azsmga001.ch.intel.com with ESMTP; 28 May 2014 02:46:09 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.239]) by IRSMSX102.ger.corp.intel.com ([169.254.2.105]) with mapi id 14.03.0123.003; Wed, 28 May 2014 10:45:16 +0100 From: "Ananyev, Konstantin" To: Stephen Hemminger , Olivier Matz Thread-Topic: [dpdk-dev] [PATCH RFC 03/11] mbuf: remove rte_ctrlmbuf Thread-Index: AQHPeUD6hrZ9sefUWEukOQQx7WskgJtVvKFQ Date: Wed, 28 May 2014 09:45:15 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580EFB3572@IRSMSX105.ger.corp.intel.com> References: <1399647038-15095-1-git-send-email-olivier.matz@6wind.com> <1399647038-15095-4-git-send-email-olivier.matz@6wind.com> <20140526171701.7bd0fadd@nehalam.linuxnetplumber.net> In-Reply-To: <20140526171701.7bd0fadd@nehalam.linuxnetplumber.net> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] 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 RFC 03/11] mbuf: remove rte_ctrlmbuf 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, 28 May 2014 09:46:06 -0000 Hi, >The only win from this is to save the byte for the type field. >Yes bits here are precious. >Does external application mix control and data mbuf's in the same ring? >The stuff in the tree only uses type field for debug validation/sanity >checks. >Since it is only one bit, maybe you can find one bit to store that.=20 >Since buffer and pool addresses are going to be at least 32 bit aligned >maybe you can use the old GC trick of using the LSB as flag. Or, as an alternative we can move mbuf type up into the mempool. In most cases user has to deal only with one particular type of mbufs and h= e already knows what mbuf type it would be. For the rare cases when code need to deal with mix of mbuf types, it is probably ok to read mbuf type from the corresponding mempool.=20 Of course, it would mean that all elements in the mempool should have the = same type, but I don't think right now people using mempools with mix of pktmbuf/ctrlm= buf anyway. =20 Konstantin=20