Date: Sat, 11 Apr 2009 13:27:09 -0700 From: Sam Leffler <sam@freebsd.org> To: Karim Fodil-Lemelin <kfl@xiplink.com> Cc: freebsd-net@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: m_tag, malloc vs uma Message-ID: <49E0FD1D.408@freebsd.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
Karim Fodil-Lemelin wrote:
> 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.
Typically tags are allocated in a context where decisions like the above
can be made so I'm not sure where you think m_tag_alloc might be used.
At one point vlan-tagged packets were identified by an mbuf tag.
Initially they were allocated by malloc but I moved that to a dedicated
zone w/ a noticeable benefit. However the overhead was still too high
and so we now space was added to the mbuf pkt hdr explicitly to hold
vlan data.
It's unlikely any scheme where the tags are allocated independent of the
mbufs will scale well enough to handle existing high speed interfaces.
There's been discussion about supporting emedding of tags in the mbuf
itself; this might come along as part of the variable-size mbuf work
that Jeff Roberson was working on. However unless one pre-allocated
space and/or defined a general mechanism for managing such space you'd
still potentially need to allocate tags separately when they are
attached at a later time. For embedded/inline mbuf tag space management
I think m_tag_free and m_tag_copy would sufficient for current usage.
Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E0FD1D.408>