On 8/20/13 6:38 AM, 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.
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.
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.
If there's an alternative to M_NOFREE, I'd be more than happy to
use that.
I think an alternative would be a reference counted version. we used
to have that and NetBSD had a quite sophisticated mbuf system where
there were multiple owners of mbufs..
they wouldn't be freed until the last one freed it but I don't
remember the details.
later,
Peter.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
