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.
