In message <200405040520.i445KRhv005292@caligula.anu.edu.au>Darren Reed writes
>Thank you for the comments, Jonathan.
>
>Taking into consideration what you've said, one is left to ask,
>what use is an MSIZE of 256 ?

>Is it because use of NetBSD is mainly geared towards uses where
>the average packet is 200 bytes or so in size ?

That's a fair question. My understanding is that the change (on all
ports, iirc) from 128 to 256 was motivated by IPv6.  Which, from most
quantitative performance metrics, is the tail wagging the dog.

As I said in an offlist note, I often wonder about having a separate
`tinymbuf' pool for ACK-only TCP output traffic.  There are certain
workloads where that seems quite justifiable. NICs with special queues
for small/QoS-preferred traffic may also benefit.


>Another question is, should someone be expected to recompile a
>kernel in order to tune/adjust this to best meet their needs or
>should the system just work and self-tune out of the box ?

Speaking personally, I'd prefer a world where config tuning almost
never required a kernel recompile. I think FreeBSD aims closer to that
goal than we do; I've found that makes friends, fast.  FreeBSD (4.x)
certainly has more boot-loader-configurable hooks, and better support
for modules, than does NetBSD. To go futher down that route --- say to
allow changing MSIZE without recompilation --- you'd have to put a
really smart linker into the kernel/bootloader; or move many small
computations (shifts, allocation sizes, etc) from compile-time
constants to run-time.

I think its premature to speculate on whether NetBSD wants to go that
far. (Given they very broad, diverse range of hardware we support, I
expect it'd be very hard to reach a conensus on one vs. the other.
Even if there *was* a consensus to, say, make NMBCLUSTERS boot-time
configurable on all ports, as I understand FreeBSD does.)

tech-kern would be a better place for that discussion.


>It would be interesting to count in m_freem how many mbufs are
>cascaded vs single entities or even try and discover what the
>distribution of mbuf chain sizes is.  Or is there a better place
>to measure this, such as IF_ENQUEUE ?

I'd measure separate statistics:
#1.  where drivers or media subroutines  IF_ENQUEUE() mbuf chains onto
     the per-protocol input queue; and 

#2. on the chains given to driver send entrypoints.