Date: Thu, 11 Jul 2013 01:37:19 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: hacking - aio_sendfile() Message-ID: <CAJ-VmomFcZv6_uhpy6ShBzL21=Fqw7_y2xE2oYGod2T=Z5Qgpg@mail.gmail.com> In-Reply-To: <20130711061753.GK91021@kib.kiev.ua> References: <CAJ-Vmo=icr6bda%2BWMNUarc3WbdqJ%2BMdauX6kByxxdTx8oSovBg@mail.gmail.com> <20130711061753.GK91021@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hiya, I'm more interested in the API than the implementation at the moment. Yes, you're right - it should eventually be driven using disk io completion upcalls which triggers the push of data into the socket buffer. I totally agree. I'm hacking up some libevent-ish looking thing that uses kqueue and wraps aio, read, write, and other event types into something I can easily shoehorn this stuff into. I'll then throughly test it (and other options) out. You're right, it's likely going to end up with a whole lot of aio threads sitting there waiting for disk IO to complete - and at that point, I'll start hacking at sendfile() to split it into two halves and have it driven by a completion call from g_up or wherever, triggering the socket write side of things. There are some other questions too - like whether the IO completion should just queue socket IO (and have it potentially block in the TCP code) or whether it should funnel completions into a per-CPU aio completion thread which does the socket write bit. That way disk IO completion isn't going to be blocked by longer-held locks in the networking stack. Thanks, -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomFcZv6_uhpy6ShBzL21=Fqw7_y2xE2oYGod2T=Z5Qgpg>