From owner-freebsd-net@FreeBSD.ORG Sun Apr 12 14:25:17 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 7A07F1065670 for ; Sun, 12 Apr 2009 14:25:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 537A88FC13 for ; Sun, 12 Apr 2009 14:25:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0A6CD46B1A; Sun, 12 Apr 2009 10:25:17 -0400 (EDT) Date: Sun, 12 Apr 2009 15:25:16 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Karim Fodil-Lemelin In-Reply-To: <49E0F5EF.3030807@xiplink.com> Message-ID: References: <49DF5F75.6080607@xiplink.com> <49DF9EAD.1050609@xiplink.com> <49E0F5EF.3030807@xiplink.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Sun, 12 Apr 2009 14:25:17 -0000 On Sat, 11 Apr 2009, Karim Fodil-Lemelin wrote: >> 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. My feeling is that, for types not maintained by the m_tag framework itself, the m_tag_ops.m_tag_copy() method should take an existing m_tag and produce a copy of it appropriate for inserting on the list of a copied mbuf header. That way both the allocation and copying of the m_tag are left to the subsystem that owns it, allowing it to use its own memory type, perform deep copying or reference counting of other structures, etc. Robert N M Watson Computer Laboratory University of Cambridge