From: "Wiles, Keith" <keith.wiles@intel.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Cc: Dan Gora <dg@adax.com>, "dev@dpdk.org" <dev@dpdk.org>,
Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [dpdk-dev] [PATCH 1/4] mbuf: add accessor function for private data area
Date: Fri, 8 Jun 2018 17:19:33 +0000 [thread overview]
Message-ID: <5F1328F1-6991-45EA-8DC2-300600702210@intel.com> (raw)
In-Reply-To: <99f224eb-0470-78d2-a062-8dca4d4b7b1a@solarflare.com>
> On Jun 8, 2018, at 2:06 AM, Andrew Rybchenko <arybchenko@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@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
next prev parent reply other threads:[~2018-06-08 17:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-07 23:54 Dan Gora
2018-06-08 8:30 ` Burakov, Anatoly
2018-06-08 9:06 ` Andrew Rybchenko
2018-06-08 17:19 ` Wiles, Keith [this message]
2018-06-09 0:24 ` Dan Gora
2018-06-09 9:23 ` Andrew Rybchenko
2018-06-12 2:24 ` Dan Gora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5F1328F1-6991-45EA-8DC2-300600702210@intel.com \
--to=keith.wiles@intel.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=dg@adax.com \
--cc=olivier.matz@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).