From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 63E373B29F; Sat, 1 Oct 2016 13:28:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk B546F41622 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1475342921; bh=O7uma0UTSEW1XLKlTTy1zgXzMWpv9TrphYQnTPYfQpo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Hn/Xyta8kxKNO95tmPqwqK3oylFb4yradi7UTW1+zwACzphDWFCE1AGy8Yccg6EMv QH6OY2WMijxkFzlLDyuDCjHn3EUWPUxEIH9npuiEPFh8ySMkKi8dY2A7OACZomi+rI amw1q+sO9MDPTLa29igJLXvuI2hVlRGe0ypoPx+w= Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 80A8B8743A3; Sat, 1 Oct 2016 19:28:41 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Dave Taht Cc: "Jason A. Donenfeld" , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net, WireGuard mailing list References: <87twcw9tih.fsf@toke.dk> <87ponk9if1.fsf@toke.dk> Date: Sat, 01 Oct 2016 19:28:41 +0200 In-Reply-To: (Dave Taht's message of "Sat, 1 Oct 2016 10:19:00 -0700") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87intc9dx2.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] WireGuard Queuing, Bufferbloat, Performance, Latency, and related issues X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 17:28:44 -0000 Dave Taht writes: > On Sat, Oct 1, 2016 at 8:51 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> Dave Taht writes: >> >>> My thought - given that at least on some platforms - encrypting 1000 >>> packets at a time is a bad idea - would be something regulating the >>> amount of data being crypted at a time, an equivalent to byte queue >>> limits - BQL - BCL? byte crypto limits - to keep no more than, say, >>> 1ms of data in that part of the subsystem. >> >> Well, the dynamic queue limit stuff is reusable (in >> include/linux/dynamic_queue_limits.h). The netdev BQL stuff just uses >> these functions with the packet byte sizes; so adapting it to use in >> wireguard should be fairly straight forward :) > > Having one global queue for all of wireguard makes a lot of sense, one > that gets divvied up as per the amount of traffic for each > destination, You'd get that with the FQ structure I described earlier. Then apply the dql stuff to limit (globally) the number of packets (or bytes) currently being encrypted, and you should have something fairly reasonable. -Toke