From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 95ED81AFE8 for ; Mon, 9 Oct 2017 10:48:02 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0597B20D2A; Mon, 9 Oct 2017 04:48:02 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 09 Oct 2017 04:48:02 -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:x-sasl-enc; s=mesmtp; bh=T00XorlRuVvsb9n aq6H4ohJ6TYMatzxiobVlMaUcwac=; b=IiAENmHtvx//36wkdGjuj1E/tk4Eof/ eAPG7wgroT6H2wr+Dx5o0kwdGCbVP0783PBhrMr2aK6uYzcxXeyVaNcXVY2BBfjm Da2D5t70PLbFixDTwY/z5w0jgocxqC5QiYbVy4a5FG7c7uH5jlSHqAb5+bTQCrYM iuD47B9Ewsek= 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:x-sasl-enc; s= fm1; bh=T00XorlRuVvsb9naq6H4ohJ6TYMatzxiobVlMaUcwac=; b=lnw//WnI eiFEZaIfNBtBmRUaiJ4xa4Nhu6NxJ4wUvu+NGIfNfOh25aaI4Ak0O/4LNvSHdVg+ XSXXJCVUezJwJcUijRgHsBu7AL+keXsM49n07iYa/Ahey0LgCG7hjWnBEzwRxS0b UXimWuFefXZXVw6APXZhVLoEQdgIIoYWr/uawO3O8aL8iCu8WMuTPEYHTJQ3s1rd aXV/OtbjQYfUsFJ+w/VxCvjwGcGnzIGUJlEnEXLfWwG62N6QiIY9uE9HrY5e4XJk 3zD7CJJk233HRrV0MrKmEsyQQGVh7dkv5cn+xjbQ/nIMVAXainYX5ei8br2aZkQn PwVCjsJEKVMjtw== X-ME-Sender: X-Sasl-enc: yPs6pFCcT7wtjjNKqfbF+E9MI11iugUbV3ZuW1YU6kgS 1507538881 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id B20CB248B1; Mon, 9 Oct 2017 04:48:01 -0400 (EDT) From: Thomas Monjalon To: santosh Cc: dev@dpdk.org, olivier.matz@6wind.com, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, John McNamara , ferruh.yigit@intel.com Date: Mon, 09 Oct 2017 10:48:00 +0200 Message-ID: <79352056.QgdvfuXRzQ@xps> In-Reply-To: References: <20170831063719.19273-1-santosh.shukla@caviumnetworks.com> <0d07a0ca-5fb3-f275-9d5f-2f30a8503caa@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: Mon, 09 Oct 2017 08:48:02 -0000 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. > > If above said does not make sense then will follow Thomas proposition > > and propose a patch. > > > > Thoughts? > > > Additional input: > > mempool PMD logically can work across nics.. could be a reason > to not to mention under platform/octeontx or platform/dpaa ..etc.. I don't understand. OcteonTx mempool works only on OcteonTX? Are you saying that OcteonTX can be managed as a device? > IMO, Its worth adding a new section for mempool PMD. > > Thoughts? > > Regards, > > >> I choose to integrate this series without this last patch. > >> I mark this patch as rejected. > >> Please submit a new one separately. > >> > >>> It then adds the octeontx fpavf mempool PMD to the listed mempool > >>> devices. > >>> > >>> Cc: John McNamara > >>> > >>> Signed-off-by: Santosh Shukla > >>> Signed-off-by: Jerin Jacob > >>> Reviewed-by: John McNamara > >>> --- > >> [...] > >>> --- a/MAINTAINERS > >>> +++ b/MAINTAINERS > >>> @@ -340,6 +340,13 @@ F: drivers/net/liquidio/ > >>> F: doc/guides/nics/liquidio.rst > >>> F: doc/guides/nics/features/liquidio.ini > >>> > >>> +Cavium Octeontx Mempool > >>> +M: Santosh Shukla > >>> +M: Jerin Jacob > >>> +F: drivers/mempool/octeontx > >> A slash is missing at the end of the directory. > >> > >> Until now, the mempool and bus drivers are listed with net drivers. > >> We could move them in a platform section later. > >> For now, let's put it as "Cavium OcteonTX" in net drivers. > >> > >> I fixed and merged it with the first patch. > > Thanks. > > > > IMO, for MAINTAINERS file: > > Just like we have entry for "Eventdev Driver" and underneath > > to that- all vendor specific PMD sits, I was thinking to > > introduce "Mempool Drivers" such that we place all > > external mempool PMDs + s/w PMD (example: Ring) sits underneath. > > > > thoughts? No need to move SW mempool drivers in a different section. They are maintained by Olivier with the mempool core code. I have the feeling that all platform specific stuff (bus, mempool, makefile and config file) are maintained by the same persons. I think it is easier to know who contact for issues with a platform.