Date: Fri, 01 Feb 2013 14:04:38 +0100 From: Andre Oppermann <andre@freebsd.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: m_get2() name Message-ID: <510BBD66.4080903@freebsd.org> In-Reply-To: <20130201120414.GG91075@FreeBSD.org> References: <20130201120414.GG91075@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?510BBD66.4080903>