Re: [PATCH 00/16] IB/hfi1: Add a page pinning cache for PSM sdma

[Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

On Mon, Mar 14, 2016 at 11:19:53PM +0200, Or Gerlitz wrote:
>On Mon, Mar 14, 2016 at 2:01 PM, Dennis Dalessandro
><dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> On Mon, Mar 14, 2016 at 09:09:51AM +0200, Leon Romanovsky wrote:
>>>
>>> Hi Doug,
>>> I saw that you picked these patches and it is now in your github
>>> repository. Since the original author probably missed my and Or's
>>> questions, It
>>> will be great if you can share with us your technical view on the topic.
>>>
>>> In addition to my question regarding appropriate layer - IB/core. MM, I
>>> see that
>>> it can be natively implemented in user-space layer too.
>
>> The original author did not miss your questions. When I say "we" or "our"
>> you can be assured that includes the original author.
>
>Just to make sure we're on the same page(...) submitting code to the
>upstream kernel is not send-and-forget, authors should respond to
>questions posed on their patches and this is very much not the case
>how you act here.
>
>> Our position continues to be that this is best located in the hfi1 driver.
>> If something else comes along that can make use of the same/similar
>> functionality we can then move it to the core or elsewhere, once we have a
>> better understanding of the use cases and how best to generalize the code.
>
>As I wrote your on this thread, you have all you need in user-space,
>expect for mmu notifications for cache entries which were invalidated
>by memunmaps, which indeed should originate from the kernel -- as such
>the cache doesn't belong to the kernel at all. You didn't respond on
>that, just ignored, and now again talking on the cache being in the
>core, why?

I said "core or elsewhere". Elsewhere may well include user space. That is 
just a different solution than what we have proposed. I agree that it is 
certainly one alternative. I'd like to see what Doug's opinion on the matter 
is.

>Doug, As Dennis noted, you already picked ~300 patches for 4.6 / hfi1
>driver from him. I don't see why picking this patch series there too
>and not letting us to further discuss it out, thoughts?
>
>Or.

I believe in taking an iterative approach to kernel development, if the code 
doesn't cause problems I don't see any harm adding the series. If Doug 
agrees with you and doesn't like this approach but is willing to let it 
stand for now,  I think the changes can be done in a subsequent release.

-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html