Subject: Re: mbuf pros and cons [was Re: mtod abuse?]
To: Pavel Cahyna <email@example.com>
From: Sam Leffler <firstname.lastname@example.org>
Date: 08/09/2004 08:47:52
On Monday 09 August 2004 04:53 am, Pavel Cahyna wrote:
> > BTW, does anyone have a comparison of mbufs with solaris mblocks and
> > linux skbufs (both in terms of perf and usability)?
> There is a short comparison in Czech here:
> Briefly, the skbuf is a single memory area which has enough space before
> it to be able to prepend any headers, while data in mbufs can be
> fragmented - in multiple mbufs chained together. This makes implementation
> of zero-copy send easy and clean - you allocate a mbuf which points to
> user data and headers are prepended to it in separate mbufs. To get
> zero-copy send, Linux skbufs had to be somehow hacked.
> Unfortunately, there is no comparison of speed. But I believe all the
> benefits of skbufs can be obtained with mbufs by allocating sufficiently
> large mbufs. Is that right?
When skbufs "work" they are simple to use and convenient (ignoring other
design warts). Having data contiguous can be a big win (e.g. eliminating
scatter-gather overhead). However they do not always work and then things
can get complicated and the effects can be far-reaching. In general
"linearizing" network data can significantly improve performance. The
problem is that you need to guarantee this contiguous layout or any code that
processes the data has to handle both the linear and non-linear case. mbufs
were designed in a time when memory was precious and optimizing for space was
a valid design choice. Since then the design has been extended to support
more linearized management of data. An mbuf replacement has been needed for
a while but I don't think skbuf's are a good choice.
As to speed I've seen no significant performance difference between mbufs and
skbufs in my uses (in 2.4 and 2.6 Linux kernels). Other issues tend to