lkml.org 
[lkml]   [1999]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.051 / U:1.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site