From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by dpdk.org (Postfix) with ESMTP id 9344B5A7A for ; Wed, 15 Jul 2015 12:10:50 +0200 (CEST) Received: by wibud3 with SMTP id ud3so36310668wib.0 for ; Wed, 15 Jul 2015 03:10:50 -0700 (PDT) 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=+4xVdvpd9RKrc5hUY4VeyfwO0ZGnaAgLSn4/ykEc0+0=; b=QQAYdovYb/QXkexMEb2VwIOx4osPHQK2QXwHjEWvxzkwPZHzJcNJyuETePHfZDegaE N48RnbEblHdv04P0hN71izpuBa0n9s6uw4UcFRCuPFNjKNc9jSXVN5nzwuUOLAJMe2Ul L1iz3LgOhdlqy4MSKvdtwwTQaMBGpsLI+e3oTzBRsq9eMImh6O3uYjgW0gF+mQsUTPiT ZxI+va53lPIsi+O/fgm3ROS9/yyoxW6Ecgg8eUqqekFZRksWp0YKz/1ZI38tasHzY2Z0 D9rmS76zQYLQWUmA22KXNvLiQx/4tdwT3dUN8xmXqtET9MmIaIdoH0WIeMvfUu+n7exh un9w== X-Gm-Message-State: ALoCoQmRKz9cLh0h/wh9yx0BDwf7KtPK422vIlroDTLRQ4kBCPDT4wLD5CUF9uhx+T6dw9VB+bNZ X-Received: by 10.180.23.69 with SMTP id k5mr14925823wif.3.1436955050401; Wed, 15 Jul 2015 03:10:50 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.151.210]) by smtp.gmail.com with ESMTPSA id k16sm7157688wjr.7.2015.07.15.03.10.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jul 2015 03:10:49 -0700 (PDT) Message-ID: <55A631A3.1000309@6wind.com> Date: Wed, 15 Jul 2015 12:10:43 +0200 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, 15 Jul 2015 10:10:50 -0000 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. > I agree with Bruce: the userdata field is in the second cache line, and we should avoid touching it in rx path. Resetting it in mbuf_free() may not be the solution either: in tx path, the mbufs are freed when we want to send a new mbuf on the hw ring entry, and the mbuf may not be in the cache anymore. I don't understand why doing it in the application induces a performance drop compared to the PMD. What do you mean by false cache sharing?