[ovs-dev] STT Implementation Thoughts

Simon Horman horms at verge.net.au
Mon Mar 26 05:36:31 UTC 2012


On Wed, Mar 21, 2012 at 12:09:09PM -0700, Jesse Gross wrote:
> On Wed, Mar 21, 2012 at 1:52 AM, Simon Horman <horms at verge.net.au> wrote:
> > Hi Jesse, Hi all,
> >
> > I am currently investigating how STT[1] may be implemented for Open vSwtich.
> > In the course of this it has struck me that a property particular
> > to STT is that it uses the TCP IP protocol number but actually isn't TCP.
> > Which makes me wonder how the receive-side it may be hooked into the Linux
> > kernel.
> >
> > My thought so far is that some modifications may need to be made to
> > tcp_v4_rcv() and/or tcp_v6_rcv() to skip TCP processing of packets
> > for sockets that have been bound by STT. But I was wondering if you
> > have any thoughts on this.
> 
> I agree it is an issue.  I think what we want is something analogous
> to encap_rcv in the UDP stack, which is used for exactly this purpose
> (for example, the OVS CAPWAP implementation uses it, as do L2TP and
> UDP encapsulated IPsec upstream).  It's perhaps somewhat more likely
> to be contentious since with UDP the packets are still processed by
> the UDP stack just without the userspace termination part whereas this
> takes the TCP state machine out of the picture but as least there is
> precedent.

Agreed, it does seem that there could be some cause for contention there.

The next thing that I am puzzling over is how to select a source port.
The draft makes reference to using a hash, which seems like a nice idea.
However I am concerned about ensuring that a) the port isn't already in use
and b) nothing else uses it while STT is using it. It seems to me that
an obvious but not necessarily very efficient way to do this would be to
create a sock using sock_create() and bind it using a modified
version if inet_bind() or similar. Do you have any thoughts on this.



More information about the dev mailing list