From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <konstantin.ananyev@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
by dpdk.org (Postfix) with ESMTP id 395904A65
for <dev@dpdk.org>; Fri, 15 Apr 2016 13:32:26 +0200 (CEST)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
by fmsmga101.fm.intel.com with ESMTP; 15 Apr 2016 04:32:25 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,486,1455004800"; d="scan'208";a="785537784"
Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157])
by orsmga003.jf.intel.com with ESMTP; 15 Apr 2016 04:32:25 -0700
Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by
IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Fri, 15 Apr 2016 12:32:23 +0100
Received: from irsmsx105.ger.corp.intel.com ([169.254.7.35]) by
irsmsx155.ger.corp.intel.com ([169.254.14.51]) with mapi id 14.03.0248.002;
Fri, 15 Apr 2016 12:32:23 +0100
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>
Thread-Topic: [dpdk-dev] [RFC 2/2] librte_ether: add new fields to
rte_eth_dev_info struct
Thread-Index: AQHRljJqUHsu9ftggEmEvQDdB6w7kJ+KyBcAgAAfISA=
Date: Fri, 15 Apr 2016 11:32:22 +0000
Message-ID: <2601191342CEEE43887BDE71AB97725836B3ECD5@irsmsx105.ger.corp.intel.com>
References: <1460627077-8207-1-git-send-email-reshma.pattan@intel.com>
<1460627077-8207-3-git-send-email-reshma.pattan@intel.com>
<2916536.igaxvufRMN@xps13>
In-Reply-To: <2916536.igaxvufRMN@xps13>
Accept-Language: en-IE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTkzZDNiMzMtMjBlZS00ZmIwLWFlNjgtOTM0YjliNWJhNTIwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlFQUmRZQXF3UW5oVDZHdHZadnhXMmFlWnhqV2tCa2E3TkVpVG9wNFU1TW89In0=
x-ctpclassification: CTP_IC
x-originating-ip: [163.33.239.180]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [RFC 2/2] librte_ether: add new fields
to rte_eth_dev_info struct
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Fri, 15 Apr 2016 11:32:26 -0000
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
>=20
> 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. */
> > };
>=20
> 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).
>=20
> 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
>=20
> 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.
>=20
> Shouldn't we try to streamline this API?
I think in general it is a good idea to split dev_info into some smaller s=
ub-pieces.
But introduce a new API just for these 2 fields seems like an overkill to m=
e.
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 =20
patch/discussion.
Konstantin