lkml.org 
[lkml]   [2021]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support
From
Date
Am 10.12.21 um 14:26 schrieb Jason Gunthorpe:
> On Fri, Dec 10, 2021 at 01:47:37PM +0100, Christian König wrote:
>> Am 10.12.21 um 13:42 schrieb Jason Gunthorpe:
>>> On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote:
>>>> Hi Jason,
>>>> Thank you for replying.
>>>>
>>>> 2021年12月8日(水) 2:14 Jason Gunthorpe <jgg@ziepe.ca>:
>>>>> On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote:
>>>>>> Hi maintainers,
>>>>>>
>>>>>> Could you please review this patch series?
>>>>> Why is it RFC?
>>>>>
>>>>> I'm confused why this is useful?
>>>>>
>>>>> This can't do copy from MMIO memory, so it shouldn't be compatible
>>>>> with things like Gaudi - does something prevent this?
>>>> I think if an export of the dma-buf supports vmap, CPU is able to access the
>>>> mmio memory.
>>>>
>>>> Is it wrong? If this is wrong, there is no advantages this changes..
>>> I don't know what the dmabuf folks did, but yes, it is wrong.
>>>
>>> IOMEM must be touched using only special accessors, some platforms
>>> crash if you don't do this. Even x86 will crash if you touch it with
>>> something like an XMM optimized memcpy.
>>>
>>> Christian? If the vmap succeeds what rules must the caller use to
>>> access the memory?
>> See dma-buf-map.h and especially struct dma_buf_map.
>>
>> MMIO memory is perfectly supported here and actually the most common case.
> Okay that looks sane, but this rxe RFC seems to ignore this
> completely. It stuffs the vaddr directly into a umem which goes to all
> manner of places in the driver.
>
> ??

Well, yes that can go boom pretty quickly.

Not sure what they want to use this for.

Christian.

>
> Jason

\
 
 \ /
  Last update: 2021-12-10 14:31    [W:0.071 / U:2.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site