From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E350EA00E6 for ; Wed, 10 Jul 2019 20:12:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CE6B13195; Wed, 10 Jul 2019 20:12:35 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 7EC822BD5 for ; Wed, 10 Jul 2019 20:12:34 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2019 11:12:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,475,1557212400"; d="scan'208";a="156576005" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga007.jf.intel.com with ESMTP; 10 Jul 2019 11:12:32 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 10 Jul 2019 11:12:17 -0700 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.206]) by FMSMSX102.amr.corp.intel.com ([169.254.10.233]) with mapi id 14.03.0439.000; Wed, 10 Jul 2019 11:12:17 -0700 From: "Wiles, Keith" To: Olivier Matz CC: dpdk dev community , Stephen Hemminger Thread-Topic: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags Thread-Index: AQHVNwH87YnOXs5oQkeR+lrxtZZvp6bEluuAgAAGbAA= Date: Wed, 10 Jul 2019 18:12:16 +0000 Message-ID: <3117C805-492A-4DA9-BE8F-E119E057C80D@intel.com> References: <20190710092907.5565-1-olivier.matz@6wind.com> <20190710104917.73bc9201@hermes.lan> In-Reply-To: <20190710104917.73bc9201@hermes.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.251.155.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Jul 10, 2019, at 12:49 PM, Stephen Hemminger wrote: >=20 > On Wed, 10 Jul 2019 11:29:07 +0200 > Olivier Matz wrote: >=20 >> /** >> * Indicate that the metadata field in the mbuf is in use. >> @@ -738,6 +741,8 @@ struct rte_mbuf { >> */ >> struct rte_mbuf_ext_shared_info *shinfo; >>=20 >> + uint64_t dynfield1; /**< Reserved for dynamic fields. */ >> + uint64_t dynfield2; /**< Reserved for dynamic fields. */ >> } __rte_cache_aligned; >=20 > Growing mbuf is a fundamental ABI break and this needs > higher level approval. Why not one pointer? >=20 > It looks like you are creating something like FreeBSD m_tag. > Why not use that? Changing the mbuf structure causes a big problem for a number reasons as St= ephen states. If we leave the mbuf stucture alone and add this feature to the headroom sp= ace between the mbuf structure and the packet. When setting up the mempool/= mbuf pool we define a headroom to hold the extra data when the mbuf pool is= created or just use the current headroom space. Using this method we can e= liminate the mbuf structure change and add the data to the packet buffer. W= e can do away with dynfield1 and 2 as we know where headroom space begins a= nd ends. Just a thought. Regards, Keith