From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id 6E2B42C1A for ; Wed, 15 Mar 2017 12:15:58 +0100 (CET) Received: by mail-wr0-f170.google.com with SMTP id l37so8668273wrc.1 for ; Wed, 15 Mar 2017 04:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=sginyRYQ3bbOU9AnHZ2LdCVly9PBmyqcfdEDgKI953E=; b=1cUkLkiFNmEY8EenQKliwxqBBo9/U+sAgh+pRc5KsvTRwIJ9ArOz5Mz3/NCu3HN6aG 7VE6KCbmp4U5X3xTPhgMBZ0WrZMjPmtBJDTLVZXCI9R7v+ANgbUedMpjfw50852nGSqG GQv1Q7GviYZFyFMYxVXVGkUGvP3CtwMt9UIF/KI0lAyBvfpHSFt15Sb8ZO4MIxE7BIz9 qtckU0XGxFP1YQ7/P+Gsql6nHbNhJ39VGXHwMy6YST3u+DP+XRBlezp7JtrqNlT6ASXk vwyR/pyUzIGTsGm6OXsyQIAD8wumc7o9CCZd3RdCaPEc6Y2eANlOw0VK4X8BH91+t9YB 4mwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=sginyRYQ3bbOU9AnHZ2LdCVly9PBmyqcfdEDgKI953E=; b=FII+0G1ifoWHmRKBNVUl7hVAgZIYcmrP+TfCrg8Q2DZpny4E35rTsLQ4Ddl4rciPsl jnR7SGkwk+PHu787LRcSma++b4TRZgk+D9/pzm2X+RZWueLy7ga1xg9zJlPXBO6KKCzX GmufMMx+lwhG1PFqeD7eB3OuM5UY7NqKiULAAk5Tttit7v18tNAYxAUnAozXxtXAcnuK MSZGPONHWnMvUujTuxrIy5pIMCYKkDMap5Utm7AL+nnG8nWpLosuevPaVSBHjqX+xHth +qg5TW1/q79wqxj8Z5/D3QRaKMNQRRQBOQzqAvXZ7J1Pa3kWey4tvQRr6awpSaQdM5gm PDUA== X-Gm-Message-State: AFeK/H29iFjH3xpFQ7MTCEztQVFt8VyGZJ9/ShyTHEx+iJ5kC4wyvulbFiQ0UYWvN/7cw9Gu X-Received: by 10.223.135.237 with SMTP id c42mr2420665wrc.139.1489576557694; Wed, 15 Mar 2017 04:15:57 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id o31sm1966799wrc.27.2017.03.15.04.15.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 04:15:57 -0700 (PDT) From: Thomas Monjalon To: Bruce Richardson , =?ISO-8859-1?Q?Ga=EBtan?= Rivet Cc: Neil Horman , dev@dpdk.org, Adrien Mazarguil , techboard@dpdk.org Date: Wed, 15 Mar 2017 12:15:56 +0100 Message-ID: <2220671.FCXKFdQQ2A@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20170315032853.GA366048@bricha3-MOBL3.ger.corp.intel.com> References: <20170314144947.GO908@bidouze.vm.6wind.com> <20170315032853.GA366048@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 11:15:58 -0000 2017-03-15 03:28, Bruce Richardson: > On Tue, Mar 14, 2017 at 03:49:47PM +0100, Ga=EBtan Rivet wrote: > > > > 2. Bonding and link availability > > > > > > > > The hot-plug functionality is not a core function of the bondi= ng PMD. > > > > It is only interested in knowing if the link is active or not.= > > > > > > > Currently, yes. The suggestion was that you augment the bonding = driver so that > > > hot plug is a core function of bonding. > > >=20 > > > > Adding the device persistence to the bonding PMD would mean ad= ding the > > > > ability to flexibly parse device definitions to cope with plug= -ins in > > > > evolving busses (PCI hot-plug could mean changing bus addresse= s), being > > > > able to emulate the EAL and the ether layer and to properly st= ore the > > > > device configuration. This means formally describing the life= of a > > > > device in a DPDK application from start to finish. > > > > > > > Which seems to me to be exactly what your PMD does. I don't see = why its > > > fundamentally harder to do that in an existing pmd, than it is in= a new one. > > >=20 > >=20 > > Indeed it does. I must emphasize the "formally describe the life of= a > > device". The hot-plug functionality goes beyong the link-level chec= k. > > The description of a device from a DPDK standpoint is complete in t= he > > fail-safe PMD. The state-machine must be able to describe the entir= e > > life of a device, from the devargs parsing to its start-up. > >=20 > > We cannot reuse the existing bonding PMD architecture for this. We= > > would have to rewrite the bonding PMD from the ground up for the > > hot-plug function. Because it is actually a different approach to > > managing the slaves. > >=20 > > This is what I wanted to illustrate in [Fig. 1] and [Fig. 2]: > >=20 > > - In the bonding, the init and configuration steps are still the > > responsibility of the application and no one else. The bonding PMD= > > captures the device, re-applies its configuration upon dev_configu= re() > > which is actually re-applying part of the configuration already p= resent > > within the slave eth_dev (cf rte_eth_dev_config_restore). > >=20 > > - In the fail-safe, the init and configuration are both the > > responsibilities of the fail-safe PMD itself, not the application > > anymore. This handling of these responsibilities in lieu of the > > application is the whole point of the "deferred hot-plug" support,= of > > proposing a simple implementation to the user. > >=20 > > This change in responsibilities is the bulk of the fail-safe code. = It > > would have to be added as-is to the bonding. Verifying the correctn= ess > > of the sync of the initialization phase (acceptable states of a dev= ice > > following several events registered by the fail-safe PMD) and the > > configuration items between the state the application believes it i= s in > > and the fail-safe knows it is in, is the bulk of the fail-safe code= . > >=20 > > This function is not overlapping with that of the bonding. The reas= on I > > did not add this whole architecture to the bonding is that when I t= ried > > to do so, I found that I only had two possibilities: > >=20 > > - The current slave handling path is kept, and we only add a new on= e > > with additional functionalities: full init and conf handling with > > extended parsing capabilities. > >=20 > > - The current slave handling is scraped and replaced entirely by th= e new > > slave management. The old capturing of existing device is not done= > > anymore. > >=20 > > The first solution is not acceptable, because we effectively end-up= with > > a maintenance nightmare by having to validate two types of slaves w= ith > > differing capabilities, differing initialization paths and differin= g > > configuration code. This is extremely awkward and architecturally > > unsound. This is essentially the same as having the exact code of t= he > > fail-safe as an aside in the bonding, maintening exactly the same > > breadth of code while having muddier interfaces and organization. > >=20 > > The second solution is not acceptable, because we are bending the w= hole > > existing bonding API to our whim. We could just as well simply rena= me > > the fail-safe PMD as bonding, add a few grouping capabilities and c= all > > it a day. This is not acceptable for users. > >=20 > If the first solution is indeed not an option, why do you think this > second one would be unacceptable for users? If the functionality rema= ins > the same, I don't see how it matters much for users which driver > provides it or where the code originates. >=20 > Despite all the discussion, it still just doesn't make sense to me to= > have more than one DPDK driver to handle failover - be it link or > device. If nothing else, it's going to be awkward to explain to users= > that if they want fail-over for when a link goes down they have to us= e > driver A, but if they want fail-over when a NIC gets hotplugged they = use > driver B, and if they want both kinds of failover - which would surel= y > be the expected case - they need to use both drivers. The usability i= s > a problem here. It seems everybody agrees on the need for the failsafe code. We are just discussing the right place to implement it. Gaetan, moving this code in the bonding PMD means replacing the bonding= API design by the failsafe design, right? With the failsafe design in the bonding PMD, is it possible to keep oth= er bonding features? In case we do not have a consensus in the following days, I suggest to = add this topic in the next techboard meeting agenda.