On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote: > On Mon, Apr 23, 2012 at 2:08 PM, David Miller <da...@davemloft.net> wrote: > > From: Jesse Gross <je...@nicira.com> > > Date: Mon, 23 Apr 2012 13:53:42 -0700 > > > >> On Mon, Apr 23, 2012 at 1:13 PM, David Miller <da...@davemloft.net> wrote: > >>> From: Jesse Gross <je...@nicira.com> > >>> Date: Mon, 23 Apr 2012 13:08:49 -0700 > >>> > >>>> Assuming that the TCP stack generates large TSO frames on transmit > >>>> (which could be the local stack; something sent by a VM; or packets > >>>> received, coalesced by GRO and then encapsulated by STT) then you can > >>>> just prepend the STT header (possibly slightly adjusting things like > >>>> requested MSS, number of segments, etc. slightly). After that it's > >>>> possible to just output the resulting frame through the IP stack like > >>>> all tunnels do today. > >>> > >>> Which seems to potentially suggest a stronger intergration of the STT > >>> tunnel transmit path into our IP stack rather than the approach Simon > >>> is taking > >> > >> Did you have something in mind? > > > > A normal bonafide tunnel netdevice driver like GRE instead of the > > openvswitch approach Simon is using. > > Ahh, yes, that I agree with. Independent of this, there's work being > done to make it so that OVS can use the normal in-tree tunneling code > and not need its own. Once that's done I expect that STT will follow > the same model.
Hi Jesse, I am wondering how firm the plans to on allowing OVS to use in-tree tunnel code are. I'm happy to move my efforts over to an in-tree STT implementation but ultimately I would like to get STT running in conjunction with OVS. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
