netdev - Re: [net-next Patch v2 4/5] octeontx2-pf: Add devlink support to configure TL1 RR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <PH0PR18MB44748DFCCABCDC2806A2DC2CDEC99@PH0PR18MB4474.namprd18.prod.outlook.com>
Date:   Tue, 24 Jan 2023 11:49:48 +0000
From:   Hariprasad Kelam <hkelam@...vell.com>
To:     Maxim Mikityanskiy <maxtram95@...il.com>,
        Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        Linu Cherian <lcherian@...vell.com>,
        Geethasowjanya Akula <gakula@...vell.com>,
        Jerin Jacob Kollanukkaran <jerinj@...vell.com>,
        Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "jiri@...nulli.us" <jiri@...nulli.us>,
        "saeedm@...dia.com" <saeedm@...dia.com>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        "tariqt@...dia.com" <tariqt@...dia.com>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "hariprasad.netdev@...il.com" <hariprasad.netdev@...il.com>,
        Naveen Mamindlapalli <naveenm@...vell.com>
Subject: Re: [net-next Patch v2 4/5] octeontx2-pf: Add devlink support to
 configure TL1 RR_PRIO



> On Mon, Jan 23, 2023 at 02:45:48PM -0800, Jakub Kicinski wrote:
> > On Mon, 23 Jan 2023 22:05:58 +0200 Maxim Mikityanskiy wrote:
> > > OK, I seem to get it now, thanks for the explanation!
> > >
> > > How do you set the priority for HTB, though? You mentioned this
> > > command to set priority of unclassified traffic:
> > >
> > > devlink -p dev param set pci/0002:04:00.0 name tl1_rr_prio value 6 \
> > > cmode runtime
> > >
> > > But what is the command to change priority for HTB?
> > >
> > > What bothers me about using devlink to configure HTB priority is:
> > >
> > > 1. Software HTB implementation doesn't have this functionality, and
> > > it always prioritizes unclassified traffic. As far as I understand,
> > > the rule for tc stuff is that all features must have a reference
> > > implementation in software.
> > >
> > > 2. Adding a flag (prefer unclassified vs prefer classified) to HTB
> > > itself may be not straightforward, because your devlink command has
> > > a second purpose of setting priorities between PFs/VFs, and it may
> > > conflict with the HTB flag.
> >
> > If there is a two-stage hierarchy the lower level should be controlled
> > by devlink-rate, no?
> 
> From the last picture by Hariprasad, I understood that the user sets all
> priorities (for unclassified traffic per PF and VF, and for HTB traffic) on the
> same TL2 level, i.e. it's not two-stage. (Maybe I got it all wrong again?)
> 
> I asked about the command to change the HTB priority, cause the
> parameters aren't easily guessed, but I assume it's also devlink (i.e.
> driver-specific).
> 
Currently, we don't support changing HTB priority since TC_HTB_MODIFY is not yet supported.
The driver implementation is inline with htb tc framework, below are commands we use for setting htb priority

ethtool -K eth0 hw-tc-offload on
tc qdisc replace dev eth0 root handle 1: htb offload
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Gbit prio 2
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Gbit prio 3


> If there were two levels (the upper level chooses who goes first: HTB or
> unclassified, and the lower level sets priorities per PF and VF for unclassified
> traffic), that would be more straightforward to solve: the upper level should
> be controlled by a new HTB parameter, and the lower level is device-specific,
> thus it goes to devlink.

The PF netdev and VFs share the same physical link and share the same TL1 node.
Hardware supports one DWRR group and the rest are strict priority nodes. Driver configures
the priority set by devlink to PF and VF traffic TL2 nodes such that traffic is forwarded
to TL1 using DWRR algorithm.

Now that if we add htb command for unclassified traffic, at any given point in time HTB
rule only applies to a single interface, since we require to set DWRR priority at TL1, 
which applies to both PF/VFs, we feel it's a different use case altogether.