DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Hanoch Haim (hhaim)" <hhaim@cisco.com>
To: "Chilikin, Andrey" <andrey.chilikin@intel.com>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] i40e mbuf->rss indication
Date: Sun, 25 Mar 2018 21:54:55 +0000	[thread overview]
Message-ID: <B6CC7756-16FD-46DD-8FEA-769E278D20D4@cisco.com> (raw)
In-Reply-To: <AAC06825A3B29643AF5372F5E0DDF0538DDAF214@IRSMSX106.ger.corp.intel.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



      reply	other threads:[~2018-03-25 21:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 18:47 Hanoch Haim (hhaim)
2018-03-22 11:34 ` Bruce Richardson
2018-03-22 11:46   ` Hanoch Haim (hhaim)
2018-03-22 12:18     ` Ferruh Yigit
2018-03-22 12:52       ` Hanoch Haim (hhaim)
2018-03-22 14:21         ` Bruce Richardson
2018-03-25 18:19           ` Chilikin, Andrey
2018-03-25 21:54             ` Hanoch Haim (hhaim) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B6CC7756-16FD-46DD-8FEA-769E278D20D4@cisco.com \
    --to=hhaim@cisco.com \
    --cc=andrey.chilikin@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).