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 9C814423E7; Sun, 15 Jan 2023 23:46:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2D89A40156; Sun, 15 Jan 2023 23:46:38 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 91E6F40042 for ; Sun, 15 Jan 2023 23:46:36 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 29CAF5C00DF; Sun, 15 Jan 2023 17:46:36 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 15 Jan 2023 17:46:36 -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=1673822796; x= 1673909196; bh=8KrzyzzllPH1HRC613rsUia3muB6aj1r56O8us7tnss=; b=j iQVCD6RQgniZ6gyoLsrCNJ2OfSM5dm3JemJfpz5K8s4DynyrMukdn5Vj15kpnU5e 3geNkQB7mq/wuv0PAE9UwB3tIUXwBmSEm+yiEaHMWeg4PYYl0clBB/IhmebpAz13 egl/+9wqo14bXl6rGX2E4g3T66XxksgznpaNP/i0ycq2jkicSr9JNeNWMBhr89cc v8BL4QOTLJ6rVxTcd4afxHOLjDEITeaZ8NXD6pBiQO8Z2F9AipccWVF6sfbq2Bzi sKmrwobCXVzB1BN5U2A4/INv5gWmBVyprAQIAdvC1As/tyCgSgLvc9eSeTL3rnLX bKNePPP5I3+pZv+9upjig== 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=1673822796; x= 1673909196; bh=8KrzyzzllPH1HRC613rsUia3muB6aj1r56O8us7tnss=; b=r PeoOEULvOF46xWenTs3NlrSnfoSWHngMTOOtNOlDazaAjHcAYMoPdyNK5rSgFrXS 4WK2CfST3XPUHq9X+O09qnaQGpSEtROeZwO+DVDL+okWolUlVynkJE2ivHUbyvhP 050htmj6f0UqxfGLsl8pZRnuZFHOZDhugX3aq3woQTv5j9ZcPukklqryt896mHJP sF4lEugApwDYk6KVHTwVDkjax8dCN9qTkXzwzolwgXihTwKqCMWHXQH+3igJ1RH8 lf4PxMphH7zin+hIqfytfrHtwynhWLZ2mb4LJwjmZoFM2EwuLefPnpi3hN1ty1pz /6XQANQykjqxYoFJBT24A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddtfedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdei uddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 15 Jan 2023 17:46:34 -0500 (EST) From: Thomas Monjalon To: Rongwei Liu , Jerin Jacob , Ori Kam Cc: dev@dpdk.org, Matan Azrad , Slava Ovsiienko , Ferruh Yigit , Andrew Rybchenko , "dev@dpdk.org" , Raslan Darawsheh , maxime.coquelin@redhat.com Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby Date: Sun, 15 Jan 2023 23:46:32 +0100 Message-ID: <12782390.VsHLxoZxqI@thomas> In-Reply-To: References: <20221205215416.7ac53a55@hermes.local> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 26/12/2022 17:44, Ori Kam: > From: Rongwei Liu > > From: Jerin Jacob > > > On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu wrote: > > > > From: Jerin Jacob > > > > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu wrote: > > > > > > From: Jerin Jacob > > > > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu wrote: > > > > > > > > From: Jerin Jacob > > > > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu wrote: > > > > > > > > > > > > > > > > > > > > Users may want to change the DPDK process to different > > > > > > > > > > versions > > > > > > > > > > > > > > > > > > Different version of DPDK? If there is any ABI change how= to > > > > > > > > > support > > > > > this? > > > > > > > > > > > > > > > > > There is a new member which was introduced into > > > > > > > > rte_eth_dev_info but it > > > > > > > shouldn=E2=80=99t be ABI breaking since using reserved fields. > > > > > > > > > > > > > > That is just for rte_eth_dev_info. What about the ABI change = in > > > > > > > different ethdev structure and rte_flow structures across > > > > > > > different DPDK > > > > > ABI versions. > > > > > > > > > > > > > Besides this, there is no other ABI changes dependency. > > > > > > > > > > > > Assume there is a DPDK process A running with version v21.11 and > > > > > > plan to upgrade to version v22.11. Let' call v22.11 as process = B. > > > > > > > > > > OK. That's a relief. I understand the use case now. > > > > > > > > > > Why not simply use standard DPDK multiprocess model then. > > > > > Primary process act as server for slow path API. Secondary process > > > > > can come and go(aka can be updated at runtime) and use as client = to > > > > > update rules via primary-secondray communication mechanism. > > > > > > > > > Just image if process A and process B have ABI breakage like differ= ent > > > rte_flow_item_*** and rte_flow_action_*** size and members. > > > > How can we quickly accommodate primary/secondary to be ABI > > compatible > > > across different versions? > > > > It will be very huge effort and difficult to implement, at least in= my > > opinion. > > > > What do you think? > > > > > > Yes. it difficult what ever approach we take, On other hand, ethdev > > subsystem > > > has other components like rte_tm and other offload etc, We can not si= mply > > > have rte_eth_process_set_active() and things magical works across > > different > > > DPDK versions. Example, if rte_flow rule has meter action will depend= on > > > another HW piece in NIC card for doing the metering but set by flow A= PI. > > > IMO, Customer can simply use standard multiprocess model if version a= re > > > compatible without any special intelligence in application. > > > Otherwise they can reload and start the application again or have spe= cial > > > intelligence in application to cater the specific area of API they ne= ed to > > > leverage based on server and client DPDK versions. > >=20 > > Thanks for the message. > > IMO, we are trying to eliminate the version/ABI dependency with this new > > added API. > > For example, if meter action is in the flow rules: > > 1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / = end" > > 2. Process B starts with "rte_eth_process_set_active(false, flags)" > >=20 > > Just give Nvidia' hardware as example (other NIC vendors may not care if > > group 0 or not) > > If the process A' rules are in group 0, users should set them one by on= e to > > process B. > > Then either flush process A' rules or quit process A, then process B ca= lls with > > "rte_eth_process_set_active(true, flags)" > > All is set. > > It will avoid complex operations with client/server model and avoid use= r mis- > > operation too. > > We should avoid reload as much as possible since reloading is very time > > consuming and may take up to few seconds. > > In this time slot, there is no application to handle the traffic, and e= verything is > > lost. > > For end user especially cloud service providers, they are sensitive to = the > > traffic down time. >=20 > From my viewpoint the upgrade has nothing to do with DPDK as a library, > the upgrade may be because of application upgrade. > Unless I'm missing something, this API is not meant for API/ABI it is cre= ated > to allow minimum downtime when doing upgrade of the application. > Unless I'm missing something critical, since the upgrade in any case is n= ot > only for the DPDK but the entire app, there isn't any ABI/API issue. Yes we can consider the case of an application upgrade with the same DPDK. The patch needs to be reworded in this more realistic direction I think. We can also improve the usage explanations. That said, another high level question is about the scope of the feature. In this patch, only ethdev is targetted. Do you think we need the same migration mechanism in other classes like vDPA, crypto, etc?