From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by dpdk.org (Postfix) with ESMTP id 6B9A91396 for ; Thu, 26 Mar 2015 16:30:22 +0100 (CET) Received: by wiaa2 with SMTP id a2so27771713wia.0 for ; Thu, 26 Mar 2015 08:30:22 -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=a4Me4a76MsjOq7ZFzMQs2oV+KEuK9D1PZ8cdcHzNP2Y=; b=c9iT7zj6W0yvRZ0yjtSR0w7bF3CYLg2FwXb7UTNnI3fdK+zLsIeVjvrGwEShyEWbZ3 aSon/W6quSRFrjhGd76C/TsWusFHuX/96ReokOeBBHT8buyZFMHGD5nqaOsv2Nd2x5db UPyaY8+GBlJy/1T9ih3QUSuM8L0G11WEL/UWUsEz0AQpupl1ArGcbzFv28z6TiV9XOzh lqgnJ9YvXMGpwxj96W/ngW+mhu1Ke7zirILIvLAKnlErAxJ2ZiedKWYWFDaFmS4aQhVv EzjJok0zXlglcgHMknhdFYbaqCQLfJusB07ZgRmFqxJ4WqDquCcZYV544FCzfxnqb8Mj McQw== X-Gm-Message-State: ALoCoQmcPKDze/FdbSVJWywOdnOsZsWmuGLvWTLXFT/Zw1MwLqLCoNWdsU2yeDq02ob8u4vNY9iJ X-Received: by 10.194.108.137 with SMTP id hk9mr28225886wjb.112.1427383822229; Thu, 26 Mar 2015 08:30:22 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id u16sm8888512wjr.5.2015.03.26.08.30.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 08:30:21 -0700 (PDT) Message-ID: <5514260F.3000003@6wind.com> Date: Thu, 26 Mar 2015 16:30:23 +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: Bruce Richardson References: <1427302838-8285-1-git-send-email-olivier.matz@6wind.com> <1427302838-8285-2-git-send-email-olivier.matz@6wind.com> <20150326133520.GA4944@bricha3-MOBL3> In-Reply-To: <20150326133520.GA4944@bricha3-MOBL3> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 1/5] mbuf: fix clone support when application uses private mbuf data 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: Thu, 26 Mar 2015 15:30:22 -0000 Hi Bruce, On 03/26/2015 02:35 PM, Bruce Richardson wrote: > On Wed, Mar 25, 2015 at 06:00:34PM +0100, Olivier Matz wrote: >> Add a new private_size field in mbuf structure that should >> be initialized at mbuf pool creation. This field contains the >> size of the application private data in mbufs. >> >> Introduce new static inline functions rte_mbuf_from_baddr() >> and rte_mbuf_to_baddr() to replace the existing macros, which >> take the private size in account when attaching and detaching >> mbufs. >> >> [...] > > Why does this new field need to go in cache line zero? New fields should go > by default in cache line 1, where there is more space, unless there is a compelling > reason not to. Space in cache line 0 is at a premium. You are right, having this in the second cache line makes more sense, I'll change that in the v2. Thanks for your review, Olivier