Hi everyone, > -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Friday, April 15, 2016 11:36 AM > To: Pattan, Reshma > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC 2/2] librte_ether: add new fields to > rte_eth_dev_info struct > > 2016-04-14 10:44, Reshma Pattan: > > --- a/lib/librte_ether/rte_ethdev.h > > +++ b/lib/librte_ether/rte_ethdev.h > > @@ -908,6 +908,9 @@ struct rte_eth_dev_info { > > struct rte_eth_desc_lim rx_desc_lim; /**< RX descriptors limits */ > > struct rte_eth_desc_lim tx_desc_lim; /**< TX descriptors limits */ > > uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */ > > + /** number of queues configured by software*/ > > + uint16_t nb_rx_queues; /**< Number of RX queues. */ > > + uint16_t nb_tx_queues; /**< Number of TX queues. */ > > }; > > I think the ethdev design is strange for these structures. > struct rte_eth_dev is internal to be used inside the ethdev API > or by the drivers. > It contains struct rte_eth_dev_data which can be of interest for > the application, except the dev_private part (which could be > directly in struct rte_eth_dev). > > So the global question is: how to share the device data with the > application? > Instead of giving a pointer or a copy of struct rte_eth_dev_data, > we have some different accessors: > - rte_eth_dev_info_get() with a specific struct rte_eth_dev_info > which gathers a lot of info, not only from struct rte_eth_dev_data > - rte_eth_macaddr_get() > - rte_eth_dev_socket_id() > - rte_eth_link_get() which is more than an accessor > > I think having some specialized accessors is good. > But the rte_eth_dev_info_get() looks like to be a big request > without precise goal and going to break ABI really often. > There are some queues informations, some (not so precise) > offload capabilities, some steering (RSS/VMDq) informations, > the default configuration of some Intel NIC thresholds, > the speed capabilities, etc. > > Shouldn't we try to streamline this API?
I think in general it is a good idea to split dev_info into some smaller sub-pieces. But introduce a new API just for these 2 fields seems like an overkill to me. My vote would be to allow nb_rx/tx_queues into dev_info, If we'll decide to split dev_info - I think it needs to be a subject for a separate patch/discussion. Konstantin
