From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 08251325D for ; Wed, 18 Oct 2017 15:45:04 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 79C6520B58; Wed, 18 Oct 2017 09:45:04 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 18 Oct 2017 09:45:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=c40SNtCa4yp5Mf68lTR4Rq5ACC KFH9vO9YakapYW7kE=; b=s10X/67p+Tc3I1MCltEtY6uk44NAwMgq/rlBzQZzf0 W6LxuPx9QUzP8QH47G3FlHGt49C2WuQmYKsmPno9elQXZTPxPpMUNlUv8StqE+7g IJJHY/qDg7IQaYz7i3ps5waWk98vmhz5ajG4BMqj77iv7q2M4DBW1ynYgIY9U+NG A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=c40SNt Ca4yp5Mf68lTR4Rq5ACCKFH9vO9YakapYW7kE=; b=K0LumF0453opQDhYwwIDK9 bS4QaTGDo5pGcUMJq/dpj/eESIFO/b+Afc4NlI5KD8JmWUVzZD6LWK1YJyzkupjA /u54tdAEjZnO7dN2srV0F6jxmr/+0AyQRz1y7bGIRssreYmbmUEagRy9qBGEW9d7 7jZNCHkJF3aOlbrnbIibr/Z+i4jjVinoia3XafSHyOwq+XKaeu/5aRjdZbsWRB5T MKBYZ31zcPpNc8D38qV9JdMSJ3arIFN8VeF1lVgeS0rBjjWTMohYUyIiDLJH5t8o aec+tl1leF+nWBVuIs+3wOLaA6YwIrTf3rBo9F20HwAvjbIL6r8DwslWlgrgzuAQ == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 26A74247AD; Wed, 18 Oct 2017 09:45:04 -0400 (EDT) From: Thomas Monjalon To: santosh , John McNamara Cc: dev@dpdk.org, olivier.matz@6wind.com, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, ferruh.yigit@intel.com Date: Wed, 18 Oct 2017 15:45:03 +0200 Message-ID: <2831928.n80VB9rmku@xps> In-Reply-To: <2b50074a-f964-d1de-d3b9-0abcd9df68a8@caviumnetworks.com> References: <20170831063719.19273-1-santosh.shukla@caviumnetworks.com> <2b50074a-f964-d1de-d3b9-0abcd9df68a8@caviumnetworks.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 10/10] doc: add mempool and octeontx mempool device X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 13:45:05 -0000 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. 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. > 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, you can make it outside in a mempool guide. John do you have an opinion?