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 7ABEDA04DD; Wed, 28 Oct 2020 13:23:47 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7B0FECA37; Wed, 28 Oct 2020 13:21:59 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id F10F6CA16 for ; Wed, 28 Oct 2020 13:21:57 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9DE265C013F; Wed, 28 Oct 2020 08:21:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 28 Oct 2020 08:21:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= Yxu6VqzwQka1ofxiQ/UtoHoQvB8W6pILEhwp2MdHPTI=; b=KkgFkjK0KvV6u+em Uz4AuQ8GcaJipeIkCoFSQih2BNrfPIkvsPE04aqrdg60HizDYwCozp2GbqQ7txih qj7YcFhiKEyOjEH06swyKEcIZGvHLkHVhYPZLJoSXI+b+u4P0HBEXhypJ4+dZ8Et DXCYiWM4VBgmNuAJQwnGPI24QEvtL6S6ltNk+AOqqstQlBetne7Vb4hXP07XsX/Y UdHk4Ej0rfJM+2tmAqrwiisA2bjm6u9OYpJwN/FAiCT8JIX0C7XZUdlajJEooXGn Do8+w8RbSEI1CjCkdsRA/yFXET0FU+ye82XGaQZQwSUGjUzEAN05NNxqENf653gd sFJvfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Yxu6VqzwQka1ofxiQ/UtoHoQvB8W6pILEhwp2MdHP TI=; b=CRovnWc7gPrn4KBktU7nWJACFMD1chTTGEAjIlvEIell+BMgwGFVk/zpW j++7NGj8LM/U8Zmfu9V04acb/VoYiYIAW/P4uPsqtKzo7zqBfpWL3oD/w0JUc+rS sToBVB/p23LUH8rZlxM7UIScMOLrDNWtvvX4tjaBi8V6fc9CHitzBOqaKU04BviP WKcFZtU1s2dmlMmsVQmLRvbzheDBUG/iITeAZOTYwAyOBlqjO886N8czfjwN2KMA GzlcACP6oPx269qqZHCmHji8N4UScI57MMPcbQJftCrW5KbmIFmk0GW1VlnLbr3c AXdSefvBbdS6RQtbAMcFpzkStFV0A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrledugdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 8CB253280064; Wed, 28 Oct 2020 08:21:53 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: dev@dpdk.org, ferruh.yigit@intel.com, david.marchand@redhat.com, bruce.richardson@intel.com, olivier.matz@6wind.com, akhil.goyal@nxp.com, Nicolas Chautru Date: Wed, 28 Oct 2020 13:21:52 +0100 Message-ID: <1714689.AnfboGAeF5@thomas> In-Reply-To: References: <20201026052105.1561859-1-thomas@monjalon.net> <20201028102640.3191964-14-thomas@monjalon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4 13/15] examples/bbdev: switch to dynamic mbuf field 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" 28/10/2020 12:51, Andrew Rybchenko: > On 10/28/20 1:26 PM, Thomas Monjalon wrote: > > The example used the deprecated mbuf field udata64 as input mbuf pointer. > > It is moved to a dynamic field in order to allow removal of udata64. > > > > Signed-off-by: Thomas Monjalon > > Reviewed-by: Andrew Rybchenko > > I like the approach with inline function(s) more than approach > with macros. Not sure that get/set is needed. Approach in > David's patches looks a bit simpler to me - less duplicated > code (i.e. just one function which returns pointer of correct > type to a dynamic field and allow to get and set it). Yes I tend to agree with you. Olivier was asking for more functions, especially if it has a semantic meaning. Here get/set has no real added value but I don't have strong opinion, and I don't think it deserves a respin :)