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

Thomas Monjalon thomas.monjalon at 6wind.com
Fri Jul 24 14:40:34 CEST 2015


2015-07-24 10:50, Ananyev, Konstantin:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > 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.

You can avoid ABI breakage by using the compat macros and/or NEXT_ABI.
But it shouldn't go into 2.1 as the API shouldn't be changed after RC1.



More information about the dev mailing list