Skip site navigation (1)Skip section navigation (2)
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>