From: Olivier Matz <olivier.matz@6wind.com>
To: Hiroyuki Mikita <h.mikita89@gmail.com>,
thomas.monjalon@6wind.com, konstantin.ananyev@intel.com
Cc: dev@dpdk.org
Subject: Re: [PATCH v3] mbuf: decrease refcnt when detaching
Date: Wed, 18 May 2016 13:58:54 +0200 [thread overview]
Message-ID: <573C58FE.3020101@6wind.com> (raw)
In-Reply-To: <1463502902-5295-1-git-send-email-h.mikita89@gmail.com>
Hi Hiroyuki,
Thanks for submitting a new version.
There are some styling issues in the patch, I highlighted them below
but you can check them by using checkpatch:
DPDK_CHECKPATCH_PATH=/path/to/linux/checkpatch.pl \
scripts/checkpatches.sh file.patch
On 05/17/2016 06:35 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>
>
> [...]
>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 529debb..299b60e 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -1408,6 +1408,8 @@ static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool,
> *
> * After attachment we refer the mbuf we attached as 'indirect',
> * while mbuf we attached to as 'direct'.
> + * The direct mbuf's reference counter is incremented.
> + *
ERROR:TRAILING_WHITESPACE: trailing whitespace
#82: FILE: lib/librte_mbuf/rte_mbuf.h:1412:
+ * $
> * Right now, not supported:
> * - attachment for already indirect mbuf (e.g. - mi has to be direct).
> * - mbuf we trying to attach (mi) is used by someone else
> @@ -1462,12 +1464,15 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
> * - restore original mbuf address and length values.
> * - reset pktmbuf data and data_len to their default values.
> * All other fields of the given packet mbuf will be left intact.
> + * - decrement the direct mbuf's reference counter.
> + * When the reference counter becomes 0, the direct mbuf is freed.
Minor comment here: I think something like that would be clearer:
* - restore original mbuf address and length values.
* - reset pktmbuf data and data_len to their default values.
* - decrement the direct mbuf's reference counter. When the
* reference counter becomes 0, the direct mbuf is freed.
*
* All other fields of the given packet mbuf will be left intact.
> *
> * @param m
> * The indirect attached packet mbuf.
> */
> 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;
>
> @@ -1482,6 +1487,10 @@ static inline void rte_pktmbuf_detach(struct rte_mbuf *m)
> m->data_off = RTE_MIN(RTE_PKTMBUF_HEADROOM, (uint16_t)m->buf_len);
> m->data_len = 0;
> m->ol_flags = 0;
> +
> + if (rte_mbuf_refcnt_update(md, -1) == 0) {
> + __rte_mbuf_raw_free(md);
> + }
> }
WARNING:BRACES: braces {} are not necessary for single statement blocks
#107: FILE: lib/librte_mbuf/rte_mbuf.h:1491:
+ if (rte_mbuf_refcnt_update(md, -1) == 0) {
+ __rte_mbuf_raw_free(md);
+ }
>
> static inline struct rte_mbuf* __attribute__((always_inline))
> @@ -1491,15 +1500,9 @@ __rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
>
> if (likely(rte_mbuf_refcnt_update(m, -1) == 0)) {
>
> - /* if this is an indirect mbuf, then
> - * - detach mbuf
> - * - free attached mbuf segment
> - */
> + /* if this is an indirect mbuf, it is detached. */
> 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)
> - __rte_mbuf_raw_free(md);
> }
> return m;
> }
>
It's not seen by checkpatch, but the braces could also be removed
here.
Apart from this, it looks good to me. I'm ok with not providing a
compat function as we could consider it was a bug.
Thanks for working on this.
Olivier
next prev parent reply other threads:[~2016-05-18 11:59 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
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 [this message]
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=573C58FE.3020101@6wind.com \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=h.mikita89@gmail.com \
--cc=konstantin.ananyev@intel.com \
--cc=thomas.monjalon@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.