Why would the hardware care? I'd imagine it would simply forward the data
to the system. I'd be rather surprised if it did otherwise.
It wouldn't change its buffer management at all, not would it required a
memory layout change.
-=R
On Wed, Jun 25, 2014 at 1:28 PM, Greg Wilkins <gregw@intalio.com> wrote:
> Roberto,
>
> CONTINUATION will not make hardware implementations more difficult,
> because they (like many other implementations) will just not implement
> continuation support.
>
> cheers
>
>
>
> On 25 June 2014 22:24, Roberto Peon <grmocg@gmail.com> wrote:
>
>> I don't see how CONTINUATION makes a hardware implementation more
>> difficult, though?
>> It doesn't at all change the buffer management.
>> -=R
>>
>>
>> On Wed, Jun 25, 2014 at 1:20 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
>> wrote:
>>
>>> In message <CAP+FsNcwTBLjn+CV0gnrpG_87U=
>>> xetOJsqoyFF5Ze+w_Ucwfpg@mail.gmail.com>
>>> , Roberto Peon writes:
>>>
>>> >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 requires far more complexity for a hardware implementation, and
>>> would
>>> >reduce the chance that we get acceleration in HW for HTTP2.
>>>
>>> But the elimination of CONTINUATION would more than offset that minor
>>> bit of complexity.
>>>
>>>
>>> --
>>> 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.
>>>
>>
>>
>
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com advice and support for jetty and cometd.
>