svn commit: r293439 - in head: lib/libc/sys sys/dev/ti sys/kern sys/sys usr.bin/netstat

[NGie Cooper]

> On Jan 8, 2016, at 13:10, Gleb Smirnoff <glebius at FreeBSD.org> wrote:
> 
> On Fri, Jan 08, 2016 at 12:44:32PM -0800, NGie Cooper wrote:
> N> > Log:
> N> >  New sendfile(2) syscall. A joint effort of NGINX and Netflix from 2013 and
> N> >  up to now.
> N> > 
> N> >  The new sendfile is the code that Netflix uses to send their multiple tens
> N> >  of gigabits of data per second. The new implementation features asynchronous
> N> >  I/O, when I/O operations are launched, but not awaited to be complete. An
> N> >  explanation of why such behavior is beneficial compared to old one is
> N> >  going to be too long for a commit message, so we will skip it here.
> N> > 
> N> >  Additional features of new syscall are extra flags, which provide an
> N> >  application more control over data sent. The SF_NOCACHE flag tells
> N> >  kernel that data shouldn't be cached after it was sent. The SF_READAHEAD()
> N> >  macro allows to specify readahead size in pages.
> N> > 
> N> >  The new syscalls is a drop in replacement. No modifications are required
> N> >  to applications. One can take nginx binary for stable/10 and run it
> N> >  successfully on head. Although SF_NODISKIO lost its original sense, as now
> N> >  sendfile doesn't block, and now means something completely different (tm),
> N> >  using the new sendfile the old way is absolutely safe.
> N> > 
> N> >  Celebrates:	Netflix global launch!
> N> >  Sponsored by:	Nginx, Inc.
> N> >  Sponsored by:	Netflix
> N> >  Relnotes:	yes
> N> 
> N> Did anyone review these changes and the other changes made recently to sys/kern and sys/net* ?
> 
> 1) The review requests were sent continuosly to arch@ during last 1.5 years.
> 
>   https://lists.freebsd.org/pipermail/freebsd-arch/2014-May/015385.html
> 
> 2) Team of engineers at Netflix has a lot of code build on top of that code,
>   e.g. SSL_sendfile(). Of course, writing something on top assumes reviewing,
>   so assume it reviewed thoroughly by rrs at . Actually, here is list of people
>   who did some review of the code: emax@, rrs@, scottl@, gallatin@, imp at .
> 
> 3) Do you have any particulars concerns with this change or those made recently
>   to sys/kern and sys/net*?

I don’t as of right now, other than it’s really difficult to audit changes and assess risk if someone doesn’t have access to the CRs :(.

Also…

N> >  An
N> >  explanation of why such behavior is beneficial compared to old one is
N> >  going to be too long for a commit message, so we will skip it here.

This wasn’t really helpful. It would have been nice if there was a wiki page or some other reference used in this commit which would have described the where, why, and how behind this change a lot more.

Thanks,
-NGie