[ovs-dev] [RFC v4] Add TCP encap_rcv hook (repost)

[David Miller]

From: Simon Horman <horms at verge.net.au>
Date: Mon, 23 Apr 2012 14:14:02 +0900

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

Yes, this is what the IETF draft states.

But I wonder about your encap_rcv hook placement, nevermind
that your posted patch won't compile since tcp_sock lacks
an encap_tcv member and your patch didn't add one. :-)

You'll need to somehow create either a fully established or a
listening socket for that hook to work.

You'd need to perform a full handshake to get a socket into
established state, and it seems STT doesn't do a TCP handshake.

That leaves you with the listening socket option, and in that case I
want to know how you're going to send packets out of this STT tunnel?

In order to get the advertised benefits of this STT thing, you'll need
to go through the whole TCP data packet sending engine, in order to
get all the TSO/GSO stuff initialized properly on the SKB so the NIC
will do it's thing.

But you can't send data out of an un-established TCP socket.

At the very least, we'll need to see the rest of your full
implementation before we can say whether this encap_rcv hook is the
right way to do things.