Date: Fri, 18 Jun 2004 09:42:56 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Ed Maste <emaste@sandvine.com> Cc: freebsd-hackers@freebsd.org Subject: RE: memory mapped packet capturing - bpf replacement ? Message-ID: <200406181642.i5IGguWs013799@apollo.backplane.com> References: <FE045D4D9F7AED4CBFF1B3B813C8533701BD40E0@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
There's no reason why the time has to be in microseconds or even that
it must be adjusted to realtime. You also do not have to support
low power modes during testing which means that just time-stamping the
packets with the TSC plus a simple base offset to correct for variences
between cpus and machines on the network ought to be sufficient.
You can translate the numbers back into real time in the program which
dumps the data.
-Matt
Matthew Dillon
<dillon@backplane.com>
:> 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?200406181642.i5IGguWs013799>