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

[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?

>> 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?

>
>>> - 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?

>
>> 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!.

>
>> 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?

Thanks.