Libguestfs - Jun 2021 - nbd_aio_p{read,write} responsibilities

I was going through the code and realized io_uring is similar to libev in
the way that we listen to the io events ourselves but the difference is
when we encounter the event we read it ourselves(io_uring), whereas in the
case of libev we ask libnbd to read it for us. We notify that the
connection is readable using ai_notify_read and the command is ran by the
state machine the command was queued by an earlier call to nbd_aio_pread.

My question is if we read from the socket using (let's say read[1]) what do
we need to do to inform the state machine we have done so, so that it can
function properly as I am assuming nbd_aio_pread modifies the state in some
way on enqueue and completion

Thanks and regards,
Abhay

---
[1]: io_uring has read but not recv in kernel 5.5
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libguestfs/attachments/20210618/2098b297/attachment.htm>

On Fri, Jun 18, 2021 at 03:38:16PM +0530, Abhay Raj Singh
wrote:
> I was going through the code and realized io_uring is similar to
> libev in the way that we listen to the io events ourselves but the
> difference is when we encounter the event we read it
> ourselves(io_uring), whereas in the case of libev we ask libnbd to
> read it for us. We notify that the connection is readable using
> aio_notify_read and the command is ran by the state machine the
> command was queued by an earlier call to nbd_aio_pread.
The current "nbd_aio_*" API isn't really designed around
completion
events.  You're thinking about the right thing: what would an nbd_*
API look like that could be implemented using io_uring?

I find it useful to write some example programs using a proposed new
API (obviously not programs that can be compiled) to explore what API
could work.
> My question is if we read from the socket using (let's say read[1])
> what do we need to do to inform the state machine we have done so,
> so that it can function properly as I am assuming nbd_aio_pread
> modifies the state in some way on enqueue and completion
The answer will be in the code :-)  I don't remember all the exact
details of how it works now.  The generated files are probably the
best place to start reading.
> [1]: io_uring has read but not recv in kernel 5.5
The main technical reason we currently use send/recv instead of
write/read is so we can pass the flags MSG_NOSIGNAL and MSG_MORE.
MSG_MORE is an optimization so we don't have to use it.  MSG_NOSIGNAL
is necessary, but at a first pass we could ignore it until we work out
what to do with it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/