M_NOFREE removal (was Re: svn commit: r254520 - in head/sys: kern sys)

[Julian Elischer]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
>