[dpdk-dev] [PATCH v4 05/12] net/failsafe: add plug-in support

Stephen Hemminger stephen at networkplumber.org
Thu Jun 1 20:00:10 CEST 2017


On Thu, 1 Jun 2017 16:12:41 +0200
Gaëtan Rivet <gaetan.rivet at 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.rivet at 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.



More information about the dev mailing list