Andy Zhou <az...@nicira.com> wrote on 09/09/2015 08:08:36 PM: > 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. >
An existing row with a map that at least on of it's member was added, modified or deleted will cause the entire row to be treated as modified. Therefore an Update Notification will be sent according to the "modify" or "modified" bit. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
