Date: Sun, 01 Feb 2009 23:55:35 -0800 From: Julian Elischer <julian@elischer.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: freebsd-net@freebsd.org Subject: Re: mbuf revision, testers/comments wanted. Message-ID: <4986A6F7.7080402@elischer.org> In-Reply-To: <20090131125100.N983@desktop> References: <20090131125100.N983@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeff Roberson wrote: > http://people.freebsd.org/~jeff/mbuf_ref2.diff > > Hello, > > I have been experimenting with different revisions to the mbuf api to > improve performance and simplify code. This patch is the first of > several proposed steps towards those goals. The aim of this patch is > two fold; > > 1) Revising the reference counting system so that we can eliminate > reference uma zones and the significant uma_find_refcnt() costs in some > workloads. This is done by making all mbufs reference counted and using > the owning mbuf's ref for the ext_ref. In this model we never reference > data, we only reference other mbufs owning the data. > > 2) Improve allocation and free performance by reducing the special > cases in the format and using inlines when appropriate. In particular, > the simplification of the m_ext structure yields less code and confusion > for dealing with external storage on free. The ctor/dtor mbuf routines > are no longer used. A zone pointer and length was added to struct mbuf > to simplify free and size calculations. > > A number of routines were made much, much simpler by the addition of a > 16bit size field. Previously we dependend on calculating the size by > figuring out if it was an ext, pkthdr, or standard mbuf. Ultimately, > this patch moves us closer to having a size agnostic mbuf which we can > use to experiment with different allocation sizes or even backending to > malloc for dynamically sized mbufs. > > I would appreciate testing feedback from varied workloads to make sure > there are no bugs before I go forward with this. I have tested only > host oriented networking with a few drivers. It is not anticipated that > there will be any significant incompatibilities introduced with this > round but there is always that possibility. > generally I like it. We discussed someof this before.. It would be nice if you added more comments than you stripped out I personally think that some descriptions of what you are doing would be great in teh comments. ascii art too if needed... Also some diagrams in any form you want would be nice.. all that about 1000 words and a picture is true. > Thanks, > Jeff > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4986A6F7.7080402>