>Don't you mean wasting ~1/2k?

Hi Lloyd, long time no see...

Yes, sorry. Post-swimming, pre-coffee fagitue :)


>This still doesn't solve the problem of mid sized ethernet packets
>needing two mbufs,


Well, no. The statistics I'm familiar with say that for backbone
traffic, half the total bytes come in max-len Ethernet frames and the
other half of the bytes are in `smaller' to `small' packets, with the
exact distribution depends on how new the data is.

But if you care, you can tune around that, by changing MINCLSIZE.
I've done that for some research boards we built here. Not hard.
Would you prefer to make it sysctl'able or per-interface
(at the cost of a couple of extra memory refs?


>and the somewhat obfuscated code needed to allocate
>mbufs and clusters correctly c.f. dev/ic/dp8390.c. It wouldn't be so
>awful if it weren't for the extra jiggery pokery with:
>
>	mbuf packet headers
>	aligning the packet data, while keeping the packet headers in the mbuf
>	removing the packet headers after the bpf tap
>
>There are better ways of working with mbufs than the way used in
>dev/ic/dp8390.c even if they aren't _much_ better. I am sure that all
>the maths to do with aligning packet data can be done at compile time.
>If my laptop changes its memory alignment requirements or ethernet
>headers change size while my laptop is running, I will be worried about
>more than code elegance.

I thought the idea is that the first mbuf in the chain has a pkthdr,
but the rest don't, so the alignment does/can change? I suppose one
could precompute each case, but getting them down to compile-time
constants might be hairy.