Bill,

After an interface bpf_attach()'s, BPF has a pointer to the interface,
however, BPF will not set the interface's back pointer (if_bpf) until
there is at least one listener. The back pointer is zeroed when the last
listener disconnects.

When BPF has one struct bpf_if per DLT, and an interface has one back
pointer per DLT, each back pointer is set only when there is a listener
for that DLT. Also, each back pointer is cleared when the last listener
for that DLT detaches.

Make sense so far?

So, in sum, when there are no listeners, the overhead for first, second,
and third DLTs is only the cost of comparing those back pointers to
NULL. I think NetBSD can afford that.

Dave

On Wed, Aug 07, 2002 at 10:34:01AM -0700, Bill Studenmund wrote:
> On Tue, 6 Aug 2002, Atsushi Onoe wrote:
> 
> > > > >  1) A driver supporting more than one DLT will call bpf with a new
> > > > >     procedure, bpfattach_multidlt, passing bpfattach_multidlt a mask
> > > > >     describing the DLTs the driver supports.
> > > >
> > > > Since the number of supported DLTs for a driver would be limited,
> > > > multiple calls to bpfattach_dlt() may be accepted.
> > > > This would help to implement streight forward implementation which splits
> > > > bpf_if for each DLT.
> > >
> > > But do we want multiple bpf_if's? My original idea was there would be one
> > > bpf, just it could hand back different packet types.
> >
> > Hmm, I've found my previous implementation.  I admit it is something like
> > ad hoc, but it works well and it has complete compatibility.
> 
> That code is missing one of the key points:
> 
> +#if NBPFILTER > 0
> +               if (ic->ic_rawbpf)
> +                       bpf_mtap(ic->ic_rawbpf, m0);
> +#endif
> 
> One of the main points of the effort was that when using the new
> interface, drivers would by default hand NOTHING to bpf. bpf has to call
> the driver to request packets of type X or type Y. Thus you only make
> packets IFF there is a consumer.
> 
> So if I understand your code right, (ic->ic_rawbpf) is a necessary but not
> sufficient condition to hand the packet off to bpf_mtap. The bpf system
> would have had to ask for that packet type too. So something like:
> 
> if ((ic->ic_rawbpf) && (ic->ic_raw_bpfcount))
> 	bpf_mtap(ic->ic_rawbpf, m0);
> 
> and ic->ic_raw_bpfcount is incremented when bpf asks for that packet type,
> and decrememnted when it says it's done.
> 
> "Asking" would be done by an ioctl.
> 
> This step is important as otherwise we are going to destroy performance.
> We're looking at adding 802.11, a driver specific type, and (I think) a
> common 802.11+stuff type. With the original 802.3, that's four packet
> types. Unless there's a consumer for each of these different frame types,
> I think we should NOT make them. :-)
> 
> That also was one of the reasons for wanting to break backwards
> compatability (*). By attaching the interface with the new call, you are
> informing the bpf layer that you will only make packets when it has asked
> you to. That's a big behavioral difference, so a different API seems
> appropriate.
> 
> (*) Of course old drivers still would work as they did.
> 
> Take care,
> 
> Bill

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