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 A89842C8 for ; Tue, 4 Jul 2017 11:03:30 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5BA6C20716; Tue, 4 Jul 2017 05:03:30 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 04 Jul 2017 05:03:30 -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=9SkLB0omf/ZGMFc GLtp1x+P/cr9y2uc+h16YRxjCYLk=; b=aLpIBelYHW6cZnOXzG5e2yx5FgZX6za Xj0ZnxkejeQlZwZ57ZO7CJrrz2hOAb1D6VrbzhCRRJacFZBE/kbS2k6qxOTdqOZA ctFZrnPBSPWzWpPp8Uaq++RldbdeyyliYJlysA99ggmBui9sVk/uD774BVVzzRUJ UFmabdsj9NWk= 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=9SkLB0omf/ZGMFcGLtp1x+P/cr9y2uc+h16YRxjCYLk=; b=cn2RtHUN gO/0UkMfWBVn8WzNsf8czGCiUSaTzHaOZemmgQhw0nVxLdPbUJ7li3Jn71H/7ClY ke75U8WXxFY8ipUwpITPnWHXGSH5+kZWy0s9lKO9CY03GEJs3PIRvBZ4hVTT4Uor rMSll5NLf4Un5rQOCEVIXVejovtM3ABSRef5f4nCMn2btna+umZx4p14omYf6zjC WEjIkMfIjqZ1AWy9D+aiygQLY6OZr2+Me369sfv80F7VwTjMaNWifMrM0707Mppv o5T5CAiih9ROfRb4Lo1iSj0UDw3ueMx4oCg0Id441Xt72HPeaByHSueLHOXNGsyK RCoZ//QPVCksVw== X-ME-Sender: X-Sasl-enc: UP1K/DDGVMRi2xXjAYIr/nB232ca6N7k6fXZUTbg8Njp 1499159010 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C3E77E82A; Tue, 4 Jul 2017 05:03:30 -0400 (EDT) From: Thomas Monjalon To: santosh Cc: dev@dpdk.org, bruce.richardson@intel.com, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, shreyansh.jain@nxp.com, gaetan.rivet@6wind.com, sergio.gonzalez.monroy@intel.com, Anatoly Burakov Date: Tue, 04 Jul 2017 11:03:29 +0200 Message-ID: <5582305.WQTxLAGo1s@xps> In-Reply-To: References: <20170608110513.22548-1-santosh.shukla@caviumnetworks.com> <2628050.KKD6Gl9D8Z@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 00/10] Infrastructure to detect iova mapping on the bus 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: Tue, 04 Jul 2017 09:03:31 -0000 04/07/2017 09:57, santosh: > Hi Thomas, > > On Tuesday 04 July 2017 12:49 PM, Thomas Monjalon wrote: > > > 04/07/2017 06:41, santosh: > >> Ping? > > You should try to ping Sergio, memory maintainer, > > and Anatoly, VFIO maintainer. > > > > Given that > > - there is no review at all, > > By default if no review then its maintainer responsibility to review Or > ask someone to review? Yes, but it is also the responsibility of the author. > BTW: Who is the bus maintainer? I don't see entry in MAINTAINER file. Bus code is new and there is no maintainer yet. > > - it is conflicting with the bus/PCI rework in progress, > > it will not be considered for 17.08. > > We're adding only two new iommu_class bus api in rte_bus, I'm not sure > about conflict. If there is conflict then I should see review comment for > same in my patch set? It is mostly a time conflict. > This initiatives came out from [1], and we put lot of effort in You forgot the [1] reference. > breaking down api from bus till library layer. This framework indeed > a need for those platform which cares for iova=va like octeontx, dpaa2 and > perhaps many future SoCs. W/o this framework, we can't get pktio working for octeontx ethdev > in dpdk, can't get HW pool manager working for Octeontx offload blocks. > > I agree that I missed on sergio or Anatoly But crux of design is rte_bus > layer. I expect comment on those area, right? > > And if we have consent on bus approach then rest changes are trivial. > > I didn't ping before as You had picked my patch set and asked for review comment in past. > > Can we include it in RC2? Because it will delay upstreaming effort of octeontx ethdev driver > and other dependent driver for us. This series is touching to many parts of DPDK. It really depends on maintainers of malloc, mempool and vfio. I'm also afraid your cover letter is too difficult to understand, because most of us do not know the acronyms you are talking about. I will comment on it.