From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 637EAA0C47; Tue, 15 Jun 2021 15:05:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2854D4067A; Tue, 15 Jun 2021 15:05:39 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id 2CEA240140 for ; Tue, 15 Jun 2021 15:05:36 +0200 (CEST) IronPort-SDR: 39ASa7rP4B7ez6aOM6ThKjkObXAJmts5l1Nl9Gz7CUgSRhm9f9/9ESVHI5xMtfwiwzqZDcOq50 uKlstwjSY8qw== X-IronPort-AV: E=McAfee;i="6200,9189,10015"; a="291617028" X-IronPort-AV: E=Sophos;i="5.83,275,1616482800"; d="scan'208";a="291617028" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jun 2021 06:05:35 -0700 IronPort-SDR: BPAouTso6gPOw8gX2KlpnXacKEW2LD57lGtmukKCHqNfr+OpUwDLN/bQMGpGJQflxDoitfznYr /9OPYujndRIA== X-IronPort-AV: E=Sophos;i="5.83,275,1616482800"; d="scan'208";a="484464279" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.31.246]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 15 Jun 2021 06:05:33 -0700 Date: Tue, 15 Jun 2021 14:05:29 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Olivier Matz , Matan Azrad , Shahaf Shuler , Viacheslav Ovsiienko , dev@dpdk.org Message-ID: References: <98CBD80474FA8B44BF855DF32C47DC35C6185B@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C6185B@smartserver.smartshare.dk> Subject: Re: [dpdk-dev] mbuf next field belongs in the first cacheline X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Jun 15, 2021 at 02:16:27PM +0200, Morten Brørup wrote: > MBUF and MLX5 maintainers, > > I'm picking up an old discussion, which you might consider pursuing. Feel free to ignore, if you consider this discussion irrelevant or already closed and done with. > > The Techboard has previously discussed the organization of the mbuf fields. Ref: http://mails.dpdk.org/archives/dev/2020-November/191859.html > > It was concluded that there was no measured performance difference if the "pool" or "next" field was in the first cacheline, so it was decided to put the "pool" field in the first cacheline. And further optimizing the mbuf field organization could be reconsidered later. > > I have been looking at it. In theory it should not be required to touch the "pool" field at RX. But the "next" field must be written for segmented packets. > Question: are there cases where segmented packets are used, but they aren't big packets, and so need a high packets-per-second value? The thinking when designing the mbuf was that any application which could handle high packets per second for medium/small packets would be fine with a few extra cycles penalty for big ones, since the overall PPS for the driver would be much lower. /Bruce