hi, this is regarding a mail sent sometime before.. sorry about that.
below it is said that except linux2.4[.x] every UNIX flavored OS does a copy from kernel to user space i read that the BPF used in *BSDs was developed to avoid this kernel-user copy for all packets. Only the filtered packets will be copied thereby improving performance. does linux2.4[x] do this better ? thanks ashley On Fri, 9 Nov 2001, Guy Harris wrote: > > Is there a simple answer like that the performance of the libpcap driver > > does not support data rates of 100 BT Network? > > That might be the answer, but there's no "the" libpcap driver - one of > the reasons for libpcap is to hide from applications the variety of > different raw-packet-capture mechanisms on different flavors of UNIX > (and, with WinPcap, the raw packet capture mechanism its developers > provide, running atop NDIS, for Windows). > > Different OS's raw packet capture mechanisms might have different > traffic rates they can handle. > > In all of those flavors of UNIX, except for Linux with a 2.4[.x] kernel, > the currently-available packet capture mechanisms involve at least one > copy of the packet data from the OS kernel to user mode; some of them > may involve more. The 2.4[.x] kernel provides a memory-mapped packet > capture mechanism which might reduce the number of copies; the current > libpcap from tcpdump.org doesn't use that mechanism, but some other > versions of libpcap do. > > On some of those flavors of UNIX, libpcap can obtain a count of packets > dropped from the packet capture mechanism because libpcap, or the > application using it, didn't consume the packets fast enough; these > include: > > the BSDs > > Linux, with a 2.4[.x] kernel (or the right patches to a 2.2[.x] > kernel) *and* the current CVS version of libpcap, or the 0.7 > beta version of libpcap, from tcpdump.org (and some other > versions) > > systems with DLPI and the "bufmod" STREAMS module (Solaris and > possibly AIX) > > Digital UNIX > > On those OSes, tcpdump, if you run it with the "-w" flag to write > captured packets to a file, should report, when you stop the capture by > interrupting tcpdump with control-C (or whatever your interrupt > character is), the number of packets dropped. The number will be > reported in an "N packets dropped by kernel" message. > > You can also use "pcap_stats()" in your application. > > Note that "tcpdump -w" will consume both CPU time and bus bandwidth, and > disk bandwidth, and disk-arm movement, and so on writing to the capture > file; you could write to "/dev/null" by doing "-w /dev/null", which > would eliminate most of that overhead, letting you factor it out. > - > This is the TCPDUMP workers list. It is archived at > http://www.tcpdump.org/lists/workers/index.html > To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe > - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
