From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <helin.zhang@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id 312473B5;
 Fri, 17 Mar 2017 04:28:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
 d=intel.com; i=@intel.com; q=dns/txt; s=intel;
 t=1489721318; x=1521257318;
 h=from:to:cc:subject:date:message-id:references:
 in-reply-to:content-transfer-encoding:mime-version;
 bh=yLMXZRHdNy6NZUCWuHbNmoncL39ZoAtouOTsiX+bf2k=;
 b=dlMEDb1iMcRYaGE3e5HqtB7+bW8VCjbsT/HagvP03wMwLhrlpfljKPDS
 8F1bBjwzLDT1MN/GeUxT6CZLvc8pxQ==;
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 16 Mar 2017 20:28:36 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.36,175,1486454400"; d="scan'208";a="61507889"
Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203])
 by orsmga002.jf.intel.com with ESMTP; 16 Mar 2017 20:28:35 -0700
Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by
 FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS)
 id 14.3.248.2; Thu, 16 Mar 2017 20:28:36 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
 fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS)
 id 14.3.248.2; Thu, 16 Mar 2017 20:28:36 -0700
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.20]) by
 SHSMSX151.ccr.corp.intel.com ([169.254.3.204]) with mapi id 14.03.0248.002;
 Fri, 17 Mar 2017 11:28:32 +0800
From: "Zhang, Helin" <helin.zhang@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>, "Zhang, Qi Z"
 <qi.z.zhang@intel.com>, "techboard@dpdk.org" <techboard@dpdk.org>
CC: "dev@dpdk.org" <dev@dpdk.org>, "Wu, Jingjing" <jingjing.wu@intel.com>,
 "Yigit, Ferruh" <ferruh.yigit@intel.com>
Thread-Topic: [dpdk-dev] [PATCH] net/i40e: enable statistic reset for VF
Thread-Index: AQHSnm7qLNr9KRpWrkuo4DM+d+diN6GYXQuQ
Date: Fri, 17 Mar 2017 03:28:31 +0000
Message-ID: <F35DEAC7BCE34641BA9FAC6BCA4A12E71AA05FA6@SHSMSX103.ccr.corp.intel.com>
References: <1487874421-11934-1-git-send-email-qi.z.zhang@intel.com>
 <2062537.uIRGRt8aVp@xps13>
In-Reply-To: <2062537.uIRGRt8aVp@xps13>
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] net/i40e: enable statistic reset for VF
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <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, 17 Mar 2017 03:28:39 -0000



> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Friday, March 17, 2017 12:04 AM
> To: Zhang, Qi Z; techboard@dpdk.org
> Cc: dev@dpdk.org; Wu, Jingjing; Zhang, Helin; Yigit, Ferruh
> Subject: Re: [dpdk-dev] [PATCH] net/i40e: enable statistic reset for VF
>=20
> 2017-02-23 13:27, Qi Zhang:
> >  static void
> > +i40evf_dev_stats_reset(struct rte_eth_dev *dev) {
> > +	struct i40e_vf *vf =3D I40EVF_DEV_PRIVATE_TO_VF(dev->data-
> >dev_private);
> > +	/* only DPDK PF support this */
> > +	if (vf->version_major =3D=3D I40E_DPDK_VERSION_MAJOR) {
> > +		if (i40evf_reset_statistics(dev))
> > +			PMD_DRV_LOG(ERR, "Reset statistics failed");
> > +	}
> > +}
>=20
> One more SR-IOV feature not supported with a Linux PF.
> The basic stats feature must be marked as partially supported in
> 	doc/guides/nics/features/i40e_vf.ini
> See also this email:
> 	http://dpdk.org/ml/archives/dev/2017-March/060063.html
>=20
> I wonder whether we should allow such divergence between PF
> implementations. Intel committed to avoid such fragmentation and keep the
> SR-IOV messaging standard but it does not happen.
> It is said that we must allow fast innovation in DPDK space.
> I agree but we should also target a good usability of the VF drivers, all=
owing to
> replace the PF implementations as needed.

Hi Thomas

I think I need to clarify a little bit here.
I think we will try our best, but I don't think we can commit. As they are =
on
totally different community, and of cause code repositories.

>=20
> Here is my suggestion: let's accept a VF feature only if the PF support i=
s
> submitted to both dpdk.org and kernel.org mailing lists.
> I ask to add this topic to the next techboard meeting.

Sorry, technically I disagree with this suggestion, as I don't understand w=
hy!
I was told DPDK is not Linux, and Linux is not DPDK. Why we want to add thi=
s
dependency on Linux PF host driver? And why just on PF/VF driver feature on=
ly?
I think if we can have any good innovative idea on DPDK first, why not just
have it on DPDK? Then Linux or even other OS/community/Company can learn
from DPDK and develop their own.

Regards,
Helin