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