From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) by dpdk.org (Postfix) with ESMTP id 30479235 for ; Fri, 7 Jul 2017 12:08:32 +0200 (CEST) Received: by mail-wr0-f175.google.com with SMTP id c11so39874400wrc.3 for ; Fri, 07 Jul 2017 03:08:32 -0700 (PDT) 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=oq2EGOEtM3194bdAjb+39RP3WhTcW1FizMFhFpicZT8=; b=MXVLxDtehUHvsOO9WpW7jzPVYkVTIZksmGXAdrHoJLAd7C75p2PF/3KxsbmDIzuNQ2 N11WCcLZhKjpGP/6PaUXwP6bM9DaY3L3uD7HlfP+lgWsaok9LWbRLfSgK+DGN5IuqF2b fTzqJY6toizqoThHm8x4AT/t/yoawIM0eiIDdhNY4GTYYkMDKaTRXKnyxhCarolvWBjf G6Ns6BUjr3zEFf+x8wgC6JSG1iy400P2Zw05DsTeblASSzDTSkPEIVlJyqv6wr0gUjaJ ewCI0XU4iEAUs5m3bNk0o2UDpjZEfLAlv2+lhGj/r/BNFkLSyBh6WQCWKh/lTubCE5nl DwKA== 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=oq2EGOEtM3194bdAjb+39RP3WhTcW1FizMFhFpicZT8=; b=XuDqO47rN3iA80h6tJrmURkyI8Owjyat5frHTWwNUlpaPXpgAt9qzQm81iTcXkfwd2 wKavNPHkzRos5UcdMt8CWtNPDIL/4bWpk9gAkbXhAnP7BPYps4kfqW0xPkmY2CKQNN4v xhr36s0eJrDoQpOCm8OWj5x3BS7Wt8jk3FWPSRFt6qNoDpH1v3yPdO/Cmi+uHbHFI4kL T2qqInFTGM+jWEp9sH0KQVJxnT/LHIn/UikpTn84m2GcMfyeBpS2niN46GnQY5Bly7NG QvcrMDItI6WGDLKpe7cdJoJZZsOhw7O5RWmdnSGhfgRreyzcUzFs2oEhdVRa9RLojjUC cFYg== X-Gm-Message-State: AIVw113cWxZP0Kc/qiIzo46Py4/LHcZrGZyjGoK3K0bvdU/0Sil6n6+k y3HhFrOOcqRBKebbYXE= X-Received: by 10.223.166.148 with SMTP id t20mr317645wrc.52.1499422111785; Fri, 07 Jul 2017 03:08:31 -0700 (PDT) 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 y9sm2958008wry.32.2017.07.07.03.08.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 03:08:30 -0700 (PDT) Date: Fri, 7 Jul 2017 12:08:23 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Ferruh Yigit Cc: dev@dpdk.org, Thomas Monjalon Message-ID: <20170707100823.GR11154@bidouze.vm.6wind.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v6 00/22] 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, 07 Jul 2017 10:08:32 -0000 On Fri, Jul 07, 2017 at 11:05:22AM +0100, Ferruh Yigit wrote: > On 7/7/2017 1:09 AM, 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 patchset depends on: > > > > eal: complete attach / detach support > > http://dpdk.org/ml/archives/dev/2017-May/066366.html > > http://dpdk.org/dev/patchwork/patch/24522/ > > > > ethdev: add flow API rule copy function > > http://dpdk.org/ml/archives/dev/2017-May/066145.html > > http://dpdk.org/dev/patchwork/patch/24406/ > > > > ethdev: add isolated mode to flow API > > http://dpdk.org/ml/archives/dev/2017-April/064327.html > > http://dpdk.org/dev/patchwork/patch/23741/ > > > > v1 --> v2: > > > > - Wrote documentation > > - Fixed commit logs, signed-off-by > > - Added LSC event support > > - A few minor fixes > > > > v2 --> v3: > > > > - Numerous bug fixes. > > - Complete sub-EAL rework to follow new bus API. > > - burst protection on sub removal. > > - more flexible sub definition. > > - flow isolated mode support. > > > > v3 --> v4: > > > > - Split back commits > > net/failsafe: add fast burst functions > > net/failsafe: support device removal > > That were squashed by error during a rebase > > - Fix segfault on port plugin > > - Fix isolate mode support for MLX4 ports plugin > > > > v4 --> v5: > > > > - Follow new plug / unplug API. > > > > v5 --> v6: > > > > - Follow new hotplug API. > > - Improve usability of hotplug API. > > - Fix rte_dev hotplug API implementation. > > - Introduce rte_eal_devargs_rmv API as EXPERIMENTAL. > > - Use it to clean up resources on hotplug_remove. > > - Fix hotplug implementation and support un pci bus. > > The scan was not idempotent, nor clean. > > Neither were the device fields. > > - Implement plug operation for vdev bus. > > This is needed for hotplug support and to make the EAL > > independent from vdev-specific API. > > - Remove useless parameters from plug / unplug API. > > > > This patchset is fairly big and complex. The hotplug API has been rushed and > > has never been tested outside of the special case of vdev bus. > > > > These evolutions are proposed alongside this PMD as only this PMD allows to test > > this API at the moment, and without those evolutions this PMD cannot be used. > > > > Gaetan Rivet (22): > > eal: return device handle upon plugin > > eal: fix hotplug add > > devargs: introduce removal function > > eal: release devargs on device removal > > pci: use given name as generic name > > pci: fix generic driver pointer on probe error > > pci: fix hotplug operations > > vdev: add dev to vdev macro > > vdev: implement plug operation > > bus: remove useless plug parameter > > ethdev: save VLAN filter setting > > ethdev: add deferred intermediate device state > > ethdev: count devices consistently > > net/failsafe: add fail-safe PMD > > net/failsafe: add plug-in support > > net/failsafe: add flexible device definition > > net/failsafe: support flow API > > net/failsafe: support offload capabilities > > net/failsafe: add fast burst functions > > net/failsafe: support device removal > > net/failsafe: support link status change event > > net/failsafe: support flow API isolation mode > > Hi Gaetan, > > The failsafe PMD postponed to RC2, to mainly let eal level dependencies > be resolved first, and I believe it is OK to get a PMD in RC2 because > its scope is limited. > > But in this new version of the patchset, there are many patches touches > to eal and ethdev level. I don't think it is good idea to get these > changes in RC2 and with next-net tree. > > I believe these should be resolved in main repo, in RC1. And failsafe as > a PMD, can go in RC2 via next-net. > > What do you think separating eal and ethdev bits of the patchset and > target RC1? > Sure, I'm all for it. The only reason I presented them both at once was because the changes that would then be included in RC1 will be hard to test without the fail-safe PMD. But it makes sense to stabilize the lib changes before integrating the fail-safe. > Thanks, > ferruh -- Gaëtan Rivet 6WIND