Cover Detail
Show a cover letter.
GET /api/covers/50431/?format=api
{ "id": 50431, "url": "http://patchwork.dpdk.org/api/covers/50431/?format=api", "web_url": "http://patchwork.dpdk.org/project/dpdk/cover/20190222070427.22866-1-honnappa.nagarahalli@arm.com/", "project": { "id": 1, "url": "http://patchwork.dpdk.org/api/projects/1/?format=api", "name": "DPDK", "link_name": "dpdk", "list_id": "dev.dpdk.org", "list_email": "dev@dpdk.org", "web_url": "http://core.dpdk.org", "scm_url": "git://dpdk.org/dpdk", "webscm_url": "http://git.dpdk.org/dpdk", "list_archive_url": "https://inbox.dpdk.org/dev", "list_archive_url_format": "https://inbox.dpdk.org/dev/{}", "commit_url_format": "" }, "msgid": "<20190222070427.22866-1-honnappa.nagarahalli@arm.com>", "list_archive_url": "https://inbox.dpdk.org/dev/20190222070427.22866-1-honnappa.nagarahalli@arm.com", "date": "2019-02-22T07:04:22", "name": "[RFC,v3,0/5] rcu: add RCU library supporting QSBR mechanism", "submitter": { "id": 1045, "url": "http://patchwork.dpdk.org/api/people/1045/?format=api", "name": "Honnappa Nagarahalli", "email": "honnappa.nagarahalli@arm.com" }, "mbox": "http://patchwork.dpdk.org/project/dpdk/cover/20190222070427.22866-1-honnappa.nagarahalli@arm.com/mbox/", "series": [ { "id": 3506, "url": "http://patchwork.dpdk.org/api/series/3506/?format=api", "web_url": "http://patchwork.dpdk.org/project/dpdk/list/?series=3506", "date": "2019-02-22T07:04:22", "name": "rcu: add RCU library supporting QSBR mechanism", "version": 3, "mbox": "http://patchwork.dpdk.org/series/3506/mbox/" } ], "comments": "http://patchwork.dpdk.org/api/covers/50431/comments/", "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 6BB812B8C;\n\tFri, 22 Feb 2019 08:04:54 +0100 (CET)", "from foss.arm.com (foss.arm.com [217.140.101.70])\n\tby dpdk.org (Postfix) with ESMTP id D1B571D7\n\tfor <dev@dpdk.org>; Fri, 22 Feb 2019 08:04:52 +0100 (CET)", "from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0053480D;\n\tThu, 21 Feb 2019 23:04:52 -0800 (PST)", "from qc2400f-1.austin.arm.com (qc2400f-1.austin.arm.com\n\t[10.118.12.104])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t7A8363F690; Thu, 21 Feb 2019 23:04:51 -0800 (PST)" ], "From": "Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>", "To": "konstantin.ananyev@intel.com, stephen@networkplumber.org,\n\tpaulmck@linux.ibm.com, dev@dpdk.org, honnappa.nagarahalli@arm.com", "Cc": "gavin.hu@arm.com, dharmik.thakkar@arm.com, malvika.gupta@arm.com,\n\tnd@arm.com", "Date": "Fri, 22 Feb 2019 01:04:22 -0600", "Message-Id": "<20190222070427.22866-1-honnappa.nagarahalli@arm.com>", "X-Mailer": "git-send-email 2.17.1", "In-Reply-To": "<20181222021420.5114-1-honnappa.nagarahalli@arm.com>", "References": "<20181222021420.5114-1-honnappa.nagarahalli@arm.com>", "Subject": "[dpdk-dev] [RFC v3 0/5] rcu: add RCU library supporting QSBR\n\tmechanism", "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>" }, "content": "Lock-less data structures provide scalability and determinism.\nThey enable use cases where locking may not be allowed\n(for ex: real-time applications).\n\nIn the following paras, the term 'memory' refers to memory allocated\nby typical APIs like malloc or anything that is representative of\nmemory, for ex: an index of a free element array.\n\nSince these data structures are lock less, the writers and readers\nare accessing the data structures simultaneously. Hence, while removing\nan element from a data structure, the writers cannot return the memory\nto the allocator, without knowing that the readers are not\nreferencing that element/memory anymore. Hence, it is required to\nseparate the operation of removing an element into 2 steps:\n\nDelete: in this step, the writer removes the reference to the element from\nthe data structure but does not return the associated memory to the\nallocator. This will ensure that new readers will not get a reference to\nthe removed element. Removing the reference is an atomic operation.\n\nFree(Reclaim): in this step, the writer returns the memory to the\nmemory allocator, only after knowing that all the readers have stopped\nreferencing the deleted element.\n\nThis library helps the writer determine when it is safe to free the\nmemory.\n\nThis library makes use of thread Quiescent State (QS). QS can be\ndefined as 'any point in the thread execution where the thread does\nnot hold a reference to shared memory'. It is upto the application to\ndetermine its quiescent state. Let us consider the following diagram:\n\n Time -------------------------------------------------->\n\n | |\n RT1 $++++****D1****+++***D2*|**+++|+++**D3*****++++$\n | |\n RT2 $++++****D1****++|+**D2|***++++++**D3*****++++$\n | |\n RT3 $++++****D1****+++***|D2***|++++++**D2*****++++$\n | |\n |<--->|\n Del | Free\n |\n Cannot free memory\n during this period\n (Grace Period)\n\nRTx - Reader thread\n< and > - Start and end of while(1) loop\n***Dx*** - Reader thread is accessing the shared data structure Dx.\n i.e. critical section.\n+++ - Reader thread is not accessing any shared data structure.\n i.e. non critical section or quiescent state.\nDel - Point in time when the reference to the entry is removed using\n atomic operation.\nFree - Point in time when the writer can free the entry.\nGrace Period - Time duration between Del and Free, during which memory cannot\n be freed.\n\nAs shown, thread RT1 acesses data structures D1, D2 and D3. When it is\naccessing D2, if the writer has to remove an element from D2, the\nwriter cannot free the memory associated with that element immediately.\nThe writer can return the memory to the allocator only after the reader\nstops referencng D2. In other words, reader thread RT1 has to enter\na quiescent state.\n\nSimilarly, since thread RT3 is also accessing D2, writer has to wait till\nRT3 enters quiescent state as well.\n\nHowever, the writer does not need to wait for RT2 to enter quiescent state.\nThread RT2 was not accessing D2 when the delete operation happened.\nSo, RT2 will not get a reference to the deleted entry.\n\nIt can be noted that, the critical sections for D2 and D3 are quiescent states\nfor D1. i.e. for a given data structure Dx, any point in the thread execution\nthat does not reference Dx is a quiescent state.\n\nSince memory is not freed immediately, there might be a need for\nprovisioning of additional memory, depending on the application requirements.\n\nIt is important to make sure that this library keeps the over head, of\nidentifying the end of grace period and subsequent freeing of memory,\nto a minimum. One has to understand how grace period and critical section\naffect this overhead.\n\nThe writer has to poll the readers to identify the end of grace period.\nPolling introduces memory accesses and wastes CPU cycles. The memory\nis not available for reuse during grace period. Longer grace periods\nexasperate these conditions.\n\nThe length of the critical section and the number of reader threads\nis proportional to the duration of the grace period. Keeping the critical\nsections smaller will keep the grace period smaller. However, keeping the\ncritical sections smaller requires additional CPU cycles(due to additional\nreporting) in the readers.\n\nHence, we need the characteristics of small grace period and large critical\nsection. This library addresses this by allowing the writer to do\nother work without having to block till the readers report their quiescent\nstate.\n\nFor DPDK applications, the start and end of while(1) loop (where no shared\ndata structures are getting accessed) act as perfect quiescent states. This\nwill combine all the shared data structure accesses into a single, large\ncritical section which helps keep the over head on the reader side to\na minimum.\n\nDPDK supports pipeline model of packet processing and service cores.\nIn these use cases, a given data structure may not be used by all the\nworkers in the application. To provide the required flexibility, this\nlibrary has a concept of QS variable. The application can create one\nQS variable per data structure to help it track the end of grace\nperiod for each data structure.\n\nThe application can initialize a QS variable using the API rte_rcu_qsbr_init.\n\nEach reader thread is assumed to have a unique thread ID. Currently, the\nmanagement of the thread ID (for ex: allocation/free) is left to the\napplication. The thread ID should be in the range of 0 to\nRTE_RCU_MAX_THREADS. The application could also use lcore_id as the\nthread ID where applicable.\n\nrte_rcu_qsbr_register_thread API will register a reader thread\nto report its quiescent state. This can be called from a reader thread.\nA control plane thread can also call this on behalf of a reader thread.\nHowever, the application must ensure that the reader thread is ready to\nreport the QS status before the writer checks the QS.\n\nThe application can trigger the reader threads to report their QS\nstatus by calling the API rte_rcu_qsbr_start. It is possible for multiple\nwriter threads to query the quiescent state status simultaneously. Hence,\nrte_rcu_qsbr_start returns a token to each caller.\n\nThe application has to call rte_rcu_qsbr_check API with the token to get the\ncurrent QS status. Option to block till all the reader threads enter the\nQS is provided. If this API indicates that all the reader threads have entered\nthe QS, the application can free the deleted entry.\n\nThe APIs rte_rcu_qsbr_start and rte_rcu_qsbr_check are lock free. Hence, they\ncan be called concurrently from multiple writers even while running\nas wroker threads.\n\nThe separation of triggering the reporting from querying the status provides\nthe writer threads flexibility to do useful work instead of blocking for the\nreader threads to enter the QS. This reduces the memory accesses due\nto continuous polling for the status.\n\nrte_rcu_qsbr_unregister_thread API will remove a reader thread from reporting\nits QS. The rte_rcu_qsbr_check API will not wait for this reader thread to\nreport the QS status anymore.\n\nThe reader threads should call rte_rcu_qsbr_update API to indicate that they\nentered a quiescent state. This API checks if a writer has triggered a\nquiescent state query and update the state accordingly.\n\nv3:\n1) Library changes\n a) Rebased to latest master\n b) Added new API rte_rcu_qsbr_get_memsize\n c) Add support for memory allocation for QSBR variable\n d) Fixed a bug in rte_rcu_qsbr_check (Konstantin)\n3) Testcase changes\n a) Separated stress tests into a performance test case file\n b) Added performance statistics\n\nv2:\n1) Cover letter changes\n a) Explian the parameters that affect the overhead of using RCU\n and their effect\n b) Explain how this library addresses these effects to keep\n the overhead to minimum\n2) Library changes\n a) Rename the library to avoid confusion (Matias, Bruce, Konstantin)\n b) Simplify the code/remove APIs to keep this library inline with\n other synchronisation mechanisms like locks (Konstantin)\n c) Change the design to support more than 64 threads (Konstantin)\n d) Fixed version map to remove static inline functions\n3) Testcase changes\n a) Add boundary and additional functional test cases\n b) Add stress test cases (Paul E. McKenney)\n\nNext Steps:\n1) Update the cover letter to indicate the addition of rte_rcu_get_memsize\n2) rte_rcu_qsbr_register_thread/rte_rcu_qsbr_unregister_thread can be\n optimized to avoid accessing the common bitmap array. This is required\n as these are data plane APIs. Plan is to introduce\n rte_rcu_qsbr_thread_online/rte_rcu_qsbr_thread_offline which will not\n touch the common bitmap array.\n3) Add debug logs to enable debugging\n4) Documentation\n5) Convert to patch\n\nDharmik Thakkar (1):\n test/rcu_qsbr: add API and functional tests\n\nHonnappa Nagarahalli (4):\n rcu: add RCU library supporting QSBR mechanism\n lib/rcu: add dynamic memory allocation capability\n test/rcu_qsbr: modify test cases for dynamic memory allocation\n lib/rcu: fix the size of register thread ID array size\n\n config/common_base | 6 +\n lib/Makefile | 2 +\n lib/librte_rcu/Makefile | 23 +\n lib/librte_rcu/meson.build | 5 +\n lib/librte_rcu/rte_rcu_qsbr.c | 89 +++\n lib/librte_rcu/rte_rcu_qsbr.h | 353 ++++++++++++\n lib/librte_rcu/rte_rcu_version.map | 8 +\n lib/meson.build | 2 +-\n mk/rte.app.mk | 1 +\n test/test/Makefile | 2 +\n test/test/autotest_data.py | 12 +\n test/test/meson.build | 7 +-\n test/test/test_rcu_qsbr.c | 858 +++++++++++++++++++++++++++++\n test/test/test_rcu_qsbr_perf.c | 275 +++++++++\n 14 files changed, 1641 insertions(+), 2 deletions(-)\n create mode 100644 lib/librte_rcu/Makefile\n create mode 100644 lib/librte_rcu/meson.build\n create mode 100644 lib/librte_rcu/rte_rcu_qsbr.c\n create mode 100644 lib/librte_rcu/rte_rcu_qsbr.h\n create mode 100644 lib/librte_rcu/rte_rcu_version.map\n create mode 100644 test/test/test_rcu_qsbr.c\n create mode 100644 test/test/test_rcu_qsbr_perf.c" }