From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 741E27CEE for ; Wed, 25 Apr 2018 16:45:51 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 3580180007D; Wed, 25 Apr 2018 14:45:49 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 25 Apr 2018 15:45:38 +0100 To: Yongseok Koh , Olivier Matz CC: , , , , , , Thomas Monjalon References: <20180310012532.15809-1-yskoh@mellanox.com> <20180424013854.33749-1-yskoh@mellanox.com> <934e714e-3cba-7f5d-9fcf-4f96611d758f@solarflare.com> <20180424160244.bggifhilvadxcjb2@neon> <20180424191538.exjgzoif4odhndew@neon> <20180424233442.GC88208@yongseok-MBP.local> From: Andrew Rybchenko Message-ID: <6f520eb1-8ce4-16bc-49b5-ddd25f73f330@solarflare.com> Date: Wed, 25 Apr 2018 17:45:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180424233442.GC88208@yongseok-MBP.local> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23804.003 X-TM-AS-Result: No--12.400000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1524667550-Unt2Kf9qQzVt Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v4 1/2] mbuf: support attaching external buffer to mbuf X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 14:45:51 -0000 On 04/25/2018 02:34 AM, Yongseok Koh wrote: > On Tue, Apr 24, 2018 at 09:15:38PM +0200, Olivier Matz wrote: >> On Tue, Apr 24, 2018 at 09:21:00PM +0300, Andrew Rybchenko wrote: >>> On 04/24/2018 07:02 PM, Olivier Matz wrote: >>>>>> + m->ol_flags |= EXT_ATTACHED_MBUF; >>>>>> + m->shinfo = shinfo; >>>>>> + >>>>>> + rte_mbuf_ext_refcnt_set(shinfo, 1); >>>>> Why is assignment used here? Cannot we attach extbuf already attached to >>>>> other mbuf? >>>> In rte_pktmbuf_attach(), this is true. That's not illogical to >>>> keep the same approach here. Maybe an assert could be added? > Like I described in the doc, intention is to attach external buffer by > _attach_extbuf() for the first time and _attach() is just for additional mbuf > attachment. Will add an assert. Not sure that I understand. How should the second chunk with shared shinfo of the huge buffer be attached to a new mbuf? >>> Other option is to have shinfo per small buf plus reference counter >>> per huge buf (which is decremented when small buf reference counter >>> becomes zero and free callback is executed). I guess it is assumed above. >>> My fear is that it is too much reference counters: >>>  1. mbuf reference counter >>>  2. small buf reference counter >>>  3. huge buf reference counter >>> May be it is possible use (1) for (2) as well? >> I would prefer to have only 2 reference counters, one in the mbuf >> and one in the shinfo. > Good discussion. It should be a design decision by user. > > In my use-case, it would be a good idea to make all the mbufs in a same chunk > point to the same shared info in the head of the chunk and reset the refcnt of > shinfo to the total number of slices in the chunk. > > +--+----+----+--------------+----+--------------+---+- - - > |global |head|mbuf1 data |head|mbuf2 data | | > | shinfo|room| |room| | | > +--+----+----+--------------+----+--------------+---+- - - I don't understand how it can be achieved using proposed API. Andrew.