Feature #3131
closed
EthernetTransport: re-enable TPACKET_V3 for capture if kernel and libpcap are recent enough
0%
Description
We disabled TPACKET_V3 in #1511 as a workaround for a Linux kernel bug. The bug was finally fixed in Linux v3.19, released earlier this year. Recently libpcap also received some patches to improve its behavior with TPACKET_V3 and recent kernels.
We should detect if the system has a recent enough combination of kernel and libpcap, and stop disabling TPACKET_V3 in that case. This should improve the performance of the EthernetTransport receive path, and might help with #2441.
Updated by Davide Pesavento over 9 years ago
- Related to Bug #1511: EthernetFace cannot receive on Ubuntu 14.04 added
Updated by Junxiao Shi about 9 years ago
- Subject changed from EthernetFace: re-enable TPACKET_V3 for capture if kernel and libpcap are recent enough to EthernetTransport: re-enable TPACKET_V3 for capture if kernel and libpcap are recent enough
- Target version set to v0.5
Ubuntu would have recent enough libpcap since 15.10.
Updated by Davide Pesavento over 8 years ago
- Tracker changed from Task to Feature
Updated by Davide Pesavento over 7 years ago
Junxiao Shi wrote:
Ubuntu would have recent enough libpcap since 15.10.
libpcap version 1.5.3 should be sufficient. And that version is available in Ubuntu 14.04.
Updated by Davide Pesavento over 6 years ago
- Status changed from New to Rejected
- Assignee deleted (
Davide Pesavento)
Actually, libpcap recommends enabling immediate mode (thereby limiting the highest TPACKET version to V2) if the application wishes to be notified of new packets as soon as they are received, see https://github.com/the-tcpdump-group/libpcap/issues/472#issuecomment-169791537
The alternative (i.e. allowing TPACKET_V3 by not enabling immediate mode) means setting the "packet buffer timeout" to 1ms (the lowest possible value), which means that each incoming packet may be delayed by up to 1ms, which is probably unacceptable for a packet forwarder. So I'm rejecting this issue.