From: Yongseok Koh <yskoh@mellanox.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"adrien.mazarguil@6wind.com" <adrien.mazarguil@6wind.com>,
"nelio.laranjeiro@6wind.com" <nelio.laranjeiro@6wind.com>
Subject: Re: [dpdk-dev] [PATCH v5 1/2] mbuf: support attaching external buffer to mbuf
Date: Wed, 25 Apr 2018 10:06:39 -0700 [thread overview]
Message-ID: <20180425170638.GB3268@yongseok-MBP.local> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258AEBCF98C@IRSMSX102.ger.corp.intel.com>
On Wed, Apr 25, 2018 at 01:31:42PM +0000, Ananyev, Konstantin wrote:
[...]
> > /** Mbuf prefetch */
> > #define RTE_MBUF_PREFETCH_TO_FREE(m) do { \
> > if ((m) != NULL) \
> > @@ -1213,11 +1306,127 @@ static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool,
> > }
> >
> > /**
> > + * Attach an external buffer to a mbuf.
> > + *
> > + * User-managed anonymous buffer can be attached to an mbuf. When attaching
> > + * it, corresponding free callback function and its argument should be
> > + * provided. This callback function will be called once all the mbufs are
> > + * detached from the buffer.
> > + *
> > + * The headroom for the attaching mbuf will be set to zero and this can be
> > + * properly adjusted after attachment. For example, ``rte_pktmbuf_adj()``
> > + * or ``rte_pktmbuf_reset_headroom()`` can be used.
> > + *
> > + * More mbufs can be attached to the same external buffer by
> > + * ``rte_pktmbuf_attach()`` once the external buffer has been attached by
> > + * this API.
> > + *
> > + * Detachment can be done by either ``rte_pktmbuf_detach_extbuf()`` or
> > + * ``rte_pktmbuf_detach()``.
> > + *
> > + * Attaching an external buffer is quite similar to mbuf indirection in
> > + * replacing buffer addresses and length of a mbuf, but a few differences:
> > + * - When an indirect mbuf is attached, refcnt of the direct mbuf would be
> > + * 2 as long as the direct mbuf itself isn't freed after the attachment.
> > + * In such cases, the buffer area of a direct mbuf must be read-only. But
> > + * external buffer has its own refcnt and it starts from 1. Unless
> > + * multiple mbufs are attached to a mbuf having an external buffer, the
> > + * external buffer is writable.
> > + * - There's no need to allocate buffer from a mempool. Any buffer can be
> > + * attached with appropriate free callback and its IO address.
> > + * - Smaller metadata is required to maintain shared data such as refcnt.
> > + *
> > + * @warning
> > + * @b EXPERIMENTAL: This API may change without prior notice.
> > + * Once external buffer is enabled by allowing experimental API,
> > + * ``RTE_MBUF_DIRECT()`` and ``RTE_MBUF_INDIRECT()`` are no longer
> > + * exclusive. A mbuf can be considered direct if it is neither indirect nor
> > + * having external buffer.
> > + *
> > + * @param m
> > + * The pointer to the mbuf.
> > + * @param buf_addr
> > + * The pointer to the external buffer we're attaching to.
> > + * @param buf_iova
> > + * IO address of the external buffer we're attaching to.
> > + * @param buf_len
> > + * The size of the external buffer we're attaching to. If memory for
> > + * shared data is not provided, buf_len must be larger than the size of
> > + * ``struct rte_mbuf_ext_shared_info`` and padding for alignment. If not
> > + * enough, this function will return NULL.
> > + * @param shinfo
> > + * User-provided memory for shared data. If NULL, a few bytes in the
> > + * trailer of the provided buffer will be dedicated for shared data and
> > + * the shared data will be properly initialized. Otherwise, user must
> > + * initialize the content except for free callback and its argument. The
> > + * pointer of shared data will be stored in m->shinfo.
> > + * @param free_cb
> > + * Free callback function to call when the external buffer needs to be
> > + * freed.
> > + * @param fcb_opaque
> > + * Argument for the free callback function.
> > + *
> > + * @return
> > + * A pointer to the new start of the data on success, return NULL
> > + * otherwise.
> > + */
> > +static inline char * __rte_experimental
> > +rte_pktmbuf_attach_extbuf(struct rte_mbuf *m, void *buf_addr,
> > + rte_iova_t buf_iova, uint16_t buf_len,
> > + struct rte_mbuf_ext_shared_info *shinfo,
> > + rte_mbuf_extbuf_free_callback_t free_cb, void *fcb_opaque)
> > +{
> > + /* Additional attachment should be done by rte_pktmbuf_attach() */
> > + RTE_ASSERT(!RTE_MBUF_HAS_EXTBUF(m));
>
> Shouldn't we have here something like:
> RTE_ASSERT(RTE_MBUF_DIRECT(m) && rte_mbuf_refcnt_read(m) == 1);
> ?
Right. That's better. Attaching mbuf should be direct and writable.
> > +
> > + m->buf_addr = buf_addr;
> > + m->buf_iova = buf_iova;
> > +
> > + if (shinfo == NULL) {
>
> Instead of allocating shinfo ourselves - wound's it be better to rely
> on caller always allocating afeeling it for us (he can do that at the end/start of buffer,
> or whenever he likes to.
It is just for convenience. For some users, external attachment could be
occasional and casual, e.g. punt control traffic from kernel/hv. For such
non-serious cases, it is good to provide this small utility.
> Again in that case - caller can provide one shinfo to several mbufs (with different buf_addrs)
> and would know for sure that free_cb wouldn't be overwritten by mistake.
> I.E. mbuf code will only update refcnt inside shinfo.
I think you missed the discussion with other people yesterday. This change is
exactly for that purpose. Like I documented above, if this API is called with
shinfo being provided, it will use the user-provided shinfo instead of sparing a
few byte in the trailer and won't touch the shinfo. This code block happens only
if user doesn't provide memory for shared data (shinfo is NULL).
> > + void *buf_end = RTE_PTR_ADD(buf_addr, buf_len);
> > +
> > + shinfo = RTE_PTR_ALIGN_FLOOR(RTE_PTR_SUB(buf_end,
> > + sizeof(*shinfo)), sizeof(uintptr_t));
> > + if ((void *)shinfo <= buf_addr)
> > + return NULL;
> > +
> > + m->buf_len = RTE_PTR_DIFF(shinfo, buf_addr);
> > + rte_mbuf_ext_refcnt_set(shinfo, 1);
> > + } else {
> > + m->buf_len = buf_len;
>
> I think you need to update shinfo>refcnt here too.
Like explained above, if shinfo is provided, it doesn't alter anything except
for callbacks and its arg.
Thanks,
Yongseok
next prev parent reply other threads:[~2018-04-25 17:06 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-10 1:25 [dpdk-dev] [PATCH v1 0/6] net/mlx5: add Multi-Packet Rx support Yongseok Koh
2018-03-10 1:25 ` [dpdk-dev] [PATCH v1 1/6] mbuf: add buffer offset field for flexible indirection Yongseok Koh
2018-03-10 1:25 ` [dpdk-dev] [PATCH v1 2/6] net/mlx5: separate filling Rx flags Yongseok Koh
2018-03-10 1:25 ` [dpdk-dev] [PATCH v1 3/6] net/mlx5: add a function to rdma-core glue Yongseok Koh
2018-03-12 9:13 ` Nélio Laranjeiro
2018-03-10 1:25 ` [dpdk-dev] [PATCH v1 4/6] net/mlx5: add Multi-Packet Rx support Yongseok Koh
2018-03-12 9:20 ` Nélio Laranjeiro
2018-03-10 1:25 ` [dpdk-dev] [PATCH v1 5/6] net/mlx5: release Tx queue resource earlier than Rx Yongseok Koh
2018-03-10 1:25 ` [dpdk-dev] [PATCH v1 6/6] app/testpmd: conserve mbuf indirection flag Yongseok Koh
2018-04-02 18:50 ` [dpdk-dev] [PATCH v2 0/6] net/mlx5: add Multi-Packet Rx support Yongseok Koh
2018-04-02 18:50 ` [dpdk-dev] [PATCH v2 1/6] mbuf: add buffer offset field for flexible indirection Yongseok Koh
2018-04-03 8:26 ` Olivier Matz
2018-04-04 0:12 ` Yongseok Koh
2018-04-09 16:04 ` Olivier Matz
2018-04-10 1:59 ` Yongseok Koh
2018-04-11 0:25 ` Ananyev, Konstantin
2018-04-11 5:33 ` Yongseok Koh
2018-04-11 11:39 ` Ananyev, Konstantin
2018-04-11 14:02 ` Andrew Rybchenko
2018-04-11 17:18 ` Yongseok Koh
2018-04-11 17:08 ` Yongseok Koh
2018-04-12 16:34 ` Ananyev, Konstantin
2018-04-12 18:58 ` Yongseok Koh
2018-04-02 18:50 ` [dpdk-dev] [PATCH v2 2/6] net/mlx5: separate filling Rx flags Yongseok Koh
2018-04-02 18:50 ` [dpdk-dev] [PATCH v2 3/6] net/mlx5: add a function to rdma-core glue Yongseok Koh
2018-04-02 18:50 ` [dpdk-dev] [PATCH v2 4/6] net/mlx5: add Multi-Packet Rx support Yongseok Koh
2018-04-02 18:50 ` [dpdk-dev] [PATCH v2 5/6] net/mlx5: release Tx queue resource earlier than Rx Yongseok Koh
2018-04-02 18:50 ` [dpdk-dev] [PATCH v2 6/6] app/testpmd: conserve mbuf indirection flag Yongseok Koh
2018-04-19 1:11 ` [dpdk-dev] [PATCH v3 1/2] mbuf: support attaching external buffer to mbuf Yongseok Koh
2018-04-19 1:11 ` [dpdk-dev] [PATCH v3 2/2] app/testpmd: conserve offload flags of mbuf Yongseok Koh
2018-04-23 11:53 ` [dpdk-dev] [PATCH v3 1/2] mbuf: support attaching external buffer to mbuf Ananyev, Konstantin
2018-04-24 2:04 ` Yongseok Koh
2018-04-25 13:16 ` Ananyev, Konstantin
2018-04-25 16:44 ` Yongseok Koh
2018-04-25 18:05 ` Ananyev, Konstantin
2018-04-23 16:18 ` Olivier Matz
2018-04-24 1:29 ` Yongseok Koh
2018-04-24 15:36 ` Olivier Matz
2018-04-24 1:38 ` [dpdk-dev] [PATCH v4 " Yongseok Koh
2018-04-24 1:38 ` [dpdk-dev] [PATCH v4 2/2] app/testpmd: conserve offload flags of mbuf Yongseok Koh
2018-04-24 5:01 ` [dpdk-dev] [PATCH v4 1/2] mbuf: support attaching external buffer to mbuf Stephen Hemminger
2018-04-24 11:47 ` Yongseok Koh
2018-04-24 12:28 ` Andrew Rybchenko
2018-04-24 16:02 ` Olivier Matz
2018-04-24 18:21 ` [dpdk-dev] ***Spam*** " Andrew Rybchenko
2018-04-24 19:15 ` [dpdk-dev] " Olivier Matz
2018-04-24 20:22 ` Thomas Monjalon
2018-04-24 21:53 ` Yongseok Koh
2018-04-24 22:15 ` Thomas Monjalon
2018-04-25 8:21 ` Olivier Matz
2018-04-25 15:06 ` Stephen Hemminger
2018-04-24 23:34 ` Yongseok Koh
2018-04-25 14:45 ` Andrew Rybchenko
2018-04-25 17:40 ` Yongseok Koh
2018-04-25 8:28 ` Olivier Matz
2018-04-25 9:08 ` Yongseok Koh
2018-04-25 9:19 ` Yongseok Koh
2018-04-25 20:00 ` Olivier Matz
2018-04-25 22:54 ` Yongseok Koh
2018-04-24 22:30 ` Yongseok Koh
2018-04-25 2:53 ` [dpdk-dev] [PATCH v5 " Yongseok Koh
2018-04-25 2:53 ` [dpdk-dev] [PATCH v5 2/2] app/testpmd: conserve offload flags of mbuf Yongseok Koh
2018-04-25 13:31 ` [dpdk-dev] [PATCH v5 1/2] mbuf: support attaching external buffer to mbuf Ananyev, Konstantin
2018-04-25 17:06 ` Yongseok Koh [this message]
2018-04-25 17:23 ` Ananyev, Konstantin
2018-04-25 18:02 ` Yongseok Koh
2018-04-25 18:22 ` Yongseok Koh
2018-04-25 18:30 ` Yongseok Koh
2018-04-26 1:10 ` [dpdk-dev] [PATCH v6 " Yongseok Koh
2018-04-26 1:10 ` [dpdk-dev] [PATCH v6 2/2] app/testpmd: conserve offload flags of mbuf Yongseok Koh
2018-04-26 11:39 ` [dpdk-dev] [PATCH v6 1/2] mbuf: support attaching external buffer to mbuf Ananyev, Konstantin
2018-04-26 16:05 ` Andrew Rybchenko
2018-04-26 16:10 ` Thomas Monjalon
2018-04-26 19:42 ` Olivier Matz
2018-04-26 19:58 ` Thomas Monjalon
2018-04-26 20:07 ` Olivier Matz
2018-04-26 20:24 ` Thomas Monjalon
2018-04-26 17:18 ` Yongseok Koh
2018-04-26 19:45 ` Olivier Matz
2018-04-27 0:01 ` [dpdk-dev] [PATCH v7 " Yongseok Koh
2018-04-27 0:01 ` [dpdk-dev] [PATCH v7 2/2] app/testpmd: conserve offload flags of mbuf Yongseok Koh
2018-04-27 8:00 ` Andrew Rybchenko
2018-04-27 7:22 ` [dpdk-dev] [PATCH v7 1/2] mbuf: support attaching external buffer to mbuf Andrew Rybchenko
2018-04-27 17:22 ` [dpdk-dev] [PATCH v8 " Yongseok Koh
2018-04-27 17:22 ` [dpdk-dev] [PATCH v8 2/2] app/testpmd: conserve offload flags of mbuf Yongseok Koh
2018-04-27 18:09 ` [dpdk-dev] [PATCH v8 1/2] mbuf: support attaching external buffer to mbuf Thomas Monjalon
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=20180425170638.GB3268@yongseok-MBP.local \
--to=yskoh@mellanox.com \
--cc=adrien.mazarguil@6wind.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=nelio.laranjeiro@6wind.com \
--cc=olivier.matz@6wind.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
--cc=wenzhuo.lu@intel.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).