From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 16:37:27 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 26899106564A; Sat, 25 Sep 2010 16:37:27 +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 DF8E68FC16; Sat, 25 Sep 2010 16:37:26 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 0631E73098; Sat, 25 Sep 2010 18:30:11 +0200 (CEST) Date: Sat, 25 Sep 2010 18:30:11 +0200 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20100925163010.GA76213@onelab2.iet.unipi.it> References: <4C9DA26D.7000309@freebsd.org> <4C9DB0C3.5010601@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C9DB0C3.5010601@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: 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, 25 Sep 2010 16:37:27 -0000 On Sat, Sep 25, 2010 at 10:20:19AM +0200, Andre Oppermann wrote: > On 25.09.2010 09:19, Julian Elischer wrote: > >over the last few years there has been a bit of talk about some changes > >people want to see in mbufs > >for 9.x > >extra fields, changes in the way things are done, etc. > > > >If you are one of these people, pipe up now.. > > > >to get the ball rolling.. > > > >* Add a field for the current FIB.. currently this is 4 bits stolen from > >the flags. > >what would be a good width: 8,12,16,24,32 bits? > >this would allow setfib to use numbers greater than 16 (the current max) > > 16 bits for 65535 FIB's should be sufficient. More than that seems really > excessive. > > >* Preallocating some room for some number of tags before we start > >allocating > >(expensively) new ones. > > Within the mbuf? Or at external and attached mbuf allocation time? Tags > are variable width and such not really suitable for pre-allocation. my idea was to have an extra field in the mbuf to tell how much room should be reserved/used for metadata (such as mtags) after the payload area so you don't need to change the allocator, and possibly can even modify this on an existing mbuf. Almost always mbufs have spare room (e.g. incoming pkts have all data in the cluster and mostly empty mdata; outgoing, except for rare cases, tend to be in a similar situation. So this approach would allow to take an already allocated mbuf and put the mtag in the spare area after the data. > >* dynamically working out what the front padding size should be.. per > >session.. i.e. ... > We already have "max_linkhdr" that specifies how much space is left the issue is that this is global (kern.ipc.max_linkhdr) but perhaps it would be good if we could make it per-socket so either we set it with a setsockopt, or the system can adjust back the value for specific sockets once it detects that it needs extra room (if you make the default too large, the useful room in the mdata area becomes too small unless perhaps we move to 512-bytes mbufs cheers luigi