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 88022A00E6 for ; Thu, 11 Jul 2019 10:34:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2EEDC1B4B6; Thu, 11 Jul 2019 10:34:12 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 583B02C6A for ; Thu, 11 Jul 2019 10:34:10 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2019 01:34:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,476,1557212400"; d="scan'208";a="317615534" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga004.jf.intel.com with ESMTP; 11 Jul 2019 01:34:08 -0700 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 11 Jul 2019 01:34:08 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 11 Jul 2019 01:34:07 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.134]) by shsmsx102.ccr.corp.intel.com ([169.254.2.3]) with mapi id 14.03.0439.000; Thu, 11 Jul 2019 16:34:05 +0800 From: "Wang, Haiyue" To: Olivier Matz CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags Thread-Index: AQHVNwH9rBZt164hek6OOjYJj0DjD6bEEJBwgABvLYCAAIwSIP//gzAAgACI3FA= Date: Thu, 11 Jul 2019 08:34:05 +0000 Message-ID: References: <20190710092907.5565-1-olivier.matz@6wind.com> <20190711072619.fldr3dz7qblyvej5@glumotte.dev.6wind.com> <20190711082056.zx5cl2vrqxof7add@glumotte.dev.6wind.com> In-Reply-To: <20190711082056.zx5cl2vrqxof7add@glumotte.dev.6wind.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTE2YzQ5ZDEtOWNlMS00YzczLTk5MTItNjliMGZiZmI5NjgwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidHNqWFh3NlZCdVZcLzFzY1VncDl4MUhEQm1MbDZQZUVzOHhOazUrZ3I3dWlDVnl1Zk1pNjlIVEtsbndITnVqd0YifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" 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" > -----Original Message----- > From: Olivier Matz [mailto:olivier.matz@6wind.com] > Sent: Thursday, July 11, 2019 16:21 > To: Wang, Haiyue > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags >=20 > On Thu, Jul 11, 2019 at 08:04:00AM +0000, Wang, Haiyue wrote: > > > -----Original Message----- > > > From: Olivier Matz [mailto:olivier.matz@6wind.com] > > > Sent: Thursday, July 11, 2019 15:26 > > > To: Wang, Haiyue > > > Cc: dev@dpdk.org > > > Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags > > > > > > Hi, > > > > > > On Wed, Jul 10, 2019 at 05:14:33PM +0000, Wang, Haiyue wrote: > > > > Hi, > > > > > > > > Sounds cool, just have some questions inline. > > > > > > > > > -----Original Message----- > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz > > > > > Sent: Wednesday, July 10, 2019 17:29 > > > > > To: dev@dpdk.org > > > > > Subject: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags > > > > > > > > > > Many features require to store data inside the mbuf. As the room = in mbuf > > > > > structure is limited, it is not possible to have a field for each > > > > > feature. Also, changing fields in the mbuf structure can break th= e API > > > > > or ABI. > > > > > > > > > > This commit addresses these issues, by enabling the dynamic regis= tration > > > > > of fields or flags: > > > > > > > > > > - a dynamic field is a named area in the rte_mbuf structure, with= a > > > > > given size (>=3D 1 byte) and alignment constraint. > > > > > - a dynamic flag is a named bit in the rte_mbuf structure. > > > > > > > > > > The typical use case is a PMD that registers space for an offload > > > > > feature, when the application requests to enable this feature. A= s > > > > > the space in mbuf is limited, the space should only be reserved i= f it > > > > > is going to be used (i.e when the application explicitly asks for= it). > > > > > > > > > > The registration can be done at any moment, but it is not possibl= e > > > > > to unregister fields or flags for now. > > > > > > > > > > Signed-off-by: Olivier Matz > > > > > > (...) > > > > > > > > +/** > > > > > + * @file > > > > > + * RTE Mbuf dynamic fields and flags > > > > > + * > > > > > + * Many features require to store data inside the mbuf. As the r= oom in > > > > > + * mbuf structure is limited, it is not possible to have a field= for > > > > > + * each feature. Also, changing fields in the mbuf structure can= break > > > > > + * the API or ABI. > > > > > + * > > > > > + * This module addresses this issue, by enabling the dynamic > > > > > + * registration of fields or flags: > > > > > + * > > > > > + * - a dynamic field is a named area in the rte_mbuf structure, = with a > > > > > + * given size (>=3D 1 byte) and alignment constraint. > > > > > + * - a dynamic flag is a named bit in the rte_mbuf structure. > > > > > + * > > > > > + * The typical use case is a PMD that registers space for an off= load > > > > > + * feature, when the application requests to enable this feature= . As > > > > > + * the space in mbuf is limited, the space should only be reserv= ed if it > > > > > + * is going to be used (i.e when the application explicitly asks= for it). > > > > > + * > > > > > + * The registration can be done at any moment, but it is not pos= sible > > > > > + * to unregister fields or flags for now. > > > > > + * > > > > > + * Example of use: > > > > > + * > > > > > + * - RTE_MBUF_DYN__(ID|SIZE|ALIGN) are defined in this = file > > > > > > > > Does it means that all PMDs define their own 'RTE_MBUF_DYN__(ID|SIZE|ALIGN)' > > > > here ? In other words, each PMD can expose its private DYN_ here for public > > > > using ? > > > > > > For generic fields, I think they should be declared in this file. For > > > instance, if we decide to replace the current m->timestamp field by a > > > dynamic field, we should add like this: > > > > > > #define RTE_MBUF_DYN_TIMESTAMP_ID "rte_timestamp" > > > #define RTE_MBUF_DYN_TIMESTAMP_SIZE sizeof(uint64_t) > > > #define RTE_MBUF_DYN_TIMESTAMP_ALIGN __alignof__(uint64_t) > > > > > > If the feature is PMD-specific, the defines could be exposed in a > > > PMD header. > > > > > > > Now, understand the comments a little : ... must not define identifers = prefixed with "rte_", > > which are reserved for standard features. Seems have big plan ? >=20 > The dynamic field can also be used by an external application or by an > external library. For instance, a field to tag a packet, like skb->mark > in linux. In this case, id, size and alignment would be defined outside > dpdk subtree. >=20 > To avoid name conflicts, I think we should define a convention for > identifiers, so they are in different namespaces: >=20 > - "rte_*" for identifiers declared inside dpdk subtree > - any other name for identifiers declared in an external application or > library Very clearer now, thanks, this convention can be in programming guide docum= ent. :)