m_tag, malloc vs uma

[Robert Watson]

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