From: Olivier Matz <olivier.matz@6wind.com>
To: Hiroyuki Mikita <h.mikita89@gmail.com>
Cc: dev@dpdk.org, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Subject: Re: [PATCH] mbuf: decrease refcnt when detaching
Date: Mon, 16 May 2016 10:52:44 +0200 [thread overview]
Message-ID: <57398A5C.2050802@6wind.com> (raw)
In-Reply-To: <1463327436-6863-1-git-send-email-h.mikita89@gmail.com>
Hi Hiroyuki,
On 05/15/2016 05:50 PM, Hiroyuki Mikita wrote:
> The rte_pktmbuf_detach() function should decrease refcnt on a direct
> buffer.
>
> Signed-off-by: Hiroyuki Mikita <h.mikita89@gmail.com>
> ---
> lib/librte_mbuf/rte_mbuf.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 529debb..3b117ca 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -1468,9 +1468,11 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
> */
> static inline void rte_pktmbuf_detach(struct rte_mbuf *m)
> {
> + struct rte_mbuf *md = rte_mbuf_from_indirect(m);
> struct rte_mempool *mp = m->pool;
> uint32_t mbuf_size, buf_len, priv_size;
>
> + rte_mbuf_refcnt_update(md, -1);
> priv_size = rte_pktmbuf_priv_size(mp);
> mbuf_size = sizeof(struct rte_mbuf) + priv_size;
> buf_len = rte_pktmbuf_data_room_size(mp);
> @@ -1498,7 +1500,7 @@ __rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> if (RTE_MBUF_INDIRECT(m)) {
> struct rte_mbuf *md = rte_mbuf_from_indirect(m);
> rte_pktmbuf_detach(m);
> - if (rte_mbuf_refcnt_update(md, -1) == 0)
> + if (rte_mbuf_refcnt_read(md) == 0)
> __rte_mbuf_raw_free(md);
> }
> return m;
>
Thanks for submitting this patch. I agree that rte_pktmbuf_attach()
and rte_pktmbuf_detach() are not symmetrical, but I think your patch
could trigger some race conditions.
Example:
- init: m, c1 and c2 are direct mbuf
- rte_pktmbuf_attach(c1, m); # c1 becomes a clone of m
- rte_pktmbuf_attach(c2, m); # c2 becomes another clone of m
- rte_pktmbuf_free(m);
- after that, we have:
- m is a direct mbuf with refcnt = 2
- c1 is an indirect mbuf pointing to data of m
- c2 is an indirect mbuf pointing to data of m
- if we call rte_pktmbuf_free(c1) and rte_pktmbuf_free(c2) on 2
different cores at the same time, m can be freed twice because
(rte_mbuf_refcnt_read(md) == 0) can be true on both cores.
I think the proper way of doing would be to have rte_pktmbuf_detach()
returning the value of rte_mbuf_refcnt_update(md, -1), ensuring that
only one core will call _rte_mbuf_raw_free().
In the unit tests, in test_attach_from_different_pool(), the mbuf m
is never freed due to this behavior. That shows the current api is
a bit misleading. I think it should also be fixed in the patch.
Another issue is that it will break the API.
To avoid issues in applications relying on the current behavior of
rte_pktmbuf_detach(), I'd say we should keep the function as-is and
mark it as deprecated. Then, introduce a new function
rte_pktmbuf_detach2() (or any better name :) ) that changes the
behavior to what you suggest. An entry in the release note would
also be helpful.
The other option is to let things as-is and just document the behavior
of rte_pktmbuf_detach(), explicitly saying that it is not symmetrical
with the attach. But I'd prefer the first option.
Thoughts ?
Regards,
Olivier
next prev parent reply other threads:[~2016-05-16 8:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-15 15:50 [PATCH] mbuf: decrease refcnt when detaching Hiroyuki Mikita
2016-05-16 0:05 ` Ananyev, Konstantin
2016-05-16 2:46 ` Hiroyuki MIKITA
2016-05-16 8:49 ` Ananyev, Konstantin
2016-05-16 9:13 ` Thomas Monjalon
2016-05-16 16:24 ` Hiroyuki MIKITA
2016-05-16 8:52 ` Olivier Matz [this message]
2016-05-16 16:53 ` [PATCH v2] " Hiroyuki Mikita
2016-05-17 10:58 ` Bruce Richardson
2016-05-17 11:06 ` Ananyev, Konstantin
2016-05-17 12:43 ` Thomas Monjalon
2016-05-17 12:59 ` Ananyev, Konstantin
2016-05-17 13:39 ` Thomas Monjalon
2016-05-17 13:44 ` Ananyev, Konstantin
2016-05-17 14:19 ` Thomas Monjalon
2016-05-17 15:45 ` Ananyev, Konstantin
2016-05-17 16:12 ` Hiroyuki MIKITA
2016-05-17 16:35 ` [PATCH v3] " Hiroyuki Mikita
2016-05-18 11:58 ` Olivier Matz
2016-05-18 14:29 ` Hiroyuki Mikita
2016-05-18 14:41 ` [PATCH v4] " Hiroyuki Mikita
2016-05-18 15:51 ` Olivier Matz
2016-05-19 12:38 ` 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=57398A5C.2050802@6wind.com \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=h.mikita89@gmail.com \
--cc=konstantin.ananyev@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 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.