From owner-freebsd-current@FreeBSD.ORG Tue May 24 11:31:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5652106566C for ; Tue, 24 May 2011 11:31:28 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 929A18FC0C for ; Tue, 24 May 2011 11:31:28 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QOppf-0004Sj-4B for freebsd-current@freebsd.org; Tue, 24 May 2011 13:31:27 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2011 13:31:27 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2011 13:31:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 24 May 2011 13:31:15 +0200 Lines: 19 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: X-Enigmail-Version: 1.1.2 Subject: Re: FYI: merging TCP, UDP, netisr locking changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 11:31:28 -0000 On 24/05/2011 13:24, Robert Watson wrote: > Dear all: > > Over the next few days, I will be merging a number of TCP-related > locking changes, as well as changes to various network stack > infrastructure bits, such as the netisr implementation. The goal, > generally, has been to move us in the direction of supporting more clear > CPU affinity for network flows, the ability to program filters in > network cards to support those affinities explicitly, and elimination of > cache line contention (whether by locks, stats, etc) during high-volume > parallel steady-state TCP load, with ancillary benefits (hopefully) for > UDP and other protocols. This has implied non-trivial changes to our > inpcb locking model, netisr code, etc. Detailed information will appear > in commit messages as I go; some elements, such a programming of card > filters based on setting TCP socket options, are very much a work in > progress. This sounds great! Thanks! :)