From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet Subject: Re: [PATCH 00/12] introduce fail-safe PMD Date: Mon, 6 Mar 2017 14:53:17 +0100 Message-ID: <20170306135317.GA908@bidouze.vm.6wind.com> References: <20170303161420.GA217096@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dev@dpdk.org, Thomas Monjalon , Adrien Mazarguil , Jingjing Wu To: Bruce Richardson Return-path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id F02682C35 for ; Mon, 6 Mar 2017 14:53:30 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id n11so65018529wma.0 for ; Mon, 06 Mar 2017 05:53:30 -0800 (PST) Content-Disposition: inline In-Reply-To: <20170303161420.GA217096@bricha3-MOBL3.ger.corp.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 Fri, Mar 03, 2017 at 04:14:20PM +0000, Bruce Richardson wrote: >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, > Hi Bruce, >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. > Yes there appears to be a certain amount of overlap between these two PMDs from the above description. Actually we've considered modifying bonding at first but found it to be fundamentally incompatible: - By design, with bonding, applications are aware of slave PMDs and can use them directly (even if they shouldn't, depending on the aggregation mode). If they were supported, hot-plug events would have to be managed by the application as well. - With fail-safe, slaves are provided as PMD parameters and are fully owned by the parent instance, which takes care of their entire initialization and provides transparent support for hot-plug events. Their purposes also differ: - Bonding implements various modes of operation for link aggregation (round robin, active backup, LACP...) in the same fashion as the Linux bond driver. - Fail-safe handles hot-plug events so applications do not have to. To answer your second question, both are stackable: the fail-safe design aims at being the most transparent possible, meaning that it should make no difference to applications using it, whether within a bond or not. >Alternatively, should this be merged into the bonding driver or replace >it? > Applications (or users) that need their combined functionality benefit from greater flexibility this way, so I think having them both in the tree makes sense. >Regards, >/Bruce Regards -- Gaëtan Rivet 6WIND