On Fri, Mar 11, 2022 at 11:57 AM Christoph Hellwig <hch@xxxxxx> wrote: > > And that's because this ioctl requires additional "__u64 result;" to > > be updated within "struct nvme_passthru_cmd64". > > To update that during completion, we need, at the least, the result > > field to be a pointer "__u64 result_ptr" inside the struct > > nvme_passthru_cmd64. > > Do you see that is possible without adding a new passthru ioctl in nvme? > > We don't need a new passthrough ioctl in nvme. Right. Maybe it is easier for applications if they get to use the same ioctl opcode/structure that they know well already. > We need to decouple the > uring cmd properly. And properly in this case means not to add a > result pointer, but to drop the result from the _input_ structure > entirely, and instead optionally support a larger CQ entry that contains > it, just like the first patch does for the SQ. Creating a large CQE was my thought too. Gave that another stab. Dealing with two types of CQE felt nasty to fit in liburing's api-set (which is cqe-heavy). Jens: Do you already have thoughts (go/no-go) for this route?
