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 4BA7CA054A; Tue, 6 Dec 2022 06:54:21 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3704E40151; Tue, 6 Dec 2022 06:54:21 +0100 (CET) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by mails.dpdk.org (Postfix) with ESMTP id B3B6B4014F for ; Tue, 6 Dec 2022 06:54:19 +0100 (CET) Received: by mail-pj1-f41.google.com with SMTP id w4-20020a17090ac98400b002186f5d7a4cso17073295pjt.0 for ; Mon, 05 Dec 2022 21:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=iEDPzwBbZcF6dtPeTg1Hb0vqCk+KwXDlymvtiufJlaE=; b=3nhwn6z62Ujqx/L/9DTcNPWhVnkwhUGkumZxOH6qwPttX7jEip8ctRU/V+KPgZzjrR +x5Dnb+8ARHqpfZLgbl3rsuM0xVAJ0ts2dk0PTIEsfEXrg0yoOvBtAdT7mm0pxWaw/0L Oh6ZS/Ve83CEExBtBUr7DZGIm41b9PQp+DO4uTICYHFCY5sLYdHAUVXfPc1X3Is78OP4 tBsZyq+wK5BzMO1Gm1/2r5v0UnjsTxzNQku2Gxzj0SDyNIrk5PUJmHi26aZWuItwcPgG 6KrXs5RuB5kZvR+QpvQwG7q6CFh3AfvAE9wpKhcMt2B4BiCw8reIdWSonyW8ZLOCKAs1 AXag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iEDPzwBbZcF6dtPeTg1Hb0vqCk+KwXDlymvtiufJlaE=; b=BurxaXwcikZz7amf4RWVa68MdQypzAuqrJCBLiittwR8R7Fp4fyHm+2btreYOE4SZQ akBxToQm4+iPCSXD+P4/3SwHyonAc+fek14U0RtgLIyHunnC5iyXZhGkucSa8RbZbKRk a8OGl3t0SPz5wfD+UxHQuNF4BFNwSddnlpmUYLw1qFqIhlPcZSf2WmP3gIZefbW6hF9j +oU3N9L8iMfyVyDxsLkqMg29Ot6WLQeYpa36eYKlsemzR2u0UYBPO5dbBEvwovXXzY6S DYXH/vaRzt40658RCCWDW5lGnOmA8Ctx7zRi37iirzVo4Tha5smfQqVNwKWSH+41OpQN dudg== X-Gm-Message-State: ANoB5pl2uydhq8n6mM/vXark0x1i0fWAkrVtzzLXRZmopFJp1Lq1BUZm OVhyimIdIOjIhMWwjfrV0tlU0w== X-Google-Smtp-Source: AA0mqf7lFmp5mVSGn0Mv/2mT5CA2T7KMEtmU00QoPvoJNORqRPfDTsIhBxrF4gmrId1rCmu1kg6+lg== X-Received: by 2002:a17:902:ed94:b0:189:66dc:4af4 with SMTP id e20-20020a170902ed9400b0018966dc4af4mr52970806plj.149.1670306058571; Mon, 05 Dec 2022 21:54:18 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id mv15-20020a17090b198f00b0021937b2118bsm11954160pjb.54.2022.12.05.21.54.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Dec 2022 21:54:18 -0800 (PST) Date: Mon, 5 Dec 2022 21:54:16 -0800 From: Stephen Hemminger To: Rongwei Liu Cc: Matan Azrad , Slava Ovsiienko , Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Ferruh Yigit , Andrew Rybchenko , "dev@dpdk.org" , Raslan Darawsheh Subject: Re: [RFC 2/2] ethdev: add API to set process to primary or secondary Message-ID: <20221205215416.7ac53a55@hermes.local> In-Reply-To: References: <20221201082005.732252-1-rongweil@nvidia.com> <20221201082005.732252-3-rongweil@nvidia.com> <20221201071011.1fd30f68@hermes.local> <20221205080801.52030df8@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Tue, 6 Dec 2022 03:47:42 +0000 Rongwei Liu wrote: > Hi > > BR > Rongwei > > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Tuesday, December 6, 2022 00:08 > > To: Rongwei Liu > > Cc: Matan Azrad ; Slava Ovsiienko > > ; Ori Kam ; NBU-Contact- > > Thomas Monjalon (EXTERNAL) ; Ferruh Yigit > > ; Andrew Rybchenko > > ; dev@dpdk.org; Raslan Darawsheh > > > > Subject: Re: [RFC 2/2] ethdev: add API to set process to primary or secondary > > > > External email: Use caution opening links or attachments > > > > > > On Fri, 2 Dec 2022 03:27:38 +0000 > > Rongwei Liu wrote: > > > > > > > > > > The state of the devices and the system is really unstable if this > > > > fails. There is no rollback here. > > > > > > > Assume application is calling rte_eth_process_set_primary(false); > > > Once failed, call all preceding successful ports as > > > rte_eth_process_set_primary(true); > > > What do you think? > > > > I think this should have a PMD capability flag so that application > > > > can check that device supports doing this. And it would have to be > > > > opt-in so that existing devices would always fail. > > > If device doesn't support it, it can set the ethdev callback to NULL or return > > failure for all devices. > > > Then the devices' state will be consistent. > > > > > > Assume there are two DPDK ports. > > If the application tries to change roles and one of the devices does not support > > the change over, then that error is fatal. The first device has changed state > > already, and the second doesn't allow it. > > > If my understanding is correct, you are saying one application to probe two PMD vendors. This is difficult to handle. > > This needs to be a capability flag for the device, and would need an additional > > flag in the device documentation as well. > > > For multiple vendors simultaneously probing. Capability flag is a must. But no need for single vendor, right? > > I bet many devices do regular malloc or mmap in the primary process and that > > is not going to work with this change. > Sorry, looks like I mis-lead you. The words "Primary/Secondary" in this update have no relationship with current PRIMARY/SECDONARY definition. > Doesn't focus on the resource ownership. > In this update: Primary application' offload rules are effective immediately. Secondary' rules are in queue which will be effective if primary application exits or primary application doesn't insert any rule. > Maybe we can call it as "active/standby" or "main/standby" or "active/backup"? Do you have naming suggestion? DPDK supports any combination of PCI and virtual devices. Any patch that restricts that is a bad idea. There already is a capability mechanism in ethdev API. A well written application would look at those flags for all ethdev's before attempting transition. Layered PMD's like bonding, failsafe, and netvsc would also need to handle the nesting. The problem is hard, what you did so far is a start but there are lots more issues that need to be considered.