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 A5CCBA0471 for ; Tue, 16 Jul 2019 13:31:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8B3AB3195; Tue, 16 Jul 2019 13:31:20 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id AB6FB2C18 for ; Tue, 16 Jul 2019 13:31:19 +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-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 577E1340071; Tue, 16 Jul 2019 11:31:18 +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; Tue, 16 Jul 2019 12:31:14 +0100 To: Olivier Matz CC: References: <20190710092907.5565-1-olivier.matz@6wind.com> <06276df5-302f-a3af-218e-ef736bc26fc3@solarflare.com> <20190716094909.plszssstmbj2kjaw@platinum> From: Andrew Rybchenko Message-ID: <61c3ac7e-52f5-7d17-2150-ad209f873ea1@solarflare.com> Date: Tue, 16 Jul 2019 14:31:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190716094909.plszssstmbj2kjaw@platinum> 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-24764.000 X-TM-AS-Result: No-12.542400-8.000000-10 X-TMASE-MatchedRID: ZFzIhWOuIztq0U6EhO9EE4mfV7NNMGm+69aS+7/zbj+qvcIF1TcLYDAI p5pTdcguHgMJANv0t7POITe1Iy4+lYpAMGiqcHEM5Qo03mEdwAFjibYbm9O0sMsh83hywc54OFC wbqLWMLiXWBKDe9c5qXPowW7S5SQRl40u9PyJvISqNnzrkU+2mnVNoFzxmabniiKPXbEds+52UI TB7hbummnQ5zSCW+AyoPLKm2nRCpO6LacOIlEHv07tgjnds/VlTsTCHtXv0Pq4zlF1pkNzlprle 4a/uYaak+MXeAJ9thRV4HNAAEjuPvy8t1SC6KPcGjzBgnFZvQ5Zi708rC+Dz8uSXx71bvSLaXKz U8OFYujgzrFYJB6O5xPF8Qn6QUl/CQZYBny/onPaize54oCwVDh4aiF3uCM21y0aXF5eX+gguq3 huZ1BOybIdSrUEQyNlZuuLIAUxI4WFyz6902fBxwu4QM/6Cpy1O6lMmMIDDdBL//DKiVcztskxt NP0r9NMktR0FDInUtrPe2lrP8XWAHXE0tJr8xhi+quUbDYb+RB9uUinegF0Zsoi2XrUn/JyeMtM D9QOgChMIDkR/KfwI2j49Ftap9EOwBXM346/+zxN9BbMDYmD9jxHZC/oAUTN16rk+U6Kz/LXUjk MhTYxYaiqTZxFE1s X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--12.542400-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24764.000 X-MDID: 1563276679-jOO5GfL7Kl0e Subject: Re: [dpdk-dev] ***Spam*** Re: [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 7/16/19 12:49 PM, Olivier Matz wrote: > 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. I see that API itself has no restrictions, but the goal is to have something working and it is very easy to break things with dynamic fields and flags. May be obvious requirements are sufficient (e.g. should be registered before lookup to be found by lookup), but it is getting more complicated when drivers, core libraries and applications come into play with their life cycles. But may be it is really out-of-scope of the API description. Thanks.