On Apr 25, 2012, at 9:28 PM, Guy Harris wrote:
>
> On Apr 25, 2012, at 12:06 PM, Michael Tuexen wrote:
>
>> When using threads, we run a thread for each source. Once the packet has been read it is
>> stored in a queue.
>
> I'm assuming here that "stored in a queue" doesn't mean "the raw packet contents are copied", as that would add to dumpcap's memory bandwidth requirements and reduce its ability to avoid dropping packets, relative to the 1.6.x version of dumpcap; if the raw packet contents *are* copied, that's a bug.
dumpcap uses
pcap_dispatch(pcap_opts->pcap_h, 1, capture_loop_queue_packet_cb, (u_char *)pcap_opts);
In capture_loop_queue_packet_cb() dumpcap g_malloc()s memory for the packet, copies it in and
puts that copy in the queue (using another small queue element).
So it adds copying, but we did some measurements and if you make the queue large, it can improve
the capturing, because you can store packets as long as you can allocate memory. On Mac OS X we
could reduce the packet drop rate...
If you consider this a bug, I would be happy, if you can suggest an improvement. I think
using a separate thread for each interface, putting the packets in a queue and using a
single writer queue is a way to perform capturing on multiple interfaces without having to
deal with the problems of select() in combination with pcap descriptors. I wanted to have
the feature running on all platforms.
When capturing from a single interface, you can get the old behavior by not using the -t command line
option.
>
> Given that, I would be inclined to dynamically allocate the queue elements, which should be small as they don't have to include packet data, so that packets are dropped by the capture mechanism because dumpcap can't read them fast enough, but not by dumpcap itself.
We do have small queue elements, but also the raw packet contents...
>
> If that's impossible, I would add "dropped by the capture mechanism" and "dropped by dumpcap" together and use that as a count of packets dropped.
... It is what I do on the command line reporting of dumpcap...
Best regards
Michael
> ___________________________________________________________________________
> 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
>
