Re: Have tshark discard state when doing ring-buffer capture

[Anders Broman <anders.broman () ericsson com>]

Hi,
This is perhaps a better place to have the discussion of the implementation, copying info from gerrit, etc here:

Anders wrote:
> I suppose tshark epan new calls the dissector initial routines clearing all hashtables etc,during heavy load that 
> might trigger packet loss I guess.

Evan wrote:



> As Anders correctly pointed out in I7d8f84b2e<https://code.wireshark.org/review/#q,I7d8f84b2e,n,z>, constantly 
> resetting state will
> turn init_dissection into a bit of a hot path. Especially as we will already
> bear the overhead of switching files, we don't want to fall any further behind
> than we have to.

> This change includes three unrelated optimizations that reduce the cost of
> init_dissection by about 40% as measured by callgrind:
> - only initialize ares/ADNS if that preference is enabled (this of course only
>   applies if you specify -n to tshark or otherwise disable the preference)
> - use memcpy instead of a loop in sigcomp UDVM init
> - use memcpy instead of a loop in bootp dissector

( Commited https://code.wireshark.org/review/2738 )
> The only remaining obvious hot spot in this path is reassembly_table_init since
> it is called by so many dissectors. Suggestions (perhaps to get rid of the
> GPtrArray) welcome.

Anders wrote:

> Could switching of files be made more efficient by preopening the next ring buffer file and delegate closing and 
> opening next file to a new tread?

Another possibility that might boost performance is to remove reassembled data from the hash table and store it in 
per-packet-data reducing the size of the hash table and hopefully making lookups faster as well as destroying the hash 
table  (wmem hash tables?) or use
g_hash_table_remove_all ()

Did you profile ring buffer switchover? ( how?).

So in general I think you are right this *is* the expected behavior of tshark with ring buffers, but I fear that it 
might not be as useful as expected under heavy traffic because of potential packet drops during file switchover of 
files unless we can make it more efficient. I have no data verifying that this is the case so if we could device a 
measurement that would be great.

Regards
Anders

From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Evan Huus
Sent: den 30 juni 2014 23:19
To: Wireshark Developer List
Subject: [Wireshark-dev] Have tshark discard state when doing ring-buffer capture

I was kind of expecting this change to generate more controversy, so I'll give it another few days but if nobody 
objects I'll merge it then.

https://code.wireshark.org/review/2669
I don't currently plan on putting it in 1.12 so that we have a full dev cycle to work out any subtle implications, but 
I know it's a fairly heavily-requested feature so I'm willing to entertain the notion if somebody wants to argue for it.

Evan

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