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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
