From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 2745421F220 for ; Sun, 12 Apr 2015 15:08:23 -0700 (PDT) Received: by qkx62 with SMTP id 62so145227108qkx.0 for ; Sun, 12 Apr 2015 15:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=IUVuVOalZnQ9GiT1G2Y62ZCPVKpT2+MOhyKuGYkO3E0=; b=UthJfZNEk688gRXNE08U8Yr6hq3gChIt/o5+tqUqJR3e2uYYt5SwQv8nsP9O/33iu8 AAM7tyTCUxEVS1wzWXBv16H+XEecIFf6g6E7vFa5vL942JVGWPE53DQdwnY6dO4vPQjG PKeJKCYxuC7wRMIEVgDrswC4ds9x6vDaDQiRzQLgr+DGyLDNLwoagpULJYk/7IYYoiA7 V63XLNcUKa+5biKP14m0LZdrXYAxJ+gGDYH80kMT0J+PiwwGy3sUTzxGZm2ItUOzfKe8 j7CGABTAMAanmx0LuK++PhuQAaIuy7Ie7lbVuTgvPU681a0frrGDa2IoFD//kniEGR0S yHLQ== MIME-Version: 1.0 X-Received: by 10.202.71.84 with SMTP id u81mr5414384oia.81.1428876502805; Sun, 12 Apr 2015 15:08:22 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Sun, 12 Apr 2015 15:08:22 -0700 (PDT) Date: Sun, 12 Apr 2015 15:08:22 -0700 Message-ID: From: Dave Taht To: cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cake] FIB lookup verses GRO X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 22:08:52 -0000 On the linksys 1900ac I was able to achieve full line rate (920Mbits) using the mvneta driver in it (which lacks BQL, AND is hardware multiqueue - we need to add BQL at least) Flooding it in both directions with rrul I got about 600/500. With offloads off, that was halved. mvneta has a interesting property in that it is actually doing software GRO - and I assume (need profiling) much of the savings here are coming from not having to do a FIB lookup on every packet. FIB lookups are vastly improved in linux 4.0 and later. (Turning off offloads univrsally to shape is not a good idea, which is also why I suggested GRO "peeling" be explored. ) A) Having the hash handy, we could associate the next hop on rx and steer from there (RPS), caching the next hop as part of an associated structure in the hash, cleaning it when the FIB table is changed. B) mvneta had GRO of up to 64k! so to me this means that entire tcp windows are being buffered up at line rate and sent as a burst and these MUST be broken up at low rates - so GRO "peeling" is a necessity when shaping. --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67