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=-10.3 required=3.0 tests=BAYES_00, 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 37C05C07E99 for ; Tue, 6 Jul 2021 01:48:52 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 7F8D16197F for ; Tue, 6 Jul 2021 01:48:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F8D16197F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com 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 A6CF34067E; Tue, 6 Jul 2021 03:48:50 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id EE6EA40040 for ; Tue, 6 Jul 2021 03:48:48 +0200 (CEST) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4GJlk8135Sz78Mg; Tue, 6 Jul 2021 09:45:20 +0800 (CST) Received: from dggema767-chm.china.huawei.com (10.1.198.209) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Tue, 6 Jul 2021 09:48:46 +0800 Received: from [10.66.74.184] (10.66.74.184) by dggema767-chm.china.huawei.com (10.1.198.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 6 Jul 2021 09:48:45 +0800 To: Andrew Rybchenko , Thomas Monjalon CC: , , References: <1620460836-38506-1-git-send-email-lihuisong@huawei.com> <1644089.D8zZfYZZjn@thomas> <62f7ec14-50a8-7404-d462-c40502c07348@huawei.com> <1640815.0OcVWAD7zg@thomas> From: Huisong Li Message-ID: <79a410e0-7ca9-551c-7e5d-7e02f57884ed@huawei.com> Date: Tue, 6 Jul 2021 09:48:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.66.74.184] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggema767-chm.china.huawei.com (10.1.198.209) X-CFilter-Loop: Reflected 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" 在 2021/7/5 17:50, Andrew Rybchenko 写道: > 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. ok > .