Subject: bpf statistics
To: None <tech-net@netbsd.org>
From: Darren Reed <darrenr@reed.wattle.id.au>
List: tech-net
Date: 04/15/2004 08:13:06
In looking at the statistics BPF keeps, I've discovered what I consider
to be a serious deficiency.

It keeps track of two numbers: number of packet delivered to the BPF tap
(call it 'X') and the number of packets that matched the BPF filter but
could not be put in a buffer for delivery to the application ('Y').

An application should see Y-X packets, shouldn't it ?

No.

X is measured pre-filter, Y is measured post filter.

The only relationship between these is "Y <= X".

What I'd like to add is a count of the number of times catchpacket() is
called - bd_ccount (call it 'Z'.)  The relationship between these three
statistics would be "Y <= Z <= X".  No "X+Y=Z" or similar.  What sort
of difference would this make?  When you ^C tcpdump, it'd be trivial
to then get three lines of output:

166 packets received by filter
100 packets matched by filter
0 packets dropped by kernel

rather than just:
166 packets received by filter
0 packets dropped by kernel

Whether or not tcpdump adds its own line like:
99 packets displayed

is up to it, but something that's not easily recognised is that these
numbers, above, can all be different.  Depending on your application,
it may or may not be relevant to know the various details.

I believe this is a valuable enough metric to add that I'd be willing
to do what's required to keep applications that only expect the old
bpf_stat struct working.

Does anyone see why this metric isn't useful, or are there any other
metrics for measuring bpf that should be added ?

Furthermore, is it worth adding an array like "bs_xxx[42]" to the
bpf_stat structure to allow it to grow without needing further ioctl
compatibility changes ?  (42 is just an arbitrary number.

Darren