Re: TCP reassembly slow

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

On Mar 24, 2017, at 4:11 PM, Simon Barber <simon.barber () meraki net> 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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe