Date: Thu, 28 Jan 2016 02:18:17 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: Refactoring asynchronous I/O Message-ID: <20160127231817.GA88527@zxy.spb.ru> In-Reply-To: <3640314.Du7Q0QmH0W@ralph.baldwin.cx> References: <2793494.0Z1kBV82mT@ralph.baldwin.cx> <1723457.HAUy43H1XN@ralph.baldwin.cx> <20160127210420.GZ88527@zxy.spb.ru> <3640314.Du7Q0QmH0W@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160127231817.GA88527>