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