From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6B51E41B93; Tue, 31 Jan 2023 23:55:33 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F0D5D40684; Tue, 31 Jan 2023 23:55:32 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 78E2D4067B for ; Tue, 31 Jan 2023 23:55:31 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4FFDF3200908; Tue, 31 Jan 2023 17:55:29 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 31 Jan 2023 17:55:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1675205728; x= 1675292128; bh=nHL2qZHNE4ulDijXJvxFwphUrg57DqVcsOtYNgX0oOw=; b=O hzkv1x2eifnyvSCF2WJ1aSyhZMaR0tYUAz0sGS1S4ZikJYA91i075oILBv3woVL0 sow/trWxklPgYLEwq/UCdJ0uTcldFzflVL8M658s6SzkH6wBtGLh0IdRZJZgmnTi bHZYgh1sGI1W/XMM8UYC4jwmePF+lW4tbmBLe7OPiVfxrZDkEnQIj0dFms7DiEka XQlbcaLVDb9AmvXP+esL+XGj10zASAddJleN/cCtgeaKUx86cdprZ0pu2MnPBHk0 5qxfG6jPTPAoFivLqGolbJEWSpS9qkHSd+9cP3MA23kUgdbGCjA7F6qN1JQsYJMA 2dVUO5BU5dyG7JsgMOEHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1675205728; x= 1675292128; bh=nHL2qZHNE4ulDijXJvxFwphUrg57DqVcsOtYNgX0oOw=; b=Y d9ev4+MFHr+xBKmtEz/WJ/tYsCsZlHi8EZVfswhqjpK8SZjh7Gegm2mcS8DCFyiz sxBscMdZ1C12XiXOiY6s3iH6cvmuQiOmpAlP9O4OCvuVs9yo5kEggv5UcLiMjeY6 v3PPsEi7CYr3SKxURuW4bMzlZQAf2qPP6ZoMYLZjA79SCTrITBnYs8fo2ev4HBeo pQH74b8VJ+Vw5oDsrZC4PgYL64cl82aQQb9f+Gxe0sVPfV6b87DuyRopNDoM42mI zRGIa0nc/r6/myjTe0SbD45wzxZy8LwtwEKM5beZxSuNbZZF3wyIRsblwmvRlkE0 A5KVgDfeFfa0yn4k+hLGw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefhedgtdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 31 Jan 2023 17:55:27 -0500 (EST) From: Thomas Monjalon To: Rongwei Liu , Jerin Jacob Cc: dev@dpdk.org, matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, stephen@networkplumber.org, rasland@nvidia.com, Ferruh Yigit , Andrew Rybchenko , bruce.richardson@intel.com Subject: Re: [PATCH v4 2/3] ethdev: add standby state for live migration Date: Tue, 31 Jan 2023 23:55:26 +0100 Message-ID: <45277384.fMDQidcC6G@thomas> In-Reply-To: References: <20221221090017.3715030-2-rongweil@nvidia.com> <20230118154447.595231-3-rongweil@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 31/01/2023 19:14, Jerin Jacob: > On Wed, Jan 18, 2023 at 9:15 PM Rongwei Liu wrote: > > > > When a DPDK application must be upgraded, > > the traffic downtime should be shortened as much as possible. > > During the migration time, the old application may stay alive > > while the new application is starting and being configured. > > > > In order to optimize the switch to the new application, > > the old application may need to be aware of the presence > > of the new application being prepared. > > This is achieved with a new API allowing the user to change the > > new application state to standby and active later. > > > > The added function is trying to apply the new state to all probed > > ethdev ports. To make this API simple and easy to use, > > the same flags have to be accepted by all devices. > > > > This is the scenario of operations in the old and new applications: > > . device: already configured by the old application > > . new: start as active > > . new: probe the same device > > How to probe same device if is already bind to another application? > vfio-pci wont allow this. I missed that part. There is no way to share a VFIO device between 2 applications? > > . new: set as standby > > . new: configure the device > > . device: has configurations from old and new applications > > . old: clear its device configuration > > . device: has only 1 configuration from new application > > . new: set as active > > . device: downtime for connecting all to the new application > > . old: shutdown