[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <61c89e02-c916-421e-b469-62b307853b1b@tahiti.vyatta.com>
Date: Sun, 22 Apr 2012 08:22:24 -0700 (PDT)
From: Stephen Hemminger <stephen.hemminger@...tta.com>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, dev@...nvswitch.org,
eric dumazet <eric.dumazet@...il.com>, horms@...ge.net.au
Subject: Re: [RFC v4] Add TCP encap_rcv hook (repost)
> From: Simon Horman <horms@...ge.net.au>
> Date: Thu, 19 Apr 2012 13:53:35 +0900
>
> > This hook is based on a hook of the same name provided by UDP. It
> > provides
> > a way for to receive packets that have a TCP header and treat them
> > in some
> > alternate way.
> >
> > It is intended to be used by an implementation of the STT tunneling
> > protocol within Open vSwtich's datapath. A prototype of such an
> > implementation has been made.
> >
> > The STT draft is available at
> > http://tools.ietf.org/html/draft-davie-stt-01
>
> I think that unlike UDP, you need to let the stack handle the TCP
> packet before taking it into your subsystem. The reason is that
> otherwise you'll need to handle packet ordering, sequence number
> gaps,
> and proper TCP ACK'ing and timeout all inside of your module and
> that's simply unacceptable.
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. Therefore Simon's
proposed hook is the only way to support it. But exposing that
hook does allow for other misuse.
--
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