From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cmailsend13.nm.naver.com (cmailsend13.nm.naver.com [125.209.208.222]) by dpdk.org (Postfix) with ESMTP id BB4618EA1 for ; Fri, 16 Oct 2015 01:46:47 +0200 (CEST) Received: (qmail 29094 invoked by uid 100); 15 Oct 2015 23:46:45 -0000 Received: from 10.114.49.164 (HELO cweb02.nm.nhnsystem.com) (10.114.49.164) by cmailsend13.nm.naver.com with SMTP;15 Oct 2015 23:46:45 -0000 Date: Fri, 16 Oct 2015 08:46:45 +0900 (KST) From: =?UTF-8?B?7LWc7J217ISx?= To: McnamaraJohn , De Lara GuarchPablo , dev@dpdk.org Message-ID: <64f8a94f237ac2b7f3483156c3188db@cweb02.nm.nhnsystem.com> In-Reply-To: References: <2ea9ba136f5095d746f98779a478382f@cweb13.nm.nhnsystem.com> <29ad3ce6413c3e312db856ac423e836a@cweb09.nm.nhnsystem.com> <9d3f39f1cd6d917e5e74c12b73f90dd@cweb24.nm.nhnsystem.com> MIME-Version: 1.0 Importance: normal X-Priority: 3 (Normal) X-Naver-CIP: 129.254.191.249 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] =?utf-8?q?I_have_a_problem_in_setting_up_DPDK_2=2E1=2E?= =?utf-8?q?0_in_Fedora_OS_release_20_=28Heisenbug=29=2E_I_cannot_r?= X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: =?UTF-8?B?7LWc7J217ISx?= List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 23:46:49 -0000 ICAKRGVhciBKb2huIE1hbmFtYXJhIGFuZCBEUERLIGV4cGVydHMuCiAKVGhhbmsgeW91IHZlcnkg bXVjaCBmb3IgeW91ciBwcmVjaW91cyBhZHZpY2UgYW5kIGFuc3dlci4KIApJIHdpbGwgdHJ5IHRv IHVwZ3JhZGUgdGhlIE9TLgogCkkgcmVhbGx5IGFwcHJlY2lhdGUgdG8geW91IGZvciB5b3VyIGV4 Y2VsbGVudCB3b3JrIGFuZCBncmVhdCBjb250cmlidXRpb25zLgogClNpbmNlcmVseSBZb3VycywK IApJY2stU3VuZyBDaG9pLgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogIk1jbmFt YXJhLCBKb2huIiZsdDtqb2huLm1jbmFtYXJhQGludGVsLmNvbSZndDsgClRvOiAiPz8/IiZsdDtw bmswMDNAbmF2ZXIuY29tJmd0OzsgIkRlIExhcmEgR3VhcmNoLCBQYWJsbyImbHQ7cGFibG8uZGUu bGFyYS5ndWFyY2hAaW50ZWwuY29tJmd0OzsgImRldkBkcGRrLm9yZyImbHQ7ZGV2QGRwZGsub3Jn Jmd0OzsgCkNjOiAKU2VudDogMjAxNS0xMC0xNSAo66qpKSAxNzoxMDo0OApTdWJqZWN0OiBSRTog W2RwZGstZGV2XSBJIGhhdmUgYSBwcm9ibGVtIGluIHNldHRpbmcgdXAgRFBESyAyLjEuMCBpbiBG ZWRvcmEgT1MgcmVsZWFzZSAyMCAoSGVpc2VuYnVnKS4gSSBjYW5ub3QgcgogCiZndDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0KCiZndDsgRnJvbTogZGV2IFttYWlsdG86ZGV2LWJvdW5jZXNA ZHBkay5vcmddIE9uIEJlaGFsZiBPZiA/Pz8KCiZndDsgU2VudDogVGh1cnNkYXksIE9jdG9iZXIg MTUsIDIwMTUgMjowMiBBTQoKJmd0OyBUbzogRGUgTGFyYSBHdWFyY2gsIFBhYmxvOyBkZXZAZHBk ay5vcmcKCiZndDsgU3ViamVjdDogUmU6IFtkcGRrLWRldl0gSSBoYXZlIGEgcHJvYmxlbSBpbiBz ZXR0aW5nIHVwIERQREsgMi4xLjAgaW4KCiZndDsgRmVkb3JhIE9TIHJlbGVhc2UgMjAgKEhlaXNl bmJ1ZykuIEkgY2Fubm90IHIKCiZndDsKCiZndDsgSSBjaGVja2VkIHdoYXQgeW91IG1lbnRpb25l ZC4KCiZndDsgCgomZ3Q7ICogRmVkb3JhIExpbnV4IGtlcm5lbCB2ZXJzaW9uIGlzIGFzIGZvbGxv d3MuCgomZ3Q7IAoKJmd0OyAgICAgICQgdW5hbWUgLXIgKHByaW50IGtlcm5lbCBuYW1lKQoKJmd0 OyAgICAgIDMuMTcuNy0yMDAuZmMyMC54ODZfNjQKCgoKSGksCgoKClRoaXMgbWF5IGJlIGEga25v d24gaXNzdWUuIFNlZToKCgoKCgpodHRwOi8vZHBkay5vcmcvZG9jL2d1aWRlcy9yZWxfbm90ZXMv a25vd25faXNzdWVzLmh0bWwjZGV2aWNlcy1ib3VuZC10by1pZ2ItdWlvLXdpdGgtdnQtZC1lbmFi bGVkLWRvLW5vdC13b3JrLW9uLWxpbnV4LWtlcm5lbC0zLTE1LTMtMTcKCgoKCgoiRGV2aWNlcyBi b3VuZCB0byBpZ2JfdWlvIHdpdGggVlQtZCBlbmFibGVkIGRvIG5vdCB3b3JrIG9uIExpbnV4IGtl cm5lbCAzLjE1LTMuMTcKCgoKRGVzY3JpcHRpb246CgogICAgV2hlbiBWVC1kIGlzIGVuYWJsZWQg KGlvbW11PXB0IGludGVsX2lvbW11PW9uKSwgZGV2aWNlcyBhcmUgMToxIG1hcHBlZC4gSW4gdGhl IExpbnV4IGtlcm5lbCB1bmJpbmRpbmcgZGV2aWNlcyBmcm9tIGRyaXZlcnMgcmVtb3ZlcyB0aGF0 IG1hcHBpbmcgd2hpY2ggcmVzdWx0IGluIElPTU1VIGVycm9ycy4gSW50cm9kdWNlZCBpbiBMaW51 eCBrZXJuZWwgMy4xNSBjb21taXQsIHNvbHZlZCBpbiBMaW51eCBrZXJuZWwgMy4xOCBjb21taXQu IgoKCgpKb2huCgo= >From wenzhuo.lu@intel.com Fri Oct 16 03:15:28 2015 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 27E339208 for ; Fri, 16 Oct 2015 03:15:26 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 15 Oct 2015 18:15:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,687,1437462000"; d="scan'208";a="581799299" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by FMSMGA003.fm.intel.com with ESMTP; 15 Oct 2015 18:15:25 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 15 Oct 2015 18:15:25 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 15 Oct 2015 18:15:24 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.253]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.96]) with mapi id 14.03.0248.002; Fri, 16 Oct 2015 09:15:23 +0800 From: "Lu, Wenzhuo" To: "Ananyev, Konstantin" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 1/4] ixgbe: 512 entries RSS table on x550 Thread-Index: AQHRB5eOv4Kjn8PV/ESlBID4frSQlZ5tSlTw Date: Fri, 16 Oct 2015 01:15:22 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC09090209F59B@shsmsx102.ccr.corp.intel.com> References: <1443426751-4906-1-git-send-email-wenzhuo.lu@intel.com> <1443426751-4906-2-git-send-email-wenzhuo.lu@intel.com> <2601191342CEEE43887BDE71AB97725836AB02D5@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725836AB02D5@irsmsx105.ger.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 1/4] ixgbe: 512 entries RSS table on x550 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: Fri, 16 Oct 2015 01:15:28 -0000 Hi Konstantin, > -----Original Message----- > From: Ananyev, Konstantin > Sent: Friday, October 16, 2015 6:19 AM > To: Lu, Wenzhuo; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 1/4] ixgbe: 512 entries RSS table on x550 >=20 > Hi Wenzhuo, >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu > > Sent: Monday, September 28, 2015 8:52 AM > > To: dev@dpdk.org > > Subject: [dpdk-dev] [PATCH 1/4] ixgbe: 512 entries RSS table on x550 > > > > Comparing with the older NICs, x550's RSS redirection table is > > enlarged to 512 entries. As the original code is for the NICs which > > have a 128 entries RSS table, it means only part of the RSS table is > > set on x550. So, RSS cannot work as expected on x550, it doesn't redire= ct the > packets evenly. > > This patch configs the entries beyond 128 on x550 to let RSS work > > well, and also update the query and update functions to support 512 ent= ries. > > > > Signed-off-by: Wenzhuo Lu > > --- > > drivers/net/ixgbe/ixgbe_ethdev.c | 106 > ++++++++++++++++++++++++++++++++++----- > > drivers/net/ixgbe/ixgbe_rxtx.c | 18 +++++-- > > 2 files changed, 109 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c > > b/drivers/net/ixgbe/ixgbe_ethdev.c > > index ec2918c..a1ef26f 100644 > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > > @@ -2397,7 +2397,17 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, > struct rte_eth_dev_info *dev_info) > > ETH_TXQ_FLAGS_NOOFFLOADS, > > }; > > dev_info->hash_key_size =3D IXGBE_HKEY_MAX_INDEX * sizeof(uint32_t); > > - dev_info->reta_size =3D ETH_RSS_RETA_SIZE_128; > > + > > + switch (hw->mac.type) { > > + case ixgbe_mac_X550: > > + case ixgbe_mac_X550EM_x: > > + dev_info->reta_size =3D ETH_RSS_RETA_SIZE_512; > > + break; > > + default: > > + dev_info->reta_size =3D ETH_RSS_RETA_SIZE_128; > > + break; > > + } > > + >=20 > Instead of adding switch(hw->mac_type) in dozen of places, why not to cre= ate a > new function: get_reta_size(hw) and use it whenever it is needed? Thanks for the comments. I'll create a function for it. >=20 > > dev_info->flow_type_rss_offloads =3D IXGBE_RSS_OFFLOAD_ALL; } > > > > @@ -3205,14 +3215,29 @@ ixgbe_dev_rss_reta_update(struct rte_eth_dev > *dev, > > struct ixgbe_hw *hw =3D > > IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private); > > > > PMD_INIT_FUNC_TRACE(); > > - if (reta_size !=3D ETH_RSS_RETA_SIZE_128) { > > - PMD_DRV_LOG(ERR, "The size of hash lookup table configured > " > > - "(%d) doesn't match the number hardware can > supported " > > - "(%d)\n", reta_size, ETH_RSS_RETA_SIZE_128); > > - return -EINVAL; > > + switch (hw->mac.type) { > > + case ixgbe_mac_X550: > > + case ixgbe_mac_X550EM_x: > > + if (reta_size !=3D ETH_RSS_RETA_SIZE_512) { > > + PMD_DRV_LOG(ERR, "The size of hash lookup table " > > + "configured (%d) doesn't match the " > > + "number hardware can supported > (%d)\n", > > + reta_size, ETH_RSS_RETA_SIZE_512); > > + return -EINVAL; > > + } > > + break; > > + default: > > + if (reta_size !=3D ETH_RSS_RETA_SIZE_128) { > > + PMD_DRV_LOG(ERR, "The size of hash lookup table " > > + "configured (%d) doesn't match the " > > + "number hardware can supported > (%d)\n", > > + reta_size, ETH_RSS_RETA_SIZE_128); > > + return -EINVAL; > > + } > > + break; > > } > > > > - for (i =3D 0; i < reta_size; i +=3D IXGBE_4_BIT_WIDTH) { > > + for (i =3D 0; i < ETH_RSS_RETA_SIZE_128; i +=3D IXGBE_4_BIT_WIDTH) { > > idx =3D i / RTE_RETA_GROUP_SIZE; > > shift =3D i % RTE_RETA_GROUP_SIZE; > > mask =3D (uint8_t)((reta_conf[idx].mask >> shift) & @@ -3234,6 > > +3259,30 @@ ixgbe_dev_rss_reta_update(struct rte_eth_dev *dev, > > IXGBE_WRITE_REG(hw, IXGBE_RETA(i >> 2), reta); > > } > > > > + for (i =3D ETH_RSS_RETA_SIZE_128; i < reta_size; i +=3D > IXGBE_4_BIT_WIDTH) { > > + idx =3D i / RTE_RETA_GROUP_SIZE; > > + shift =3D i % RTE_RETA_GROUP_SIZE; > > + mask =3D (uint8_t)((reta_conf[idx].mask >> shift) & > > + IXGBE_4_BIT_MASK); > > + if (!mask) > > + continue; > > + if (mask =3D=3D IXGBE_4_BIT_MASK) > > + r =3D 0; > > + else > > + r =3D IXGBE_READ_REG(hw, > > + IXGBE_ERETA((i - ETH_RSS_RETA_SIZE_128) >> > 2)); > > + for (j =3D 0, reta =3D 0; j < IXGBE_4_BIT_WIDTH; j++) { > > + if (mask & (0x1 << j)) > > + reta |=3D reta_conf[idx].reta[shift + j] << > > + (CHAR_BIT * j); > > + else > > + reta |=3D r & (IXGBE_8_BIT_MASK << > > + (CHAR_BIT * j)); > > + } > > + IXGBE_WRITE_REG(hw, > > + IXGBE_ERETA((i - ETH_RSS_RETA_SIZE_128) >> 2), reta); > > + } > > + >=20 > Is there any good reason to create a second loop and duplicate loops body= ? > Why not just: >=20 > if (reta_size !=3D get_reta_size(hw) {return -EINVAL;} for (i=3D0; I !=3D= reta_size; i+=3D...) > {...} ? Because the different registers are used. I don't want add a judgement in t= he loop. But this's not a performance sensitive scenario, so, It's also OK to merge = them. The same for the similar comments below. >=20 > > return 0; > > } > > > > @@ -3248,11 +3297,26 @@ ixgbe_dev_rss_reta_query(struct rte_eth_dev > *dev, > > struct ixgbe_hw *hw =3D > > IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private); > > > > PMD_INIT_FUNC_TRACE(); > > - if (reta_size !=3D ETH_RSS_RETA_SIZE_128) { > > - PMD_DRV_LOG(ERR, "The size of hash lookup table configured > " > > - "(%d) doesn't match the number hardware can > supported " > > - "(%d)\n", reta_size, ETH_RSS_RETA_SIZE_128); > > - return -EINVAL; > > + switch (hw->mac.type) { > > + case ixgbe_mac_X550: > > + case ixgbe_mac_X550EM_x: > > + if (reta_size !=3D ETH_RSS_RETA_SIZE_512) { > > + PMD_DRV_LOG(ERR, "The size of hash lookup table " > > + " configured (%d) doesn't match the " > > + "number hardware can supported > (%d)\n", > > + reta_size, ETH_RSS_RETA_SIZE_512); > > + return -EINVAL; > > + } > > + break; > > + default: > > + if (reta_size !=3D ETH_RSS_RETA_SIZE_128) { > > + PMD_DRV_LOG(ERR, "The size of hash lookup table " > > + " configured (%d) doesn't match the " > > + "number hardware can supported > (%d)\n", > > + reta_size, ETH_RSS_RETA_SIZE_128); > > + return -EINVAL; > > + } > > + break; > > } > > > > for (i =3D 0; i < ETH_RSS_RETA_SIZE_128; i +=3D IXGBE_4_BIT_WIDTH) { = @@ > > -3272,6 +3336,24 @@ ixgbe_dev_rss_reta_query(struct rte_eth_dev *dev, > > } > > } > > > > + for (i =3D ETH_RSS_RETA_SIZE_128; i < reta_size; i +=3D > IXGBE_4_BIT_WIDTH) { > > + idx =3D i / RTE_RETA_GROUP_SIZE; > > + shift =3D i % RTE_RETA_GROUP_SIZE; > > + mask =3D (uint8_t)((reta_conf[idx].mask >> shift) & > > + IXGBE_4_BIT_MASK); > > + if (!mask) > > + continue; > > + > > + reta =3D IXGBE_READ_REG(hw, > > + IXGBE_ERETA((i - ETH_RSS_RETA_SIZE_128) >> > 2)); > > + for (j =3D 0; j < IXGBE_4_BIT_WIDTH; j++) { > > + if (mask & (0x1 << j)) > > + reta_conf[idx].reta[shift + j] =3D > > + ((reta >> (CHAR_BIT * j)) & > > + IXGBE_8_BIT_MASK); > > + } > > + } > > + >=20 > Same as above - don't see any need to create an extra loop with identical= body. > Pls merge them into one. >=20 > > return 0; > > } > > > > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c > > b/drivers/net/ixgbe/ixgbe_rxtx.c index a598a72..a746ae7 100644 > > --- a/drivers/net/ixgbe/ixgbe_rxtx.c > > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c > > @@ -2790,7 +2790,7 @@ ixgbe_rss_configure(struct rte_eth_dev *dev) { > > struct rte_eth_rss_conf rss_conf; > > struct ixgbe_hw *hw; > > - uint32_t reta; > > + uint32_t reta =3D 0; > > uint16_t i; > > uint16_t j; > > > > @@ -2802,8 +2802,7 @@ ixgbe_rss_configure(struct rte_eth_dev *dev) > > * The byte-swap is needed because NIC registers are in > > * little-endian order. > > */ > > - reta =3D 0; >=20 > What was wrong with that one? I just init it where it's defined. >=20 > > - for (i =3D 0, j =3D 0; i < 128; i++, j++) { > > + for (i =3D 0, j =3D 0; i < ETH_RSS_RETA_SIZE_128; i++, j++) { > > if (j =3D=3D dev->data->nb_rx_queues) > > j =3D 0; > > reta =3D (reta << 8) | j; > > @@ -2812,6 +2811,19 @@ ixgbe_rss_configure(struct rte_eth_dev *dev) > > rte_bswap32(reta)); > > } > > > > + if ((hw->mac.type =3D=3D ixgbe_mac_X550) || > > + (hw->mac.type =3D=3D ixgbe_mac_X550EM_x)) { > > + for (i =3D 0, j =3D 0; i < (ETH_RSS_RETA_SIZE_512 - > ETH_RSS_RETA_SIZE_128); > > + i++, j++) { > > + if (j =3D=3D dev->data->nb_rx_queues) > > + j =3D 0; > > + reta =3D (reta << 8) | j; > > + if ((i & 3) =3D=3D 3) > > + IXGBE_WRITE_REG(hw, IXGBE_ERETA(i >> 2), > > + rte_bswap32(reta)); > > + } > > + } > > + >=20 > Same as above. > Seems no need to have 2 identical loops, pls merge into one. >=20 > Konstantin >=20 > > /* > > * Configure the RSS key and the RSS protocols used to compute > > * the RSS hash of input packets. > > -- > > 1.9.3