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

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2015-07-24 09:15, Ananyev, Konstantin:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2015-07-22 19:28, Konstantin Ananyev:
> > > +struct rte_eth_rxq_info {
> > > +	struct rte_mempool *mp;     /**< mempool used by that queue. */
> > > +	struct rte_eth_rxconf conf; /**< queue config parameters. */
> > > +	uint8_t scattered_rx;       /**< scattered packets RX supported. */
> > > +	uint16_t nb_desc;           /**< configured number of RXDs. */
> > 
> > Shouldn't we move nb_desc in rte_eth_rxconf?
> > So rte_eth_rx_queue_setup() would have less parameters.
> 
> I thought about that too, but it seems more drawbacks then pluses with that idea:
> 1. Right now it is possible to call rte_eth_rx_queue_setup(..., rx_conf=NULL, ...);
> In that case rte_eth_rx_queue_setup()will use default for that device rx_conf.
> If we'll move mempool into rxconf, will break that ability.
> 2.  A bit unclear what mempool should be returned as default_rxconf by rte_eth_dev_info_get().
> Should it be just NULL.

I was only suggesting to move nb_desc, not mempool.
In case rx_conf==NULL, the nb_desc should be the max allowed by the driver.
By the way, we should allow nb_desc==0 as it is done in virtio.
Users shouldn't have to care about queue parameters (including nb_desc) for
a basic usage.

> 3. ABI breakage and we (and all customers) will need  to modify each and every RX setup/configure code.
> 
> For me it just seems like too much hassle, without any clear advanatage.

The advantage is to have a cleaner API. Seems important to me.