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 7DDBB42415; Thu, 19 Jan 2023 11:31:43 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 62554410DD; Thu, 19 Jan 2023 11:31:43 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id B7A2C4068E for ; Thu, 19 Jan 2023 11:31:41 +0100 (CET) Received: from kwepemm600004.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NyJls682zzRrgl; Thu, 19 Jan 2023 18:29:45 +0800 (CST) Received: from [10.67.103.231] (10.67.103.231) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Thu, 19 Jan 2023 18:31:39 +0800 Message-ID: <04cd6606-e4fc-5ce4-1f08-6a982f1bfd4e@huawei.com> Date: Thu, 19 Jan 2023 18:31:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port To: Thomas Monjalon , Ferruh Yigit CC: , , , , References: <20220825024425.10534-1-lihuisong@huawei.com> <3044549.6YUMPnJmAY@thomas> From: "lihuisong (C)" In-Reply-To: <3044549.6YUMPnJmAY@thomas> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.231] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemm600004.china.huawei.com (7.193.23.242) X-CFilter-Loop: Reflected 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 在 2023/1/18 22:12, Thomas Monjalon 写道: > 11/01/2023 11:46, Ferruh Yigit: >> On 1/11/2023 10:27 AM, Ferruh Yigit wrote: >>> On 1/11/2023 12:53 AM, lihuisong (C) wrote: >>>> 在 2023/1/11 0:51, Ferruh Yigit 写道: >>>>> Hi Huisong, >>>>> >>>>> I haven't checked the patch in detail yet, but I can see it gives some >>>>> ABI compatibility warnings, is this expected: >>>> This is to be expected. Because we insert a device state, >>>> RTE_ETH_DEV_ALLOCATED, >>>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned. >>>> We may have to announce it. What do you think? >>> If there is an actual ABI break, it can't go in this release, need to >>> wait LTS release and yes needs deprecation notice in advance. >>> >>> But not all enum value change warnings are real break, need to >>> investigate all warnings one by one. >>> Need to investigate if old application & new dpdk library may cause any >>> unexpected behavior for application. >>> >> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the >> enum solves the issue, although logically it won't look nice. >> Perhaps order can be fixed in next LTS, to have more logical order, but >> not quite sure if order worth the disturbance may cause in application. > It is a state with a logical order, so it would be nice to be able to do > if (state > RTE_ETH_DEV_ALLOCATED) > but given there is RTE_ETH_DEV_REMOVED later in the enum, not sure it is useful. The device state is internel. Applications should not access it directly, right? Currently, ethdev layer or PMD use it by enum value instead of the way like 'state > RTE_ETH_DEV_ALLOCATED'. But, I encapsulated an API, rte_eth_dev_is_used(), for ethdev or PMD to call. I'm not sure if it can help to eliminate our concerns. > > > .