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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
