From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 6BE6C37B1 for ; Thu, 1 Jun 2017 16:38:20 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id 7so160478727wmo.1 for ; Thu, 01 Jun 2017 07:38:20 -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=qgQ9KNYjXy0M7cWa4e4t4sBt3RvxI5yp+iemtcQ+f3k=; b=vv5nchLjGSe0BmhtVEXKldeKDNE/TzBeNfBQc8+o0wGFOKG/HG54Zxe/O4PomfxRsK yATDQD2V8WnBgRLvmbG8zRE8vbun8+VP59C+kd79paF8EQGXALELM2+R92OKBUWzLjNB PFO55TtnHMQTgiHF9XRNauVdauU4O9eyhQphEwF8+AURrCjLESIm9n4qd6AUIe/Hyj+j +uV/vbPwXTNEM6Huves6RVWjqp69048g6ajd6L5N7b6eaSYZj0qPNALNSuhwZIennB0S oFi+4E00TfvG00ku6FTiRzNsN1lyx/Dc3zoC2RTDzZJ13v9pNxAbXfOWx0g8MuWDBIVp OCPg== 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=qgQ9KNYjXy0M7cWa4e4t4sBt3RvxI5yp+iemtcQ+f3k=; b=bOgl94YMvgVuNksmiuiJ4T+aAuyBVAhmTm1BuSWwUsXWF7O1OkyXVX27Z7dJ6pBEPs KSO1069qGjPHHvJ52Onwx2QCV9Mi25AwOSaTUJi9MCBHPREveAdTvo4sA2i0fLEenpyN wzlBxv84A1U5sdWb091qqrC8j/kDsG52zBSvVs8NzpOtqMfcf4PJzgiXVK4Kne5dCgnn bZbqnlmbwEpQFm3Tui7COP9dWNVE5QvLb3dMDEgWdA5IRdNxZVCkncjSsF88JjtYU7yU n3vMNI8K5gtqFpIBMXU+uNszkjrd74S82xkk58dk6kM60uOYzI8Ep4Ip1f2uWlCJEZV+ +mrg== X-Gm-Message-State: AODbwcB9kR3WIC10/FuzxW4J06EDFS7ekwzQMKRIbGGPTgSxhsUjE6kF jLNMNOj6Nb6neCqCbos= X-Received: by 10.223.139.146 with SMTP id o18mr1598662wra.146.1496327899633; Thu, 01 Jun 2017 07:38:19 -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 9sm22521159wmh.17.2017.06.01.07.38.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2017 07:38:18 -0700 (PDT) Date: Thu, 1 Jun 2017 16:38:12 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Stephen Hemminger Cc: dev@dpdk.org Message-ID: <20170601143812.GF18840@bidouze.vm.6wind.com> References: <20170531082309.072c873d@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170531082309.072c873d@xeon-e3> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v4 08/12] net/failsafe: support offload capabilities 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: Thu, 01 Jun 2017 14:38:20 -0000 On Wed, May 31, 2017 at 08:23:09AM -0700, Stephen Hemminger wrote: > On Mon, 29 May 2017 15:42:20 +0200 > Gaetan Rivet wrote: > > > Signed-off-by: Gaetan Rivet > > Acked-by: Olga Shern > > --- > > doc/guides/nics/features/failsafe.ini | 6 ++ > > drivers/net/failsafe/failsafe_ops.c | 131 +++++++++++++++++++++++++++++++++- > > 2 files changed, 135 insertions(+), 2 deletions(-) > > Once again what about case of dumb synthetic NIC combined with SR-IOV VF? > The VF has offloads the virtual NIC does not. > The rules for capabilities are a little complicated. In the case both VF and the virtual NIC are present at launch, then the logical AND is done both their capabilities sets. If one has additional capabilities that the user is requesting, and the fail-safe recognize them (currently, all RX offloads, as TX offloads were not yet expressed by flags), and this capability is not supported by one slave, then this offload is disabled in the configuration. > What about late plugin. how do you program the offloads of the later arriving > VF device. If the VF is not present at launch, then the fail-safe reads only the set of capabilities from the fallback device. It does not have to do any AND-ing of the flags. The consequence is that upon plugin of the VF, the latter has to respect the current running configuration. Probing will actually fail if some capability is not supported (depending on PMDs), and the running configuration is not updated as it is considered "live". There are only two solutions to this, either: * Complicate a lot the fail-safe design and the rules applied in the decision made on NIC configuration. The user then has bad surprises upon seeing that his performance have been degraded for arcane reasons. * Emulate in software the offloads and try to advertize as many as possible. This is done for example in the TAP PMD for some flags, allowing those offloads to be used with hardware NICs. The user then has a clear view of the available offloads by comparing both sets of capabilities. -- Gaëtan Rivet 6WIND