Date: Sun, 12 Apr 2009 15:25:16 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Karim Fodil-Lemelin <kfl@xiplink.com> Cc: freebsd-net@freebsd.org Subject: Re: m_tag, malloc vs uma Message-ID: <alpine.BSF.2.00.0904121524040.19879@fledge.watson.org> In-Reply-To: <49E0F5EF.3030807@xiplink.com> References: <49DF5F75.6080607@xiplink.com> <alpine.BSF.2.00.0904101950350.36143@fledge.watson.org> <49DF9EAD.1050609@xiplink.com> <alpine.BSF.2.00.0904102057320.36143@fledge.watson.org> <49E0F5EF.3030807@xiplink.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904121524040.19879>