From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 735E4A0527;
	Mon,  9 Nov 2020 12:25:06 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id BAEA05A62;
	Mon,  9 Nov 2020 12:25:04 +0100 (CET)
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by dpdk.org (Postfix) with ESMTP id D23E65953;
 Mon,  9 Nov 2020 12:25:00 +0100 (CET)
IronPort-SDR: 4Y7g2HgpgFKUuxE0YOmH9kD4lxdG59AmU8Brf3gG46ta0Jmc/3ClWMr2abbuYcfCbQJYdiVZfj
 NaiZ6d+JffGQ==
X-IronPort-AV: E=McAfee;i="6000,8403,9799"; a="231417434"
X-IronPort-AV: E=Sophos;i="5.77,463,1596524400"; d="scan'208";a="231417434"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga004.jf.intel.com ([10.7.209.38])
 by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 09 Nov 2020 03:24:58 -0800
IronPort-SDR: cijfzBh6UsC3xrVLDfMOpYzDNa9vfMc+w5zgM82GNs+n/nQL0hWMdmxg9eLq6SyVhWO0BP9366
 2Y3oA8ktmvDQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.77,463,1596524400"; d="scan'208";a="472933857"
Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82])
 by orsmga004.jf.intel.com with ESMTP; 09 Nov 2020 03:24:58 -0800
Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by
 fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.1713.5; Mon, 9 Nov 2020 03:24:57 -0800
Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by
 fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.1713.5; Mon, 9 Nov 2020 03:24:57 -0800
Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by
 fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5
 via Frontend Transport; Mon, 9 Nov 2020 03:24:57 -0800
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.173)
 by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.1.1713.5; Mon, 9 Nov 2020 03:24:57 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=d2S86dl64KrhibswM/W95E0sViXrno2tZdb6F+Q3CDpJ78iQ3oKLayqmjhicjnVnvbuJI4mn2L7MW40XyZ0nXhU8jrj9EjmF5Mmn2ztklxTwywAIx9W7PehG93cZVe8ipDhqCLx2fyVLQCcDP0oPwV6kJXwQsVE5VhjpmQdE7rVJKBRVBW16Ou52JA7D+KUk24A/02v9O0uB9YBDH48q+zAeB0sIMxHbW3+5zPJv3xI6g9e/8W6JZaNCiNrcjbihE3TPBxb6G1m4YNXUqXbxcxlrXg7ZDDFZNK256n7ZUBE9T9CqZvb2ot6/KqWuxwumrEFDf5sewXvo4I67AHfwSQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JVPK3J8uAQrnmHlK4RXGeA5CtpQNznCCuw3gSnOHTXk=;
 b=i/cws7eu8uoIN4NhpbIASr5MY6u/oWzCPSKEDjMfiUDzwICWHuYmoPVFP3ZZCMSVWgzF9aN4v3BOKFFBx5tOLtTaNFqszgNas6jVL6xbxgYlpeTwev8W375xsaXbtbGNQ7d3oCA8Qi7jOAiGfVHyRStc+kcLwi00ncAIWozA3RM8tulHH3w0IS43P6Q3yZvTrNt1ONesAPU5GJ0MTWHvqKfjm+nTPV3Du8mNvkAYd4bydSFf3l+DW4cUx5fRYvQmDEPVe3UDrAc47kUzBW1q5Ho8eBTo3eUOW26pu+RT2KDmUWCJ2UmF20X/mpixw5uhyHSXFT+Qj7mD8P2z+j6SNQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
 dkim=pass header.d=intel.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; 
 s=selector2-intel-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JVPK3J8uAQrnmHlK4RXGeA5CtpQNznCCuw3gSnOHTXk=;
 b=aAAOzhJAuNXkJNyiiGSFvz7+CO7JbFmXOpEm08EparPf64RsEL9sLrlh/1qQNRPU9ZR7xbztagCjKvcWxpWXzpvZ+9k0NZzaraXsu+Iy/LfWN0qDdX8B9mXkK9pFORuAFUSPCZJfqtzA0/Mwq83oknSxPGf2HK48kfiROOe0EWU=
Received: from DM6PR11MB3308.namprd11.prod.outlook.com (2603:10b6:5:d::22) by
 DM5PR1101MB2124.namprd11.prod.outlook.com (2603:10b6:4:55::12) with
 Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3541.21; Mon, 9 Nov 2020 11:24:55 +0000
Received: from DM6PR11MB3308.namprd11.prod.outlook.com
 ([fe80::fd2d:9bbb:599e:72dd]) by DM6PR11MB3308.namprd11.prod.outlook.com
 ([fe80::fd2d:9bbb:599e:72dd%6]) with mapi id 15.20.3541.021; Mon, 9 Nov 2020
 11:24:55 +0000
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>,
 =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>
CC: Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org>,
 "david.marchand@redhat.com" <david.marchand@redhat.com>, "Yigit, Ferruh"
 <ferruh.yigit@intel.com>, "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
 "andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
 "viacheslavo@nvidia.com" <viacheslavo@nvidia.com>,
 "ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>,
 "jerinj@marvell.com" <jerinj@marvell.com>, "hemant.agrawal@nxp.com"
 <hemant.agrawal@nxp.com>, Ray Kinsella <mdr@ashroe.eu>, Neil Horman
 <nhorman@tuxdriver.com>, Nithin Dabilpuram <ndabilpuram@marvell.com>, "Kiran
 Kumar K" <kirankumark@marvell.com>, "techboard@dpdk.org" <techboard@dpdk.org>
Thread-Topic: [PATCH 1/1] mbuf: move pool pointer in first half
Thread-Index: AQHWtSP/uGyncSiUVECsGul9I7S6/am9BUmAgAKRBACAAATGYIAADgLg
Date: Mon, 9 Nov 2020 11:24:55 +0000
Message-ID: <DM6PR11MB33085E031B2922B3401436A99AEA0@DM6PR11MB3308.namprd11.prod.outlook.com>
References: <20201107155306.463148-1-thomas@monjalon.net>
 <98CBD80474FA8B44BF855DF32C47DC35C61404@smartserver.smartshare.dk>
 <20201109100838.GC831@bricha3-MOBL.ger.corp.intel.com>
 <DM6PR11MB3308005609F8FFC3A39F27B39AEA0@DM6PR11MB3308.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB3308005609F8FFC3A39F27B39AEA0@DM6PR11MB3308.namprd11.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.5.1.3
authentication-results: intel.com; dkim=none (message not signed)
 header.d=none;intel.com; dmarc=none action=none header.from=intel.com;
x-originating-ip: [46.7.39.127]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c4b49c08-026d-452b-adf0-08d884a21580
x-ms-traffictypediagnostic: DM5PR1101MB2124:
x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM5PR1101MB2124203C990A4968583851969AEA0@DM5PR1101MB2124.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Pe/i2S3h2+jgoYbBRyEOziJBS0zHHCmzEPsJNxh31W0NZ4+iZakqhP7xGt8jX6eoF0WQCxbiohFyk9CmKekoUUidmbLOpdI7RjODHjpnkjcrOCbdNixql4rYX4JiZJLMmVgnX69O2R8dCb2zgWi/UXIlH1c3tqOKgYitQpdvwjvZzAYsvpSbmCxtcj89zvdzdZZ0JXkeD+cxyIFwkIfII21wSsH4yvwAdxCQxmiLepAizL6T2s8qbeEPLMDWRJ+2FwxU/dzObwE/p0bkd6mYgWcAL2nV3gebgjk3FjJiFit50+NwGuePr4TS80azL8zvi2hoOaifML0zG3Ds06k22w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:DM6PR11MB3308.namprd11.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(4636009)(136003)(396003)(366004)(376002)(346002)(39860400002)(71200400001)(4326008)(54906003)(7696005)(2940100002)(6506007)(7416002)(9686003)(110136005)(186003)(26005)(5660300002)(52536014)(55016002)(8936002)(2906002)(66476007)(86362001)(316002)(478600001)(66556008)(8676002)(64756008)(33656002)(76116006)(66946007)(66446008);
 DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: 2uvkyu1hsPjBRoHz0UZDWvrZ9HRWmehTAWKT1UhsLUc38TfHZ7bYRB/TqVlP0OED/LThVS/jYqyICjesumGvOCFo/gFw0zmyxOFBzP9eEuBl206ytflJRVFADT2W9/SEYmt1Hzc/nVB09Uqoyn42XKp6iEUxP6wUVTxHdg8oUqQJ6m+Ap8cwFdQmKLk5u9UrlpQNQR3x/y7+iLQhWBUV9K/d+rruFfEabjetWfBXTf5QgYzXpciZOTsWVKVqgh5KgDhIezaHV/S/5igwrfvXP22O9nOyBdA6UAnJXA0g2x3KIJ256ziiB4n3+Wg2pWCtkmGBqaRfUrd0Mtz9mLc4vznM1AEjb5PQYRqc9kMV/ArLnuY4f5I5CZShQscUr1IyhoTI0NqcT9TTQtGcVg/E2vH2+L5M3j7qTEj/oGTdvXnIl3xE0/SbtjSPUVRkS5Tf8zIvb3wLh+N5CDO/khyqF5Jm+keV8m3S3miahj6NH243EjeVOBvCRJ7Nm2VQ//y0TYrULLA3I9wSNGkvPLkpbXBqrPJsUMo0BjoCXwvvHNRgmynQHpbUTA5T0/8VUk5hhaWT9tRjbSio9Rcxs5swdw1OTHzIq2m0vjTZoP5vL+xzJnmLsEX3fjZcRJNxnmvaexapLMvd+6/rxwuLPPa3+A==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3308.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c4b49c08-026d-452b-adf0-08d884a21580
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 11:24:55.2368 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZQyIXiyj4TRrXYLwobAo4EgagzoXVMwZzx+bqlMyIaarxXTkmFi1iofn5iB8zzXfeEjq3/mtWql6ymAjitMvolp0dEAV8p+zIWN0fjWwQ5w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2124
X-OriginatorOrg: intel.com
Subject: Re: [dpdk-dev] [PATCH 1/1] mbuf: move pool pointer in first half
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > Sent: Saturday, November 7, 2020 4:53 PM
> > > >
> > > > The mempool pointer in the mbuf struct is moved
> > > > from the second to the first half.
> > > > It should increase performance on most systems having 64-byte cache=
 line,
> > > > i.e. mbuf is split in two cache lines.
> > >
> > > Perhaps with the #define DEV_TX_OFFLOAD_MBUF_FAST_FREE mentioned by K=
onstantin, it might be better moving m->next instead, at
> > least for applications with the opportunity to set this flag (e.g. appl=
ications with only one mbuf pool).
> > >
> > > Unfortunately, the information about the DEV_TX_OFFLOAD_MBUF_FAST_FRE=
E flag came to light after the techboard meeting, and I
> > don't have any benchmarks to support this suggestion, so I guess it's h=
ard to change the techboard's decision to move the pool pointer.
> > >
> >
> > The thing with FAST_FREE is that it doesn't just indicate that there is
> > only one mbuf pool, but rather that none of the packets are chained mbu=
fs
> > either.
>=20
> Hmm, wonder where such assumption comes from?
> There is nothing about forbidding chained mbufs in rte_ethdev.h right now=
:
> #define DEV_TX_OFFLOAD_MBUF_FAST_FREE   0x00010000
> /**< Device supports optimization for fast release of mbufs.
>  *   When set application must guarantee that per-queue all mbufs comes f=
rom
>  *   the same mempool and has refcnt =3D 1.
>  */
>=20
> > Therefore, the flag applies equally to both next and pool pointers
> > for optimization. [And the flag should perhaps be two flags!]
> >
>=20
> I think what Morten means here:
> For FAST_FREE PMD can store pool pointer somewhere in its queue metadata
> and doesn't need to read it from the mbuf.
> So if we move next to first line - mbuf_free code-path for FAST_FREE case=
 can
> avoid touching  second cache line in the mbuf.

Just as a different thought:
if we move 'next' to the first cache line, can we get rid of 'nb_segs' fiel=
d completely?