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 3B443A0471 for ; Tue, 16 Jul 2019 11:49:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E59FA2C18; Tue, 16 Jul 2019 11:49:12 +0200 (CEST) Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 94D1A2BE1 for ; Tue, 16 Jul 2019 11:49:11 +0200 (CEST) Received: from lfbn-lil-1-176-160.w90-45.abo.wanadoo.fr ([90.45.26.160] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hnK8D-00028I-E3; Tue, 16 Jul 2019 11:52:22 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Tue, 16 Jul 2019 11:49:09 +0200 Date: Tue, 16 Jul 2019 11:49:09 +0200 From: Olivier Matz To: Andrew Rybchenko Cc: dev@dpdk.org Message-ID: <20190716094909.plszssstmbj2kjaw@platinum> References: <20190710092907.5565-1-olivier.matz@6wind.com> <06276df5-302f-a3af-218e-ef736bc26fc3@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06276df5-302f-a3af-218e-ef736bc26fc3@solarflare.com> User-Agent: NeoMutt/20180716 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 Fri, Jul 12, 2019 at 05:54:57PM +0300, Andrew Rybchenko wrote: > On 10.07.2019 12:29, Olivier Matz wrote: > > 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 > > I like the idea. > > I think it would be very useful to measure performance impact. Since it is > core structure which is heavily used on datapath, performance impact is > required to make decision to go or not to go. If acceptable, more fields > can be converted to dynamic: timestamp, user data, sequence number, > timesync data etc. Agree. I'll try to do this in the coming days. > Rules on which fields should be static and which > dynamic are required. Timestamp, for example, is located in the first > cache line. Do we need a way prioritize some dynamic fields to be located > (if possible) in the first cache line? Or is it better simply move some > static > to the first cache line instead? There is a "flags" argument, which is designed for this purpose. Today, there is no room in the first cache line, but as soon as we remove something from it, we can add a flag to ask to register a dynamic field in the first cache line. > I think rules should be better defined and imposed, if possible, when > dynamic fields may be registered. Which entities are allowed to register > dynamic fields? I think there is no restriction. Library, PMD, App can register their dynamic fields as soon as there is room for it. > Do we need to keep track which entity has registered > which dynamic fields? Looks quite difficult to me. Most of the time, a dynamic field will be registered at several places. Only the first registration is effective, the other will just get the offset. But at least we could add a log in the registration function. > What to expect if a dynamic field is registered > after port start (the field is registered, but most likely not filled in)? > What to expect on port restart? Registration of dynamic field can be done at any moment. But to register a field that will be used by a PMD, we need to ask for the feature at port configuration (usually through ethdev). Then the PMD will register the dynamic field. If it fails, the configuration of the port should fail. The application that will access to the field will also register it. It can be done before or after the PMD initialization.