From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by dpdk.org (Postfix) with ESMTP id 9AC922B86 for ; Fri, 13 Jul 2018 23:10:32 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8FA9437B; Fri, 13 Jul 2018 17:10:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 13 Jul 2018 17:10:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=iHnToxiYOkVC3mTzS+m2WWYytw m2YdC+yMNMXFuxdz4=; b=rFImmZj1qTGHHoV2gxwJv1lqIzGbn2mFoiCp32bQYj EqVXJPXkhsrEXwJ8FTHdJDJl90RXYiUJAKhPjQHouGIBe1gmd6Z9awbvV/3/PU0s WoyehCvhClsLUJCgLZWzLyFhAddGZ4ajzleY6lWLQqOt7YdAZmvMaBGQkdk25IvS 0= 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=iHnTox iYOkVC3mTzS+m2WWYytwm2YdC+yMNMXFuxdz4=; b=dv01DHSwEfuyOHHVBVygC9 u2Z9UWfjtOsIAfw8UOLcL4+BvG/za7DneVzdK51lm+ZQ+t1/RIeUq4t8ODqILxc3 6ASvN3r+CB6IJm14j464ly8Trx1fjx3cM2ZApljHv7apBiZOtG8l8knrOSsRjv/D 9UiWsm+JuTeALA8cm2suEx0sGubLScAKTIN/P1bpV6i4LF9qrMjVAl9TCkd+d6i5 G9h7eTwuXfc9QJRvQCbB0jMs8rOCYzNLmXfNKmImJy8T4vRCAfwsZYBmNBqQpBn/ 72N+q2vtMf4cB/K4fVglStrptuyqG/N9MvWtmSLDBga/KA95bM9FfznBGYG9bdUQ == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 77AB310273; Fri, 13 Jul 2018 17:10:30 -0400 (EDT) From: Thomas Monjalon To: Dan Gora Cc: dev@dpdk.org, Olivier Matz Date: Fri, 13 Jul 2018 23:10:29 +0200 Message-ID: <2026591.7TBDLejgCm@xps> In-Reply-To: <20180626073904.nsieqomdqq3xmr62@platinum> References: <20180618233534.21611-1-dg@adax.com> <20180626073904.nsieqomdqq3xmr62@platinum> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 1/4] mbuf: add accessor function for private data area 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: , X-List-Received-Date: Fri, 13 Jul 2018 21:10:32 -0000 26/06/2018 09:39, Olivier Matz: > Hi Dan, > > On Mon, Jun 18, 2018 at 04:35:34PM -0700, Dan Gora wrote: > > Add an inline accessor function to return the starting address of > > the private data area in the supplied mbuf. > > > > This allows applications to easily access the private data area between > > the struct rte_mbuf and the data buffer in the specified mbuf without > > creating private macros or accessor functions. > > > > No checks are made to ensure that a private data area actually exists > > in the buffer. > > > > Signed-off-by: Dan Gora > > Thank you for this patch. > > Few (late) comments to your previous questions: > > - about rte_mbuf vs rte_pktmbuf, as Andrew said pktmbuf was used in > the past when there was a ctrlmbuf. This one has been removed now, so > mbuf should be used. > > - I agree that removing the test (m->priv_size == 0) is better for > the reasons mentionned, and also because it would add a test in the > dataplane area, which would sometimes be useless: the application create > the mbuf pools, so it can know that all mbufs have a priv area. > > > Acked-by: Olivier Matz Series applied