On Mon, Sep 7, 2015 at 1:39 AM, Liran Schour <lir...@il.ibm.com> wrote: > 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 v2 proposal will also leave the monitor request intact.
> 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). How would row delete be encoded? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
