> > I don't see how the proposed feature is better than what we already have. It > saves a little memory temporarily, but memory isn't > usually a big deal in typical OVS environments. Is there some other > advantage?
A couple of points that come into my mind: 1. OpenFlow bundle depends on OF 1.4. Not many controllers support OF 1.4 and its bundle mechanism yet. Our proposal has no such dependency. 2. The OVS bundle implementation does not cover groups and meters (yet). Our proposal covers all flow state. 3. Memory to store millions of bundled OFP messages may well be significant even on typical compute nodes running OVS. 4. How quickly can OVS install a million of bundled flow_mod messages after commit? It appears that the main ofproto_mutex is locked all the time. In our proposal all fresh flow state is installed immediately at reception. The cleanup of stale flow state after a resync_fisnih command can be handled by a background walker thread. No locking required. 5. During transmission of a "resync bundle" (delete all, download all state) a controller would have to either buffer new flow/group/meter mods or insert them into the bundle. Both requires additional controller logic. In our proposal insertion/modification/removal of flows/groups/meters can happen asynchronously and almost fully uncoordinated with the resync download, allowing a cleaner decoupling in the controller between applications generating flow state and the generic switch handler function (e.g. FRM in ODL). _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
