On 20.08.2013 00:38, Peter Grehan wrote:
Hi Andre,

  (moving to the more appropriate freebsd-net)

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.

  Sure. I'm not really upset since my code wasn't too far along, but with any 
API, you never know
who consumers might be so it's always worth being proactive about announcing 
it's removal.

Agreed.  OTOH there wasn't any in-tree user of it and posting before such 
removals
always yields at least one obscure hand wavy use or potential use of it.  So 
nothing
ever happens.

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?

  I was looking at something similar to Linux's vhost-net, where a guest's 
virtio ring would be
processed in-kernel. An mbuf chain with external buffers would be used to pass 
guest tx buffer/len
segments directly into FreeBSD drivers.

Is that like page flipping?

  The intent of M_NOFREE was to avoid small mbuf allocations/frees in what is a 
hot path. This code
was intended to run at 10/40G.

  Note this code isn't really generic - it would require interfaces to be 
'owned' by the guest,
except that direct PCI-level pass-through wouldn't be needed.

Do you have some example code showing how that is or can be done?

  If there's an alternative to M_NOFREE, I'd be more than happy to use that.

Set up your own (*ext_free) function and omit freeing of the mbuf itself.  Make
sure to properly track your mbufs to avoid leaking them.

--
Andre

_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to