On Fri, Apr 1, 2022 at 6:52 AM Jens Axboe <axboe@xxxxxxxxx> wrote: > > On 3/22/22 11:10 AM, Kanchan Joshi wrote: > >> 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? > > Yes, I think we should just add support for 32-byte CQEs as well. Only > pondering I've done here is if it makes sense to manage them separately, > or if you should just get both big sqe and cqe support in one setting. > For passthrough, you'd want both. But eg for zoned writes, you can make > do with a normal sized sqes and only do larger cqes. I had the same thought. That we may have other use-cases returning a second result. For now I am doing 32-byte cqe with the same big-sqe flag, but an independent flag can be done easily. Combinations are: (a) big-sqe with big-cqe (for nvme-passthru) (b) big-sqe without big-cqe (inline submission but not requiring second result) (c) regular-sqe with big-cqe (for zone-append) (d) regular-sqe with regular-cqe (for cases when inline submission is not enough e.g. > 80 bytes of cmd) At this point (d) seems rare. And the other three can be done with two flags.
