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

santosh santosh.shukla at caviumnetworks.com
Wed Oct 18 14:17:14 CEST 2017


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?
and bundle them under one roof OR go by my current proposal.

Who'll take a call on that?

Thanks.




More information about the dev mailing list