[HEADS-UP] mbuma is in the tree

[Wes Peters]

On Wednesday 02 June 2004 07:12, Bosko Milekic wrote:
>
>   If you read the paper on mbuma, you'll notice that I point out that it
>   would be worth investigating whether, in scenarios where an m_tag is
>   ALWAYS required per packet (e.g., MAC), providing a secondary zone with
>   pre-allocated m_tags for packet headers might be worth it.  Prior to
>   this work, however, I suggest we investigate the possibility of using
>   smaller mini-mbufs whenever clusters are used so that space wastage
>   is reduced.

It may also be worthwhile investigating eliminating clusters entirely.  This 
is the point Poul-Henning, Robert and I were trying to make at the end of 
you talk at BSDCan.

Since the double allocation required to create a cluster makes the locking 
(and cache slushing) requirements go up, it is probably worthwhile to 
investigate if raising the nominal mbuf size doesn't end up decreasing 
overall memory pressure.  If you allocate more memory, but the allocation 
takes less time due to the simpler locking, you may actually decrease the 
total memory need.

This is worth investigating partly because it is such a simple change.  I 
propose investigating with mbuf size of 2K, large enough to fit standard 
ethernet frames, and a cluster size of 8K, which means a cluster mbuf is 
large enough to hold a 9K jumbo frame.

Now that you've got mbuma in the tree, I can test this for you, unless this 
proposal catches your interest enough to give it a try.  I'll see if I 
can't get a couple of our beefier machines at work updated to -CURRENT in 
the next week.

Thanks for the good work.

-- 

        Where am I, and what am I doing in this handbasket?

Wes Peters                                               wes at softweyr.com