On Wed, Mar 16, 2016 at 11:47:21AM -0600, Ryan Moats wrote: > > "dev" <dev-boun...@openvswitch.org> wrote on 03/14/2016 01:01:16 PM: > > > From: Ryan Moats/Omaha/IBM@IBMUS > > To: Ben Pfaff <b...@ovn.org> > > Cc: ovs dev <dev@openvswitch.org>, Guru Shetty <g...@ovn.org> > > Date: 03/14/2016 01:01 PM > > Subject: Re: [ovs-dev] [RFC 0/8] OVN east-west loadbalancing. > > Sent by: "dev" <dev-boun...@openvswitch.org> > > > > "dev" <dev-boun...@openvswitch.org> wrote on 03/14/2016 12:57:10 PM: > > > > > From: Ben Pfaff <b...@ovn.org> > > > To: Guru Shetty <g...@ovn.org> > > > Cc: ovs dev <dev@openvswitch.org> > > > Date: 03/14/2016 12:57 PM > > > Subject: Re: [ovs-dev] [RFC 0/8] OVN east-west loadbalancing. > > > Sent by: "dev" <dev-boun...@openvswitch.org> > > > > > > On Mon, Feb 29, 2016 at 08:32:13AM -0800, Guru Shetty wrote: > > > > On 28 February 2016 at 22:33, Gurucharan Shetty <g...@ovn.org> wrote: > > > > > > > > > This series adds support for OVN loadbalancing. This is very > > > > > lightly tested (with a very simple OVN topology of 1 router > > > > > and 2 lswitches), but the patches are far enough to get any > > > > > early feedback. > > > > > > > > > > The patches were tested on Linux kernel 4.4 with Jarno's > > > > > NAT patches (sent for review upstream) compiled in. > > > > > > > > > I forgot to mention that this series was built on top of > > > > commit ad99e2ed492607397e33ee (Better abstract OFPT_SET_CONFIG and > > > > OFPT_GET_CONFIG_REPLY, make stricter.) > > > > > > Thanks, knowing that turned out to be important! > > > _______________________________________________ > > > dev mailing list > > > dev@openvswitch.org > > > http://openvswitch.org/mailman/listinfo/dev > > > > I agree - this is on my list of patches to look at this week (along > > with Jarno's NAT patches) so ... knowing that I need another > > commit is good... > > > > Ryan (regXboi) > > I gave this patch series a test drive this morning, but I'm seeing a > failure on > the 3HVs, 1LS, 3 lports/HV end to end OVN test case. I *think* it's > coming from this rule: > > cookie=0x0, duration=1.488s, table=33, n_packets=0, n_bytes=0, > priority=100,reg7=0xffff,metadata=0x1 actions=set_field:0x1-> > reg5,set_field:0x3->reg7,resubmit(,34),set_field:0x2->reg5,set_field:0x2-> > reg7,resubmit(,34),set_field:0x3->reg5,set_field:0x1->reg7,resubmit > (,34),set_field:0xffff->reg7 > > but I'll admit that I'm still digging into things...
This is a logical switch broadcast flow, if I'm reading it correctly. This might be related to a bug that was reported earlier for a broadcast to several conntracked ports. At our weekly meeting here at VMware on Monday, that came up for a brief discussion, where we found ourselves wondering whether it makes any sense to try to conntrack broadcast/multicast packets. If we resolve that, perhaps it will fix this problem too. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
