Andy Zhou <az...@nicira.com> wrote on 03/09/2015 10:52:42 PM: > On Thu, Sep 3, 2015 at 5:27 AM, Liran Schour <lir...@il.ibm.com> wrote: > > Andy Zhou <az...@nicira.com> wrote on 01/09/2015 11:15:56 PM: > > > >> From: Andy Zhou <az...@nicira.com> > >> To: Liran Schour/Haifa/IBM@IBMIL > >> Cc: Ben Pfaff <b...@nicira.com>, dev <dev@openvswitch.org> > >> Date: 01/09/2015 11:16 PM > >> Subject: Re: [ovs-dev] OVN: RFC add a new JSON-RPC selective monitoring > >> method > >> > >> > > >> >> Third, this may be a good opportunity to fix a design mistake in > >> >> "monitor", which is that it sends too much data when a row is modified: > >> >> it sends both the old and new values for columns that have changed, as > >> >> well as the value of every column that did not change. I thought that > >> >> would be useful when I originally designed it, but it's proven to just > >> >> waste CPU and memory and bandwidth. > >> >> > >> > > >> > I will include a new version of Update Notification that will describe > >> > this change. > >> > > >> I am working on patch series that implements this enhancement. My > >> current plan is to send the RFC changes along with the prototyping > >> code for review. I am currently making a small change to the original > >> monitor message to indicate whether it will accept the new Update > >> Notification format. With the proposal of <monitor-cond-request>, I > >> think it can be implied with the new message, and much cleaner. > >> > >> The details of the new Update Notification is more involved that I > >> would like to prototype before proposing. > >> > > > > I thought to define a new member called "modified" to monitor-select object > > to signify that update notification should include only modified columns > > with their new value only. Client should set to true only one of the members > > "modify", "modified". If both omitted default behavior is "modify" as it is > > now. (XOR) > > This is an interesting proposal. But I don't think we need the bit for > the new monitor message. > > The new 'modified' only update notification is likely to be > significantly different than current Update Notification, > I think it will make sense to add a new message type, say, Update > Notification2 (V2). > > Coming back to the modified bit proposal, I don't think we need this > extra bit. The monitor-select should accept > both current Update Notification and V2, assuming both changes are > made into the same OVS release. > > On the other hand, this bit may be useful to be added to the current > monitor message if we want to continue > using it after monitor-select being available for modified only > updates. I currently don't foresee such > use case. Do you? > > Make sense? >
The idea behind the "modified" bit proposal was to leave the current usage of the monitor request intact and iteratively change the code only in places that can make a significant benefit from the new "modified" behavior. The Update Notification method can remain as is with a minor change that defines the behavior under the new "modified" bit. (send only "new" <row> that includes only selected modified columns). I will send a new version of the spec. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
