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

Re: #540: "jumbo" frames

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 25 Jun 2014 14:05:53 -0700
Message-ID: <CAP+FsNfm+Y6y0oe1yh7-YYaeJBRPzJVRdEdeFFxTGj2f8jd3CA@mail.gmail.com>
To: "K.Morgan@iaea.org" <K.Morgan@iaea.org>
Cc: Willy Tarreau <w@1wt.eu>, Patrick McManus <pmcmanus@mozilla.com>, Jason Greene <jason.greene@redhat.com>, Nicholas Hurley <hurley@todesschaf.org>, Mark Nottingham <mnot@mnot.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Dürst <duerst@it.aoyama.ac.jp>
On Wed, Jun 25, 2014 at 1:59 PM, <K.Morgan@iaea.org> wrote:

> On 25 June 2014 22:12, grmocg@gmail.com wrote:
> > Look at this from a hardware engineer's perspective.
> > This bit changes how you must structure hardware buffers in order to
> parse things properly.
>
> This is a good point, and valuable feedback for designing jumbo frames,
> but easily solvable with Willy's proposal or any other variation with a
> fixed length field for the payload length.
>
> > This requires far more complexity for a hardware implementation,
> > and would reduce the chance that we get acceleration in HW for HTTP2.
>
> Exactly what is the http2 hardware acceleration doing? Reassembling frames?
>

Assembling or removing the framing, yes.
In the end the application doesn't care about the framing. It cares about
getting the data in the order it requested as a stream of bytes or
messages, and possibly it cares about padding.
-=R


> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>
Received on Wednesday, 25 June 2014 21:06:25 UTC

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