[dpdk-dev] [PATCH 1/4] mbuf: add accessor function for private data area

Wiles, Keith keith.wiles at intel.com
Fri Jun 8 19:19:33 CEST 2018



> On Jun 8, 2018, at 2:06 AM, Andrew Rybchenko <arybchenko at solarflare.com> wrote:
> 
> 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 <dg at adax.com>
>> ---
>>  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.

I believe the sizeof(struct rte_mbuf) is much more readable then sizeof(*m) it makes the reader have to look up what ‘m’ is defined to. I know this is a small function, but readability is still a good reason to not use sizeof(*m) IMO.

> 
>> +}
>> +
>>  /**
>>   * Returns TRUE if given mbuf is cloned by mbuf indirection, or FALSE
>>   * otherwise.

Regards,
Keith



More information about the dev mailing list