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 D5B09A0A0F; Mon, 5 Jul 2021 08:07:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 602B240686; Mon, 5 Jul 2021 08:07:56 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 3F97340141 for ; Mon, 5 Jul 2021 08:07:54 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6FA8F5C00B8; Mon, 5 Jul 2021 02:07:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 05 Jul 2021 02:07:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= 6V+0goYczVkP00u8RacXkOrAdEMhb9E/eE4+coTDFwQ=; b=KJLE+q8chXRI+tSh UHhefinaCvIW6BNtqkh6AqWhRE3La6XF6NLkRaiAQBCvAJrwXVKNfn6XFM97rWtV RFhyAc9FKgmcXu3kKaojfhyFjR6Yi3lVvyRkTVFmtGD21sX3ImF34ykdXQkyPlLh 2eccCbRLmnPIPPN8HKz597a3RrwDAr9GrhfaRqGY2eu8JWEpoUXlZxZy+wneFDM8 vpNdVVyRqujnZbCBqYDyS9kQPGTqCwt2WrS454XnTpDaCjuENDNyWx1brmcXvmMT MmUqVsaQ0Pa99NXytm/ooLYNhKlzrNHzZPXGiS4Rw0Ot8ZKwsWfpWgINlQIq18zJ X55UOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=6V+0goYczVkP00u8RacXkOrAdEMhb9E/eE4+coTDF wQ=; b=TJoeWQ+odt14RrHksPY+PEoUYwSwLqrwj2VjZYi45tRHG4VQNAqQcxGV6 KP2qx1Q6FWXmmDCzTix2H+PttxFh6d6pmwzENrqLpj6kPSFKnLoSGnwMrt9fT3vA fsv2tOg+OHDoW+kNen2qDK9RBW8gTq3hyQ8IFeyvFcRmz7NHF+DLswBEfFk6jQc0 gfcun45tnToZCZpqgNRzeg3ZiIS+E1Au8PeQYHf0sPnjxBOtcn6uzo97OF7CiS+m ZmBWxxCp07HsiCA09tQN20TKWggkszMSYhYcRfOERU0UoH/gFmWpwwnmw5/qj5eg uInmJZkCAJA+++e634RdDj/C5bq3Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeejfedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeekteehtdeivefhieegjeelgedufeejheekkeetueevieeuvdev uedtjeevheevteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 5 Jul 2021 02:07:51 -0400 (EDT) From: Thomas Monjalon To: Huisong Li Cc: dev@dpdk.org, ferruh.yigit@intel.com, andrew.rybchenko@oktetlabs.ru, konstantin.ananyev@intel.com Date: Mon, 05 Jul 2021 08:07:48 +0200 Message-ID: <1640815.0OcVWAD7zg@thomas> In-Reply-To: <62f7ec14-50a8-7404-d462-c40502c07348@huawei.com> References: <1620460836-38506-1-git-send-email-lihuisong@huawei.com> <1644089.D8zZfYZZjn@thomas> <62f7ec14-50a8-7404-d462-c40502c07348@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC] lib/ethdev: add dev configured flag 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 Sender: "dev" 05/07/2021 05:18, Huisong Li: > =E5=9C=A8 2021/7/5 4:05, Thomas Monjalon =E5=86=99=E9=81=93: > > 08/05/2021 10:00, Huisong Li: > >> Currently, if dev_configure is not invoked or fails to be invoked, use= rs > >> can still invoke dev_start successfully. This patch adds a "dev_config= ured" > >> flag in "rte_eth_dev_data" to control whether dev_start can be invoked. > > [...] > >> --- a/lib/ethdev/rte_ethdev_core.h > >> +++ b/lib/ethdev/rte_ethdev_core.h > >> @@ -167,7 +167,11 @@ struct rte_eth_dev_data { > >> scattered_rx : 1, /**< RX of scattered packets is ON(1) / OFF(0) = */ > >> all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */ > >> dev_started : 1, /**< Device state: STARTED(1) / STOPPED(0). */ > >> - lro : 1; /**< RX LRO is ON(1) / OFF(0) */ > >> + lro : 1, /**< RX LRO is ON(1) / OFF(0) */ > >> + dev_configured : 1; > >> + /**< Device configuration state: > >> + * CONFIGURED(1) / NOT CONFIGURED(0). > >> + */ > > Why not using "enum rte_eth_dev_state"? > > Because rte_eth_dev.state is not shared between processes? >=20 > It doesn't feel right. "enum rte_eth_dev_state" is private to the=20 > primary and secondary processes and can be independently controlled. >=20 > However, the secondary process does not make resource allocations and=20 > does not call dev_configure(). >=20 > These are done by the primary process and can be obtained or used by=20 > the secondary process. >=20 > Like "dev_started" in struct rte_eth_dev_data. That's a good reason, thanks.