DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Min Hu (Connor)" <humin29@huawei.com>,
	"lihuisong (C)" <lihuisong@huawei.com>
Cc: Ori Kam <orika@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Qi Zhang <qi.z.zhang@intel.com>,
	Olivier Matz <olivier.matz@6wind.com>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Slava Ovsiienko <viacheslavo@nvidia.com>,
	huangdaode <huangdaode@huawei.com>
Subject: Re: [PATCH 2/6] net/hns3: fix inconsistent enabled RSS behavior
Date: Tue, 22 Mar 2022 18:13:32 +0100	[thread overview]
Message-ID: <8080441.NyiUUSuA9g@thomas> (raw)
In-Reply-To: <03375cab-d228-50bf-7005-06fc718c63e9@huawei.com>

21/03/2022 08:14, lihuisong (C):
> 2022/3/10 16:08, lihuisong (C):
> > 2022/3/9 17:55, Ori Kam:
> >> From: lihuisong (C) <lihuisong@huawei.com>
> >>> 2022/3/3 10:47, lihuisong (C):
> >>>> 2022/3/2 22:07, Ori Kam:
> >>>>> From: lihuisong (C) <lihuisong@huawei.com>
> >>>>>> 2022/3/1 0:42, Ferruh Yigit:
> >>>>>>> On 2/28/2022 3:21 AM, Min Hu (Connor) wrote:
> >>>>>>>> From: Huisong Li <lihuisong@huawei.com>
> >>>>>>>>
> >>>>>>>> RSS will not be enabled if the RTE_ETH_MQ_RX_RSS_FLAG isn't be 
> >>>>>>>> set in
> >>>>>>>> dev_configure phase. However, if this flag isn't set, RSS can be
> >>>>>>>> enabled
> >>>>>>>> through the ethdev ops and rte_flow API. This behavior is 
> >>>>>>>> contrary to
> >>>>>>>> each
> >>>>>>>> other.
> >>>>>>>>
> >>>>>>>> Fixes: c37ca66f2b27 ("net/hns3: support RSS")
> >>>>>>>> Cc: stable@dpdk.org
> >>>>>>>>
> >>>>>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >>>>>>> Hi Huisong, Connor,
> >>>>>>>
> >>>>>>> Let's get a little more feedback for this patch, cc'ed more people.
> >>>>>>>
> >>>>>>> To enable RSS, multi queue mode should be set to
> >>>>>>> 'RTE_ETH_MQ_RX_RSS_FLAG'.
> >>>>>>>
> >>>>>>> But I wonder if it is required to configure RSS via flow API,
> >>>>>> I do not know the original purpose of adding the RSS 
> >>>>>> configuration in
> >>>>>> flow API.
> >>>>>>
> >>>>> The purpose is simple, this allow to create RSS per rule and not a
> >>>>> global one.
> >>>>> For example create RSS that sends TCP to some queues while othe RSS
> >>>>> will send
> >>>>> UDP traffic to different queues.
> >>>> I'm a little confused now. The "per rule" also seems to be a global
> >>>> configuration.
> >>>> Example:
> >>>>   - start PMD with 0,1,2,3
> >>>>   - create TCP packets to 2,3 queues. At this moment, only 2,3 queues
> >>>> can be received for other types of packets.
> >>>> Because this rule is implemented by modifying the entry of the
> >>>> redirection table which is global for this device.
> >>> Hi, Ori and Stephen.
> >>> Can you help me clear up the confusion above? If some NICs behave like
> >>> this, what should we do about it?
> >> I'm not sure I understand the issue, maybe it is releated to some 
> >> HW/PMD limitation.
> >> In your example non TCP traffic will be routed to one of the 4 queues 
> >> (0,1,2,3),
> >> While TCP traffic will only be routed to queues 2,3.
> >>
> >> Now I can add new rule that matches on UDP packet and RSS to queue 0 
> >> and 3 in this case:
> >> TCP packets will be routed to queues 0,3.
> >> UDP packets will be routed to queues 2,3.
> >> All the rest of the traffic will be routed to queues 0,1,2,3
> >>
> >> And just to be clear if now I add a rule to match all packets in 
> >> higher priority,
> >> with RSS to queues 1,2. Then all traffic will be routed to queues 1,2.
> >>
> >> At least this is what is expected, from API point of view.
> >>
> >> Best,
> >> Ori
> > Thank you for your answer. I understand it.
> > hns3 PMD cannot implement the above functions due to hardware limitation.
> > we may need add a check that specified RSS queues cannot be supported 
> > when specified packets types.
> > And only the packet type is specified, which meets the requirements of 
> > rte_flow API.
> > The check for the RTE_ETH_MQ_RX_RSS_FLAG flag in rte_flow is not correct.
> > Thanks, Ori and Stephen😁
> >
> > But, I think, it is necessary for the '.rss_hash_update' and 
> > '.reta_update' APIs
> > in eth_dev_ops to verify this flag. What do you think? @Thomas, 
> > @Ferruh, @Ori and @Stephen.
> What's your take on it? I am looking forward to your reply. Thanks!

I am not sure why you want to check this flag.
I can imagine we configure the hash and the table before enabling RSS
with the RTE_ETH_MQ_RX_RSS_FLAG flag.



  reply	other threads:[~2022-03-22 17:13 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28  3:21 [PATCH 0/6] bugfixes for hns3 PMD Min Hu (Connor)
2022-02-28  3:21 ` [PATCH 1/6] net/hns3: remove duplicate macro definition Min Hu (Connor)
2022-02-28 17:46   ` Ferruh Yigit
2022-03-02 11:22     ` Ferruh Yigit
2022-02-28  3:21 ` [PATCH 2/6] net/hns3: fix inconsistent enabled RSS behavior Min Hu (Connor)
2022-02-28 16:42   ` Ferruh Yigit
2022-03-02  2:09     ` lihuisong (C)
2022-03-02 14:07       ` Ori Kam
2022-03-02 14:46         ` Thomas Monjalon
2022-03-02 16:59           ` Stephen Hemminger
2022-03-03  2:48             ` lihuisong (C)
2022-03-24  7:16             ` Harold Huang
2022-03-03  2:47         ` lihuisong (C)
2022-03-09  8:03           ` lihuisong (C)
2022-03-09  9:55             ` Ori Kam
2022-03-10  8:08               ` lihuisong (C)
2022-03-21  7:14                 ` lihuisong (C)
2022-03-22 17:13                   ` Thomas Monjalon [this message]
2022-03-23  3:05                     ` lihuisong (C)
2022-03-23  9:14                       ` Thomas Monjalon
2022-03-23 11:04                         ` lihuisong (C)
2022-03-23 19:04                           ` Thomas Monjalon
2022-03-23 19:50                             ` Ajit Khaparde
2022-03-24 12:44                               ` lihuisong (C)
2022-05-12 14:13               ` Ferruh Yigit
2022-02-28  3:21 ` [PATCH 3/6] net/hns3: remove unnecessary RSS switch Min Hu (Connor)
2022-02-28  3:21 ` [PATCH 4/6] net/hns3: fix the time waiting for PF reset completion Min Hu (Connor)
2022-02-28 17:09   ` Ferruh Yigit
2022-03-01  6:32     ` Min Hu (Connor)
2022-03-01 10:44       ` Ferruh Yigit
2022-03-02  0:35   ` [PATCH v2] " Min Hu (Connor)
2022-03-02 11:48     ` Ferruh Yigit
2022-02-28  3:21 ` [PATCH 5/6] net/hns3: fix RSS TC mode entry Min Hu (Connor)
2022-02-28  3:21 ` [PATCH 6/6] net/hns3: fix VF " Min Hu (Connor)
2022-04-06  6:56 ` [PATCH v2 0/2] fix RSS bugs Min Hu (Connor)
2022-04-06  6:57   ` [PATCH v2 1/2] ethdev: fix enabling RSS behavior inconsistent Min Hu (Connor)
2022-05-12 14:13     ` Ferruh Yigit
2022-04-06  6:57   ` [PATCH v2 2/2] net/hns3: remove unnecessary RSS switch Min Hu (Connor)
2022-05-12 14:13   ` [PATCH v2 0/2] fix RSS bugs 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=8080441.NyiUUSuA9g@thomas \
    --to=thomas@monjalon.net \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=huangdaode@huawei.com \
    --cc=humin29@huawei.com \
    --cc=jerinj@marvell.com \
    --cc=lihuisong@huawei.com \
    --cc=olivier.matz@6wind.com \
    --cc=orika@nvidia.com \
    --cc=qi.z.zhang@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=viacheslavo@nvidia.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).