Cover Comment List
List cover comments
GET /api/covers/44349/comments/?format=api
[ { "id": 85565, "web_url": "http://patches.dpdk.org/comment/85565/", "msgid": "<AM6PR08MB3672DCC3B1216CA9F730B03698190@AM6PR08MB3672.eurprd08.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/AM6PR08MB3672DCC3B1216CA9F730B03698190@AM6PR08MB3672.eurprd08.prod.outlook.com", "date": "2018-09-14T21:18:39", "subject": "Re: [dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "submitter": { "id": 1045, "url": "http://patches.dpdk.org/api/people/1045/?format=api", "name": "Honnappa Nagarahalli", "email": "honnappa.nagarahalli@arm.com" }, "content": "I have added the memory ordering ladder diagrams to the DPDK summit slides to help understand the changes. The slides are available at: https://dpdkuserspace2018.sched.com/event/G44w/lock-free-read-write-concurrency-in-rtehash. Please look at the backup slides.\n\nThank you,\nHonnappa\n\n-----Original Message-----\nFrom: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> \nSent: Thursday, September 6, 2018 12:12 PM\nTo: bruce.richardson@intel.com; pablo.de.lara.guarch@intel.com\nCc: dev@dpdk.org; honnappa.nagarahalli; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Steve Capper <Steve.Capper@arm.com>; Ola Liljedahl <Ola.Liljedahl@arm.com>; nd <nd@arm.com>; Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>\nSubject: [PATCH 0/4] Address reader-writer concurrency in rte_hash\n\n Currently, reader-writer concurrency problems in rte_hash are\n addressed using reader-writer locks. Use of reader-writer locks\n results in following issues:\n \n 1) In many of the use cases for the hash table, writer threads\n are running on control plane. If the writer is preempted while\n holding the lock, it will block the readers for an extended period\n resulting in packet drops. This problem seems to apply for platforms\n with transactional memory support as well because of the algorithm\n used for rte_rwlock_write_lock_tm:\n \n static inline void\n rte_rwlock_write_lock_tm(rte_rwlock_t *rwl)\n {\n if (likely(rte_try_tm(&rwl->cnt)))\n return;\n rte_rwlock_write_lock(rwl);\n }\n \n i.e. there is a posibility of using rte_rwlock_write_lock in\n failure cases.\n 2) Reader-writer lock based solution does not address the following\n issue.\n rte_hash_lookup_xxx APIs return the index of the element in\n the key store. Application(reader) can use that index to reference\n other data structures in its scope. Because of this, the\n index should not be freed till the application completes\n using the index.\n 3) Since writer blocks all the readers, the hash lookup\n rate comes down significantly when there is activity on the writer.\n This happens even for unrelated entries. Performance numbers\n given below clearly indicate this.\n \n Lock-free solution is required to solve these problems. This patch\n series adds the lock-free capabilities in the following steps:\n \n 1) Correct the alignment for the key store entry to prep for\n memory ordering.\n 2) Add memory ordering to prevent race conditions when a new key\n is added to the table.\n \n 3) Reader-writer concurrency issue, caused by moving the keys\n to their alternate locations during key insert, is solved\n by introducing an atomic global counter indicating a change\n in table.\n \n 4) This solution also has to solve the issue of readers using\n key store element even after the key is deleted from\n control plane.\n To solve this issue, the hash_del_key_xxx APIs do not free\n the key store element. The key store element has to be freed\n using the newly introduced rte_hash_free_key_with_position API.\n It needs to be called once all the readers have stopped using\n the key store element. How this is determined is outside\n the scope of this patch (RCU is one such mechanism that the\n application can use).\n \n 4) Finally, a lock free reader-writer concurrency flag is added\n to enable this feature at run time.\n \n Performance numbers:\n Scenario: Equal number of writer/reader threads for concurrent\n\t writers and readers. For readers only test, the\n entries are added upfront.\n\n Current code:\n\tCores\tLookup Lookup\n\t\twith add\n\t2\t474\t 246\n\t4\t935 579\n\t6\t1387 1048\n\t8\t1766 1480\n\t10\t2119 1951\n\t12\t2546 2441\n\n With this patch:\n\tCores\tLookup Lookup\n\t\twith add\n\t2\t291\t 211\n\t4\t297\t 196\n\t6\t304\t 198\n\t8\t309\t 202\n\t10\t315\t 205\n\t12\t319\t 209\n\nHonnappa Nagarahalli (4):\n hash: correct key store element alignment\n hash: add memory ordering to avoid race conditions\n hash: fix rw concurrency while moving keys\n hash: enable lock-free reader-writer concurrency\n\n lib/librte_hash/rte_cuckoo_hash.c | 445 +++++++++++++++++++++++++----------\n lib/librte_hash/rte_cuckoo_hash.h | 6 +-\n lib/librte_hash/rte_hash.h | 63 ++++-\n lib/librte_hash/rte_hash_version.map | 7 +\n 4 files changed, 393 insertions(+), 128 deletions(-)", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id ADE094D3A;\n\tFri, 14 Sep 2018 23:18:43 +0200 (CEST)", "from EUR01-VE1-obe.outbound.protection.outlook.com\n\t(mail-ve1eur01on0058.outbound.protection.outlook.com [104.47.1.58])\n\tby dpdk.org (Postfix) with ESMTP id A3D1C4CA6\n\tfor <dev@dpdk.org>; Fri, 14 Sep 2018 23:18:41 +0200 (CEST)", "from AM6PR08MB3672.eurprd08.prod.outlook.com (20.177.115.29) by\n\tAM6PR08MB3160.eurprd08.prod.outlook.com (52.135.164.21) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1122.16; Fri, 14 Sep 2018 21:18:39 +0000", "from AM6PR08MB3672.eurprd08.prod.outlook.com\n\t([fe80::589e:d3cf:9777:5ff9]) by\n\tAM6PR08MB3672.eurprd08.prod.outlook.com\n\t([fe80::589e:d3cf:9777:5ff9%2]) with mapi id 15.20.1122.018;\n\tFri, 14 Sep 2018 21:18:39 +0000" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;\n\ts=selector1-arm-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=MH0iJt6Pm9BuP8MOTyb7YLrlVC90HxkQoM0/MkKhqH0=;\n\tb=L2L0gpcoJIkG3WGK01OGadJGmv+JAiLu4Mi23QgUZ5UUN+3+AIksErkY90Td8JyJPNNNGCAssoge1u0T45jqPpFe1zcN1Dk8iuketIoAIwwLIPoLOa/NFeoMwTZG5sYB7IBz8ECz9ztImHu/APfXaEgUHXAyg+/egW9HTCIt+w0=", "From": "Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>", "To": "Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,\n\t\"bruce.richardson@intel.com\" <bruce.richardson@intel.com>,\n\t\"pablo.de.lara.guarch@intel.com\" <pablo.de.lara.guarch@intel.com>", "CC": "\"dev@dpdk.org\" <dev@dpdk.org>, honnappa.nagarahalli\n\t<IMCEAINVALID-honnappa+2Enagarahalli@eurprd08.prod.outlook.com>,\n\t\"Gavin Hu (Arm Technology China)\" <Gavin.Hu@arm.com>, Steve Capper\n\t<Steve.Capper@arm.com>, Ola Liljedahl <Ola.Liljedahl@arm.com>, nd\n\t<nd@arm.com>, \"yipeng1.wang@intel.com\" <yipeng1.wang@intel.com>, Michel\n\tMachado <michel@digirati.com.br>, \"sameh.gobriel@intel.com\"\n\t<sameh.gobriel@intel.com>", "Thread-Topic": "[PATCH 0/4] Address reader-writer concurrency in rte_hash", "Thread-Index": "AQHURgTKqGcS9ICsZUeJFhcyzG1braTwU7bw", "Date": "Fri, 14 Sep 2018 21:18:39 +0000", "Message-ID": "<AM6PR08MB3672DCC3B1216CA9F730B03698190@AM6PR08MB3672.eurprd08.prod.outlook.com>", "References": "<1536253938-192391-1-git-send-email-honnappa.nagarahalli@arm.com>", "In-Reply-To": "<1536253938-192391-1-git-send-email-honnappa.nagarahalli@arm.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "x-originating-ip": "[217.140.111.135]", "x-ms-publictraffictype": "Email", "x-microsoft-exchange-diagnostics": "1; AM6PR08MB3160;\n\t6:pSkKIM/e7o/NGhgmV9KPJ4lUTXqR3rYuP8Spf7h3eGZHu/8sXgVsr2rAdvU1UdSFzHAe2V4V5+g+aQNnRi11jgWB+xkctrTdQaffoCBd5qQ36brSBEK1tUhPEOJX0DB8/EUcsrBDqn0Ky7d0BLJL4Gz4R19sc8BJgBGR0GmkRA10cDvqeRu+VAqNzSa5hGgoqVsY+G53L+hVjKHEDyccSuLSY/DMRB8oYOAsVJviyCWAuK/Z7Be1np1UWBcjBvfgJ+6LA8nlk3rO59lhSwQ6Kln8AOY1kZL12FQ4txN2u1P+VEkc7JKDxIe1Fl2NH/bGJ2TrDLfmdd3KHIJD0GA/5HO557FdMyg3KSWeeALvTYDWT5HVSIosY7Aw8f1zPcWTPhSjvRmarg1qeTzThxVNd0c1xHNYWljZMpARRRZAwUFMC89tZkw5+/2gS5FN0UBUx1ljQXPJKlZV8Vr1Tpif3Q==;\n\t5:pjWAMOfUvl7R+CaGS7lR3i2A/ZxQOTLtIM4Jf8AMEQIuutybkQu6HBxoPbbfvxbVGpLBAAdRWYBaeFuThderwliKDt20uTIPZ0d312McShz4O/0BI+PkCdAhXjKaTfzBP1X+XUUMOHHwQBeGvUvAuD9UGFnUkM9fibBqlJbEDYo=;\n\t7:3k7E3i0wdwB6tumhHhVaM+gDOJSTlUz1ZnYlPlcQF9sWJ29ZB+b0Y9VZM+CA5Zog8ZfhpZ53VNTMFuFDYx817pceKmR3mJirPkzoAOz3Z75UZZlOlcokHN57VtwVISFa1LH/lbFCAIKWgL3Hr3jKwx9C4mddf6uxFR5wCoL6In/vVNl3LzK4KBwsvM5BCj11MO77mS5Am1jqBvRPZ3mjhA240uVxgpAN4UxcDedo61HbPSQoHGr76fHq5SxfK1HA", "x-ms-exchange-antispam-srfa-diagnostics": "SOS;SOR;", "x-ms-office365-filtering-correlation-id": "9bc4cd2e-6330-4656-c398-08d61a87a41f", "x-ms-office365-filtering-ht": "Tenant", "x-microsoft-antispam": "BCL:0; PCL:0;\n\tRULEID:(7020095)(4652040)(8989137)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020);\n\tSRVR:AM6PR08MB3160; ", "x-ms-traffictypediagnostic": "AM6PR08MB3160:", "nodisclaimer": "True", "x-microsoft-antispam-prvs": "<AM6PR08MB31601738B137B476619B496898190@AM6PR08MB3160.eurprd08.prod.outlook.com>", "x-exchange-antispam-report-test": "UriScan:(180628864354917)(228905959029699); ", "x-ms-exchange-senderadcheck": "1", "x-exchange-antispam-report-cfa-test": "BCL:0; PCL:0;\n\tRULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231344)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(201708071742011)(7699050)(76991041);\n\tSRVR:AM6PR08MB3160; BCL:0; PCL:0; RULEID:; SRVR:AM6PR08MB3160; ", "x-forefront-prvs": "07954CC105", "x-forefront-antispam-report": "SFV:NSPM;\n\tSFS:(10009020)(39860400002)(366004)(136003)(396003)(346002)(376002)(189003)(199004)(13464003)(2900100001)(25786009)(106356001)(256004)(14454004)(6116002)(5660300001)(14444005)(229853002)(3846002)(446003)(53936002)(97736004)(105586002)(316002)(8936002)(54906003)(55016002)(4326008)(7696005)(6436002)(6246003)(76176011)(33656002)(110136005)(486006)(81156014)(81166006)(99286004)(8676002)(7736002)(2201001)(305945005)(6506007)(53546011)(72206003)(102836004)(86362001)(476003)(68736007)(9686003)(966005)(6346003)(478600001)(2906002)(26005)(6306002)(74316002)(11346002)(2501003)(66066001)(5250100002)(21314002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3160;\n\tH:AM6PR08MB3672.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en;\n\tPTR:InfoNoRecords; MX:1; A:1; ", "received-spf": "None (protection.outlook.com: arm.com does not designate\n\tpermitted sender hosts)", "authentication-results": "spf=none (sender IP is )\n\tsmtp.mailfrom=Honnappa.Nagarahalli@arm.com; ", "x-microsoft-antispam-message-info": "3rvNeJmcXDmvafNjqf7rg0N7ZZcQCuMKJnanI+x+c9Tn/ZtbfHmln4pQlAZIpXYyvvqzcACpZTENCjcHcLUW97oY1STM34XQ9COxp5YwNjyRf3YbPkbWaWu1jQfYUZi7BgGdZlMWtXDsZZfCX6TNw8tMX9IoC/8ZXImF/FHYFJWGZfo0NO3/vonFjCIKpqxdIBodW8PZsmAHX0y+muWVLuf6P656y4aCpcz2oRmuLl4IsPFyGw8/237NhGY3fK7gNvD8wvqnau9cLfUwHNZrYLYWa8t9KHF01oESviGKDVUrP3Xo54VlyPxWKX5OJIvMv1nAk6H743YfeHhukBPEawelVCx1OLytpuigf6h66JA=", "spamdiagnosticoutput": "1:99", "spamdiagnosticmetadata": "NSPM", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-OriginatorOrg": "arm.com", "X-MS-Exchange-CrossTenant-Network-Message-Id": "9bc4cd2e-6330-4656-c398-08d61a87a41f", "X-MS-Exchange-CrossTenant-originalarrivaltime": "14 Sep 2018 21:18:39.4862\n\t(UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "f34e5979-57d9-4aaa-ad4d-b122a662184d", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "AM6PR08MB3160", "Subject": "Re: [dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "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>,\n\t<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\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 86168, "web_url": "http://patches.dpdk.org/comment/86168/", "msgid": "<AM6PR08MB367268604BE30F01A034128A98150@AM6PR08MB3672.eurprd08.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/AM6PR08MB367268604BE30F01A034128A98150@AM6PR08MB3672.eurprd08.prod.outlook.com", "date": "2018-09-26T14:36:43", "subject": "Re: [dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "submitter": { "id": 1045, "url": "http://patches.dpdk.org/api/people/1045/?format=api", "name": "Honnappa Nagarahalli", "email": "honnappa.nagarahalli@arm.com" }, "content": "Hi Bruce/Pablo,\n I need to get this into 18.11, appreciate any review/feedback soon.\n\nThank you,\nHonnappa\n\n> -----Original Message-----\n> From: Honnappa Nagarahalli\n> Sent: Friday, September 14, 2018 4:19 PM\n> To: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>;\n> bruce.richardson@intel.com; pablo.de.lara.guarch@intel.com\n> Cc: dev@dpdk.org; honnappa.nagarahalli; Gavin Hu (Arm Technology China)\n> <Gavin.Hu@arm.com>; Steve Capper <Steve.Capper@arm.com>; Ola Liljedahl\n> <Ola.Liljedahl@arm.com>; nd <nd@arm.com>; yipeng1.wang@intel.com;\n> Michel Machado <michel@digirati.com.br>; sameh.gobriel@intel.com\n> Subject: RE: [PATCH 0/4] Address reader-writer concurrency in rte_hash\n> \n> I have added the memory ordering ladder diagrams to the DPDK summit slides\n> to help understand the changes. The slides are available at:\n> https://dpdkuserspace2018.sched.com/event/G44w/lock-free-read-write-\n> concurrency-in-rtehash. Please look at the backup slides.\n> \n> Thank you,\n> Honnappa\n> \n> -----Original Message-----\n> From: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>\n> Sent: Thursday, September 6, 2018 12:12 PM\n> To: bruce.richardson@intel.com; pablo.de.lara.guarch@intel.com\n> Cc: dev@dpdk.org; honnappa.nagarahalli; Gavin Hu (Arm Technology China)\n> <Gavin.Hu@arm.com>; Steve Capper <Steve.Capper@arm.com>; Ola Liljedahl\n> <Ola.Liljedahl@arm.com>; nd <nd@arm.com>; Honnappa Nagarahalli\n> <Honnappa.Nagarahalli@arm.com>\n> Subject: [PATCH 0/4] Address reader-writer concurrency in rte_hash\n> \n> Currently, reader-writer concurrency problems in rte_hash are\n> addressed using reader-writer locks. Use of reader-writer locks\n> results in following issues:\n> \n> 1) In many of the use cases for the hash table, writer threads\n> are running on control plane. If the writer is preempted while\n> holding the lock, it will block the readers for an extended period\n> resulting in packet drops. This problem seems to apply for platforms\n> with transactional memory support as well because of the algorithm\n> used for rte_rwlock_write_lock_tm:\n> \n> static inline void\n> rte_rwlock_write_lock_tm(rte_rwlock_t *rwl)\n> {\n> if (likely(rte_try_tm(&rwl->cnt)))\n> return;\n> rte_rwlock_write_lock(rwl);\n> }\n> \n> i.e. there is a posibility of using rte_rwlock_write_lock in\n> failure cases.\n> 2) Reader-writer lock based solution does not address the following\n> issue.\n> rte_hash_lookup_xxx APIs return the index of the element in\n> the key store. Application(reader) can use that index to reference\n> other data structures in its scope. Because of this, the\n> index should not be freed till the application completes\n> using the index.\n> 3) Since writer blocks all the readers, the hash lookup\n> rate comes down significantly when there is activity on the writer.\n> This happens even for unrelated entries. Performance numbers\n> given below clearly indicate this.\n> \n> Lock-free solution is required to solve these problems. This patch\n> series adds the lock-free capabilities in the following steps:\n> \n> 1) Correct the alignment for the key store entry to prep for\n> memory ordering.\n> 2) Add memory ordering to prevent race conditions when a new key\n> is added to the table.\n> \n> 3) Reader-writer concurrency issue, caused by moving the keys\n> to their alternate locations during key insert, is solved\n> by introducing an atomic global counter indicating a change\n> in table.\n> \n> 4) This solution also has to solve the issue of readers using\n> key store element even after the key is deleted from\n> control plane.\n> To solve this issue, the hash_del_key_xxx APIs do not free\n> the key store element. The key store element has to be freed\n> using the newly introduced rte_hash_free_key_with_position API.\n> It needs to be called once all the readers have stopped using\n> the key store element. How this is determined is outside\n> the scope of this patch (RCU is one such mechanism that the\n> application can use).\n> \n> 4) Finally, a lock free reader-writer concurrency flag is added\n> to enable this feature at run time.\n> \n> Performance numbers:\n> Scenario: Equal number of writer/reader threads for concurrent\n> \t writers and readers. For readers only test, the\n> entries are added upfront.\n> \n> Current code:\n> \tCores\tLookup Lookup\n> \t\twith add\n> \t2\t474\t 246\n> \t4\t935 579\n> \t6\t1387 1048\n> \t8\t1766 1480\n> \t10\t2119 1951\n> \t12\t2546 2441\n> \n> With this patch:\n> \tCores\tLookup Lookup\n> \t\twith add\n> \t2\t291\t 211\n> \t4\t297\t 196\n> \t6\t304\t 198\n> \t8\t309\t 202\n> \t10\t315\t 205\n> \t12\t319\t 209\n> \n> Honnappa Nagarahalli (4):\n> hash: correct key store element alignment\n> hash: add memory ordering to avoid race conditions\n> hash: fix rw concurrency while moving keys\n> hash: enable lock-free reader-writer concurrency\n> \n> lib/librte_hash/rte_cuckoo_hash.c | 445 +++++++++++++++++++++++++-------\n> ---\n> lib/librte_hash/rte_cuckoo_hash.h | 6 +-\n> lib/librte_hash/rte_hash.h | 63 ++++-\n> lib/librte_hash/rte_hash_version.map | 7 +\n> 4 files changed, 393 insertions(+), 128 deletions(-)\n> \n> --\n> 2.7.4", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 232BE1B181;\n\tWed, 26 Sep 2018 16:36:47 +0200 (CEST)", "from EUR03-AM5-obe.outbound.protection.outlook.com\n\t(mail-eopbgr30070.outbound.protection.outlook.com [40.107.3.70])\n\tby dpdk.org (Postfix) with ESMTP id CDA661B14C\n\tfor <dev@dpdk.org>; Wed, 26 Sep 2018 16:36:45 +0200 (CEST)", "from AM6PR08MB3672.eurprd08.prod.outlook.com (20.177.115.29) by\n\tAM6PR08MB3384.eurprd08.prod.outlook.com (20.177.112.221) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1164.22; Wed, 26 Sep 2018 14:36:44 +0000", "from AM6PR08MB3672.eurprd08.prod.outlook.com\n\t([fe80::589e:d3cf:9777:5ff9]) by\n\tAM6PR08MB3672.eurprd08.prod.outlook.com\n\t([fe80::589e:d3cf:9777:5ff9%2]) with mapi id 15.20.1164.024;\n\tWed, 26 Sep 2018 14:36:44 +0000" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;\n\ts=selector1-arm-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=+zWqpblWgnrRebC7nLH9k7gLYmRdbyjbjPuDJpU5CsQ=;\n\tb=TxkYRE5lUwzMXpUj5Y7CNIq3/LCtSE81MjFYVD/EHwcE1TFl9ZSnWAisx/QSehsqfHnU4C96zMtLfikIt94UGNNxxcwWvG7i95soBQbSOlUmVPlbg5NRrOhNkGLhKZhhlVwRlGKu+aAYDXxZvHA7IlAX04w8zrdA3uV2ebnqinw=", "From": "Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>", "To": "Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,\n\t\"bruce.richardson@intel.com\" <bruce.richardson@intel.com>,\n\t\"pablo.de.lara.guarch@intel.com\" <pablo.de.lara.guarch@intel.com>", "CC": "\"dev@dpdk.org\" <dev@dpdk.org>, honnappa.nagarahalli\n\t<IMCEAINVALID-honnappa+2Enagarahalli@eurprd08.prod.outlook.com>,\n\t\"Gavin Hu (Arm Technology China)\" <Gavin.Hu@arm.com>, Steve Capper\n\t<Steve.Capper@arm.com>, Ola Liljedahl <Ola.Liljedahl@arm.com>, nd\n\t<nd@arm.com>, \"yipeng1.wang@intel.com\" <yipeng1.wang@intel.com>, Michel\n\tMachado <michel@digirati.com.br>, \"sameh.gobriel@intel.com\"\n\t<sameh.gobriel@intel.com>", "Thread-Topic": "[PATCH 0/4] Address reader-writer concurrency in rte_hash", "Thread-Index": "AQHURgTKqGcS9ICsZUeJFhcyzG1braTwU7bwgBJsctA=", "Date": "Wed, 26 Sep 2018 14:36:43 +0000", "Message-ID": "<AM6PR08MB367268604BE30F01A034128A98150@AM6PR08MB3672.eurprd08.prod.outlook.com>", "References": "<1536253938-192391-1-git-send-email-honnappa.nagarahalli@arm.com>\n\t<AM6PR08MB3672DCC3B1216CA9F730B03698190@AM6PR08MB3672.eurprd08.prod.outlook.com>", "In-Reply-To": "<AM6PR08MB3672DCC3B1216CA9F730B03698190@AM6PR08MB3672.eurprd08.prod.outlook.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "authentication-results": "spf=none (sender IP is )\n\tsmtp.mailfrom=Honnappa.Nagarahalli@arm.com; ", "x-originating-ip": "[217.140.111.135]", "x-ms-publictraffictype": "Email", "x-microsoft-exchange-diagnostics": "1; AM6PR08MB3384;\n\t6:prgAKUFCm8gFNqHGPwYlsRlhKduAlTZa7FifpGi37E6CYh5fZ5kit+MQmq51HhPEDNCvZwaa3DjU6sYYqg5mUpJxqRrX/Qa0petkeFxOKtluhp+c47kLzlpGYJnRuiQrC6/GP/PHIWW21LFo62mcKbd6f2ronsC4vdAY2Uv7iCc5Kthm7o+5JDkNrc4z4Fio9+FfPnds5g7DOxEIsJLmDFi9giLfl0ArP7dy2rPT1IyAZSwfG9Zc6s5h8EB/J6+VLfBheeRfXflMt3DtdjijeI3vHoOOFYnAPkhPDhbtMF699o27bR1P6e3JE6vac04bmcM4gbCPuNHgS1EakSzsxiMwRpRrzVleeQ2HEetAaCxnyTfsA0/7f3ubDkJdvWUG4LBWk8yY+Vr3D8Y8ZdTHwi6YGIgkj7W0aKW+eQ2oO2s/EXAyiBmPTo8d8ijIjWVdn6qN0TbY37/fAEvNK2WckA==;\n\t5:yUHFVH1Osn9UcbTbr28NU/HoLUswKLfE3gMhbG9BniDcJxBY0KXgUuH0AQSYMJSjDd5EtS+q4YK3yhdzL+S2LZJInGZFlbpO+ESBLGmI9XQnSgmlFfXGym51AMnbD4RamA2ngdxFnTvySig+1gQOJwPY9BdyVBvxPVlG5Z7kTMU=;\n\t7:4e+IHxkrKcfVllGYc5lBuvCy2s9H1SJD0DqlMBS6HpeDienzV/HpmDEYIWX0cwxekzE9y2H5wC7qx/mnBPt+5OlYwaSwbGe39kZ3F3NQrg2hQi02rjehn/zHZx6SMTX8w9gTh8LCSvVFx2BhrZb9xlR12aJw1Uz1KBmDKdMvql3dvR7QemBGDyysau8Ctngy+IK903IjPJnlKm458dixmQgyLrenXb+F2gkeM+O4ujRZ8w+q91OD+SRP+BJQPEnW", "x-ms-exchange-antispam-srfa-diagnostics": "SOS;SOR;", "x-ms-office365-filtering-correlation-id": "229afefa-8965-4dfa-0405-08d623bd7b1d", "x-ms-office365-filtering-ht": "Tenant", "x-microsoft-antispam": "BCL:0; PCL:0;\n\tRULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020);\n\tSRVR:AM6PR08MB3384; ", "x-ms-traffictypediagnostic": "AM6PR08MB3384:", "nodisclaimer": "True", "x-microsoft-antispam-prvs": "<AM6PR08MB3384A319368DB7F80CC451F598150@AM6PR08MB3384.eurprd08.prod.outlook.com>", "x-exchange-antispam-report-test": "UriScan:(228905959029699)(180628864354917)(166494164430575); ", "x-ms-exchange-senderadcheck": "1", "x-exchange-antispam-report-cfa-test": "BCL:0; PCL:0;\n\tRULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(10201501046)(6055026)(149066)(150057)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051);\n\tSRVR:AM6PR08MB3384; BCL:0; PCL:0; RULEID:; SRVR:AM6PR08MB3384; ", "x-forefront-prvs": "08076ABC99", "x-forefront-antispam-report": "SFV:NSPM;\n\tSFS:(10009020)(39860400002)(136003)(376002)(396003)(366004)(346002)(13464003)(189003)(199004)(2501003)(105586002)(25786009)(8676002)(5250100002)(33656002)(5660300001)(106356001)(2201001)(486006)(476003)(11346002)(86362001)(7696005)(446003)(76176011)(6436002)(99286004)(66066001)(97736004)(8936002)(110136005)(54906003)(9686003)(316002)(53936002)(6306002)(71190400001)(71200400001)(55016002)(68736007)(34290500001)(6116002)(3846002)(2906002)(2900100001)(4326008)(6246003)(26005)(14444005)(102836004)(256004)(966005)(6506007)(14454004)(74316002)(478600001)(53546011)(81166006)(81156014)(229853002)(7736002)(305945005)(72206003)(21314002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3384;\n\tH:AM6PR08MB3672.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en;\n\tPTR:InfoNoRecords; MX:1; A:1; ", "received-spf": "None (protection.outlook.com: arm.com does not designate\n\tpermitted sender hosts)", "x-microsoft-antispam-message-info": "sMHWHDyOKfW+WqHCRX8D1HvSF9/l0UwBNMIK9eejVLEfsGt+JB9ETz7HnpN7cZuNS/S1CXDaWQGWnn3wjqwRFJoprR/OUfudkpeW0fN4l/1iJpHcF9GOCV3q7+tzkXvp92aEvdHgfa7m4vzKjhoBeanokUBvMv/TD2I9oZvQTy1ZMm4Ntqre7a124W4QC/0UsAAavtgY3cOGrW8CO7vyF4mfoG7APXyy4oF5MpIXR8ZbsgmTAR3sV6tmmYS5Vy/+aHRN7ywBtHhojp/MQWpo/TVcyhCh0b70j9wYa30fAXRhJvf1pldUZsNLHKQ1MswdqntWejqv/YKd3r6tnwZgkZa2SCLrgX9VStYqAjAER8s=", "spamdiagnosticoutput": "1:99", "spamdiagnosticmetadata": "NSPM", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-OriginatorOrg": "arm.com", "X-MS-Exchange-CrossTenant-Network-Message-Id": "229afefa-8965-4dfa-0405-08d623bd7b1d", "X-MS-Exchange-CrossTenant-originalarrivaltime": "26 Sep 2018 14:36:43.9673\n\t(UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "f34e5979-57d9-4aaa-ad4d-b122a662184d", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "AM6PR08MB3384", "Subject": "Re: [dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "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>,\n\t<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\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 86280, "web_url": "http://patches.dpdk.org/comment/86280/", "msgid": "<D2C4A16CA39F7F4E8E384D204491D7A6614D7F25@FMSMSX151.amr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/D2C4A16CA39F7F4E8E384D204491D7A6614D7F25@FMSMSX151.amr.corp.intel.com", "date": "2018-09-27T23:45:31", "subject": "Re: [dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "submitter": { "id": 754, "url": "http://patches.dpdk.org/api/people/754/?format=api", "name": "Wang, Yipeng1", "email": "yipeng1.wang@intel.com" }, "content": "Hi Honnappa,\n\nReply inlined:\n\n>-----Original Message-----\n>\n> Currently, reader-writer concurrency problems in rte_hash are\n> addressed using reader-writer locks. Use of reader-writer locks\n> results in following issues:\n>\n> 1) In many of the use cases for the hash table, writer threads\n> are running on control plane. If the writer is preempted while\n> holding the lock, it will block the readers for an extended period\n> resulting in packet drops. This problem seems to apply for platforms\n> with transactional memory support as well because of the algorithm\n> used for rte_rwlock_write_lock_tm:\n>\n> static inline void\n> rte_rwlock_write_lock_tm(rte_rwlock_t *rwl)\n> {\n> if (likely(rte_try_tm(&rwl->cnt)))\n> return;\n> rte_rwlock_write_lock(rwl);\n> }\n>\n> i.e. there is a posibility of using rte_rwlock_write_lock in\n> failure cases.\n[Wang, Yipeng] In our test, TSX failure happens very rarely on a TSX platform. But we agree\nthat without TSX, the current rte_rwlock implementation may make the writer to\nhold a lock for a period of time.\n\n> 2) Reader-writer lock based solution does not address the following\n> issue.\n> rte_hash_lookup_xxx APIs return the index of the element in\n> the key store. Application(reader) can use that index to reference\n> other data structures in its scope. Because of this, the\n> index should not be freed till the application completes\n> using the index.\n[Wang, Yipeng] I agree on this use case. But I think we should provide new API functions for deletion\nto users who want this behavior,\nwithout changing the meaning of current API if that is possible.\n\n> Current code:\n>\tCores\tLookup Lookup\n>\t\twith add\n>\t2\t474\t 246\n>\t4\t935 579\n>\t6\t1387 1048\n>\t8\t1766 1480\n>\t10\t2119 1951\n>\t12\t2546 2441\n>\n> With this patch:\n>\tCores\tLookup Lookup\n>\t\twith add\n>\t2\t291\t 211\n>\t4\t297\t 196\n>\t6\t304\t 198\n>\t8\t309\t 202\n>\t10\t315\t 205\n>\t12\t319\t 209\n>\n[Wang, Yipeng] It would be good if you could provide the platform information on these results.\n\nAnother comment is as you know we also have a new extension to rte_hash to enable extendable\nbuckets and partial-key hashing. Thanks for the comments btw. Could you check if your lockless\nscheme also applies to those extensions?", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id ECA671B17C;\n\tFri, 28 Sep 2018 01:45:51 +0200 (CEST)", "from mga14.intel.com (mga14.intel.com [192.55.52.115])\n\tby dpdk.org (Postfix) with ESMTP id AFCFB1B17A\n\tfor <dev@dpdk.org>; Fri, 28 Sep 2018 01:45:49 +0200 (CEST)", "from fmsmga003.fm.intel.com ([10.253.24.29])\n\tby fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t27 Sep 2018 16:45:48 -0700", "from fmsmsx107.amr.corp.intel.com ([10.18.124.205])\n\tby FMSMGA003.fm.intel.com with ESMTP; 27 Sep 2018 16:45:32 -0700", "from fmsmsx123.amr.corp.intel.com (10.18.125.38) by\n\tfmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Thu, 27 Sep 2018 16:45:31 -0700", "from fmsmsx151.amr.corp.intel.com ([169.254.7.87]) by\n\tfmsmsx123.amr.corp.intel.com ([169.254.7.84]) with mapi id\n\t14.03.0319.002; Thu, 27 Sep 2018 16:45:31 -0700" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.54,312,1534834800\"; d=\"scan'208\";a=\"84015230\"", "From": "\"Wang, Yipeng1\" <yipeng1.wang@intel.com>", "To": "Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>, \"Richardson, Bruce\"\n\t<bruce.richardson@intel.com>, \"De Lara Guarch, Pablo\"\n\t<pablo.de.lara.guarch@intel.com>", "CC": "\"dev@dpdk.org\" <dev@dpdk.org>, \"honnappa.nagarahalli@dpdk.org\"\n\t<honnappa.nagarahalli@dpdk.org>, \"gavin.hu@arm.com\" <gavin.hu@arm.com>,\n\t\"steve.capper@arm.com\" <steve.capper@arm.com>, \"ola.liljedahl@arm.com\"\n\t<ola.liljedahl@arm.com>, \"nd@arm.com\" <nd@arm.com>, \"Gobriel, Sameh\"\n\t<sameh.gobriel@intel.com>", "Thread-Topic": "[dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "Thread-Index": "AQHURgTuMbp3QXuwrESo2qvnFE2pcaUE6Y7g", "Date": "Thu, 27 Sep 2018 23:45:31 +0000", "Message-ID": "<D2C4A16CA39F7F4E8E384D204491D7A6614D7F25@FMSMSX151.amr.corp.intel.com>", "References": "<1536253938-192391-1-git-send-email-honnappa.nagarahalli@arm.com>", "In-Reply-To": "<1536253938-192391-1-git-send-email-honnappa.nagarahalli@arm.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-product": "dlpe-windows", "dlp-version": "11.0.400.15", "dlp-reaction": "no-action", "x-ctpclassification": "CTP_NT", "x-titus-metadata-40": "eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTkxOWJjZWYtMmIyNy00OWNmLTgzYWItYTRkMzFkMzMyNGMwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUWc0MEVobjBWdmNzK2dqa0JSVmJkYlwvanQ5cFlFQzFTZkt0SjJ0OWp6ZFNvaTFwSmVtWnlMZjRkbUtJZ2ZGSkoifQ==", "x-originating-ip": "[10.1.200.106]", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "Subject": "Re: [dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "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>,\n\t<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\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 86344, "web_url": "http://patches.dpdk.org/comment/86344/", "msgid": "<DB7PR08MB36741BAF98F4ABFCFE3B036998EC0@DB7PR08MB3674.eurprd08.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/DB7PR08MB36741BAF98F4ABFCFE3B036998EC0@DB7PR08MB3674.eurprd08.prod.outlook.com", "date": "2018-09-28T21:11:18", "subject": "Re: [dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "submitter": { "id": 1045, "url": "http://patches.dpdk.org/api/people/1045/?format=api", "name": "Honnappa Nagarahalli", "email": "honnappa.nagarahalli@arm.com" }, "content": "> \n> Hi Honnappa,\n> \n> Reply inlined:\nHi Yipeng,\nThank you so much for reviewing.\n\n> \n> >-----Original Message-----\n> >\n> > Currently, reader-writer concurrency problems in rte_hash are\n> > addressed using reader-writer locks. Use of reader-writer locks\n> > results in following issues:\n> >\n> > 1) In many of the use cases for the hash table, writer threads\n> > are running on control plane. If the writer is preempted while\n> > holding the lock, it will block the readers for an extended period\n> > resulting in packet drops. This problem seems to apply for platforms\n> > with transactional memory support as well because of the algorithm\n> > used for rte_rwlock_write_lock_tm:\n> >\n> > static inline void\n> > rte_rwlock_write_lock_tm(rte_rwlock_t *rwl)\n> > {\n> > if (likely(rte_try_tm(&rwl->cnt)))\n> > return;\n> > rte_rwlock_write_lock(rwl);\n> > }\n> >\n> > i.e. there is a posibility of using rte_rwlock_write_lock in\n> > failure cases.\n> [Wang, Yipeng] In our test, TSX failure happens very rarely on a TSX\n> platform. But we agree that without TSX, the current rte_rwlock\n> implementation may make the writer to hold a lock for a period of time.\n> \n> > 2) Reader-writer lock based solution does not address the following\n> > issue.\n> > rte_hash_lookup_xxx APIs return the index of the element in\n> > the key store. Application(reader) can use that index to reference\n> > other data structures in its scope. Because of this, the\n> > index should not be freed till the application completes\n> > using the index.\n> [Wang, Yipeng] I agree on this use case. But I think we should provide new\n> API functions for deletion to users who want this behavior, without\n> changing the meaning of current API if that is possible.\nIn the lock-free algorithm, the rte_hash_delete API will not free the index. The new API rte_hash_free will free the index. The solution for the algorithm with rw locks needs to be thought about.\n\n> \n> > Current code:\n> >\tCores\tLookup Lookup\n> >\t\twith add\n> >\t2\t474\t 246\n> >\t4\t935 579\n> >\t6\t1387 1048\n> >\t8\t1766 1480\n> >\t10\t2119 1951\n> >\t12\t2546 2441\n> >\n> > With this patch:\n> >\tCores\tLookup Lookup\n> >\t\twith add\n> >\t2\t291\t 211\n> >\t4\t297\t 196\n> >\t6\t304\t 198\n> >\t8\t309\t 202\n> >\t10\t315\t 205\n> >\t12\t319\t 209\n> >\n> [Wang, Yipeng] It would be good if you could provide the platform\n> information on these results.\nApologies, I should have done that. The machine I am using is: Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz, 64G memory. This is a hacked test case which is not upstreamed. In the case of 'Lookup with add' - I had equal number of threads calling 'rte_hash_add' and 'rte_hash_lookup'. In the case of 'Lookup' - a set of entries were added and all the threads called 'rte_hash_lookup'. Note that these are the numbers without htm. We have created another test case which I will upstream as next version of this patch. I will publish the numbers with that test case. So, you should be able to reproduce the numbers with that test case.\n\n> \n> Another comment is as you know we also have a new extension to rte_hash\n> to enable extendable buckets and partial-key hashing. Thanks for the\n> comments btw. Could you check if your lockless scheme also applies to\n> those extensions?\nThank you for reminding me on this. I thought I had covered everything. On a relook, I have missed few key issues. I will reply on the other email thread.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 222031B158;\n\tFri, 28 Sep 2018 23:11:22 +0200 (CEST)", "from EUR02-VE1-obe.outbound.protection.outlook.com\n\t(mail-eopbgr20086.outbound.protection.outlook.com [40.107.2.86])\n\tby dpdk.org (Postfix) with ESMTP id C981D1B153\n\tfor <dev@dpdk.org>; Fri, 28 Sep 2018 23:11:20 +0200 (CEST)", "from DB7PR08MB3674.eurprd08.prod.outlook.com (20.177.120.156) by\n\tDB7PR08MB2955.eurprd08.prod.outlook.com (52.134.109.145) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n\t15.20.1164.25; Fri, 28 Sep 2018 21:11:19 +0000", "from DB7PR08MB3674.eurprd08.prod.outlook.com\n\t([fe80::c41d:b908:aa56:5874]) by\n\tDB7PR08MB3674.eurprd08.prod.outlook.com\n\t([fe80::c41d:b908:aa56:5874%4]) with mapi id 15.20.1164.027;\n\tFri, 28 Sep 2018 21:11:19 +0000" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;\n\ts=selector1-arm-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n\tbh=bZqW3/6KxxhcnVWC2HMclSXcmj+RjpkfSfQLw/0ZXbA=;\n\tb=rBwH6pvBWrW7qvoIKAeeRYWg186T8VNkHhunIdh/B529vGYLVvcaEVEDio6e+9v5UQkeya/k1hjKHXRh5+BiEcmUYoulUAv9bonvBjBYdgFtZm7i6+IsSTc1euLaoxsC+teNXBRKv1tbJv9Z1PpTkeFvjeLc1DC7U8y5oFJv3xU=", "From": "Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>", "To": "\"Wang, Yipeng1\" <yipeng1.wang@intel.com>, \"Richardson, Bruce\"\n\t<bruce.richardson@intel.com>, \"De Lara Guarch, Pablo\"\n\t<pablo.de.lara.guarch@intel.com>", "CC": "\"dev@dpdk.org\" <dev@dpdk.org>, \"honnappa.nagarahalli@dpdk.org\"\n\t<honnappa.nagarahalli@dpdk.org>, \"Gavin Hu (Arm Technology China)\"\n\t<Gavin.Hu@arm.com>, Steve Capper <Steve.Capper@arm.com>, Ola Liljedahl\n\t<Ola.Liljedahl@arm.com>, nd <nd@arm.com>, \"Gobriel, Sameh\"\n\t<sameh.gobriel@intel.com>", "Thread-Topic": "[dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "Thread-Index": "AQHURgTKqGcS9ICsZUeJFhcyzG1braUE7FCAgAFWTlA=", "Date": "Fri, 28 Sep 2018 21:11:18 +0000", "Message-ID": "<DB7PR08MB36741BAF98F4ABFCFE3B036998EC0@DB7PR08MB3674.eurprd08.prod.outlook.com>", "References": "<1536253938-192391-1-git-send-email-honnappa.nagarahalli@arm.com>\n\t<D2C4A16CA39F7F4E8E384D204491D7A6614D7F25@FMSMSX151.amr.corp.intel.com>", "In-Reply-To": "<D2C4A16CA39F7F4E8E384D204491D7A6614D7F25@FMSMSX151.amr.corp.intel.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "authentication-results": "spf=none (sender IP is )\n\tsmtp.mailfrom=Honnappa.Nagarahalli@arm.com; ", "x-originating-ip": "[217.140.111.135]", "x-ms-publictraffictype": "Email", "x-microsoft-exchange-diagnostics": "1; DB7PR08MB2955;\n\t6:OdhGIgMAIxnxjo2DOQ7UKbsD1nJoa/E507Ve+Ah8Zu/HKnq7U1kjupaR8jRiEqYfX8uTfxg5tekAsj4R+RbAJ7Q5aLRWeKzXinvuixVdC08hc8+azsQyHh4Gv0E6MwkwKldA4V7CYPFVzEOGa/Ps8UwNfTx6u7JSg0zF0X1H3UrNjBDoP/qtqQmNNrfdTjGJ1GY/zTVgf3oFVSlmnU+HJfzpzYeuhUbfbt6O8AiYU3/9ldveiwzKm6GCmpoKt4JRWljNy7gCDNp5moAyyQxLUf3HokNzeIGhJz4wZ+WPpJT2WpaNTaIwTELUV2wv8zzFrEHn4dtMNkx11d0VS/EqlJjrWv0zeZtg+Vh3Upc6kSD0nSQFAdHx4DPZgbteZZveaTaongJOfb/4DU0MmqGOeuyQEMJOOlZPdwU9vJQfNQjHjPFpqyYM0gWhMDgq6GEroCCWhu6rUOIczQ1h23c1/g==;\n\t5:8k8/cwX5idZ0Upj6res43/QTKAXB8+QCAEWsb9EyTFzDf/sryyYFivX0AoxecbWy7LWO4KixR1YD7viuvrgcNi4V2Q+Yo9V+mi6fu6VVgVUcmRAfD8tHDgSJjLSHJYQOkebPM3KV8ZmKqVcpWNz5NDgaEwlRlo8Cl/9h1OxQzIw=;\n\t7:jVfGCJQmcDRrdyc/IIedlZFchnaXoZ9o1m16FqD0h6Uq0pw5Xq9j/lAuGE5DQTFIPYJFroRA0n7sbukvEM7zKHvQSPUcmMW4U0fUPca2dT99R1V3/Oh7wzJf2Eo0D/KYXyXhoMst+9Y8L4Dq6JgjLsyI9lcUO9sxoqni7Z4qF0EkRC0p/fi2WvtkPF3jC5bsQ9eVX++fqFl2SwfJ423cb/ooWZ96NlBBqm7PUjnpr4cjbkDdvxwSB/XC3+ajjz9p", "x-ms-exchange-antispam-srfa-diagnostics": "SOS;SOR;", "x-ms-office365-filtering-correlation-id": "d447e34b-fa69-48e0-1591-08d62586ef55", "x-ms-office365-filtering-ht": "Tenant", "x-microsoft-antispam": "BCL:0; PCL:0;\n\tRULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020);\n\tSRVR:DB7PR08MB2955; ", "x-ms-traffictypediagnostic": "DB7PR08MB2955:", "nodisclaimer": "True", "x-microsoft-antispam-prvs": "<DB7PR08MB2955D2D4BD3E8868E3E670A198EC0@DB7PR08MB2955.eurprd08.prod.outlook.com>", "x-exchange-antispam-report-test": "UriScan:;", "x-ms-exchange-senderadcheck": "1", "x-exchange-antispam-report-cfa-test": "BCL:0; PCL:0;\n\tRULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231355)(944501410)(52105095)(10201501046)(3002001)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(201708071742011)(7699051);\n\tSRVR:DB7PR08MB2955; BCL:0; PCL:0; RULEID:; SRVR:DB7PR08MB2955; ", "x-forefront-prvs": "0809C12563", "x-forefront-antispam-report": "SFV:NSPM;\n\tSFS:(10009020)(396003)(346002)(39860400002)(136003)(366004)(376002)(13464003)(199004)(51914003)(189003)(25786009)(105586002)(26005)(55016002)(7736002)(71200400001)(71190400001)(33656002)(6506007)(34290500001)(106356001)(4326008)(7696005)(229853002)(2900100001)(66066001)(81166006)(6246003)(76176011)(186003)(345774005)(305945005)(8676002)(3846002)(99286004)(8936002)(6436002)(74316002)(102836004)(81156014)(53936002)(9686003)(68736007)(6116002)(11346002)(2906002)(72206003)(476003)(110136005)(446003)(86362001)(97736004)(14444005)(5660300001)(54906003)(486006)(14454004)(316002)(256004)(478600001)(5250100002)(21314002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR08MB2955;\n\tH:DB7PR08MB3674.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en;\n\tPTR:InfoNoRecords; A:1; MX:1; ", "received-spf": "None (protection.outlook.com: arm.com does not designate\n\tpermitted sender hosts)", "x-microsoft-antispam-message-info": "bOLjVyoRvnHUKk/bB4w2IGAh7fdaqktFfyTq8Lc4Tz0Sgvz0gT0zDCBQ+a56E65AOLixaVAMOlQtbHveM6Hk7hA62AUg/Cyj41jy3bFVLKZhBBnloW+N1baSzBYdDrS2zPM2VEWSGXM59oyYd07ZUu7Hd+RmyEseCLiRM36D2vwSuRLdu8wq+32gAp/RWzJ8UmGCUF+JYT7KPdi8AWgG/TwVVxqy5uLOwbSIUcphB5AGcdHvxTioHrOlagojgVa0oqgwXKOkAIX55YSs4BNpW7BuFnD95n39uGjPWtgo5h47fJtxw3eA4bJQinvBNGaDp58xhbBeaheYaMLzStmccSQQ1iS7/HpT6uTh3KxuCQg=", "spamdiagnosticoutput": "1:99", "spamdiagnosticmetadata": "NSPM", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "X-OriginatorOrg": "arm.com", "X-MS-Exchange-CrossTenant-Network-Message-Id": "d447e34b-fa69-48e0-1591-08d62586ef55", "X-MS-Exchange-CrossTenant-originalarrivaltime": "28 Sep 2018 21:11:18.9929\n\t(UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "f34e5979-57d9-4aaa-ad4d-b122a662184d", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "DB7PR08MB2955", "Subject": "Re: [dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "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>,\n\t<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\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 86475, "web_url": "http://patches.dpdk.org/comment/86475/", "msgid": "<D2C4A16CA39F7F4E8E384D204491D7A6614EA35D@FMSMSX151.amr.corp.intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/D2C4A16CA39F7F4E8E384D204491D7A6614EA35D@FMSMSX151.amr.corp.intel.com", "date": "2018-10-02T00:30:29", "subject": "Re: [dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "submitter": { "id": 754, "url": "http://patches.dpdk.org/api/people/754/?format=api", "name": "Wang, Yipeng1", "email": "yipeng1.wang@intel.com" }, "content": ">>\n>> Another comment is as you know we also have a new extension to rte_hash\n>> to enable extendable buckets and partial-key hashing. Thanks for the\n>> comments btw. Could you check if your lockless scheme also applies to\n>> those extensions?\n>Thank you for reminding me on this. I thought I had covered everything. On a relook, I have missed few key issues. I will reply on the\n>other email thread.\n[Wang, Yipeng] Hi, Honnappa, would like to rebase your V2 on the V4 patch I submitted for the ext table and partial-key hashing (http://patchwork.dpdk.org/cover/45620/). I will have V5 sent soon, so if it is in time, please rebase on V5. If you have any difficulty to do so we can work together on resolving the conflicts. Let's resolve the conflicts so that the final merge would be easier.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@dpdk.org", "Delivered-To": "patchwork@dpdk.org", "Received": [ "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 84EAB5688;\n\tTue, 2 Oct 2018 02:30:33 +0200 (CEST)", "from mga05.intel.com (mga05.intel.com [192.55.52.43])\n\tby dpdk.org (Postfix) with ESMTP id E22CD5398\n\tfor <dev@dpdk.org>; Tue, 2 Oct 2018 02:30:31 +0200 (CEST)", "from fmsmga002.fm.intel.com ([10.253.24.26])\n\tby fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t01 Oct 2018 17:30:30 -0700", "from fmsmsx108.amr.corp.intel.com ([10.18.124.206])\n\tby fmsmga002.fm.intel.com with ESMTP; 01 Oct 2018 17:30:30 -0700", "from fmsmsx116.amr.corp.intel.com (10.18.116.20) by\n\tFMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Mon, 1 Oct 2018 17:30:30 -0700", "from fmsmsx151.amr.corp.intel.com ([169.254.7.87]) by\n\tfmsmsx116.amr.corp.intel.com ([169.254.2.92]) with mapi id\n\t14.03.0319.002; Mon, 1 Oct 2018 17:30:30 -0700" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "X-IronPort-AV": "E=Sophos;i=\"5.54,329,1534834800\"; d=\"scan'208\";a=\"91275103\"", "From": "\"Wang, Yipeng1\" <yipeng1.wang@intel.com>", "To": "Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>, \"Richardson, Bruce\"\n\t<bruce.richardson@intel.com>, \"De Lara Guarch, Pablo\"\n\t<pablo.de.lara.guarch@intel.com>", "CC": "\"dev@dpdk.org\" <dev@dpdk.org>, \"honnappa.nagarahalli@dpdk.org\"\n\t<honnappa.nagarahalli@dpdk.org>, \"Gavin Hu (Arm Technology China)\"\n\t<Gavin.Hu@arm.com>, Steve Capper <Steve.Capper@arm.com>, Ola Liljedahl\n\t<Ola.Liljedahl@arm.com>, nd <nd@arm.com>, \"Gobriel, Sameh\"\n\t<sameh.gobriel@intel.com>", "Thread-Topic": "[dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "Thread-Index": "AQHURgTuMbp3QXuwrESo2qvnFE2pcaUE6Y7ggAHfWQCABHZaYA==", "Date": "Tue, 2 Oct 2018 00:30:29 +0000", "Message-ID": "<D2C4A16CA39F7F4E8E384D204491D7A6614EA35D@FMSMSX151.amr.corp.intel.com>", "References": "<1536253938-192391-1-git-send-email-honnappa.nagarahalli@arm.com>\n\t<D2C4A16CA39F7F4E8E384D204491D7A6614D7F25@FMSMSX151.amr.corp.intel.com>\n\t<DB7PR08MB36741BAF98F4ABFCFE3B036998EC0@DB7PR08MB3674.eurprd08.prod.outlook.com>", "In-Reply-To": "<DB7PR08MB36741BAF98F4ABFCFE3B036998EC0@DB7PR08MB3674.eurprd08.prod.outlook.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-product": "dlpe-windows", "dlp-version": "11.0.400.15", "dlp-reaction": "no-action", "x-ctpclassification": "CTP_NT", "x-titus-metadata-40": "eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzIwMjk5MTMtZjE0Mi00Yjg3LWFjNjAtNTJlNTA4NzgyMjgzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiMWh1dXpUNE51R0M2RloxZzVOcUZYeTMxZzFSVlwvamNHZzJ2and2dW14XC9Dc2J5UHgwc0VZQUQzNXpBbkE0SExKIn0=", "x-originating-ip": "[10.1.200.107]", "Content-Type": "text/plain; charset=\"us-ascii\"", "Content-Transfer-Encoding": "quoted-printable", "MIME-Version": "1.0", "Subject": "Re: [dpdk-dev] [PATCH 0/4] Address reader-writer concurrency in\n\trte_hash", "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>,\n\t<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\t<mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null } ]