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 AA59E44038; Wed, 15 May 2024 19:01:09 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2E57A402C2; Wed, 15 May 2024 19:01:09 +0200 (CEST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on2043.outbound.protection.outlook.com [40.107.6.43]) by mails.dpdk.org (Postfix) with ESMTP id 8FE904021D for ; Wed, 15 May 2024 19:01:07 +0200 (CEST) ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=Hqwb/vgJbV5ohjng/kwiC9pP/eabtrGLybGY1tF74M/iBvw65L+kP+Yc06cFB1RQ+XcvWt9mKH9AR/6eRhgiBm1nP+l0ZFaXQTisFM/rgK0KJMtzBcVotBikaGs81YzaFSJRmC9U9qfD3Agc9LiSkgkuZJ7feV/7gwkPzzCHMEytCRWGjvWWvWgZgL6kqjtM3Zsvb4f12j/fVEe/pX3KynS5GMCVIGCFnDImTraiqUPinHnCGVq+uaZ5CjxzQ3vi0hwfiBBk1Y4Ov9tpVubyaEaL47sEW2NIKJ0ViyXkvpGi/HjZ5D0dDc11Y2GFIssKGHFgqvh7ZJ4vN38H3fzmcQ== ARC-Message-Signature: i=2; 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=JuSBv1i8SthNyyhwN+SABB+a09/q+2Sp5Pwb2KpjhRE=; b=BHZqncj/22QznDpvP3ID7Apx7Irt7f0cqYCFFyQuci38vd2WK2wMP9PxlGobQMEDjNaLJ9jG+TD6HQKM44X9tHIAbth+ud9UVhmubwa7CJrnWwde5cWIwcat6/7Dbg7ov8HsKvYR7T5ugXJeqp74QY9cYkxJyecScDnGHR0dm+0+dZgZtzz7i0KhHI9PFvcvXY+Xlluy5ViC945RvZYHWGbbP43G1F67Sjh3fLWZsEBqWTN+SPLNZw3Pb5P+F0Hem2sap0SLT87if7At/cy/G659l78Lsrt+U5Sry0MR3DtGlh4DrOHonhanb6524KiJTuzPNINTFwFnvABtUkKr1g== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=dpdk.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JuSBv1i8SthNyyhwN+SABB+a09/q+2Sp5Pwb2KpjhRE=; b=f1BF9LlT7/mSvejrZRf3Ivlls6cFXTJHkPEI+NdfvUrsHh94WDv7vZ+A3rzhMvV5dLl+QH5w6qrAl17n8qj4efeYmxo/C3XMkrnjkcDe6iEJhGmKu5tguryiHwv8Dh/9aGp+Ao+McuIpEW6pycsuZgAxwTLPslMrGp4lIniHQ4o= Received: from DU2PR04CA0296.eurprd04.prod.outlook.com (2603:10a6:10:28c::31) by DB3PR08MB9010.eurprd08.prod.outlook.com (2603:10a6:10:42b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.55; Wed, 15 May 2024 17:01:04 +0000 Received: from DU2PEPF00028D10.eurprd03.prod.outlook.com (2603:10a6:10:28c:cafe::2e) by DU2PR04CA0296.outlook.office365.com (2603:10a6:10:28c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7587.25 via Frontend Transport; Wed, 15 May 2024 17:01:04 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DU2PEPF00028D10.mail.protection.outlook.com (10.167.242.24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7544.18 via Frontend Transport; Wed, 15 May 2024 17:01:04 +0000 Received: ("Tessian outbound 9d9bf1c5d85a:v315"); Wed, 15 May 2024 17:01:04 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: c7209ccc06bf7877 X-CR-MTA-TID: 64aa7808 Received: from 38a9983d53e7.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 396B305F-BDFF-435A-8256-9467CB23965D.1; Wed, 15 May 2024 17:00:58 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 38a9983d53e7.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 15 May 2024 17:00:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IsnDYwGuvMf2I3ITRGGmKo2I8yEcMztPBohjYgNBLFnjEIMp5w+V4GRTzLOt/K/TPBc/xexwJBYfIm2nQsgRrQVPjnEFvBl61epVZX9pb1TSJQMpkY2yu6EEikF7D1aEjij1e6EbkUvm36H9Wfq4U0iMWop/oCp21d66/DUchFTvrNCK0yW9bPjrVOZyPhmatwklNyF6xdsSGeO1BwOqkjbxU2EAh1iCtZ8XCcW8SwXe2BqR/J1C3Ejw2BUw2z20zF9jIQWCO9G1Wyj1Ur3d7nRIvfEf/u2l6V8Th2N3xBp1Q6i38otMubF5/eAAW3+0bE8+YL2j8RN5FNJLH/IzJg== 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=JuSBv1i8SthNyyhwN+SABB+a09/q+2Sp5Pwb2KpjhRE=; b=ao/1PtuW1gfPkT8fBrm0diJN9owa80hRGA5YQVHz4GClhy8Pk+LAGx3+R+3ySDp/XjlS84F5nebk2m8ZdSLMEVM5bwuDAy2jk6uOdiF373720fSnPGc0+kkJkHoM/IiZi+Zhifz/3kG+mqTAD71DCcqIDVndOqMP/ARE59ks7yYgk93iiXBVHh9POXPckjQlRGW6hcg0W7flCFCZ4ap0PQ80j1REyteWXDkyUDEiQwlhtAlRs3jL7FiuLoaFUGosyGgWfcjZgt1UI54PUj7noctItmSdMTy8O3EoJlJ5dvl1DoG0Sh74zI8xTndFxUsWZ0thMRVXAZw64M/DloNE/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JuSBv1i8SthNyyhwN+SABB+a09/q+2Sp5Pwb2KpjhRE=; b=f1BF9LlT7/mSvejrZRf3Ivlls6cFXTJHkPEI+NdfvUrsHh94WDv7vZ+A3rzhMvV5dLl+QH5w6qrAl17n8qj4efeYmxo/C3XMkrnjkcDe6iEJhGmKu5tguryiHwv8Dh/9aGp+Ao+McuIpEW6pycsuZgAxwTLPslMrGp4lIniHQ4o= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from DB4PR08MB8151.eurprd08.prod.outlook.com (2603:10a6:10:381::16) by VI1PR08MB10198.eurprd08.prod.outlook.com (2603:10a6:800:1be::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.55; Wed, 15 May 2024 17:00:55 +0000 Received: from DB4PR08MB8151.eurprd08.prod.outlook.com ([fe80::79fc:e321:c17d:31f2]) by DB4PR08MB8151.eurprd08.prod.outlook.com ([fe80::79fc:e321:c17d:31f2%5]) with mapi id 15.20.7587.026; Wed, 15 May 2024 17:00:54 +0000 Message-ID: <039e71aa-f798-4f64-8c66-a9427a77b821@arm.com> Date: Wed, 15 May 2024 18:00:51 +0100 User-Agent: Mozilla Thunderbird Cc: nd@arm.com, "dev@dpdk.org" , Honnappa Nagarahalli , =?UTF-8?Q?Morten_Br=C3=B8rup?= Subject: Re: RE: [PATCH v5 0/4] add pointer compression API Content-Language: en-US To: Konstantin Ananyev , "konstantin.v.ananyev@yandex.ru" References: <20230927150854.3670391-2-paul.szczepanek@arm.com> <20231101181301.2449804-1-paul.szczepanek@arm.com> <7058331a-d829-4f0e-8634-726ca3be1ef2@arm.com> <98CBD80474FA8B44BF855DF32C47DC35E9F290@smartserver.smartshare.dk> <7D23A333-9846-4A34-A8B5-FDC11F042025@arm.com> <18e97877c4a64521a02317a329572866@huawei.com> From: Paul Szczepanek In-Reply-To: <18e97877c4a64521a02317a329572866@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0251.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:350::19) To DB4PR08MB8151.eurprd08.prod.outlook.com (2603:10a6:10:381::16) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: DB4PR08MB8151:EE_|VI1PR08MB10198:EE_|DU2PEPF00028D10:EE_|DB3PR08MB9010:EE_ X-MS-Office365-Filtering-Correlation-Id: 0d5522fb-4453-4839-0175-08dc75009b2c x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230031|376005|366007|1800799015; X-Microsoft-Antispam-Message-Info-Original: =?utf-8?B?ZlpZa2xPdUdWeHM3VWRLL3c3cFFpOXZXSHI2WGNUS1ZiblQrbHpMTlFWMW42?= =?utf-8?B?QmpGSC8xQnJLYnFuY1ROc1dORTVmaGxWZmNaVWx5VS8yL3RKczcwMEpRNXJ6?= =?utf-8?B?WVJyZ1NWOTFkZVNPek1WMys2bGN6ZnNvNWoyOGlCcGVRUnJ0cnhKTllBMlFQ?= =?utf-8?B?R2Nvem0rMUFPL3JyZWQwVFFjdXcrV3F4bjVWZjZkSkpycFRlSDhiS0J4ZDZJ?= =?utf-8?B?UDlpOVhrOElOTWR0WXJaOHo0QTBLWjZaNEZ6aFZzbkMrR0VFOTdQUmVWcFUy?= =?utf-8?B?QUVmL0FUWFZvdkhlTjU2ZzZuamRhTG8wSWtYSzIwRFBoM0JlZkNTY1VlNE9R?= =?utf-8?B?K09OeGpSS0Y3SWU1emVpbDJyYThUUWFjYWgrQlMwaTEvSzNhV2xtWDZINXRo?= =?utf-8?B?WDV6S0xkeTNuUVN0SU1WTTJtK3FWellDdW5JRk1iV2lSNnVqZ3hJcUFSS0JF?= =?utf-8?B?Z0wrQzFpNUpmNUdDR2lNMER6c3A3NlBQY04wYmh4bVZsK2NCaytsSDlTbGFB?= =?utf-8?B?bnZBTU9Tb3d5SWxXN3hqRUdqZDNUVUZ5MGs4MEhJRTUrOVZ2Y2JZa1QrMHJQ?= =?utf-8?B?WEhnRHhwRkMrbHAzNjYwWHdXOThsMjNORnVUbmc0WEV5S3NkVmk1OW9YSVdU?= =?utf-8?B?K3IwM3RBeXlmRGhVSExaMWRVZDNBbUkrSHRkKzAvMm9JY2phUHhybjVMTExQ?= =?utf-8?B?cFV1bWZmUmR3aldORzFVenMrc0V5TEs4MXIvNVcvcHl6blRzSms2czZpTW1J?= =?utf-8?B?K0JSTWhOL2QwcjA5NmhHc25aR0ZwNXZyaDQ0eFBUK1A1c3BGa0xyRmloa3dh?= =?utf-8?B?MXB1OUQ3VlNIQS91Zllxc05LZDBMS1FzVEltZndQWnVFV3FiQzRWcUNEenhJ?= =?utf-8?B?Z25pN0lKdmo2THR4cXJkSVF2SFJHRzdkTXRBMzdwejRsRlBmTVJ6YTBqM21J?= =?utf-8?B?aXlHUHNxM1ExQVdEM3J3c3pTdDIyK1FSbFhXV3BZK05pS3c0VWpSQko1Y3R5?= =?utf-8?B?V0dpdFF0ZjhnZVNsQ3RuWm1qazNpdldTQ3d6REg0WHZ6YU9ZNlB1eGRLZnZW?= =?utf-8?B?bENmZ0lnT2ZzSmJKWDJ1SjN6QzNmaWlnWWMwYXcyWTdJdm0vMzBaT3pUSFRv?= =?utf-8?B?M25TUHlOUXA0aThTdGI3N2VEY0hUd0tuY2lzVDV4N0tnK0l0UXJZay8vZzBM?= =?utf-8?B?TmZkWFp4eGZ1WmI5Q1gya0ZvQ2ltTkJhNUx1YlRJd0ZSZnlqc3dSdDJDekRa?= =?utf-8?B?eUlvSkVVN09NVXlMYzlGMW53d2VydHp2Rk9FeC81b3UvVzc0Sis1QnRZRUR3?= =?utf-8?B?djdOR0lFejdLdjQxZjVZWmpIVFZkTlRxRnhPUFl0VkVOK3pBR2laOWE0WmJa?= =?utf-8?B?NHE2cnZ2VzZIUUNVb3R1M1hGdHJZN0VZc2hOWnJQTjA1dTcrVjhRY01mYThK?= =?utf-8?B?VTltekdBdTlxUXRzSS92MloySk56REFnTnE0WGZ4bmo2dmRoaVp4aWs4N3ZT?= =?utf-8?B?OUJ6UjRHaDE1ajdaZDBqdllSdXpvSGhWNVpHYVkvME9iTC9rTlhlczF0NlVO?= =?utf-8?B?TW9hL3UvRHo1YVVEU0wzbm1OdWRaNUNsSU5ZbTAyMmZFclE3aUlkV3dhQkly?= =?utf-8?B?c1dBOGdxWlFraThtMmpvZERpRi85QUhicmdsL1VKSDFta0xXVThaMW5seDNK?= =?utf-8?B?MjJ2VFkvZFhVbTZCMC9nLytaNkZvTTNtNk5OOG1pc2N0UmFFWW9pZ2ZnPT0=?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB4PR08MB8151.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376005)(366007)(1800799015); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB10198 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU2PEPF00028D10.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 1c5502b8-4f68-45e9-f350-08dc7500950b X-Microsoft-Antispam: BCL:0; ARA:13230031|376005|36860700004|1800799015|82310400017|35042699013; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aHRpdnFoeXBhQ2NhNDJ1aGYyb2kwYXNaRTdoVFU3SGdVT2hUMC82M1kxV1Ra?= =?utf-8?B?T2RKaDczWDZWa1RGOWVPTFhCeXpYbGE4empmY2tCTEVvOUhaN25jcHQ4WlUr?= =?utf-8?B?NzFOazlDYjUrS0x5bzlvL0U2b05MdGNkb3d2TkZTMFZpNitxVTcxQkNVOG5I?= =?utf-8?B?aU02TFpJcVNTTnNQdXh4NEFVd3hSZUNPTWNOMi95MFFsaWZ0ajlxb0J6dEdE?= =?utf-8?B?b1dqa1o1RHhGVkt5REI2YTRFdTRyRlhZMjE2QUNYQ3U3aGFsZWI1cEpKRFFP?= =?utf-8?B?a25QODhFRFFPSzZlZzJ1bFZqMXVWZVJHSVVmSTRJelJYdi9XUE83R3pLUjBv?= =?utf-8?B?S25kRHBBaDdwZ2VRTE1odnRUSERLeFA1eW5Xb0FVQjJxYkZIR2FqZ0JhOXVr?= =?utf-8?B?dm12UTJFazBOUEpudDgxZTQwVzkrY0hRVSsrRHF1dUhRblVPTVdjbVBTYVRy?= =?utf-8?B?YlNiWDg2SkFJeW5PNXBPTU1rMzJBbllvaGRidVVaZklZRXd5Wk5wNUxDRjdM?= =?utf-8?B?WFQvelNNckJRSll2V0lMRHZCa0JjWXlBSzlSSkFob3BnNGgvQ3hMOTBMOUlv?= =?utf-8?B?MUFoVmorWmR2WEwxUWRtWVNTVWJPSjIrYjlUTXZLV0kvcEJ6OWJKNm5tZjlB?= =?utf-8?B?b0xqdy9nR2MwakFVemsrQWd0cWU4OWxFN0x1TzRQTWluYkN3eERKK2YzOGpx?= =?utf-8?B?Z2pKemtxSjhtMEhZclUrM3BBSlJTZ0VxTHA0UG5BaGdsZmM5YnlwRlM4RTVx?= =?utf-8?B?emkrYW9EN0pITHY3MVpCeUhOWmpUWis0SUhkRnlhUzkxT2dEMGVTblV0MGNM?= =?utf-8?B?bG0yaW5UWVlSeXJadEp5VXdwTEZBbTMydGRPQmwrVDhYdy9LdHhxWTRWNUtw?= =?utf-8?B?UkRKUUNSb0U2NWR6OTVyMGxzTzNOOE15YVpZMUorTkpSM0toWWVySmM4M0cr?= =?utf-8?B?UkJZQ0RoZE41cWpBN2xWYUxBYnh3NjlXdVpubVlmbEpxSk82bUJKSFU2bCtn?= =?utf-8?B?VitwY2N2WHYwQmswUlkyMXhEZzRvUEU1RHZ2dGo3L0tuM2kwdDJLd0JVanVO?= =?utf-8?B?NlhSWXdpcnc4QTJyR25UZ0UxdTJYQzd2c2RNN3lvS0ppcGxyL0RQS0YwUVQ3?= =?utf-8?B?elQrNHlnTitwRVdSMnNZc3htTFQ2ZzdVL3FVVEJhMVVGaFpuQWloQmEranF2?= =?utf-8?B?R0k0bGs3ak1TeXhYNVg5MHVuaHlGUDZhOE9LWkZBdjZoSmFPcE95YTRBTEVY?= =?utf-8?B?QXcwQlg1cXYydnpEcjFZbk41MDgxekVkU2ZvTllxQXoxZW1NdnNqS2J5SFV3?= =?utf-8?B?Z09lbzdIWnFUV2IySjRtcUVoNHJiQWhzV1FaY1NWRUhJQU8xUXJ5ZnQyZjJn?= =?utf-8?B?K0QwdURHaU5ENTBoRzZabFBuc1NyMTllUzVIaG5CRnl2TUpiaDNDYXZhOW9N?= =?utf-8?B?R1R2elhzRWhMaVo0Njc1Q3F3SW54dVErSTRRNndyNGZMdHdua2xTUkJ2Y3hX?= =?utf-8?B?ZmdDRkc0elhBbWc2OGl5U2lYajM2Ly92THd1S3RrS2VMb0hOWlhJYlZLS3Zi?= =?utf-8?B?WE92NFRXTXpiL0lFZWk2ejVGUnZTL1pPNXFuZUY2UzBkUGJDcEVETk1STnov?= =?utf-8?B?MUJvaENMSkV5Q2ZoRFFxYlcrbHYrNWtXbEdocFcrb0RLN2x3a3ZRTlpBM3ph?= =?utf-8?B?R0pjcG1TVk1UVzZhTXMrN1ZDMW9KMVErbmJyTG85RmU5MFJjTm5IU25rczMx?= =?utf-8?B?NmU0b29BZHhEQ2lJa3ZHQ1VOdXh3WkZkRzl5UExOMm52NUZQNFhVbVhPK0Ri?= =?utf-8?B?SmFOY2hjUUd6ZDQ5UmVLUEdMWGpaMG5TdlhnQWUyelJreGo4OWhwakE1Rmsr?= =?utf-8?Q?/VXXrLrfDbi7g?= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230031)(376005)(36860700004)(1800799015)(82310400017)(35042699013); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2024 17:01:04.3570 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0d5522fb-4453-4839-0175-08dc75009b2c X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DU2PEPF00028D10.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR08MB9010 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 On 04/03/2024 14:44, Konstantin Ananyev wrote: >> This feature is targeted for pipeline mode of applications. We see many customers using pipeline mode. This feature helps in reducing >> the cost of transferring the packets between cores by reducing the copies involved. > > I do understand the intention, and I am not arguing about usefulness of the pipeline model. > My point is you are introducing new API: compress/decompress pointers, > but don't provide (or even describe) any proper way for the developer to use it in a safe and predictable manner. > Which from my perspective make it nearly useless and misleading. In the latest version there is an example in the docs showing how to use it. There is an integration test that shows how to use it. The comments in the header also provide detailed guidance. >> For an application with multiple pools, it depends on how the applications are using multiple pools. But, if there is a bunch of packets >> belonging to multiple mempools, compressing those mbufs may not be possible. But if those mbufs are grouped per mempool and >> are transferred on different queues, then it is possible. Hence the APIs are implemented very generically. > > Ok, let's consider even more simplistic scenario - all pointers belong to one mempool. > AFAIK, even one mempool can contain elements from different memzones, > and these memzones are not guaranteed to have consecutive VAs. > So even one mempool, with total size <=4GB can contain elements with distances between them more than 4GB. > Now let say at startup user created a mempool, how he can determine programmatically > can he apply your compress API safely on it or not? > I presume that if you are serious about this API usage, then such ability has to be provided. > Something like: > > int compress_pointer_deduce_mempool_base(const struct rte_memepool *mp[], > uint32_t nb_mp, uint32_t compress_size, uintptr_t *base_ptr); > > Or probably even more generic one: > > struct mem_buf {uintptr_t base, size_t len;}; > int compress_pointer_deduce_base(const struct mem_buf *mem_buf[], > uint32_t nb_membuf, uint32_t compress_size, uintptr_t *base_ptr); > > Even with these functions in-place, user has to be extra careful: > - he can't add new memory chunks to these mempools (or he'll need to re-calcualte the new base_ptr) > - he needs to make sure that pointers from only these mempools will be used by compress/decompress. > But at least it provides some ability to use this feature in real apps. > > With such API in place it should be possible to make the auto-test more realistic: > - allocate mempool > - deduce base_pointer > - then we can have a loop with producer/consumer to mimic realistic workload. > As an example: > producer(s): mempool_alloc(); ; ring_enqueue(); > consumer(s): ring_dequeue(); ; free_mbuf(); > - free mempool I understand your objections and agree that the proposed API is limited in its applicability due to its strict requirements. AFAIK DPDK rte_mempool does require the addresses to be virtually contiguous as the memory reservation is done during creation of the mempool and a single memzone is reserved. However, I do not require users to use the rte_mempool as the API accepts pointers so other mempool implementations could indeed allow non-contiguous VAs. To help decide at compile time if compression is allowed I will add extra macros to the header #define BITS_REQUIRED_TO_STORE_VALUE(x) \ ((x) == 0 ? 1 : ((sizeof(x)) - __builtin_clzl(x))) #define BIT_SHIFT_FROM_ALIGNMENT(x) ((x) == 0 ? 0 : __builtin_clzl(x)) #define CAN_USE_RTE_PTR_COMPRESS_16(memory_range, object_alignment) \ ((BITS_REQUIRED_TO_STORE_VALUE(memory_range) - \ BIT_SHIFT_FROM_ALIGNMENT(object_alignment)) <= 16 ? 1 : 0) #define CAN_USE_RTE_PTR_COMPRESS_32(memory_range, object_alignment) \ ((BITS_REQUIRED_TO_STORE_VALUE(memory_range) - \ BIT_SHIFT_FROM_ALIGNMENT(object_alignment)) <= 32 ? 1 : 0) And explain usage in the docs. The API is very generic and does not even require you to use a mempool. There are no runtime checks to verify or calculate if the pointers can be compressed. This is because doing this at runtime would remove any gains achieved through compression. The code doing the compression needs to remain limited in size, branching and execution time to remain fast. This is IMHO the nature of C applications, they trade off runtime checks for performance. Program correctness needs to be enforced through other means, linting, valgrind, tests, peer review, etc. It is up to the programmer to calculate and decide on the viability of compression as it cannot be done at compile time automatically. There is no way for me to programmatically verify the alignment and distance of the pointers being passed in at compile time as I don't require the user to use any particular mempool implementation. These limitations are clearly documented in the API and the guide. > Or probably you can go even further: take some existing pipeline sample app and make it use compress/decompress API. > That will provide people with some ability to test it and measure it's perf impact. > Again, it will provide an example of the amount of changes required to enable it. > My speculation here that majority of users will find the effort too big, > while the gain way too limited and fragile. > But at least, there would be some realistic reference point for it and users can decide themselves is it worth it or not. I have added a performance test that runs the compression and decompression loop with different burst sizes so that you can easily test if attempting compression is worth the the effort in your usecase. This is documented in the guide. > >>> >>> I would like to add: >>> If we want to offer optimizations specifically for applications with a single mbuf pool, I think it should be considered in a system-wide >> context to determine if performance could be improved in more areas. >>> E.g. removing the pool field from the rte_mbuf structure might free up space to move hot fields from the second cache line to the >> first, so the second cache line rarely needs to be touched. (As an alternative to removing the pool field, it could be moved to the >> second cache line, only to be used if the global "single mbuf pool" is NULL.) >> Agree on this. The feedback I have received is on similar lines, many are using simple features. I also received feedback that 90% of >> the applications use less than 4GB of memory for mbuf and burst sizes are up to 256. > > Well, from my perspective the story is completely different: > Majority of real-world apps I am aware do use multiple mempools, > it is also not uncommon to have a mempools with size bigger then 4GB (8/16). > Again, there are queries to make mempools growable/shrinkable on demand. You can use this API with mempools even as big as 32GB as long as your alignment allows for sufficient shift (as explained in the headers and docs) and rte_mempool objects will have at least 8 bytes alignment so can fit a 32GB mempool in. It is true that you cannot use it if you cannot guarantee the address range at compile time. This utility is not a golden bullet to use on every pointer.