From owner-freebsd-net@FreeBSD.ORG Sun Oct 3 13:01:36 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 347FA106566C; Sun, 3 Oct 2010 13:01:36 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0618FC15; Sun, 3 Oct 2010 13:01:35 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5F96A73098; Sun, 3 Oct 2010 15:13:30 +0200 (CEST) Date: Sun, 3 Oct 2010 15:13:30 +0200 From: Luigi Rizzo To: FreeBSD Net , Rui Paulo , Juli Mallett , Ryan Stone , Robert Watson Message-ID: <20101003131330.GA85551@onelab2.iet.unipi.it> References: <4C9DA26D.7000309@freebsd.org> <4CA51024.8020307@freebsd.org> <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> <0DB8120D-C02A-49A1-8013-1ED818EDE7E6@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DB8120D-C02A-49A1-8013-1ED818EDE7E6@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: 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: Sun, 03 Oct 2010 13:01:36 -0000 On Sun, Oct 03, 2010 at 12:29:21AM +0100, Rui Paulo wrote: > On 2 Oct 2010, at 21:35, Juli Mallett wrote: > > > On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote: > >> On 2 Oct 2010, at 16:29, Robert Watson wrote: > >>> On Thu, 30 Sep 2010, Julian Elischer wrote: > >>>> 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.. > >>> > >>> 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. > > > > Can't we? What about a union, so that we can gradually convert things > > but keep ABI and API compatibility? I mean, as long as we use the > > right queue.h type, anyway, it should be consistent? STAILQ, > > presumably. > > Well, I don't have the layout of the mbuf struct offhand, but it's an idea worth investigating. what is the point of refactoring part of a struct that no new code is touching ? I'd like to keep this discussion on the original topics, i.e. performance-related issues (make room to embed mtags and other metadata such as FIB; have flexible per-socket initial padding so we don't always waste 100+ bytes just because ipv6+ipsec is compiled in; and so on). Please open another thread if you want to propose cosmetics or code refactoring or other unrelated changes Cheers luigi