Re: Zerocopy bpf
On Thu, 29 Jan 2015 12:25:25 +0100 (CET) el...@sentor.se wrote > Hi! > > q1) > I assume that libpcap has builtin support for checking if sysctl > net.bpf.zerocopy_enable is set to 1, and if so uses zerocopy. > Correct? > > q2) > This should mean that all normal sniffing tools like tcpdump, tshark, > ngrep, argus, etc do NOT need any specific options in order to use > zerocopy. > Correct? > > q3) > How do I see if zerocopy is used or not? 'netstat -B' don't tell me > much, and the tool 'bpfstat' don't seem to exist any more. I can't speak from personal experience to the rest. But as to bpfstat(8); it was merged into netstat(1) ~RELENG_7. --Chris > > q4) > When activating zerocopy, should I immediately see a performance boost on > the machine? (like less drops on a heavily loaded sniffer NIC (running in > monitor mode)) > > /Elof > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Zerocopy bpf
Hi! q1) I assume that libpcap has builtin support for checking if sysctl net.bpf.zerocopy_enable is set to 1, and if so uses zerocopy. Correct? q2) This should mean that all normal sniffing tools like tcpdump, tshark, ngrep, argus, etc do NOT need any specific options in order to use zerocopy. Correct? q3) How do I see if zerocopy is used or not? 'netstat -B' don't tell me much, and the tool 'bpfstat' don't seem to exist any more. q4) When activating zerocopy, should I immediately see a performance boost on the machine? (like less drops on a heavily loaded sniffer NIC (running in monitor mode)) /Elof ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: HEADS UP: zerocopy bpf commits impending
On Mon, 24 Mar 2008, Petri Helenius wrote: Pardon the basic question, but is the current patchset "zero copy" or "one copy"? The paper I saw a link to described a mechanism to eliminate one of the two copies the traditional bpf approach makes but I haven't taken a look into the actual code. The short answer is "one-copy". This eliminates the copy between the kernel and user space, but not the possibility of in-kernel copying. In practice, that in-kernel copying is frequently desirable as: (1) It allows packing of headers into a buffer when a small snaplen is used, which greatly reduces memory overhead when capturing, for example, just TCP headers and not payloads. (2) It allows us to more easily maintain independence between separate BPF sessions, and in particular, to avoid leaking memory between kernel, userspace, and different BPF consumers. If doing full capture of all packet data to userspace, the approach we took would improve performance, but would still involve one full copy of packet data in kernel. Further work would be required to eliminate that copy. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: zerocopy bpf commits impending
Pardon the basic question, but is the current patchset "zero copy" or "one copy"? The paper I saw a link to described a mechanism to eliminate one of the two copies the traditional bpf approach makes but I haven't taken a look into the actual code. Pete ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: zerocopy bpf commits impending
I just want everyone to know that I have completed the zerocopy bpf commit. Please be on the "lookout" for any strange bpf related issues. For people that want to test the new zerocopy bpf implementation, a patch can be found here: http://people.freebsd.org/~csjp/pcap.1206364304.diff Any comments, patches etc can be sent to Robert Watson (rwatson@) or myself. Thanks! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: zerocopy bpf commits impending
On Mon, 24 Mar 2008, Christian S.J. Peron wrote: I just want everyone to know that I have completed the zerocopy bpf commit. Please be on the "lookout" for any strange bpf related issues. For people that want to test the new zerocopy bpf implementation, a patch can be found here: http://people.freebsd.org/~csjp/pcap.1206364304.diff Any comments, patches etc can be sent to Robert Watson (rwatson@) or myself. FYI, right now there is a known issue in which only one of the two BPF buffers can be owned by user processes at a time. As a result, when acking one buffer, it's almost always the case that userspace will enter select() even though another buffer is essentially ready, leading to a system call being generated for each buffer even though that's undesirable. I'm working on some changing allowing both buffers to be owned by userspace at a time, but it will be a couple of weeks before that enters CVS. I believe that the current libpcap patches should keep working with that fine, although of course, we'll see. :-) The bpf.4 documentation is very careful to warn that applications should not assume that there are any invariants about the number of buffers assigned to userspace at a time. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS UP: zerocopy bpf commits impending
All, Just wanted to give a heads up that I plan to start merging the work located in the zerocopy bpf perforce branch. We have been working on this project for about a year now and feel that it is ready to come into the tree. I will begin to merge hopefully today [assuming nobody has any concerns] or tommorow. Zerocopy bpf will be disabled by default, and can be enabled globally though the use of a sysctl variable. Once the kernel bits are in and we sort out a couple minor nits in libpcap+tcpdump, we will be be looking at getting our libpcap patches committed upstream. I will post a patch for people to experiment with in the meantime after the kernel commits are complete. We do not anticipate this will have any effect on existing bpf consumers like libpcap, tcpdump etc... so if something breaks, it shouldn't have and we need to know about :) We were pretty careful about preserving the ABI. The only exception to this is, netstat will need a recompile because the size of it's bpf stats structure changed. So if there are any objections or concerns, now is the time to raise them. Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
