URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=5ff8c3895a41b44486fbc17e05e4a188e3c4827e
Submitter: Peter Wu (peter@xxxxxxxxxxxxx)
Changed: branch: master
Repository: wireshark
Commits:
5ff8c38 by Ivan Nardi (nardi.ivan@xxxxxxxxx):
SCCP: fix performance drop in reassembler code
Commit 46dc5f75, while fixing sccp reassembler in the generic case, introduced
a huge performance drop in some scenarios.
The bottleneck is the sccp_reassembly_id_map hash table and, more precisely,
the combination of the key layout and the hash function g_int64_hash()
The key is defined as:
guint64 key = ((guint64)frame << 32) | offset;
Since the hash function uses only the lowest 32 bits of the key, all fragments
at the same offset are saved in the same bucket
If the sccp fragments are always in different packets and at the same offset
(because, for example, there are only 1 chunk in every sctp packet) the hash
table degenerates in exactly one linked list.
Changing the key definition seems to restore the original performance
Since there are usually hardly more than ~10/20 sctp chunks in a packet,
this change shouldn't significantly affect performance when (all) fragments
are in the same frame
Change-Id: I2867a72819c2d91e1e0ae2cb97d63b5684d35bcc
Reviewed-on: https://code.wireshark.org/review/27944
Petri-Dish: Peter Wu <peter@xxxxxxxxxxxxx>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@xxxxxxxxxxxxx>
Actions performed:
from a1a56bd Qt: Move Layout and clear master_split use
adds 5ff8c38 SCCP: fix performance drop in reassembler code
Summary of changes:
epan/dissectors/packet-sccp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)