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

[Liran Schour]

Andy Zhou <azhou at nicira.com> wrote on 09/09/2015 08:08:36 PM:

> On Wed, Sep 9, 2015 at 3:24 AM, Liran Schour <LIRANS at il.ibm.com> wrote:
> > Andy Zhou <azhou at nicira.com> wrote on 08/09/2015 10:42:26 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: 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 <LIRANS at il.ibm.com> 
wrote:
> >> > 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 
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.