On Tue, 24 Apr 2012 16:02:41 +0000 "Kyle Mestery (kmestery)" <kmest...@cisco.com> wrote:
> On Apr 23, 2012, at 9:25 PM, Simon Horman wrote: > > 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? > > > > Hi Simon: > > The VXLAN work has been slow going for me at this point. What I have works, > but is far from complete. It's available here: > > https://github.com/mestery/ovs-vxlan/tree/vxlan > > This is based on a fairly recent version of OVS. I'm currently working to > allow tunnels to be flow-based rather than port-based, as they currently > exist. As Jesse may have mentioned, doing this allows us to move most tunnel > state into user space. The outer header can now be part of the flow lookup > and can be passed to user space, so things like multicast learning for VXLAN > become possible. > > With regards to working together, ping me off-list and we can work something > out, I'm very much in favor of this! > My use of VXVLAN was to be key based (like existing GRE), not flow based. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
