On 02.07.2011, at 11:45, Pekka Enberg <penberg@xxxxxxxxxx> wrote: > On Fri, 2011-07-01 at 15:46 +0200, Alexander Graf wrote: >>> That's pretty impressive (if it does not come at the expensive of >>> features that Qemu's slirp code has) - and the thing is that we don't >>> actually have to implement the vast majority of TCP-IP features, >>> because the transport between the guest and the host is obviously >>> reliable. >> >> I don't see how it would. Once you overrun device buffers, you have to >> do something. Either you drop packets or you stall the guest. I'd >> usually prefer the former :). > > If we make the buffers large enough, will this matter in practice? Would you trust a system based on statistics? :) Also, I'm not sure you can easily change the size of the buffers. If your emulated network adapter has a buffer of n bytes for sg lists, that's what you get. No more, no less. > >>> This patch-set turned out to be a *lot* more simple than i first >>> thought it would end up. >>> >>> Simpler also means potentially faster and potentially more secure. >>> >>> ( The lack of ipv6 is not something we should worry about too much, >>> ipv4 should scale up to a couple of hundred thousand virtual >>> machines per box, right? ) >> >> Well, if the system you're trying to connect to supports ipv4, sure. >> If it doesn't, tough luck :). > > Does that mean that the guests would effectively be ipv4-only? That'd be > unfortunate. Well, for starters, yeah. Unless you also implement ipv6 in the user networking or add networking support an osi level below (tap, macvtap, ...). User networking is great for quick testing, but it's by no means able to replace network forwarding on the link layer. It's really a matter of use cases. Just imagine you want to use kvm-tool to test an ipx/spx stack :). Alex > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
