[PATCH] dma-buf: add DMA_BUF_IOCTL_SYNC_PARTIAL support

[Rong Qianfeng]

在 2024/4/9 23:34, Christian König 写道:
> Am 09.04.24 um 09:32 schrieb Rong Qianfeng:
>>
>> 在 2024/4/8 15:58, Christian König 写道:
>>> Am 07.04.24 um 09:50 schrieb Rong Qianfeng:
>>>> [SNIP]
>>>>> Am 13.11.21 um 07:22 schrieb Jianqun Xu:
>>>>>> Add DMA_BUF_IOCTL_SYNC_PARTIAL support for user to sync dma-buf with
>>>>>> offset and len.
>>>>>
>>>>> You have not given an use case for this so it is a bit hard to 
>>>>> review. And from the existing use cases I don't see why this 
>>>>> should be necessary.
>>>>>
>>>>> Even worse from the existing backend implementation I don't even 
>>>>> see how drivers should be able to fulfill this semantics.
>>>>>
>>>>> Please explain further,
>>>>> Christian.
>>>> Here is a practical case:
>>>> The user space can allocate a large chunk of dma-buf for 
>>>> self-management, used as a shared memory pool.
>>>> Small dma-buf can be allocated from this shared memory pool and 
>>>> released back to it after use, thus improving the speed of dma-buf 
>>>> allocation and release.
>>>> Additionally, custom functionalities such as memory statistics and 
>>>> boundary checking can be implemented in the user space.
>>>> Of course, the above-mentioned functionalities require the 
>>>> implementation of a partial cache sync interface.
>>>
>>> Well that is obvious, but where is the code doing that?
>>>
>>> You can't send out code without an actual user of it. That will 
>>> obviously be rejected.
>>>
>>> Regards,
>>> Christian.
>>
>> In fact, we have already used the user-level dma-buf memory pool in 
>> the camera shooting scenario on the phone.
>>
>> From the test results, The execution time of the photo shooting 
>> algorithm has been reduced from 3.8s to 3s.
>>
>> To be honest, I didn't understand your concern "...how drivers should 
>> be able to fulfill this semantics." Can you please help explain it in 
>> more detail?
>
> Well you don't give any upstream driver code which actually uses this 
> interface.
>
> If you want to suggest some changes to the core Linux kernel your 
> driver actually needs to be upstream.
>
> As long as that isn't the case this approach here is a completely no-go.

Ok, I get it now, thanks!

Regards,

Rong Qianfeng.

>
> Regards,
> Christian.
>
>>
>> Thanks,
>>
>> Rong Qianfeng.
>>
>>>
>>>>
>>>> Thanks
>>>> Rong Qianfeng.
>>>
>