From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <nhorman@tuxdriver.com>
Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])
 by dpdk.org (Postfix) with ESMTP id 000E4108A
 for <dev@dpdk.org>; Wed,  8 Mar 2017 17:54:15 +0100 (CET)
Received: from [66.78.254.93] (helo=localhost)
 by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63)
 (envelope-from <nhorman@tuxdriver.com>)
 id 1cleqo-0001tE-Co; Wed, 08 Mar 2017 11:54:12 -0500
Date: Wed, 8 Mar 2017 11:54:02 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Gaetan Rivet <gaetan.rivet@6wind.com>
Cc: dev@dpdk.org, Thomas Monjalon <thomas.monjalon@6wind.com>,
 Adrien Mazarguil <adrien.mazarguil@6wind.com>
Message-ID: <20170308165402.GA20936@neilslaptop.think-freely.org>
References: <cover.1488550982.git.gaetan.rivet@6wind.com>
 <cover.1488985489.git.gaetan.rivet@6wind.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cover.1488985489.git.gaetan.rivet@6wind.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Spam-Score: -2.9 (--)
X-Spam-Status: No
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Mar 2017 16:54:16 -0000

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