[ovs-dev] OVN: RFC add a new JSON-RPC selective monitoring method

[Liran Schour]

Andy Zhou <azhou at nicira.com> wrote on 03/09/2015 10:52:42 PM:

> On Thu, Sep 3, 2015 at 5:27 AM, Liran Schour <LIRANS at il.ibm.com> wrote:
> > Andy Zhou <azhou at nicira.com> wrote on 01/09/2015 11:15:56 PM:
> >
> >> From: Andy Zhou <azhou at nicira.com>
> >> To: Liran Schour/Haifa/IBM at IBMIL
> >> Cc: Ben Pfaff <blp at nicira.com>, dev <dev at 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.