Date: Thu, 12 Dec 2013 12:45:15 -0800 From: Adrian Chadd <adrian@freebsd.org> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: review request: sendfile kqueue notification Message-ID: <CAJ-Vmo=U%2BgKkYU=cGgAg-f17P-S-mEWYGmrfn9_C0WT-_Ms%2B3A@mail.gmail.com> In-Reply-To: <CAJ-VmomtUYE8O1XGy6a8OSbZwnxRzC1zfU9cx=V1=tBOOZywQg@mail.gmail.com> References: <CAJ-VmomtUYE8O1XGy6a8OSbZwnxRzC1zfU9cx=V1=tBOOZywQg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
And yes, I know this breaks the 32 bit compat sendfile call. I'm thinking of how to fix this without just duplicating all of that code. Thanks, -a On 12 December 2013 12:41, Adrian Chadd <adrian@freebsd.org> wrote: > Hi, > > I'd like to start committing this to FreeBSD-HEAD: > > http://people.freebsd.org/~adrian/netflix/20131211-sendfile-kqueue-11.diff > > It implements kqueue notifications for sendfile so users can get an > asynchronous notification that the underlying mbufs have been freed. > This allows userland users of sendfile to know that the underlying > memory / file object can be recycled or overwritten. Right now the > only way to do this is to set SF_SYNC and this causes sendfile() to > sleep until the transaction is complete and the mbufs have been freed. > > I've been testing this out locally in my lab environment and it's > running flawlessly at 30gbit/sec of TCP across 32,768 active > transmitting sockets. > > I'd like to start merging this into -HEAD in small pieces to make it > easier to MFC to -10. > > Thanks! > > > > -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=U%2BgKkYU=cGgAg-f17P-S-mEWYGmrfn9_C0WT-_Ms%2B3A>