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 F13F0A491 for ; Sun, 25 Mar 2018 20:20:00 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2018 11:19:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,361,1517904000"; d="scan'208";a="185882256" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga004.jf.intel.com with ESMTP; 25 Mar 2018 11:19:58 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.37]) by IRSMSX104.ger.corp.intel.com ([169.254.5.171]) with mapi id 14.03.0319.002; Sun, 25 Mar 2018 19:19:58 +0100 From: "Chilikin, Andrey" To: "Richardson, Bruce" , "Hanoch Haim (hhaim)" CC: "Yigit, Ferruh" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] i40e mbuf->rss indication Thread-Index: AdPBRQrucDZfeSBkRGa2KOwaLov0vwAjMLuAAABmEwAAAR01AAABMhIAAAMcK4AAnvzasA== Date: Sun, 25 Mar 2018 18:19:57 +0000 Message-ID: References: <782383cd531a4248a3634705f46d8acf@XCH-RTP-017.cisco.com> <20180322113457.GB608@bricha3-MOBL.ger.corp.intel.com> <856b65d4-a35f-3b2e-73d4-dbfdf105b9c6@intel.com> <20180322142133.GA7112@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20180322142133.GA7112@bricha3-MOBL.ger.corp.intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjIxNzIyYTAtOTk3OS00YTE5LWI5MjQtYWQ3MjI1OTEzMWMzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Imw3K3NqNVFzbXhKdnBCRzNYUHVCWVBVTndYelFFVnBwelprc3BzdzhcL20wPSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] i40e mbuf->rss indication 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: Sun, 25 Mar 2018 18:20:01 -0000 Hi Hanoh, Could you please explain what do you mean by *wrong hash value*? i40e calculates hash value for TCP/UDP using 4-tuple: L3 source/destination= addresses and L4 source/destination ports. It does not use IP protocol, as= TCP and UDP already separated to different PCTYPEs at HW level. Could this= be the root cause of the problem you are seeing? Regards, Andrey > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > Sent: Thursday, March 22, 2018 2:22 PM > To: Hanoch Haim (hhaim) > Cc: Yigit, Ferruh ; dev@dpdk.org > Subject: Re: [dpdk-dev] i40e mbuf->rss indication >=20 > On Thu, Mar 22, 2018 at 12:52:30PM +0000, Hanoch Haim (hhaim) wrote: > > Hi, > > I think this is not the vector driver because I'm user scatter/gather > > >=20 > Vector driver has supported multi-buffer packets for a while now, so it > should be used for packet RX in i40e in just about all cases. >=20 > If possible, could you check if adjusting the setting for 16B/32B > descriptors in the build-time config makes a difference. For 16B > descriptors the flow director ID and RSS hash share a field in the > descriptor, while they don't with 32B versions (though the vector driver > only ever reads the first 16B of each descriptor in any case). >=20 > /Bruce >=20 > > Thanks, > > Hanoh > > > > > > -----Original Message----- > > From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] > > Sent: Thursday, March 22, 2018 2:18 PM > > To: Hanoch Haim (hhaim); Bruce Richardson > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] i40e mbuf->rss indication > > > > On 3/22/2018 11:46 AM, Hanoch Haim (hhaim) wrote: > > > Driver: i40e > > > > > > DPDK : 17.11 > > > > > > Configuration : > > > > > > 1) RSS configuration > > > rxmode.mq_mode =3D ETH_MQ_RX_RSS; > > > rss->rss_hf =3D ETH_RSS_UDP | ETH_RSS_TCP; > > > rss->rss_key =3D Microsoft key > > > rss->rss_key_len =3D 52 > > > > > > *configure RETA to some rx-queues > > > > > > 2) Change hash to TOEPLITZ (only for i40e) > > > > > > struct rte_eth_hash_filter_info info =3D {}; > > > info.info_type =3D RTE_ETH_HASH_FILTER_GLOBAL_CONFIG; > > > info.info.global_conf.hash_func =3D > RTE_ETH_HASH_FUNCTION_TOEPLITZ; > > > rte_eth_dev_filter_ctrl(m_repid, > > > RTE_ETH_FILTER_HASH, > > > RTE_ETH_FILTER_SET, &info); > > > > > > 3) Configure some flow-director rules > > > > > > 4) TCP/UDP packets are received to the *right* core (based on a SW > Toeplitz calculation +reta table) however > > > The reported rss value is *wrong* in the mbuf > > > (m->hash.rss =3D=3D *wrong value*) > > > > Are you getting same result with both scalar and vector driver? > > > > > ((m->ol_flags&PKT_RX_RSS_HASH) =3D=3D PKT_RX_RSS_HASH > > > > > > 5) The above works fine for mlx5 and ixgbe > > > > > > 6) I suspect the hash is something else, maybe flow-director id or xo= r > hash .. > > > > > > Wanted to know if this is a known issue. I can provide a simple way t= o > reproduce it using TRex > > > > > > Thanks, > > > Hanoh > > > > > > > > > -----Original Message----- > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > Sent: Thursday, March 22, 2018 1:35 PM > > > To: Hanoch Haim (hhaim) > > > Cc: dev@dpdk.org > > > Subject: Re: [dpdk-dev] i40e mbuf->rss indication > > > > > > On Wed, Mar 21, 2018 at 06:47:22PM +0000, Hanoch Haim (hhaim) wrote: > > >> Hi All, > > >> DPDK:17.11 > > >> When i40e is configured with RSS enabled and hash.type=3Dtoeplitz > > >> > > >> m->hash.rss =3D some weird number > > >> ((m->ol_flags&PKT_RX_RSS_HASH) =3D=3D PKT_RX_RSS_HASH > > >> > > >> The hash value is correct and match the MS Toeplitz standard. > > >> > > >> Is this expected? > > > > > > I'm sorry, but I don't quite follow the question, or the problem. Are= you > meaning to say that the hash value is incorrect, or that the flag is not = being > set or something else? > > > > > > /Bruce > > > > > >> > > >> The above works fine with ixgbe/mlx5 > > >> > > >> Thanks, > > >> Hanoh > > >> > >