On Wed, Sep 9, 2015 at 3:24 AM, Liran Schour <lir...@il.ibm.com> wrote: > Andy Zhou <az...@nicira.com> wrote on 08/09/2015 10:42:26 PM: > >> From: Andy Zhou <az...@nicira.com> >> To: Liran Schour/Haifa/IBM@IBMIL >> Cc: Ben Pfaff <b...@nicira.com>, dev <dev@openvswitch.org> >> Date: 08/09/2015 10:42 PM >> Subject: Re: [ovs-dev] OVN: RFC add a new JSON-RPC selective monitoring >> method >> >> 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 onlyin >> > 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? >> > > In the proposal that I submitted (V2) row delete remains under the same > behavior as before. Only modified rows can be treated under the new > "modified" semantics.
That can be improved. Also for columns that stores maps, we also add, modify or delete at member level. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
