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 59ABDA0032; Fri, 14 Jan 2022 12:52:02 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 163F840DDD; Fri, 14 Jan 2022 12:52:02 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id AB4F640C35 for ; Fri, 14 Jan 2022 12:51:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1642161119; x=1673697119; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7GYg8z07wfEpv5kkla9W2Y5o0MfrF7IsuLy9rwaZaaY=; b=SUuOTHflAyfsMihUNQ1K0n8JSY9UqkDP9NpAg7c0LA0u86FcuM9YLLYM 6WgHzeEdEfupTvLQi8jNUL4r0pdnF9uLU9BXYqRYFMxVbtIkIHUA7kX7t tuH3u8dTXMc12bEhfpg6DBloMLO6eZuBkuZpl5dNOETGP4R9l9o5e9Kuc vKTJ6AGAM7og70UaPA6VQVrvBWrUHpZL4yc/53vM5Nd8NwCdviM60El8B PwfGrPKdy4UQfRV97u/S3kvoedMdjGi8WW5kam3Wcjbd7F9m6AwciEOdh dRN4GZczMmv1cJBsqhbJxhMRWYxX95U//WcUBxDsqJh/KM7srpu3yAQlL Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10226"; a="224919875" X-IronPort-AV: E=Sophos;i="5.88,288,1635231600"; d="scan'208";a="224919875" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2022 03:51:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,288,1635231600"; d="scan'208";a="624302129" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga004.jf.intel.com with ESMTP; 14 Jan 2022 03:51:58 -0800 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 14 Jan 2022 03:51:57 -0800 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 14 Jan 2022 03:51:57 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20 via Frontend Transport; Fri, 14 Jan 2022 03:51:57 -0800 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.104) 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.2308.20; Fri, 14 Jan 2022 03:51:57 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=APipVfLAGeoUIGEzvb1J87MfLYLdTDhqVf9mWsntK5q2u/J0bux+IqQBBmkU849+keHq2INfAUxdtcVo5p+NUiB11VlDuOCWwg9NNiVQHM9erXtVDin2v5XnjbPe39vWpSrrlZ3uO3Cby32/IzbYd4ZZsy3zqrH6uCGLk9tkIn0SAqxh/FkZStnqjaWAn9P2e2q9+SQRueFrFnpNE/FW2mR5yL5bT2VaYGdKWPb5s/sP3BcDItqqOKmM4+dJGntXYqY6sUglBqH4QBt0EZiMtS9kyOUWOCmHwFlbINIrHX/o50MB9g8iAds1X11Gp8OnGGLRAjdVd6qI+nS3u9IJyQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oT/FrpXYr7R3KYZFQagjzPaYyWzhCH3sznjyA9Eer8g=; b=nB5WmTwZ2sRdmHkYPxRUXJocf1nkArTkhxqEx2MQg1hXr5Qv5ScBPlHNR9oukEe8UTvAn/yObe+Q5lQLQuecZfDyOi/Z02rOT/D5it5HunxIMN7aRGfidn6JKM0JsrHO6I96m2YdFIVXqo25rBZAm8k5QjrIlpVGnY1QB+7+0sJisOfbPtYGJS4rqCF6K7ZVDIrbG0FbK7heDfVipqNN8YNhkTJdqyDt2tem8Yydyt9As0aG4LFaRB6i6SO6Wc4M7WXk+JFftCUhZtE3w1JdrPIfrJCdD7+/x3Zj2mXPUBjQfnctKZLLtL0Vcjwv73I9xyvLjGlVvLfzT/NcVNYoyw== 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 Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM6PR11MB2892.namprd11.prod.outlook.com (2603:10b6:5:61::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.9; Fri, 14 Jan 2022 11:51:53 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::7de4:731c:cee2:49c2]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::7de4:731c:cee2:49c2%3]) with mapi id 15.20.4888.012; Fri, 14 Jan 2022 11:51:53 +0000 From: "Ananyev, Konstantin" To: =?iso-8859-1?Q?Morten_Br=F8rup?= , "Richardson, Bruce" CC: Jan Viktorin , Ruifeng Wang , David Christensen , "dev@dpdk.org" Subject: RE: rte_memcpy alignment Thread-Topic: rte_memcpy alignment Thread-Index: AdgJJKuLTRnjdnFpTB+l82T17Hz8JgAAf5GAAAF+hAAAAYyb4AAAuizwAAGUpTA= Date: Fri, 14 Jan 2022 11:51:53 +0000 Message-ID: References: <98CBD80474FA8B44BF855DF32C47DC35D86E00@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D86E02@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D86E03@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86E03@smartserver.smartshare.dk> 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.6.200.16 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52333fd3-17aa-4933-f01c-08d9d754420b x-ms-traffictypediagnostic: DM6PR11MB2892:EE_ x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: egt/5lfXoxyUOBQ1gS70ycuRZUqSqHUEli3b3IQWq3Qwi3iPQ1IkCDpxzClo8rJk/x+zZTJJpIVcWvM54UJ7WG1fi8zFHmK+Vac5jz+iriG8mNDsfg3JVCrF/DheIZAHl2cFwv/M8X5PbeK6hRlOtfef+6KWTMH5hXIZrDMQ+WZWf2rVD2kYIdR+OqRDOR+Twq6mwtARSv8yl8CsAe2RyIV/OkQhZqUbRSuj8DqgBcQCtLeoOtwEjietwJTCm8fyKGdf18sAeXXAQufiCFji+2RDV1SdJaBaQPyOM4T28c9FNo11/Bfri8iwfMTWBlw8AV33wGr2ikrRN4VfTgQ6Ib6K7NobR1SMx2lXVNx6HmicFHtLJIi8Ph3jmiTtuXWDH8r/00l1HB6RsHcIsEhJBm6QLwtcPSJ/i6GxXjIeyxO5qQY/srGWfylX7mGb4m4mRJhL63uhp2JX1Rw/4xb8zseT3QGwrKRAoeBM+zOJp+gaC+YIhlxauMvkzyqBQ2FWW4JkdXXkkUJ3T0DfzDc5Qj9P4QTbh0fC3eK6kr6xrelzzLNvjEmTd4cLG2HuMkZDHDAt1mzbms8mP6lRDCq+cQDRdhVivS0vxnj5AHltwkUhOfLUxA31e2yF4ifG1WCU/zltAJI0kgZ96JDaB/850CLFOel7MuE92wbG+Bx7ZRpe8gDPMKzERZIat0jPct4qtR1S5N0U6M62GRSPAyvgDQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4491.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(66476007)(2906002)(66556008)(66946007)(9686003)(86362001)(66446008)(64756008)(26005)(186003)(71200400001)(122000001)(6506007)(52536014)(66574015)(5660300002)(7116003)(83380400001)(76116006)(4326008)(55016003)(8936002)(38100700002)(8676002)(38070700005)(7696005)(110136005)(54906003)(316002)(33656002)(82960400001)(6636002)(508600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Fohw1GzqvY3nUAaOZ2vgSX1cWYLnRKD9MO9appmEK4L/Ni9mkO3X6+mMgf?= =?iso-8859-1?Q?vaLfGdWlzv35gi0h677NUVJ1jJCJ18mpdyT68OGcgkNaHTAtVh9V5FhydD?= =?iso-8859-1?Q?BsjUPXTwc7WO75ektlPC6rfvxfDax0WS1reRgjYEip+hn9QT0kyGr4dvzD?= =?iso-8859-1?Q?Pi0JP8z39VBKDTTxMQCX3JsQ8Tn/z2EnBzGhI19tYbntCfyzCcR955V93a?= =?iso-8859-1?Q?Bz+jdHMP5jBNnPyX62QSwL9xkZf1qYrZg7zeHf6CNEDkAT19wBjawhZxOL?= =?iso-8859-1?Q?of3XHrUl/+yamKu6axXH3qiSX5W1L53x6E1FazKGwZUQ2fCLIqesoTSyKD?= =?iso-8859-1?Q?qbDT4f01ZXM8yLRnaW5j1SwlwE+YiKMaB/sviYz+Uhz8Y4fj497jK7UXNp?= =?iso-8859-1?Q?C96PHF/Y3qtgusCcfU3xthcivHtZnpDDTU6Gh0Xpe3wDeR2X5Qv/mVGTYe?= =?iso-8859-1?Q?K7MgjF+gGT5/0dAqhRl4bnCTeHjaBfOBHpzJarrRyMUnT/geCSSUNjz9Ah?= =?iso-8859-1?Q?pT/B8ib+6e6wADCj3JcZcjzZAawmYfHkBoTgATiOoztFo9Jo0GO+Ps6k6G?= =?iso-8859-1?Q?WnksZEtUIbH+z5hG0Swpx0nvRvKsqzlJDJ6AgVZA6RlGGuOLmbBGam3hKj?= =?iso-8859-1?Q?U3PKCEH/+Io3ix93rLiQhqA4HktCPTUbj7uMFK6DYVkAzQi60HNKq4Ofpv?= =?iso-8859-1?Q?ayPzKjQUQJtL9SecO5a5DJoHN+jzw+LE+fVG5G4N5yomxJEc2azeh+Jl9N?= =?iso-8859-1?Q?MTohZchKZ2CBWgbF2NzGU11dF1TCF436vCr63LLpftk7XG1ecRs89hTAuo?= =?iso-8859-1?Q?CsDN1hD+Dp0Xsh8ezC3SZlr7D7ClkJ0k8fN7JBfvylDCBaEIctJYiyz7cl?= =?iso-8859-1?Q?/TifdAYupT4K8cAc2ccAknqF0tKpYlZW9mBEkeExx7ukhLOSQ14lex0zvi?= =?iso-8859-1?Q?fVnY3hZ0Yg1Rd0omb0wn3RiRVH6t+hoBc8jj2GQNezufZTc57NiUJ4D++q?= =?iso-8859-1?Q?UWVze28Lan0HTwyTsVet0HI2zVCSzM4TXf50MwbqCGhADUjWP+xAOHb4GU?= =?iso-8859-1?Q?LNXYyygfSH1YYodxjEuYMNW+ZwyhjICnP0NmGSGWOyIwS5zUYlGGuCaaMJ?= =?iso-8859-1?Q?KbfDuDReNGUfMNGPWxlVctVEBdim8FjoCtDxNGkoriK08oLLgfb27W0SS2?= =?iso-8859-1?Q?UdxOICCQqEQ7ZdqkTVa3sNXAWTuMGk5awMn9x8139+GtDLZG0qv0F/Xc6E?= =?iso-8859-1?Q?0PN6zWEsKElMhurSG4AKxS8ZKiZZNvNKP7IkGNRMaz1ZBa1Kbu3WVzLrqa?= =?iso-8859-1?Q?RE6iV0iyVHEYeWbOOeYJpKG/jDovBEuZlI1lyZ9RcvWgeLZTRnu1ukonGW?= =?iso-8859-1?Q?gjhMvHr3Rtn5n5VAmf3gfqegiVzin+FQeZfgmlwXJ8d7mIzR9ptNBxqJrG?= =?iso-8859-1?Q?lkUD8xsiUcRb+sHimPasjpbBz54QDEiRgGfDKil+Gs5AVkr1K1NTl76ZnU?= =?iso-8859-1?Q?uLcw8PYpaLrGrA4Q9IJOn32uZW1RWQzPbdPj/c10Ten1M2VpxNg0RftxVQ?= =?iso-8859-1?Q?O/gQXfNWVajH1kYB4aAo4ipW51tZlCSH4n8SpXnLyvC8Uj5VoDHLl5w6ph?= =?iso-8859-1?Q?9Eodgky4F3xwtzFvpW3f6docrdCESGpzcR6VrBsNn8bwUS5yGDSKoBOkW/?= =?iso-8859-1?Q?M5tcGwZpej18QUy9fcHWOInFVx5tUxPBChLW9Qcr2QkMmoQCdt7SUf5R4t?= =?iso-8859-1?Q?J0TQ=3D=3D?= 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: DM6PR11MB4491.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52333fd3-17aa-4933-f01c-08d9d754420b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2022 11:51:53.4001 (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: NHnqlmH/Qb2fXfs0vGARxozGX5x3lSTwr3cAk5NhRibSI4q/DJaX6idwWGP180FrptXPwawpLiMhD+3oN9dAqyUczxktA9G4tJfAiMp0B98= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2892 X-OriginatorOrg: intel.com 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 >=20 > > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com] > > Sent: Friday, 14 January 2022 11.54 > > > > > From: Morten Br=F8rup > > > Sent: Friday, January 14, 2022 9:54 AM > > > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > Sent: Friday, 14 January 2022 10.11 > > > > > > > > On Fri, Jan 14, 2022 at 09:56:50AM +0100, Morten Br=F8rup wrote: > > > > > Dear ARM/POWER/x86 maintainers, > > > > > > > > > > The architecture specific rte_memcpy() provides optimized > > variants to > > > > copy aligned data. However, the alignment requirements depend on > > the > > > > hardware architecture, and there is no common definition for the > > > > alignment. > > > > > > > > > > DPDK provides __rte_cache_aligned for cache optimization > > purposes, > > > > with architecture specific values. Would you consider providing an > > > > __rte_memcpy_aligned for rte_memcpy() optimization purposes? > > > > > > > > > > Or should I just use __rte_cache_aligned, although it is > > overkill? > > > > > > > > > > > > > > > Specifically, I am working on a mempool optimization where the > > objs > > > > field in the rte_mempool_cache structure may benefit by being > > aligned > > > > for optimized rte_memcpy(). > > > > > > > > > For me the difficulty with such a memcpy proposal - apart from > > probably > > > > adding to the amount of memcpy code we have to maintain - is the > > > > specific meaning > > > > of what "aligned" in the memcpy case. Unlike for a struct > > definition, > > > > the > > > > possible meaning of aligned in memcpy could be: > > > > * the source address is aligned > > > > * the destination address is aligned > > > > * both source and destination is aligned > > > > * both source and destination are aligned and the copy length is a > > > > multiple > > > > of the alignment length > > > > * the data is aligned to a cacheline boundary > > > > * the data is aligned to the largest load-store size for system > > > > * the data is aligned to the boundary suitable for the copy size, > > e.g. > > > > memcpy of 8 bytes is 8-byte aligned etc. > > > > > > > > Can you clarify a bit more on your own thinking here? Personally, I > > am > > > > a > > > > little dubious of the benefit of general memcpy optimization, but I > > do > > > > believe that for specific usecases there is value is having their > > own > > > > copy > > > > operations which include constraints for that specific usecase. For > > > > example, in the AVX-512 ice/i40e PMD code, we fold the memcpy from > > the > > > > mempool cache into the descriptor rearm function because we know we > > can > > > > always do 64-byte loads and stores, and also because we know that > > for > > > > each > > > > load in the copy, we can reuse the data just after storing it > > (giving > > > > good > > > > perf boost). Perhaps something similar could work for you in your > > > > mempool > > > > optimization. > > > > > > > > /Bruce > > > > > > I'm going to copy array of pointers, specifically the 'objs' array in > > the rte_mempool_cache structure. > > > > > > The 'objs' array starts at byte 24, which is only 8 byte aligned. So > > it always fails the ALIGNMENT_MASK test in the x86 specific > > > rte_memcpy(), and thus cannot ever use the optimized > > rte_memcpy_aligned() function to copy the array, but will use the > > > rte_memcpy_generic() function. > > > > > > If the 'objs' array was optimally aligned, and the other array that > > is being copied to/from is also optimally aligned, rte_memcpy() would > > use > > > the optimized rte_memcpy_aligned() function. > > > > > > Please also note that the value of ALIGNMENT_MASK depends on which > > vector instruction set DPDK is being compiled with. > > > > > > The other CPU architectures have similar stuff in their rte_memcpy() > > implementations, and their alignment requirements are also different. > > > > > > Please also note that rte_memcpy() becomes even more optimized when > > the size of the memcpy() operation is known at compile time. > > > > If the size is known at compile time, rte_memcpy() probably an overkill > > - modern compilers usually generate fast enough code for such cases. > > > > > > > > So I am asking for a public #define __rte_memcpy_aligned I can use to > > meet the alignment requirements for optimal rte_memcpy(). > > > > Even on x86 ALIGNMENT_MASK could have different values (15/31/63) > > depending on ISA. > > So probably 64 as 'generic' one is the safest bet. >=20 > I will use cache line alignment for now. >=20 > > Though I wonder do we really need such micro-optimizations here? >=20 > I'm not sure, but since it's available, I will use it. :-) >=20 > And the mempool get/put functions are very frequently used, so I think we= should squeeze out every bit of performance we can. Well it wouldn't come for free, right? You would probably need to do some extra checking and add handling for non-= aligned cases. Anyway, will probably just wait for the patch before going into further dis= cussions :) >=20 > > Would it be such huge difference if you call rte_memcpy_aligned() > > instead of rte_memcpy()? >=20 > rte_memcpy_aligned() is x86 only. >=20