Dave Taht <[email protected]> writes: > On Sat, Oct 1, 2016 at 8:51 AM, Toke Høiland-Jørgensen <[email protected]> wrote: >> Dave Taht <[email protected]> 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 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
