From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH v6 00/22] introduce fail-safe PMD Date: Fri, 7 Jul 2017 11:05:22 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit To: Gaetan Rivet , dev@dpdk.org, Thomas Monjalon Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 9B0783256 for ; Fri, 7 Jul 2017 12:05:25 +0200 (CEST) In-Reply-To: Content-Language: en-US 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 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? Thanks, ferruh