On 6/2/23 9:42 AM, Jason Gunthorpe wrote: > I think we said long ago that this was the last HW that can use the > hfi1 cdev. Yeah. I don't want to conflate the two things though. This patch is specifically for the older HW. > 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. 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. >> Is that going to be considered an incomplete feature? Should we >> wait until it's all done and ship it all at once? I was envisioning doing things >> the way we did for rdmavt, showing our work so to speak, making incremental >> changes overtime as opposed to how we submitted the original hfi1 code in a >> giant blob. > > I think it depends, stay away from the uapi and things are easier The new chip doesn't require any changes to uapi. We'll start sending patches soon then. -Denny
