From: Thomas Monjalon <thomas@monjalon.net>
To: Dan Gora <dg@adax.com>
Cc: dev@dpdk.org, Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [PATCH v2 1/4] mbuf: add accessor function for private data area
Date: Fri, 13 Jul 2018 23:10:29 +0200 [thread overview]
Message-ID: <2026591.7TBDLejgCm@xps> (raw)
In-Reply-To: <20180626073904.nsieqomdqq3xmr62@platinum>
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 <dg@adax.com>
>
> 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 <olivier.matz@6wind.com>
Series applied
prev parent reply other threads:[~2018-07-13 21:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-18 23:35 [PATCH v2 1/4] mbuf: add accessor function for private data area Dan Gora
2018-06-19 12:56 ` Andrew Rybchenko
2018-06-26 7:39 ` Olivier Matz
2018-07-13 21:10 ` Thomas Monjalon [this message]
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=2026591.7TBDLejgCm@xps \
--to=thomas@monjalon.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.