Date: Fri, 1 Feb 2013 17:15:55 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org> Cc: net@FreeBSD.org Subject: Re: m_get2() name Message-ID: <20130201131555.GJ91075@glebius.int.ru> In-Reply-To: <510BBD66.4080903@freebsd.org> References: <20130201120414.GG91075@FreeBSD.org> <510BBD66.4080903@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 01, 2013 at 02:04:38PM +0100, Andre Oppermann wrote: A> > The m_get2() function allocates a single mbuf with enough space A> > to hold specified amount of data. It can return either a single mbuf, A> > an mbuf with a standard cluster, page size cluster, or jumbo cluster. A> A> While m_get2() is a good function, I'm not too happy with it returning A> jumbo clusters. The size of jumbo cluster is not well specified and A> can be anything above 2K, from 4K to 16K or more. The network stack A> hacker can't rely on any particular size above PAGE_SIZE to be present. A> A> So I recommend to make PAGE_SIZE the largest cluster size to be available A> in a single mbuf allocator. PAGE_SIZE is a known quantity and plays well A> with the allocator. Anything larger than PAGE_SIZE causes contig_malloc A> to be used as the requirement is physically contiguous pages for those A> clusters. After some uptime this may become more difficult to allocate A> and can lead to premature allocation failures while still plenty of A> memory would be around. The allocation overhead for such jumbo zones A> is higher in UMA than for PAGE_SIZE clusters. I am against API that forbids allocating jumbo clusters. The kernel has them, albeit their disadvantages. And API should offer them to drivers and modules. If some module doesn't want to get a jumbo clustered mbuf from m_get2(), then it should not request above PAGE_SIZE from m_get2() and that's all. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130201131555.GJ91075>