There are two separate linux worlds:

  1. The kernel world
  2. The user world

These worlds are viewed here as being joined via system calls and shared
memory.

1. In the kernel there are packets seen by a network device and packets that
   are made available to user programs.  A number of things can happen along
   the way:

  a. A packet can be dropped by the hardware device because it cannot handle
     the load.
  b. A packet can be dropped because there is no room for the packet in
     the shared kernel/user buffer set aside for the purpose of holding it
     for a user process.
  c. A packet can be discarded because it fails to pass through a kernel
     filter.
     
2. In the user process there are packets on the shared kernel/user buffer
   waiting to be read and then released by the user process.  The process
   can:

   a. discard (drop) packets very quickly by not even reading them, by just
      changing a value in shared memory indicating to the kernel that it has
      finished using the packet.
   
   b. pass a pointer to a packet via a callback mechanism to an application
      subroutine which does what it wants with it and then returns so that
      the packet (residing on the shared kernel/user buffer) can be released
      using the same mechanism in (a).  This is essentialy what happens in
      libpcap when a libpcap based application calls a libpcap library routine
      to "read a packet off the network".

There is a system call which is used to return packet statistics generated while
the kernel is placing (or attempting to place) a packet on the ring.  It
returns two values:

   1. ps_recv: the sum of the number of packets which have passed the filter
      and successfully been placed on the ring, and the number of packets which
      were dropped (after passing the filter) because the ring was full.

   2. ps_drop: the number of packets which were dropped due to lack of resources.

To calculate the number of packets which were made available to the user
process one would have to subtract ps_drop from ps_recv.  There is no
precise way to determine how many packets were filtered out.  One would
have to look at the interface statistics (/proc/net/dev) for a hint.

Note: Before returning to the user program the statistics system call clears
      the counters.  The linux libpcap subroutine pcap_stats, which calls this
      system call, accumulates them so that each call to it returns the
      grand total since initializing the ring.

BSD on the other hand ...

   1. ps_recv is the total count of packets handed to the filter (not packets
      that passed the filter) and packets that were dropped for lack of
      buffer space since initializing the ring.  

   2. ps_drop is the total count of packets dropped because the kernel ran out
      of the alloted buffer space since initializing the ring.

The recieved counts, returned by pcap_stats, on both Linux and BSD will include
packets not yet seen by the application.

Consequently, if there is only a null filter, then BSD and Linux will
(or should have) the same received counts under the same network load.

If a filter were to discard 50 percent of the packets then Linux will
reflect that fact in "ps_recv" while BSD will still indicate the total number
of packets seen on the net.

How am I doing?