Re: [dpdk-dev] [PATCH 00/10] Infrastructure to detect iova mapping on the bus

[Thomas Monjalon <thomas@monjalon.net>]

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.