From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
"Pattan, Reshma" <reshma.pattan@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC 2/2] librte_ether: add new fields to rte_eth_dev_info struct
Date: Fri, 15 Apr 2016 11:32:22 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725836B3ECD5@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <2916536.igaxvufRMN@xps13>
Hi everyone,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, April 15, 2016 11:36 AM
> To: Pattan, Reshma
> Cc: dev@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
prev parent reply other threads:[~2016-04-15 11:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-14 9:44 [dpdk-dev] [RFC 0/2] add new fields to rte_eth_dev_info structure Reshma Pattan
2016-04-14 9:44 ` [dpdk-dev] [RFC 1/2] doc: announce ABI change for " Reshma Pattan
2016-04-15 9:42 ` Mcnamara, John
2016-04-15 10:02 ` Thomas Monjalon
2016-04-14 9:44 ` [dpdk-dev] [RFC 2/2] librte_ether: add new fields to rte_eth_dev_info struct Reshma Pattan
2016-04-15 9:42 ` Mcnamara, John
2016-04-15 10:36 ` Thomas Monjalon
2016-04-15 11:32 ` Ananyev, Konstantin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2601191342CEEE43887BDE71AB97725836B3ECD5@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=reshma.pattan@intel.com \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).