Date: Sat, 2 Oct 2010 20:07:02 +0100 From: Rui Paulo <rpaulo@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Ryan Stone <rysto32@gmail.com>, FreeBSD Net <net@freebsd.org> Subject: Re: mbuf changes Message-ID: <9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.1010021627230.49031@fledge.watson.org> References: <4C9DA26D.7000309@freebsd.org> <AANLkTim7oRyVYY3frn7=cn4Et8Acbcq9cXja_bR6YWvP@mail.gmail.com> <4CA51024.8020307@freebsd.org> <alpine.BSF.2.00.1010021627230.49031@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9AD4923A-72AE-4FE3-A869-3AF8ECBF17E2>