From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 19:15:34 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F3C716A41C for ; Tue, 28 Jun 2005 19:15:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (www.vicor.com [12.155.182.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3677C43D49 for ; Tue, 28 Jun 2005 19:15:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id E186A4CE931; Tue, 28 Jun 2005 12:15:33 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60594-09; Tue, 28 Jun 2005 12:15:33 -0700 (PDT) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 5433C4CE918; Tue, 28 Jun 2005 12:15:33 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 0AF8F7A403; Tue, 28 Jun 2005 12:15:33 -0700 (PDT) Message-ID: <42C1A204.1040504@elischer.org> Date: Tue, 28 Jun 2005 12:16:20 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Max Laier References: <42C0DB3B.6000606@elischer.org> <200506281409.23885.max@love2party.net> <200506281415.36453.net@dino.sk> <200506281437.11835.max@love2party.net> In-Reply-To: <200506281437.11835.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: freebsd-net@freebsd.org, Milan Obuch Subject: Re: Julian's netowrking challenge 2005 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: Tue, 28 Jun 2005 19:15:34 -0000 Max Laier wrote: >On Tuesday 28 June 2005 14:15, Milan Obuch wrote: > > > >The problem here is that this has to be a static thing (otherwise you need an >additional malloc and your possible performance gain is lost). If you change >MSIZE or sizeof(struct pkthdr) on a kernel option, you will have to recompile >all network device drivers and everything else that touches mbufs. This will >effectively prevent the use of 3rd party drivers. So it has to be one size >fits all, which is - most likely - the minimal version pkthdr and additional >mallocs when needed. > > > We already chaned the mbuf from 128 to 256 bytes a while ago, so having more in the header is not necessarily a bad thing.. it generally wasn't a problem when it was only capable of holding 100 or so bytes of data. Even with an expanded header we are still talking of holding up to 200 or so bytes of data in the mbuf. I'd like to propose an expandable format for mbufs... Pitty I'm about 25 years too late. [header1][total headerlength] [offset to first tag] [more header info] m_data-------\ [tag1] [tag1 len] | [tag1 data] | [tag2] [tag2 len] | [tag2 data] | [end of header] | ... | packet data <-------------------/ ... [end of mbuf >>>On the other hand a zone allocator for mbuf tags might be the right >>>sollution here? >>> >>> >> >> > >See zone(9) for details. Basically we would have a cache of mbuf tags that >get reused, thus taking of pressure off the rest of the memory management >system. Again we have to evaluate carefully if that is actually a >performance gain or hit - though I certainly suspect a gain. > > but tags can be variable length.