From: Andrew Rybchenko <arybchenko@solarflare.com>
To: Dan Gora <dg@adax.com>, <dev@dpdk.org>
Cc: 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 12:06:04 +0300 [thread overview]
Message-ID: <99f224eb-0470-78d2-a062-8dca4d4b7b1a@solarflare.com> (raw)
In-Reply-To: <20180607235454.27832-1-dg@adax.com>
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.
> +}
> +
> /**
> * Returns TRUE if given mbuf is cloned by mbuf indirection, or FALSE
> * otherwise.
next prev parent reply other threads:[~2018-06-08 9:06 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 [this message]
2018-06-08 17:19 ` Wiles, Keith
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=99f224eb-0470-78d2-a062-8dca4d4b7b1a@solarflare.com \
--to=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).