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 D7A1441B9B; Wed, 1 Feb 2023 09:46:53 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C7AD842B8C; Wed, 1 Feb 2023 09:46:53 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 4E15B4021F for ; Wed, 1 Feb 2023 09:46:52 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D4C385C0117; Wed, 1 Feb 2023 03:46:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 01 Feb 2023 03:46:51 -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=1675241211; x= 1675327611; bh=S74x1NLrt0SC9QdAXMRsCvpM9VfIS9H5vCsFA6mY19I=; b=E P9HqerzT9FPiSPSuyNXCQTHH1Zi2LIHcosRuNI1X8H60XHEu09er9ibvsn0+c9of GvVvSsahj4Yk91JDtEWr+F4spSTzyJG0OgkPcqnnWvVkXd7AADvJJUsvyVsrs/UT NgVfDsy8Hsbyko9RFSkQ6TSz7vShMLVe+KgBfyq2KGeqrfv5QLOaN7klWvAbATu5 hZElR4EH/WxH5KfpwmXT2nsULNXZc/brCYK8tLkrDxpK0HRUEuiYn7OUu3bXLIIC n0KCNrJsvgKcvI3l6bpEeurydYgUC4YwcfiwamPc1lZqUcuelatySTQhtiN4XlAJ p1GHwK2L0X/41/nZfGDqg== 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=1675241211; x= 1675327611; bh=S74x1NLrt0SC9QdAXMRsCvpM9VfIS9H5vCsFA6mY19I=; b=Y LhcbQAfqoqgzqa68nBRa99+d7lsmxQ6fUPnzLEtvw9PrfZvIaM40kfn7nnWWbmlZ COFhRr6rRSYa1ym00YFjlG/b+ivLlzJKQ5iKE1qVg2dHfzQ9j/Gm+Q3P/2hCapeG k+VRcSI1704/naV4A5xcAZyMNZLgJxHuyi45LhyXnFMCrGjow4DZbZe3/ddUPGEq IDuVQu7n6tKpE7WStbUSsLa9xW+kqLjU53cT4xjcHMbieV3j8XLMICgBR39agqRN whKPpKO2/ohrNwHVRiJc0Nk2+SdOS7/BB5znrJLQf0iP0B65NtR2YTwDunNWBbws XDgaOOTVkfavJ1Lzm8PMg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefhedguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 1 Feb 2023 03:46:50 -0500 (EST) From: Thomas Monjalon To: Andrew Rybchenko , Jerin Jacob Cc: Rongwei Liu , dev@dpdk.org, matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, stephen@networkplumber.org, rasland@nvidia.com, Ferruh Yigit , bruce.richardson@intel.com Subject: Re: [PATCH v4 2/3] ethdev: add standby state for live migration Date: Wed, 01 Feb 2023 09:46:49 +0100 Message-ID: <13621401.RDIVbhacDa@thomas> In-Reply-To: References: <20221221090017.3715030-2-rongweil@nvidia.com> <6b2c3d11-428a-2c69-ddf9-2b3306dacbce@oktetlabs.ru> 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 01/02/2023 09:40, Jerin Jacob: > On Wed, Feb 1, 2023 at 1:02 PM Andrew Rybchenko > wrote: > > > > On 2/1/23 01:55, Thomas Monjalon wrote: > > > 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? > > > > As I understand multi-process shares an VFIO device between > > many application. As far as I remember it is just required to > > pass corresponding file descriptor to another application. > > I think, Here, it is two different primary application. Yes it is 2 primary applications. > Even if it is primary-secondary kind of case, bus or pci driver layer > needs fixup, > Currently, if we add allow list same PCI device on primary and secondary, > the second app start will fail. Can we imagine passing a VFIO handle to the new application?