Messages in this thread | | | Date | Wed, 10 Apr 2024 15:09:42 +0800 | Subject | Re: [PATCH] dma-buf: add DMA_BUF_IOCTL_SYNC_PARTIAL support | From | 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. >>> >
| |