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 69712424A5; Sat, 28 Jan 2023 02:39:08 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 58F3B42BAC; Sat, 28 Jan 2023 02:39:08 +0100 (CET) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id 9B94C410DC for ; Sat, 28 Jan 2023 02:39:07 +0100 (CET) Received: from kwepemm600004.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4P3cSK2CKfzJq20; Sat, 28 Jan 2023 09:34:41 +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; Sat, 28 Jan 2023 09:39:05 +0800 Message-ID: <40b99e49-a4ef-81dc-6fd0-cd8a112e3a0c@huawei.com> Date: Sat, 28 Jan 2023 09:39:05 +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> <04cd6606-e4fc-5ce4-1f08-6a982f1bfd4e@huawei.com> <2812469.o2A3GueYyp@thomas> From: "lihuisong (C)" In-Reply-To: <2812469.o2A3GueYyp@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/19 22:35, Thomas Monjalon 写道: > 19/01/2023 11:31, lihuisong (C): >> 在 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? > Right > >> Currently, ethdev layer or PMD use it by enum value instead of the way like >> 'state > RTE_ETH_DEV_ALLOCATED'. > Right > >> 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. > Yes I think it's OK. ok, I will fix it based on our discussion. > > > .