Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 20 Jan 2023 15:37:58 +0200
From:   Maxim Mikityanskiy <maxtram95@gmail.com>
To:     Hariprasad Kelam <hkelam@marvell.com>
Cc:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        "edumazet@google.com" <edumazet@google.com>,
        Sunil Kovvuri Goutham <sgoutham@marvell.com>,
        Linu Cherian <lcherian@marvell.com>,
        Geethasowjanya Akula <gakula@marvell.com>,
        Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
        Subbaraya Sundeep Bhatta <sbhatta@marvell.com>,
        "jhs@mojatatu.com" <jhs@mojatatu.com>,
        "xiyou.wangcong@gmail.com" <xiyou.wangcong@gmail.com>,
        "jiri@resnulli.us" <jiri@resnulli.us>,
        "saeedm@nvidia.com" <saeedm@nvidia.com>,
        "richardcochran@gmail.com" <richardcochran@gmail.com>,
        "tariqt@nvidia.com" <tariqt@nvidia.com>,
        "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
        "hariprasad.netdev@gmail.com" <hariprasad.netdev@gmail.com>
Subject: Re: [net-next Patch v2 4/5] octeontx2-pf: Add devlink support to
 configure TL1 RR_PRIO
Message-ID: <Y8qZNhUgsdOMavC4@mail.gmail.com>
References: <20230118105107.9516-1-hkelam@marvell.com>
 <20230118105107.9516-5-hkelam@marvell.com>
 <Y8hYlYk/7FfGdfy8@mail.gmail.com>
 <PH0PR18MB4474FCEAC4FA5907CAC17011DEC59@PH0PR18MB4474.namprd18.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <PH0PR18MB4474FCEAC4FA5907CAC17011DEC59@PH0PR18MB4474.namprd18.prod.outlook.com>
Precedence: bulk

On Fri, Jan 20, 2023 at 08:50:16AM +0000, Hariprasad Kelam wrote:
> 
> On Wed, Jan 18, 2023 at 04:21:06PM +0530, Hariprasad Kelam wrote:
> > All VFs and PF netdev shares same TL1 schedular, each interface PF or 
> > VF will have different TL2 schedulars having same parent TL1. The TL1 
> > RR_PRIO value is static and PF/VFs use the same value to configure its 
> > TL2 node priority in case of DWRR children.
> > 
> > This patch adds support to configure TL1 RR_PRIO value using devlink.
> > The TL1 RR_PRIO can be configured for each PF. The VFs are not allowed 
> > to configure TL1 RR_PRIO value. The VFs can get the RR_PRIO value from 
> > the mailbox NIX_TXSCH_ALLOC response parameter aggr_lvl_rr_prio.
> 
> I asked this question under v1, but didn't get an answer, could you shed some light?
> 
> "Could you please elaborate how these priorities of Transmit Levels are related to HTB priorities? I don't seem to understand why something has to be configured with devlink in addition to HTB.
> 
> SMQ (send meta-descriptor queue) and MDQ (meta-descriptor queue) are the first transmit levels.
> Each send queue is mapped with SMQ.
>  
> As mentioned in cover letter, each egress packet needs to traverse all transmit levels starting from TL5 to TL1.

Yeah, I saw that, just some details about your hardware which might be
obvious to you aren't so clear to me...

Do these transmit levels map to "layers" of HTB hierarchy? Does it look
like this, or is my understanding completely wrong?

TL1                 [HTB root node]
                   /               \
TL2          [HTB node]         [HTB node]
            /          \             |
TL3    [HTB node]  [HTB node]   [HTB node]
...                       ...


> This applies to non-QOS Send queues as well.
>  
>                        SMQ/MDQ --> TL4 -->TL3 -->TL2 -->TL1
> 
> By default non QOS queues use a default hierarchy  with round robin priority. 
> To avoid conflict with QOS tree priorities, with devlink user can choose round-robin priority before Qos tree formation.

So, this priority that you set with devlink is basically a weight of
unclassified (default) traffic for round robin between unclassified and
classified traffic, right? I.e. you have two hierarchies (one for HTB,
another for non-QoS queue), and you do DWRR between them, according to
this priority?

> BTW, why did you remove the paragraphs with an example and a limitation?
> I think they are pretty useful.
> 
> Ok , removed them accidentally will correct in the next version.
> 
> Another question unanswered under v1 was:
> 
> "Is there any technical difficulty or hardware limitation preventing from implementing modifications?" (TC_HTB_NODE_MODIFY)
> 
> There is no hardware limitation, we are currently implementing it.  once it's implemented we will submit for review.

Great, that's nice to hear, looking forward to it.