> -----Original Message-----
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Honnappa Nagarahalli
> Sent: Wednesday, May 1, 2019 4:54 AM
> To: Ananyev, Konstantin <konstantin.anan...@intel.com>;
> step...@networkplumber.org; paul...@linux.ibm.com; Kovacevic, Marko
> <marko.kovace...@intel.com>; dev@dpdk.org
> Cc: honnappa.nagaraha...@arm.com; gavin...@arm.com;
> dharmik.thak...@arm.com; malvika.gu...@arm.com
> Subject: [dpdk-dev] [PATCH v9 3/4] doc/rcu: add lib_rcu documentation
>
> Add lib_rcu QSBR API and programmer guide documentation.
>
> Signed-off-by: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>
> Reviewed-by: Marko Kovacevic <marko.kovace...@intel.com>
Some minor comments below. Nothing blocking.
>
> +Delete: in this step, the writer removes the reference to the element
> +from the data structure but does not return the associated memory to
> +the allocator. This will ensure that new readers will not get a
> +reference to the removed element. Removing the reference is an atomic
> operation.
> +
> +Free(Reclaim): in this step, the writer returns the memory to the
> +memory allocator, only after knowing that all the readers have stopped
> +referencing the deleted element.
These would be better as a bullet or number list.
> +What is Quiescent State
> +-----------------------
> +Quiescent State can be defined as 'any point in the thread execution
> +where the thread does not hold a reference to shared memory'. It is up
> +to the application to determine its quiescent state.
> +
> +Let us consider the following diagram:
> +
> +.. figure:: img/rcu_general_info.*
The image would be better like this (as recommended in the docs:
http://doc.dpdk.org/guides/contributing/documentation.html#images)
.. _figure_quiescent_state:
.. figure:: img/rcu_general_info.*
Phases in the Quiescent State model.
However, it isn't worth a re-spin. I'll send you on a file with the suggested
changes.
Acked-by: John McNamara <john.mcnam...@intel.com>
