From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7532821F4FC for ; Fri, 10 Oct 2014 17:52:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6BC3238015F; Fri, 10 Oct 2014 20:52:47 -0400 (EDT) X-Virus-Scanned: OK Received: from app60.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 33C99380137; Fri, 10 Oct 2014 20:52:47 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app60.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.2.13); Sat, 11 Oct 2014 00:52:47 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app60.wa-webapps.iad3a (Postfix) with ESMTP id 1A50B28005A; Fri, 10 Oct 2014 20:52:47 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 10 Oct 2014 20:52:47 -0400 (EDT) Date: Fri, 10 Oct 2014 20:52:47 -0400 (EDT) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20141010205247000000_57757" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Auth-ID: dpreed@reed.com Message-ID: <1412988767.10122173@apps.rackspace.com> X-Mailer: webmail7.0 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: Sat, 11 Oct 2014 00:53:17 -0000 ------=_20141010205247000000_57757 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AThe best approach to dealing with "locking overhead" is to stop thinking= that if locks are good, more locking (finer grained locking) is better. O= S 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 obsessio= n, the parallelized capacity is limited). If you do a thoughtful design o= f 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"= .=0A =0AThere are some really good ideas out there (e.g. RCU) but you have = to think about the big picture of networking to understand how to use them.= I'm not impressed with the folks who do the Linux networking stacks.=0A= =0A=0AOn Thursday, October 9, 2014 3:48pm, "Dave Taht" said:=0A=0A=0A=0A> I have some hope that the skb->xmit_more API could be = used to make=0A> aggregating packets in wifi on an AP saner. (my vision for= it was that=0A> the overlying qdisc would set xmit_more while it still had= packets=0A> queued up for a given station and then stop and switch to the = next.=0A> But the rest of the infrastructure ended up pretty closely tied t= o=0A> BQL....)=0A> =0A> Jesper just wrote a nice piece about it also.=0A> h= ttp://netoptimizer.blogspot.com/2014/10/unlocked-10gbps-tx-wirespeed-smalle= st.html=0A> =0A> It was nice to fool around at 10GigE for a while! And netp= erf-wrapper=0A> scales to this speed also! :wow:=0A> =0A> I do worry that o= nce sch_fq and fq_codel support is added that there=0A> will be side effect= s. I would really like - now that there are al=0A> these people profiling t= hings at this level to see profiles including=0A> those qdiscs.=0A> =0A> /m= e goes grumbling back to thinking about wifi.=0A> =0A> On Thu, Oct 9, 2014 = at 12:40 PM, David Lang wrote:=0A> > lwn.net has an article= about a set of new patches that avoid some locking=0A> > overhead by trans= mitting multiple packets at once.=0A> >=0A> > It doesn't work for things wi= th multiple queues (like fq_codel) in it's=0A> > current iteration, but it = sounds like something that should be looked at and=0A> > watched for latenc= y related issues.=0A> >=0A> > http://lwn.net/Articles/615238/=0A> >=0A> > D= avid Lang=0A> > _______________________________________________=0A> > Cerow= rt-devel mailing list=0A> > Cerowrt-devel@lists.bufferbloat.net=0A> > https= ://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> =0A> =0A> =0A> --=0A> D= ave T=C3=A4ht=0A> =0A> https://www.bufferbloat.net/projects/make-wifi-fast= =0A> _______________________________________________=0A> Cerowrt-devel mail= ing list=0A> Cerowrt-devel@lists.bufferbloat.net=0A> https://lists.bufferbl= oat.net/listinfo/cerowrt-devel=0A> ------=_20141010205247000000_57757 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The best approach to deali= ng with "locking overhead" is to stop thinking that if locks are good, more= locking (finer grained locking) is better.  OS designers (and Linux d= esigners in particular) are still putting in way too much locking.  I = deal with this in my day job (we support systems with very large numbers of= cpus and because of the "fine grained" locking obsession, the parallelized= capacity is limited).   If you do a thoughtful design of your network= code, you don't need lots of locking - because TCP/IP streams don't have t= o interact much - they are quite independent.   But instead OS designe= rs spend all their time thinking about doing "one thing at a time".

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 10pt; word-wra= p: break-word;"> 

=0A

There are some really good id= eas out there (e.g. RCU) but you have to think about the big picture of net= working to understand how to use them.  I'm not impressed with the fol= ks who do the Linux networking stacks.

=0A=0A



On Thursd= ay, October 9, 2014 3:48pm, "Dave Taht" <dave.taht@gmail.com> said:

=0A
=0A

> = 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 packe= ts
> 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 pi= ece about it also.
> http://netoptimizer.blogspot.com/2014/10/unloc= ked-10gbps-tx-wirespeed-smallest.html
>
> It was nice to f= ool around at 10GigE for a while! And netperf-wrapper
> scales to t= his speed also! :wow:
>
> I do worry that once sch_fq and = fq_codel support is added that there
> will be side effects. I woul= d really like - now that there are al
> these people profiling thin= gs 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 <david@lang.hm> wr= ote:
> > 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 mul= tiple queues (like fq_codel) in it's
> > current iteration, but = it sounds like something that should be looked at and
> > watche= d for latency related issues.
> >
> > http://lwn.net/= Articles/615238/
> >
> > David Lang
> > __= _____________________________________________
> > Cerowrt-devel = mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> &= gt; https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
&g= t;
>
> --
> Dave T=C3=A4ht
>
> h= ttps://www.bufferbloat.net/projects/make-wifi-fast
> ______________= _________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferblo= at.net/listinfo/cerowrt-devel
>

=0A
 ------=_20141010205247000000_57757--