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 2AE78A00E6 for ; Thu, 11 Jul 2019 10:20:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 080337CBC; Thu, 11 Jul 2019 10:20:59 +0200 (CEST) Received: from proxy.6wind.com (host.76.145.23.62.rev.coltfrance.com [62.23.145.76]) by dpdk.org (Postfix) with ESMTP id 8D705532C for ; Thu, 11 Jul 2019 10:20:57 +0200 (CEST) Received: from core.dev.6wind.com (unknown [10.0.0.1]) by proxy.6wind.com (Postfix) with ESMTPS id 71E8D2E5230; Thu, 11 Jul 2019 10:20:57 +0200 (CEST) Received: from [10.16.0.195] (helo=6wind.com) by core.dev.6wind.com with smtp (Exim 4.84_2) (envelope-from ) id 1hlUK0-0007UN-DL; Thu, 11 Jul 2019 10:20:57 +0200 Received: by 6wind.com (sSMTP sendmail emulation); Thu, 11 Jul 2019 10:20:56 +0200 Date: Thu, 11 Jul 2019 10:20:56 +0200 From: Olivier Matz To: "Wang, Haiyue" Cc: "dev@dpdk.org" Message-ID: <20190711082056.zx5cl2vrqxof7add@glumotte.dev.6wind.com> References: <20190710092907.5565-1-olivier.matz@6wind.com> <20190711072619.fldr3dz7qblyvej5@glumotte.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) 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 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 the API > > > > or ABI. > > > > > > > > This commit addresses these issues, 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 (>= 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. As > > > > the space in mbuf is limited, the space should only be reserved 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 possible > > > > 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 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 > > > > + * 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 (>= 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. As > > > > + * the space in mbuf is limited, the space should only be reserved 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 possible > > > > + * 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 ? 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. To avoid name conflicts, I think we should define a convention for identifiers, so they are in different namespaces: - "rte_*" for identifiers declared inside dpdk subtree - any other name for identifiers declared in an external application or library