Re: running tcpdump seems to block disk operations on loaded systems

[Guy Harris <guy () alum mit edu>]

On Dec 18, 2011, at 3:54 AM, Nikola Ciprich wrote:

> here's the strace:
> 09:48:15.982305 setsockopt(3, SOL_PACKET, PACKET_RX_RING, "\0\0\2\0\37\0\0\0@\0\1\0\37\0\0\0", 16) = 0 <15.531056>
> ^^^ here it hangs
> 09:48:32.050796 mmap(NULL, 4063232, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7fdd92457000 <0.000298>
>
> will it help somehow?

What would *really* help would be if somebody went back in time, made sure TPACKET_V1 was never introduced into the 
kernel (note to all kernel developers, whether for Linux or Mac OS X or any other OS: if you're going to make an 
interface between the kernel and userland public, please either make sure it handles, at minimum, 32-bit userland on a 
64-bit kernel, as well as 64-bit userland on a 32-bit kernel on OSes such as Mac OS X that support it), and arranged 
that TPACKET_V3 were put into the kernel at the same time TPACKET_V2 was (note to developers of packet-capture 
mechanisms: fixed-length slots for packets are *really* tricky to get right, if the goal is to ensure that the slots 
are big enough for all possible packets delivered to the capture mechanism, so don't use them unless you're certain 
you've gotten it right). :-)

If you don't have any adapters that do segmentation/fragmentation or reassembly offloading, and you don't expect any 
such adapters to show up without a reboot (for example, you don't expect to plug them into any hot-pluggable bus), and 
you can determine the largest packet size possible on all the interfaces you have or expect to have on the capture 
you're running, use that number as the argument to a "-s" flag to tcpdump.  That will cut all packets short at a 
maximum length of that argument's value, so choose it carefully; it will also set the size of the fixed-length packet 
slots to a smaller value, so the mmap() won't map as large a chunk.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.