From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=IUO9dFHzcmsbjLd5tyXimfoxNhPXbWsWk+IWBdJBG9M=; b=j+TQH4jc++7sB2XOznhpcZxCsBIwvnUMryGTqxnkMvDHYCvZFAPCLCE0dNJnvk03jL xKTqAPzYKpzxzBBl0YxTbGbZcMXOGmWCVzi9FU5tUa2DlflKPJpNzyowqFWunUcS3hmI luw3JDjCZ0VFNy9CiPnOZnIaMr1eMqgD5cX1L3j4EKSSAVlprHjY6x/iDj7TGf6CjBKn md+xPN3kw8aGn+w4a3YTL/0cF7ycwEa875u44MNcjggtoZH3gLpfWrUHyz4QBiAtvlfg t+rtPCngzRapzst7QXAFfcxqnngjM7qnh8awg+aJ7wJ7LXO5Bp+EZOIRGVcd+gbQLzUt X+eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=IUO9dFHzcmsbjLd5tyXimfoxNhPXbWsWk+IWBdJBG9M=; b=pdK0lWWkWMTcPoI3W+Gxh00vGaIM6OStCYjVp7NX/+knLjVab26TJi5WVsseXXrO2z SnLZJUprBfv92jqCM+OIi0IWiIZdm2A9O0yCaalYc5qtHimM1Xn7wAGGy9lhBEyRXq4Y Zq0oww3vHb4vI4Cf49tP4jM4+spjQd+RotqeEtnyDFD4FVCyyE1NYkUDCsEj6lhrLYna y0xEjB9hwT46u8NlYF8JK/mRvvMeblBbyBismMOPSu9rP0MKnH9m5lNYyvF7hXE/ay5q 1gCBXnM2avCAH12dkq6SKLMUPD5FfhGC4g86Dq45mJdSMrGu5usISnImV+XQnimHJdMD pthg== X-Gm-Message-State: AMke39luGqYS4lh36S+sqYt7Vg2d/Itlxq5RQ7TDXDMxdP0lzOS9o8fSSSvCV1ZY7TvP7Zll X-Received: by 10.28.24.5 with SMTP id 5mr13083056wmy.1.1488808410422; Mon, 06 Mar 2017 05:53:30 -0800 (PST) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id q4sm10916824wme.17.2017.03.06.05.53.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 05:53:29 -0800 (PST) Date: Mon, 6 Mar 2017 14:53:17 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Bruce Richardson Cc: dev@dpdk.org, Thomas Monjalon , Adrien Mazarguil , Jingjing Wu 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170303161420.GA217096@bricha3-MOBL3.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Mon, 06 Mar 2017 13:53:31 -0000 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