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 BDFF02A58 for ; Tue, 4 Jul 2017 11:42:42 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E4D7220AF2; Tue, 4 Jul 2017 05:42:41 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 04 Jul 2017 05:42:41 -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=xSkqHkDdkApRmQS DqXVrDEcy7O5qXi6iCI3AthfVEfc=; b=d2L7b/BvYfLprtHkdvNh6MkqVgvItAE FNKvqHKLp0efe9bGDgzgCtlIwAP7gDdlr7AULWSrISRzRWwaYftWT+ogv63RMZNd knG0IEvcKvNPJURj0X+4u/P/iKHmlDAOz/pVwjZCyV7m7jYDmOUYDENCU2C2cYuc Z7YmRORdSPuI= 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=xSkqHkDdkApRmQSDqXVrDEcy7O5qXi6iCI3AthfVEfc=; b=k66xtr57 QkgEfXEHQwywy7oPFOf1EEPB/SvMheOeSfq0sxDoC/WegZr+MRYoISJ89a8czava vFUYzP5RV4suSZpKndpjeJi+xkBye15SY2r3dRCOKP2puHX70w3R+65RoUoKtECu BMKCuzAYurs1t9aMaL5r/z7Gl7ydVJKZ8wUyivyh7QyUxZ5KiHvgDhJpK8+Artu2 fJPCDEiHeOy8xSdX78d2r6Ethf27fnD0kys+MTjxQGXI7QjRD/R2b78amvQcO099 5o/y/m2SZwRP9s3o0uWEPSPTvz36ntg6AS9iD13ix+3wzDNZm3s/DmD8YRWN7gRT 1AXx1aYyPqmtvw== X-ME-Sender: X-Sasl-enc: e1Tb1Hc9UwvQ/FlV2jhFY8K/ggIAOKsE7N2PwTPKyn2N 1499161361 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 95F25246E8; Tue, 4 Jul 2017 05:42:41 -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:42:40 +0200 Message-ID: <2284242.6gVytuhYS6@xps> In-Reply-To: References: <20170608110513.22548-1-santosh.shukla@caviumnetworks.com> <5582305.WQTxLAGo1s@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:42:43 -0000 04/07/2017 11:21, santosh: > > On Tuesday 04 July 2017 02:33 PM, Thomas Monjalon wrote: > > > 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. > > To review my own code? Or if its about pinging then you already picked and > asked list for review comment then why should I spam list by sending ping? Not reviewing your own code :) Yes you're right, I've tried to ping. People do not make a lot of reviews. That's where we need more help. There would be no problem if everyone waiting for a review were reviewing some patches from others. > >> BTW: Who is the bus maintainer? I don't see entry in MAINTAINER file. > > Bus code is new and there is no maintainer yet. > > then else you expect from author? Yes, there are several authors of the bus rework. > >>> - 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. > > I have not been told about that, so how author get to know. I could understand > code conflict , Can you suggest how to align and address time conflict, how > author could address time conflict? You could try to make other patches touching bus code to be reviewed, so integrated faster. > >> This initiatives came out from [1], and we put lot of effort in > > You forgot the [1] reference. > > http://dpdk.org/dev/patchwork/patch/24549/ > > If we're upto taking short cut then simply requested to push -iova-va as eal arg > but intent was to address in a proper way .. propose framework. That takes effort > and time!. Yes, I understand. It is a big work, and it may take time to be properly reviewed. It happens that we cannot get others working with us in the right timeframe. I try to coordinate but sometimes there are some fails. We can still try to speed things up and see what happens. > >> 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. > > You are missing a point and this why a review feedback on crux of rte_bus > design was essential. if we agreed on rte_xx_iova_mode() then changes > at malloc/mempool and vfio is trivial or could have thought upon way to address in simpler way. > And if there is disagreement then drop this approach. Provided if someone has better solution. > For that review comment on rte_bus changes a must. > > > 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. > > Which is part not understood? can you please elaborate on details? How would > author come to know about that? Do I need to send patches to some other list where > most of folks review? Santosh, please do not blame me, I cannot review everything on the mailing list. I am going to ask questions in order to make this cover letter easier to understand.