netdev - Re: [RFC] Packet pacing (offload) for flow-aggregates and forwarding use-cases

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: <a8510982-96a0-f8d5-b401-f4cce3d30c3c@mellanox.com>
Date:   Mon, 6 Apr 2020 23:26:03 +0300
From:   Yossi Kuperman <yossiku@...lanox.com>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...lanox.com>
Cc:     Rony Efraim <ronye@...lanox.com>
Subject: Re: [RFC] Packet pacing (offload) for flow-aggregates and forwarding
 use-cases


On 26/03/2020 16:42, Yossi Kuperman wrote:
> On 24/03/2020 21:26, Eric Dumazet wrote:
>> On 3/24/20 12:05 PM, Yossi Kuperman wrote:
>>> Hello,
>>>
>>>  
>>>
>>> We would like to support a forwarding use-case in which flows are classified and paced
>>>
>>> according to the selected class. For example, a packet arrives at the ingress hook of interface
>>>
>>> eth0,  performing a sequence of filters and being redirected to interface eth1. Pacing takes
>>>
>>> place at the egress qdisc of eth1.
>>>
>>>  
>>>
>>> FQ queuing discipline is classless and cannot provide such functionality. Each flow is
>>>
>>> paced independently, and different pacing is only configurable via a socket-option—less
>>>
>>> suitable for forwarding  use-case.
>>>
>>>  
>>>
>>> It is worth noting that although this functionality might be implemented by stacking multiple
>>>
>>> queuing disciplines, it will be very difficult to offload to hardware.
>>>
>>>  
>>>
>>> We propose introducing yet another classful qdisc, where the user can specify in advance the
>>>
>>> desired classes (i.e. pacing) and provide filters to classify flows accordingly. Similar to other
>>>
>>> qdiscs, if skb->priority is already set, we can skip the classification; useful for forwarding
>>>
>>> use-case, as the user can set the priority field in ingress. Works nicely with OVS/TC.
>>>
>>>  
>>>
>>> Any thoughts please?
>>>
>> Why not using HTB for this typical use case ?
>
> As far as I understand HTB is meant for rate-limiting, is the implementation fine-grained enough to support pacing
>
> as well?
>
Hi Eric, I'm not sure if HTB also performs pacing (similarly to FQ), can you please comment on that?