DPDK patches and discussions
 help / color / mirror / Atom feed
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?


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