On Thu, 1 Jun 2017 16:12:41 +0200 Gaëtan Rivet <gaetan.ri...@6wind.com> wrote:
> On Wed, May 31, 2017 at 08:15:26AM -0700, Stephen Hemminger wrote: > > On Mon, 29 May 2017 15:42:17 +0200 > > Gaetan Rivet <gaetan.ri...@6wind.com> wrote: > > > > > Periodically check for the existence of a device. > > > If a device has not been initialized and exists on the system, then it > > > is probed and configured. > > > > > > The configuration process strives to synchronize the states between the > > > plugged-in sub-device and the fail-safe device. > > > > There are existing event models (udev and netlink) that could be used to > > do plug-in support without polling. Polling relies on application doing > > rte_alarms and many don't. > > Indeed. This possibility arose during development. > > The main issue with it however is that it introduces an asynchronous > design, which the DPDK and PMDs underneath are not well-suited to > interact with. It goes against the grain in a way. > > The polling is simple. It can work with all models of device and is > independent of event models specific to any architecture. > > It also allows to simplify the contexts in which probing and > removal are done. Currently there is only one, the interrupt thread. > This solves a few possible race conditions without having to resort to > critical sections. > > The only dependency is on another DPDK subsystem, rte_alarm. > I used alarms here because rte_timers need regular rte_timer_manage() > calls and there is little way to guarantee the frequency of the calls. > > rte_alarms do not force any externalities on applications, thus allowing a > seamless use of the fail-safe. > The issue with rte_alarm and also with LSC interrupt callbacks is that they don't run on a normal DPDK EAL application thread. These callbacks run on a DPDK internal pthread. I remember having to do some application hacks like having the callback generate an internal event on a pipe.
