From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH 1/5] mbuf: fix clone support when application uses private mbuf data Date: Thu, 26 Mar 2015 16:30:23 +0100 Message-ID: <5514260F.3000003@6wind.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Bruce Richardson Return-path: In-Reply-To: <20150326133520.GA4944@bricha3-MOBL3> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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