From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yongseok Koh Subject: Re: [PATCH v4 1/2] mbuf: support attaching external buffer to mbuf Date: Wed, 25 Apr 2018 09:19:32 +0000 Message-ID: <22EF1A3B-ECFF-4A4F-955D-43F992B4F135@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> <915EB643-1009-4016-9E18-7DAB43FFDC9F@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Andrew Rybchenko , Wenzhuo Lu , Jingjing Wu , "dev@dpdk.org" , Konstantin Ananyev , "Adrien Mazarguil" , =?iso-8859-1?Q?N=E9lio_Laranjeiro?= To: Olivier Matz Return-path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0049.outbound.protection.outlook.com [104.47.0.49]) by dpdk.org (Postfix) with ESMTP id 818FACF3 for ; Wed, 25 Apr 2018 11:19:33 +0200 (CEST) In-Reply-To: <915EB643-1009-4016-9E18-7DAB43FFDC9F@mellanox.com> Content-Language: en-US Content-ID: <60CEA32DB6B5A14F96CDA3EF34794866@eurprd05.prod.outlook.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Apr 25, 2018, at 2:08 AM, Yongseok Koh wrote: >> On Apr 25, 2018, at 1:28 AM, Olivier Matz 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 FALS= E >>>>> + * 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? >=20 > 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_EXT= BUF(). > I'm not sure I understand you correctly. >=20 > Can you please give me more guidelines so that I can take you idea? Maybe, did you mean the following? Looks like doable but RTE_MBUF_DIRECT() can't logically mean 'mbuf embeds its own data', right? #define RTE_MBUF_INDIRECT(mb) ((mb)->ol_flags & IND_ATTACHED_MBUF) #define RTE_MBUF_DIRECT(mb) (!RTE_MBUF_INDIRECT(mb)) #define RTE_MBUF_HAS_EXTBUF(mb) ((mb)->ol_flags & EXT_ATTACHED_MBUF) #define RTE_MBUF_CLONED(mb) ((mb)->ol_flags & IND_ATTACHED_MBUF) [...] @@ -1327,7 +1572,7 @@ rte_pktmbuf_prefree_seg(struct rte_mbuf *m) =20 if (likely(rte_mbuf_refcnt_read(m) =3D=3D 1)) { =20 - if (RTE_MBUF_INDIRECT(m)) + if (RTE_MBUF_INDIRECT(m) || RTE_MBUF_HAS_EXTBUF(m)) rte_pktmbuf_detach(m); =20 if (m->next !=3D NULL) { @@ -1339,7 +1584,7 @@ rte_pktmbuf_prefree_seg(struct rte_mbuf *m) =20 } else if (__rte_mbuf_refcnt_update(m, -1) =3D=3D 0) { =20 - if (RTE_MBUF_INDIRECT(m)) + if (RTE_MBUF_INDIRECT(m) || RTE_MBUF_HAS_EXTBUF(m)) rte_pktmbuf_detach(m); =20 if (m->next !=3D NULL) { Thanks, Yongseok