From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yongseok Koh <yskoh@mellanox.com>
Subject: Re: [PATCH v4 1/2] mbuf: support attaching external
 buffer to mbuf
Date: Wed, 25 Apr 2018 09:08:05 +0000
Message-ID: <915EB643-1009-4016-9E18-7DAB43FFDC9F@mellanox.com>
References: <20180310012532.15809-1-yskoh@mellanox.com>
 <20180424013854.33749-1-yskoh@mellanox.com>
 <934e714e-3cba-7f5d-9fcf-4f96611d758f@solarflare.com>
 <20180424160244.bggifhilvadxcjb2@neon> <20180425082821.ktbzjrnxbo4nhqgg@neon>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Andrew Rybchenko <arybchenko@solarflare.com>, "wenzhuo.lu@intel.com"
 <wenzhuo.lu@intel.com>, "jingjing.wu@intel.com" <jingjing.wu@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>, "konstantin.ananyev@intel.com"
 <konstantin.ananyev@intel.com>, Adrien Mazarguil
 <adrien.mazarguil@6wind.com>, =?iso-8859-1?Q?N=E9lio_Laranjeiro?=
 <nelio.laranjeiro@6wind.com>
To: Olivier Matz <olivier.matz@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from EUR01-HE1-obe.outbound.protection.outlook.com
 (mail-he1eur01on0055.outbound.protection.outlook.com [104.47.0.55])
 by dpdk.org (Postfix) with ESMTP id 9A0F01DBE
 for <dev@dpdk.org>; Wed, 25 Apr 2018 11:08:07 +0200 (CEST)
In-Reply-To: <20180425082821.ktbzjrnxbo4nhqgg@neon>
Content-Language: en-US
Content-ID: <C2A9EDED7F6AE34B86B580C35C88D6AD@eurprd05.prod.outlook.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>



> On Apr 25, 2018, at 1:28 AM, Olivier Matz <olivier.matz@6wind.com> wrote:
>=20
> Hi Yongseok,
>=20
> 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)
>>>=20
>>> It is still confusing that INDIRECT !=3D !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.
>>=20
>> Agree. I may have missed something, but is my previous suggestion
>> not doable?
>>=20
>> - direct =3D embeds its own data      (and indirect =3D !direct)
>> - clone (or another name) =3D data is another mbuf
>> - extbuf =3D data is in an external buffer
>=20
> 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_EXTBU=
F().
I'm not sure I understand you correctly.

Can you please give me more guidelines so that I can take you idea?

Thanks,
Yongseok=