Subject: Re: "const int" in conf/param.c?
To: Simon Burge <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 04/25/1999 12:18:14
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
> 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 ...
> #ifndef MCLSHIFT
> #define MCLSHIFT ...
> #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.