From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 0D5B07CDA for ; Mon, 5 Jun 2017 01:09:25 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id 7so60808343wmo.1 for ; Sun, 04 Jun 2017 16:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=OMZ0dGRZRGX/ZFT4shQTKQZM2zQU04tivHFWNxjlsRc=; b=nabzPYLvQ/84a0NxixpqHr0LZOBtxQkd3vmJ+qsBrQQmOqd3WBtRvvx6xXVYQAVxu3 pNYNyHsqzhrB/zVlLqPwPCfYdcf3sYgLuLymULPOy3V33DOkm6W3VuvgpMaoMsX0kiu6 DE+Ro+JnfR7QQiVTGOadqE33IiujJViLZrq1z5+8Ai49hej1k/or7Lf2FMp5jnotoBer nvydn0HcavZblIIODuIlMT+uR/Shisu9+7bSUiINryCeCSyDB2w2oeFQAffhayOblxAz WDbY0TZC0/QLoyE5yCGBBJU8XydDGLbpPVtCPDcDG2kbPcMAXvitfYsSfoeeYtu4S06m yorg== 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:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=OMZ0dGRZRGX/ZFT4shQTKQZM2zQU04tivHFWNxjlsRc=; b=qH2cRj+GkBsbAqI24u3DVxxb/bP903P1b40RGPOx6JlX9jlN/5T7qrsKQKOPXMlAW8 3mLoDfwF9ThkP7RAgyYVR6vy8zPouhuS/Jj/1BQ1K2Ny4NYscJPvD1/mHorpi33rAzKH PxK/8CWcmS6hvJcowiGw1ccrrAwKaxGwPpMHmXeplmt13X4C7h9HtH8KWVe1bjPk6cW/ s5d605eROhNpzlWVBurUr/03dV1ipgLZVLYdOfe0nRANhsYcO60dJUMtR6J2Jb17YYdE ihFCDYB3IcbCMHWaB2uPJ37gePHXojVD1yGkgIidjap8CZSlh8O9TSJeXctFWA8ms3CY XiiA== X-Gm-Message-State: AODbwcBAzxfA2At+wK6WzqPW61GiVS+1fy0lnsfaT0xxYy+MgCcZbqFu jcAvynj+2ozi9gpC X-Received: by 10.28.63.9 with SMTP id m9mr6230436wma.87.1496617765637; Sun, 04 Jun 2017 16:09:25 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id x37sm51884492wrb.42.2017.06.04.16.09.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jun 2017 16:09:24 -0700 (PDT) Date: Mon, 5 Jun 2017 01:09:19 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Stephen Hemminger Cc: dev@dpdk.org Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170601110010.79a147c2@xeon-e3> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Sun, 04 Jun 2017 23:09:26 -0000 On Thu, Jun 01, 2017 at 11:00:10AM -0700, Stephen Hemminger wrote: > On Thu, 1 Jun 2017 16:12:41 +0200 > Gaëtan Rivet 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 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. > 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. 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. -- Gaëtan Rivet 6WIND