Max Laier wrote:
On Tuesday 28 June 2005 14:15, Milan Obuch wrote:
The problem here is that this has to be a static thing (otherwise you need an
additional malloc and your possible performance gain is lost). If you change
MSIZE or sizeof(struct pkthdr) on a kernel option, you will have to recompile
all network device drivers and everything else that touches mbufs. This will
effectively prevent the use of 3rd party drivers. So it has to be one size
fits all, which is - most likely - the minimal version pkthdr and additional
mallocs when needed.
We already chaned the mbuf from 128 to 256 bytes a while ago, so having
more in the
header is not necessarily a bad thing.. it generally wasn't a problem
when it was only
capable of holding 100 or so bytes of data. Even with an expanded header
we are still
talking of holding up to 200 or so bytes of data in the mbuf.
I'd like to propose an expandable format for mbufs...
Pitty I'm about 25 years too late.
[header1][total headerlength]
[offset to first tag]
[more header info] m_data-------\
[tag1] [tag1 len] |
[tag1 data] |
[tag2] [tag2 len] |
[tag2 data] |
[end of header] |
... |
packet data <-------------------/
...
[end of mbuf
On the other hand a zone allocator for mbuf tags might be the right
sollution here?
See zone(9) for details. Basically we would have a cache of mbuf tags that
get reused, thus taking of pressure off the rest of the memory management
system. Again we have to evaluate carefully if that is actually a
performance gain or hit - though I certainly suspect a gain.
but tags can be variable length.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
