From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet Subject: Re: [PATCH v2 00/13] introduce fail-safe PMD Date: Wed, 17 May 2017 18:59:37 +0200 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-Transfer-Encoding: 8bit Cc: Thomas Monjalon , dev@dpdk.org, Adrien Mazarguil , Neil Horman , Bruce Richardson , Stephen Hemminger To: Ferruh Yigit 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) Content-Disposition: inline In-Reply-To: <09a808a2-2398-fc10-057c-b3595572e910@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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