>>> >>> Note: The hairpin queue is not supported with above >>> rte_eth_*x_queue_info_get, so the queue state could be >>> RTE_ETH_QUEUE_STATE_STARTED or RTE_ETH_QUEUE_STATE_STOPPED. >>> Note: After add queue_state field, the 'struct rte_eth_rxq_info' size >>> remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so >>> it could be ABI compatible. >>> >>> Signed-off-by: Chengwen Feng fengchengwen@huawei.com >>> Signed-off-by: Lijun Ou oulijun@huawei.com >> >> <...> >> >>> diff --git a/lib/librte_ethdev/rte_ethdev.h >>> b/lib/librte_ethdev/rte_ethdev.h >>> index efda313..3b83c5a 100644 >>> --- a/lib/librte_ethdev/rte_ethdev.h >>> +++ b/lib/librte_ethdev/rte_ethdev.h >>> @@ -1591,6 +1591,8 @@ struct rte_eth_rxq_info { >>> uint8_t scattered_rx; /**< scattered packets RX supported. */ >>> uint16_t nb_desc; /**< configured number of RXDs. */ >>> uint16_t rx_buf_size; /**< hardware receive buffer size. */ >>> + /**< Queues state: STARTED(1) / STOPPED(0). */ >>> + uint8_t queue_state; >>> } __rte_cache_min_aligned; >>> /** >>> @@ -1600,6 +1602,8 @@ struct rte_eth_rxq_info { >>> struct rte_eth_txq_info { >>> struct rte_eth_txconf conf; /**< queue config parameters. */ >>> uint16_t nb_desc; /**< configured number of TXDs. */ >>> + /**< Queues state: STARTED(1) / STOPPED(0). */ >>> + uint8_t queue_state; >>> } __rte_cache_min_aligned; >>> /* Generic Burst mode flag definition, values can be ORed. */ >>> >> >> This is causing an ABI warning [1], but I guess it is safe since the >> size of the struct is not changing (cache align). Adding a few more >> people to comment. >> >> >> [1] >> https://travis-ci.com/github/ovsrobot/dpdk/builds/220497651 > > Frankly speaking I dislike addition of queue_state as uint8_t. > IMHO it should be either 'bool started' or enum to support more > states in the future if we need.
I think we already have set of defines for it: lib/librte_ethdev/rte_ethdev_driver.h:925:#define RTE_ETH_QUEUE_STATE_STOPPED 0 lib/librte_ethdev/rte_ethdev_driver.h:926:#define RTE_ETH_QUEUE_STATE_STARTED 1 lib/librte_ethdev/rte_ethdev_driver.h:927:#define RTE_ETH_QUEUE_STATE_HAIRPIN 2
If we want to publish it, then might be enough just move these macros to rte_ethdev.h or so.
About uint8_t vs enum - yes, in principle enum would be a bit nicer, but right now rte_eth_dev_data.(rx|tx)_queue_state[] itself is an array of uint8_t. So probably not much point to waste extra 3B in rte_eth_(rxq|txq)_info. Unless in future will want to change it in struct rte_eth_dev_data too (or even hide it inside dev private queue data).
I forgot about hairpin and bitmask... If so, I think it is sufficient to fix absolutely misleading comment, say that it is a bit mask and think about removal of RTE_ETH_QUEUE_STATE_STOPPED (since it could be stopped+hairpin). May be consider to use uin16_t, since 8 bit is really small bitmask. It still fits in available hole.
Hmm, as I can read the code - hairpin queue can't be started/stopped by SW, and each of the states (stopped/started/hairpin) is mutually exclusive. Is that not what was intended when hairpin queues were introduced?
Thanks, yes, you're right. My memory lies to me. If queue state is not a bit mask, it should be an enum from API point of view. Rx/Tx queue info structures are control path. I see no point to save bits here. Clear API is more important on control path. The only reason here to use uint8_t is to avoid ABI breakage. I can't judge if it is critical to wait or not.
As alternate thought - introduce new API function, something like: int rte_eth_get_rxq_state(portid, queue_id); Then rte_eth_dev_is_rx_hairpin_queue() probably can be deprecated in favour of this new one.
The 'rte_eth_dev_is_rx_hairpin_queue()' is internal function, and it is not visible to the application, it should be OK to keep it.
What I am saying - we well have get-state() - PMDs can use the new one instead of rte_eth_dev_is_rx_hairpin_queue(). Or rte_eth_dev_is_rx_hairpin_queue() can be just a wrapper around get_rxq_state().
But 'STATE_HAIRPIN' should be kept internal, or should be available to the application?
The actual need is to know the start/stop state of the queue. That is for app to decide if 'rte_eth_tx_done_cleanup()' can be done or not an a queue: https://patches.dpdk.org/project/dpdk/patch/1614938252-62955-1-git-send-emai...
If we don't expose STATE_HAIRPIN what state we will report for hairpin queue back to the user? Either STARTED or STOPPED are both invalid and misleading. I think we have to report all 3 supported states back to the user.
And normally I also prefer APIs with simple & clear responsibility, but this one seems very related to the existing '_queue_info_get()' ones, so I am fine with both options.