Messages in this thread | | | Date | Thu, 24 Jun 1999 03:10:05 +0300 | From | Matti Aarnio <> | Subject | Re: Linux and Network Flight Recorder |
| |
I really think this should be at linux-net@vger.rutgers.edu, or possibly even at the netdev@nuclecu.unam.mx (did I remember it right?).
On Thu, Jun 24, 1999 at 12:37:25AM +0200, Jamie Lokier wrote: > yodaiken@chelm.cs.nmt.edu wrote: > > Is it known that zero copy is the only way to deliver this? Last time > > I looked at it, memory was much faster than networks. > > Zero-copy delivers. > Some benchmarks from a user-space network implementation: > > Zero-copy 115Mbyte/s 6% CPU > Single-copy 82Mbyte/s 97% CPU
And pray tell, what does this "6% CPU" really mean ? BSD and Linux do account interrupt-side work differently.
Unless the "Zero-copy" system really begins by supplying set of buffer descriptors that 1) are in userspace, and 2) already are locked into memory, and 3) can be mapped into physical addresses for the network card DMA, I don't believe into this claimed zero-copy thing...
I don't think the BPF does quite work that way.
A true zero-copy would mean that the network card DMA engine is receiving data straight into user address space. Easiest would there be dropping data into buffers within a SysV-SHM segment(s).
Modern network cards can work with memory based descriptor lists quite fine.
Now how to tell the user-space in most efficient manner, that new packet(s) have arrived ? Busy poll is -- not so nice a thing...
A SysV semaphore where the user-space process can wait for announ- cement(s) about interrupts ? (And meanwhile the card can pull in more packets while the first has been announced to the userspace.)
So, the network card driver and parts of the userspace must both be in tight co-operation to really get the full feed in, and no copying around in kernel space is to be allowed. Trick-BFP, or not (preferrably not..)
At work I might end up building something like this to monitor full-blast giga-ether flows, and possibly STM-1 or STM-4 ATM flow contained IP frames.
Propably in form where the ethernets 6+6+2 prefix is stored into separate buffer (possibly same one for all packets), then IP's 20 bytes plus some application bytes (TCP/UDP/whatnot), say 64 in total into packet specific frames, and all the rest into common "junking" buffer of 8000+ bytes. (Ethernet MACs aren't interesting in between core routers.)
Such will require some trick playing with the chained buffer descriptors, so be it :) (We get aligned IPv4 frames with that trick even with e.g. Tulip cards.)
NFR's requirements are likely different, like wanting full MAC frames.
> - Alteon ACEnic Tigon-2 PCI > - 400MHz Pentium II (single processor) > - BX chipset > - 64Mb main memory > - 512k L2 cache > > I don't very much is actually _done_ with that data though. > > enjoy, > -- Jamie
/Matti Aarnio <matti.aarnio@sonera.fi>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |