There's nothing unusual there. Hmm. If you're willing to try some experiments, maybe we can learn more.
First, try commenting out the call to "bond_wait(br)" in bridge_wait() in vswitchd/bridge.c. Does that have any effect? If that has no effect, then try commenting out the call to poll_timer_wait_until(iface_stats_timer) in the same function and see if it makes a difference. Thanks, Ben. On Wed, Aug 25, 2010 at 06:37:09PM -0300, Luiz Henrique Ozaki wrote: > # ovs-appctl bond/show bond0 > updelay: 200 ms > downdelay: 0 ms > next rebalance: 8481 ms > slave eth3: enabled > active slave > hash 218: 5 kB load > 00:23:7d:e8:2a:00 > slave eth2: enabled > # ovs-appctl bond/show bond1 > updelay: 200 ms > downdelay: 0 ms > next rebalance: 9737 ms > slave eth4: enabled > active slave > slave eth5: enabled > # ovs-appctl bond/show bond2 > updelay: 200 ms > downdelay: 0 ms > next rebalance: 8585 ms > slave eth7: enabled > active slave > slave eth6: enabled > > > I saw in the openvswitch init script that there's a verification for > Xenserver 5.5, I changed for 5.6 to load the /proc/net just to check if this > was the issue but cpu process is still high, with or without > /proc/net/bonding > > Changed for the original init again. > > > On Wed, Aug 25, 2010 at 6:04 PM, Ben Pfaff <b...@nicira.com> wrote: > > > On Wed, Aug 25, 2010 at 05:59:35PM -0300, Luiz Henrique Ozaki wrote: > > > May 16 21:56:39|14629|poll_loop|DBG|0-ms timeout: 0x805bac1(bridge_wait) > > > 0x8063da9(main) 0xb7470e9c > > > > Thanks. It's definitely part of the bridge code then. What does > > "ovs-appctl bond/show <bondname>", with <bondname> replaced by the name > > of the bonded port, print out? > > > > > > -- > []'s > Luiz Henrique Ozaki _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
