From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [PATCH v2 00/13] introduce fail-safe PMD Date: Wed, 8 Mar 2017 11:54:02 -0500 Message-ID: <20170308165402.GA20936@neilslaptop.think-freely.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org, Thomas Monjalon , Adrien Mazarguil To: Gaetan Rivet Return-path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 000E4108A for ; Wed, 8 Mar 2017 17:54:15 +0100 (CET) Content-Disposition: inline In-Reply-To: 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, Mar 08, 2017 at 04:15:33PM +0100, Gaetan Rivet wrote: > This PMD intercepts and manages Ethernet device removal events issued by > slave PMDs and re-initializes them transparently when brought back so that > existing applications do not need to be modified to benefit from true > hot-plugging support. > > The stacked PMD approach shares many similarities with the bonding PMD but > with a different purpose. While bonding provides the ability to group > several links into a single logical device for enhanced throughput and > supports fail-over at link level, this one manages the sudden disappearance > of the underlying device; it guarantees applications face a valid device in > working order at all times. > Why not just add this feature to the bonding pmd then? A bond is perfectly capable of handling the trivial case of a single underlying device, and adding an option to make the underly slave 'persistent' seem both much simpler in terms of implementation and code size, than adding an entire new pmd, along with its supporting code. Neil