In message <199904251255.WAA14243@balrog.supp.cpr.itg.telecom.com.au>,
Simon Burg e writes:

>A few people have commented on why not leave msize and mclbytes in
>conf/param.c as plain old patchable ints.  Part of the reason was the
>comment preceding the variables:
>
>	/*
>	 * Actual network mbuf sizes (read-only), for netstat.
>	 */
>
>These two variables aren't used anywhere in the kernel.

That's no fun.


>So I looked a bit further ... here's how each arch defines MSIZE and
>MCLBYTES.
>
>	ARCH	MSIZE		MCLBYTES
>	alpha	def  256	cond 1<<11
>	arm32	def  128	def  1<<11
>	bebox	def  128	def  1<<11
>	i386	def  128	cond 1<<11
>	m68k	def  128	cond 1<<11
>	macppc	def  128	def  1<<11
>	news	def  128	conf 1<<11
>	ofppc	def  128	def  1<<11
>	pc532	cond 128	cond 1<<11
>	pica	def  128	def  1<<11 (but gets MCLSHIFT wrong)

Might as well fix it (Unless the arc port is going into the tree RSN?)

>	pmax	def  128	cond 1<<11
>	powerpc	def  128	def  1<<11
>	sparc	def  128	def  1<<11
>	sparc64	def  128	def  1<<11
>	vax	cond 128	cond 1<<11
>
>Two questions arise from this:
>
> + Why does the alpha want 256 byte mbufs?  If the 64 bit architecture
>   is really an issue, should sparc64 also have 256 byte mbufs?

Header overhead. There's just not much left out of 128 bytes after
subtracting out the 64-bit pointers and ints and what-have-you, and
then aligning the remainder to a 64-bit boundary, etc.


> + Modulo the alpha mbuf size issue, should we move the default setting
>   of MSIZE and MCLBYTES to sys/param.h?  We can have:
>
>	#ifndef MSIZE
>	#define MSIZE ...
>	#endif
>	#ifndef MCLSHIFT
>	#define MCLSHIFT ...
>	#endif
>	#define MCLBYTES (1 << MCLSHIFT)
>
>   and each port can override this if it wants to in machine/param.h if
>   it really wants to.
>
>So, is there any real-world use for ever changing these sizes?

Yes, there is. Historically they were 512 bytes or 1k.  I agitated to
get those few ports which hadn't bumped them to 2k to do so, so that
single mbuf cluster can hold an entire Ethernet frame (common packet
size).  The assumption is that most machines have sufficent memory
that wasting ~512k is a win over the costs of allocating and
deallocating two clusters.

If you're on FDDI, then a > 4k-plus-headers cluster is desirable (or
4k plus ordinary mbufs; i dont know how well tuned, space-wise, the
allocation code is for that case).

>Along the same issue, there seems at first glance to be a lot in the
>various machine/*.h files that is needlessly duplicated.  Is it worth
>the effort to clean all this up?

Yes :).  Or at least documented.