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

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 :-)

Willy

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