Wireshark-dev: Re: [Wireshark-dev] TCP reassembly slow
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 24 Mar 2017 18:22:14 -0700
On Mar 24, 2017, at 4:11 PM, Simon Barber <simon.barber@xxxxxxxxxx> wrote:

> When loading a large file (0.5M packets) with a large single TCP stream in it, wireshark gets very slow. I did some profiling and found 90% of the CPU time was spent in epan/reassemble.c LINK_FRAG() - scanning through a long singly linked list and adding to the end of it.

So is the stream one, or a small number of, huge packets when reassembled?  If a packet has stuff from two TCP segments, that shouldn't be slow.

A quick 99% optimization would be to save a pointer to the end of the list and, if the new fragment should go after the last item in the list, just add it there.

In the general case, perhaps a tree would work better, as the goal of LINK_FRAG() is to find the appropriate place to insert the new fragment so that the set of fragments is sorted by fragment offset.