From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.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)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-type:content-transfer-encoding;
 bh=9CQqgNQxgh5mLGsGlSIFpHJ/P/m6+cA87jrgWQLl8eE=;
 b=NFQxot67ry+c/1XWNlu6YdrbAOu1IEkkpln8dXC/DyoPDQhmDlB2/0Kua0+HGQUEAa
 UgiaUQZjb49D9gCxQ/6XkeMoCGJrrx+8XuQ2gAMGXjYymiJGP4ceAAO8r/4l9zkg1fon
 GHQLLPPrJUc+is/Yzftw4qpN8LczNIzRORvhAmA9MPGqKHJKosbKquTL664EP0zxRJ2+
 LPHulrcazGOCEWtMYAWCiThStku7blobJuZfe1ru4xbPJf943eCJRLggccRpVSZG4K2D
 ReCNQKAadvMeaotKIvFE38q/U3JLq4k0EzvGG2raPYyX58iU0uLz487x+1TCwr+DPu4m
 3uIg==
X-Gm-Message-State: ALoCoQl8MbfPDDPdMTca5M1Zq9D1PLxvaYZAEG9pnc0F5y9zeVspXO6wnBG4JkadoxeFd61zB+Pd
X-Received: by 10.70.130.144 with SMTP id oe16mr43849117pdb.116.1436543032834; 
 Fri, 10 Jul 2015 08:43:52 -0700 (PDT)
Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net.
 [50.53.82.155])
 by smtp.gmail.com with ESMTPSA id xd9sm9996807pab.6.2015.07.10.08.43.52
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 10 Jul 2015 08:43:52 -0700 (PDT)
Date: Fri, 10 Jul 2015 08:43:56 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Bruce Richardson <bruce.richardson@intel.com>
Message-ID: <20150710084356.37d22b65@urahara>
In-Reply-To: <20150710093217.GB10556@bricha3-MOBL3>
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>
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 <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>
X-List-Received-Date: Fri, 10 Jul 2015 15:43:53 -0000

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.