From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [RFC 2/2] librte_ether: add new fields to
	rte_eth_dev_info struct
Date: Fri, 15 Apr 2016 12:36:10 +0200
Message-ID: <2916536.igaxvufRMN@xps13>
References: <1460627077-8207-1-git-send-email-reshma.pattan@intel.com>
 <1460627077-8207-3-git-send-email-reshma.pattan@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org
To: Reshma Pattan <reshma.pattan@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48])
 by dpdk.org (Postfix) with ESMTP id 2316B4CE4
 for <dev@dpdk.org>; Fri, 15 Apr 2016 12:36:13 +0200 (CEST)
Received: by mail-wm0-f48.google.com with SMTP id v188so25021355wme.1
 for <dev@dpdk.org>; Fri, 15 Apr 2016 03:36:13 -0700 (PDT)
In-Reply-To: <1460627077-8207-3-git-send-email-reshma.pattan@intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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?