From owner-freebsd-arch@FreeBSD.ORG Thu Sep 7 19:03:54 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D759C16A4DE; Thu, 7 Sep 2006 19:03:54 +0000 (UTC) (envelope-from prvs=julian=39828977f@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4679943D58; Thu, 7 Sep 2006 19:03:54 +0000 (GMT) (envelope-from prvs=julian=39828977f@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 07 Sep 2006 12:03:51 -0700 Message-ID: <45006D19.4040607@elischer.org> Date: Thu, 07 Sep 2006 12:03:53 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <450035AD.3040600@freebsd.org> In-Reply-To: <450035AD.3040600@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, yar@comp.chem.msu.su, freebsd-arch@freebsd.org Subject: Re: Moving ethernet VLAN tags into the mbuf packet header (from mtags) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2006 19:03:55 -0000 Andre Oppermann wrote: > With the recent addition of a 16bit field for TSO into the mbuf packet > header we've got 16bits left over. I've reserved these bits for the > ethernet VLAN tagging of packet to do away with the allocated mbuf mtag. > > The change is rather mechanical. Patch available here: > > http://people.freebsd.org/~andre/vlan_pkthdr-20060907.diff > > The big advantage is that we don't have to do a UMA zalloc for very > incoming > vlan tagged packet. The m_pkthdr.ether_vlan field is always present > and its > validity depends on the M_VLANTAG flag. > > Testing & reviews encouraged. :-) > You are adding these fields to the mbuf pktheader in an unconditional manner. This means that even protocols that have no need or understanding of these fields are paying the price. I understand that at this point in history 99.999% of packets are for protocols for which these make sense but I wonder if we should consider whether mbufs should have some 'protocol specific' fields. mbuf tags are one way of doing this but maybe we can work out some method of doing this that doesn't require as much overhead (no extra allocations). Possibly by making some scheme whereby tags are allocated as part of the mbuf. I would suggest that each protocol have its own mbuf allocator that does preallocations according to what the active protocols might require. just vague ideas.