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... _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
