On Mon, Apr 23, 2012 at 09:40:57PM -0700, Stephen Hemminger wrote: > > > ----- Original Message ----- > > On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote: > > > On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <ho...@verge.net.au> > > > wrote: > > > > 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. > > > > > > I would say that it's a firm goal but the implementation probably > > > still has a ways to go. Kyle Mestery (CC'ed) has volunteered to > > > work > > > on this in support of adding VXLAN, which needs some additional > > > flexibility that this approach would also provide. You might want > > > to > > > talk to him to see if there are ways that you guys can work > > > together > > > on it if you are interested. Having better integration with > > > upstream > > > tunneling is definitely a step that OVS needs to make and sooner > > > would > > > be better than later. > > > > Hi Jesse, Hi Kyle, > > > > that sounds like an excellent plan. > > > > Kyle, do you have any thoughts on how we might best work together on > > this? > > Perhaps there are some patches floating around that I could take a > > look at? > > ChrisW had a start to VxVlan tunnel (non OVS), and I promised to work on > finishing
Thanks. I guess that I might be able to base parts of an STT implementation on that work. I'd like to use an STT implementation with OVS, so in-tree tunnel support for OVS is also important to me. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
