[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120423051359.GE11672@verge.net.au>
Date: Mon, 23 Apr 2012 14:14:02 +0900
From: Simon Horman <horms@...ge.net.au>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Stephen Hemminger <stephen.hemminger@...tta.com>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
dev@...nvswitch.org, eric dumazet <eric.dumazet@...il.com>
Subject: Re: [RFC v4] Add TCP encap_rcv hook (repost)
On Sun, Apr 22, 2012 at 11:54:42AM -0400, Jamal Hadi Salim wrote:
> On Sun, 2012-04-22 at 08:22 -0700, Stephen Hemminger wrote:
>
> > STT isn't really doing TCP, it just lying and pretending to be
> > TCP to allow TSO to work! There is no packet ordering, sequence
> > numbers or any real transport layer.
Yes, that is my understanding. Originally I envisaged that an STT
implementation would rely more heavily on the TCP stack. However, as
STT doesn't rely on any of the features of TCP other than its header
this was not the case and (almost) bypassing the TCP stack seems
to be sufficient.
I believe the motivation for reusing TCP is, as Stephen suggests,
to allow some hardware acceleration to occur.
> True. It is a nice engineering hack but even as a protocol enhancement
> questionable at best.
>
> > Therefore Simon's
> > proposed hook is the only way to support it. But exposing that
> > hook does allow for other misuse.
>
> If you object to this, then you gotta object to the UDP equivalent
> which has been around for sometime now for legitimate reasons
That is basically my reasoning too.
> and could be used by STT (I think the claim was no hardware
> does USO);->
I was not involved in the design of STT so I can't comment on that
although I do suspect you are correct.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists