mbuf changes

[Luigi Rizzo]

On Sat, Sep 25, 2010 at 10:20:19AM +0200, Andre Oppermann wrote:
> On 25.09.2010 09:19, Julian Elischer wrote:
> >over the last few years there has been a bit of talk about some changes 
> >people want to see in mbufs
> >for 9.x
> >extra fields, changes in the way things are done, etc.
> >
> >If you are one of these people, pipe up now..
> >
> >to get the ball rolling..
> >
> >* Add a field for the current FIB.. currently this is 4 bits stolen from 
> >the flags.
> >what would be a good width: 8,12,16,24,32 bits?
> >this would allow setfib to use numbers greater than 16 (the current max)
> 
> 16 bits for 65535 FIB's should be sufficient.  More than that seems really
> excessive.
> 
> >* Preallocating some room for some number of tags before we start 
> >allocating
> >(expensively) new ones.
> 
> Within the mbuf?  Or at external and attached mbuf allocation time?  Tags
> are variable width and such not really suitable for pre-allocation.

my idea was to have an extra field in the mbuf to tell how much room
should be reserved/used for metadata (such as mtags) after
the payload area so you don't need to change the allocator, and
possibly can even modify this on an existing mbuf.
Almost always mbufs have spare room (e.g. incoming pkts have all
data in the cluster and mostly empty mdata; outgoing, except
for rare cases, tend to be in a similar situation.
So this approach would allow to take an already allocated
mbuf and put the mtag in the spare area after the data.

> >* dynamically working out what the front padding size should be.. per 
> >session.. i.e.
...
> We already have "max_linkhdr" that specifies how much space is left

the issue is that this is global (kern.ipc.max_linkhdr)
but perhaps it would be good if we could make it per-socket
so either we set it with a setsockopt, or the system can
adjust back the value for specific sockets once it detects
that it needs extra room
(if you make the default too large, the useful room in the mdata
area becomes too small unless perhaps we move to 512-bytes mbufs

cheers
luigi