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. > > I think at one point you said it was ok to have the fast datapath go through the > cdev. We want the core to own the configuration/etc. This is the fast datapath. Maybe, but dmabuf binding and page extraction really can't be fast datapath, it just isn't fast to start with. You should be crystalizing the dmabuf into a MR and caching the DMA addrs like everything else and referring the MR on your fast path. > The high level idea in my mind is that we do basically what is done with our > control IOCTLs through the core, setting up contexts, etc. However, still create > a cdev for sending in the lists of pages to pin down since that is hot path. I > assume that cdev could be created by the core and owned rather than done by the > driver directly. I never really liked that HFI has effectively its own weird implementation of MRs and ODP hidden in the cdev. Jason
