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 3F794A0C47; Tue, 15 Jun 2021 15:40:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B2C434067A; Tue, 15 Jun 2021 15:40:55 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 399A840140 for ; Tue, 15 Jun 2021 15:40:54 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2021 15:40:50 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C6185E@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] mbuf next field belongs in the first cacheline Thread-Index: Addh5yWBMdKe5hCaT7elQ3v0iQ12SQAAUAOQ References: <98CBD80474FA8B44BF855DF32C47DC35C6185B@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" Cc: "Olivier Matz" , "Matan Azrad" , "Shahaf Shuler" , "Viacheslav Ovsiienko" , 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" > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > Sent: Tuesday, 15 June 2021 15.05 >=20 > On Tue, Jun 15, 2021 at 02:16:27PM +0200, Morten Br=F8rup 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. Always good with a reality check! :-) I recall a proposal from NVIDIA that introduced a feature to split RX = packets into multiple small segments from a list of mbuf pools; = basically a variant of "header split". Here it is: = https://patchwork.dpdk.org/project/dpdk/list/?series=3D13070&state=3D%2A&= archive=3Dboth I don't know if swapping "next" and "pool" fields would make a = performance difference if the RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT is being = used. Otherwise, you are correct: The performance gain is mostly theoretical. So in reality, it would be a very big change for an insignificant = improvement. It's mainly the principle that annoys me: The DPDK documentation = mentions that the mbuf structure is designed for the second cache line = not to be touched by RX. If that is not the bearing principle anymore, = the documentation needs to be updated.