tcpdump mailing list archives
Re: Snaplen (git-latest) not working properly on
From: Guy Harris <guy () alum mit edu>
Date: Wed, 8 Feb 2012 21:07:25 -0800
On Feb 8, 2012, at 8:28 PM, Gianluca Varenni wrote:
We've run some more tests, and it looks like the problem is (obviously) not just with a snaplen of 1500. Here is what we found (using packets bigger than the snaplen): Snaplen = 59+16n -> caplen=58+16n Snaplen = 60+16n -> caplen=58+16n The results are the same on 32- and 64-bit systems (using a 64bit libpcap on a 64bit kernel), so it's not some 32 vs 64bit alignment issue. @Guy: if you have some pointers/info about TPACKET_V2, maybe I can give a look at it.
TPACKET_V1 and TPACKET_V2 are generally described by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/networking/packet_mmap.txt;hb=HEAD and by the structures and #defines in include/linux/if_packet.h: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=include/linux/if_packet.h;hb=HEAD (e.g., struct tpacket_hdr, with the fatal-to-32-bit-userland-on-a-64-bit-kernel "unsigned long" in it, and struct tpacket2_hdr, which fixes that problem by using specified-length integers for all members). (If you're curious about TPACKET_V3 - which is only available in recent 3.x kernels, so adding support to it, while fine for people running Shiny New Releases of distributions, wouldn't fix the problem for people running with older releases that have 2.x kernels or even not-so-recent 3.x kernels - the headers for it are in the latest if_packet.h, but I don't know of any documentation for it, other than linux-netdev messages such as http://marc.info/?l=linux-netdev&m=130750281222159&w=2 (which mentions the problem with TPACKET_V[12]:
This patch attempts to: 1)Improve network capture visibility by increasing packet density 2)Assist in analyzing multiple(aggregated) capture ports. Benefits: B1) ~15-20% reduction in cpu-usage. B2) ~20% increase in packet capture rate. B3) ~2x increase in packet density. B4) Port aggregation analysis. B5) Non static frame size to capture entire packet payload. With the current af_packet->rx::mmap based approach, the element size in the block needs to be statically configured. Nothing wrong with this config/implementation. But the traffic profile cannot be known in advance. And so it would be nice if that configuration wasn't static. Normally, one would configure the element-size to be '2048' so that you can atleast capture the entire 'MTU-size'.But if the traffic profile varies then we would end up either i)wasting memory or ii) end up getting a sliced frame. In other words the packet density will be much less in the first case.
"packet density" being the key phrase here - with TPACKET_V[12], you want to make the fixed-size elements big enough for the largest packet, if you don't have a snaplen, but no bigger, so you don't end up with a huge chunk of wired-down memory or a ring too small to avoid dropping packets, and you also have to go through a bit of complexity if you want to use smaller fixed-size elements if you *do* have a snaplen, and we're probably *still* not doing *that* calculation right), and followups: http://marc.info/?l=linux-netdev&m=130750283622169&w=2 and the rest of the thread, and http://marc.info/?l=linux-netdev&m=130750332222426&w=2 and the rest of the thread, and then version 2 of the patches: http://marc.info/?l=linux-kernel&m=130870867401986&w=2 and the rest of the thread, and http://marc.info/?l=linux-netdev&m=130870870602024&w=2 and the rest of the thread, and http://marc.info/?l=linux-kernel&m=130870873902058&w=2 and then version 3 of the patches: http://marc.info/?l=linux-netdev&m=131095963200980&w=2 and http://marc.info/?l=linux-netdev&m=131095964400985&w=2 and the rest of the thread, and http://marc.info/?l=linux-netdev&m=131095968601068&w=2 and the rest of the thread, and then version 4 of the patches: http://marc.info/?l=linux-netdev&m=131311628001282&w=2 and the rest of the thread, and http://marc.info/?l=linux-netdev&m=131311629101295&w=2 and http://marc.info/?l=linux-netdev&m=131311631701312&w=2 and the rest of the thread, and then version 5 of the patches: http://marc.info/?l=linux-netdev&m=131378511610546&w=2 and http://marc.info/?l=linux-netdev&m=131378512710552&w=2 and the rest of the thread, and http://marc.info/?l=linux-netdev&m=131378514010561&w=2 and the rest of the thread - v5 was the version that was accepted and applied.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Current thread:
- Snaplen (git-latest) not working properly on linux Gianluca Varenni (Jan 15)
- Re: Snaplen (git-latest) not working properly on linux Guy Harris (Jan 15)
- Re: Snaplen (git-latest) not working properly on Gianluca Varenni (Feb 08)
- Re: Snaplen (git-latest) not working properly on Guy Harris (Feb 08)
- Re: Snaplen (git-latest) not working properly on Gianluca Varenni (Feb 08)
- Re: Snaplen (git-latest) not working properly on linux Guy Harris (Jan 15)