From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <wenzhuo.lu@intel.com>
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by dpdk.org (Postfix) with ESMTP id 0B2A25F29
 for <dev@dpdk.org>; Fri,  7 Dec 2018 02:02:20 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20])
 by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 06 Dec 2018 17:02:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.56,324,1539673200"; d="scan'208";a="300048630"
Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206])
 by fmsmga006.fm.intel.com with ESMTP; 06 Dec 2018 17:02:18 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
 FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS)
 id 14.3.408.0; Thu, 6 Dec 2018 17:02:18 -0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.182]) by
 SHSMSX103.ccr.corp.intel.com ([169.254.4.59]) with mapi id 14.03.0415.000;
 Fri, 7 Dec 2018 09:02:17 +0800
From: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>
To: "Varghese, Vipin" <vipin.varghese@intel.com>, "Ananyev, Konstantin"
 <konstantin.ananyev@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
CC: "Yang, Qiming" <qiming.yang@intel.com>, "Li, Xiaoyun"
 <xiaoyun.li@intel.com>, "Wu, Jingjing" <jingjing.wu@intel.com>
Thread-Topic: [dpdk-dev] [PATCH v2 03/20] net/ice: support device and queue ops
Thread-Index: AQHUitYvnvewVum/C0SwcC+JV3x3NaVtfrcAgAOtQxD//4DRAIAAa58AgAAoToCAATomYA==
Date: Fri, 7 Dec 2018 01:02:16 +0000
Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC09093FE11AD7@shsmsx102.ccr.corp.intel.com>
References: <1542956179-80951-1-git-send-email-wenzhuo.lu@intel.com>
 <1543820821-108122-1-git-send-email-wenzhuo.lu@intel.com>
 <1543820821-108122-4-git-send-email-wenzhuo.lu@intel.com>
 <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2C4550@BGSMSX101.gar.corp.intel.com>
 <6A0DE07E22DDAD4C9103DF62FEBC09093FE11691@shsmsx102.ccr.corp.intel.com>
 <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2D4171@BGSMSX101.gar.corp.intel.com>
 <2601191342CEEE43887BDE71AB977258010CEC3BAA@irsmsx105.ger.corp.intel.com>
 <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2D4448@BGSMSX101.gar.corp.intel.com>
In-Reply-To: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2D4448@BGSMSX101.gar.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [PATCH v2 03/20] net/ice: support device and queue
 ops
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2018 01:02:21 -0000

Hi Vipin, Konstantin,

> -----Original Message-----
> From: Varghese, Vipin
> Sent: Thursday, December 6, 2018 10:16 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Lu, Wenzhuo
> <wenzhuo.lu@intel.com>; dev@dpdk.org
> Cc: Yang, Qiming <qiming.yang@intel.com>; Li, Xiaoyun
> <xiaoyun.li@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 03/20] net/ice: support device and queu=
e
> ops
>=20
> snipped
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Varghese, Vipin
> > > Sent: Thursday, December 6, 2018 5:27 AM
> > > To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; dev@dpdk.org
> > > Cc: Yang, Qiming <qiming.yang@intel.com>; Li, Xiaoyun
> > > <xiaoyun.li@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
> > > Subject: Re: [dpdk-dev] [PATCH v2 03/20] net/ice: support device and
> > > queue ops
> > >
> > > Hi Wenzhuo,
> > >
> > > Please find my updates below
> > >
> > > snipped
> > > > > > +	if (!vsi->rss_key)
> > > > > > +		vsi->rss_key =3D rte_zmalloc("rss_key",
> > > > > > +					   vsi->rss_key_size, 0);
> > > > > > +	if (!vsi->rss_lut)
> > > > > > +		vsi->rss_lut =3D rte_zmalloc("rss_lut",
> > > > > > +					   vsi->rss_lut_size, 0);
> > > > >
> > > > > 2 suggestions
> > > > > 1. should the name be macro?
> > > > Sorry, which name?
> > > Would you like to convert and use as?
> > > #define ICE_RSS_KEY "rss_key"
> > > #define ICE_RSS_LUT "rss_lut"
> > >
> > > And replace ' rte_zmalloc("rss_key",' as ' rte_zmalloc(ICE_RSS_KEY,'
> > > >
> > > > > 2. if there are multiple 810 NIC under DPDK, should not each rss
> > > > > be different like "rss_key-%u" where it is port number?
> > > > Sorry, don't understand the question.
> > > Let assume we have 2 ICE_DSI NIC on PCIe bus. Then crating '
> > rte_zmalloc("rss_key",' for port 1 will fail since malloc region "rss_k=
ey"
> > > already exist for port 0
> >
> > It wouldn't.
> > rte_malloc() simply ignores name argument.
> > You can even put NULL here.
> > As I remember, Anatoly suggested to remove it completely in future.
> > Konstantin
> Ohh, this I was not aware. Then the suggestion from my end would be to
> pass 'NULL'. Wenzhuo you can ignore the MACRO and safe thing is passing
> NULL.
Checked the code, currently someone already passes NULL to the function. I'=
d like to change it to NULL. Thanks.

>=20
> >
> > >
> > > >
> > > > >
> > > > > Snipped
> > > > >
> > > > > > +
> > > > > > +static int
> > > > > > +ice_dev_start(struct rte_eth_dev *dev) {
> > > > > > +	struct rte_eth_dev_data *data =3D dev->data;
> > > > > > +	struct ice_hw *hw =3D ICE_DEV_PRIVATE_TO_HW(dev->data-
> > > > > > >dev_private);
> > > > > > +	struct ice_pf *pf =3D ICE_DEV_PRIVATE_TO_PF(dev->data-
> > > > > >dev_private);
> > > > > > +	uint16_t nb_rxq =3D 0;
> > > > > > +	uint16_t nb_txq, i;
> > > > > > +	int ret;
> > > > > > +
> > > > > > +	ICE_PROC_SECONDARY_CHECK;
> > > > >
> > > > > Device start is not supported, but how is this differentiated
> > > > > from primary configured device vs secondary configured device.
> > > > >
> > > > > Ie: primary uses black list '-b BB:DD:F' while secondary uses
> > > > > '-w BB:DD:F'. In this case since we are checking process type
> > > > > this will return without
> > > > start?
> > > Two updates with respect to your comment, 1. tool and application
> > > like dpdk-procinfo will no longer be able pull data since you are
> > > asking to black
> > list.
> > > 2. If there are functions which needs to shared, like primary using
> > > rx-0 and tx-
> > 0 then secondary rx-1 and tx-1 how to make this work?
> > >
> > > snipped