From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id AD1994CBB for ; Fri, 8 Jun 2018 11:06:15 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 3AAA1A8005A; Fri, 8 Jun 2018 09:06:14 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 8 Jun 2018 10:06:09 +0100 To: Dan Gora , CC: Olivier Matz References: <20180607235454.27832-1-dg@adax.com> From: Andrew Rybchenko Message-ID: <99f224eb-0470-78d2-a062-8dca4d4b7b1a@solarflare.com> Date: Fri, 8 Jun 2018 12:06:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180607235454.27832-1-dg@adax.com> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23894.003 X-TM-AS-Result: No--16.078800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1528448775-1WLKR-GEjuGO Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 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, 08 Jun 2018 09:06:16 -0000 On 06/08/2018 02:54 AM, Dan Gora wrote: > Add an inline accessor function to return the starting address of > the private data area in the supplied mbuf. > > If the user did not allocate space for a private data area in the > mbuf's memory pool, then return NULL. > > 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. > > Signed-off-by: Dan Gora > --- > lib/librte_mbuf/rte_mbuf.h | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > index 8e6b4d292..0c4f8f698 100644 > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -728,6 +728,25 @@ rte_mbuf_to_baddr(struct rte_mbuf *md) > return buffer_addr; > } > > +/** > + * Return the starting address of the private data area embedded in > + * the given mbuf. > + * > + * @param md > + * The pointer to the mbuf. > + * @return > + * The starting address of the private data area or NULL if there > + * is no private data area. > + */ > +static inline void * > +rte_mbuf_to_priv(struct rte_mbuf *md) Just a nit... As I understand 'md' here follows previous function which is rte_mbuf_to_baddr() and works with direct mbuf - that's why parameter is named 'md' (mbuf direct). The most of functions in the header use just 'm' for any mbuf. > +{ > + if (md->priv_size == 0) > + return NULL; > + > + return RTE_PTR_ADD(md, sizeof(struct rte_mbuf)); Also a nit... I'd use sizeof(*md) (or sizeof(*m) in fact as described above) here. At least previous functions do it in such way. > +} > + > /** > * Returns TRUE if given mbuf is cloned by mbuf indirection, or FALSE > * otherwise.