[Patch] Timeout for pcap_open_live()

[segv]

I have submitted a one line patch to add a timeout value to pcap_open_live() in packet.cpp.

This ensures compatibility with FreeBSD kernels >4.2-RELEASE, and should improve performance under packet intensive circumstances for newer FreeBSD and Linux kernels.

Systems that do not support timeouts will ignore this value.

The disadvantage to a zero timeout is that packets are read from kernel to user space as they arrive. This is expensive.

The patch sets the timeout to 100ms, and should be quite sufficient for ShowEQ purposes.

[fee]

Segv,

Please explain in detail how this affects compatibility with FreeBSD. From the crappy pcap docs, this value is described as a read timeout. I'm not sure I follow how setting a timeout of any length will affect kernel load or compatibility. If you are seeing problems with BSD and packets coming from the BPF to user-land, it is probably related to BIOCIMMEDIATE not being set. See SINS packet.cpp for an example of this.

If you want to easy the load packet capture places on your system by showeq, I would recommend not setting the packet capture thread to realtime.

fee

[segv]

Setting BIOCIMMEDIATE causes packets to be copied to userland as they are received. This is expensive.

A feature was introduced after 4.2-RELEASE that creates a default buffer (32k if I remember correctly) for BPF packet capture. Packets will not be copied to userland until this buffer has been filled unless an explicit timeout has been set (or BIOCIMMEDIATE is set). This feature was implemented to help the kernel cope with packet capture on high traffic (>50MBps) networks. My understanding is that a similar feature has been implemented in more recent versions of the Linux kernel, although I have not kept up with the Linux kernel since the 2.0.x train. Older Linux kernels do not support a timeout, and hence tend to drop packets while capturing on high traffic networks.

Setting a small timeout (100ms) makes more sense than setting BIOCIMMEDIATE if the data stream exceeds 10pps during gameplay, particularly since ShowEQ runs at a default of 10fps. For systems that support a timeout, this should equate to slightly better performance during packet intensive (>10pps) conditions.

As I recall, there was some fairly detailed discussion of this issue on the tcpdump mailing list a while back. It might be worth a browse.

-- segv