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-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: HEADS UP: zerocopy bpf commits impending
    ... Please be on the "lookout" for any strange bpf related issues. ... patches etc can be sent to Robert Watson or myself. ... As a result, when acking one buffer, it's almost always the case that userspace will enter selecteven 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. ...
    (freebsd-current)
  • Re: HEADS UP: zerocopy bpf commits impending
    ... Please be on the "lookout" for any strange bpf related issues. ... patches etc can be sent to Robert Watson or myself. ... As a result, when acking one buffer, it's almost always the case that userspace will enter selecteven 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. ...
    (freebsd-net)
  • [RFC] LTTng Userspace Tracing, vDSO
    ... I am poking in the userspace tracing problem again. ... The idea is to fast-path tracing so a system call is not required. ... Per CPU buffers mapped by both userspace and the kernel ... can afford to have smaller buffers than the kernel buffers. ...
    (Linux-Kernel)
  • Re: [RFC] Userspace tracing memory mappings
    ... for my LTTng userspace tracing buffers. ... Would you mind offering some justification for requiring a kernel ... System-wide activation of markers located in userspace code ... Ability to extract buffers of a crashed process ...
    (Linux-Kernel)
  • Re: praudit parse with gnu grep
    ... Robert Watson wrote: ... The input/output buffers in stdio mean that you may not see output immediately, the buffer has to fill enough to trigger an I/O before that will happen. ... The attached patch might do this. ...
    (freebsd-hackers)