> -----Original Message-----
> From: dev [mailto:[email protected]] On Behalf Of Honnappa Nagarahalli
> Sent: Wednesday, May 1, 2019 4:54 AM
> To: Ananyev, Konstantin <[email protected]>;
> [email protected]; [email protected]; Kovacevic, Marko
> <[email protected]>; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]
> 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 <[email protected]>
> Reviewed-by: Marko Kovacevic <[email protected]>
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 <[email protected]>
