questions on fixed-buf variations other than read_fixed and write_fixed

[FrankReh]

sendmsg variations: prep_sendmsg_zc and prep_sendmsg_zc_fixed

1. Missing man page info: the kernel supports a prep_sendmsg_zc but there is no man page for it and the op is not in the io_uring_enter.2 man page. (edit: there is a man page for it now)

   There is support for it in the liburing API: io_uring_prep_sendmsg_zc is defined and there appears to be a path in test/send-zerocopy.c for testing it. Perhaps this should be added to the prep_sendmsg.3 and the io_uring_enter.2 man pages.

2. Missing liburing API: it appears the kernel is already supporting a fixed-buffer option to sendmsg_zc, but the liburing API does not include such a variation. Based on the names chosen for the prep_send options, I guess the name would be io_uring_prep_sendmsg_zc_fixed. (edit: this was probably incorrect, my apologies. A single fixed buffer wouldn't make much sense given the msghdr fields generally refer to multiple buffers.)

uring_cmd operation

1. Missing man page info. No liburing support for this. That's not a problem, per se, but the io_uring_enter.2 man page doesn't give even a mention to the IORING_OP_URING_CMD op but the io_uring_setup.2 man page does mention it when explaining the need for the larger sized SQE and CQE structures.
2. It does get tested via test/io_uring_passthrough.c.
3. The kernel appears to support a fixed-buffer variation of this, using the sqe->buf_index field when the IORING_URING_CMD_FIXED ioprio bit is set. But it is not tested in the io_uring_passthrough.c.
4. Additional man page info: and the io_uring_enter.2 man page would then cover this ioprio bit.

IORING_RECVSEND_FIXED_BUF flag

1. Was this name chosen to future proof the symbol even though there is no recv or recvmsg op that accepts a fixed buf or is it considered a misnomer by now? While designing the fixed-buf option for a Rust library, am wondering if it should be made general enough to cover some receive operations which may come in the future or if it will always just be for the zero-copy forms of send and sendmsg.

   And if it is just going to be used for the zero-copy forms, a question purely out of curiosity: why is the fixed-buf well suited for zero-copy send and sendmsg but not as well suited for the normal send and sendmsg?

[isilence]

IORING_RECVSEND_FIXED_BUF flag

1. Was this name chosen to future proof the symbol even though there is no recv or recvmsg op that accepts a fixed buf or is it considered a misnomer by now? While designing the fixed-buf option for a Rust library, am wondering if it should be made general enough to cover some receive operations which may come in the future or if it will always just be for the zero-copy forms of send and sendmsg.
   And if it is just going to be used for the zero-copy forms, a question purely out of curiosity: why is the fixed-buf well suited for zero-copy send and sendmsg but not as well suited for the normal send and sendmsg?

For zerocopy it saves some cycles on page pinning and so, but there should be almost no performance difference when we already memcpy the payload. Even though it can be implemented for generality, it would be useless performance wise. I didn't put much meaning into the RECV part of the name, the support might appear at some moment but I don't expect anyone being much interested in it.