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

[Ananyev, Konstantin]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, July 24, 2015 10:24 AM
> 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
> 
> 2015-07-24 09:15, Ananyev, Konstantin:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 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.

Ah, sorry didn't read it properly first time.
Yes, I think it makes sense to move nb_desc into rxconf, though that means ABI breakage,
and that patch would definitely not make into 2.1. 

> In case rx_conf==NULL, the nb_desc should be the max allowed by the driver.

In my opinion it should be 'preferable by default' PMD value.
Plus, rte_eth_dev_info should contain  min_rx_desc and max_rx_desc,
so user can select nb_rx_desc from the allowed interval, if he needs to.

Konstantin

> 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.