I see sctp_recvmsg is a wrapper for recvmsg call and also there isn't anything like io_uring_prep_sctp_recvmsg, so would I be wrong in concluding what I need to do is effectively repeat what sctp_recvmsg code is doing replacing its internal recvmsg call with io_uring_prep_recvmsg (and adding corresponding cqe parts to build struct sctp_sndrcvinfo)?

May I ask what code you refer to when you mention QUIC implementation with io_uring?

I've a followup question:
When using io_uring_prep_recvmsg_multishot with io_uring_buf_ring, which is brilliant, the part that's seems awkward is handling of returned struct msghdr. If it was somehow attached to the buffer all would be great, kernel selects buffer from buf_ring, fills it, etc. etc. But as in this api msghdr isn't attached to the buffer, especially in multishot case won't it overwrite msghdr over and over if user is too slow reacting and retrieving it when its ready?
Logically (esp for SCTP) the msghdr is kind of part of the message, so each time buffer fills it goes with its own header; having such a convenient component as buff_ring but requiring user to jump through hoops to retrieve and keep associated msghdr seems an odd choice. Am I completely missing something?

Actually, looks like message header is attached to the buffer, as prepended struct io_uring_recvmsg_out. Haven't seen it in the docs, only in src, and still need to confirm that to be the case. Would be super nice if it was documented or a worked example provided though.