netdev - Re: [RFC/PATCH net-next v3 0/8] allow user to offload tc action to net device

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: <4247ecd8-e4ca-0c35-5c0f-1124a043080f@mojatatu.com>
Date:   Sun, 31 Oct 2021 10:14:23 -0400
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Dave Taht <dave.taht@...il.com>, Oz Shlomo <ozsh@...dia.com>
Cc:     Simon Horman <simon.horman@...igine.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Vlad Buslov <vladbu@...dia.com>, Roi Dayan <roid@...dia.com>,
        Ido Schimmel <idosch@...dia.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Baowen Zheng <notifications@...hub.com>,
        Louis Peens <louis.peens@...igine.com>,
        oss-drivers@...igine.com
Subject: Re: [RFC/PATCH net-next v3 0/8] allow user to offload tc action to
 net device

On 2021-10-31 08:03, Dave Taht wrote:
[..]

> 
> Just as an on-going grump: It has been my hope that policing as a
> technique would have died a horrible death by now. Seeing it come back
> as an "easy to offload" operation here - fresh from the 1990s! does
> not mean it's a good idea, and I'd rather like it if we were finding
> ways to
> offload newer things that work better, such as modern aqm, fair
> queuing, and shaping technologies that are in pie, fq_codel, and cake.
> 
> policing leads to bursty loss, especially at higher rates, BBR has a
> specific mode designed to defeat it, and I ripped it out of
> wondershaper
> long ago for very good reasons:
> https://www.bufferbloat.net/projects/bloat/wiki/Wondershaper_Must_Die/
> 
> I did a long time ago start working on a better policing idea based on
> some good aqm ideas like AFD, but dropped it figuring that policing
> was going to vanish
> from the planet. It's baaaaaack.

A lot of enthusiasm for fq_codel in that link ;->
Root cause for burstiness is typically due to large transient queues
(which are sometimes not under your admin control) and of course if
you use a policer and dont have your double leaky buckets set properly
to compensate for both short and long term rates you will have bursts
of drops with the policer. It would be the same with shaper as well
if the packet burst shows up when the queue is full.

Intuitively it would feel, for non-work conserving approaches,
delaying a packet (as in shaping) is better than dropping (as in
policing) - but i have not a study which scientifically proves it.
Any pointers in that regard?
TCP would recover either way (either detecting sequence gaps or RTO).

In Linux kernel level i am not sure i see much difference in either
since we actually feedback an indicator to TCP to indicate a local
drop (as opposed to guessing when it is dropped in the network)
and the TCP code is smart enough to utilize that knowledge.
For hardware offload there is no such feedback for either of those
two approaches (so no difference with drop in the blackhole).

As to "policer must die" - not possible i am afraid;-> I mean there
has to be strong evidence that it is a bad idea and besides that
_a lot of hardware_ supports it;-> Ergo, we have to support it as well.
Note: RED for example has been proven almost impossible to configure
properly but we still support it and there's a good set of hardware
offload support for it. For RED - and i should say the policer as well -
if you configure properly, _it works_.

BTW, Some mellanox NICs offload HTB. See for example:
https://legacy.netdevconf.info/0x14/session.html?talk-hierarchical-QoS-hardware-offload

cheers,
jamal