DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wei Hu (Xavier)" <huwei013@chinasoftinc.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: <dev@dpdk.org>, Wenzhuo Lu <wenzhuo.lu@intel.com>,
	Beilei Xing <beilei.xing@intel.com>,
	Bernard Iremonger <bernard.iremonger@intel.com>,
	<xavier.huwei@huawei.com>, <lihuisong@huawei.com>,
	Pavan Nikhilesh <pbhagavatula@marvell.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [PATCH 1/2] app/testpmd: update Rx RSS HASH offload when setting MQ RSS
Date: Mon, 28 Sep 2020 20:27:32 +0800	[thread overview]
Message-ID: <dd434230-1bf9-bb81-b568-ff96c2f7d1c8@chinasoftinc.com> (raw)
In-Reply-To: <02fd6a3c-3810-fbb6-f51d-7c29fc26bfed@intel.com>

Hi, Ferruh Yigit

On 2020/9/23 17:35, Ferruh Yigit wrote:
> On 9/23/2020 8:04 AM, Wei Hu (Xavier) wrote:
>> Hi, Ferruh Yigit
>>
>> On 2020/9/23 0:21, Ferruh Yigit wrote:
>>> On 9/8/2020 3:16 AM, Wei Hu (Xavier) wrote:
>>>> From: Huisong Li <lihuisong@huawei.com>
>>>>
>>>> Currently, when starting testpmd application without 
>>>> '--disable-rss' and
>>>> the number of Rx queue configured is greater than 1, ETH_MQ_RX_RSS 
>>>> flag
>>>> is set in port->dev_conf.rxmode.mq_mode in testpmd application, and
>>>> DEV_RX_OFFLOAD_RSS_HASH flag is set in rx_offloads
>>>> (dev->data->dev_conf.rxmode.offloads) according to the ETH_MQ_RX_RSS
>>>> flag of rxmode.mq_mode in PMD drivers.
>>>>
>>>> However, DEV_RX_OFFLOAD_RSS_HASH is not set to rx_offloads maintained
>>>> in testpmd application, this will cause the inconsistent problem that
>>>> rx_offloads is different for testpmd and PMD drivers.
>>>
>>> Yes for DEV_RX_OFFLOAD_RSS_HASH, application rx_offload config and 
>>> PMD one diverges, for *some* PMDs.
>>>
>>> This is done to have the backward compatibility of the PMD behavior.
>>>
>>> The PMDs that would like to write the provide the calculated hash 
>>> value back, overwrites the offload config to enable 
>>> 'DEV_RX_OFFLOAD_RSS_HASH'. And does more work than user requested, 
>>> this shouldn't have any side affect.
>>> Some doesn't provide the hash unless user explicitly requests it.
>>>
>>> Applications shouldn't set it blindly, at least first check if PMD 
>>> supports it but even that case, unless it is needed I think HASH 
>>> offload shouldn't be requested by default.
>>
>> OK, we are going to do modification to add check if PMD support 
>> DEV_RX_OFFLOAD_RSS_HASH before setting it as below:
>>
>>   @@ -3356,11 +3356,13 @@ init_port_config(void)
>>             }
>>             if (port->dcb_flag == 0) {
>>                if (port->dev_conf.rx_adv_conf.rss_conf.rss_hf != 0) {
>>                     port->dev_conf.rxmode.mq_mode =
>>                         (enum rte_eth_rx_mq_mode)
>>                             (rx_mq_mode & ETH_MQ_RX_RSS);
>>             if (port->dev_info.rx_offload_capa &
>>                DEV_RX_OFFLOAD_RSS_HASH)
>>               port->dev_conf.rxmode.offloads |=
>>                          DEV_RX_OFFLOAD_RSS_HASH;
>>               } else
>>                     port->dev_conf.rxmode.mq_mode = ETH_MQ_RX_NONE;
>>             }
>>
>
> Hi Xavier,
>
> The capability check is correct thing to do, but even in that case I 
> am not sure if we should set the config by default.
>
> The reason to extract the 'DEV_RX_OFFLOAD_RSS_HASH' offload is to gain 
> performance for some NICs, enabling it by default defeats the purpose.
>
> The offload should be enabled when application needs the provided hash 
> value.
>
> I can see you are trying to remove the divergence between PMD and 
> application config, this can be fixed when all PMDs take this user 
> offload request into account instead of overwriting, but for some PMDs 
> it is cheaper to provide the hash value instead of checks, so this 
> divergence is not easy to address.
>
OK, please ignore this patch and the V2 patch.

http://patches.dpdk.org/patch/78502/

Thanks.


Regards

Xavier


  reply	other threads:[~2020-09-28 12:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08  2:16 [dpdk-dev] [PATCH 0/2] updates for testpmd Wei Hu (Xavier)
2020-09-08  2:16 ` [dpdk-dev] [PATCH 1/2] app/testpmd: update Rx RSS HASH offload when setting MQ RSS Wei Hu (Xavier)
2020-09-22 16:21   ` Ferruh Yigit
2020-09-23  7:04     ` Wei Hu (Xavier)
2020-09-23  9:35       ` Ferruh Yigit
2020-09-28 12:27         ` Wei Hu (Xavier) [this message]
2020-09-08  2:16 ` [dpdk-dev] [PATCH 2/2] app/testpmd: retain original FDIR mode when configuring DCB Wei Hu (Xavier)
2020-09-22  5:15   ` Ajit Khaparde
2020-09-23  7:14     ` Wei Hu (Xavier)
2020-09-24  2:41       ` Wei Hu (Xavier)
2020-09-23  7:51 ` [dpdk-dev] [PATCH v2] app/testpmd: update Rx RSS HASH offload when setting MQ RSS Wei Hu (Xavier)

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=dd434230-1bf9-bb81-b568-ff96c2f7d1c8@chinasoftinc.com \
    --to=huwei013@chinasoftinc.com \
    --cc=arybchenko@solarflare.com \
    --cc=beilei.xing@intel.com \
    --cc=bernard.iremonger@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=lihuisong@huawei.com \
    --cc=pbhagavatula@marvell.com \
    --cc=wenzhuo.lu@intel.com \
    --cc=xavier.huwei@huawei.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).