On 10/14/24 13:10, Miklos Szeredi wrote: > On Mon, 14 Oct 2024 at 04:44, Ming Lei <tom.leiming@xxxxxxxxx> wrote: > >> It also depends on how fuse user code consumes the big CQE payload, if >> fuse header needs to keep in memory a bit long, you may have to copy it >> somewhere for post-processing since io_uring(kernel) needs CQE to be >> returned back asap. > > Yes. > > I'm not quite sure how the libfuse interface will work to accommodate > this. Currently if the server needs to delay the processing of a > request it would have to copy all arguments, since validity will not > be guaranteed after the callback returns. With the io_uring > infrastructure the headers would need to be copied, but the data > buffer would be per-request and would not need copying. This is > relaxing a requirement so existing servers would continue to work > fine, but would not be able to take full advantage of the multi-buffer > design. > > Bernd do you have an idea how this would work? I assume returning a CQE is io_uring_cq_advance()? In my current libfuse io_uring branch that only happens when all CQEs have been processed. We could also easily switch to io_uring_cqe_seen() to do it per CQE. I don't understand why we need to return CQEs asap, assuming CQ ring size is the same as SQ ring size - why does it matter? If we indeed need to return the CQE before processing the request, it indeed would be better to have a 2nd memory buffer associated with the fuse request. Thanks, Bernd
