From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by dpdk.org (Postfix) with ESMTP id 68363AF7F for ; Thu, 25 Sep 2014 04:12:09 +0200 (CEST) Received: from ALA-HCB.corp.ad.wrs.com (ala-hcb.corp.ad.wrs.com [147.11.189.41]) by mail.windriver.com (8.14.9/8.14.5) with ESMTP id s8P2IKGL012921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 19:18:20 -0700 (PDT) Received: from ALA-MBB.corp.ad.wrs.com ([169.254.1.18]) by ALA-HCB.corp.ad.wrs.com ([147.11.189.41]) with mapi id 14.03.0174.001; Wed, 24 Sep 2014 19:18:20 -0700 From: "Wiles, Roger Keith" To: Hiroshi Shimamoto Thread-Topic: [dpdk-dev] [memnic PATCH 7/7] pmd: split calling mbuf free Thread-Index: Ac/NlUxI5nJ3s/X2TP+cHArf+IKJdAKsHXwAAAFpgQAAEz55gAACUMSA Date: Thu, 25 Sep 2014 02:18:19 +0000 Message-ID: <8A06C158-C9BC-4166-B031-E8A4E90D2F93@windriver.com> References: <7F861DC0615E0C47A872E6F3C5FCDDBD011A99C6@BPXM14GP.gisp.nec.co.jp> <16805029.uPnEfVsb0t@xps13> <7F861DC0615E0C47A872E6F3C5FCDDBD02ADA02E@BPXM14GP.gisp.nec.co.jp> In-Reply-To: <7F861DC0615E0C47A872E6F3C5FCDDBD02ADA02E@BPXM14GP.gisp.nec.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.25.40.166] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <7AB3D5991CB5A44A845B5A277FD6FB9E@local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" , Hayato Momma Subject: Re: [dpdk-dev] [memnic PATCH 7/7] pmd: split calling mbuf free X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 02:12:10 -0000 On Sep 24, 2014, at 8:12 PM, Hiroshi Shimamoto = wrote: > Hi Thomas, Keith, >=20 >> Subject: Re: [dpdk-dev] [memnic PATCH 7/7] pmd: split calling mbuf free >>=20 >>=20 >> On Sep 24, 2014, at 10:20 AM, Thomas Monjalon wrote: >>=20 >>> 2014-09-11 07:52, Hiroshi Shimamoto: >>>> @@ -408,9 +408,9 @@ retry: >>>>=20 >>>> rte_compiler_barrier(); >>>> p->status =3D MEMNIC_PKT_ST_FILLED; >>>> - >>>> - rte_pktmbuf_free(tx_pkts[nr]); >>>> } >>>> + for (i =3D 0; i < nr; i++) >>>> + rte_pktmbuf_free(tx_pkts[i]); >>>>=20 >>>> /* stats */ >>>> st->opackets +=3D pkts; >>>>=20 >>>=20 >>> You are bursting mbuf freeing. Why title is about "split=1B$B!I=1B(B? >=20 > I thought that in this patch splits main loop operations to putting conte= nt and > freeing mbuf, then took work "split", but I see "burst mbuf freeing" is p= referable. >=20 >>=20 >> Maybe this should be a new API as in rte_pktmbuf_bulk_free(tx_pkts, nr);= ?? >> This would remove the loop in the application and I know I have done the= same thing for Pktgen too. >=20 > Good point, yes, I'm thinking that having new API like rte_pktmbuf_(alloc= |free)_bulk() > is good to reduce TLS access and gain performance. > I put that on my stack, but haven't had a time yet. >=20 > Do you have any plan to do such thing? I do not have any plans, but the alloc would be good too. >=20 > thanks, > Hiroshi >=20 >>>=20 >>> -- >>> Thomas >>=20 >> Keith Wiles, Principal Technologist with CTO office, Wind River mobile 9= 72-213-5533 Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-= 213-5533