On Sep 1, 2009, at 8:19 AM, martin wrote:
Does anybody know if there is any intentions to address the single-
threaded implementation of Wireshark in the future?
Wireshark is a great tool but suffers from performance issues when
tracing a conversation or doing other filtering for instance.
What you *should* be asking is "is there any intention to improve
Wireshark's performance when tracing a conversation or doing other
filtering?" Ask whether there is an intent to improve performance,
not whether there's an intent to use a particular mechanism for
improving performance, as there might be ways of improving performance
more effective than just throwing more CPU at the problem (especially
if, for example, the problem is with memory usage, not CPU usage).
The answer to that question is "yes"; a bunch of changes have been
checked into the main branch that should improve performance in a
number of places, and at least some of them will, I think, address the
items you're talking about. There are also a number of ideas that
haven't been implemented yet.
And, yes, some thought has been given to what would be involved in
using more than one CPU core to do dissection. It's not trivial -
packet dissection is not even close to an "embarrassingly parallel"
problem, as the dissection of a given packet can, in a number of ways,
depend on previous packets.
There will probably have to be a more general notion of
"conversations", with conversations existing at multiple protocol
layers (both above and below the network and transport layers), and
packets within a conversation for that protocol will, for many
protocols, *not* be able to be dissected in parallel, at least for
that protocol. If a capture has enough separate conversations at all
layers, there should be enough parallelism to get some performance
gains (where "enough" might be "at least as many conversations as
there are independent cores"; whether "cores" should be replaced by
"processor threads" with multi-threaded processors is another matter).
