m_get2() name

[Andre Oppermann]

On 01.02.2013 13:04, Gleb Smirnoff wrote:
>    Hi!
>
>    The m_get2() function allocates a single mbuf with enough space
> to hold specified amount of data. It can return either a single mbuf,
> an mbuf with a standard cluster, page size cluster, or jumbo cluster.

While m_get2() is a good function, I'm not too happy with it returning
jumbo clusters.  The size of jumbo cluster is not well specified and
can be anything above 2K, from 4K to 16K or more.  The network stack
hacker can't rely on any particular size above PAGE_SIZE to be present.

So I recommend to make PAGE_SIZE the largest cluster size to be available
in a single mbuf allocator.  PAGE_SIZE is a known quantity and plays well
with the allocator.  Anything larger than PAGE_SIZE causes contig_malloc
to be used as the requirement is physically contiguous pages for those
clusters.  After some uptime this may become more difficult to allocate
and can lead to premature allocation failures while still plenty of
memory would be around.  The allocation overhead for such jumbo zones
is higher in UMA than for PAGE_SIZE clusters.

There is also some overlap with m_getm2() which returns an mbuf chain
of specified size.  The only difference being chain vs. single mbuf.
m_get2() can be simply implemented on top of m_getm2() by using the flags
field to restrict it to one mbuf only instead of a chain to avoid code
duplication.

>    It is alredy utilized in pfsync, bpf, libalias and soon to be utilized
> in ieee802111. There are probably more places in stack where it can be used.
>
>    The question is about its name. Once introduced, I just gave it name
> "m_get2" to avoid discussion with myself about bikeshed colour and continue
> hacking. Now it is getting used wider, and before we branch any stable branch
> off the head, we have last chance to rename it to smth more meaningful.

This is mostly matter of "compatibility" we want keep with original BSD code.

The right names would be m_get() and m_getm() for single mbuf and chain
allocations of a certain supplied minimum size.

As far as I see it the other BSDs have evolved quite a bit and a significant
number of differences exists these days making porting more involved than
just copying the files.  Having a clean API would be only a minor additional
inconvenience IMHO.

--
Andre