Re: [dpdk-dev] [PATCH v3 10/10] doc: add mempool and octeontx mempool device

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----Original Message-----
> Date: Wed, 18 Oct 2017 19:32:44 +0530
> From: santosh <santosh.shukla@caviumnetworks.com>
> To: Thomas Monjalon <thomas@monjalon.net>, John McNamara
>  <john.mcnamara@intel.com>
> Cc: dev@dpdk.org, olivier.matz@6wind.com, jerin.jacob@caviumnetworks.com,
>  hemant.agrawal@nxp.com, ferruh.yigit@intel.com
> Subject: Re: [dpdk-dev] [PATCH v3 10/10] doc: add mempool and octeontx
>  mempool device
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
>  Thunderbird/45.5.1
> 
> 
> On Wednesday 18 October 2017 07:15 PM, Thomas Monjalon wrote:
> > 18/10/2017 14:17, santosh:
> >> Hi Thomas,
> >>
> >>
> >> On Monday 09 October 2017 02:49 PM, santosh wrote:
> >>> On Monday 09 October 2017 02:18 PM, Thomas Monjalon wrote:
> >>>> 09/10/2017 07:46, santosh:
> >>>>> On Monday 09 October 2017 10:31 AM, santosh wrote:
> >>>>>> Hi Thomas,
> >>>>>>
> >>>>>>
> >>>>>> On Sunday 08 October 2017 10:13 PM, Thomas Monjalon wrote:
> >>>>>>> 08/10/2017 14:40, Santosh Shukla:
> >>>>>>>> This commit adds a section to the docs listing the mempool
> >>>>>>>> device PMDs available.
> >>>>>>> It is confusing to add a mempool guide, given that we already have
> >>>>>>> a mempool section in the programmer's guide:
> >>>>>>> 	http://dpdk.org/doc/guides/prog_guide/mempool_lib.html
> >>>>>>>
> >>>>>>> And we will probably need also some doc for bus drivers.
> >>>>>>>
> >>>>>>> I think it would be more interesting to create a platform guide
> >>>>>>> where you can describe the bus and the mempool.
> >>>>>>> OK for doc/guides/platform/octeontx.rst ?
> >>>>>> No Strong opinion,
> >>>>>>
> >>>>>> But IMO, purpose of introducing mempool PMD was inspired from
> >>>>>> eventdev, Which I find pretty organized.
> >>>>>>
> >>>>>> Yes, we have mempool_lib guide but that is more about common mempool
> >>>>>> layer details like api, structure layout etc.. I wanted
> >>>>>> to add guide which tells about mempool PMD's and their capability
> >>>>>> if any, thats why included octeontx as strarter and was thinking
> >>>>>> that other external-mempool PMDs like dpaa/dpaa2 , sw ring pmd may come
> >>>>>> later.
> >>>> Yes sure it is interesting.
> >>>> The question is to know if mempool drivers make sense in their own guide
> >>>> or if it's better to group them with all related platform specifics.
> >>> I vote for keeping them just like Eventdev/cryptodev, 
> >>> has vendor specific PMD's under one roof.. (has both s/w and hw).
> >> To be clear and move on to v3 for this patch:
> >> * Your proposition to mention about mempool block in dir struct like
> >> doc/guides/platform/octeontx.rst. 
> >> And right now we have more than one reference for octeontx.rst in dpdk
> >> example:
> >> ./doc/guides/nics/octeontx.rst --> NIC
> >> ./doc/guides/eventdevs/octeontx.rst --> eventdev device
> >>
> >> Keeping above order in mind: My current proposal was to introduce doc like eventdev for mempool block.
> >>
> >> So now, I am in two mind, Whether I opt your path If so then that should I remove all octeontx.rst reference from dpdk?
> > I think we must keep octeontx.rst in nics and eventdevs.
> >
> > My proposal was to have a platform guide to give more explanations
> > about the common hardware and bus design.
> 
> That way, event device also a common hw block.. just like mempool block is
> for octeontx platform. Also PCI bus is octeontx bus.. we don;t have platform
> specific bus like dpaa has, so bus stuff not applicable to octeontx doc(imo).
> 
> > Some infos for tuning Intel platforms are in the quick start guide,
> > and could be moved later in such a platform guide.
> >
> > With this suggestion, we can include mempool drivers in the
> > platform guide as mempool is really specific to the platform.
> >
> > I thought you agreed on it when talking on IRC.
> 
> yes, we did discussed on IRC. But I'm still unsure about scope of that guide 
> from octeontx perspective: That new platform entry has info about only one block
> which is mempool and for other common block or specific blocks : 
> user has to look around at different directories.. 
> 
> >> and bundle them under one roof OR go by my current proposal.
> >>
> >> Who'll take a call on that?
> > If you strongly feel that mempool driver is better outside,
> 
> I don't have strong opinion on doc.. I'm just asking for more opinions here..

Combining both proposal. How about,
1) Create ./doc/guides/mempool/octeontx.rst to capture octeontx mempool
specific information.(Which is inline with driver/ hierarchy).
2) Create a platform specific document(say doc/guides/platform/octeontx.rst)
- We can use this file to capture information about the common content
between the three separate documents(doc/guides/nics/octeontx.rst,
./doc/guides/eventdevs/octeontx.rst and ./doc/guides/mempool/octeontx.rst) and
give reference to common file instead of duplicating the information in
driver documentation.

Thomas, John,

Thoughts?


> as I'm not fully convinced with your proposition.
> 
> > you can make it outside in a mempool guide.
> > John do you have an opinion?
> >
>