tcpdump mailing list archives
Re: TPACKET_V3 support added big packet delivery delay and/or affected timestamps
From: Guy Harris <guy () alum mit edu>
Date: Thu, 4 Dec 2014 12:01:30 -0800
On Dec 4, 2014, at 10:13 AM, Thomas Habets <thomas () habets se> wrote:
Actual behaviour: $ sudo sh -c "LD_PRELOAD=$HOME/opt/buggypcap/lib/libpcap.so ./arping 10.0.0.1" ARPING 10.0.0.1 60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=0 time=52.633 msec 60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=1 time=90.928 msec 60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=2 time=115.183 msec 60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=3 time=285.153 msec ^C --- 10.0.0.1 statistics --- 4 packets transmitted, 4 packets received, 0% unanswered Expected (and received with 1.4.0): $ sudo sh -c "LD_PRELOAD=$HOME/opt/goodpcap/lib/libpcap.so ./arping 10.0.0.1" ARPING 10.0.0.1 60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=0 time=817.060 usec 60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=1 time=895.977 usec 60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=2 time=759.840 usec 60 bytes from 00:xx:xx:xx:xx:xx (10.0.0.1): index=3 time=827.074 usec ^C --- 10.0.0.1 statistics --- 4 packets transmitted, 4 packets received, 0% unanswered Notice the unit difference. About a hundred milliseconds vs about 800 microseconds.
TPACKET_V3 does the same style of buffer as does BPF, so packets are *not* guaranteed to be delivered as soon as they arrive; instead, they buffer packets so that multiple packets are delivered in a batch. See, for example: https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt This is different from TPACKET_V1 and TPACKET_V2. If your program needs to have packets delivered as soon as they arrive, it should, if the version of libpcap with which it's being built has the pcap_set_immediate_mode() API, open the capture device by doing p = pcap_create(device, errbuf); if (p == NULL) { report failure, using errbuf; quit; } pcap_set_immediate_mode(p, 1); {set timeout, etc. using pcap_set_timeout(), pcap_set_promisc(), pcap_set_snaplen(), etc.} status = pcap_activate(p); if (status != 0) { report warning or error, using status and pcap_geterr(); if it's an error, quit; }
Questions: Is TPACKET V3 (and V2?) much slower than V1?
No, TPACKET_V3 is just different, with the buffering. TPACKET_V1 and TPACKET_V2 don't do the same buffering.
Can I disable them?
You can disable buffering with pcap_set_immediate_mode(). *On Linux*, that *happens* to do so by falling back to TPACKET_V2 on systems that have TPACKET_V3; on systems using BPF, it does so with a BIOCIMMEDIATE ioctl.
Is this actual delay, or just a different way of measuring?
Since it's the same version of arping, and since the time stamps are from the system clock, not from the packets as provided by libpcap: https://github.com/ThomasHabets/arping/blob/arping-2.x/src/arping.c it's clearly not a different way of measuring. _______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- TPACKET_V3 support added big packet delivery delay and/or affected timestamps Thomas Habets (Dec 04)
- Re: TPACKET_V3 support added big packet delivery delay and/or affected timestamps Guy Harris (Dec 04)
- Re: TPACKET_V3 support added big packet delivery delay and/or affected timestamps Thomas Habets (Dec 05)
- Re: TPACKET_V3 support added big packet delivery delay and/or affected timestamps Guy Harris (Dec 04)