Date: Wed, 27 Jan 2016 09:52:12 -0800 From: John Baldwin <jhb@freebsd.org> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: arch@freebsd.org Subject: Re: Refactoring asynchronous I/O Message-ID: <1723457.HAUy43H1XN@ralph.baldwin.cx> In-Reply-To: <20160127105205.GP37895@zxy.spb.ru> References: <2793494.0Z1kBV82mT@ralph.baldwin.cx> <20160127105205.GP37895@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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(). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1723457.HAUy43H1XN>