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

Andy Zhou azhou at nicira.com
Tue Sep 8 19:42:26 UTC 2015


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 only in 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?



More information about the dev mailing list