From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 94D862A9 for ; Thu, 25 Dec 2014 02:47:00 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 24 Dec 2014 17:45:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,640,1413270000"; d="scan'208";a="652893767" Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96]) by fmsmga002.fm.intel.com with ESMTP; 24 Dec 2014 17:46:58 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by PGSMSX105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 25 Dec 2014 09:46:57 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id 14.03.0195.001; Thu, 25 Dec 2014 09:46:56 +0800 From: "Ouyang, Changchun" To: Vlad Zolotarov , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v3 0/6] Enable VF RSS for Niantic Thread-Index: AQHQHzm9+XzyM+/AzkmVdIuTG6pu75yd/AcAgAGLwpA= Date: Thu, 25 Dec 2014 01:46:54 +0000 Message-ID: References: <1419389808-9559-1-git-send-email-changchun.ouyang@intel.com> <1419398584-19520-1-git-send-email-changchun.ouyang@intel.com> <549A8E7C.7010806@cloudius-systems.com> In-Reply-To: <549A8E7C.7010806@cloudius-systems.com> Accept-Language: zh-CN, 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 v3 0/6] Enable VF RSS for Niantic X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 01:47:01 -0000 Hi, > -----Original Message----- > From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com] > Sent: Wednesday, December 24, 2014 5:59 PM > To: Ouyang, Changchun; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 0/6] Enable VF RSS for Niantic >=20 >=20 > On 12/24/14 07:22, Ouyang Changchun wrote: > > This patch enables VF RSS for Niantic, which allow each VF having at mo= st 4 > queues. > > The actual queue number per VF depends on the total number of pool, > > which is determined by the total number of VF at PF initialization > > stage and the number of queue specified in config: > > 1) If the number of VF is in the range from 1 to 32 and the number of > > rxq is 4('--rxq 4' in testpmd), then there is totally 32 > > pools(ETH_32_POOLS), and each VF have 4 queues; > > > > 2)If the number of VF is in the range from 33 to 64 and the number of > > rxq is 2('--rxq 2' in testpmd), then there is totally 64 > > pools(ETH_64_POOLS), and each VF have 2 queues; > > > > On host, to enable VF RSS functionality, rx mq mode should be set as > > ETH_MQ_RX_VMDQ_RSS or ETH_MQ_RX_RSS mode, and SRIOV mode > should be activated(max_vfs >=3D 1). > > It also needs config VF RSS information like hash function, RSS key, RS= S key > length. > > > > The limitation for Niantic VF RSS is: > > the hash and key are shared among PF and all VF >=20 > Hmmm... This kinda contradicts the previous sentence where u say that VF > on the host should configure hash and RSS key. If PF and VF share the sam= e > hash and key what's the use of configuring it in VF? Could u clarify, ple= ase? What make you think of any "contradicts"? To be more clear, would you pls c= opy and paste which 2 sentences you think of "contradicts", I can correct it if they are, but currently I don't find them.=20 Share means vf doesn't has its own hash function, hash key, and reta table. =20 > > , the RETA table with 128 entries are > > also shared among PF and all VF. So it is not good idea to query the > > hash and reta content per VF on guest, instead, it makes sense to query > them on host(PF). >=20 > On the contrary - it's a very good idea! We use DPDK on Amazon's guests > with enhanced networking and we have no access to the PF. We still need t= o > know the RSS redirection rules for our VF pool. From the 82599 spec, chap= ter > 4.6.10.1.1: "redirection table is common to all the pools and only indica= tes the > queue inside the pool to use once the pool is chosen". In that case we ne= ed > to get the whole 128 entries of the RETA. Is there a reason why we can't = have > it? > Due to hardware limitation, VF could not query its own reta table, because = there is not its own reta, The reta table shared by pf and all vfs. If you need know it, query them on pf is feasible way to do it. > > > > v3 change: > > - More cleanup; > > > > v2 change: > > - Update the description; > > - Use receiving queue number('--rxq ') specified in config to > determine the number of pool and > > the number of queue per VF; > > > > v1 change: > > - Config VF RSS; > > > > Changchun Ouyang (6): > > ixgbe: Code cleanup > > ixgbe: Negotiate VF API version > > ixgbe: Get VF queue number > > ether: Check VMDq RSS mode > > ixgbe: Config VF RSS > > testpmd: Set Rx VMDq RSS mode > > > > app/test-pmd/testpmd.c | 10 +++ > > lib/librte_ether/rte_ethdev.c | 39 +++++++++-- > > lib/librte_pmd_ixgbe/ixgbe_ethdev.h | 1 + > > lib/librte_pmd_ixgbe/ixgbe_pf.c | 75 ++++++++++++++++++++- > > lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 127 > ++++++++++++++++++++++++++++-------- > > 5 files changed, 219 insertions(+), 33 deletions(-) > >