patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: "lihuisong (C)" <lihuisong@huawei.com>,
	Ferruh Yigit <ferruh.yigit@xilinx.com>,
	Xiaoyun Li <xiaoyun.li@intel.com>,
	Aman Singh <aman.deep.singh@intel.com>,
	Yuying Zhang <yuying.zhang@intel.com>,
	Helin Zhang <helin.zhang@intel.com>,
	Jingjing Wu <jingjing.wu@intel.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org, Thomas Monjalon <thomas@monjalon.net>, stable@dpdk.org
Subject: Re: [PATCH 1/3] app/testpmd: fix displaying RSS info
Date: Tue, 31 May 2022 19:35:22 +0300	[thread overview]
Message-ID: <ab281bdc-c594-7b3a-2afa-6e725359faa8@oktetlabs.ru> (raw)
In-Reply-To: <a1138f54-6950-d3f7-6d19-134b5e68411a@huawei.com>

On 5/31/22 05:07, lihuisong (C) wrote:
> 
> 在 2022/5/30 21:02, Ferruh Yigit 写道:
>> On 5/30/2022 1:32 PM, lihuisong (C) wrote:
>>> CAUTION: This message has originated from an External Source. Please 
>>> use proper judgment and caution when opening attachments, clicking 
>>> links, or responding to this email.
>>>
>>>
>>> 在 2022/5/30 18:43, Ferruh Yigit 写道:
>>>> On 5/27/2022 3:30 AM, lihuisong (C) wrote:
>>>>> CAUTION: This message has originated from an External Source. Please
>>>>> use proper judgment and caution when opening attachments, clicking
>>>>> links, or responding to this email.
>>>>>
>>>>>
>>>>> 在 2022/5/26 1:37, Ferruh Yigit 写道:
>>>>>> When supported RSS offload flow types are printed via 'show port
>>>>>> info #'
>>>>>> command, flow names are get from flow type array which is wrong and
>>>>>> causing some RSS flow types not being displayed.
>>>>>>
>>>>>> Instead RSS flow type array should be used. Also helper functions 
>>>>>> added
>>>>>> and existing code updated to use helpers.
>>>>>>
>>>>>> Fixes: b12964f621dc ("ethdev: unification of RSS offload types")
>>>>>> Cc: stable@dpdk.org
>>>>>>
>>>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@xilinx.com>
>>>>>> ---
>>>>>> Cc: helin.zhang@intel.com
>>>>>>
>>>>>> Note:
>>>>>> In ethdev, flow type macros 'RTE_ETH_FLOW_*' and RSS type macros
>>>>>> 'RTE_ETH_RSS_*' are related, buy they seems diverged a little, may 
>>>>>> need
>>>>>> to check that too.
>>>>>> ---
>>>>>>   app/test-pmd/config.c | 92
>>>>>> ++++++++++++++++++++++++++++++-------------
>>>>>>   1 file changed, 64 insertions(+), 28 deletions(-)
>>>>>>
>>>>>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
>>>>>> index 72d2606d19d5..c353d224ef06 100644
>>>>>> --- a/app/test-pmd/config.c
>>>>>> +++ b/app/test-pmd/config.c
>>>>>> @@ -147,6 +147,32 @@ const struct rss_type_info rss_type_table[] = {
>>>>>>       { NULL, 0 },
>>>>>>   };
>>>>>>
>>>>>> +static const char *
>>>>>> +rsstype_to_str(uint64_t rss_type)
>>>>>> +{
>>>>>> +     int i;
>>>>>> +
>>>>>> +     for (i = 0; rss_type_table[i].str != NULL; i++) {
>>>>>> +             if (rss_type_table[i].rss_type == rss_type)
>>>>>> +                     return rss_type_table[i].str;
>>>>>> +     }
>>>>>> +
>>>>>> +     return NULL;
>>>>>> +}
>>>>>> +
>>>>>> +static uint64_t
>>>>>> +str_to_rsstype(const char *str)
>>>>>> +{
>>>>>> +     int i;
>>>>>> +
>>>>>> +     for (i = 0; rss_type_table[i].str != NULL; i++) {
>>>>>> +             if (!strcmp(rss_type_table[i].str, str))
>>>>>> +                     return rss_type_table[i].rss_type;
>>>>>> +     }
>>>>>> +
>>>>>> +     return 0;
>>>>>> +}
>>>>>> +
>>>>>>   static const struct {
>>>>>>       enum rte_eth_fec_mode mode;
>>>>>>       const char *name;
>>>>>> @@ -779,19 +805,21 @@ port_infos_display(portid_t port_id)
>>>>>>       if (!dev_info.flow_type_rss_offloads)
>>>>>>               printf("No RSS offload flow type is supported.\n");
>>>>>>       else {
>>>>>> +             uint64_t rss_types = dev_info.flow_type_rss_offloads;
>>>>>>               uint16_t i;
>>>>>> -             char *p;
>>>>>>
>>>>>>               printf("Supported RSS offload flow types:\n");
>>>>>> -             for (i = RTE_ETH_FLOW_UNKNOWN + 1;
>>>>>> -                  i < sizeof(dev_info.flow_type_rss_offloads) *
>>>>>> CHAR_BIT; i++) {
>>>>>> -                     if (!(dev_info.flow_type_rss_offloads & (1ULL
>>>>>> << i)))
>>>>>> -                             continue;
>>>>>> -                     p = flowtype_to_str(i);
>>>>>> -                     if (p)
>>>>>> -                             printf("  %s\n", p);
>>>>>> -                     else
>>>>>> -                             printf("  user defined %d\n", i);
>>>>>> +             for (i = 0; rss_types != 0; i++) {
>>>>>> +                     if (rss_types & 1) {
>>>>>> +                             uint64_t rss_type = 1ULL << i;
>>>>>> +                             const char *p = 
>>>>>> rsstype_to_str(rss_type);
>>>>>> +
>>>>>> +                             if (p)
>>>>>> +                                     printf("  %s\n", p);
>>>>>> +                             else
>>>>>> +                                     printf("  user defined
>>>>>> 0x%"PRIx64"\n", rss_type);
>>> Maybe we need to add a mapping table between RSS offload and name for
>>> 'flow_type_rss_offloads'.
>>>>>> +                     }
>>>>>> +                     rss_types >>= 1;
>>>>>>               }
>>>>>>       }
>>>>>>
>>>>>> @@ -1547,6 +1575,7 @@ port_flow_complain(struct rte_flow_error 
>>>>>> *error)
>>>>>>   static void
>>>>>>   rss_config_display(struct rte_flow_action_rss *rss_conf)
>>>>>>   {
>>>>>> +     uint64_t rss_types;
>>>>>>       uint8_t i;
>>>>>>
>>>>>>       if (rss_conf == NULL) {
>>>>>> @@ -1582,16 +1611,23 @@ rss_config_display(struct
>>>>>> rte_flow_action_rss *rss_conf)
>>>>>>       }
>>>>>>
>>>>>>       printf(" types:\n");
>>>>>> -     if (rss_conf->types == 0) {
>>>>>> +     rss_types = rss_conf->types;
>>>>>> +     if (rss_types == 0) {
>>>>>>               printf("  none\n");
>>>>>>               return;
>>>>>>       }
>>>>>> -     for (i = 0; rss_type_table[i].str; i++) {
>>>>>> -             if ((rss_conf->types &
>>>>>> -                 rss_type_table[i].rss_type) ==
>>>>>> -                 rss_type_table[i].rss_type &&
>>>>>> -                 rss_type_table[i].rss_type != 0)
>>>>>> -                     printf("  %s\n", rss_type_table[i].str);
>>>>>> +
>>>>>> +     for (i = 0; rss_types != 0; i++) {
>>>>>> +             if (rss_types & 1) {
>>>>>> +                     uint64_t rss_type = 1ULL << i;
>>>>>> +                     const char *p = rsstype_to_str(rss_type);
>>>>> It seems that we can't use one bit to get rss type name.
>>>>> Because part of name in rss_type_table[] consist of multiple bits.
>>>>> Maybe it's better to use the original method to display RSS type name.
>>>>>
>>>>
>>>> Right, it doesn't cover 'all' case, but thinking twice how useful
>>>> 'all' case is, it doesn't really cover all options, and for user it is
>>>> hard to know which functions are set when it displays 'all'.
>>>> What about to remove 'all' item from 'rss_type_table[]'?
>>> It seems that remove 'all' item isn't the way to resolve this issue.
>>> There are other iterms in 'rss_type_table[], such as, 'ip', 'udp',
>>> 'tcp' and so on. The 'rss_type_table[]' should primarily serve
>>> the "show port rss xxx" and "port confg rss xxx" commands.
>>> They all need these.
>> >
>>
>> You are right, it is not just 'all'.
>>
>>>>
>>>>> On the other hand, RSS type name are printed in many places as this
>>>>> patch modified.
>>>>> It is recommended that you encapsulate a funcion to display RSS type.
>>>>
>>>> Yes but each are formatting slightly different, so to let various
>>>> formatting possible, common function returns string instead of
>>>> printing them. As 3/3 of this set does some formatting.
>>>
>>> We can unify this display if we add the mapping table mentioned above.
>>>
>>
>> If it can be unified, agree that this simplifies the code [2].
> Ack.
>>
>> Both above two changes already exists in your set [1], if you don't 
>> mind to adapt 2/3 & 3/3 of this set into yours, we can continue with 
>> your set, is this OK for you?
> ok. It's my pleasure to work with you.
>>
>>
>>
>> [1]
>> https://patches.dpdk.org/project/dpdk/list/?series=22735
>>
>> [2]
>> In your 'show_rss_types()', it can get additional parameter for 
>> formatting, like after how many items to break to next line, this can 
>> cover existing formatting options, but not sure how elegant a solution 
>> it is.

So, I'm waiting for a new version from lihuisong.

      reply	other threads:[~2022-05-31 16:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-25 17:37 Ferruh Yigit
2022-05-26  3:52 ` lihuisong (C)
2022-05-26  8:56   ` Ferruh Yigit
2022-05-27  2:48     ` lihuisong (C)
2022-05-27  2:30 ` lihuisong (C)
2022-05-30 10:43   ` Ferruh Yigit
2022-05-30 12:32     ` lihuisong (C)
2022-05-30 13:02       ` Ferruh Yigit
2022-05-31  2:07         ` lihuisong (C)
2022-05-31 16:35           ` Andrew Rybchenko [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=ab281bdc-c594-7b3a-2afa-6e725359faa8@oktetlabs.ru \
    --to=andrew.rybchenko@oktetlabs.ru \
    --cc=aman.deep.singh@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@xilinx.com \
    --cc=helin.zhang@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=lihuisong@huawei.com \
    --cc=stable@dpdk.org \
    --cc=thomas.monjalon@6wind.com \
    --cc=thomas@monjalon.net \
    --cc=xiaoyun.li@intel.com \
    --cc=yuying.zhang@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).