On Sun, 13 Jul 2003, Ben Greear wrote: > Guy Harris wrote: > > On Sun, Jul 13, 2003 at 03:32:56PM -0700, Yuchung Cheng wrote: > > > >>I also run tcpdump on a busy gigabites link (90MBps) and tcpdump is dropping > >>lots of packets and locking up the cpu, is there any patch for using Linux > >>sendfile(2) to minimize dumping to file overhead for capturing? > > > > > > Well, that might be an interesting patch, but it wouldn't write out a > > tcpdump-format file, it'd write out a Linux-format file (and given that > > at least some of the information in the packet header isn't returned by > > "recvfrom()" in the buffer, it's returned from elsewhere, it might not > > even be possible without a *kernel* patch as well). > > Seems you cannot use sendfile when reading from a socket, so can't > capture like this. It will definately need a kernel module.
Well, the first poster's question does not make any sense, but it does not seem to me that the claim that you can't use sendfile when reading from a socket makes any sense either. I thought Linux's sendfile was symmetric in that regard, unlike, say, sendfile under FreeBSD, where you cannot use sendfile to read from a socket. It seems to me that the real problem is that sendfile is designed to copy to/from a socket and a file while in kernel-space to avoid the overhead of copying the data out to user-space and back again. I don't think that with packet filtering you really have a socket, although I could be wrong on that score. Regards ----- Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
