From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com [209.85.192.176]) by dpdk.org (Postfix) with ESMTP id 786CA7CB6 for ; Mon, 5 Jun 2017 17:25:31 +0200 (CEST) Received: by mail-pf0-f176.google.com with SMTP id 83so26901815pfr.0 for ; Mon, 05 Jun 2017 08:25:30 -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=+RqilwyL1EsasmOB31ieGaVjLPN4bTqx2Y5q0GmzUOg=; b=NCIEUnvIn6Yw3yaWiys6orGeF/QeIiiv7XHM944F6tXdfgFCGmFrOuRwULSRsG7uxG 6JL08kf4WF/eAdXfW95C3Xg0jZmA7Xi9WRktMzbdFRBz5tmx5xSwlrd7gJJmOpUI3zK9 i/Z8dhnBN7U8sfaamYYR4pZFymbrFu5cQwvR57H+njtifHhCojjPW4rmarV14nAqkabt JgswFCI4dSvSPPu7vgwlWXt5ii6NW7ZWmC7Lozl7AYCvXXauBio0sdRvB4g8V0aOh0Ot MFsZET/YZC0FoZmtvzyExqCMyaNnhlnqf5brZGjevuM3Qw/YEORcz4qnbdOLoaZsS9NX bs8A== 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=+RqilwyL1EsasmOB31ieGaVjLPN4bTqx2Y5q0GmzUOg=; b=h8d84WUdv+mtRQAnvazbM+y6ta3TyA6ZwpLMO5rCnRdVcFVhSCVoNKHAuKOsvJ9lwr fTVg/XsBCjcPFG0buMokjRp7W0GGnmGBn0fk6akn7F8HQJK1L4o9eUfwuKFlaRWKVLn+ DO6zx2vGZEYDzQ39kKjfxpOzif+/zm6ZX32Vq1Sdf31NCxtK8QGKzPTuV1tfDmkdsrq5 UeFYqk8pmz/J0kT7qx200JEHXjZWW5W5YKl05DbZstCmVVvbWwAK2+5QxlAL743ZxrME OpHaspouMNr9WuCphgRUYiVHsjIOmVePmcAMwZUXvQjajGHR1ikjLlE4wbHeQK9wEPYY 1lbQ== X-Gm-Message-State: AODbwcAn5Mr06G0GTfsliOTwInGHh8dxGE6Eqie5nlGEKY0Bp54nk5ta OA4okhOZklZFtLmy X-Received: by 10.99.111.194 with SMTP id k185mr21192219pgc.69.1496676330323; Mon, 05 Jun 2017 08:25:30 -0700 (PDT) Received: from xeon-e3 (76-14-207-240.or.wavecable.com. [76.14.207.240]) by smtp.gmail.com with ESMTPSA id s131sm10679581pgc.61.2017.06.05.08.25.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 05 Jun 2017 08:25:29 -0700 (PDT) Date: Mon, 5 Jun 2017 08:25:22 -0700 From: Stephen Hemminger To: =?UTF-8?B?R2HDq3Rhbg==?= Rivet Cc: dev@dpdk.org Message-ID: <20170605082522.64dadbdb@xeon-e3> In-Reply-To: <20170604230919.GH18840@bidouze.vm.6wind.com> References: <6b96432155ffd2d5fc6f6011a0b229c2224116f8.1496065002.git.gaetan.rivet@6wind.com> <20170531081526.3e8de246@xeon-e3> <20170601141241.GC18840@bidouze.vm.6wind.com> <20170601110010.79a147c2@xeon-e3> <20170604230919.GH18840@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 15:25:31 -0000 On Mon, 5 Jun 2017 01:09:19 +0200 Ga=C3=ABtan Rivet wrote: > On Thu, Jun 01, 2017 at 11:00:10AM -0700, Stephen Hemminger wrote: > > On Thu, 1 Jun 2017 16:12:41 +0200 > > Ga=C3=ABtan Rivet wrote: > > =20 > > > On Wed, May 31, 2017 at 08:15:26AM -0700, Stephen Hemminger wrote: =20 > > > > On Mon, 29 May 2017 15:42:17 +0200 > > > > Gaetan Rivet wrote: > > > > =20 > > > > > Periodically check for the existence of a device. > > > > > If a device has not been initialized and exists on the system, th= en it > > > > > is probed and configured. > > > > >=20 > > > > > The configuration process strives to synchronize the states betwe= en the > > > > > plugged-in sub-device and the fail-safe device. =20 > > > >=20 > > > > There are existing event models (udev and netlink) that could be us= ed to > > > > do plug-in support without polling. Polling relies on application d= oing > > > > 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 allow= ing a > > > seamless use of the fail-safe. > > > =20 > >=20 > >=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. > > =20 >=20 > On the other hand, not all applications would make use of those hacks, > and adding those would impose architecture elements on users. While > convenient, this goes somewhat against the tool-box ethos of DPDK. >=20 > In the end, I had to leverage the existing tools. Interrupts in DPDK are > a known weak point, but they are at least working and not too heavy > conceptually on applications (clean threading model, no need for signal > masks, etc). Better implementation might crop up at some point, if those > hurdles are too much and shared by many. >=20 The alarm solution is a good intermediate step. But eventually in the spirit of the DPDK there should be option to have an event driven model. Maybe the= event library will help. For me the litmus test is can the known open source heavy weight DPDK appli= cations like VPP work?