doc: describe token and resource retention in RCU guide
authorHonnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Tue, 8 Oct 2019 21:12:16 +0000 (16:12 -0500)
committerDavid Marchand <david.marchand@redhat.com>
Mon, 21 Oct 2019 15:54:40 +0000 (17:54 +0200)
After calling rte_rcu_qsbr_start API, the token and the deleted
resource need to be stored for subsequent query/free.

Fixes: 64994b56cfd7 ("rcu: add RCU library supporting QSBR mechanism")
Cc: stable@dpdk.org
Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Gavin Hu <gavin.hu@arm.com>
doc/guides/prog_guide/rcu_lib.rst

index 4d1ed39..8d0dfcf 100644 (file)
@@ -162,14 +162,19 @@ running as worker threads.
 The separation of triggering the reporting from querying the status provides
 the writer threads flexibility to do useful work instead of blocking for the
 reader threads to enter the quiescent state or go offline. This reduces the
-memory accesses due to continuous polling for the status.
+memory accesses due to continuous polling for the status. But, since the
+resource is freed at a later time, the token and the reference to the deleted
+resource need to be stored for later queries.
 
 The ``rte_rcu_qsbr_synchronize()`` API combines the functionality of
 ``rte_rcu_qsbr_start()`` and blocking ``rte_rcu_qsbr_check()`` into a single
 API. This API triggers the reader threads to report their quiescent state and
 polls till all the readers enter the quiescent state or go offline. This API
 does not allow the writer to do useful work while waiting and introduces
-additional memory accesses due to continuous polling.
+additional memory accesses due to continuous polling. However, the application
+does not have to store the token or the reference to the deleted resource. The
+resource can be freed immediately after ``rte_rcu_qsbr_synchronize()`` API
+returns.
 
 The reader thread must call ``rte_rcu_qsbr_thread_offline()`` and
 ``rte_rcu_qsbr_thread_unregister()`` APIs to remove itself from reporting its