From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from proxy.6wind.com (host.76.145.23.62.rev.coltfrance.com [62.23.145.76]) by dpdk.org (Postfix) with ESMTP id 4ED273237 for ; Wed, 3 Feb 2016 18:23:52 +0100 (CET) Received: from [10.16.0.195] (unknown [10.16.0.195]) by proxy.6wind.com (Postfix) with ESMTP id BCCF5284C2; Wed, 3 Feb 2016 18:23:08 +0100 (CET) Message-ID: <56B23799.4020600@6wind.com> Date: Wed, 03 Feb 2016 18:23:37 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Stephen Hemminger , Bruce Richardson References: <1436485068-30609-1-git-send-email-stephen@networkplumber.org> <1436485068-30609-3-git-send-email-stephen@networkplumber.org> <20150710093217.GB10556@bricha3-MOBL3> <20150710084356.37d22b65@urahara> In-Reply-To: <20150710084356.37d22b65@urahara> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Stephen Hemminger Subject: Re: [dpdk-dev] [PATCH 2/2] mbuf: make sure userdata is initialized 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, 03 Feb 2016 17:23:52 -0000 Hi, On 07/10/2015 05:43 PM, Stephen Hemminger wrote: > On Fri, 10 Jul 2015 10:32:17 +0100 > Bruce Richardson wrote: > >> On Thu, Jul 09, 2015 at 04:37:48PM -0700, Stephen Hemminger wrote: >>> From: Stephen Hemminger >>> >>> For applications that use m->userdata the initialization can >>> be a signficant (10%) performance penalty. >>> >>> Rather than taking the cache penalty of initializing userdata >>> in the receive handling, do it in the place where mbuf is >>> already cache hot and being setup. >> >> Should the management of the userdata field not be the responsibility of the >> app itself, rather than having the PMD manage it? If the PMD does manage the >> userdata field, I would suggest taking the approach of having the field cleared >> by the mbuf library on free, rather than on RX. > > The problem with that is m->userdata is that when the application > gets the mbuf, touching the userdata field causes false cache > sharing and we see a significant performance drop. Internally the > userdata field is only used for few special cases and 0/NULL > is used to indicate that no metadata is present. Agree with Bruce. The management of this field is the responsibility of the application. Also, this field is located in the second cache line, and we should avoid to touch it in the rx functions. We had the same discussion for the next field in this thread: http://dpdk.org/ml/archives/dev/2015-June/019182.html A pure-app solution would be to set it to NULL in: - your mempool object init function - in your mbuf_free() function, before calling rte_pktmbuf_free() - before passing the mbuf to the tx driver But a better solution in dpdk is probably what Bruce suggests. Regards, Olivier