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