On 19.08.2013 19:40, Peter Grehan wrote:
I recently tried some experiments to reduce the number of mbuf and
cluster allocations in a 40G NIC driver. M_NOFREE and EXT_EXTREF proved
very useful and the code changes to the kernel were minimal. See
user/np/cxl_tuning. The experiment was quite successful and I was
planning to bring in most of those changes to HEAD. I was hoping to get
some runtime mileage on the approach in general before tweaking the
ctors/dtors for jumpbo, jumbo9, jumbo16 to allow for an mbuf+refcnt
within the cluster. But now M_NOFREE has vanished without a warning...
I also had a virtualization work-in-progress where static mbufs were
allocated in the kernel and
M_NOFREE set.
Might be worth sending a prior heads-up for these type of changes.
I'm sorry for ambushing but this stuff has to be done. I have provided
an alternative way of handling it and I'm happy to help you with your
use case to make it good for you and to prevent the mbuf system from
getting bloated and hackish again.
Mbuf is a core system for the kernel and we should avoid to kitchen-sink
it again while at the same time to keep speedy enough to keep up with
the speed requirements.
I believe it would be bad to have Navdeep, you and others invent their
own network buffer management routines over again in slightly different
ways tailored to each immediate use case.
Can you please describe your intended use of M_NOFREE to better understand
the shortcomings of the current mbuf systems and the additional advantages
of the M_NOFREE case?
--
Andre
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
