[ovs-dev] [PATCH v2 0/6] Add OVS DPDK keep-alive functionality

[Ben Pfaff]

On Mon, May 01, 2017 at 10:55:55PM +0000, Bodireddy, Bhanuprakash wrote:
> >> > This patch is aimed at achieving Fastpath Service Assurance in
> >> > OVS-DPDK deployments. This commit adds support for monitoring the
> >> > packet processing cores(pmd thread cores) by dispatching heartbeats
> >> > at regular intervals. Incase of heartbeat miss the failure shall be
> >> > detected & reported to higher level fault management
> >systems/frameworks.
> >> >
> >> > The implementation uses POSIX shared memory object for storing the
> >> > events that will be read by monitoring framework. keep-alive feature
> >> > can be enabled through below OVSDB settings.
> >>
> >> I've been thinking about this design, and I'm concerned - shared
> >> memory is inflexible, and allows multiple actors to mess with the
> >information.
> >> Is there a reason to use shared memory?  I am not sure of what
> >> advantage this form of reporting has vs. simply using a message
> >> passing interface.  With messages there is clear abstraction, and the
> >> projects / processes are truly separated.  Shared memory is leads to a
> >> situation of inextricably coupling two (or more) processes.
> >
> >Shared memory is great within a process, but it has drawbacks as an inter-
> >process interface.  Bhanu, is there a reason that we need the same interface
> >intra- and inter-process?  For example, OVS could have a dedicated thread
> >that monitors the shared memory interface and, on failure, reports the
> >problem over a Unix domain socket.
> 
> Ben,
> In the original KA design shared memory interface was meant for inter-process.  With OvS-DPDK, Keepalive thread is spawned that wakes up periodically to update the PMD core status in SHM. This SHM interface will be monitored by collectd and in case of event it notifies to OpenStack service ceilometer.
> 
> I like what you suggested,  wherein we can still have the SHM interface and additionally spawn a dedicated monitoring thread to monitor SHM interface and notify the status(in case of events) to external monitoring frameworks(collectd) over Unix domain sockets. 
> 
> As the consensus is to use Unix domain sockets, I would pass on the feedback to collectd team for appropriate changes on their side.

OK.  If what I said made sense, please go ahead; if I don't understand
well enough, ignore me...