Re: [dpdk-dev] [PATCHv4 1/5] ethdev: add new API to retrieve RX/TX queue information

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, July 22, 2015 8:48 PM
> To: Ananyev, Konstantin
> Cc: dev@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@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@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.