> -----Original Message----- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Wednesday, July 22, 2015 8:48 PM > To: Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCHv4 1/5] ethdev: add new API to retrieve RX/TX > queue information > > On Wed, 22 Jul 2015 19:28:51 +0100 > Konstantin Ananyev <konstantin.ananyev at intel.com> wrote: > > > Add the ability for the upper layer to query RX/TX queue information. > > > > Add new structures: > > struct rte_eth_rxq_info > > struct rte_eth_txq_info > > > > new functions: > > rte_eth_rx_queue_info_get > > rte_eth_tx_queue_info_get > > > > into rte_etdev API. > > > > Left extra free space in the queue info structures, > > so extra fields could be added later without ABI breakage. > > > > v2 changes: > > - Add formal check for the qinfo input parameter. > > - As suggested rename 'rx_qinfo/tx_qinfo' to 'rxq_info/txq_info' > > > > v3 changes: > > - Updated rte_ether_version.map > > - Merged with latest changes > > > > v4 changes: > > - rte_ether_version.map: move new functions into DPDK_2.1 sub-space. > > > > Signed-off-by: Konstantin Ananyev <konstantin.ananyev at intel.com> > > Since all this data should be rxconf already, Is it possible > to do a generic version of this and not have to change every driver.
I don't think it is possible to implement these two functions at rte_etdev level only. At least not with current ethdev/PMD implementation: - Inside struct rte_eth_dev_info we have only: 'struct rte_eth_rxconf default_rxconf;'. We don't have rxconf here for each configured rx queue. That information is maintained by PMD and inside PMD, different devices have different format for queue structure. - rte_eth_rxq_info contains not only rxconf but some extra information: mempool in use by that queue, min/max possible number of descriptors. Also my intention was that in future that structure would be extended to provide some RT info about queue: (number of free/used descriptors from SW point of view, etc). Konstantin > > You only handled the Intel hardware drivers. But there also > all the virtual drivers, other vendors etc.
