From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 88F5F3B29D for ; Fri, 22 Nov 2019 09:33:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574433238; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ub//KWimiFNMi7cK1VCZb8E5H/Bsp7mRtA4Zh3qvZvM=; b=cWiYPk85EGHV4yRSqYKxfCiOQ1vc2Ddth+myE4TGnsrnGUmBXYNljgADte104PO8JmOQ0D 2HaPsTfedWD2PkMESBbYRtoTWiqrFjLHMyaWpIfmDEZUM0TfCh0De6+pojCyqpC4s4lRIZ aB7DQ+JVrmPh8MVKszeqF/XTEHxsCBc= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-413-pzY_2RNhNbiZJG1ALiWYAw-1; Fri, 22 Nov 2019 09:33:56 -0500 Received: by mail-lj1-f200.google.com with SMTP id 70so1373237ljf.13 for ; Fri, 22 Nov 2019 06:33:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=rHani0T8yJAE7ORuopDL/3sKy5oYgZuGJ8AzgOBOuI4=; b=Gcq3avuxU5q9qIfj//SR6jAgGjN82ggTmqIGYHx4lRr/KLkGpNf0tUkYnUUJo+Xb0x hUFIwFQvY6nU7Opyz3NYu6MGDzznyy6B+wpGiqgdXIltg0rbRXTqmi/lElUW0AklNbBp C10P0evdYTAZzty2sJLS0BqAIyy2hME7+wntW4XKzA15W/KYDabmhyAOcOfQ/t9WptS1 /Tn3J9DPdjqfm9fpiyXCmp5hXXeQ51MuJZr21rFoXRVaz5IGWgZhtYErqbxJ5+7HxtQB a/Wx9EWlXrz31IUxTtTwN5R6vXomB+M20C/b0rXkizUTCRRYBkX3ymxqYXtSj1sNji3n +cvw== X-Gm-Message-State: APjAAAX+6xSNWuBn8BHMHrbTGdYQzQd2cKutwU1kr8xF+DncE5Obln5w RP+9KHE3v5kq0Ku1+e6z00viGMLNCxt70tmAm2i9iRoLNkOsaGTlKa+VdNxmpDjgaLl0byd29qL G+FDNJ+sDT9lbJOYo7nlhdg== X-Received: by 2002:ac2:484a:: with SMTP id 10mr11800613lfy.80.1574433235248; Fri, 22 Nov 2019 06:33:55 -0800 (PST) X-Google-Smtp-Source: APXvYqz/jD/ltd4yzhAMOtnrAJGTbGxuSi/ITdbruZ/NiPJNMaan+pWUyUl6kPCLrD/59AsGe+jJYQ== X-Received: by 2002:ac2:484a:: with SMTP id 10mr11800603lfy.80.1574433235008; Fri, 22 Nov 2019 06:33:55 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id p19sm3140770lji.65.2019.11.22.06.33.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Nov 2019 06:33:54 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 557D81800B9; Fri, 22 Nov 2019 15:33:53 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Adam Moffett , cake@lists.bufferbloat.net In-Reply-To: References: <878so85e2d.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 22 Nov 2019 15:33:53 +0100 Message-ID: <877e3s3rqm.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: pzY_2RNhNbiZJG1ALiWYAw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 22 Nov 2019 09:42:28 -0500 Subject: Re: [Cake] Cake implementations 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: Fri, 22 Nov 2019 14:33:58 -0000 "Adam Moffett" writes: >> >>> Second concern is that many of our equipment vendors already use >>> Linux. Even Cisco now in some products. Maybe we'll waste our time >>> trying to roll our own solution and then find that a software update >>> from a vendor next year gives us everything we needed anyway. >> >>This would be great, of course, and do go and bug your vendors to solve >>this problem! Note, however, that just because a system is running >>Linux on the control plane, it may be using a hardware-offloaded data >>plane that does not have any of the bufferbloat mitigation features >>(unless the vendor specifically implemented them). I'm hoping that >>*eventually* these things will be ubiquitous across the industry, but >>thus far this has seemed to be an "any decade now" kind of proposition :/ >> >>-Toke > That's a great point. > > Is the software more or less CPU independent? Would we run into any=20 > known problems with a 72-core Tilera platform? Hmm, well, maybe? Depends on the networking hardware; you can run a separate qdisc on each hardware queue on your network adapter. So if you can configure that for enough queues you can scale to all 72 cores. Otherwise, you'll get lock contention between cores trying to transmit on the same hardware queue, in which case the best solution may be to configure packet steering so you're just not using all cores. Jesper's script that I linked previously is basically a way to program this steering. So it should be doable, but some care is needed in designing the system. > Thanks for all your help and input by the way. You're very welcome! It's always great to hear from someone who is aware of (and wants to fix!) bufferbloat in their network :) -Toke