From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 5C59F2BB9 for ; Thu, 8 Jun 2017 11:06:10 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id x70so73025706wme.0 for ; Thu, 08 Jun 2017 02:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=vMo06Lc52QZxXsXPQYya0nCNKXg5yCVrgkukV8rO0K8=; b=OxP4w92glY/cy6vl7igA9OokPAtHy12lSz+hRpRyNWMuebTakVXKEheKWP5YtgMkso gUlOI//xl6y3VN0dNhkmvW0G6Dyx2lz2Ttgi3hn0e3OUGH3/Cj5fDs7ZyZ2rthj6b67S FjrvuAEOBaXQIcCJJ+jjrw2P+GjxB1c4trfVj1RMscIKSL2XwQpqyZ26WMwhL9ijL+J4 Ne88CzHe4IE3TyskeT1o7HktEBAAftQnDGSpiEo4Vvyp5z6ZeLgJU5/67ISVpeOjwqs9 poc9vktwqe6qsbXxoN5lYsIFDYoW0WM3wUT6RkDIPxEuqKm3WwEMmccqqHd3lJkTfYv+ 3pMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=vMo06Lc52QZxXsXPQYya0nCNKXg5yCVrgkukV8rO0K8=; b=mgH2h990kD6wfVKrsWyZiaBsbMxcpfp6CyRoSdz9K+fcgaIYQEbVb4LujKu7ttfxrQ HxTMvsUYsMZYHEHxAACM9RAgtY4q+eNXh79i+HnNEf53lb50JW6nemhqRLEGF593lzc6 VVuPtY2vwFibXKx9ha6+8OTFBuTiA0Nzv5cEnVLqpsDuxAq5fDrgzyRqPzbD3+0mN+iD Fw/5RfaTjimzNKA4UgX7XdVYZO240/r9UOwlTyXQrlpUbIUiYOpqhylf/5oG5rkYWkaY 7IIGOGuNjRPFAPKSNBErU7vGeyvDU4rDVXDZfj+QRAES/qBbVtRS1E3eU8X4U0gdXCnl sjVw== X-Gm-Message-State: AODbwcBKSjqnL8o36m/3q+677R/lfaSPcpm98+dUwr4TY+CIXLsqAp+o hPjnayeiGSKt0BD5Of0= X-Received: by 10.28.13.1 with SMTP id 1mr2766678wmn.12.1496912769655; Thu, 08 Jun 2017 02:06:09 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id p5sm5248003wma.17.2017.06.08.02.06.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Jun 2017 02:06:09 -0700 (PDT) Date: Thu, 8 Jun 2017 11:06:07 +0200 From: Olivier Matz To: dev@dpdk.org Cc: Ferruh Yigit Message-ID: <20170608110607.30887c26@platinum> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [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: Thu, 08 Jun 2017 09:06:10 -0000 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. Thanks, Olivier [1] http://dpdk.org/ml/archives/dev/2017-April/063081.html