W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Stuck in a train -- reading HTTP/2 draft.

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Wed, 25 Jun 2014 19:30:02 +0000
To: Martin Thomson <martin.thomson@gmail.com>
cc: Jason Greene <jason.greene@redhat.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <1577.1403724602@critter.freebsd.dk>
In message <CABkgnnVZb7e9npjm0P+fT7VeCCv+2TKuo4djDRviA1wF8YD0OQ@mail.gmail.com>
, Martin Thomson writes:

>I know of at least one major operating system that supports this sort
>of function already.  And let's be clear: HTTP is important enough to
>allocate custom kernel resources to improve performance.  I'd argue
>that it's important enough to dedicate silicon to eke out a few
>milliseconds or watts.

While that is true, even in kernel code 16kB framesize is suboptimal
from a performance point of view when the majority of all objects
are larger than that.

At 100 Gbit/s, you'll be north of half a million frames per second,
statistically probably very close to full million frames per second.

Being able to cut that number by a factor of 10 will matter a lot to
performance -- even if you allocate silicon.

100 Gbit/s NICs are close to shipping in bulk and some people are
already talking about 400 Gbit/s ethernet as the next step.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Wednesday, 25 June 2014 19:30:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC