From: Olivier MATZ <olivier.matz-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
To: "Ananyev,
Konstantin"
<konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Richardson,
Bruce" <bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
Subject: Re: [PATCH 2/2] Remove RTE_MBUF_REFCNT references
Date: Wed, 18 Feb 2015 12:01:27 +0100 [thread overview]
Message-ID: <54E47107.3020103@6wind.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258213EF67E-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hi Konstantin,
On 02/18/2015 11:47 AM, Ananyev, Konstantin wrote:
>>> How was this managed before, since refcnt field seems to be necessary in order
>>> to effectively manage indirect mbufs? Is this just the case that this is something
>>> that never worked and that needs to be solved, or is it something that was
>>> working that this patch will now break?
>>
>> This is something that never worked before: refcounts are not compatible
>> with reserving private data in mbufs. This patch does not change the
>> issue, it is still there.
>>
>> Before the patch, an application that wanted to reserve a private
>> data could disable refcounts at compile-time.
>> After the patch, the solution is just to avoid using refcounts.
>
> I'd say avoid using mbuf_attach/detach.
> refcnt itself has nothing to do with that.
> I finally understood what you are talking about ...
> About private data - I suppose it is a matter of another patch.
> I still think it would be better to reserve private data space before mbuf, not after
> (at mbuf pool initialisation time).
> Then *BADDR* macros could be unaffected.
Indeed that could be a good idea.
Regards,
Olivier
next prev parent reply other threads:[~2015-02-18 11:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-16 16:08 [PATCH 0/2] Removal of RTE_MBUF_REFCNT Sergio Gonzalez Monroy
[not found] ` <1424102913-18944-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-02-16 16:08 ` [PATCH 1/2] mbuf: Introduce IND_ATTACHED_MBUF flag Sergio Gonzalez Monroy
2015-02-16 16:08 ` [PATCH 2/2] Remove RTE_MBUF_REFCNT references Sergio Gonzalez Monroy
[not found] ` <1424102913-18944-3-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-02-18 9:16 ` Olivier MATZ
[not found] ` <54E45888.7070603-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2015-02-18 9:35 ` Bruce Richardson
2015-02-18 9:48 ` Ananyev, Konstantin
[not found] ` <2601191342CEEE43887BDE71AB977258213EF5E4-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-02-18 10:00 ` Bruce Richardson
2015-02-18 10:14 ` Olivier MATZ
[not found] ` <54E46612.7050809-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2015-02-18 10:22 ` Ananyev, Konstantin
2015-02-18 10:22 ` Bruce Richardson
2015-02-18 10:33 ` Olivier MATZ
[not found] ` <54E46A8C.9010105-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2015-02-18 10:37 ` Bruce Richardson
2015-02-18 10:47 ` Olivier MATZ
2015-02-18 10:47 ` Ananyev, Konstantin
[not found] ` <2601191342CEEE43887BDE71AB977258213EF67E-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-02-18 11:01 ` Olivier MATZ [this message]
2015-02-18 9:52 ` Olivier MATZ
2015-02-16 20:47 ` [PATCH 0/2] Removal of RTE_MBUF_REFCNT Stephen Hemminger
[not found] ` <20150216154710.42bd6fe9-CA4OZQ/Yy2Lykuyl+CZolw@public.gmane.org>
2015-02-17 8:43 ` Gonzalez Monroy, Sergio
2015-02-18 11:03 ` [PATCH v2 " Sergio Gonzalez Monroy
[not found] ` <1424257383-4177-1-git-send-email-sergio.gonzalez.monroy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-02-18 11:03 ` [PATCH v2 1/2] mbuf: Introduce IND_ATTACHED_MBUF flag Sergio Gonzalez Monroy
2015-02-18 11:03 ` [PATCH v2 2/2] Remove RTE_MBUF_REFCNT references Sergio Gonzalez Monroy
2015-02-18 12:05 ` [PATCH v2 0/2] Removal of RTE_MBUF_REFCNT Ananyev, Konstantin
[not found] ` <2601191342CEEE43887BDE71AB977258213EF713-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-02-23 18:36 ` 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=54E47107.3020103@6wind.com \
--to=olivier.matz-pdr9zngts4eavxtiumwx3w@public.gmane.org \
--cc=bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=dev-VfR2kkLFssw@public.gmane.org \
--cc=konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@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.