From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com
 [209.85.192.175]) by dpdk.org (Postfix) with ESMTP id 75D717CCE
 for <dev@dpdk.org>; Thu,  1 Jun 2017 20:00:19 +0200 (CEST)
Received: by mail-pf0-f175.google.com with SMTP id e193so33760634pfh.0
 for <dev@dpdk.org>; Thu, 01 Jun 2017 11:00:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20150623.gappssmtp.com; s=20150623;
 h=date:from:to:cc:subject:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=IcRTfRptbUCI8sV5/IGlEQjVHLxmff9Qf4VFVaWLm28=;
 b=ObXFrXaV4DIq89A5hfkEuJHpKoLZolSXVFI9itKY3g8KmX/tcHf7qlEg86k4qA5fiB
 dIr3krhNJfaX8lFzmkQSXD3bXI+L8Py7VhGjX0PnfUIePkvL1cICRpzs95uLb6EZgWPJ
 DJhz5WsHUx10n6zOkVCigOovvya3Knihwa09mNYeOIIDzmHVzCHByoEZkjaQdbP5h+S1
 h0EUwXhhTUoOX5ktZg0m4Axy8eV+61c7hjfbhqd2r4lXEKnxEIOmwxPXtXUHAQtq273d
 F7aEMfJewLgG0kK0HawHDMkJgSOUsRqu1NlU1keFzQD102mgQPa7o9Obdi5am65VVS8D
 uRRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=IcRTfRptbUCI8sV5/IGlEQjVHLxmff9Qf4VFVaWLm28=;
 b=VbIZ0b7Jj9FGz5Ej0jzRr8kGjdyZJsPqRUFjVJ3VoZWL9wRLV9g00AieChMM14i5ON
 8zlDZtFNhmoxHpvtgQWITelGUXSO21vUsv1zRN9lDqsgOhE1gPRTEquqbdyrIiwDSgtW
 BJgebQMMvBP4KrUG3qc3VXL6K7S+pOLWjzuwsm9+NGcywKlHAn05sH8KNYYs/wbRqI75
 EFeZJeU5rKHnKQOf9X9jPA0tKeb/SSzc07sc5xGb3PLbHP9rIeXztuxzMZYPl0BO3Zzh
 uLYxeFX3hc595yFUTo5YFMdAWA+jiuC1is54d0Vx71TZvK1IBcgtPK09xcPAN7K13UDe
 cSyw==
X-Gm-Message-State: AODbwcBYguOZGKBP5oP9zy+SaBJHKa+olNPLAO79lDlSDOEb16C5sFke
 mygnPxsRKfFOS1e3YyoA1w==
X-Received: by 10.98.65.26 with SMTP id o26mr2225599pfa.228.1496340017035;
 Thu, 01 Jun 2017 11:00:17 -0700 (PDT)
Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240])
 by smtp.gmail.com with ESMTPSA id e124sm30746523pgc.17.2017.06.01.11.00.16
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Thu, 01 Jun 2017 11:00:16 -0700 (PDT)
Date: Thu, 1 Jun 2017 11:00:10 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: =?UTF-8?B?R2HDq3Rhbg==?= Rivet <gaetan.rivet@6wind.com>
Cc: dev@dpdk.org
Message-ID: <20170601110010.79a147c2@xeon-e3>
In-Reply-To: <20170601141241.GC18840@bidouze.vm.6wind.com>
References: <cover.1495634974.git.gaetan.rivet@6wind.com>
 <cover.1496065002.git.gaetan.rivet@6wind.com>
 <6b96432155ffd2d5fc6f6011a0b229c2224116f8.1496065002.git.gaetan.rivet@6wind.com>
 <20170531081526.3e8de246@xeon-e3>
 <20170601141241.GC18840@bidouze.vm.6wind.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dpdk-dev] [PATCH v4 05/12] net/failsafe: add plug-in support
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jun 2017 18:00:19 -0000

On Thu, 1 Jun 2017 16:12:41 +0200
Ga=C3=ABtan Rivet <gaetan.rivet@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@6wind.com> wrote:
> >  =20
> > > 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.
> > >=20
> > > The configuration process strives to synchronize the states between t=
he
> > > plugged-in sub-device and the fail-safe device. =20
> >=20
> > 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. =20
>=20
> Indeed. This possibility arose during development.
>=20
> 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.
>=20
> The polling is simple. It can work with all models of device and is
> independent of event models specific to any architecture.
>=20
> 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.
>=20
> 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.
>=20
> rte_alarms do not force any externalities on applications, thus allowing a
> seamless use of the fail-safe.
>=20


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.