From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0087.outbound.protection.outlook.com [104.47.1.87]) by dpdk.org (Postfix) with ESMTP id 5A24E2BC7 for ; Tue, 20 Mar 2018 12:35:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UeVBA05UtxbTrTLaRsoDYtvosAidNTarXR1zfGrDCIg=; b=qXPXUb8OB8IxC3B4Q2qA8MFUp1eAsJkLlL22+6Sn8ryn9C5n0Tl4LTULkTFyK/t3KWjfHKdslKGNbNd29RYf8zbOqoV/m+4LR+X3qQbvINXPwzAAxWFflRe2Po9qQPV0EFzaHJzkPszapSg19AooEcla45+9+Xit2S5IMjXyIQE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=shreyansh.jain@nxp.com; Received: from mail-wr0-f173.google.com (209.85.128.173) by HE1PR0402MB2780.eurprd04.prod.outlook.com (2603:10a6:3:d4::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Tue, 20 Mar 2018 11:35:50 +0000 Received: by mail-wr0-f173.google.com with SMTP id z12so1326582wrg.4 for ; Tue, 20 Mar 2018 04:35:50 -0700 (PDT) X-Gm-Message-State: AElRT7HnldzaWgRxdX8TC6RyAQGCVE4A30NmyW0I7PJiC8UJI/kShDwt mtzrXRb6xdz2L5LBh50As3NAwAK2golvBw5XtVU= X-Google-Smtp-Source: AG47ELvxwmFYEN+hs3Z37F+gL3nOaVG2dHPHNzHQ4Y3vK8kYxZNE6sC2hI2ABkV8u8CI1cwcvR3TW79TuKUH9HTmZgM= X-Received: by 10.223.186.140 with SMTP id p12mr12600183wrg.162.1521545747413; Tue, 20 Mar 2018 04:35:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.30.65 with HTTP; Tue, 20 Mar 2018 04:35:17 -0700 (PDT) In-Reply-To: References: From: Shreyansh Jain Date: Tue, 20 Mar 2018 17:05:17 +0530 X-Gmail-Original-Message-ID: Message-ID: To: Anatoly Burakov Cc: dev@dpdk.org, Olivier Matz , keith.wiles@intel.com, jianfeng.tan@intel.com, andras.kovacs@ericsson.com, laszlo.vadkeri@ericsson.com, benjamin.walker@intel.com, Bruce Richardson , Thomas Monjalon , "Ananyev, Konstantin" , kuralamudhan.ramakrishnan@intel.com, louise.m.daly@intel.com, nelio.laranjeiro@6wind.com, yskoh@mellanox.com, pepperjo@japf.ch, jerin.jacob@caviumnetworks.com, Hemant Agrawal Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [209.85.128.173] X-ClientProxiedBy: AM5PR0202CA0007.eurprd02.prod.outlook.com (2603:10a6:203:69::17) To HE1PR0402MB2780.eurprd04.prod.outlook.com (2603:10a6:3:d4::14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1669b925-8532-4311-22aa-08d58e56bb8e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR0402MB2780; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0402MB2780; 3:/N5folkLMlZcbR0SYpLJmqNtQelcj30+CaR8udhgLCmGsHczNLO5L0AFowvq8Y1DZML3R/JetqISPBJPeRvtVr+uo996nsoSjjtTMV47I0dtB77mRb1pcNFK0ncbEugmUBxvw3TqEMlzQC4X32oldJJ6HtCUVzKb2SE8YUYCNutanFf+t6V3oRrQ1WnFVX/R+OoT1DxoSwcArU2aNHWmL6e3+QIIDHHpuLdAK2de3f6Qx6eHOSsgErO+4YkQgsVK; 25:5PmXN7nJEMr0bf/hOhtT6aStYLFw2jq7rIZ+UP+JnigTNkw69mvZIJIaC3dWtYqI1qu8bdwjZADXCvf/VXNbz2zsxyytDo1OgNUwqC7OjLmsVvntVFFu4/fVPc/xCnqWD2+Dek75123q/VmRpmBhk2sMzM7t+a0dHlSsXehvHR4L0FrEvKjhpdUv6nNfyPxpte3x/TAlKOot1i7t9I4kriKBanN0+wYLy9QRQTMeFK1CzIJ7B8au8mQSSQ0D6O7Ia/jU3UtNBpDj5cqkf6TGxoEzSw9g96pcopJAE9xRJ6omEqWjOa1vSHbFvyGmgjYJVRiW4QYNIpQ0OEk+wBOheg==; 31:VcflTwGKwCBiqQto1tSoyN8XWGpPxlVSkil90JS9xrJWAqs249noZFTy9g7NZZ9qtMdkxRw/W0CRJK2VWGH2v134f6bVNBxo20mOP3iDLzh4AbjIkjpXTwLLUNbIBfI1M05A2/8J3y2Ack0YbDWnfYWhNC/tezKvw7EK7+1gSiIgSHmHZQ5usHzHt3EONInkdnMGl/EfMgKd8IHM6jodkt+Sat5QJtGiitzPZTy9V4Y= X-MS-TrafficTypeDiagnostic: HE1PR0402MB2780: X-Microsoft-Exchange-Diagnostics: 1; HE1PR0402MB2780; 20:da6izlN6SyDYLhY3BYWd0rQ24buSbu7gDxMrorKFH8RUXLWNmgXlqrPCY1IM8eepIH10RZe/KvxMR8wjtQ7ivZCnE9FSjmO5SDhIpAEb85Ag9eoOqTmfpi5oj7ygCMsEEIieif9QZW9mZH2l2+ResAnCbqHxtYBi6z7tiZAITggK/MxOuh9A4ujB64lhe/563KtTOMVEMEYhtVO3uXTgdbZV1y5vOdP2s9h2GB2LYT/Cf5UdqVv5VRcFPKRIZdC5NLjbcx8/CHNu6GKadH3FKp0IOpvP5a7MfnEs9XRjeo+ZjGtk0VUy8dlvw2EDlhhWYIlFCLchzUTSYObd6yL4rR612SrM6nm6HHUbxQU5HyjW0TU0WWEgt2T7jVnu0QMa/CrlJbaRFmuuSl1WJ/B08ySAI+oewUhIe8d205T/riG+XNPcLXZmVhP+hk6Lc3pf4MWecIee6tGVeLCeEnN2r4xYFpWSHX3YlDuSpRWrRymrvO3Lyvjf7zpid/h7RjLD; 4:pj081QWcG5Yz48OR6a9CqX0IevUutsARo5tDRq2d3qMC/as+nBymGwlCCz31cDIv/y8HJQ0WDGXXy5ImSZsZw9whaq71rwrqV4q8ASMA/NbpLo5b42Hi8n4iJeKWH5YN7zQxSM98YwqFnsuujLC6wWiV7dWm1qkwfkVWhIZj+lrZ3G3h5y0eU5umaIIwt1xlGkDExMKzP4TBGu01N5x2wV0CwlTfUT2JdY7/U7mqXD6LWEoV8RNva2KJ6Vm2VfYjX6d+E3Qb5jxmxwPZfwZkOLNcGZP6GsOhw/7/4mHLo68u0U+ogmZdxs/DtxKxIWtR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501244)(52105095)(6055026)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0402MB2780; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0402MB2780; X-Forefront-PRVS: 061725F016 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(366004)(39860400002)(39380400002)(199004)(189003)(105586002)(6862004)(69596002)(305945005)(8936002)(53546011)(5660300001)(97736004)(106356001)(16586007)(7736002)(66066001)(59450400001)(386003)(59536001)(81156014)(81166006)(95326003)(8676002)(47776003)(5820100001)(26005)(478600001)(54906003)(4326008)(498394004)(42186006)(76176011)(53936002)(86362001)(52116002)(316002)(2950100002)(6116002)(3846002)(9896002)(122856001)(61726006)(61266001)(68736007)(33896004)(23676004)(6246003)(2906002)(50466002)(55446002)(93516011)(186003)(229853002)(9686003)(55456009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0402MB2780; H:mail-wr0-f173.google.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA0MDJNQjI3ODA7MjM6a2l6TGx3eStpZWxmUmdsNG1qWUcvaFFM?= =?utf-8?B?Z01KR0lTZVJ5RWhucFYyOFZBbVZVTG16NTIxUHJUMmF4eGoxVW93bG9lZitx?= =?utf-8?B?dlRGK3VkT1ZQdGJpTjRYeENiZmNCZzNIb2h3aDBnQmtkUUl5V0VIUENTVWlP?= =?utf-8?B?a1hBbVJZdUMzSHNSSjdnTENmM1BKNXIrTjRxekVIYlJDeWJWZHUyRXcvQVpS?= =?utf-8?B?dEJtL1F0UjNFay9SSXg2M2VDZzFJUmk5RXVZUGpiNHFFN2l6RmRVWFJzZ0Vp?= =?utf-8?B?UFN2OGh6UU5YWUdjZWxSckRhYjFYSmNuQW5PdElBUHNEUkRETGxOeWFpbWtE?= =?utf-8?B?aTJRNjZTbkIvMStTNW1pTGFDU3lGTEZjQ3VCeld2WmxOTTcvQWVQcitRZzdC?= =?utf-8?B?ZlRVeUlYUGU0Z08rUHhuWGppRnVOZTlIQVlVTFI1LytMRGFUV2VheC9XeUxo?= =?utf-8?B?R1NuZDBlQUJUT3phM0JXRFpESk9qQmoxNE95ZlNKeW5XUHlSNUduOUNrRVFn?= =?utf-8?B?R1BNTHQzcHpuREwxYVVmY2RiSS91OGJjU1d4eGJTcXlnWGhsekNRcGxzdmh1?= =?utf-8?B?bXVxcmQyWWozbFM4aG1sUzZGcmhMc2ZNQ2JQd2d0OHdrYzNXOWhET2p2Q2hw?= =?utf-8?B?a0JDdzFzNjhrNnpCc2Vub2dFdGlOSkhKMm85S2FDdmw1a05tNnAyL016N1RI?= =?utf-8?B?WWxrRmxxNVpWNXZTanBBRTE3bE9HZHpxL2ozcmNuL0ZnYWhqU1I3dFpPV0NN?= =?utf-8?B?UHo5c3BucVJsODJPUGVJMDRtUmxCQStabzJDUTBQOHMyRXBHWVF5dVpXMEtP?= =?utf-8?B?ODhrejBKOXh5dDZ1cFpsVVlROHBpWFVmTEF6RG9rblRsVmRrS2FBRVhtRHM3?= =?utf-8?B?UW96UVVML1NTaXpYVnkzWTNDZCtyOWhkaGxTRDhjNTJwYkEzeWtPRTJLWS8y?= =?utf-8?B?NFJHeTJXT0JXOUYrTlNVaUhZZ3YvWEJLMXdWVFhCVUh4TU1vcmluLzdVVU8z?= =?utf-8?B?T1kyVUxHMTZnSzlXdW9BTCtUOWRKdkFqY2l5ZnIvaUlpOGxta1NGa09rRitS?= =?utf-8?B?V0pxR05XRGhNZ3JOdWtEVUNuRVdKdzE2WVkzZXQ2SU1aMlFMbzZiVWlGZHRx?= =?utf-8?B?UXp5NG0xL29zWS9kdEhSRmdyZm1YaCtWdTNvelJ5V0l2WGNBVG55bXc0ZG1H?= =?utf-8?B?UW1pbzAzMTk5b0dtTzhPbDIwUVRadWxLa2tzak9qTDY3OVNDSk5LVHJDZzlq?= =?utf-8?B?N29BN1Y5R2F4TldWQkd4TlNjWXM3WXRnWTB1bkljWEZQWmNWZ0FZNGRwVFhE?= =?utf-8?B?dS9lOWRiaUt4aVZzUFBDNWFadExHYmlzd2lNRGxqVW5Wc2pqMGJZTkw4eXpN?= =?utf-8?B?SDRvUFc1RnRRaW5RZzRjemYwa0VHKzBKZk12UGhiK2Rob20vUHR4TUJLWkho?= =?utf-8?B?MUlzaTUxTlpaNjNXS09Bb05YSytTM2JBUWpoNWgzQlh3Y21uL1lxWVlxM3Fq?= =?utf-8?B?eGVlQ0ZvWUE3c2creVByaWZqdlUzZUZHc0Q2VkpQd1V5RzJNaUh6aU4zSnlB?= =?utf-8?B?d20xdkJSWFhDTVhaU2x2YkhjVnJlanA5WXl6S0VRZGFRYjF4N2JzUC9pSXNS?= =?utf-8?B?UUdWdDJVRFhBN1BHbFo1WndpclV4Z3NVNmY1SWpVK3UrV1lxYVozYi9mMUhw?= =?utf-8?B?S2JlQS92ekR6L2U2V2J6WE5HSGhNRllKNk40d1JlYmRXTU1IZUJQZWxtYkph?= =?utf-8?B?R3NBOFgxRlhEV0cwK29ldDM0V2NIOTh4UlNrRUM3cVJrT3dGZ0RMTnBVeGpU?= =?utf-8?B?MUsydjRkVEFvZXd3eFlZbUtvdzM1VmFsTzFmY2Q0dGsrVXJUQT09?= X-Microsoft-Antispam-Message-Info: otzlkgAE66eAOqL5GKABb+SuC/UvoA1yFXmVXbIqRKHNyyh6AKmHlrjzCWLdjQhCTRuxG/H7XjyEnBlBtEfqE/7zSBHPfufXITsCjtLeZ4oYdFn2FSKv7bn/K0t47IZuhsLOGpe7l11dko31A5UOSYTaFElK9eXiKVut87yIBjrjfzsnDrfgYE4OGnTjHvlm X-Microsoft-Exchange-Diagnostics: 1; HE1PR0402MB2780; 6:mheVTRWmLQdM5vkNJZekg3l4rlC/aJamtFb96bthyOEJe4z+4LO+gjR750yFMZWOsdkGIinsVQ64QmGrcOlBb5mnRocEuAN55YpFXHpG6ceaEKraGfYoMNOqYty/Q+MCUqRSBCtLLZOFy2PMMdFzqUpSdtqE7cGtnL7jz2Pww5lqzAUYjIiMcQUxY5K8K2EHr0EvIrenNO8Macgy0UHsnewISACDNCt0wpVx29PA/8cZV4et//7GEOjb4bJtHe88kvnbpW2wUvDBmIMLEtageTXW66DVNmHJv5Cr7ukUFZQHjk/Hdtmu83wGLBo723tFCvFosshluGxJfEFIif9vh5WSEg2Gpu/jAcXahdVmZe8=; 5:UECl+WN2Y6DdbRRM+4H4jMAnvLrM0TfxQz7AH+oI5sc5/8olZXP2T4IG2Im1gGi4PXkIrVW+L60Bg8phcdh+qJPx5BZMZm2Ir55FN7PDQwuyfn7FY/47VtMmH5JyXLu3OgGxE0HF6w5w/DLM8xPqhtW1Id4Zx5NujMbbYnV1Iig=; 24:zSs1Xdc5IXLweIYWBvisYf/KjTdHPDNMxkxsaziqk+PlLKLC9Jobjrt79/yAt+TALI6upXjAtSDIJlyFwF7MBBMup2/u31j+ICz6OrKgw4M=; 7:ddnuIbnalLEJyMZvIl5rSzOQJqHRSlZcP9ZGvqQzGn525FgOem8swCigcbx4a45Ehw3vwdhtr0txwectPuLrscBLGnibuz4MAiLHzAVkMsYoUN7VkNGaWBa+D/5rWs6o/sAlr03mDoQt82ZcIkLGBcDHYYvbP96xnWGIW3MeUH3N3GdUypmQAG9FVBIPQEwgCgws8GN0xJHurjhVkL/MQv53UVHZwGSfN3EXKV/nf/rBN/Y4RBfxrmNRXOpWvETG SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2018 11:35:50.7779 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1669b925-8532-4311-22aa-08d58e56bb8e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0402MB2780 Subject: Re: [dpdk-dev] [PATCH v2 23/41] mempool: add support for the new allocation methods 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: Tue, 20 Mar 2018 11:35:52 -0000 Hello Anatoly, On Wed, Mar 7, 2018 at 10:26 PM, Anatoly Burakov wrote: > If a user has specified that the zone should have contiguous memory, > use the new _contig allocation API's instead of normal ones. > Otherwise, account for the fact that unless we're in IOVA_AS_VA > mode, we cannot guarantee that the pages would be physically > contiguous, so we calculate the memzone size and alignments as if > we were getting the smallest page size available. > > Signed-off-by: Anatoly Burakov > --- [...] > static void > mempool_add_elem(struct rte_mempool *mp, void *obj, rte_iova_t iova) > { > @@ -549,6 +570,7 @@ rte_mempool_populate_default(struct rte_mempool *mp) > unsigned mz_id, n; > unsigned int mp_flags; > int ret; > + bool force_contig, no_contig; > > /* mempool must not be populated */ > if (mp->nb_mem_chunks != 0) > @@ -563,10 +585,46 @@ rte_mempool_populate_default(struct rte_mempool *mp) > /* update mempool capabilities */ > mp->flags |= mp_flags; > > - if (rte_eal_has_hugepages()) { > - pg_shift = 0; /* not needed, zone is physically contiguous */ > + no_contig = mp->flags & MEMPOOL_F_NO_PHYS_CONTIG; > + force_contig = mp->flags & MEMPOOL_F_CAPA_PHYS_CONTIG; > + > + /* > + * there are several considerations for page size and page shift here. > + * > + * if we don't need our mempools to have physically contiguous objects, > + * then just set page shift and page size to 0, because the user has > + * indicated that there's no need to care about anything. I think the above case is not handled properly here. reason below... > + * > + * if we do need contiguous objects, there is also an option to reserve > + * the entire mempool memory as one contiguous block of memory, in > + * which case the page shift and alignment wouldn't matter as well. > + * > + * if we require contiguous objects, but not necessarily the entire > + * mempool reserved space to be contiguous, then there are two options. > + * > + * if our IO addresses are virtual, not actual physical (IOVA as VA > + * case), then no page shift needed - our memory allocation will give us > + * contiguous physical memory as far as the hardware is concerned, so > + * act as if we're getting contiguous memory. > + * > + * if our IO addresses are physical, we may get memory from bigger > + * pages, or we might get memory from smaller pages, and how much of it > + * we require depends on whether we want bigger or smaller pages. > + * However, requesting each and every memory size is too much work, so > + * what we'll do instead is walk through the page sizes available, pick > + * the smallest one and set up page shift to match that one. We will be > + * wasting some space this way, but it's much nicer than looping around > + * trying to reserve each and every page size. > + */ > + > + if (no_contig || force_contig || rte_eal_iova_mode() == RTE_IOVA_VA) { > pg_sz = 0; > + pg_shift = 0; > align = RTE_CACHE_LINE_SIZE; So, assuming dpaa2 as example, I ran testpmd. IOVA=VA is the mode. pg_sz = 0 is set. same as before applying the hotplug patchset except that earlier this decision was purely based on availability of hugepages (rte_eal_has_hugepages()). Moving on... > + } else if (rte_eal_has_hugepages()) { > + pg_sz = get_min_page_size(); > + pg_shift = rte_bsf32(pg_sz); > + align = pg_sz; > } else { > pg_sz = getpagesize(); > pg_shift = rte_bsf32(pg_sz); > @@ -585,23 +643,34 @@ rte_mempool_populate_default(struct rte_mempool *mp) > goto fail; > } > > - mz = rte_memzone_reserve_aligned(mz_name, size, > - mp->socket_id, mz_flags, align); > - /* not enough memory, retry with the biggest zone we have */ > - if (mz == NULL) > - mz = rte_memzone_reserve_aligned(mz_name, 0, > + if (force_contig) { > + /* > + * if contiguous memory for entire mempool memory was > + * requested, don't try reserving again if we fail. > + */ > + mz = rte_memzone_reserve_aligned_contig(mz_name, size, > + mp->socket_id, mz_flags, align); > + } else { > + mz = rte_memzone_reserve_aligned(mz_name, size, > mp->socket_id, mz_flags, align); > + /* not enough memory, retry with the biggest zone we > + * have > + */ > + if (mz == NULL) > + mz = rte_memzone_reserve_aligned(mz_name, 0, > + mp->socket_id, mz_flags, align); > + } > if (mz == NULL) { > ret = -rte_errno; > goto fail; > } > > - if (mp->flags & MEMPOOL_F_NO_PHYS_CONTIG) > + if (no_contig) > iova = RTE_BAD_IOVA; > else > iova = mz->iova; > > - if (rte_eal_has_hugepages()) > + if (rte_eal_has_hugepages() && force_contig) So, pre-hotplugging patch, call used to enter mempool_populate_iova. But, with the 'force_contig' not set (in app/test-pmd/testpmd.c:521) while calling rte_pktmbuf_pool_create, rte_mempool_populate_va is called instead. > ret = rte_mempool_populate_iova(mp, mz->addr, > iova, mz->len, > rte_mempool_memchunk_mz_free, > -- > 2.7.4 This is called with pg_sz = 0: 678 else >># 679 ret = rte_mempool_populate_virt(mp, mz->addr, 680 mz->len, pg_sz, 681 rte_mempool_memchunk_mz_free, 682 (void *)(uintptr_t)mz); In this function, 512 /* address and len must be page-aligned */ 513 if (RTE_PTR_ALIGN_CEIL(addr, pg_sz) != addr) 514 return -EINVAL; This is where error is returned. I don't think RTE_PTR_ALIGN_CEIL is designed to handle pg_sz = 0. It is roughly equivalent to: RTE_PTR_ALIGN_FLOOR(((uintptr_t)addr - 1), pg_sz) which returns NULL (0 ~ pg_sz). Basically, this ends up failing rte_mempool_populate_default. I think the reason is the assumption that when rte_mempool_populate_virt is called, it can handle 0 page sizes (there would issues besides the above RTE_PTR_ALIGN_CEIL as well, like a for-loop looping over off+pg_sz), is wrong. It needs a valid page-size value to work with (!0). So, basically, DPAA2 is stuck with this patch because of above issue, if I am correctly comprehending it as above. Regards, Shreyansh