From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 9061721F3A4 for ; Mon, 13 Oct 2014 15:11:07 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id u20so14512901oif.28 for ; Mon, 13 Oct 2014 15:11:06 -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=ziiOEdzGxxMOMQU+aphfOD/icDhEXMnR26ry1/w4UxI=; b=nnJwIX/dpoFEaAk7xnpp9E/AREjdZGuANiuaDhow9xGtSB554GTPtF0opbSMXMwLZ7 UDR6KfAWb14DoIpHii1tV8K3zP8SQfIppA6yjnodvxDqtvcqpdr46fqd/UXJXNkZ4EQa j/fqW1hilNFmZ2O0qPHWN1un9moRvDB2ChfdCo5zrxVpNB0Tc4axaG7P+nqVjGUrgDC9 jgtO/pO61WdsobK4b+m+wpP07DgB/YNa98FYKelMy8p/QnMSYwDerzQbMlWmRlyEe7MA GbEfY0aFM2cAzTOoJ9AcuIg2Ywcv0t9RF3+Zlbs6wzg8UMHEBaEGn3FmVvPTX8nsom/F GdFw== MIME-Version: 1.0 X-Received: by 10.60.148.169 with SMTP id tt9mr1062202oeb.19.1413238266042; Mon, 13 Oct 2014 15:11:06 -0700 (PDT) Received: by 10.202.227.211 with HTTP; Mon, 13 Oct 2014 15:11:05 -0700 (PDT) In-Reply-To: <1412988767.10122173@apps.rackspace.com> References: <1412988767.10122173@apps.rackspace.com> Date: Mon, 13 Oct 2014 15:11:05 -0700 Message-ID: From: Dave Taht To: David Reed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" , Jesper Dangaard Brouer Subject: Re: [Cerowrt-devel] bulk packet transmission 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: Mon, 13 Oct 2014 22:11:35 -0000 In the end, I weighed in on this thread on netdev: http://www.spinics.net/lists/netdev/msg300590.html On Fri, Oct 10, 2014 at 5:52 PM, wrote: > The best approach to dealing with "locking overhead" is to stop thinking > that if locks are good, more locking (finer grained locking) is better. = OS > designers (and Linux designers in particular) are still putting in way to= o > much locking. I deal with this in my day job (we support systems with ve= ry > large numbers of cpus and because of the "fine grained" locking obsession= , > the parallelized capacity is limited). If you do a thoughtful design of I'd certainly like to see you load up the new code under your workloads. > your network code, you don't need lots of locking - because TCP/IP stream= s > don't have to interact much - they are quite independent. But instead O= S > designers spend all their time thinking about doing "one thing at a time"= . Well, it's an engineering trait to focus on doing one thing at a time. I'd like it if more CS folk had some EE influence and vice versa. Certainly thinking about the system as a whole, as you must, in circuit design, helps. I really regret the shift towards specialization that has happened. When I was a kid, programmers could design a circuit and soldier it up. And in many cases, had to. Thankfully the maker movement seems to be bringing these two fields back together again, and I look forward to the day where I can look j random programmer in the eye and ask "What would you do with a billion transitors", and get back a reasonable answer. > There are some really good ideas out there (e.g. RCU) but you have to thi= nk > about the big picture of networking to understand how to use them. an RCU conversion is actually part of the xmit_more stuff. The end results of all this work are being presented this week at linux plumbers (the site with the preso with the pretty graphs is down right now) When people complain about slow progress in the network stack or how it's overly complex somewhere, and how much easier it would be to do something clean, and/or move everything in userspace, I tend to point them at this skbuff structure, and explain how each and every field is needed in some circumstance: http://lxr.free-electrons.com/source/include/linux/skbuff.h#L417 I am ALL in favor of moving packet processing to userspace, but so far, aside from toy prototypes, I haven't seen anything genuinely useful that covers the extreme range of link layer technologies and speeds and devices that linux does. I do think that netmap has some potential as does stuff layered on the dpdk, but haven't played with either. And certainly I'd like to see network hardware gain completion rings, be able to deliver packets out of order, and thus be made fq_codel capable. > > > On Thursday, October 9, 2014 3:48pm, "Dave Taht" sa= id: > >> I have some hope that the skb->xmit_more API could be used to make >> aggregating packets in wifi on an AP saner. (my vision for it was that >> the overlying qdisc would set xmit_more while it still had packets >> queued up for a given station and then stop and switch to the next. >> But the rest of the infrastructure ended up pretty closely tied to >> BQL....) >> >> Jesper just wrote a nice piece about it also. >> >> http://netoptimizer.blogspot.com/2014/10/unlocked-10gbps-tx-wirespeed-sm= allest.html >> >> It was nice to fool around at 10GigE for a while! And netperf-wrapper >> scales to this speed also! :wow: >> >> I do worry that once sch_fq and fq_codel support is added that there >> will be side effects. I would really like - now that there are al >> these people profiling things at this level to see profiles including >> those qdiscs. >> >> /me goes grumbling back to thinking about wifi. >> >> On Thu, Oct 9, 2014 at 12:40 PM, David Lang wrote: >> > lwn.net has an article about a set of new patches that avoid some >> > locking >> > overhead by transmitting multiple packets at once. >> > >> > It doesn't work for things with multiple queues (like fq_codel) in it'= s >> > current iteration, but it sounds like something that should be looked = at >> > and >> > watched for latency related issues. >> > >> > http://lwn.net/Articles/615238/ >> > >> > David Lang >> > _______________________________________________ >> > Cerowrt-devel mailing list >> > Cerowrt-devel@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> >> >> -- >> Dave T=C3=A4ht >> >> https://www.bufferbloat.net/projects/make-wifi-fast >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> --=20 Dave T=C3=A4ht https://www.bufferbloat.net/projects/make-wifi-fast