On Fri, Jun 16, 2023 at 12:33:40PM -0400, Dennis Dalessandro wrote: > On 6/2/23 1:23 PM, Jason Gunthorpe wrote: > > On Fri, Jun 02, 2023 at 01:15:47PM -0400, Dennis Dalessandro wrote: > >>> So you will have to think carefully about is needed. It is part of why > >>> I don't want to take uAPI changed for incomplete features. I'm > >>> wondering how you will fit dmabuf into hfi1 when I won't be happy if > >>> this is done by adding dmabuf support to the cdev. > > The cdev just needs to know what type of memory it's dealing with. We expect the > dmabuf to be allocated and ready to use. Just like we would a GPU buffer. So > would you still reject the patch if we sent support for AMD's GPU instead of > dmabuf if it's all in-tree and upstream and we have the user code to go with it? I don't understand what that even means, how can you support AMD GPU without also using DMABUF? My big problem with this patch is I can't understand what it really even does because it is somehow tied to the HW functionality. Which is also very confusing because DMABUF is supposed to have general MR based code for processing MRs. We are not able to support DMABUF on "ODP" like situations, and AFAIK this hfi stuff is basically a weird version of ODP / some kernel support for registration caching. So maybe if you explain it better and more carefully, IDK. Jason
