From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id AFA9D2C55 for ; Wed, 17 May 2017 18:59:45 +0200 (CEST) Received: by mail-wm0-f54.google.com with SMTP id 70so17418822wmq.1 for ; Wed, 17 May 2017 09:59:45 -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=zD+ar1w2qg75DBcsdY1EkPwOBfRhqE5u/0vUjJ4RT7Y=; b=KGgkHswdjfG7G6q4mgK/lcLIkUcNSpM43zkwVgdVZ4f/EmHBdIxuoEFyR3M4uJ3lpa pXnPQ8YSFyItd62R3c7JbJSjizHFY9LNgqSZdW/xWDk4rAJXZ52yrXX76VQOwJsg+pTf tFDtFSTQ/wyC8iZZ5icaxFdsv+E3y7uBBEztrzURuVCVEXb8EMcfJgZRxSGxkDP3smTr 1iVa5Ro0CCl2ohhyyNIjcw0cXd7LxdHX8T4unaNFIWPwRHGcS6f4gaC1T436pZwQoGhT nUXQ03cEwAjRWhLGQ9mHwBWOu73RxlDEitSOD2CPas27YazIUFBO7iu6iiU9F8oFJHrQ xqjA== 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=zD+ar1w2qg75DBcsdY1EkPwOBfRhqE5u/0vUjJ4RT7Y=; b=WKrC61DsvRO6F6OjbA4SOmnMe3hVMIv9Zejc9Jiv6wLsxJpe4XNiYmuz5YnZvG5dvb nU+E0cwG4puFMp5w87qpf+tCAEDXYmhXTe+O016bALZh/lVqqLz41suyM4UdHRHV5mLo SPx0gDsmmlqt10UxJVWEoSZl11E1Y8SU3G0BP69QS0tPq5OjmZDGSHwOFTkThGDNeqll qHpOLHk2Psv0LcJ3bIX9Vfjb5sqigHvgQ+2shKuz8oBlePISjTHPWbTdYD6mnXNbBTNZ iTNQVi8FBoXclSigxakl/VmudN7QCUH+d3dNRuTinXQEq1O4Uy333MQLPzkkhozPVpKO ZO2g== X-Gm-Message-State: AODbwcCrg/b+Y/jqMUeONFkCiJtORntZmvyg/J/e6SeLzjv46PtSFBjO uOUVePmXz96zseqU X-Received: by 10.28.197.11 with SMTP id v11mr12765967wmf.84.1495040384700; Wed, 17 May 2017 09:59:44 -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 92sm2251316wra.0.2017.05.17.09.59.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 09:59:43 -0700 (PDT) Date: Wed, 17 May 2017 18:59:37 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Ferruh Yigit Cc: Thomas Monjalon , dev@dpdk.org, Adrien Mazarguil , Neil Horman , Bruce Richardson , Stephen Hemminger Message-ID: <20170517165937.GR14914@bidouze.vm.6wind.com> References: <3248422.BZSJxlJxmA@xps13> <09a808a2-2398-fc10-057c-b3595572e910@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <09a808a2-2398-fc10-057c-b3595572e910@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v2 00/13] introduce fail-safe PMD 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: Wed, 17 May 2017 16:59:45 -0000 On Wed, May 17, 2017 at 01:50:40PM +0100, Ferruh Yigit wrote: >On 3/20/2017 3:00 PM, Thomas Monjalon wrote: >> There have been some discussions on this new PMD and it will be >> discussed today in the techboard meeting. >> >> I would like to expose my view and summarize the solutions I have heard. >> First it is important to remind that everyone agrees on the need for >> this feature, i.e. masking the hotplug events by maintaining an ethdev >> object even without real underlying device. >> >> 1/ >> The proposal from Gaetan is to add a failsafe driver with 2 features: >> * masking underlying device >> * limited and small failover code to switch from a device >> to another one, with the same centralized configuration >> The latter feature makes think to the bonding driver, but it could be >> kept limited without any intent of implementing real bonding features. >> >> 2/ >> If we really want to merge failsafe and bonding features, we could >> create a new bonding driver with centralized configuration. >> The legacy bonding driver let each slave to be configured separately. >> It is a different model and we should not mix them. >> If one is better, it could be deprecated later. >> >> 3/ >> It can be tried to implement the failsafe feature into the bonding >> driver, as Neil suggests. >> However, I am not sure it would work very well or would be easy to use. >> >> 4/ >> We can implement only the failsafe feature as a PMD and use it to wrap >> the slaves of the bonding driver. >> So the order of link would be >> bonding -> failsafe -> real device >> In this model, failsafe can have only one slave and do not implement >> the fail-over feature. >> > >Tech board decided [1] to "reconsider" the PMD for this release (17.08). >So, lets start it J > >I think it is good idea to continue on top of above summary, is there a >plan to how to proceed? > The fail-safe proposal has not evolved from the techboard point of view. The salient point is still choosing between those 4 possible integrations. To give a quick overview of its current state: I have started working on a v3 to be integrated to v17.08. The work however was exceedingly complicated due to deep-rooted dependencies in the PCI implementation within the EAL, which has evolved in v17.05 and will evolve during this release. The current rte_bus rework from Jan Blunck and myself will greatly simplify the sub-EAL layer that was used in the fail-safe. I am thus waiting on Jan Blunck series on attach / detach, to propose mine in turn for rte_devargs, move the PCI bus where it belongs and, finally, rebase the fail-safe upon it. The form this work is taking however is still the same as previously, thus currently aiming at solutions 1 or 2. >Thanks, >ferruh > >[1] >http://dpdk.org/ml/archives/dev/2017-March/061009.html -- Gaëtan Rivet 6WIND