From: Ferruh Yigit <ferruh.yigit@intel.com>
To: oulijun <oulijun@huawei.com>,
wenzhuo.lu@intel.com, beilei.xing@intel.com,
adrien.mazarguil@6wind.com
Cc: dev@dpdk.org, linuxarm@huawei.com, Ori Kam <orika@nvidia.com>
Subject: Re: [dpdk-dev] [PATCH v4] app/testpmd: fix the default RSS key configuration
Date: Fri, 9 Oct 2020 19:54:23 +0100 [thread overview]
Message-ID: <df9b6507-89cf-5f7b-dbbb-823fef991cf6@intel.com> (raw)
In-Reply-To: <51baf0aa-9e26-56c3-569f-91cc846f8caa@intel.com>
On 10/9/2020 7:27 PM, Ferruh Yigit wrote:
> On 10/9/2020 12:55 PM, oulijun wrote:
>>
>>
>> 在 2020/9/30 20:57, Ferruh Yigit 写道:
>>> On 9/24/2020 2:45 PM, Lijun Ou wrote:
>>>> It use the NIC valid default RSS key instead of the testpmd
>>>> dummy RSS key in the flow configuration when the RSS key is
>>>> not specified in the flow rule. If the NIC RSS key is
>>>> invalid, it will use testpmd dummy RSS key as the default
>>>> key.
>>>
>>> Can you please describe the impact, what fails without this fix?
>>>
>> Hi, Ferruh
>> According to Phil Yang's suggestion, I've put the impact description in the
>> cover letter.
>> When a user runs a flow create cmd to configure an RSS rule
>> with specifying the empty rss actions in testpmd, this mean
>> that the flow gets the default RSS functions from the valid
>> NIC default RSS hash key. However, the testpmd is not set
>> the default RSS key incorrectly when RSS key is not specified
>> in flow create cmd.
>> After the testpmd is started, run the flow create cmd without specifying
>> the RSS hash key. Ensure that RSS hash key queried after
>> the RSS flow is configured is the same as the default key after the
>> testpmd is start.
>>
>>>>
>>>> Fixes: ac8d22de2394 ("ethdev: flatten RSS configuration in flow API")
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>> ---
>>>> V3->V4:
>>>> -fix checkpatch warning and shorter commit content.
>>>>
>>>> V2->V3:
>>>> -fix checkpatch warning.
>>>>
>>>> V1->V2:
>>>> -fix the commit.
>>>> ---
>>>> app/test-pmd/cmdline_flow.c | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
>>>> index 6263d30..e6648da 100644
>>>> --- a/app/test-pmd/cmdline_flow.c
>>>> +++ b/app/test-pmd/cmdline_flow.c
>>>> @@ -4312,6 +4312,7 @@ parse_vc_action_rss(struct context *ctx, const struct
>>>> token *token,
>>>> action_rss_data->queue[i] = i;
>>>> if (!port_id_is_invalid(ctx->port, DISABLED_WARN) &&
>>>> ctx->port != (portid_t)RTE_PORT_ALL) {
>>>> + struct rte_eth_rss_conf rss_conf = {0};
>>>> struct rte_eth_dev_info info;
>>>> int ret2;
>>>> @@ -4322,6 +4323,13 @@ parse_vc_action_rss(struct context *ctx, const struct
>>>> token *token,
>>>> action_rss_data->conf.key_len =
>>>> RTE_MIN(sizeof(action_rss_data->key),
>>>> info.hash_key_size);
>>>> +
>>>> + rss_conf.rss_key_len = sizeof(action_rss_data->key);
>>>> + rss_conf.rss_key = action_rss_data->key;
>>>
>>> 'rss_conf.rss_key_len' is the input parameter, it looks like it has been used
>>> as the size of the 'rss_key', but as far as I can see it is not.
>>>
>> Yes, rss_key_len and rss_key is configured independently. In fact, when the
>> user configures the rss_key, we should know rss_key_len.
>>> Because of this if 'info.hash_key_size' is bigger than
>>> 'sizeof(action_rss_data->key)', won't PMD overwrite the stack for the
>>> remaining bytes?
>> if info.hash_key_size and action_rss_data->key is set used RSS flow cmd when
>> info.hash_key_size is bigger than sizeof(action_rss_data->key), the driver
>> will return an error.
> >
>
> How can driver return an error?
> Both 'rss_conf.rss_key_len' & 'rss_conf.rss_key' filled by driver, and driver
> expect 'rss_conf.rss_key' is big enough to hold its key.
> Here 'rss_conf.rss_key' points to fixed size 'action_rss_data->key' array
> without checking the driver key length.
>
> Where this driver check happens, am I missing it?
>
>>>
>>> Can you please check?
>>>
>>>> + ret2 = rte_eth_dev_rss_hash_conf_get(ctx->port, &rss_conf);
>>>> + if (ret2 != 0)
>>>> + return ret2;
>>>
>>> If PMD not implemented the 'rss_hash_conf_get' dev_ops, should it fail the
>>> RSS action?
>> Yes, When the RSS hash key is not specified in the RSS flow, ensure that the
>> RSS hash key remains unchanged and is the same as that configured in the
>> hardware when the testpmd is started.
>
> OK, but this means any PMD not implemented dev_ops to get RSS key won't able to
> use rte flow RSS action via testpmd, not sure if this is right.
>
> What this patch does is read the device configured RSS key, and feed it back to
> rte flow RSS action, to be sure device key is not changed.
>
> Instead, can we update the rte flow RSS action to not change the key if it is
> not provided, and don't provide one in the testpmd by default.
>
> What do you think?
>
cc'ed Ori for the rte flow related change suggestion.
@Ori, can you please check the problem this patch address and the suggestion above?
next prev parent reply other threads:[~2020-10-09 18:54 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 1:51 [dpdk-dev] [PATCH v3] " Lijun Ou
2020-09-22 9:51 ` Phil Yang
2020-09-22 13:50 ` oulijun
2020-09-22 15:44 ` Phil Yang
2020-09-24 13:45 ` [dpdk-dev] [PATCH v4] RSS key use with testpmd Lijun Ou
2020-09-24 13:45 ` [dpdk-dev] [PATCH v4] app/testpmd: fix the default RSS key configuration Lijun Ou
2020-09-29 15:35 ` Phil Yang
2020-09-30 12:57 ` Ferruh Yigit
2020-10-09 11:55 ` oulijun
2020-10-09 18:27 ` Ferruh Yigit
2020-10-09 18:54 ` Ferruh Yigit [this message]
2020-09-30 13:36 ` Ferruh Yigit
2020-10-09 11:59 ` oulijun
2020-10-09 18:36 ` Ferruh Yigit
2020-10-15 12:41 ` [dpdk-dev] [PATCH v5] " Lijun Ou
2020-10-15 13:52 ` Ferruh Yigit
2020-10-15 14:04 ` oulijun
2020-10-15 14:43 ` Ferruh Yigit
2020-10-15 16:05 ` Ferruh Yigit
2020-10-15 23:21 ` Ophir Munk
2020-10-15 23:53 ` Ferruh Yigit
2020-10-16 0:14 ` Ajit Khaparde
2020-10-16 6:46 ` Ophir Munk
2020-10-16 10:05 ` oulijun
2020-10-16 15:13 ` Ophir Munk
2020-10-16 10:04 ` oulijun
2020-10-16 10:57 ` Ferruh Yigit
2020-10-16 14:59 ` Ophir Munk
2020-10-20 9:00 ` oulijun
2020-10-20 10:02 ` Ferruh Yigit
2020-10-20 13:35 ` oulijun
2020-10-20 14:34 ` Ferruh Yigit
2020-10-21 8:19 ` oulijun
2020-10-21 9:38 ` Ferruh Yigit
2020-10-21 10:07 ` oulijun
[not found] ` <20201015195637.26476-1-robot@bytheb.org>
2020-10-16 9:39 ` [dpdk-dev] |WARNING| pw80899 " oulijun
2020-10-16 9:41 ` David Marchand
2020-09-30 13:17 ` [dpdk-dev] [PATCH v4] RSS key use with testpmd Ferruh Yigit
2020-10-09 12:09 ` oulijun
2020-10-09 18:52 ` Ferruh Yigit
2020-10-10 3:07 ` Phil Yang
2020-10-14 6:15 ` oulijun
2020-10-14 8:41 ` Ferruh Yigit
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=df9b6507-89cf-5f7b-dbbb-823fef991cf6@intel.com \
--to=ferruh.yigit@intel.com \
--cc=adrien.mazarguil@6wind.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=linuxarm@huawei.com \
--cc=orika@nvidia.com \
--cc=oulijun@huawei.com \
--cc=wenzhuo.lu@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).