From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 7E0312E8B for ; Thu, 2 Jun 2016 09:36:36 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id a136so216163604wme.0 for ; Thu, 02 Jun 2016 00:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XS9x/OjS/+0w38d2bFArgCO75nTwRC7izA+g2tcYp4c=; b=JSXgnvQevkogYJ7bIof6ySV+bezsh/zhcp4H2Jswf0IFe1f4ZSyn0ovdRpAZFY96ll 6NeSeP42WsD/IQ6+C+zcapIQz0/AI8m+LENBtrG+Dz2ZvKB6l0EXWrMPQPG3t/VF+ZJu nfSOOvh09YTV5tvbueBjGXyT+eQgVZKTlEu8AbEgzw38qElzPAitP7+MBIxxLF6+rFXr JMiv3pojULjwlopMideZoErEnWGEXZm8KTmbmjwR+LC6PeXt5A6yCcZ4NmwnDNP2fGVg R4qMSdtChRXoIr3rmWpLiX2rWF7Y/oJdTQ88b8wuKmKLsHUTG9iuLggC+YlrGXEm5F8W awrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XS9x/OjS/+0w38d2bFArgCO75nTwRC7izA+g2tcYp4c=; b=TZroct8wRdULDoF5kJaMaw98m+aQWcQClHKbPI+QtkYNtnSjeL+7Lw7RH+SAwX/kuJ 6obMRqAioHBSTjxxPUU9iNab+rNHbToRgMQeiA30gXJ2ptVjtun0qtxViCjFD+kpn5QI fe9RpWkfrW5ELJVX5LJPLb1x/YhoAiKzolbaW5dKNgRLflZbxVuMWxgOfHAqlFdc8DIH l2aer3RSxVQVuCd9jW2iHIVnapG6vksRNZOe8S64ZabM0gjOULr5Lzyg0c9YzAoW0eEG 0Obc3YmulrE0/mP3TOrUjAjICr8ivT0GB/wB8PUg/db/MlqoGurihUwOAvlVGBezbJtB S6dQ== X-Gm-Message-State: ALyK8tIayr66YQBWve/vf/6LGH9Fv7mTjS1C5fqYHWdGOUhGDBspq7HmTF8AFiNgFUxt87KY X-Received: by 10.28.73.198 with SMTP id w189mr7585616wma.32.1464852996239; Thu, 02 Jun 2016 00:36:36 -0700 (PDT) Received: from [137.194.56.56] (eduroam-0-56.enst.fr. [137.194.56.56]) by smtp.gmail.com with ESMTPSA id d7sm39117692wmd.11.2016.06.02.00.36.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 00:36:35 -0700 (PDT) To: Jerin Jacob References: <1464101442-10501-1-git-send-email-jerin.jacob@caviumnetworks.com> <1464250025-9191-1-git-send-email-jerin.jacob@caviumnetworks.com> <574BFD97.2010505@6wind.com> <20160531125822.GA10995@localhost.localdomain> <574DFC9A.2050304@6wind.com> <20160601070018.GA26922@localhost.localdomain> Cc: dev@dpdk.org, thomas.monjalon@6wind.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com From: Olivier MATZ Message-ID: <574FE202.2060306@6wind.com> Date: Thu, 2 Jun 2016 09:36:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160601070018.GA26922@localhost.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] mempool: replace c memcpy code semantics with optimized rte_memcpy 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, 02 Jun 2016 07:36:36 -0000 Hi Jerin, On 06/01/2016 09:00 AM, Jerin Jacob wrote: > On Tue, May 31, 2016 at 11:05:30PM +0200, Olivier MATZ wrote: >> Today, the objects pointers are reversed only in the get(). It means >> that this code: >> >> rte_mempool_get_bulk(mp, table, 4); >> for (i = 0; i < 4; i++) >> printf("obj = %p\n", t[i]); >> rte_mempool_put_bulk(mp, table, 4); >> >> >> printf("-----\n"); >> rte_mempool_get_bulk(mp, table, 4); >> for (i = 0; i < 4; i++) >> printf("obj = %p\n", t[i]); >> rte_mempool_put_bulk(mp, table, 4); >> >> prints: >> >> addr1 >> addr2 >> addr3 >> addr4 >> ----- >> addr4 >> addr3 >> addr2 >> addr1 >> >> Which is quite strange. > > IMO, It is the expected LIFO behavior. Right ? > > What is not expected is the following, which is the case after change. Or Am I > missing something here? > > addr1 > addr2 > addr3 > addr4 > ----- > addr1 > addr2 > addr3 > addr4 > >> >> I don't think it would be an issue to replace the loop by a >> rte_memcpy(), it may increase the copy speed and it will be >> more coherent with the put(). >> I think the LIFO behavior should occur on a per-bulk basis. I mean, it should behave like in the exemplaes below: // pool cache is in state X obj1 = mempool_get(mp) obj2 = mempool_get(mp) mempool_put(mp, obj2) mempool_put(mp, obj1) // pool cache is back in state X // pool cache is in state X bulk1 = mempool_get_bulk(mp, 16) bulk2 = mempool_get_bulk(mp, 16) mempool_put_bulk(mp, bulk2, 16) mempool_put_bulk(mp, bulk1, 16) // pool cache is back in state X Note that today it's not the case for bulks, since object addresses are reversed only in get(), we are not back in the original state. I don't really see the advantage of this. Removing the reversing may accelerate the cache in case of bulk get, I think. Regards, Olivier