From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa.plexicomm.net (sa.plexicomm.net [204.80.232.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CE22E3B29D for ; Fri, 22 Nov 2019 08:33:37 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by sa.plexicomm.net (Postfix) with ESMTP id 3C725412F17 for ; Fri, 22 Nov 2019 08:32:10 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at plexicomm.net X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-9999 required=4.5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.125, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: sa.plexicomm.net (amavisd-new); dkim=pass (1024-bit key) header.d=plexicomm.net Received: from sa.plexicomm.net ([127.0.0.1]) by localhost (sa.plexicomm.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzdNe8a6-vkJ for ; Fri, 22 Nov 2019 08:32:09 -0500 (EST) Received: from mail.plexicomm.net (mail.plexicomm.net [204.80.232.17]) by sa.plexicomm.net (Postfix) with ESMTP id 849A8412F18 for ; Fri, 22 Nov 2019 08:32:09 -0500 (EST) DKIM-Signature: a=rsa-sha256; t=1574429609; x=1575034409; s=key1; d=plexicomm.net; c=relaxed/relaxed; v=1; bh=EMPpmtImqwhyAI0QyaoKsimV9SL49Hu6kWcuwsONhsU=; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type:In-Reply-To:References; b=S6cbfNG9Nh4nnEBlXFdXcOSTP9rvk1T91afaJ+MgHd4PxKhd7LYlcsiN+JtDCWDgG2TNEq+54Rm5tQMq+nXy8RmKO+byJ5LYaJ3+N2bWADSDZLJ2etGm2HhSjOlkuokVKBEZ5O9PmBKwwLheAeWbxuxPs5JhkW08l6RnTkA76Bs= Received: from [192.168.11.33] ([23.226.94.156]) by mail.plexicomm.net (12.2.0 x64) with ASMTP id 201911220833295831 for ; Fri, 22 Nov 2019 08:33:29 -0500 From: "Adam Moffett" To: cake@lists.bufferbloat.net Date: Fri, 22 Nov 2019 13:33:36 +0000 Message-Id: In-Reply-To: <878so85e2d.fsf@toke.dk> References: <878so85e2d.fsf@toke.dk> Reply-To: "Adam Moffett" User-Agent: eM_Client/7.2.36908.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB34B77BB8-C9AC-42F3-8AE2-96E3B06B2119" 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 13:33:37 -0000 --------=_MB34B77BB8-C9AC-42F3-8AE2-96E3B06B2119 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable > >> 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? Thanks for all your help and input by the way. -Adam --------=_MB34B77BB8-C9AC-42F3-8AE2-96E3B06B2119 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=C2=A0
Second concern is that many of our equipment ven= dors already use
Linux. Even Cisco now in some products. Maybe we= 'll waste our time
trying to roll our own solution and then find th= at a software update
from a vendor next year gives us everything we n= eeded anyway.
=C2=A0
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 har= dware-offloaded data
plane that does not have any of the bufferbloat m= itigation features
(unless the vendor specifically implemented them)= . I'm hoping that
*eventually* these things will be ubiquitous acro= ss the industry, but
thus far this has seemed to be an "any decade now= " kind of proposition :/
=C2=A0
-Toke
That's a great point.

Is the sof= tware more or less CPU independent? Would we run into any known problems w= ith a 72-core Tilera platform?

Thanks for all your help and input by the w= ay.

-Adam

--------=_MB34B77BB8-C9AC-42F3-8AE2-96E3B06B2119--