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 5F113A0547; Mon, 5 Dec 2022 17:08:07 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 054A140156; Mon, 5 Dec 2022 17:08:07 +0100 (CET) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by mails.dpdk.org (Postfix) with ESMTP id 8B9F44014F for ; Mon, 5 Dec 2022 17:08:05 +0100 (CET) Received: by mail-pl1-f170.google.com with SMTP id k7so11237936pll.6 for ; Mon, 05 Dec 2022 08:08:05 -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=+bF5VsQM+/1er1iddK0pniRnuwxPqfZ/zC1JUoIhTsE=; b=QR0c3VWLu2A/3wNXWlB616MN/hbLpJ/lDxPp2+nh+dDxENi+eGhKQZXPfcINXlBW2m e4O+2lki345uciQaXTG87DFCfkU5KqTSQjWKdLBaDp1FTczLLjHITVereqGTD8p8F+kM VfQ8gUAyNWwW9VxFiFFlMWntjPecpRVR9YsbRiFVvwXU34RNohTfBDaFZ2b+mPuOpQeX +onjAPS5X9l91edWAHjWbXUwSrSzrHR41VE7daIZTIxXJKhU5AnBBVXXO943SNyTUEmB y74yY8RPQwLOVf/kwiXnGeEW0V0oiE+BX/uVyLZGYmEaBnFd+cW5dbfZEDPck2q0p93n kEZQ== 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=+bF5VsQM+/1er1iddK0pniRnuwxPqfZ/zC1JUoIhTsE=; b=rZ+U9ZFEDdtiagVPDwiUTwFT/+UG/iS0lH7lR9S3QlhdiWw2bgVXV/nHVjiyDRrQyF xEg/T0XTsgf7QHSei3Z4SELgDynM3Yo5OQXgBnUYG4sxssYR/898vQH9oeSdTE3e4gRi RQGZWQmkJtV1cA8Qnn0k1PY8JFDHGtZHgZs4W4VfPNoS4ZFKg1a4OFZaPGlUBvegd9Mv Z3NYFx+M8GXqZG9Eq7jyiEEm2JwBQ0IF6TWUA843+iKCeT8NGg0HuSo8H9vQDLoocr0X fZLtlXLoliGcB8GrLWL79aJh3aZ1bg/zwH5dPxwvnmhrd/b15ZowjuTRLKGxgCDKKxL8 6RQA== X-Gm-Message-State: ANoB5pkAY8+8TMZXRdxHjmiAPMy5NazXmYqnH2YKPCAsFbm7yMt+/iXv MeD32Sl7B12Xs8rr2VK1j7vrig== X-Google-Smtp-Source: AA0mqf5UJ4h61JKmIn0m+vmpmGOwzyd7sx2PtGWiQfRdn/RSV5FFJS5ivah5LnbIOOpyshAkr8XVFw== X-Received: by 2002:a17:90b:3941:b0:215:db2e:bb17 with SMTP id oe1-20020a17090b394100b00215db2ebb17mr90017049pjb.166.1670256484678; Mon, 05 Dec 2022 08:08:04 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id u15-20020a1709026e0f00b00189667acf15sm10820358plk.162.2022.12.05.08.08.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Dec 2022 08:08:04 -0800 (PST) Date: Mon, 5 Dec 2022 08:08:01 -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: <20221205080801.52030df8@hermes.local> In-Reply-To: References: <20221201082005.732252-1-rongweil@nvidia.com> <20221201082005.732252-3-rongweil@nvidia.com> <20221201071011.1fd30f68@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 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. This needs to be a capability flag for the device, and would need an additional flag in the device documentation as well. I bet many devices do regular malloc or mmap in the primary process and that is not going to work with this change.