BPF tweak; negative impact?

[Peter Van Epp]

	Its unlikely, since the bpf patch only activates if there is a timeout
on a select system call. Tcpdump polls the bpf interface, it doesn't do a 
select with timeout so the patch code won't activate. You may need to increase
the size of the bpf buffer (there is an iocntrl to do so, by default its 8k,
I think 64K is a nicer value larger may be better modulo DMA boundary issues
all interesting things to experiment with and measure :-)) since it is bpf that
is reporting the dropped packets that the kernel gave it but your application
didn't succeed in clearing the bpf buffers in time. The argus "man" output
from ra should be reporting the same numbers in the "dropped" field (if not
Carter has a bug :-)) since thats where argus gets that particular stat.
	A more insideous one (and what I see when I lose packets, which may 
be because I hard coded a large buffer size into bpf) is the packets not 
getting transferred to bpf from the kernel. There is undoubtably an interface
ioctl that will tell me what the enet card saw but the kernel didn't get to
the bpf interface but I haven't poked that far yet. I know this happens because
I coded a check in to bpf to check what it saw against what argus saw which 
matched, but didn't match the number of packets that tcpreplay put on the wire
the number that made the bpf interface was less than the number actually 
received).
	If you are running argus and something else (such as tcpdump) at the
same time on a fast link you will likely run out of performance and lose 
packets (because the kernel bpf is copying the same packet to multiple user
level bpf instances increasing your requirement for memory bandwith). You
might want to try commenting out the KTRACE option in the kernel config (which
adds 4 machine cycles per system call) and see if that helps. I do it 
automatically when I build a new kernel. Testing if it does anything usefull
with a full load is on my list of interesting things to do but hasn't been 
done yet so I don't know if it makes a signifigant difference. I also comment 
out all the IPV6 stuff on the theory that is one less path the kernel has to 
think about which again may or may not make a difference. So many performance
issues so little test time :-).

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

> 
> Could the bpf tweak for FreeBSD and argus be causing a severely negative
> impact upon other applications that are BPF intensive?  For example,
> I've seen the following from one application:
> 
> received 98933 packets and dropped 32460(32.810%) packets.
> 
> tcpdump 3.6.2 says:
> 
>  58926 packets received by filter
>  54615 packets dropped by kernel
> 
> (using libpcap 0.6.2, as well)
> 
> Now, that improves dramatically (in the tcpdump case) if I log to a
> file only, but even so, I'm concerned that more data may be going
> missing than I intend.
> 
> Is there a way to get these sort of statistics from argus; how many
> packets were seen by the kernel, but dropped before the bpf buffer could
> be emptied?
> 
> Thanks,
> 
> Scott
> 
>