From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH 2/2] mbuf: make sure userdata is initialized
Date: Fri, 10 Jul 2015 08:43:56 -0700
Message-ID: <20150710084356.37d22b65@urahara>
References: <1436485068-30609-1-git-send-email-stephen@networkplumber.org>
 <1436485068-30609-3-git-send-email-stephen@networkplumber.org>
 <20150710093217.GB10556@bricha3-MOBL3>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, Stephen Hemminger <shemming@brocade.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com
 [209.85.220.52]) by dpdk.org (Postfix) with ESMTP id 70F3EC400
 for <dev@dpdk.org>; Fri, 10 Jul 2015 17:43:53 +0200 (CEST)
Received: by pabvl15 with SMTP id vl15so169960781pab.1
 for <dev@dpdk.org>; Fri, 10 Jul 2015 08:43:52 -0700 (PDT)
In-Reply-To: <20150710093217.GB10556@bricha3-MOBL3>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Fri, 10 Jul 2015 10:32:17 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:

> On Thu, Jul 09, 2015 at 04:37:48PM -0700, Stephen Hemminger wrote:
> > From: Stephen Hemminger <shemming@brocade.com>
> > 
> > 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.