From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id E2BFB16E for ; Sat, 8 Jul 2017 22:36:09 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 76D7E2082E; Sat, 8 Jul 2017 16:36:09 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 08 Jul 2017 16:36:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=A5YD//+oUrV6z7U zfEe0ftg70j71OW/yuKYgJpsiH7A=; b=Gt+zGeFHcyAa9ZBchTvhQi58vDlXe+N tnW3FI2YEPbnSXX5DJLWks/W+BHoHMj9qNUpifv+JpUG5qfTY6+dk5Ze6WoFTa9/ cwyEGOYqTxHeHxWNL8j25lp4hkuc1eOGcEQIqfiEqPy/OvHVfPaDThzfgpJRJU/W GsIcoQdH7I5A= 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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=A5YD//+oUrV6z7UzfEe0ftg70j71OW/yuKYgJpsiH7A=; b=BCjrNzjq hzAjF+ZYeLrPJ9fomtcn8mmdzNOjG5NMh9r/R+KK7yCXEnX8Q7ez/NBgmJXh6+e+ Uhn2ZmCy2GL/2p97nHOATWMrxa1YTsGx2bWvaiVQIps2CQ+K/SKIGm3zHkDVrAaS HfDiHpppwQeZVveLkk79CkRIsCPULfuHPfLLy+aoUT1vWjt8aM89Iyy6T6vlT76+ GvoB9z5E5znFvG4C7qJ4rttmAI9Cz3BDdAV5nZZ2xm07ePQ+jLuFsosIXyZtjKWd IQeAAkFuZEAnY6e/3xu3mkbk5nvJ5BJmFBI0kPXzWGiPkBcBfRZIifaI9ZeZUNfD Uo1kcDHfwENqcQ== X-ME-Sender: X-Sasl-enc: Tzr/WkicRlmo1zR6yvpk94r+umTjf7bk0mD5dcZ7zBO6 1499546169 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2E3637E70C; Sat, 8 Jul 2017 16:36:09 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, Olivier Matz Date: Sat, 08 Jul 2017 22:36:08 +0200 Message-ID: <6567149.GEPADMWmoG@xps> In-Reply-To: <20170608110607.30887c26@platinum> References: <20170608110607.30887c26@platinum> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] advice to pmd maintainters: do not touch mbuf initialized fields X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 20:36:10 -0000 08/06/2017 11:06, Olivier Matz: > Hi, > > In the structure reorganization patchset [1], some work was done > to ensure that the values of the following fields are always initialized > for mbuf that are inside the mbuf pool (not yet allocated). > > In other words, calling rte_mbuf_raw_alloc() or rte_mempool_get() return > mbufs that are initialized as following: > > m->next = NULL > m->nb_segs = 1 > m->refcnt = 1 > > This property can be used in the Rx path of PMDs where the mbuf > structure is filled from the hardware descriptors: the initialization of > these fields can be skipped to gain few cycles per packet, and to avoid > an access to the second cache line (m->next) before it is prefetched. > > It is advised to do this optimization in the PMDs for this reason, and > also because we could want to move some of these fields to the second > mbuf cache line in the future: accessing them in the Rx path would cost. > > This work has already been done at several places: > > http://dpdk.org/browse/dpdk/commit/?id=ebb7bcabb > http://dpdk.org/browse/next/dpdk-next-net/commit/?id=e211a7569 > http://dpdk.org/browse/next/dpdk-next-net/commit/?id=a37cf9005 > http://dpdk.org/browse/next/dpdk-next-net/commit/?id=fb83a23ee > ... > > Feel free to ask if you have any question. Please Ferruh, could you check which drivers are not yet updated regarding this optimization? Thanks