From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=BAYES_00,DKIM_ADSP_DISCARD, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E87DC07E99 for ; Mon, 5 Jul 2021 09:50:13 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 81454613C1 for ; Mon, 5 Jul 2021 09:50:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 81454613C1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=oktetlabs.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E4A8A411B4; Mon, 5 Jul 2021 11:50:11 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id C5958411B2 for ; Mon, 5 Jul 2021 11:50:10 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 796F17F563; Mon, 5 Jul 2021 12:50:10 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 796F17F563 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1625478610; bh=6XVluCqYgung432LEL5ckd9wQEdcGsW0N0pSL5vWj3s=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=S4V31TMqcjiHZiHu5OndWNgaKMOg8uMtHUes/9QvzL87seQObBl8UPHlY5oaTltv9 axGAfNiJwocQgeGK0qnB4lS/GcHMwkemooR14xq2p6EKgs+MpNJ31S0LwzQF/p4gxS Bu4ytEEz5DXVRL/oyezsISuT8fyUpguC/b7fZ6k0= To: Thomas Monjalon , Huisong Li Cc: dev@dpdk.org, ferruh.yigit@intel.com, konstantin.ananyev@intel.com References: <1620460836-38506-1-git-send-email-lihuisong@huawei.com> <1644089.D8zZfYZZjn@thomas> <62f7ec14-50a8-7404-d462-c40502c07348@huawei.com> <1640815.0OcVWAD7zg@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Mon, 5 Jul 2021 12:50:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <1640815.0OcVWAD7zg@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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" Hi Huisong, On 7/5/21 9:07 AM, Thomas Monjalon wrote: > 05/07/2021 05:18, Huisong Li: >> 在 2021/7/5 4:05, Thomas Monjalon 写道: >>> 08/05/2021 10:00, Huisong Li: >>>> Currently, if dev_configure is not invoked or fails to be invoked, users >>>> can still invoke dev_start successfully. This patch adds a "dev_configured" >>>> 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? >> >> It doesn't feel right. "enum rte_eth_dev_state" is private to the >> primary and secondary processes and can be independently controlled. >> >> However, the secondary process does not make resource allocations and >> does not call dev_configure(). >> >> These are done by the primary process and can be obtained or used by >> the secondary process. >> >> Like "dev_started" in struct rte_eth_dev_data. > > That's a good reason, thanks. > Please, send non-RFC version of the patch with fixed summary (w/o "lib/") and above reason mentioned in the patch description as well.