Re: Snaplen (git-latest) not working properly on

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

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.