From owner-freebsd-net@FreeBSD.ORG Sat Oct 2 19:33:14 2010 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 B4188106564A for ; Sat, 2 Oct 2010 19:33:14 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1528FC15 for ; Sat, 2 Oct 2010 19:33:14 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id 6FE2C11B8A7; Sat, 2 Oct 2010 14:07:05 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id HHAO5LPYS6DV; Sat, 02 Oct 2010 14:07:05 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Sat, 2 Oct 2010 20:07:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> References: <4C9DA26D.7000309@freebsd.org> <4CA51024.8020307@freebsd.org> To: Robert Watson X-Mailer: Apple Mail (2.1081) Cc: Ryan Stone , FreeBSD Net Subject: Re: mbuf changes 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: Sat, 02 Oct 2010 19:33:14 -0000 On 2 Oct 2010, at 16:29, Robert Watson wrote: > On Thu, 30 Sep 2010, Julian Elischer wrote: >=20 >> On 9/30/10 10:49 AM, Ryan Stone wrote: >>> It's not a big thing but it would be nice to replace the m_next and = m_nextpkt fields with queue.h macros. >> funny, I've never even thought of that.. >=20 > I have, and it's a massive change touching code all over the kernel in = vast quantities. While in principle it's a good idea (consistently = avoid hand-crafted linked lists), it's something I'd discourage on the = basis that it probably won't significant reduce the kernel bug count, = but will make it even harder for vendors with large local changes to the = network stack to keep up. I think it could also increase the kernel bug count. Unfortunately, we = can't do this incrementally. > (We might consider revisiting the proposal for 10.0, perhaps? I'd = rather we burnt the cycles on fleshing out network stack virtualization = more thoroughly for 9.x though.) I agree that this doesn't bring us a great improvement for the amount of = work that's required. Regards, -- Rui Paulo