Refactoring asynchronous I/O

[John Baldwin]

On Thursday, January 28, 2016 02:18:17 AM Slawa Olhovchenkov wrote:
> On Wed, Jan 27, 2016 at 01:16:37PM -0800, John Baldwin wrote:
> 
> > On Thursday, January 28, 2016 12:04:20 AM Slawa Olhovchenkov wrote:
> > > On Wed, Jan 27, 2016 at 09:52:12AM -0800, John Baldwin wrote:
> > > 
> > > > On Wednesday, January 27, 2016 01:52:05 PM Slawa Olhovchenkov wrote:
> > > > > On Tue, Jan 26, 2016 at 05:39:03PM -0800, John Baldwin wrote:
> > > > > 
> > > > > > The original motivation for my changes is to support efficient zero-copy
> > > > > > receive for TOE using Chelsio T4/T5 adapters.  However, read() is ill
> > > > > 
> > > > > I undertuns that not you work, but: what about (teoretical) async
> > > > > open/close/unlink/etc?
> > > > 
> > > > Implementing more asynchronous operations is orthogonal to this.  It
> > > > would perhaps be a bit simpler to implement these in the new model
> > > > since most of the logic would live in a vnode-specific aio_queue
> > > > method in vfs_vnops.c.  However, the current AIO approach is to add a
> > > > new system call for each async system call (e.g. aio_open()).  You
> > > > would then create an internal LIO opcode (e.g. LIO_OPEN).  The vnode
> > > > aio hook would then have to support LIO_OPEN requests and return the
> > > > opened fd via aio_complete().  Async stat / open might be nice for
> > > > network filesystems in particular.  I've known of programs forking
> > > > separate threads just to do open/fstat of NFS files to achieve the
> > > > equivalent of aio_open() / aio_stat().
> > > 
> > > Some problem exist for open()/unlink/rename/etc -- you can't use
> > > fd-related semantic.
> > 
> > Mmmm.  We have an aio_mlock().  aio_open() would require more of a special
> > case like aio_mlock().  It's still doable, but it would not go via the
> > fileop, yes.  fstat could go via the fileop, but a path-based stat would
> > be akin to aio_open().
> 
> aio_rename require yet more of special handling.
> As I see this is can't be packed in current structures (aiocb and
> perhaps sigevent). I am don't see space for multiple paths. I am don't
> see space for fd return.
> 
> Need to change some semantics (dissalow some notifications, for
> examples, only SIGEV_THREAD will be allowed? How pass information
> about called aio operation?). 
> 
> Also, may be some problems inside kernel for fd-less operations?

The kernel side of aiocb is free to hold additional information, and you
could always pass additional information via arguments, e.g.

aio_rename(aiocb, from, to)

(Alternatively, you could define aio_buf as pointing to a structure
that holds arguments.)

-- 
John Baldwin