From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 601E921F68F for ; Thu, 29 Oct 2015 02:08:34 -0700 (PDT) Received: by oiaw3 with SMTP id w3so2031677oia.1 for ; Thu, 29 Oct 2015 02:08:34 -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=XzMY1Xc17mV8MpVEc9Hr0xiGiDF575KWlf0fpToJwb4=; b=WOaYSO2k6uQrelCyEPcrvsRJ8AiVPR5SrN1t8kCv2P98slPJqi2GW0s9KhZCMxEPIe DK60HUz4TdUVdQvoha8M25QfwCABjLvQG3KIJVD+kkXDYEJzVVza6nliVniv2oZvVcmD gZKGaZs/PzKk8X+OTSIzZvT/vmOF0KHP4DNF36UFyef9MFbyfHGpWS5VcT5v0GPus5tQ 1wOE/CzYGP5VpAx9dOgvB1GhRmJaY5xCp1SBAN7PMrsYsyA/D02ufvXcXYSk7JT8T7iB cRnWMiOr7qc67zaRnqn5yKPrUsdGBfOg78DsuCJfcGpkNVHQTuFsUiLEyweHDlbedQ36 dUIg== MIME-Version: 1.0 X-Received: by 10.202.65.86 with SMTP id o83mr289201oia.75.1446109714176; Thu, 29 Oct 2015 02:08:34 -0700 (PDT) Received: by 10.202.61.133 with HTTP; Thu, 29 Oct 2015 02:08:34 -0700 (PDT) Date: Thu, 29 Oct 2015 10:08:34 +0100 Message-ID: From: Dave Taht To: cake@lists.bufferbloat.net, Jesper Dangaard Brouer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cake] the meta problem of memory, locks, and multiple cpus 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: Thu, 29 Oct 2015 09:08:57 -0000 The real problem A) that I wish we could solve at the qdisc layer is that we could size everything more appropriately if we actually *knew* the physical link rate in many cases. It is *right there* in the sys filesystem for ethernet devices, if only there was some way to get at it, and get notifications if it changed.... or merely to know the underlying operating range of the device at qdisc init time. It is dumb to allow 50MB of memory for a 10mbit device just to make the 10GigE folk happy. yes, I know this does not help on stacked qdiscs, but... the other meta problem is getting to where we can outperform mq + cake somehow on a cpu basis - I dislike intensely the 8 hardware and BQL queues in the mvneta driver and elsewhere, they totally clobber latency. If there was some sort of saner locking structure that would instead let us repurpose those 8 hardware queues to be QoS only and let us let cake get run on multiple cpus in those cases..... bringing jesper back in... Dave T=C3=A4ht I just invested five years of my life to making wifi better. And, now... the FCC wants to make my work, illegal for people to install. https://www.gofundme.com/savewifi