Date: Mon, 1 Sep 2014 07:10:49 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: [CFT/review] new sendfile(2) Message-ID: <20140901031049.GF7693@glebius.int.ru> In-Reply-To: <540382E2.3040004@freebsd.org> References: <20140529102054.GX50679@FreeBSD.org> <20140729232404.GF43962@funkthat.com> <20140831165022.GE7693@FreeBSD.org> <540382E2.3040004@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred, On Sun, Aug 31, 2014 at 01:17:38PM -0700, Alfred Perlstein wrote: A> > J> > 1) Split of socket buffer sb_cc field into sb_acc and sb_ccc. Where A> > J> > sb_acc stands for "available character count" and sb_ccc is "claimed A> > J> > character count". This allows us to write a data to a socket, that is A> > J> > not ready yet. The data sits in the socket, consumes its space, and A> > J> > keeps itself in the right order with earlier or later writes to socket. A> > J> > But it can be send only after it is marked as ready. This change is A> > J> > split across many files. A> > J> A> > J> This change really should be split out and possibly committed seperately A> > J> after a review by the proper people... A> > A> > Of course. It actually makes 80% of the volume of the patch. A> A> This change has high value, although it has a lot of changes for what A> appears to be an interesting edge case. A> A> As I read this it really confused me, can't this be accomplished by A> utilizing the socket's callback and pointer parameter instead? A> A> Basically you would put all that accounting inside a struct hung off of A> so->sb_snd.sb_upcallarg and set a callback to do your queuing. A> A> That is how you can async drive thread to queue more data, in fact by A> using aio to read/write to the socket from a stream. A> A> It should be relatively simple, the only tricky part being that you'll A> need to watch your locks and sleeps inside the so->sb_snd.sb_upcall A> function. A> A> Basically move the sb_acc and all of that into a special struct hung off A> of so->sb_snd.sb_upcallarg and leverage so->sb_snd.sb_upcall to queue A> more data as space becomes available. A> A> At least that's how I would have tried to accomplish this... but maybe A> you went down this path and hit a non-starter? AFAIU your proposal, you suggest to go even harder and make sendfile(2) not blocking on socket buffer being full. So that we can do sendfile(fd, s, 0, 1 Gb, ...) and return immediately. And kernel would bounce between disk and socket buffer until the end. This is another step towards Poul-Henning idea, that is in near email. No, I am not there yet :) My sendfile(2) simply doesn't block on the disk I/O. If the socket buffer is full it will either block or return EAGAIN, if it is SS_NBIO. The change to socket buffers in the patch is quite primitive. It touches so many files just because it substitutes bare access to sockbuf field with an inline. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140901031049.GF7693>