From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 455EA568F for ; Wed, 4 Mar 2015 09:54:10 +0100 (CET) Received: by wghb13 with SMTP id b13so45095792wgh.0 for ; Wed, 04 Mar 2015 00:54:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RpvB6XQXQIslwcO72bJSrWCMLyELYelCV5hl1X2105c=; b=KCGrgsNHKMqO47i11K/Khh5TxK3DHvOXTsQLi4wZGpHkIxL1xSwCgSQr8Wz6vVUSM5 32UaUTzYnZSgJNZhPuADah46wS83ioJg1xTj0Z4Ily0O08Kx5fuQQO0VVGWNnJIbdxdj r83gyOrwebJoiHLi/3UYl5ObzaFnS64DFjza9Bp9aaxiaobvjmpcY/+9xHsQ/evneUqc RMd0hgAm6bC3gE2MCT6jltgYiUYgkKEBI8Ejt2+00eaLC0q+HUmJ2UypaK+8n2VPA/DP 6k7kndtravX+FsvGVQc2Hbyu8qZ6W2tbVtOVER8hXCkFYLljIDSPfI0NEsEYkJm0NnSg sFkA== X-Gm-Message-State: ALoCoQnQGpYN70jYo6KPPU9o00uRHnt/6wN6xvbAYbdRv28X5cTGe7p3yCTeKufrcDU5/5ZUPnqM X-Received: by 10.195.13.168 with SMTP id ez8mr5863885wjd.30.1425459250036; Wed, 04 Mar 2015 00:54:10 -0800 (PST) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id v9sm23313906wib.0.2015.03.04.00.54.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 00:54:09 -0800 (PST) Message-ID: <54F6C832.4070505@6wind.com> Date: Wed, 04 Mar 2015 09:54:10 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Vadim Suraev References: <1424992506-20484-1-git-send-email-vadim.suraev@gmail.com> <2601191342CEEE43887BDE71AB977258213F2C93@irsmsx105.ger.corp.intel.com> <54F06F3A.40401@6wind.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] rte_mbuf: scattered pktmbufs freeing optimization 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: Wed, 04 Mar 2015 08:54:10 -0000 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