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] [day] [month] [year] [list]
Message-ID: <CAA93jw6p47ZN4DgRjxGjeYEub5fibo3bwn6mDCd=DqkH-toDTg@mail.gmail.com>
Date:   Wed, 15 Dec 2021 13:21:18 -0800
From:   Dave Taht <dave.taht@...il.com>
To:     Naveen Mamindlapalli <naveen130617.lkml@...il.com>
Cc:     lartc <lartc@...r.kernel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>, maximmi@...dia.com
Subject: Re: Question about QoS hardware offload

On Wed, Dec 15, 2021 at 12:46 PM Naveen Mamindlapalli
<naveen130617.lkml@...il.com> wrote:
>
> Hi,
>
> Our NIC hardware provides a hierarchical QoS tree for each physical
> link with strict
> priority and DRR scheduling & also supports traffic shaping at each
> level. I'm curious what the closest qdisc that supports the above
> functionalities for offloading to hardware. I looked into htb/drr/prio
> qdiscs, but each qdisc supports a subset of the functionality enabled
> by our hardware.
>
> As per my understanding, The HTB hardware offload is used for shaping
> rather than scheduling (strict priority/DRR).

Correct.

> The PRIO qdisc seems to support strict priority but not DRR. Similarly
> DRR doesn't support strict priority.

My assumption is your hardware does not do 5 tuple FQ for the DRR, but
leverages the dscp field?

Instead, linux pretty much does a 5 tuple hash universally now for
packet steering (RPS) and in the sch_fq and fq_codel qdiscs.

I am not really big on strict priority with dscp, as whenever someone
lucks into the right dscp value they get most of the bandwidth, and
it's
more or less a matter of historical accident that the support in
mqprio/pfifo_fast is not more abused in the field. But that's me.

>
> Please advise on how to effectively offload all the features.
>
> Is the ETS - Enhanced Transmission Selection scheduler a better fit if
> we simply need to offload scheduling with strict priority and DRR?

Of course, my dream is to see 5 tuple fq-codel or cake land in some
offload somewhere.

I don't know enough about how when and where ets is used, it's pretty
new, and I'd lke to know more.

>
> Thanks,
> Naveen



-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ