From owner-freebsd-net@FreeBSD.ORG Fri Dec 23 18:09:12 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D3E1106568A; Fri, 23 Dec 2011 18:09:12 +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 28F008FC21; Fri, 23 Dec 2011 18:09:12 +0000 (UTC) Received: from [192.168.2.115] (host86-161-238-124.range86-161.btcentralplus.com [86.161.238.124]) by cyrus.watson.org (Postfix) with ESMTPSA id CB84146B0D; Fri, 23 Dec 2011 13:09:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <201112221130.01823.jhb@freebsd.org> Date: Fri, 23 Dec 2011 18:09:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <49D68715-E984-472A-AF42-613FEA1AEB11@freebsd.org> References: <201112221130.01823.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: net@freebsd.org Subject: Re: Transitioning if_addr_lock to an rwlock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 18:09:12 -0000 On 22 Dec 2011, at 16:30, John Baldwin wrote: > Phase 1 should definitely be MFC'able. Phase 2 may or may not be. = Robert had=20 > the foresight to change drivers to use explicit function wrappers = around=20 > IF_ADDR_LOCK, and sizeof(struct mtx) =3D=3D sizeof(struct rwlock), so = if we=20 > changed the lock type the KBI for existing device drivers would all be = fine. =20 > Most of the remaining uses of the locking macros are in parts of the = kernel=20 > that aren't loadable (such as inet and inet6). We can look at the = places that=20 > to do change and if any of them are in kld's then it would be up to = re@ to=20 > decide if 2) was actually safe to merge. However, even if Phase 2 = cannot be=20 > MFC'd, having phase 1 makes it easier for downstream consumers to = apply Phase=20 > 2 locally if they need it. >=20 > You can find the patch for 8.x at=20 > http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch I think this is a reasonable approach, although to repeat a point I made = privately to you, I had anticipated migrating the address lock model to = an rmlock in 10.x (and hoped to do it in 9.x, but missed the boat). The = reason this improves performance has to do with the synchronous nature = of card reconfiguration in the presence of (for example) multicast = filter changes, which otherwise stall other consumers of the address = list. I didn't encounter this in my earlier measurement, where the = migration to rwlocks offered only a small (perhaps no) win due to = continued high line contention, which an rmlock would mitigate. I'm = quite happy to see the rwlock transition occur, especially in as much as = it is mergeable without damaging KPI/KBI. However, in 10.x a significant = revisiting of both network configuration locking *and* inter-layer = synchronisation during hardware reprogramming is probably called for. Robert=