From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 8424B6841 for ; Thu, 1 Jun 2017 16:12:48 +0200 (CEST) Received: by mail-wm0-f45.google.com with SMTP id d127so62086450wmf.0 for ; Thu, 01 Jun 2017 07:12:48 -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=JrSOkW9gtS1kWDDlqe1eu6iIDSNybU0GcMoTbs9XRlc=; b=aWBksRt/Xh0QvacyotuyDoItSigC43BSPU0gGUn3gwAuk6EpQbca52Zgc5v1X7gYsM nCijA8qMkIkgSI+kqoC4viHfvzBYp+EB5c7FhP5zrefT5FRxLNzTBjOV+n//gnrZi7FZ sRhNlNPL+CvLoPp7x//EbEdoj8voKoH7+6fHGI9MjWV4jQUF2rGUnINt/qa2wowehwSO T/8qs9RdmfGCwu5j9dLyIBbAn5xjUfXF6Xv7yeFdJzXn/hEydJLR/SIbC0DZQkUa+7yU sXmF3Wt3PT1Vf3Xht9H+aEsTnGKtrteMnGjJKgF8a4NpdgmslaubjE5d4v6NT0kgccqK /9Vg== 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=JrSOkW9gtS1kWDDlqe1eu6iIDSNybU0GcMoTbs9XRlc=; b=FBrPd/Hj+neYvxp19xBewxxu5WuTRs9jiJbbZNmWk8vgG9z9ocvafLrM3gwD9Y+C6T MRD/57gEy8Xyggqal2pjKet1pb/Zo8KID3l2KlNCMj8sJj5sFv5X0UsUDoft/HZ9VowM hxmPv4vrBMTLGPjrt/GovUg4Xi+oVGOcAhi45jLuWR4gfsilu5IZ26w3S0NXwQuNfUBC Tip3R7tAkkqVSYeGXfS8IXEjs7m58VkcoeYtY/rAB64qS+bU5OmjlFIFZxI4nCLI/S/G PNpt+5BcjPZK2BYSnR9V7M86ripopkN1+BvdL9lRQrskUNWRNtGYNCpyZR5tGtT/fMGp kdww== X-Gm-Message-State: AODbwcBIkKRoLC+HX/ijAOARgaIYS+DYiiQg3WjKleogiSZO0wklpTzJ DmGUeoMqfWeYWDtuNiY= X-Received: by 10.223.176.25 with SMTP id f25mr1473076wra.74.1496326367792; Thu, 01 Jun 2017 07:12:47 -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 b78sm18621633wmf.23.2017.06.01.07.12.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 07:12:47 -0700 (PDT) Date: Thu, 1 Jun 2017 16:12:41 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Stephen Hemminger Cc: dev@dpdk.org Message-ID: <20170601141241.GC18840@bidouze.vm.6wind.com> References: <6b96432155ffd2d5fc6f6011a0b229c2224116f8.1496065002.git.gaetan.rivet@6wind.com> <20170531081526.3e8de246@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170531081526.3e8de246@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: Thu, 01 Jun 2017 14:12:48 -0000 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. -- Gaëtan Rivet 6WIND