On Mon, Sep 30, 2002 at 08:02:07AM +0900, Atsushi Onoe wrote:
> I'll take care of these once we reach consensus how to fix.  But
> now I come to think we should nuke fake mbuf here, and instead, we
> should introduce some bpf dependent code, such as bpf_mtap2 I posted.
> The main reason is a faked mbuf still cannot be handled as normal mbuf
> (cannot be freed, referenced...) so that we hard to define the concrete
> behavior for it.  And someday, we will face bugs as a result of mixup
> a faked mbuf to normal mbuf.

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

  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?

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933