On Apr 24, 2012, at 11:13 AM, Stephen Hemminger wrote: > 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. >
Yes, for OVS the idea is to add the tunnel key values to the flow-key in the OVS kernel module. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
