Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Apr 2009 15:56:31 -0400
From:      Karim Fodil-Lemelin <kfl@xiplink.com>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: m_tag, malloc vs uma
Message-ID:  <49E0F5EF.3030807@xiplink.com>
In-Reply-To: <alpine.BSF.2.00.0904102057320.36143@fledge.watson.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E0F5EF.3030807>