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.
_______________________________________________
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"
