netdev - Re: [PATCH net-next 1/2] pkt_sched: fq: avoid artificial bursts for clocked flows

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: <F3E6220B-F2F4-4985-AECE-9EB9AA7D1C20@ifi.uio.no>
Date:	Tue, 3 Feb 2015 19:51:46 +0000
From:	Kenneth Klette Jonassen <kennetkl@....uio.no>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/2] pkt_sched: fq: avoid artificial bursts for
 clocked flows


> On 02 Feb 2015, at 20:24, Eric Dumazet <eric.dumazet@...il.com> wrote:
> 
> On Mon, 2015-02-02 at 19:59 +0100, Kenneth Klette Jonassen wrote:
>> Current pacing behavior always throttle flows for a time equal to one full
>> quantum, starting at the instance in time when a flow depletes its credit.
>> …
> 
> 
> We do not want to perfectly space packets, but have an efficient packet
> scheduler, allowing TCP pacing.
> 
> I chose to not use ktime_get() in enqueue() when I wrote sch_fq.
Posted V2 to address this.

> 
> A Token Bucket Filter has the notion of quantum, meaning you configure
> the granularity given this quantum.
> 
> At Google, we have a special handling for TCP ACK packets, so that they
> do not interfere with FQ/pacing.
Interesting. How does this work when ACKs are piggybacked to data?

> 
> ACK packets are not paced, ever.
> 
> This patch also allows skb->ooo_okay being set even if the DATA packet
> immediately follows a train of ACK packets (as in typical RPC patterns)
> 
Could you please expand on this?

Thanks for the feedback so far.

Sincerely,
Kenneth