Ian Schorr wrote:
So how do we move forward with this? So far no one seems to disagree.
Should we allow tap authors more time to respond? Does someone need to
do a more thorough review code to determine if no taps do, in fact,
depend on the current display filter? Should we make a design decision
that tap listeners should not depend on the current display filter, or a
seperate function should be created (or perhaps my "retap" flag should
be replaced with something that is a bit more intelligent, and allows
only specific taps to be rebuilt if needed)?
I think all taps or at least most of them don't depend on the display
filter. I am just not so sure about the conversation, hostlist and rtp taps.
However I don't think you will get only a small performance improvement
as only the xxx_packet functions of the taps are called a lot. These
routines are usually quite small and fast compared to dissector funtions
which are called anyway when you change the display filter. But go ahead
, I'd like to see the results.
BTW, I have a capture file with more than 3 million H.225 RAS packets. I
used this file to test the H.225 RAS SRT tap of tethereal. It took about
2 hours to analyze this file with Ethereal 0.9.16 and a first version of
my tap. With 0.10.3 it takes only 8 minutes on the same PC!
Regards,
Lars
On Jul 27, 2004, at 2:35 AM, Guy Harris wrote:
On Mon, Jul 26, 2004 at 04:18:31PM -0400, Ian Schorr wrote:
Still a bit concerned that the taps are being rebuilt when changing
display filter and other events that really should only change the
packet list, though. What if we did something simple like this (see
attached patch against latest SVN)?
That sounds reasonable *if*, in fact, refiltering the display *doesn't*
change any taps.
It looks as if "tap_push_tapped_queue()" would get called regardless of
whether the packet passes the filter or not, and the taps have their own
filters, so, unless it's considered a bug, rather than a feature, that
the display filter has no effect on the taps, that sounds like the right
thing to do.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev