>   Is it true in NetBSD, as in 4.4BSD, that mbufs cannot override the
>   default m_free implementation? Is that the root problem?

I believe we NetBSD doesn't have such restriction.  MEXTADD should
deal with external mbuf other than M_CLUSTER.

>   I ask because it seems like mbufs whose reference/dereference
>   implementation can be overridden open interesting opportunities for
>   optimization.  For example, if you have some NIC whose receive buffer
>   is mapped into the host's virtual memory, then a driver can hand up
>   an mbuf which points into the NIC's receive buffer. The mbuf has a
>   special 'free' method assigned, which indicates to the NIC that the
>   mbuf's range in the receive buffer is eligible for re-use. In this way,
>   you avoid a copy to the host's memory.
> 
>   Is this optimization too complicated to consider?

The problem is we have no way to force release the receive buffer once
the corresponding mbuf is passed into the stack.  The mbuf can be left
referenced long time in socket if the application doesn't read or even
suspended.  To handle shortage of free receiving buffer, the driver
implementation should take care of allocate other mbuf cluster.

And much headache would be considering fragmentation.  If the hardware
fills data in manner of one buffer per packet, it can handled easier,
though the efficiency in usage is not so good.  If the hardware fills
data continuously among packets, the fragmentation in buffer is serious.
Again, there is no way to collect garbage in the unit smaller than page.

So it is much easier preallocating mbuf cluster and prepare it's address
for DMA for each packets, IMHO.

Some comments in dev/ieee1394/fwohci.c
	/*
	 * We may use receive buffer by external mbuf instead of copy here.
	 * But asynchronous receive buffer must be operate in buffer fill
	 * mode, so that each receive buffer will shared by multiple mbufs.
	 * If upper layer doesn't free mbuf soon, e.g. application program
	 * is suspended, buffer must be reallocated.
	 * Isochronous buffer must be operate in packet buffer mode, and
	 * it is easy to map receive buffer to external mbuf.  But it is
	 * used for broadcast/multicast only, and is expected not so
	 * performance sensitive for now.
	 * XXX: The performance may be important for multicast case,
	 * so we should revisit here later.
	 *						-- onoe
	 */

Atsushi Onoe