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 C32CBA0C47; Tue, 6 Jul 2021 03:47:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 703BA4067E; Tue, 6 Jul 2021 03:47:43 +0200 (CEST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 2899A4067E for ; Tue, 6 Jul 2021 03:47:41 +0200 (CEST) Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4GJlj80drjzZqm6; Tue, 6 Jul 2021 09:44:28 +0800 (CST) Received: from dggema767-chm.china.huawei.com (10.1.198.209) by dggemv711-chm.china.huawei.com (10.1.198.66) 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:47:39 +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:47:38 +0800 To: "Ananyev, Konstantin" , Andrew Rybchenko , "Yigit, Ferruh" , "dev@dpdk.org" CC: Thomas Monjalon References: <1620460836-38506-1-git-send-email-lihuisong@huawei.com> <644f214d-887a-02ae-5476-af8e6d100221@huawei.com> <256aa58e-7455-e861-ee22-eb87ddd2db67@oktetlabs.ru> <15094894-8483-1aef-cdae-700384130fa3@intel.com> <61f83abc-4567-7a42-220d-ccc808a2aaa4@huawei.com> From: Huisong Li Message-ID: Date: Tue, 6 Jul 2021 09:47:38 +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 19:22, Ananyev, Konstantin 写道: > >> On 7/5/21 6:03 AM, Huisong Li wrote: >>> 在 2021/7/3 19:04, Ananyev, Konstantin 写道: >>>>> 在 2021/7/2 21:23, Ananyev, Konstantin 写道: >>>>>>> On 7/2/2021 12:08 PM, Andrew Rybchenko wrote: >>>>>>>> @Thomas, @Ferruh, I tend to accept it (with minor style fixes), >>>>>>>> but I need your opinion on it before doing it. >>>>>>>> >>>>>>> I guess we were relying on the user/application to have correct >>>>>>> order up until >>>>>>> now, it can be good to add this into the API. OK to add it for me. >>>>>> I don't know do we really need that flag in dev_data or not, >>>>>> but if we do - probably better to reset it at dev_confgure() >>>>>> straight before >>>>>> we start to make any changes in dev_data. >>>>> Sorry, I don't get you. Some fields in rte_eth_dev_data are initialized >>>>> firstly in the probe phase. >>>>> >>>>> Do you mean to add clear this flag at the beginning of dev_configure()? >>>> Yes, just before we start to modify things. >>> In this patch, this flag has been cleared for all scenarios where the >>> rte_eth_dev_data modification fails in the dev_configure(). > I understand that. > What I am saying: at first call to dev_confgiure() you execute it with > dev_data->confgiured == 0. > On second and subsequent calls - it could be either 0 or 1, > depending how previous dev_confgiure() had finished. > I think it would be good to keep it always the same, > to avoid any non-anticipated behaviour. I get it. The current patch can ensure that this flag is 1 when dev_configure() is called successfully, and is 0 when dev_configure() isn't called or dev_data fails to be modified. But there is a drawback, as you say. I will fix it in non-RFC version. >>> And it is set to 1 when dev_configure() is configured successfully. >>> >>> Please check the rollback. Thanks😁 > > >> I guess Konstantin means the case when user re-configures >> the device which has been configured before and the operation >> fails. I'm not 100% what should be the state of the flag when >> dev_configure callback is executed. I'd say that it should be >> 0 when the first configure happens and should be 1 in the >> case of reconfigure. I'll try to review it carefully when >> non-RFC version of the patch is available.