[Cake] Lockup at high speeds
pete at eventide.io
Tue Jun 5 10:24:21 EDT 2018
> On Jun 5, 2018, at 1:46 PM, Pete Heist <pete at eventide.io> wrote:
>> On Jun 4, 2018, at 1:26 AM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> Georgios Amanakis <gamanakis at gmail.com> writes:
>>> I am trying to reproduce this with veth to no avail.
>>> I compiled a net-next kernel with Toke's configuration, and simplified
>>> veth to only a client and a server.
>> Hmm. Guess it may only be triggered by the way the mlx5 driver calls
>> transmit, or something? Guess I'll have to go back and check once I get
>> some spare cycles on that machine...
> As another test, I tried redirecting egress and ingress of the loopback adapter through a common IFB. I couldn’t reproduce it either, but I can only hit ~3Gbit total with cake and flent running on one APU2.
> If anyone wants to try it (faster hardware?), just run the attached ‘flentlo.sh' with no arguments as root on a box with cake and flent installed and netserver running. One run is done with noqueue and the other with cake datacentre.
> Interestingly, for me the ‘datacentre' keyword actually both increases total throughput and reduces rtt in this case (3286Mbit/5ms vs 2838Mbit/15ms), so I left that in the test. I wonder if the rtt parameter affects the lockup in any way, but I doubt it.
> Also, this is a case where using netperf UDP_RR reduces total throughput vs irtt (for me, 2910Mbit vs 3286Mbit), probably due to competition.
Update attached just using lo on egress without IFB (also replacing ifconfig with ip). Tested on VMWare w/ Debian 9 unstable (kernel 4.16.0-2) up to 22Gbit and still didn’t see a lockup. This is as far as I can go with what I have available. George’s veth test is probably closer to the original config anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 649 bytes
Desc: not available
More information about the Cake