From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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" To: Thomas Monjalon , "Zhang, Qi Z" , "techboard@dpdk.org" CC: "dev@dpdk.org" , "Wu, Jingjing" , "Yigit, Ferruh" 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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