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-next>] [day] [month] [year] [list]

Message-ID: <4d16c8e8-31d2-e3a4-2ff9-de0c9dc12d2e@gmail.com>
Date:   Tue, 24 Mar 2020 12:26:34 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Yossi Kuperman <yossiku@...lanox.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 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 ?