increase by changing the 32bit
Lubuntu 11.04 to an 64bit Ubuntu 11.04 on the same machine.
All the best,
Bernd
> From: doktorbe...@hotmail.com
> To: tcpdump-workers@lists.tcpdump.org
> Subject: Re: [tcpdump-workers] libpcap capture performance drop
> Date: Thu, 26 May 2011 09
On 05/27/2011 11:03 AM, Guy Harris wrote:
On May 27, 2011, at 5:20 AM, ri...@happyleptic.org wrote:
If I understand this code correctly, in the next release of the libpcap
if a client program ask for a capture length bigger than the MTU then
the size allocated for each frame in the ring buffer
On May 27, 2011, at 12:04 PM, Ben Greear wrote:
> Might want to add an extra 4 bytes for a possible VLAN header too.
prepare_tpacket_socket() sets the "reserve" for VLAN tag reconstruction to 4;
the "reserve", along with the maximum packet size, is involved in calculating
the frame slot size.
On May 27, 2011, at 10:54 AM, Rick Jones wrote:
> Excellent! And that makes me wonder if I should add similar offload
> checking (and reporting) code to netperf for its omni tests...
It's modeled after what ethtool does, so if your tests are wrapped in a shell
script, you could run ethtool on
On May 27, 2011, at 5:20 AM, ri...@happyleptic.org wrote:
> If I understand this code correctly, in the next release of the libpcap
> if a client program ask for a capture length bigger than the MTU then
> the size allocated for each frame in the ring buffer will be sized down
> to avoid wasting
On Fri, 2011-05-27 at 10:39 -0700, Guy Harris wrote:
> On May 27, 2011, at 10:16 AM, Rick Jones wrote:
>
> > Is this new libpcap going to be guaranteed that the underlying NIC HW
> > isn't doing Large Receive Offload, or that the tracepoint in the stack
> > is below any stack's attempt to do Gener
On May 27, 2011, at 10:16 AM, Rick Jones wrote:
> Is this new libpcap going to be guaranteed that the underlying NIC HW
> isn't doing Large Receive Offload, or that the tracepoint in the stack
> is below any stack's attempt to do Generic Receive Offload?
If
1) your kernel supports the e
On Fri, 2011-05-27 at 14:20 +0200, ri...@happyleptic.org wrote:
> -[ Mon, May 23, 2011 at 12:38:43AM -0700, Guy Harris ]
> >
> > On May 23, 2011, at 12:31 AM, ri...@happyleptic.org wrote:
> >
> > > Which brings the question: how one could find out the MTU of a
> > > pcap_handle in order no to
-[ Mon, May 23, 2011 at 12:38:43AM -0700, Guy Harris ]
>
> On May 23, 2011, at 12:31 AM, ri...@happyleptic.org wrote:
>
> > Which brings the question: how one could find out the MTU of a
> > pcap_handle in order no to set caplen to 65535 ?
>
> See pcap-linux.c in the top of the trunk or of t
ump-workers] libpcap capture performance drop
> From: g...@alum.mit.edu
> Date: Fri, 20 May 2011 12:02:42 -0700
> To: tcpdump-workers@lists.tcpdump.org
>
>
> On Sep 6, 2010, at 11:45 AM, Doktor Bernd wrote:
>
> > If I recompile with the HAVE_PACKET_RING stuff *not* co
On May 23, 2011, at 9:58 AM, Rick Jones wrote:
> Are there alignment differences for the different buffer sizes? For
> example, when one would use 1518, would one be better-off using 1520 to
> end on a 4 byte boundary and so begin on a 4 byte boundary if these
> buffers are carved one after the
On Fri, 2011-05-20 at 12:02 -0700, Guy Harris wrote:
> On Sep 6, 2010, at 11:45 AM, Doktor Bernd wrote:
>
> > If I recompile with the HAVE_PACKET_RING stuff *not* commented out I get
> > the bad performance as with the packaged versions from Ubuntu. So the
> > performance drop is caused by that
On May 23, 2011, at 12:31 AM, ri...@happyleptic.org wrote:
> Which brings the question: how one could find out the MTU of a
> pcap_handle in order no to set caplen to 65535 ?
See pcap-linux.c in the top of the trunk or of the 1.2 branch. (Short answer:
SIOCGIFMTU, as in the iface_get_mtu() rou
-[ Fri, May 20, 2011 at 12:02:42PM -0700, Guy Harris ]
> The packet-ring stuff has fixed-length slots, which means that the number of
> slots is the buffer size divided by the size of the slots.
Very interresting information!
Which brings the question: how one could find out the MTU of a
pca
On Sep 6, 2010, at 11:45 AM, Doktor Bernd wrote:
> If I recompile with the HAVE_PACKET_RING stuff *not* commented out I get the
> bad performance as with the packaged versions from Ubuntu. So the performance
> drop is caused by that part of libpcap.
The packet-ring stuff has fixed-length slots
Hi,
back from vacation I had some time to test libpcap again
> > thanks for the advice. If I use libpcap 1.1.1 compiled with the
> > HAVE_PACKET_RING stuff commented out, the my softare performs very well.
> > Ubuntu currently ships with 1.0.0.6 I think. If I use that version my
> > applicatio
On Fri, Aug 13, 2010 at 02:00:22PM -0700, Guy Harris wrote:
> No. I forgot that the availability of the memory-mapped pcap
> mechanism isn't determined by the configure script, it's determined
> by what the system includes offer.
>
> Instead, in pcap-linux.c, just #if 0 out the
>
> /* check for
On Aug 15, 2010, at 6:15 AM, Doktor Bernd wrote:
> thanks for the advice. If I use libpcap 1.1.1 compiled with the
> HAVE_PACKET_RING stuff commented out, the my softare performs very well.
> Ubuntu currently ships with 1.0.0.6 I think. If I use that version my
> application has problems captur
custom build version of libpcap then I can capture 1 Gbit/s of traffic and
problem occur only for small packet sizes (<100 Byte).
Any idea why mmap is slowing everything down? I am using pcap_dispatch to
capture packet by packet.
> Subject: Re: [tcpdump-workers] libpcap capture performanc
On Aug 10, 2010, at 3:35 AM, Doktor Bernd wrote:
> I am experiencing the same problem as described in
> http://news.gmane.org/find-root.php?message_id=%3c972613.6039.qm%40web59701.mail.ac4.yahoo.com%3e
>
> I have written a software that captures Ethernet frames and forwards them to
> different
20 matches
Mail list logo
