Re: [dpdk-dev] [PATCH v9 3/4] doc/rcu: add lib_rcu documentation

[Honnappa Nagarahalli <Honnappa.Nagarahalli@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.nagarahalli@arm.com>
> > Reviewed-by: Marko Kovacevic <marko.kovacevic@intel.com>
> 
> Some minor comments below. Nothing blocking.
Thanks John for the comments.

Thomas, please let me know if you want me to re-spin. Otherwise, these will be fixed as a follow up patch.

> 
> 
> >
> > +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.mcnamara@intel.com>
>