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 7BC1DA00E6 for ; Fri, 12 Jul 2019 16:55:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9A5071B9D9; Fri, 12 Jul 2019 16:55:34 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id AF0961B9D6 for ; Fri, 12 Jul 2019 16:55:33 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id E85BFB40070; Fri, 12 Jul 2019 14:55:31 +0000 (UTC) Received: from [192.168.1.11] (85.187.13.152) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 15:55:26 +0100 To: Olivier Matz , References: <20190710092907.5565-1-olivier.matz@6wind.com> From: Andrew Rybchenko Message-ID: <06276df5-302f-a3af-218e-ef736bc26fc3@solarflare.com> Date: Fri, 12 Jul 2019 17:54:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190710092907.5565-1-olivier.matz@6wind.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [85.187.13.152] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24754.000 X-TM-AS-Result: No-4.324100-8.000000-10 X-TMASE-MatchedRID: X4bcv0S75KnmLzc6AOD8DfHkpkyUphL9wZy9wGhpvaMfyMkN7e89A9wB FZvAf8OoCsRPQ32r0Mric+2pUF+sfpvp2jLNdmv5RiTxdAMnyJX54F/2i/DwjcAkyHiYDAQb1Is 5GvhmGbykm2pPzaVpuN7GFZVxkdav8rLDFSsZ1SSwmuJu9uyFD2m/mT16mTUC4nILf2j2NO4pQP 60tO0L4ZwyjHkeTa+VGcOo9nz8FOHW79LHa+gib8CxC+PryYbTRElFv2Ob9BIRGC0rW8q1XeTXo kEQfE6FrIXdgIcRFFsXWFeZdHDFjdAoWKhYv87v2oIkXC6Ol0BC2HaxoMvkqtc5vy7DXWxjlMa9 Q0Vx5vQJXPI0lc+77rw/krmG+Si6lwV2iaAfSWc5f9Xw/xqKXXJnzNw42kCxxEHRux+uk8irEHf aj14Zyav2p1svv5vyby4/c8D0EcP+4ouCl85HEQOAI/r446Puqc0qX05aCPrEAlAjyH4Ph7y8nD e8NfpWtnhXF+BJgdegZXMt1P3SCHOkesP+h5icvvF99/LtVog3warKS25Qh5CzhZCUYrJjXUsWX JaMK2s= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--4.324100-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24754.000 X-MDID: 1562943332-QGWEj0otWtub 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 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. 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? 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? Do we need to keep track which entity has registered which dynamic fields? 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?