Date: Fri, 18 Jun 2004 11:39:52 -0400 From: Ed Maste <emaste@sandvine.com> To: freebsd-hackers@freebsd.org Subject: RE: memory mapped packet capturing - bpf replacement ? Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701BD40E0@mail.sandvine.com>
next in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C8533701BD40E0>