Re: Too small mbuf clusters

[mlelstv%serpens.de@localhost (Michael van Elst)]

martin%duskware.de@localhost (Martin Husemann) writes:

>would bad things happen if I would create an mbuf cluster < MINCLSIZE?

MCLBYTES < MINCLSIZE doesn't work. Clusters are often used to make a whole
packet (assuming 1500+ bytes for Ethernet) fit. Smaller clusters aren't
sufficient then and you need to create chains of clusters (like for
jumbo packets).

>It seems that FreeBSD uses clusters in situations where we would create
>a two mbuf chain, and I have a case where having continous memory makes
>things a lot easier (and the packet in question is > 1 MHLEN on
>all architectures with MSIZE=256).

The first thing this would do is waste memory for medium sized packets.
You have also to think about the mbuf pool being unlimited and the
cluster pool being limited.

mbufs were made to avoid fragmentation and a single mbuf is large
enough to fit all headers of a regular packet. If this isn't true
anymore for MSIZE=256 maybe enlarge MSIZE?


>Or (with all the pools we now have in place) would it make sense to
>lower MINCLSIZE to MHLEN+1 ?

I doubt this would improve things unless you treat this as a guarantee that
incoming packets must always be in a single mbuf and optimize away the code
that handles mbuf chains.

This would then complicate drivers that pass DMA segments as mbuf
chains to the stack, it kills processing of jumbo packets that are
larger than MCLBYTES and probably needs further treatment for large
packets from a TSO/GSO engine.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."