From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH] rte_mbuf: scattered pktmbufs freeing optimization Date: Wed, 04 Mar 2015 09:54:10 +0100 Message-ID: <54F6C832.4070505@6wind.com> References: <1424992506-20484-1-git-send-email-vadim.suraev@gmail.com> <2601191342CEEE43887BDE71AB977258213F2C93@irsmsx105.ger.corp.intel.com> <54F06F3A.40401@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Vadim Suraev Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi Vadim, On 02/27/2015 06:09 PM, Vadim Suraev wrote: > >Indeed, this function looks useful, and I also have a work in progress > >on this topic, but currently it is not well tested. > I'm sorry, I didn't know. I'll not interfere with my patch)) That not what I wanted to say :) You are very welcome with your patch, I just wanted to notify that I am also working in the same area and that's why I listed the things I'm currently working on. > >About the inlining, I have no objection now, although Stephen may be > >right. I think we can consider un-inline some functions, based on > >performance measurements. > I've also noticed in many cases it makes no difference. Seems to be some > trade-off. > > >- clarify the difference between raw_alloc/raw_free and > > mempool_get/mempool_put: For instance, I think that the reference > > counter initialization should be managed by rte_pktmbuf_reset() like > > the rest of the fields, therefore raw_alloc/raw_free could be replaced > It looks useful to me since not all of the fields are used in every > particular application so > if the allocation is decoupled from reset, one can save some cycles. Yes, this is also a trade-off between maintainability and speed, and speed is probably the first constraint for the dpdk. But maybe we can find an alternative that is both fast and maintainable. Thanks, Olivier