From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 1A6C3A04DD;
	Tue, 26 Nov 2019 14:45:36 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 83EDF4C93;
	Tue, 26 Nov 2019 14:45:35 +0100 (CET)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com
 [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id EF4914C90;
 Tue, 26 Nov 2019 14:45:33 +0100 (CET)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.nyi.internal (Postfix) with ESMTP id 77FC522949;
 Tue, 26 Nov 2019 08:45:33 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Tue, 26 Nov 2019 08:45:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=mesmtp;
 bh=chaVkMmb1XQyJOZtNNysvtDfGdGmYhIRBtYeAyuucL0=; b=fmZs6AEHfhgM
 atZIMRVfe8FIX+Mmn5mlNoo+my67V1Ixm2IhvWka3KZiAtbGaPI29t3A7j9IZKlv
 QbnH+nJ0EQaetIJz8yhTKGSbr5fmY83fTdJQNF7FfmoAsbS2pAhO5CgAvwEqwVZU
 GbXF/fAMCPR/lVxLMW45nxH/Jv3W31Y=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm1; bh=chaVkMmb1XQyJOZtNNysvtDfGdGmYhIRBtYeAyuuc
 L0=; b=ZeMMNMIXz1/pbeK+RJf+2YourCOVPOJKZJXZHtOMPDPR3GnRcMSm1v2k7
 0bA0rK6vpAmUntHbQDKmmrr/GGb3rvHt6j5OaLC5ofTyCPginvSUGmLb8gRIYRVs
 1bNdDJskYs6itTuaFIushoo/qCP2jQ2DvT59csaiQxbkeGujOAS6c4vdXVA+Ou6a
 QUn0fUqhWlAsEnVGz4DS/59Wlw3jEOTTHxc/Rlc3ovdxAJj6njPZ9qF0/WPjN45d
 suFUoMftD9vP9d4t9UCkjb2Jllxd3WI4UTES76jZOoaDm4fe3pCV6oVS9QElWQId
 lx0UhE7mWU9Lnfr7HC3wDsrxR9E1g==
X-ME-Sender: <xms:fCzdXYrJj7NhFmZa1_X96e6x1zG1uy3d2cNDpPnGU4-nmN4EKVargg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeifedgheejucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
 shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf
 hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh
 ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:fCzdXaSRBKzXrUcZq3VwZ8rCtJh_vU_PqRaUMIaQcuLonh_vAPDpvA>
 <xmx:fCzdXfXxonPash730iLLZv9cUGCDxJUh8x838LjgoPqNfJgnH0epgg>
 <xmx:fCzdXeRzH9WQ-w2A7_5L2WOdUmEr-OjeKuXzLOBuSNX1KK7gPkWHrQ>
 <xmx:fSzdXSngQYzIKgHgjC5uC3ZxiXz6prFIdJvT4fEHeQni-4bpS5iPdA>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 059808005A;
 Tue, 26 Nov 2019 08:45:31 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: "Xueming(Steven) Li" <xuemingl@mellanox.com>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>, Asaf Penso <asafp@mellanox.com>,
 "stable@dpdk.org" <stable@dpdk.org>,
 "david.marchand@redhat.com" <david.marchand@redhat.com>
Date: Tue, 26 Nov 2019 14:45:30 +0100
Message-ID: <4234059.lpkmD0fh1P@xps>
In-Reply-To: <DB6PR05MB3190A2E4D0C964F590C30724AC450@DB6PR05MB3190.eurprd05.prod.outlook.com>
References: <1574346302-1263-1-git-send-email-xuemingl@mellanox.com>
 <1842633.FO3dX0cGTE@xps>
 <DB6PR05MB3190A2E4D0C964F590C30724AC450@DB6PR05MB3190.eurprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH] malloc: fix memory element size in case of
	padding
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

26/11/2019 14:39, Xueming(Steven) Li:
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Tuesday, November 26, 2019 9:30 PM
> > To: Burakov, Anatoly <anatoly.burakov@intel.com>
> > Cc: Xueming(Steven) Li <xuemingl@mellanox.com>; dev@dpdk.org; Asaf
> > Penso <asafp@mellanox.com>; stable@dpdk.org;
> > david.marchand@redhat.com
> > Subject: Re: [dpdk-dev] [PATCH] malloc: fix memory element size in case of
> > padding
> > 
> > 26/11/2019 13:57, Burakov, Anatoly:
> > > On 25-Nov-19 11:24 PM, Thomas Monjalon wrote:
> > > > 21/11/2019 16:14, Burakov, Anatoly:
> > > >> On 21-Nov-19 2:25 PM, Xueming Li wrote:
> > > >>> This patch fixes wrong inner memory element size when joining two
> > > >>> elements.
> > > >>>
> > > >>> Fixes: af75078fece3 ("first public release")
> > > >>> Cc: stable@dpdk.org
> > > >>>
> > > >>> Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> > > >>> ---
> > > >>> --- a/lib/librte_eal/common/malloc_elem.c
> > > >>> +++ b/lib/librte_eal/common/malloc_elem.c
> > > >>> @@ -487,6 +487,10 @@ join_elem(struct malloc_elem *elem1, struct
> > malloc_elem *elem2)
> > > >>>    	else
> > > >>>    		elem1->heap->last = elem1;
> > > >>>    	elem1->next = next;
> > > >>> +	if (elem1->pad) {
> > > >>> +		struct malloc_elem *inner = RTE_PTR_ADD(elem1, elem1-
> > >pad);
> > > >>> +		inner->size = elem1->size - elem1->pad;
> > > >>> +	}
> > > >>>    }
> > > >>
> > > >> Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > > >
> > > > I don't understand this patch.
> > > > The variable inner is never used.
> > > > What am I missing?
> > > >
> > >
> > > For padded elements, malloc element has two headers - the "outer"
> > > header with empty space after it, and the "inner" header, after which
> > > the user memory actually starts. This makes it so that, when joining
> > > elements, if the outer element had a pad, we also update the inner
> > element size to match.
> > 
> > Where the variable "inner" is used in this function?
> > 
> Rte_realloc, inner size is used to copy data.

I still don't get it. Am I missing half of the patch?
Please give explicit line number.