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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
