From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3F81421F3B5 for ; Wed, 15 Oct 2014 12:49:50 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XeUZt-0005KY-NL for cerowrt-devel@lists.bufferbloat.net; Wed, 15 Oct 2014 21:49:45 +0200 Received: from 32.97.110.57 ([32.97.110.57]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Oct 2014 21:49:45 +0200 Received: from wmf by 32.97.110.57 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Oct 2014 21:49:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: cerowrt-devel@lists.bufferbloat.net From: Wes Felter Date: Wed, 15 Oct 2014 14:49:35 -0500 Message-ID: References: <1412988767.10122173@apps.rackspace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 32.97.110.57 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <1412988767.10122173@apps.rackspace.com> 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: Wed, 15 Oct 2014 19:50:19 -0000 On 10/10/14, 7:52 PM, dpreed@reed.com 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 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 to interact much - they are > quite independent. But instead OS designers spend all their time > thinking about doing "one thing at a time". The IX project looks like a promising step in that direction, although it still doesn't support sub-core granularity like Linux does. https://www.usenix.org/conference/osdi14/technical-sessions/presentation/belay -- Wes Felter IBM Research - Austin