From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 4BC292B94 for ; Fri, 3 Mar 2017 17:14:30 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2017 08:14:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,237,1484035200"; d="scan'208";a="1137519887" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by fmsmga002.fm.intel.com with SMTP; 03 Mar 2017 08:14:21 -0800 Received: by (sSMTP sendmail emulation); Fri, 03 Mar 2017 16:14:20 +0000 Date: Fri, 3 Mar 2017 16:14:20 +0000 From: Bruce Richardson To: Gaetan Rivet Cc: dev@dpdk.org, Thomas Monjalon , Adrien Mazarguil , Jingjing Wu Message-ID: <20170303161420.GA217096@bricha3-MOBL3.ger.corp.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.0 (2017-02-23) Subject: Re: [dpdk-dev] [PATCH 00/12] 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: Fri, 03 Mar 2017 16:14:31 -0000 On Fri, Mar 03, 2017 at 04:40:22PM +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. > > Each fail-safe instance is configured to run atop one or several > devices, with one defined as the preferred device. Hot-plug events are > handled on all of them, and Tx is always directed to the preferred device > if present or to the next available failover device (Rx is always performed > on all devices for simplicity). > > Moreover, the configured slaves (preferred or failover) do not need to be > present at initialization time and may appear later. > > Slaves configuration is continuously synchronized with that of the virtual > device, which exposes their common set of capabilities to the application. > Failure to apply the current configuration state to a slave for any reason > simply reschedules its initialization. > > This series depends on the series > [PATCH 0/4] clarify eth_dev state management > [PATCH 0/5] add device removal event > Hi, this looks an interesting PMD, and I like the wrapper approach. However, why duplicate the functionality of the bonding device in another device driver? Is it not possible to have this driver wrap individual devices and then have the bonding driver use those wrapped devices to present an omni-present device? It seems strange to have support for grouping devices together in two different drivers - one should leverage the other. Alternatively, should this be merged into the bonding driver or replace it? Regards, /Bruce