Patch Comment Detail
get:
Show a patch comment.
patch:
Update a patch comment.
put:
Update a patch comment.
GET /api/patches/132027/comments/169982/?format=api
{ "id": 169982, "web_url": "http://patchwork.dpdk.org/comment/169982/", "msgid": "<039e71aa-f798-4f64-8c66-a9427a77b821@arm.com>", "list_archive_url": "https://inbox.dpdk.org/dev/039e71aa-f798-4f64-8c66-a9427a77b821@arm.com", "date": "2024-05-15T17:00:51", "subject": "Re: RE: [PATCH v5 0/4] add pointer compression API", "submitter": { "id": 3199, "url": "http://patchwork.dpdk.org/api/people/3199/?format=api", "name": "Paul Szczepanek", "email": "paul.szczepanek@arm.com" }, "content": "On 04/03/2024 14:44, Konstantin Ananyev wrote:\n>> This feature is targeted for pipeline mode of applications. We see many customers using pipeline mode. This feature helps in reducing\n>> the cost of transferring the packets between cores by reducing the copies involved.\n> \n> I do understand the intention, and I am not arguing about usefulness of the pipeline model. \n> My point is you are introducing new API: compress/decompress pointers,\n> but don't provide (or even describe) any proper way for the developer to use it in a safe and predictable manner.\n> Which from my perspective make it nearly useless and misleading.\n\nIn the latest version there is an example in the docs showing how to use\nit. There is an integration test that shows how to use it. The comments\nin the header also provide detailed guidance.\n\n>> For an application with multiple pools, it depends on how the applications are using multiple pools. But, if there is a bunch of packets\n>> belonging to multiple mempools, compressing those mbufs may not be possible. But if those mbufs are grouped per mempool and\n>> are transferred on different queues, then it is possible. Hence the APIs are implemented very generically.\n> \n> Ok, let's consider even more simplistic scenario - all pointers belong to one mempool.\n> AFAIK, even one mempool can contain elements from different memzones,\n> and these memzones are not guaranteed to have consecutive VAs.\n> So even one mempool, with total size <=4GB can contain elements with distances between them more than 4GB. \n> Now let say at startup user created a mempool, how he can determine programmatically\n> can he apply your compress API safely on it or not?\n> I presume that if you are serious about this API usage, then such ability has to be provided.\n> Something like:\n> \n> int compress_pointer_deduce_mempool_base(const struct rte_memepool *mp[],\n> \tuint32_t nb_mp, uint32_t compress_size, uintptr_t *base_ptr);\n> \n> Or probably even more generic one:\n> \n> struct mem_buf {uintptr_t base, size_t len;}; \n> int compress_pointer_deduce_base(const struct mem_buf *mem_buf[],\n> \tuint32_t nb_membuf, uint32_t compress_size, uintptr_t *base_ptr);\n> \n> Even with these functions in-place, user has to be extra careful:\n> - he can't add new memory chunks to these mempools (or he'll need to re-calcualte the new base_ptr)\n> - he needs to make sure that pointers from only these mempools will be used by compress/decompress.\n> But at least it provides some ability to use this feature in real apps.\n> \n> With such API in place it should be possible to make the auto-test more realistic:\n> - allocate mempool \n> - deduce base_pointer\n> - then we can have a loop with producer/consumer to mimic realistic workload.\n> As an example:\n> producer(s): mempool_alloc(); <fill mbuf with some values>; ring_enqueue(); \n> consumer(s): ring_dequeue(); <read_and_check_mbuf_data>; free_mbuf();\n> - free mempool\n\nI understand your objections and agree that the proposed API is limited\nin its applicability due to its strict requirements.\n\nAFAIK DPDK rte_mempool does require the addresses to be virtually\ncontiguous as the memory reservation is done during creation of the\nmempool and a single memzone is reserved. However, I do not require\nusers to use the rte_mempool as the API accepts pointers so other\nmempool implementations could indeed allow non-contiguous VAs.\n\nTo help decide at compile time if compression is allowed I will add\nextra macros to the header\n\n#define BITS_REQUIRED_TO_STORE_VALUE(x) \\\n\t((x) == 0 ? 1 : ((sizeof(x)) - __builtin_clzl(x)))\n\t\n#define BIT_SHIFT_FROM_ALIGNMENT(x) ((x) == 0 ? 0 : __builtin_clzl(x))\n\n#define CAN_USE_RTE_PTR_COMPRESS_16(memory_range, object_alignment) \\\n\t((BITS_REQUIRED_TO_STORE_VALUE(memory_range) - \\\n\tBIT_SHIFT_FROM_ALIGNMENT(object_alignment)) <= 16 ? 1 : 0)\n\n#define CAN_USE_RTE_PTR_COMPRESS_32(memory_range, object_alignment) \\\n\t((BITS_REQUIRED_TO_STORE_VALUE(memory_range) - \\\n\tBIT_SHIFT_FROM_ALIGNMENT(object_alignment)) <= 32 ? 1 : 0)\n\nAnd explain usage in the docs.\n\nThe API is very generic and does not even require you to use a mempool.\nThere are no runtime checks to verify or calculate if the pointers can\nbe compressed. This is because doing this at runtime would remove any\ngains achieved through compression. The code doing the compression needs\nto remain limited in size, branching and execution time to remain fast.\n\nThis is IMHO the nature of C applications, they trade off runtime checks\nfor performance. Program correctness needs to be enforced through other\nmeans, linting, valgrind, tests, peer review, etc. It is up to the\nprogrammer to calculate and decide on the viability of compression as it\ncannot be done at compile time automatically. There is no way for me to\nprogrammatically verify the alignment and distance of the pointers being\npassed in at compile time as I don't require the user to use any\nparticular mempool implementation.\n\nThese limitations are clearly documented in the API and the guide.\n\n> Or probably you can go even further: take some existing pipeline sample app and make it use compress/decompress API.\n> That will provide people with some ability to test it and measure it's perf impact.\n> Again, it will provide an example of the amount of changes required to enable it.\n> My speculation here that majority of users will find the effort too big, \n> while the gain way too limited and fragile.\n> But at least, there would be some realistic reference point for it and users can decide themselves is it worth it or not. \n\nI have added a performance test that runs the compression and\ndecompression loop with different burst sizes so that you can easily\ntest if attempting compression is worth the the effort in your usecase.\nThis is documented in the guide.\n\n> \n>>>\n>>> I would like to add:\n>>> If we want to offer optimizations specifically for applications with a single mbuf pool, I think it should be considered in a system-wide\n>> context to determine if performance could be improved in more areas.\n>>> 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\n>> 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\n>> second cache line, only to be used if the global \"single mbuf pool\" is NULL.)\n>> Agree on this. The feedback I have received is on similar lines, many are using simple features. I also received feedback that 90% of\n>> the applications use less than 4GB of memory for mbuf and burst sizes are up to 256.\n> \n> Well, from my perspective the story is completely different:\n> Majority of real-world apps I am aware do use multiple mempools,\n> it is also not uncommon to have a mempools with size bigger then 4GB (8/16).\n> Again, there are queries to make mempools growable/shrinkable on demand.\n\nYou can use this API with mempools even as big as 32GB as long as your\nalignment allows for sufficient shift (as explained in the headers and\ndocs) and rte_mempool objects will have at least 8 bytes alignment so\ncan fit a 32GB mempool in. It is true that you cannot use it if you\ncannot guarantee the address range at compile time. This utility is not\na golden bullet to use on every pointer.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from mails.dpdk.org (mails.dpdk.org [217.70.189.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id AA59E44038;\n\tWed, 15 May 2024 19:01:09 +0200 (CEST)", "from mails.dpdk.org (localhost [127.0.0.1])\n\tby mails.dpdk.org (Postfix) with ESMTP id 2E57A402C2;\n\tWed, 15 May 2024 19:01:09 +0200 (CEST)", "from EUR04-DB3-obe.outbound.protection.outlook.com\n (mail-db3eur04on2043.outbound.protection.outlook.com [40.107.6.43])\n by mails.dpdk.org (Postfix) with ESMTP id 8FE904021D\n for <dev@dpdk.org>; Wed, 15 May 2024 19:01:07 +0200 (CEST)", "from DU2PR04CA0296.eurprd04.prod.outlook.com (2603:10a6:10:28c::31)\n by DB3PR08MB9010.eurprd08.prod.outlook.com (2603:10a6:10:42b::8) with\n Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.55; Wed, 15 May\n 2024 17:01:04 +0000", "from DU2PEPF00028D10.eurprd03.prod.outlook.com\n (2603:10a6:10:28c:cafe::2e) by DU2PR04CA0296.outlook.office365.com\n (2603:10a6:10:28c::31) with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7587.25 via Frontend\n Transport; Wed, 15 May 2024 17:01:04 +0000", "from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by\n DU2PEPF00028D10.mail.protection.outlook.com (10.167.242.24) with\n Microsoft\n SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7544.18\n via Frontend Transport; Wed, 15 May 2024 17:01:04 +0000", "(\"Tessian outbound 9d9bf1c5d85a:v315\");\n Wed, 15 May 2024 17:01:04 +0000", "from 38a9983d53e7.2\n by 64aa7808-outbound-1.mta.getcheckrecipient.com id\n 396B305F-BDFF-435A-8256-9467CB23965D.1;\n Wed, 15 May 2024 17:00:58 +0000", "from EUR05-VI1-obe.outbound.protection.outlook.com\n by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id\n 38a9983d53e7.2\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);\n Wed, 15 May 2024 17:00:58 +0000", "from DB4PR08MB8151.eurprd08.prod.outlook.com (2603:10a6:10:381::16)\n by VI1PR08MB10198.eurprd08.prod.outlook.com (2603:10a6:800:1be::8)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.55; Wed, 15 May\n 2024 17:00:55 +0000", "from DB4PR08MB8151.eurprd08.prod.outlook.com\n ([fe80::79fc:e321:c17d:31f2]) by DB4PR08MB8151.eurprd08.prod.outlook.com\n ([fe80::79fc:e321:c17d:31f2%5]) with mapi id 15.20.7587.026; Wed, 15 May 2024\n 17:00:54 +0000" ], "ARC-Seal": [ "i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass;\n b=Hqwb/vgJbV5ohjng/kwiC9pP/eabtrGLybGY1tF74M/iBvw65L+kP+Yc06cFB1RQ+XcvWt9mKH9AR/6eRhgiBm1nP+l0ZFaXQTisFM/rgK0KJMtzBcVotBikaGs81YzaFSJRmC9U9qfD3Agc9LiSkgkuZJ7feV/7gwkPzzCHMEytCRWGjvWWvWgZgL6kqjtM3Zsvb4f12j/fVEe/pX3KynS5GMCVIGCFnDImTraiqUPinHnCGVq+uaZ5CjxzQ3vi0hwfiBBk1Y4Ov9tpVubyaEaL47sEW2NIKJ0ViyXkvpGi/HjZ5D0dDc11Y2GFIssKGHFgqvh7ZJ4vN38H3fzmcQ==", "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=IsnDYwGuvMf2I3ITRGGmKo2I8yEcMztPBohjYgNBLFnjEIMp5w+V4GRTzLOt/K/TPBc/xexwJBYfIm2nQsgRrQVPjnEFvBl61epVZX9pb1TSJQMpkY2yu6EEikF7D1aEjij1e6EbkUvm36H9Wfq4U0iMWop/oCp21d66/DUchFTvrNCK0yW9bPjrVOZyPhmatwklNyF6xdsSGeO1BwOqkjbxU2EAh1iCtZ8XCcW8SwXe2BqR/J1C3Ejw2BUw2z20zF9jIQWCO9G1Wyj1Ur3d7nRIvfEf/u2l6V8Th2N3xBp1Q6i38otMubF5/eAAW3+0bE8+YL2j8RN5FNJLH/IzJg==" ], "ARC-Message-Signature": [ "i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n 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;\n bh=JuSBv1i8SthNyyhwN+SABB+a09/q+2Sp5Pwb2KpjhRE=;\n b=BHZqncj/22QznDpvP3ID7Apx7Irt7f0cqYCFFyQuci38vd2WK2wMP9PxlGobQMEDjNaLJ9jG+TD6HQKM44X9tHIAbth+ud9UVhmubwa7CJrnWwde5cWIwcat6/7Dbg7ov8HsKvYR7T5ugXJeqp74QY9cYkxJyecScDnGHR0dm+0+dZgZtzz7i0KhHI9PFvcvXY+Xlluy5ViC945RvZYHWGbbP43G1F67Sjh3fLWZsEBqWTN+SPLNZw3Pb5P+F0Hem2sap0SLT87if7At/cy/G659l78Lsrt+U5Sry0MR3DtGlh4DrOHonhanb6524KiJTuzPNINTFwFnvABtUkKr1g==", "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n 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;\n bh=JuSBv1i8SthNyyhwN+SABB+a09/q+2Sp5Pwb2KpjhRE=;\n b=ao/1PtuW1gfPkT8fBrm0diJN9owa80hRGA5YQVHz4GClhy8Pk+LAGx3+R+3ySDp/XjlS84F5nebk2m8ZdSLMEVM5bwuDAy2jk6uOdiF373720fSnPGc0+kkJkHoM/IiZi+Zhifz/3kG+mqTAD71DCcqIDVndOqMP/ARE59ks7yYgk93iiXBVHh9POXPckjQlRGW6hcg0W7flCFCZ4ap0PQ80j1REyteWXDkyUDEiQwlhtAlRs3jL7FiuLoaFUGosyGgWfcjZgt1UI54PUj7noctItmSdMTy8O3EoJlJ5dvl1DoG0Sh74zI8xTndFxUsWZ0thMRVXAZw64M/DloNE/Q==" ], "ARC-Authentication-Results": [ "i=2; mx.microsoft.com 1; spf=pass (sender ip is\n 63.35.35.123) smtp.rcpttodomain=dpdk.org smtp.mailfrom=arm.com; dmarc=pass\n (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass\n (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1\n spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]\n dmarc=[1,1,header.from=arm.com])", "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass\n header.d=arm.com; arc=none" ], "DKIM-Signature": [ "v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=JuSBv1i8SthNyyhwN+SABB+a09/q+2Sp5Pwb2KpjhRE=;\n b=f1BF9LlT7/mSvejrZRf3Ivlls6cFXTJHkPEI+NdfvUrsHh94WDv7vZ+A3rzhMvV5dLl+QH5w6qrAl17n8qj4efeYmxo/C3XMkrnjkcDe6iEJhGmKu5tguryiHwv8Dh/9aGp+Ao+McuIpEW6pycsuZgAxwTLPslMrGp4lIniHQ4o=", "v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=JuSBv1i8SthNyyhwN+SABB+a09/q+2Sp5Pwb2KpjhRE=;\n b=f1BF9LlT7/mSvejrZRf3Ivlls6cFXTJHkPEI+NdfvUrsHh94WDv7vZ+A3rzhMvV5dLl+QH5w6qrAl17n8qj4efeYmxo/C3XMkrnjkcDe6iEJhGmKu5tguryiHwv8Dh/9aGp+Ao+McuIpEW6pycsuZgAxwTLPslMrGp4lIniHQ4o=" ], "X-MS-Exchange-Authentication-Results": "spf=pass (sender IP is 63.35.35.123)\n smtp.mailfrom=arm.com; dkim=pass (signature was verified)\n header.d=arm.com;dmarc=pass action=none header.from=arm.com;", "Received-SPF": "Pass (protection.outlook.com: domain of arm.com designates\n 63.35.35.123 as permitted sender) receiver=protection.outlook.com;\n client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;\n pr=C", "X-CheckRecipientChecked": "true", "X-CR-MTA-CID": "c7209ccc06bf7877", "X-CR-MTA-TID": "64aa7808", "Authentication-Results-Original": "dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=arm.com;", "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\" <dev@dpdk.org>,\n Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>, =?utf-8?q?Morten_Br?=\n\t=?utf-8?q?=C3=B8rup?= <mb@smartsharesystems.com>", "Subject": "Re: RE: [PATCH v5 0/4] add pointer compression API", "Content-Language": "en-US", "To": "Konstantin Ananyev <konstantin.ananyev@huawei.com>,\n \"konstantin.v.ananyev@yandex.ru\" <konstantin.v.ananyev@yandex.ru>", "References": "<20230927150854.3670391-2-paul.szczepanek@arm.com>\n <20231101181301.2449804-1-paul.szczepanek@arm.com>\n <7058331a-d829-4f0e-8634-726ca3be1ef2@arm.com>\n <a2d7d4eea5dc4cb3b763cb75566924ff@huawei.com>\n <98CBD80474FA8B44BF855DF32C47DC35E9F290@smartserver.smartshare.dk>\n <7D23A333-9846-4A34-A8B5-FDC11F042025@arm.com>\n <18e97877c4a64521a02317a329572866@huawei.com>", "From": "Paul Szczepanek <paul.szczepanek@arm.com>", "In-Reply-To": "<18e97877c4a64521a02317a329572866@huawei.com>", "Content-Type": "text/plain; charset=UTF-8", "Content-Transfer-Encoding": "7bit", "X-ClientProxiedBy": "LO4P265CA0251.GBRP265.PROD.OUTLOOK.COM\n (2603:10a6:600:350::19) To DB4PR08MB8151.eurprd08.prod.outlook.com\n (2603:10a6:10:381::16)", "MIME-Version": "1.0", "X-MS-TrafficTypeDiagnostic": "\n 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?q?fZYklOuGVxs7UdK/w7pQi9?=\n\t=?utf-8?q?vWHr6XcTKVbnT+lzLNQV1n6BjFH/1BrKbqncTNsWNE5fhlVfcZUlyU/2/tJs700JQ?=\n\t=?utf-8?q?5rzYRrgSV91deSOzMV3+6lczfso5j28iBpeQRrtrxJNYA2QPGcozm+1AO/rred0TQ?=\n\t=?utf-8?q?cuw+Wqxn5Vf6dJJrpTeH8bKBxd6IP9i9Xk8INMdtYrZ8z4A0KZ6Z4FzhVsnC+GEE9?=\n\t=?utf-8?q?7PReVpU2AEf/ATXVovHeN56g6njdaLo0IkXK20DPh3BefCScUe4OQ+ONxjRKF7Ie5?=\n\t=?utf-8?q?zeil2ra8TQacah+BS0i1/K3aWlmX6H5thX5zKLdy3nQStIMVM2m+qVzYCunIFMbWi?=\n\t=?utf-8?q?R6ujgxIqARKBEgL+C1i5Jf5GCGiM0Dzsp76PPcN0bhxmVl+cBk+lH9SlaAnvAMOSo?=\n\t=?utf-8?q?wyIlW7xjEGjd3TUFy0k80HIE5+9VvcbYkT+0rPXHgDxpFC+lp3660XwW98l23NFuT?=\n\t=?utf-8?q?ng4XEyKsdVi59oXIWT+r03tAyyfDhUHLZ1dUd3AmI+Htd+0/2oIcjaPxrn5LLLPpU?=\n\t=?utf-8?q?umffRdwjWNG1Uzs+sEyLK81r/5W/pyznTsJk6s6iMmI+BRMhN/d0r096hGsnZGFp5?=\n\t=?utf-8?q?vrh44xPT+P5spFkLrFihkwa1pu9D7VSHA/ufYqsNKd0LKQsTImfwPZuEWqbC4VqCD?=\n\t=?utf-8?q?zxIgni7IJvj6LtxqrdIQvHRGG7dMtA37pz4lFPfMRza0j3mIiyGPsq3Q1AWD3rwsz?=\n\t=?utf-8?q?St22+QRlXWWpY+NiKw4UjRBJ5ctyWGitQtf8geSlCtnZmjk3ivWSCwzDH4XvzaOY6?=\n\t=?utf-8?q?PuxdKfvVlCfgIgOfsJbJX2uJ3zC3fiigYc0aw2Y7Ivm/30ZOzTHTo3nSPyNQp4i8S?=\n\t=?utf-8?q?tb77eDcHTwKncisT5x7Kg+ItQrYk//g0LNfdXZxxfuZb9CX2kFoCimNBa5LubTIwF?=\n\t=?utf-8?q?RfyjswRt2CzDZyIoJEU7OMUyLc9F1nwwertzvFOEx/5ou/W74J+5BtYEDwv7NGIEz?=\n\t=?utf-8?q?7Kv41f5YZjHTVdNTqFxOPYtVEN+zAGiZ9a4ZbZ4q6rvvW6HQCUotu3XFtrY7EYshN?=\n\t=?utf-8?q?ZrPN05u7+V8QcMfa8JU9mzGAu9qQtsI/v2Z2JNzDAgNq4Xfxnj6vdhiZxik87vS9B?=\n\t=?utf-8?q?zR4Gh15j7Zd0jvYRuzoHhV5ZGaY/0ObL/kNXes1t6UNMoa/u/Dz5aUDSL3nmNudZ5?=\n\t=?utf-8?q?ClINYm022fErQ7iIdWwaBIrsWA8gqZQki8m2jodDiF/9AHbrgl/UJH1mkLWU8Z1nl?=\n\t=?utf-8?q?x3J22vTY/dXUm6B0/g/+Z6FoM3m6NN8misctRaEYoigfg=3D=3D?=", "X-Forefront-Antispam-Report-Untrusted": "CIP:255.255.255.255; CTRY:; LANG:en;\n SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB4PR08MB8151.eurprd08.prod.outlook.com;\n PTR:; CAT:NONE; SFS:(13230031)(376005)(366007)(1800799015); DIR:OUT;\n SFP:1101;", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": [ "VI1PR08MB10198", "DB3PR08MB9010" ], "Original-Authentication-Results": "dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=arm.com;", "X-EOPAttributedMessage": "0", "X-MS-Exchange-Transport-CrossTenantHeadersStripped": "\n DU2PEPF00028D10.eurprd03.prod.outlook.com", "X-MS-PublicTrafficType": "Email", "X-MS-Office365-Filtering-Correlation-Id-Prvs": "\n 1c5502b8-4f68-45e9-f350-08dc7500950b", "X-Microsoft-Antispam": "BCL:0;\n ARA:13230031|376005|36860700004|1800799015|82310400017|35042699013;", "X-Microsoft-Antispam-Message-Info": "=?utf-8?q?htivqhypaCca42uhf2oi0asZE7hTU7H?=\n\t=?utf-8?q?gUOhT0/63Y1WTZOdJh73X6VkTF9eOLXByzXla8zjfckBLEo9HZ7ncpt8ZU+71Nk9C?=\n\t=?utf-8?q?b5+KLyo9o/E6oNLtcdowvNFS0Vi6+qU71BCU8nHiM6LZIqSSNsPuxx4AUwxReCOMc?=\n\t=?utf-8?q?N2/y0Qliftj9qoBztGDoWjkZ5DxFVKyDB6a4Eu4rFXY216ACXCu7haleb5pJJDQOk?=\n\t=?utf-8?q?nP88EDQOK6eg2ulVj1uVeRGIUfI4IzRXv/WPO7GzKR0oKndDpAh7pgeQLMhvtTHDK?=\n\t=?utf-8?q?xP5ynWoAUB2qbFHGajgBa9ukvmvQ2Ek0NPJnt81e40W9+cHQU++DquuHQnUOMWcmP?=\n\t=?utf-8?q?SaTrbSbX86JAIynO5pOMMk32AnYohdbuUZfIYEwyZNp5LCF7LXT/zSMrBQJYvWILD?=\n\t=?utf-8?q?vBkBcYyAK9RJAhopg4h/CxL90L9Io1AhVj+ZdvXL1QdmYSSUbOJ2+b9TMvKWI/pBz?=\n\t=?utf-8?q?9bJ6nmf9AoLjw/gGc0jAUzk+Agtqe89lE7LuO4PMinbCwxDJ+f38jqgjJzkqJ8m0H?=\n\t=?utf-8?q?YrU+3pAJRSgEqLp4PnAhglfc9bypFS8E5qzi+aoD7JHLv71ZByHNZjTZ+4IHdFyaS?=\n\t=?utf-8?q?91OgD0eSnUt0cLlm2inTYYRyrZtJyUwpLFAm32tdOBl+T8Xw/KtxqY4V5KpRDJQCR?=\n\t=?utf-8?q?oE65dz95r0lsO3N8MyaZY1J+NJR3KhYerJc83G+RBYCDhdN5qjA7lVaLAbxw69WuZ?=\n\t=?utf-8?q?nmYflJqJO6mBJHU6l+gV+pccvXv0Bk0RY21xDg4oPE5Dvvtj7/Kn3i0t2KwBUjuN6?=\n\t=?utf-8?q?XRYwirw8A2rGnTgE1u2XC7vsdM7yoKJiplr/DPKF0QT7zT+4ygN+pEWR2sYsxmLT6?=\n\t=?utf-8?q?g7U/qUTBa1UFhZnAihBa+jqvGI4lk7jMSyxX5X90unhyFP6a8OKZFAv6hJaOpOya4?=\n\t=?utf-8?q?ALEXAw0BX5qv2vzDr1YnN5081zEdSfoNYqAz1emMvsjKbyHUwgOeo7HZqTWb2J4mq?=\n\t=?utf-8?q?Eh4rbAhsWQZcSVEHIAO1Qryft2f2g+D0uDGiND50hG6ZlPnsSr19eS5HhnBFyvMJb?=\n\t=?utf-8?q?h3Cava9oMGTvzXsEhLiZ4675CqwInxuQ+I4Q6wr4fLtwnklSRBvcxWfgCFG4zXAmg?=\n\t=?utf-8?q?68iySiXj36//vLwuKtkKeLoHNZXIbVKKvbXOv4TWMzb/IEei6z5FRvS/ZO5qneF6S?=\n\t=?utf-8?q?0dPbCpEDNMRNz/1BohCLJEyCfhDQqbW+lv+5kWlGhpW+oDK7lwkvQNZA3zaGJcpmS?=\n\t=?utf-8?q?VMTW6aMs+7VC1oJ1Q+nbrLo9Fe90RcNnHSnks316e4ooAdxDCiIkvGCUNuxwZFdG9?=\n\t=?utf-8?q?yPLN2nv5FP4XUmXO+DbJaNchcQGzd49ReKPGLXjZ0nSvXgAe2zRkxj89hpjA5Fk+/?=\n\t=?utf-8?q?VXXrLrfDbi7g?=", "X-Forefront-Antispam-Report": "CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;\n IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;\n PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE;\n SFS:(13230031)(376005)(36860700004)(1800799015)(82310400017)(35042699013);\n 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": "\n 0d5522fb-4453-4839-0175-08dc75009b2c", "X-MS-Exchange-CrossTenant-Id": "f34e5979-57d9-4aaa-ad4d-b122a662184d", "X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp": "\n TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];\n Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]", "X-MS-Exchange-CrossTenant-AuthSource": "\n DU2PEPF00028D10.eurprd03.prod.outlook.com", "X-MS-Exchange-CrossTenant-AuthAs": "Anonymous", "X-MS-Exchange-CrossTenant-FromEntityHeader": "HybridOnPrem", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.29", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <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>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org" }, "addressed": null }