memory mapped packet capturing - bpf replacement ?

[Ed Maste]

> A bit offtopic - what traffic generator you use ?

It's an in-house project somewhat similar to Emulab
<www.emulab.net>.  The traffic itself is generated by a
small number of FreeBSD boxes.

> > In my testing I found the call to microtime() to be quite
> > expensive.  (It will vary depending on which timecounter is
> > being used.)
> I haven't added the timestamp to the header yet, so what would you
> recommed to use ?

The problem is that microtime queries the timecounter on 
each use, and in my case of SMP the timecounter used is the
8254.  Accessing it takes a (relatively) long time.

If you need accurate timestamps on received packets you're
pretty much stuck with the overhead.  There's another
call, getmicrotime, which can "return a less precise, but 
faster to obtain, time."

I added a BPF ioctl (to our local tree) to turn off timestamps 
completely if they're not needed.
 
> > Is this in a SMP or uniprocesor environment?  I think your gain
> > from a ringbuffer interface will be more significant in the SMP
> > case.
> I gonna test it much more on both SMP and UP machines

All of my testing was done on SMP, where I think the benefit
from removing the read call will be greater than UP.

> This way, you intercept all Ethernet traffic trough ng_hub. Then,
> ng_bpf does BPF filtering, if any. If no filtering is needed, then
> ng_bpf node may be omitted. And, at last, ng_mmq does queuing.

Would connecting ng_mmq directly to the ng_ether lower hook
provide a useful datapoint?
		  
> > Are you using the same snap length (or copying the entire packet)
> > in each case?
> Hmm not sure what are you mean here.
> I am copying whole mbuf chain the same way BPF does. mbuf chain comes
> from the hook, and it can arrive to the hook from whatever source.

If you just run e.g. tcpdump, by default only the first
bit of the packet is actually copied.  But as BMS pointed
out you've set the snaplen to 32K so that won't be an issue
here.