From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 70D9E1B1A8 for <dev@dpdk.org>; Wed, 18 Oct 2017 17:11:02 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EF00B20D9D; Wed, 18 Oct 2017 11:11:01 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 18 Oct 2017 11:11:01 -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=QtIK5bmHTTqKKuNjeoasE4DNLx 9611VBRHxXjzlBa7E=; b=JFh7WAdlMc9noMkQR5RAmwUVx7PO9WiLDG6u7REE11 011o1hh6xPvW0Xv82wJL7lD0u0sZxddxLP7g5dzYDazBqMbwZP+egS57m4KyP9da yazezhDrbDX1Avq0HJiHMBMU+LsWPc92BkpppvBQLD6dKZVPjPfiFJmPavE6Bnrq 4= 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=QtIK5b mHTTqKKuNjeoasE4DNLx9611VBRHxXjzlBa7E=; b=bjsX/KwyksWawG3uTBjyO5 4Be/MNRV01G8WEJOTWW71Xkho3KXilSJF4lyPCzZ73fhHQCIJKsQOCQugnFM/y4h RWfeOLUFBRbQ0rYWl9Sj+UlZ77rNrTH+UuY2y9Sw0H6FT2+VnHTRs65/NOVngimW zWKf0XEieV0Oh8Suhh6u29YBUVC8RhCrGjLVZTLhG3/shbk1m53USMfOmo7cG6SV 34njyC0maWbMPOkhKkBfXSjooUj5XEcRsCS3spj1ljeZCIKdr4fbpAuCQkxNOSjx soWacwVqSQXcUXog/IMvF3wyUjy+yTRafzQv+rBRSUNcUVn9HTpe24r3yD2B4uSw == X-ME-Sender: <xms:BW_nWYh6uVLagJTRmVShAvdNsujerOcqmmHM6wDAqX53S8upaff3ng> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4ED6524787; Wed, 18 Oct 2017 11:11:01 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, santosh <santosh.shukla@caviumnetworks.com>, John McNamara <john.mcnamara@intel.com>, olivier.matz@6wind.com Cc: dev@dpdk.org, hemant.agrawal@nxp.com, ferruh.yigit@intel.com Date: Wed, 18 Oct 2017 17:11:00 +0200 Message-ID: <5080617.0u8bCYeiHp@xps> In-Reply-To: <20171018143632.GA31948@jerin> References: <20170831063719.19273-1-santosh.shukla@caviumnetworks.com> <80cd844a-511e-5b27-4bc0-ea796611cb28@caviumnetworks.com> <20171018143632.GA31948@jerin> 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 18 Oct 2017 15:11:02 -0000 18/10/2017 16:36, Jerin Jacob: > From: santosh <santosh.shukla@caviumnetworks.com> > > > > 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? This is one of the two options I described in my last email. Our emails have crossed in the air :) The other option is to merge the mempool guide in the platform guide, assuming that a hardware mempool cannot be used with another platform, and assuming that the platform guide will give the big picture about memory addressing and capabilities, overlapping with mempool section. I am OK with both options.