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

[santosh]

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..
as I'm not fully convinced with your proposition.

> you can make it outside in a mempool guide.
> John do you have an opinion?
>