Date: Mon, 14 Jun 2004 19:08:40 +0300 From: Sergey Lyubka <devnull@uptsoft.com> To: freebsd-hackers@freebsd.org Subject: Re: memory mapped packet capturing - bpf replacement ? Message-ID: <20040614190840.A29587@oasis.uptsoft.com> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C8533701BD40C7@mail.sandvine.com>; from emaste@sandvine.com on Mon, Jun 14, 2004 at 08:38:57AM -0400 References: <FE045D4D9F7AED4CBFF1B3B813C8533701BD40C7@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ed,
> I did my benchmark by increasing the packet rate until I found
> the point at which packets started to be dropped.
A bit offtopic - what traffic generator you use ?
> 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 ?
> 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
> Does the ng_hub cause the packet to be copied? If so you've
> still got the same number of copies as vanilla BPF.
I think ng_hub does not do a copy, instead it passes mbufs through.
Originally, I wanted this architecture:
ng_ether
/ \
(lower) (upper)
\ /
ng_hub
|
ng_bpf
|
ng_mmq
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.
> 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.
> As for question 3, be careful that you're atomically modifying
> the head and tail indices/pointers. But yes, you can do it
> without a mutex.
Any points how to do that ? the only thing I can think of is having
atomic variable in shared memory chunk, and using spinlock + atomic change.
sergey
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040614190840.A29587>