DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: oulijun <oulijun@huawei.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	thomas@monjalon.net
Cc: dev@dpdk.org, linuxarm@huawei.com
Subject: Re: [dpdk-dev] [PATCH] ethdev: check for Rx RSS distribution and RSS hash
Date: Fri, 1 May 2020 17:04:21 +0100	[thread overview]
Message-ID: <e5b4944e-4979-148e-4b21-0343ceb62e61@intel.com> (raw)
In-Reply-To: <7be2b2bb-80d4-aa45-b018-0e3dffc7a8fb@intel.com>

On 4/29/2020 1:42 PM, Ferruh Yigit wrote:
> On 4/29/2020 7:41 AM, oulijun wrote:
>>
>>
>> 在 2020/4/27 21:27, Ferruh Yigit 写道:
>>> On 4/27/2020 1:49 PM, Andrew Rybchenko wrote:
>>>> On 4/27/20 3:34 PM, Lijun Ou wrote:
>>>>> When rte api checks the Rx RSS distribution is enable but the RSS
>>>>> hash is disabled, it will return an error.
>>>>>
>>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>>> ---
>>>>>   lib/librte_ethdev/rte_ethdev.c | 11 +++++++++++
>>>>>   1 file changed, 11 insertions(+)
>>>>>
>>>>> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
>>>>> index 0854ef8..07734c4 100644
>>>>> --- a/lib/librte_ethdev/rte_ethdev.c
>>>>> +++ b/lib/librte_ethdev/rte_ethdev.c
>>>>> @@ -1411,6 +1411,17 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
>>>>>   		goto rollback;
>>>>>   	}
>>>>>   
>>>>> +	/* Check if Rx RSS distribution is enable but RSS hash is disabled. */
>>>>> +	if (((dev_conf->rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG) != 0) &&
>>>>> +	    !(dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_RSS_HASH)) {
>>>>> +		RTE_ETHDEV_LOG(ERR,
>>>>> +			"Ethdev port_id=%u config valid Rx mq_mode with RSS but %s offload is no-requested\n",
>>>>> +			port_id,
>>>>> +			rte_eth_dev_rx_offload_name(DEV_RX_OFFLOAD_RSS_HASH));
>>>>> +		ret = -EINVAL;
>>>>> +		goto rollback;
>>>>> +	}
>>>>> +
>>>>>   	/*
>>>>>   	 * Setup new number of RX/TX queues and reconfigure device.
>>>>>   	 */
>>>>
>>>> NACK. It is perfectly fine to do distribution, but do not need RSS hash
>>>> information.
>>>>   - ETH_MQ_RX_RSS_FLAG controls RSS hash calculation and distribution
>>>>   - DEV_RX_OFFLOAD_RSS_HASH controls delivery of the hash value
>>>>     itself from HW to SW
>>>>
>>>
>>> Hi Lijun,
>>>
>>> As Andrew described, now 'DEV_RX_OFFLOAD_RSS_HASH' controls to copy calculated
>>> hash value to 'mbuf::hash::rss' or not. When rss hash copied to mubf,
>>> 'PKT_RX_RSS_HASH' flag of 'mbuf::ol_flags' set to notify the application that
>>> hash value is valid. This was a performance optimization.
>>>
>> if the user is not configure the DEV_RX_OFFLOAD_RSS_HASH and the users 
>> add the ETH_MQ_RX_RSS_FLAG, as a result, the hardware has calculated the 
>> hash result and distributed, the mbuf::o1_flags have set the 
>> PKT_RX_RSS_HASH and the mbuf::hash::rss have set the hash result. What 
>> are the advantage of this configuration with DEV_RX_OFFLOAD_RSS_HASH?
> 
> If 'DEV_RX_OFFLOAD_RSS_HASH' NOT set, but 'ETH_MQ_RX_RSS_FLAG' set, RSS should
> work as expected but 'mbuf::hash::rss' not filled.
> 
> This is optimization for the case user doesn't need the calculated hash value,
> and seems this optimization has bigger affect in some NICs that pays some cost
> to receive the HW calculated hash values.
> 
> User requesting 'DEV_RX_OFFLOAD_RSS_HASH' offload should enable driver to update
> 'mbuf::hash::rss' and 'PKT_RX_RSS_HASH' in 'mbuf::ol_flags' addition to RSS feature.

I hope this is clear now, and back to my first point if you think above behavior
is not clear in the doc or API comments, can you please send a patch to clarify
it better?

Thanks,
ferruh

> 
>>
>> Can I understand it this way, If the user does not apply this rss hash, 
>> does it mean that rss cannot be used to improve performance, even if the 
>> hardware has calculated the rss hash result?
> 
> If 'DEV_RX_OFFLOAD_RSS_HASH' is NOT set, application won't able to receive the
> HW calculated hash values.
> 
>>> We know above because we were involved in development of it, if this is not
>>> clean for third party, can you please amend your patch to clarify above behavior?
>>>
>>> Thanks,
>>> ferruh
>>>
>>> .
>>>
>>
> 


  reply	other threads:[~2020-05-01 16:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 12:34 Lijun Ou
2020-04-27 12:49 ` Andrew Rybchenko
2020-04-27 13:27   ` Ferruh Yigit
2020-04-29  6:41     ` oulijun
2020-04-29 12:42       ` Ferruh Yigit
2020-05-01 16:04         ` Ferruh Yigit [this message]
2020-04-29  6:31   ` oulijun

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=e5b4944e-4979-148e-4b21-0343ceb62e61@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=linuxarm@huawei.com \
    --cc=oulijun@huawei.com \
    --cc=thomas@monjalon.net \
    /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).