Re: [dpdk-dev] i40e mbuf->rss indication

["Hanoch Haim (hhaim)" <hhaim@cisco.com>]

Hi Andrey,

The ML specification is clear. The key is defined and work the same for all driver.
My point is that the RSS result (Rx-queue) is *correct* but the 32bit intermediate hash value that is reported in the descriptor is not correct. The hash value reside in the first 16B.
I can send how to reproduce this if needed.It might be related to flow-director configuration I have.

Thanks,
Hanoh
Sent from my iPhone

On 25 Mar 2018, at 11:20, Chilikin, Andrey <andrey.chilikin@intel.com<mailto:andrey.chilikin@intel.com>> wrote:

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) <hhaim@cisco.com<mailto:hhaim@cisco.com>>
Cc: Yigit, Ferruh <ferruh.yigit@intel.com<mailto:ferruh.yigit@intel.com>>; dev@dpdk.org<mailto:dev@dpdk.org>
Subject: Re: [dpdk-dev] i40e mbuf->rss indication

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


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.

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).

/Bruce

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<mailto: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 = ETH_MQ_RX_RSS;
      rss->rss_hf = ETH_RSS_UDP | ETH_RSS_TCP;
      rss->rss_key = Microsoft key
      rss->rss_key_len = 52

      *configure RETA to some rx-queues

2)        Change hash to TOEPLITZ (only for i40e)

         struct rte_eth_hash_filter_info info = {};
         info.info_type = RTE_ETH_HASH_FILTER_GLOBAL_CONFIG;
         info.info.global_conf.hash_func =
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 == *wrong value*)

Are you getting same result with both scalar and vector driver?

 ((m->ol_flags&PKT_RX_RSS_HASH) == 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 xor
hash ..

Wanted to know if this is a known issue. I can provide a simple way to
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<mailto: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=toeplitz

m->hash.rss = some weird number
((m->ol_flags&PKT_RX_RSS_HASH) == 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