Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Idea for faster dissection on second pas

From: Anders Broman <a.broman@xxxxxxxxxxxx>
Date: Fri, 11 Oct 2013 06:41:54 +0200
Evan Huus skrev 2013-10-11 01:51:
On Thu, Oct 10, 2013 at 6:22 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
It might be simpler and almost as efficient to have
recently-successful heuristic dissectors bubble nearer to the top of
the list so they are tried sooner. Port/conversation lookups are
hash-tables for the most part and likely won't be made noticeably
faster by caching.
The attached trivial patch more-or-less implements the above idea. It
isn't easy to bubble dissectors to the very head of the list because
we don't have a modifiable pointer, but it was surprisingly easy to
bubble them to *second* in the list, which should still be a
substantial improvement if there are many expensive heuristics.

I don't have any long heuristic captures that I can easily time, but
I've run a few short ones and at least it doesn't seem to break
anything.

Let me know if it helps,
Evan
In the particular case I'm looking at there is mostly no match in the heuristics tables except false positives
the same is true for many of the uint table lookups too as there is RTP sent from a tool simulating many
users with many IP/port combinations making up a huge portion of the packets.

Regards
Anders



On Thu, Oct 10, 2013 at 4:22 PM, Anders Broman <a.broman@xxxxxxxxxxxx> wrote:
Hi,
If we in the UDP/TCP/(SCTP?) dissectors saved next dissector on the first
pas in say per packet data we could avoid
repeated calls to heuristic dissectors and port/conversation lookups making
the second pas faster.
Does any one see any pitfalls with this idea?

I can think of two ways of implementing it:
- A new entry in pinfo "previous protocol" or something like that.
or
- make dissector_try_uint(), dissector_try_heuristic(),
try_conversation_dissector() return the protocol
or NULL;

The second is perhaps cleaner but requires more changes or we could make new
functions
dissector_try_heuristic_ret_proto() etc or something like that.

Comments?

Regards
Anders


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

Attachment: callgrind.out.5339.bz2
Description: Binary data