From owner-freebsd-net@FreeBSD.ORG Sat Apr 11 19:56:37 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0909A106564A for ; Sat, 11 Apr 2009 19:56:37 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from smtp161.iad.emailsrvr.com (smtp161.iad.emailsrvr.com [207.97.245.161]) by mx1.freebsd.org (Postfix) with ESMTP id D47618FC1A for ; Sat, 11 Apr 2009 19:56:36 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from relay16.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay16.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 304821B4013; Sat, 11 Apr 2009 15:56:31 -0400 (EDT) Received: by relay16.relay.iad.mlsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id E9DE81B4003; Sat, 11 Apr 2009 15:56:30 -0400 (EDT) Message-ID: <49E0F5EF.3030807@xiplink.com> Date: Sat, 11 Apr 2009 15:56:31 -0400 From: Karim Fodil-Lemelin User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Robert Watson References: <49DF5F75.6080607@xiplink.com> <49DF9EAD.1050609@xiplink.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: m_tag, malloc vs uma 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, 11 Apr 2009 19:56:37 -0000 Robert Watson wrote: > On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote: > >> Thank you for the answer, clear and concise. I asked the question >> because I had modified pf_get_mtag() to use uma directly in the hope >> that it would be faster then calling malloc. But since pf_mtag is >> 20bytes, malloc will end up using a fixed 32bytes zone and I >> shouldn't expect much speed gain from using something like (except >> some savings from not having to select the 32bytes zone): > > There is another small overhead, the critical section used to protect > the consistency of the per-CPU malloc type alloc and free counters, > but it's also very small. > > I think it would be desirable to make a change to more flexible m_tag > types for 8.0, but I'm not sure I have time to implement/test it. Is > this something you might be interested in working on? I'm thinking of > basically replacing the m_tag_free pointer with a pointer to a small > vector of operations, possibly something along these lines: > > struct m_tag_ops { > void (*m_tag_free)(struct m_tag *); > struct m_tag (*m_tag_copy)(struct m_tag *); > }; > > If the m_tag_ops pointer is NULL, we go with today's default > (requiring minimal change of existing consumers). I'm not sure if > there are any other function pointers we'd need at this point? Is the m_tag_copy an 'overloaded' function for the current m_tag_copy or something else? Now it could also be interesting to have another function pointer to overload m_tag_alloc to give more control over which zone the user wants its tags from (ex: pf_mtag ...). The interest is there not sure if the schedule will allow it but that depends if the new m_tag designs allows me to squeeze some performances in. Karim.