From owner-freebsd-current@FreeBSD.ORG Tue May 24 11:24:48 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71CB2106566B for ; Tue, 24 May 2011 11:24:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5243E8FC1A for ; Tue, 24 May 2011 11:24:48 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0214F46B2C for ; Tue, 24 May 2011 07:24:41 -0400 (EDT) Date: Tue, 24 May 2011 12:24:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: 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:24:48 -0000 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. Obviously, there are no bugs in this code at all. However, if they are, they might manifest as network problems, new WITNESS warnings, etc, and network stack exercise + reports would be greatly appreciated! This work has been sponsored by Juniper Networks. Thanks also to Bjoern Zeeb, who has been reviewing changes! Robert N M Watson Computer Laboratory University of Cambridge