From: Olivier MATZ <olivier.matz-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
To: "Ananyev,
Konstantin"
<konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
Subject: Re: [PATCH v2] rte_mbuf: mbuf bulk alloc/free functions added + unittest
Date: Thu, 19 Mar 2015 11:54:55 +0100 [thread overview]
Message-ID: <550AAAFF.2010905@6wind.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258213F749B-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hi Konstantin,
On 03/19/2015 11:47 AM, Ananyev, Konstantin wrote:
>>>> Hi, Konstantin,
>>>>
>>>> Got it. To make the same, nulling the next should be inside of the block as you said.
>>>> One question raises here: If a segment in the chain has refcnt > 1 (so its next is not assigned NULL), and the next segment has
>> refcnt
>>>> == 1 (so it is freed), do you think this scenario is real/should be considered? If so, the former can be safely freed only by calling
>>>> rte_pktmbuf_free_seg which does not iterate. So why to keep next pointing to something?
>>>
>>> I think we need it, not just to keep things the same with rte_pktmbuf_free(), but because it is a right thing to do.
>>> Let say you have a packet in 2 mbufs chained together, both mbufs have refcnt==2.
>>> Then:
>>> rte_pktmbuf_free(firs_mbuf);
>>> rte_pktmbuf_free(firs_mbuf);
>>>
>>> Would work correctly and free both mbufs back to the mempool.
>>>
>>> While after:
>>> rte_pktmbuf_free_chain(first_mbuf);
>>> rte_pktmbuf_free_chain(first_mbuf);
>>>
>>> We would have first_mbuf freed back into the mempool, while second would get lost(memory leaking).
>>> Basically free() shouldn't modify any filed inside mbuf, except refcnt if rte_mbuf_refcnt_update(m, -1) > 0
>>>
>>> About your case, when: first_mbuf->refcnt==2 and second_mbuf->refcnt==1.
>>> Right now, rte_pktmbuf_free() can't handle such cases properly,
>>> and, as I know, such situation is not considered as valid one.
>>
>> I'm not sure I understand what you are saying. To me, the case you are
>> describing is similar to the case below, and it should work properly:
>>
>> /* allocate a packet and clone it. After that, m1 has a
>> * refcnt of 2 */
>> m1 = rte_pktmbuf_alloc();
>> clone1 = rte_pktmbuf_clone(m1);
>>
>> /* allocate another packet */
>> m2 = rte_pktmbuf_alloc();
>>
>> /* chain m2 after m1, updating fields like total length.
>> * After that, m1 has 2 segments, the first one has a refcnt
>> * of 1 and the second has a refcnt of 2 */
>> mbuf_concat(m1, m2);
>>
>> /* This will decrement the refcnt on the first segment and
>> * free the second segment */
>> rte_pktmbuf_free(m1);
>>
>> /* free the indirect mbuf, and as the refcnt is 1 on the
>> * direct mbuf (m1), also release it */
>> rte_pktmbuf_free(clone1);
>>
>> Am I missing something?
>
> The scenario you described would work I believe, as second reference for m1 is from indirect mbuf.
> So rte_pktmbuf_free(clone1) would just call __rte_mbuf_raw_free(m1).
>
> The scenario I am talking about is:
> No indirect mbufs pointing to m1 data buffer.
> m1->next == m2; m1->refcnt==2;
> m2->next == NULL; m2->rectn==1;
>
> And then:
> rte_pktmbuf_free(m1); //after that m2 is freed, but m1->next == m2
> rte_pktmbuf_free(m1); //would call rte_pktmbuf_free_seg(m2)
>
> That one would not work correctly, and I think considered as invalid case right now.
Ok, I agree this is invalid and should not happen.
Thanks,
Olivier
next prev parent reply other threads:[~2015-03-19 10:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-17 21:36 [PATCH v2] rte_mbuf: mbuf bulk alloc/free functions added + unittest vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w
[not found] ` <1426628169-1735-1-git-send-email-vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-03-17 23:46 ` Ananyev, Konstantin
[not found] ` <2601191342CEEE43887BDE71AB977258213F6F10-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-18 5:19 ` Vadim Suraev
[not found] ` <2601191342CEEE43887BDE71AB977258213F7053@irsmsx105.ger.corp.intel.com>
[not found] ` <2601191342CEEE43887BDE71AB977258213F7053-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-18 9:56 ` Ananyev, Konstantin
[not found] ` <2601191342CEEE43887BDE71AB977258213F706D-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-18 10:41 ` Vadim Suraev
[not found] ` <2601191342CEEE43887BDE71AB977258213F7136@irsmsx105.ger.corp.intel.com>
[not found] ` <2601191342CEEE43887BDE71AB977258213F7136-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-18 15:13 ` Ananyev, Konstantin
[not found] ` <2601191342CEEE43887BDE71AB977258213F7188-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-19 8:13 ` Olivier MATZ
[not found] ` <550A850D.9010309-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2015-03-19 10:47 ` Ananyev, Konstantin
[not found] ` <2601191342CEEE43887BDE71AB977258213F749B-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-19 10:54 ` Olivier MATZ [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-03-18 20:21 vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w
[not found] ` <1426710078-11230-1-git-send-email-vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-03-18 20:58 ` Neil Horman
[not found] ` <20150318205856.GA5151-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org>
2015-03-19 8:41 ` Olivier MATZ
[not found] ` <550A8BB5.9040104-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2015-03-19 10:06 ` Ananyev, Konstantin
2015-03-19 13:16 ` Neil Horman
[not found] ` <20150319131639.GB1992-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2015-03-23 16:44 ` Olivier MATZ
[not found] ` <551042D2.5040300-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2015-03-23 17:31 ` Vadim Suraev
[not found] ` <CAJ0CJ8kaVmfic7e9frHjYjvEP2QBcGdiMGVAcrVuGX+4CuOYcQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-23 23:48 ` Ananyev, Konstantin
[not found] ` <2601191342CEEE43887BDE71AB977258214070D7-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-24 7:53 ` Vadim Suraev
[not found] ` <2601191342CEEE43887BDE71AB977258214071C0@irsmsx105.ger.corp.intel.com>
[not found] ` <2601191342CEEE43887BDE71AB977258214071C0-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-24 11:00 ` Ananyev, Konstantin
2015-03-23 18:45 ` Neil Horman
2015-03-30 19:04 ` Vadim Suraev
[not found] ` <CAJ0CJ8mn9R4CAKp-M1NE2Td=L+GQnxGvpdeBOVQKDa0jYg9RZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-30 20:15 ` Neil Horman
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=550AAAFF.2010905@6wind.com \
--to=olivier.matz-pdr9zngts4eavxtiumwx3w@public.gmane.org \
--cc=dev-VfR2kkLFssw@public.gmane.org \
--cc=konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/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.