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

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

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 25 Jun 2014 21:51:20 +0200
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Martin Thomson <martin.thomson@gmail.com>, Jason Greene <jason.greene@redhat.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20140625195120.GT5531@1wt.eu>
On Wed, Jun 25, 2014 at 07:30:02PM +0000, Poul-Henning Kamp wrote:
> 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.

16kB-1 please, or 3.99975589375 pages, thus 3 pages hence 12kB or 8 MSS
in practice for most usages :-(

> 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.

Yes and at 3 GHz, that's 3000 cycles per frame, which are easily
wasted doing a plain data copy of 16383 bytes, some cache misses +
a little bit of synchronization job. I'd rather have 30000 cycles
to forward 10 times this and avoiding the copy.

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

Especially if moved to sillicon, because the round-trip to hardware
is particularly expensive, which is why some chip makers have moved
the crypto accelerators into the CPU's instruction set for example.

> 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.

I'm impatient :-)

Received on Wednesday, 25 June 2014 19:51:48 UTC

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