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

[Aaron Conole]

"Bodireddy, Bhanuprakash" <bhanuprakash.bodireddy at intel.com> writes:

> Hi Darrel, Aaron

Hi Bhanu,

>>There two ways to go with the design.
>>
>>1) Make it generic, so that it is not so PMD specific, as it is now.
>>2) If it stays PMD specific, make it stronger; right now, the health check is
>>limited – it detects that a PMD thread is proceeding or not.
>>For something like DPDK, I don’t think that will be enough in the long run.
>>This can result in some false negatives, as well.
>>              Maybe, we want to know that the ports and queues are getting
>>processed, PMD/port/queue mappings as expected, time spent processing
>>packets per PMD, port state changes, packet stats, queue depths, etc This
>>information could be correlated by the final receiver of the data.
>>
>>I also agree that socket communication is preferred over shm, although I don’t
>>think any shm usage will necessarily lead to a meltdown.
>
> I have posted a new version of Keepalive patch series here:
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/333546.html
> I posted the new version as RFC instead of v3 for below reason:
>   1) I have considered using OVSDB for storing the Keepalive status,
> want to know what you think about this.

I like it much more than SHM.  It means we can monitor the database for
changes, and query for this information from the DB.  I was considering
that you might use messages, but perhaps this way ends up being more
extensible.

>   2) 6-7 of the unit tests were failing due to OVSDB changes. I am
> looking in to those issues.
>   3) Apart of heartbeats(that were enabled earlier), I have
> implemented few more APIs to do the additional health checks as
> suggested in this thread(port status/ packet stats/pmd cycles
> etc). The first version of APIs are posted in the series and currently
> working on hardening them for all corner cases.

Cool.  I look forward to it.

>   4) Note that SHM is still used here but only for intra process
> communication(b/n vswitchd and Keepalive thread). Monitoring
> framework(collectd) would only read from OVSDB.

Probably the next spin should drop it.  From both a security and code
perspective, it's a lot of work to maintain.  Since it's two threads,
they will implicitly share memory - no need to worry about permissions,
files and external attackers removing the /dev/shm/ files.

> I tried making the APIs generic, but however it is implemented for
> DPDK datapath at this point.

No problems, I'll have a look.

> Regards,
> Bhanuprakash.

Thanks!