Ah, so on 2.0 I think that instant_stats_run() would go through and transact the latest status for the modules every 100ms or so, regardless of whether anything changed.
On 28 March 2014 12:29, Howard Tsai <[email protected]> wrote: > Thanks for your feedback. My work is currently based on 2.0.0 so I didn't > see the work on connectivity_seq. I will reconsider the design. > > > On Thu, Mar 27, 2014 at 4:22 PM, Joe Stringer <[email protected]> wrote: > >> For what it's worth, there's at least some LACP/STP state that is >> propagated to OVSDB, which is done through the connectivity_seq mechanism. >> Status changes cause this seq to be updated, then instant_stats_run() >> fetches the status for various modules and transacts them. >> >> >> On 28 March 2014 11:32, Howard Tsai <[email protected]> wrote: >> >>> Our application doesn't need to expose MVRP state to a controller. >>> However, my concern of storing MVRP state in OVSDB is that, at least >>> theoretically, VLAN topology changes can happen frequently (as well as >>> changes in other MRP participant state, i.e., MMRP, MSRP, once these >>> MRP-family protocols are implemented.) As ovs-vswitchd is currently >>> implemented, if I understand it correctly, a change in OVSDB will trigger >>> reconfiguration of every Open Flow port, which is quite expensive. MVRP >>> state don't need to persist across switch restart. Moreover, LACP/STP state >>> are not in OVSDB, either. In this case, is storing MVRP state in OVSDB >>> still a good choice? >>> >>> Thanks, >>> Howard >>> >>> >>> On Thu, Mar 27, 2014 at 2:36 PM, Ben Pfaff <[email protected]> wrote: >>> >>>> On Thu, Mar 27, 2014 at 10:41:40AM -0700, Howard Tsai wrote: >>>> > One thing I am curious about is the exposure of current VLAN topology >>>> from >>>> > ovs-vswitchd. >>>> > >>>> > Currently, ofbundle registers a set of callback functions with MVRP. >>>> MVRP >>>> > calls these functions to adjust VLAN membership. I.e., OVSDB doesn't >>>> have >>>> > the current VLAN topology declared by MVRP. To compensate, I >>>> implemented a >>>> > unixctl cmd "mvrp/show" to show MVRP state. >>>> > >>>> > My questions are: >>>> > 1. Is this the preferred way to expose protocol state? Any >>>> > suggestion/pseudo standard on output formatting? >>>> >>>> Is the VLAN topology something that a controller would likely be >>>> interested in? If so, then I think that exposing it in OVSDB, perhaps >>>> as a column in the Port or Interface table, would be appropriate. (I >>>> don't know much about MVRP, so I don't know what is correct >>>> conceptually.) >>>> >>>> If the VLAN topology goes in the database we probably don't need it via >>>> unixctl. >>>> >>>> > 2. It seems that OF-Config should be extended to include MVRP as one >>>> of >>>> > OpenFlow Port Feature and VLAN configuration in OpenFlow Port State. >>>> Any >>>> > thought on that? >>>> >>>> Do you mean OF-Config or OVSDB? Open vSwitch doesn't include an >>>> OF-Config implementation. I think we already covered OVSDB, above. >>>> >>> >>> >>> _______________________________________________ >>> discuss mailing list >>> [email protected] >>> http://openvswitch.org/mailman/listinfo/discuss >>> >>> >> >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
