On Sat, Aug 01, 2015 at 06:52:14AM -0400, Russell Bryant wrote: > On 08/01/2015 12:44 AM, Ben Pfaff wrote: > > On Fri, Jul 31, 2015 at 10:19:32PM -0400, Russell Bryant wrote: > >> On 07/31/2015 07:26 PM, Ben Pfaff wrote: > > Sorry, I forgot that there was a detailed example earlier. I didn't > > mean to make you go to a lot of work to repeat it. > > No problem. I copied it for the most part. :-) > > As you suggested, I'll incorporate it into the commit message, as well.
Thanks. > > I am slightly concerned about having a pair of patch ports per provider > > network port (that is what the above implies, right?), but let's go > > ahead and try that and if it's a problem we can figure out an > > optimization. > > No, the repetition is only in the logical space. There's only a single > pair of patch ports per provider network. In the above example, the > input flow looks like this: > > cookie=0x0, duration=338.834s, table=0, n_packets=0, n_bytes=0, > priority=100,in_port=1 > actions=set_field:0x1->reg5,set_field:0x2->metadata,set_field:0x4->reg6,resubmit(,16),set_field:0x3->metadata,set_field:0x6->reg6,resubmit(,16),set_field:0x1->metadata,set_field:0x2->reg6,resubmit(,16),set_field:0x4->metadata,set_field:0x8->reg6,resubmit(,16) > > This seemed like a good stopping point to make sure I had everything > right (I didn't ;-) ). I still need to add VLAN support, which I was > thinking would result in 1 patch port per VLAN. So, there could be a > lot more in that case. I suppose I could try to do it all with flows, > instead? I guess it wouldn't be too hard, if we used a single trunk port rather than VLAN access ports to join the two bridges. But I'm also willing to just do the simple thing, if access ports are simpler, and take a "wait and see" attitude on whether the cost is too high somehow. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
