Ethereal-dev: Re: [Ethereal-dev] Tap extensions. Comments please.
----- Original Message -----
From: "Guy Harris"
Sent: Tuesday, September 10, 2002 6:53 AM
Subject: Re: [Ethereal-dev] Tap extensions. Comments please.
> On Mon, Sep 09, 2002 at 06:42:48PM +1000, Ronnie Sahlberg wrote:
> > There is a problem though with tap in that performance is really
affected if
> > the tap listeners
> > use filters. I dont know epan_dissect_prime_dfilter() and friends well
> > enough to be able to fix this. Could you look at it?
> > See tap_push_tapped_queue()
> > in the inner loop there is an if-statement checking if the listener had
> > specified a filter and
> > if so it would do a full :
> > epan_dissect_new()
> > epan_dissect_prime_dfilter()
> > epan_dissect_run() <= This one takes quite some time I think.
> > dfilter_apply_edt()
> > For each and every such tap listener.
> > Well, you see the problem, we do a full and expensive dissection of the
> > entire packet just because we only want to apply a filter.
>
> To apply a display filter, you *have* to do a dissection of the entire
> packet, as filters act on protocol trees. Presumably what you meant was
> "we do a full and expensive dissection of the entire packet for each
> filter we want to apply, rather than doing one dissection and applying
> multiple filters".
Yes that is exactly what I meant.
>
> As far as I can tell, "dfilter_prime_proto_tree()" doesn't modify the
> dfilter to which it's passed a pointer (it might be worth making its
> "df" argument a "const dfilter_t *", to emphasize that), and that's
> what's called by "epan_dissect_prime_dfilter()".
>
> As such, I see no reason why you can't make multiple calls to
> "epan_dissect_prime_dfilter()" with the same tree, one for each filter
> for which you're priming the tree. Then you'd only need to make one
> 'epan_dissect_new()" call, and only one "epan_dissect_run()" call.
but epan_dissect_prime_dfilter() has to be called before epan_dissect_run()
or doesnt it?
Can one take both epan_dissect_new() and epan_dissect_run() and move them
outside the loops and then just leave epan_dissect_prime_dfilter() and
dfilter_apply_edt() inside the loop?
Something like:
epan_dissect_new()
epan_dissect_run()
loop over all entries:
epan_dissect_prime_dfilter()
dfilter_apply_edt()
end-loop
I assume it is epan_dissect_run() that is the expensive operation that
actually dissects the entire packet.
If something like this was possible, usinf filters for tap would be very low
cost since we could fold the normal display filter filtering into a very
simple tap extension as well
that just modifies a global variable to indicate passed/not-passed. Then we
could get away with only doing the dissection once, no matter if we use
display filters, color filters or tap extensions.
