Julian's netowrking challenge 2005

[Julian Elischer]

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.