From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 BA44021F220 for ; Sun, 12 Apr 2015 15:10:06 -0700 (PDT) Received: by qku63 with SMTP id 63so145094318qku.3 for ; Sun, 12 Apr 2015 15:10:05 -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=TIMM3ICXznwpuI8u0cfnoKJFqZJ/28Z6YroFnO2FGKs=; b=RP+7/QHBNMrRVaC35RIktrDySFOxnUVMFIL8+2gGXqFzou1zdEx/7wF+EbfzLpPqE0 Wm6QGCJXCYNrtfCG3PIbOCnYVk+wWIoe9AWz2BFbjjCaaYUlVhouKti34DoFFmYWUhbY 1nwSljYj9ebZ+kAn69T7OGAEk8Jf5e+HriwSK9ObYYSKiApTV/mcMuVp91y3QPNJeYPJ 2/AcTYIg8GZ7v6gfBHKb8P2bUFALj262o6VeWf9U44bupYaH0FX+ll2hCIhDZcsBi7eL m8wu9bnBGSEvObezAusLqmHz13ZMJakKGO9qUwA6A7IaAXzmunMcvxV8bAbtfoTZwnF9 MAdQ== MIME-Version: 1.0 X-Received: by 10.202.216.87 with SMTP id p84mr5421882oig.133.1428876605056; Sun, 12 Apr 2015 15:10:05 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Sun, 12 Apr 2015 15:10:05 -0700 (PDT) Date: Sun, 12 Apr 2015 15:10:05 -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] cake verses hardware multiqueue 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:10:35 -0000 Nearly all the latest hardare has hardware multiqueue, which is usually useful in gaining some benefit from natively fq-ing flows, but also (due to the limited number of queues), tends to show severe birthday problems. Hardware multiqueue is also of benefit when A) there is a mapping from the hardware queues to the cpus IRQ handler(s) so they can be serviced in parallel. B) when the queues can prioritize It is generally unclear if hardware multiqueue on ethernet is implemented as a priority queue of any sort. (it is on wifi, and sorting out which better qdisc to select for each device type is a longstanding issue) It has been shown (old eric dumazet post) that we can often get better results to have a single qdisc, rather than one per hardware queue, to keep control of the BQL queues in the implementation, so long as the single interrupt can be adaquately handled by one cpu. C) Cake - at line rate - could spread it's diffserv markings across the existing hardware queues also to get priority (if the hardware queues supported that, rather than fairness.) This would mitigate a bit against excessive BQL. D) mvneta and the ethernet device in the rangeleys are both hardware multiqueue. I believe the mvneta has 16 queues, and perhaps it would be better to have one cake instance per cpu to drive those multiqueues, instead. We would save on dcache, in particular. E) Drivers could also specify a different qdisc at instantation time, rather than the default from the sysctl, or mq + the default sysctl. "cakemq" --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67