On Thu, 2007-04-12 at 06:32 +0300, Avi Kivity wrote: > I hadn't considered an always-blocking (or unbuffered) networking API. > It's very counter to current APIs, but does make sense with things like > syslets. Without syslets, I don't think it's very useful as you need > some artificial threads to keep things humming along. > > (How would userspace specify it? O_DIRECT when opening the tap?)
TBH, I hadn't thought that far. Tap already has those IFF_NO_PI etc flags, but it might make sense to just be the default. From userspace's POV it's not a semantic change. OK, just tested: I can get 230,000 packets (28 byte UDP) through the tun device in a second (130,000 actually out the 100-base-T NIC, 100,000 dropped). If the tun driver's write() blocks until the skb is destroyed, it's 4,000 packets. So your intuition was right: skb_free latency on xmit (at least for this e1000) is far too large for anything but an async solution. Will ponder further. Thanks! Rusty. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
