> On Apr 25, 2018, at 1:28 AM, Olivier Matz <olivier.m...@6wind.com> wrote: > > Hi Yongseok, > > On Tue, Apr 24, 2018 at 06:02:44PM +0200, Olivier Matz wrote: >>>> @@ -688,14 +704,33 @@ rte_mbuf_to_baddr(struct rte_mbuf *md) >>>> } >>>> /** >>>> + * Returns TRUE if given mbuf is cloned by mbuf indirection, or FALSE >>>> + * otherwise. >>>> + * >>>> + * If a mbuf has its data in another mbuf and references it by mbuf >>>> + * indirection, this mbuf can be defined as a cloned mbuf. >>>> + */ >>>> +#define RTE_MBUF_CLONED(mb) ((mb)->ol_flags & IND_ATTACHED_MBUF) >>>> + >>>> +/** >>>> * Returns TRUE if given mbuf is indirect, or FALSE otherwise. >>>> */ >>>> -#define RTE_MBUF_INDIRECT(mb) ((mb)->ol_flags & IND_ATTACHED_MBUF) >>>> +#define RTE_MBUF_INDIRECT(mb) RTE_MBUF_CLONED(mb) >>> >>> It is still confusing that INDIRECT != !DIRECT. >>> May be we have no good options right now, but I'd suggest to at least >>> deprecate >>> RTE_MBUF_INDIRECT() and completely remove it in the next release. >> >> Agree. I may have missed something, but is my previous suggestion >> not doable? >> >> - direct = embeds its own data (and indirect = !direct) >> - clone (or another name) = data is another mbuf >> - extbuf = data is in an external buffer > > Any comment about this option?
I liked your idea, so I defined RTE_MBUF_CLONED() and wanted to deprecate RTE_MBUF_INDIRECT() in the coming release. But RTE_MBUF_DIRECT() can't be (!RTE_MBUF_INDIRECT()) because it will logically include RTE_MBUF_HAS_EXTBUF(). I'm not sure I understand you correctly. Can you please give me more guidelines so that I can take you idea? Thanks, Yongseok
