From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id EE8B821F41A for ; Thu, 29 May 2014 17:36:11 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so1180892wgh.28 for ; Thu, 29 May 2014 17:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2a/7I5tTiducQ+CZX1Ji3ArZ6EaJfvPr3PqCQQKHec0=; b=MQsk6edhg7MVsjeNVJexKLvBp/LS1ezJWPIqXeKsl/JpwU8YLGcJpzIFNXENiE9YwN kV7vcGSVtLCUUN1GY7iR762mu5Fu6TIoswnWSmuUxB7ZctCAZqq3Ps5IKdSTbrTRLtIE IIHO3T3WilDmf2rRBpQqA+xFT/nK3o1cwITnZVgDg4IHYqCC/NLVutwi/LOHXMyiome7 wjiSv2vEdt11GfzN9zv9PJPPao+oZthq+MhkWmLGb74cZwu0S06Yx7k6T33+a/fkE9SD oyZ+2wB7PM2u/mWDfgOlRIWYfth2WBxwdRZ2/WsctQ8rz3H+maAF7fkfR8Pif4GPNZnp /1kQ== MIME-Version: 1.0 X-Received: by 10.194.175.70 with SMTP id by6mr15861920wjc.3.1401410169834; Thu, 29 May 2014 17:36:09 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Thu, 29 May 2014 17:36:09 -0700 (PDT) In-Reply-To: <30541.1401406850@sandelman.ca> References: <1401048053.664331760@apps.rackspace.com> <1401290405.100110358@apps.rackspace.com> <3eb328c9-05fb-4594-81cc-71e6a623b977@katmail.1gravity.com> <30541.1401406850@sandelman.ca> Date: Thu, 29 May 2014 17:36:09 -0700 Message-ID: From: Dave Taht To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Ubiquiti QOS X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 00:36:12 -0000 On Thu, May 29, 2014 at 4:40 PM, Michael Richardson wrot= e: > > David P. Reed wrote: > > ECN-style signaling has the right properties ... just like TTL it c= an > > provide > > How would you send these signals? > > > A Bloom style filter can remember flow statistics for both of these= local > > policies. A great use for the memory no longer misapplied to > > buffering.... > > Well. > > On the higher speed dataflow equipment, the buffer is general purpose mem= ory, > so reuse like this is particularly possible. > > On routers built around general purpose architectures, the limiting facto= r > in performance is often memory throughput; adding memory rarely increases > total throughput. Packet I/O is generally quiet sequential and so makes > good use of wide memory data paths and multiple accesses per address cycl= e. > Updating of tables such as Bloom filter or any other hash has a big impac= t > due to the RMW and random access nature. In hardware using a parallel memory layout makes sense. I had always envisioned the per flow fq_codel table to be on a lookaside ca= che, much like how mac and route lookups happen today in hw. In a general purpos= e architecture with fat amounts of cache (like ivy bridge) you can set aside some main cache if you like. It needent be big (64k for 1024 flows but you can shrink the structure some if you want) - and it needent be fast, just fast enough to be accessed on a per packet basis. There are other ways to do it of course. you could set it up as 1024 8 32 bit register register banks, for example, in the asic or fpga, and elimi= nate the concept of using ram for it entirely. This is not a lot of gates (quite a lot when you consider the invsqrt dependency in codel alone is 3k gates or so - or "free" in a FPGA with dsp multipliers= ) I've never thought that pure "drop head" was possible in high speed hardwar= e - the various operations need to be pipelined, the timestamp needs to go at the head of the packet for codel to operate on them, etc, etc... > All I'm saying is that quantity of memory is seldom the problem, but acce= ss > to it, is. Concur. I keep hoping my parallela arrives. You can write your own ethernet device with that... > I do like the entire idea; it seems that it has to be implemented at the > places where the flow converge, which is often in the DSL line card, or > CTMS... The elephant in the room on those devices is the per user rate shaper. In software this accounts for 95% of the cpu time and scheduling headaches, and that's witho= ut dealing with ipv6 pools. > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article